Volume 10: OGC CDB Implementation Guidance (Best Practice)

A CDB data store instance is file system independent, (i.e., the use of a specific file system is not specified). However, implementation of the CDB standard does require that the file system be able to support a minimal set of capabilities as listed below:

The CDB standard is Operating System (OS) independent; it does not mandate the use of a specific OS. However, compliance to this standard does require that the operating system be able to support a minimal set of capabilities.

Any operating system implementing the CDB standard should support at a minimum the following basic OS properties:

Implementation of the CDB standard is hardware independent. The CDB standard does not mandate the use of particular hardware platforms. Furthermore, any general-purpose hardware compatible with modern Operating Systems (OS) can be used for a CDB implementation.

Implementation of the CDB standard assumes that the system hardware shall support, as a minimum, the subsystems described in the following requirement.

Hardware memory for systems implementing the CDB standard should support:

Immediate and indirect memory addressing modes

The CDB Standard does not provide guidelines regarding its implementation within specific vendor SE toolsets and vendor simulation architectures. This clearly falls outside of the scope of the CDB Standard. The CDB Standard is focused a physical and logical storage structure and guidance on storage formats for information (i.e., it merely describes data) for use in simulation.

The CDB model lends itself to a real-time implementation within simulation architectures. This capability requires that the vendor’s client-device be adapted with a Run-Time publishing (RTP) software function which transforms the CDB structured data into the client-device’s internal legacy/proprietary format. This is a new concept for the simulation industry and consequently there is considerable confusion regarding the implementation of Off-line and Run-Time Publishers (RTPs). While much of the attention has focused on RTPs, a similar set of considerations apply to the implementation of an off-line CDB capability (CDB is used as a Refined Source Data Repository). In this latter case, the capability requires that the vendor develop an off-line CDB import function which ingests the CDB into their Synthetic Environment Creation toolset. Once imported, the vendor toolset could produce the vendor’s proprietary data format through an off-line compilation function.

By definition, the function of an RTP is to bridge the “gap” (or adapt) between CDB data schema and the client-device’s internal (proprietary) data schema. Since this gap is unknown, it is impossible in this addendum to provide hard-and-fast rules and detailed estimates for the implementation of an RTP (or a CDB import function).

Note that there are many alternatives open to a vendor when considering the level of compliancy he wishes to achieve. The level-of-effort is essentially a function of the level of compliancy the vendor wishes to achieve, and the size of the intrinsic “gap” between the CDB data schema and his device’s internal schema.

Nonetheless, this section highlights aspects of the CDB that are particularly significant when considering such implementations. These aspects dominate the level-of-effort required to achieve ideal CDB compliancy.

The CDB Standard limits itself to a description of a data schema for Synthetic Environmental information (i.e., it merely describes data) for use in simulation. The CDB Best Practices provide rigorous guidance 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. This ensures that the all CDB data is understood, interpreted and efficiently accessed in the same way by each client-device. The CDB standard does not include detailed guidelines regarding off-line database compliers or runtime publisher implementations, since this would be tantamount to dictating internal vendor formats which are by their very nature proprietary.

The CDB Standard DOES NOT specify:

While the CDB standard does not govern the actual implementation of client-devices, it is expected that the CDB standard will have a “unifying” effect on the implementation of each vendor’s client-device by virtue of the fact that they will share the exact same Synthetic Environmental data. It is expected that side-by-side comparisons will be easier to undertake due to the fact that devices will run off the exact same runtime data. Prior to the advent of the CDB standard, side-by-side comparisons were considerably more difficult to undertake due to the fact the entire SE creation chain starting from raw source was implicated in such evaluations.

If we set aside legacy considerations, the simplest approach to adopting the CDB would require that client-devices ingest the CDB natively, i.e., client-devices would handle all of the CDB data schema/semantics without any off-line or run-time intermediary.

In practice however, most vendors have extensive legacy SE assets and cannot afford to obsolesce these. As a result, most client-devices must continue to support their own proprietary legacy runtime databases. Given these considerations, two solutions are possible.

The following discussion attempts to qualify the level-of-effort to achieve CDB compliancy. The discussion applies equally to both paradigms, i.e., the CDB Runtime Publishing paradigm and the CDB import-then-compile paradigm.

In the case where a client-device already supports most of data schema and semantics concepts of the CDB, then the RTP (or import-then-compile) software is proportionally less complex. For instance, if an IG already supports the concepts of tiles, of levels-of-detail, of layers and understands the concepts of datasets such as terrain texture, gridded terrain elevation, gridded terrain materials, etc. then there is a modest amount of work to be performed by an RTP.

Clearly, the algorithmic complexity of an RTP and the computational load imposed on the RTP is directly proportional to the above-mentioned “gap.” The larger the “gap,” the more expensive a RTP is to develop and the more computational resources need to be allocated to implement it. Conversely, with a smaller “gap,” the RTP development is straightforward and relatively few computational resources need to be allocated to this function.

In order to assess the level-of-effort to adopt the CDB model, the vendor must first evaluate the similarity of data schemas between the CDB and his client-device, in particular, the vendor must assess whether they espouse the following fundamental CDB concepts:

In the case where a client-device does not intrinsically support one or more of the above-mentioned CDB concepts, the RTP must perform SE conversions that will likely fall beyond those of mere format/structure manipulations. Such conversions may affect the precision of the data, its semantic meaning, etc. and thus can compromise certain aspects of runtime correlation.

The CDB data model favors modern up-to-date implementations of client-devices. In effect, the level-of-effort to develop an RTP for an obsolete legacy device is likely to be greater than for a modern device. This is because early approaches in digital computer based flight simulation were more severely constrained by severe hardware, software and data source limitations. Consequently, simulation engineers made important compromises between a subsystem’s targeted fidelity and its level of generality, scalability, abstraction, and correlation with other simulator client-devices. In many cases, engineers reverted to complex support data structures (generated off-line) in order to reduce the computational load at runtime.

A classic example of this was the use of Binary Separation Planes (BSPs) data structures ^[2] which were required prior to the widespread adoption of Z-buffers by the IG vendors. The CDB standard does not make provisions for this and as such, the RTP for legacy BSP-based IG devices would be burdened with the rather difficult task to generate BSPs in real-time.

Given their tremendous benefit, the concepts of paging (e.g. tiles) and levels-of-details have steadily been adopted by simulation vendors over the past 15-20 years and have been applied to most datasets, notably terrain and imagery datasets. (See Appendices G and F of the Volume 2: OGC CDB Core Model and Physical Structure Annexes for a rationale for Tiles and Levels-of-detail). As a result, it is not expected that the CDB tiles and LOD concepts will be a problem for most vendors. Note however that CDB applies these two concepts to ALL dataset layers including vector features and 3D models.

Figure 1-1: Use of a CDB conformant data store as an Off-line Repository, illustrates the deployment process of a CDB conformant database when it is used solely as an off-line Master repository. This approach follows the SE deployment paradigm commonly used today within the simulation community. The use of a CDB conformant data store as an off-line environmental data repository offers immediate benefits, namely…

Note that the use of the use of CDB conformant data store as an offline repository does not impose any change to the simulation training equipment (i.e., no modifications to client-devices are required ^[5]). However, the deployment of the synthetic environment is similar to the conventional approaches used in industry requiring the time-consuming, storage-intensive, off-line compilation of proprietary runtime databases to each client-device. Furthermore, the computing demands on the data store generation facility are significantly greater because the entire data store must be published off-line for each client-device before it can be deployed. These costs rapidly escalate with the complexity and size of the synthetic environment, the number of supported client-devices and the number of supported training facilities. For complex data stores, these costs can far outweigh the costs of the runtime publishers attached to each simulator client-device.

Figure 1-1. Use of CDB Conformant Database as an off-line Database Repository

In most modern SE tool suites in-use today, the Data Preparation step shown in Figure 1-2: SE Workflow with a CDB structured data store as an Off-line Repository consists of many sub-steps usually applied in sequence to each of the datasets (aka layers) of the SE. In effect, this aspect of the modeler’s responsibilities is virtually identical to that of a GIS ^[6] specialist. As a result, many of the simulation equipment vendors offer SE authoring tools that integrate best-of-breed COTS ^[7] GIS tools into their respective tool suites. The steps include the following.

Figure 1-2. SE Workflow with CDB as an off-line Repository

The effort expended during the Data Preparation and Modeling step is mostly independent of the targeted simulation devices and the targeted applications. Consequently, the results of the data preparation step can be stored into a Refined Source Data Store (RSDS) and then re-targeted at modest cost to one or more simulation devices.

The standardization of simulation data stores can greatly enhance their portability and reusability. The CDB Standard and associated OGC Best Practices offers a standardized means to capture the effort expended during the Data Preparation and Modeling step. In effect, a CDB structured database becomes a master repository where refined source can be “accumulated” and managed under configuration control.

While standardization of format/structure is essential to achieve high portability, interoperability and reuse, the SE content must be ideally developed so that its content is truly independent of the training application. Therefore, we strongly recommend that the SE content of the CDB structured repository be developed to be independent of the training application.

Historically, SEs were developed for a single, targeted simulation application (e.g., tactical fighter, civil and air transport, rotary wing, or ground/urban warfare). In effect, the intended training application played an important role in determining the RSDB content because SE developers were constrained by the capabilities of the authoring tools and of the targeted simulation device. Unfortunately, this tailoring of SE was performed too early during the SE workflow and severely limited the applicability and re-use of the SE. Application tailoring can require either data intensification ^[8] or data decimation ^[9].

Once the SE developer has completed his work in creating the various data layers of the RFDS, he must offline publish (aka “compile”) the SE into one or more device-specific data publishing steps. As we will discuss in section 6.4, Use of CDB structured data store as a Combined Off-line and run-time data store Repository, the device-specific off-line compilation step can be entirely omitted if the targeted training equipment is CDB-compliant.

While an off-line publishing approach does not offer all of the benefits described in this section, it nonetheless provides an easy, low-effort, migration path to CDB. Any equipment vendor can easily publish the data into their proprietary runtime format. Firstly, the publishing process is facilitated by the fact that the CDB standard provides guidance on how to use industry standard formats. However, the CDB model goes much further in that it specifies how to use these formats in a global, standardized data model suited to high-end real-time simulations. This greatly facilitates the work of SE developers. Thus, the CDB model provides a far simpler and straightforward means of interchanging refined source data.

A data store conforming to this CDB standard can be both used an offline repository for authoring tools or as an on-line (or runtime) repository for simulators. When used as a runtime repository, a CDB conformant data store offers plug-and-play interchangeability between simulators that conform to the CDB standard. Since a CDB conformant data store can be used directly by some or all of the simulator client-devices, it is considered a run-time environment data store.

In addition to the benefits outlined in section 6.3, the use of the CDB conformant data store as a combined off-line and run-time repository offers many additional benefits.

Figure 1-3: Use of CDB Model as an Off-line and On-line Data Store Repository, illustrates the CDB structure as an off-line Master data store repository for the tools and as an online Master data store repository for the training facilities. Note that the deployment of the synthetic environment to the training facilities involves a simple copy operation. The deployment of a CDB conformant data store is further simplified through an incremental versioning scheme. Since only the differences need be stored within the data store, new versions can be generated and deployed efficiently.