RIEDP Study Group Final Report - Simulation Interoperability

Transcription

SISO-REF-043-2012, RIEDP Study Group Final Report
SISO-REF-043-2012
Reuse and Interoperation of
Environmental Data and Processes
(RIEDP) Study Group
FINAL REPORT
08 October 2012
Submitted to:
SISO Standards Activities Committee
SAC approved: 06 November 2012
EXCOM approved: 13 November 2012
Copyright © 2012 by the Simulation Interoperability Standards Organization, Inc.
P.O. Box 781238
Orlando, FL 32878-1238, USA
All rights reserved.
Permission is hereby granted to quote any of the material herein, or to make copies thereof, for noncommercial purposes, as long as the proper attribution is made and this copyright notice is included. All
other uses are prohibited without written permission from the SISO Inc. Board of Directors.
SISO Inc. Board of Directors
P.O. Box 781238
Orlando, FL 32878-1238, USA
Copyright © 2012 SISO. All rights reserved
This is an approved SISO Reference Product.
Page 2 of 30
TABLE OF CONTENTS
1.0 INTRODUCTION / OVERVIEW .............................................. 5
1.1
1.1.1
1.1.2
1.1.3
1.2
1.3
BACKGROUND/HISTORY
5
LVC Environment Needs
Fall 2009 SIW Special Workshop
Harmonization Objective
SCOPE AND PURPOSE OF GROUP AT EXECUTIVE LEVEL
OVERALL PROGRESS OF GROUP AT EXECUTIVE LEVEL
5
6
7
7
8
2.0 REFERENCES ....................................................................... 8
3.0 DEFINITIONS ....................................................................... 9
4.0 ACRONYMS AND ABBREVIATIONS .................................... 9
5.0 STUDY GROUP REPORT .................................................... 10
5.1
5.2
5.3
5.4
5.5
5.5.1
5.5.2
5.5.3
5.5.4
5.5.5
5.6
5.7
STUDY GROUP OFFICERS
STUDY GROUP MEMBER LIST
TASK DESCRIPTIONS FROM THE TOR
PRODUCT DESCRIPTIONS FROM THE TOR
SIGNIFICANT RESULTS AND/OR ACHIEVEMENTS
Discussion for Significant Result Area 1: STUDY PROCESS
Discussion for Significant Result Area 2: RIEDP SG MEETINGS
Discussion for Significant Result Area 3: SURVEY
Discussion for Significant Result Area 4: RDGPM
Discussion for Significant Result Area 5: SOLUTION AREAS
SUMMARY OF TECHNICAL FINDINGS
RECOMMENDATIONS FOR FUTURE SISO ACTIONS - THE WAY AHEAD
10
10
10
11
11
11
12
13
16
26
29
30
APPENDIX A SUPPLEMENTAL / SUPPORTING RESULTS –
SURVEY CONDUCTED ....................................................... 31
A.1
A.2
A.2.1
A.2.2
A.2.3
A.2.4
A.3
SURVEY TEMPLATE APPLIED
GUIDELINE FOR SURVEY
Object
Background
Guidelines
Annex A – Template
SUMMARY OF ALL INTERVIEWS
31
37
37
37
39
44
46
Page 3 of 30
A.3.1
A.3.2
A.3.3
A.3.4
A.3.5
A.3.6
UK MoD
NATO / Mission Land
USAF/AFRL
US Army / SE Core
US Navy (NAVAIR)
Complementary information on SE Core
46
46
46
47
48
48
TABLE OF FIGURES
Figure 1 – Different Views of Environmental Representation (Figure Courtesy of
CCTT/SEDRIS) .................................................................................................................. 5
Figure 2 – US DoD Terrain Database Initiatives (Figure Courtesy of US Air Force) .... 6
Figure 3 – SIW Fall 2009 Special Workshop ................................................................... 6
Figure 4 – Harmonization Objective ............................................................................... 7
Figure 5 – Study Process .............................................................................................. 11
Figure 6 – Questionnaire Outlines ................................................................................ 13
Figure 7 – Reference Process Model ............................................................................ 18
Figure 8 – Reference Abstract Data Model................................................................... 20
Figure 9 – Attributions – Case of Linear Classes ........................................................ 21
Figure 10 – Areas of Convergences & Divergences .................................................... 21
Figure 11 – Principle of Attribution Schema ................................................................ 25
Figure 12 – Standardization Areas................................................................................ 27
Page 4 of 30
1.0 INTRODUCTION / OVERVIEW
1.1
BACKGROUND/HISTORY
This document is the final report of the Reuse and Interoperation of Environmental Data & Processes Study
Group (RIEDP-SG). It summarizes the activity accomplished during the performance period, according to
the RIEDP-SG Terms of Reference (TOR), and proposes the scope of a Product Development Group for
continuation of this effort.
The three sub-sections below provide background of the RIEDP SG with regard to the topics that include:
LVC Environment Needs, Fall 2009 SIW Special Workshop and the Harmonization Objective.
1.1.1
LVC Environment Needs
The utilization of Distributed Mission Operations (DMO) through Live-Virtual-Constructive (LVC)
simulation applications in a joint and coalition context is growing. This requires consistency of the
simulation environment for the various systems, applications, and participants.
Visual Database
Electronic Maps
Mobility Database
CGF Database
Paper Maps
Figure 1 – Different Views of Environmental Representation (Figure Courtesy of CCTT/SEDRIS)
Production and reuse of environmental databases is a significant part of the overall M&S development and
deployment cost. An environmental database typically may include an integration of terrain, ocean,
weather/atmosphere, space, sub-surface, and all related data required for simulation and modeling of entities
and sensors. Capitalizing on approaches that reduce the overall cost is an important topic of interest to the
broader M&S community.
Various levels of standardization that address different aspects of the end-to-end problem exist, and range
from international standards to ad hoc approaches. On-going projects in a number of international
government programs, as well as initiatives and innovative approaches from industry, continue to contribute
to solutions in this area.
However, the activities in the community are often fragmented or disjoint, and sometimes do not or cannot
leverage existing capabilities, standards, or lessons-learned. In some cases, these are driven by the special
Page 5 of 30
requirements of specific projects or activities. This results in multiple solutions in the community, differing
in their scope, breadth, or depth.
Figure 2 – US DoD Terrain Database Initiatives (Figure Courtesy of US Air Force)
1.1.2
Fall 2009 SIW Special Workshop
A Special Workshop on the Reuse of Environment Data for Simulation: Processes, Standards and Lessons
Learned (see Figure 3) was held during the Fall 2009 SIW to inform and discuss with international
simulation stakeholders the current state of the art and the varying degrees of requirements in this area. This
Special Workshop provided an opportunity for the international community involved with the creation,
dissemination, and development of environmental representations and effects databases to discuss existing or
emerging approaches, processes, standards, and lessons learned.
Figure 3 – SIW Fall 2009 Special Workshop
Page 6 of 30
The presentations at the Special Workshop indicated that simulation data producers use the same high-level
process in the generation of their environmental data products. Source Data, regardless of detail or
complexity, is used in internal data generation processes to produce one or more final products (usually)
specific to a particular set of applications, clients, or systems. However, the data generation processes differ
from one producer or integrator to another. These include differences in processing, organizing, and
assembling the various source data into a “database” to produce a consistent, corrected, and correlated
dataset that becomes the subsequent source and reference from which various target application databases
would be derived. Depending on the application and requirements, the degree of data integration and fusion
can vary in such databases.
1.1.3
Harmonization Objective
These differences in the detailed database generation processes can often complicate data reuse and
jeopardize the final interoperability of the target applications. At the same time, these differences usually
occur at the highly (user) interactive phase (one of the most costly phases) of the database generation
process, making it a candidate for optimization, harmonization and, if possible, standardization, by fostering
reuse of existing data.
GIS World
Initiative A
Initiative B
Figure 4 – Harmonization Objective
Therefore, as shown in figure 4, the objective is the harmonization of environmental data representations and
processes at the level immediately following the source data level but before the runtime/propriety level,
recognizing that there is a broad range within this band. In addition, it is also a desirable objective to retain
the data form (or format) as close to the source data, while at the same time keeping the internal data
consistency (intrinsic correlation factor). Added to this is the desire to not introduce specific target
application constraints at this level. Those constraints should be addressed separately by each target
application during run time.
1.2
SCOPE AND PURPOSE OF GROUP AT EXECUTIVE LEVEL
The large number of attendees at the Special Workshop has shown interest in harmonizing source data and
processes. Moreover, through their feedback forms, some of the attendees volunteered to participate in
future workshops and/or study groups with the aim of harmonizing, as much as possible, the production
approaches to environmental database generation, capitalization, and reuse.
Page 7 of 30
The RIEDP-SG met for the first time in Orlando, FL during the Spring 2010 Simulation Interoperability
Workshop (SIW).
With a focus on the needs of the Aircrew Training and Mission Rehearsal communities, the Study Group set
a goal to help merge, or at least bring to the table, the various initiatives involved in Aircrew Training and
Mission Rehearsal area. These initiatives include, in the U.S., the Air Force Common Dataset (AFCD), the
NAVAIR Portable Source Initiative (NPSI), the Army’s Synthetic Environment Core (SE Core)/Master Data
Base (MDB), and the Special Operations Command’s Common Database (CDB). In Europe, in support of
the French Air Force community, Sogitec and Thales have undertaken a similar process of harmonization
(the French Air Force approach), with principles close to those adopted by the U.S. Air Force Rehearsal
Enabling Simulation Technologies (REST) initiative and the U.S. NAVAIR NPSI. The UK MoD and
Rheinmetall in Germany have also been working on similar initiatives. To improve the readiness of the
multinational forces for coalition operations, there is strong interest for international standardization in this
area.
One of the key benefits of this Study Group was anticipated to be the establishment and propagation of a
common set of terminology for discussing and describing the environmental data and processes. Inputs and
considerations from subject matter experts from the U.S. and international M&S communities would provide
the opportunity for harmonizing domain terminology.
1.3
OVERALL PROGRESS OF GROUP AT EXECUTIVE LEVEL
The Study Group has operated for eighteen months, with the broad goal of evaluating the level of interest and
the best approaches for the development and utilization of common representations of environmental data
and processes for use in simulation applications.
Within that broader context, the Study Group has investigated and focused on environmental data that can be
immediately used in Aircrew Training and Mission Rehearsal applications. Specifically, the focus of this
effort has taken into account the U.S. AFCD, NPSI, MDB and CDB development efforts, UK MoD
Synthetic Environment (SE), NATO Mission Land, and French Air Force approach processes and data
models, with the expectation of achieving improved interoperability and reuse.
2.0 REFERENCES
Author’s
Name
NAVAIR
NAVAIR
USAF/TSPG
Document Title
Event Name
Date Published
Name of Publication
“NPSI Schema 2.3:
NPSI Standard for
Reusable Source
Dataset Metadata.”
“MPRD 2.1: NPSI
Standard for Material
Properties Reference
Database.”
AFCD Common Data
Set Version 2.0
N/A
30 Nov ‘07
N/A
N/A
30 Sept ‘06
N/A
N/A
1 Dec ‘11
N/A
Page 8 of 30
3.0 DEFINITIONS
Term
Attribution
Database
Intermediate Level
Source data
Definition
The “attribution” is the assignment of properties to an object class, or an object
instance describing the environment. Attributes can be included explicitly by direct
attachment to the object or instance, or implicitly by inheriting down a hierarchy tree.
Attributes can be simply define by attribute names and their value, or defined by
more complex schemas, called attributions rules.
An “environmental database” refers to the sets of geospatial data and all related data
required for simulation and modeling of entities and sensors. The production of an
environmental database starts from source data (see definition below) up to the
generation of target application databases, also called runtime databases.
Depending of the step in the process, the environmental database can have different
types of representation.
The “intermediate level” in this document refers to an intermediate step in the
production process of the environmental database allowing to optimizing the
capitalization of database creation efforts without inducing too many constraints from
specific target applications.
The source data refers typically the geospatial data used to produce the
environmental database. The main categories of source data are the imagery, the
elevation and the vector information. The source data are stored and exchanged in
source data formats widely used by GIS community.
4.0 ACRONYMS AND ABBREVIATIONS
Acronym
AFCD
AFRL
CCTT
CDB
DBGS
DFDD
DMO
DTED
DTS2
EDCS
EDCS
FACC
FCC
GIS
LVC
MDB
NATO
NFDD
NPSI
OF
RADM
RDGPM
Definition
U.S. Air Force Common Dataset
Air Force Research Laboratory
Close Combat Tactical Trainer
Special Operations Command’s Common Data Base
Database Generation System
DGIWG Feature Data Dictionary
Distributed Mission Operations
Digital Terrain Elevation Data
Defense Training & Simulation Services
ISO/IEC Environmental Data Coding Specification
Environment Data Coding Specification
DGIWG Feature and Attribute Coding Catalog
Feature Classification Code
Geographical Information System
Live-Virtual-Constructive
SE Core’s Master Data Base
North Atlantic Treaty Organization
NSG (National System for Geospatial Intelligence) Feature Data Dictionary
NAVAIR Portable Source Initiative
OpenFlight
Reference Abstract Data Model
Reference Database Generation Process Model (RDGPM) [made up of a Reference
Page 9 of 30
Acronym
Definition
Process Model (RPM) and a Reference Abstract Data Model (RADM)]
U.S. Air Force Rehearsal Enabling Simulation Technologies
Reuse and Interoperation of Environmental Data and Processes
Reference Process Model
Synthetic Environment
Army’s Synthetic Environment Core
Spatial Reference Model
SEDRIS Transmittal Format
Terms of Reference
REST
RIEDP
RPM
SE
SE Core
SRM
STF
TOR
5.0 STUDY GROUP REPORT
5.1
STUDY GROUP OFFICERS
Officer Role
Chair
Vice Chair
Secretary
5.2
Name
Jean-Louis Gougeat
Steve Stephens
Warren Macchi
Organization
Sogitec Industries
AFRL/RHAE (REST PM)
Abamis IT Solutions
Country
France
USA
USA
STUDY GROUP MEMBER LIST
Name
Bailey, Grant
Castaner, Gilbert
Cox, Robert (Rob)
Foley, Paul
Howard, Kerey
Kent, Amos
Mamaghani, Farid
Rind, Christophe
Sieverding, Mike
5.3
Organization
UK MoD
Sogitec Industries
PEO STRI (PM CONSIM/SE Core)
U.S. DoD Terrain M&S Executive Agent
NAWC Training Systems Division
AFRL/RHAE (REST DPM)
SEDRIS
Sogitec Industries
AFRL/RHAE (REST SME)
Country
UK
France
USA
USA
USA
USA
USA
France
USA
TASK DESCRIPTIONS FROM THE TOR
The main tasks of the group as originally defined in the TOR are the following:
No.
1.
2.
Task Title
Informal Survey
Reference Database
Generation Process
Model
Task Description
Conduct an informal survey of the U.S. and international Aircrew Training and
Mission rehearsal M&S communities for on-going initiatives that might serve as
part of an overall common solution. These included the AFCD, the NPSI, the SE
Core / MDB, the CDB, and the related French Air Force approach.
Define and document a Reference Database Generation Process Model that may
include:
a. Establishing a common terminology,
b. Identifying common areas in data generation processes between initiatives,
Page 10 of 30
No.
Task Title
3.
Time and Effort
Assessment
4.
Final Report
5.4
Task Description
c. Identifying requirements for one or more common solutions to foster
interoperability and reuse of environmental databases and processes,
d. Recommending how to expand the initial focus to cover additional
requirements.
Assess the time and effort required to develop and deploy one or more common
solutions for the interoperability and reuse of environmental databases and
processes.
Produce a final report on the RIEDP-SG activity.
PRODUCT DESCRIPTIONS FROM THE TOR
The main products of the group as originally defined in the TOR are as follows.
No.
Product Title
1.
Informal Survey
2.
Reference Database
Generation Process
Model
3.
Time and Effort
Assessment
4.
Final Report
5.5
5.5.1
Product Description
An informal survey of the U.S. and international Aircrew
Training and Mission rehearsal M&S communities
A Reference Database Generation Process Model that establishes
a common terminology, identifies common areas in data
generation processes between initiatives, identifies requirements
for one or more common solutions to foster interoperability and
reuse of environmental databases and processes and recommends
how to expand the initial focus to cover additional requirements.
Time and effort required to develop and deploy one or more
common solutions for the interoperability and reuse of
environmental databases and processes
Final report on the RIEDP-SG activity.
SIGNIFICANT RESULTS AND/OR ACHIEVEMENTS
Discussion for Significant Result Area 1: STUDY PROCESS
Tasks 1 and 2 were undertaken according to the following 8-step process:
Dataset provider type
Initiative 1
Documentation
Initiative 1
Capabilities
6
Initiative 2
Documentation
2
Initiative n
Documentation
Initiative 2
Capabilities
Questionnaire
4
3
5
Reference Database
Generation Process Model
Data Model
Initiative n
Capabilities
7
Assessment
Database
provider type
1
Process
Breakdown
8
Areas of
Divergence
Initiatives
(AFCD, NPSI, CDB, SECORE, Fr, NATO, UK)
Figure 5 – Study Process
Page 11 of 30
1.
2.
3.
4.
5.
6.
Begin from the collection of existing approaches (US and European initiatives)
Use existing approaches to develop the survey guidelines or questionnaire
Distribute the survey guidelines to all initiatives
Use the results of the survey to capture each approach's "capabilities"
Extract (factor out) common approach building blocks, as well as unique steps
Build a "Reference Database Generation Process Model" (RDGPM) made up of a Reference Process
Model (RPM) 1 and a Reference Abstract Data Model (RADM).
7. Evaluate each approach's capabilities against the RDGPM
8. Identify areas of convergence and divergence between initiatives.
5.5.2
Discussion for Significant Result Area 2: RIEDP SG MEETINGS
The work was accomplished by a core team, a subset of the participating members, as identified in section
above.
Periodically, meetings were organized in order to present the current results to the community, to collect
responses, reactions, and additional information. These were held in conjunction with international M&S
events:
•
•
•
•
•
•
•
•
•
Organizational meeting during Spring SIW 2010 in Orlando – Apr ’10;
Meeting #2 during ITEC 2010 in London – May ’10;
Meeting #3 during Image in Phoenix - July ’10;
Meeting #4 during Fall SIW Orlando - Sept ’10;
Meeting #5 during I/ITSEC Orlando- November/December ’10;
Meeting #6 during Spring SIW Boston- Apr ’11;
Meeting #7 during Fall SIW Orlando – Sept ’11;
Meeting #8 during I/ITSEC Orlando – November/December ‘11;
Meeting #8 during Spring SIW Orlando – Mar ‘12;
Web meetings were also conducted between these in-person meetings:
•
•
•
•
•
•
•
•
•
1
Web meeting #1, on November the 19th ‘10
Web meeting #2, on February the 3rd ’11;
Web meeting #3, on March the 30th ’11;
Web meeting #4 on April the 5th’11;
Web meeting #5, on April the 6th’11;
Web meeting #6, on June the 6th ’11;
Web meeting #7, on September the 2nd ’11
Web meeting #8, on January the 27th ’12
Web meeting #9, on August the 10th‘12
During the Study, we realized that RDGPM, despite its name, needed to be more than a process model. So we added a
reference abstract data model (RADM) to the Reference Process Model itself (RPM). The RDGPM will be revised to
RDGM when the PDG is initiated to reflect these changes.
Page 12 of 30
5.5.3
Discussion for Significant Result Area 3: SURVEY
The preparation, execution and exploitation of the informal survey (steps 1 to 4 of the Study Process) are
presented in the sections below. Supplemental details for the survey to include the survey template, the
survey guidelines and summary of results are provided in Appendix A. Items listed below, supporting the
execution of the survey, are described in more detail in the subsections below:
•
•
•
•
•
Survey Guidelines – Questionnaire;
Initiatives and POCs;
Initial Responses;
Clarification actions;
Conclusion of the Survey.
The results of the analysis in terms of RDGPM and the areas of convergence and divergence are addressed in
the following sections.
5.5.3.1 Survey Guidelines – Questionnaire
In order to allow each initiative representative to provide valuable / easy-to-use data about the initiative’s
process and methods for creating simulation environmental databases and to make sure these data would be
comparable to the other initiatives, a Survey Guidelines or Questionnaire was needed. In accordance with
steps 1 and 2 of the study process, a preliminary analysis based on the available documentation was
performed in order to discern the main trends. The questionnaire was derived and organized as shown in the
diagram below.
 Name
NameofofInitiative
Initiative
 Point
PointofofContact
Contact
Data
DataRepresentation
Representation
Process
ProcessBreakdown
Breakdown

Environmental
EnvironmentalData
Data

Source
SourceData
Data

Stages
Stagesininthe
theprocess
process

Operation
Operation

Environmental
EnvironmentalRepresentation
RepresentationModel
Model

Spatial
Spatialreference
referenceframe
frame
  and
andtheir
theirlocalization
localizationininthe
theprocess
process

Target
Targetapplications
applications

Imports/exports
Imports/exports
  and
andtheir
theirlocalizations
localizationsininthe
theprocess
process

Data
DataOrganization
Organization

Software
 Softwarearchitecture
architectureand
andtools
tools

Data
DataFormats
Formats

Metadata
 Metadata

Reference
Referencedictionaries
dictionaries
 Glossary
Glossary
 List
Listofofdocumentation
documentation
 Data
Dataabout
aboutthe
theEnd
EndUser
User
 Further
Information
Further Information
Figure 6 – Questionnaire Outlines
The questionnaire was detailed into an Excel spread sheet (See template provided in appendix) and included
guidance to help respondents in answering the questions.
Additionally, a tentative Process Model (PM) and Data Model (DM) in UML representation were elaborated.
The PM was based on the concatenation of the practices of the different initiatives. The DM was based on
the characteristics of the level immediately following the source data level but before the runtime/propriety
Page 13 of 30
level, as produced by the Sogitec’s SINDBAD DBGS. These models were then used during the interviews
with the intent to consolidate the results into RPM and RADM.
5.5.3.2 Initiatives and POCs
The final version of the questionnaire was sent by the end of September 2010 to the points of contact
identified for each initiative, as listed in the table below.
Initiative
AFCD
NPSI
SE Core
CDB
French AF approach
Organization
USAF / AFRL
NAVAIR
US Army
USSOCOM
Sogitec/AAF
POC
Mike Sieverding / Amos Kent
Kerey Howard
Rob Cox
Earl Miller
Christophe Rind
Additionally, the questionnaire was sent to the following organizations that volunteered to participate after
the TOR had been finalized.
Initiative
UK SE
NATO Mission Land
German Army
Organization
MoD
NLR
Rheinmetall
POC
Grant Bailey
Arjan Lemmers
Bodo Randt
5.5.3.3 Initial Answers
The answers to the questionnaire were received during November 2010 from the following contributors in
the following order:
a
USAF/AFCD Initiative
The AFCD response to the questionnaire was received from USAF according to the schedule. The generation
process and the Data Model were described in detail according to the template. Many comments were
provided to help understanding.
The AFCD process is consistent with the process used as template in terms of stages. However:
• AFCD only specifies the first stages of the generic process, leaving the responsibility of producing the
final and runtime databases to the end data users (contractors).
• AFCD adds the notions of dataset 2 requirements, dataset cataloguing, and dataset validation, which
were not included in the template.
USAF representatives provided additional information on the AFCD data model. The AFCD approach shares
the same principles as the NAVAIR’s NPSI, described in the NPSI Metadata documentation. Attributes and
attribution rules need to be clarified.
2
AFCD and NPSI use the notion of dataset to designate a set of environmental data used and/or built by database
producers during their database generation process excluding the target application level data that they call a
(runtime) database. This includes data resulting from the operations of refinement, reconciliation and possibly
integration of source data.
Page 14 of 30
b
NAVAIR / NPSI Initiative
The NPSI response to the questionnaire has not been formally received. However, AFRL indicated that NPSI
and AFCD processes share the same principles (confirmed later by NAVAIR), and NPSI documentation was
provided by AFRL:
• “NPSI Schema 2.3: NPSI Standard for Reusable Source Dataset Metadata.”
• “MPRD 2.1: NPSI Standard for Material Properties Reference Database.”
c
US Army/SE Core/MDB Initiative
The SE Core response to the questionnaire was received from US Army according to the schedule. However,
the content was very limited due to restrictions being applied during the SE Core bidding and contract
renewal process.
Similar to the AFCD, the SE Core generation process is consistent with the template, controlling all stages
from raw data to run time databases including the notion of the Master Database (MDB)
Additional information on SE Core description have been provided and presented in the Appendix.
d
USSOCOM/CDB Initiative
The SOFPREP response to the questionnaire was received from USSOCOM according to the schedule, with
limited content, and instead referring to the CDB Specification for details. The CDB process is also
consistent with the template, covering all stages from raw data to runtime databases. However, CDB is
runtime- oriented, which impacts the data representation model.
CBD uses its own attributes dictionary and attribute rules (called Attribution Schema).
e
French Air Force Approach
The French Air Force response (illustrated with Sogitec SINDBAD solution) to the questionnaire was
received according to the schedule. The Sogitec process is consistent with the process used as template in
terms of stages. Excluding the runtime databases, the Sogitec process is specifically focused on the level
immediately following the source data level but before the runtime/propriety level, which is the ultimate
common purpose value-added stage before the adaptation of the data to the target applications (publishing).
Sogitec uses its own attributes dictionary and attribute rules (see principle in § 5.5.4.4c).
f
UK SE Initiative
The UK SE response to the questionnaire was received from UK MoD according to the schedule. However,
the content was very limited due to restrictions being applied during an ongoing bidding process, and the low
level of knowledge of their future solution.
No information is available on attribution at this time.
g
NATO “Mission Land” Initiative
The NATO “Mission Land” response to the questionnaire was received from NLR, however a former version
of the Questionnaire was used. Due to Mission Land being developed as a geo-typical world in the middle of
the Atlantic Ocean, the creation process is slightly different, including a specific stage for geo-typical data
creation, and with no attention to correlation with geo-specific data.
Page 15 of 30
No information is available on attribution at this time.
5.5.3.4 Interviews of the Initiatives’ representatives
Interviews of the initiatives’ representatives were conducted as side-meetings during I/ITSEC 2010. Three
interviews (with UK, NATO, and USAF / AFRL) had been planned before the conference; two more were
arranged on site with US Army / SE Core and US Navy / NAVAIR.
All interviews were held similarly with (1) a summary of the RIEDP-SG study principles / survey status, (2)
review and comments on the initiative’s answers to the questionnaire, (3) presentation and comments on the
tentative UML model initiated by Sogitec based on their SINDBAD DBGS, with the intent of generalization.
A summary of all interviews is provided in the appendix.
5.5.3.5 Conclusion of the Survey
As a result of the Survey, it appears that the initiatives use the same core of geospatial source data formats.
They also share the same high level database generation process flow with the same stages.
It is to be noted that the initiatives do not necessarily control all the stages (for instance, some steps are left to
the responsibility of the database provider), which may reduce the capitalization of efforts.
The Survey also shows similarities between initiatives when it comes to the data models, which is something
that was expected given that the Initiative’s database generation processes heavily rely on COTS products
and de-facto or standard formats. However, these data models show some divergences as one goes along the
stages of each process, particularly in the use of feature dictionaries, attribute definitions, and the attribution
rules. This complicates the reuse between initiatives and even impedes it, if the data models cannot be
“interfaced”.
Nevertheless, enough commonness can be found so that the definition of a RDGPM, as a reference against
which the initiatives could be assessed, may be feasible.
5.5.4
Discussion for Significant Result Area 4: RDGPM
A first version of the RDGPM, composed of a RPM and a RADM is described below, along with the
assessment of the Initiatives and the resulting identification of convergence/divergence areas.
5.5.4.1 Reference Process Model
The RPM has been built based on the tentative PM consolidated with the answers to the survey by each
Initiative.
The questionnaire was generated from the data available from the initiatives’ documentation, and particularly
from NPSI. Though the level of detail of the responses has been different depending on each participating
initiative, the tentative PM provided in the questionnaire was agreed to.
The PM is composed of the following main stages:
• Stage 1 - Source Data Collection
• Stage 2 - Source Data Modification/Refinement
Page 16 of 30
•
•
•
•
•
Stage 3 - Source Data Integration/Reconciliation
Stage 4 - Content Creation
Stage 5 – Publishing
Export
Other (requirements, catalog and downloading)
These stages are each composed of various tasks. Some stages and tasks are optional during the instantiation
of the process for a certain application. The red line in the diagram shows the minimum path with the set of
mandatory tasks until publishing.
The Export stage can be reached from the end of each stage, except from Publishing, which is too specific to
the target application and probably not reusable by other target applications.
Using the RPM (reference process model), it is useful to note that the most advanced stage at which each
initiative makes its data available varies, and currently ranges somewhere between the end of the third stage
(in the AFCD case, for example) to the end of the fourth stage (for the SE Core case and the French Air
Force approach), or even further to the publishing stage (for the CDB case).
Taking maximum advantage of the database creation efforts among the initiatives may require an agreement
on an "intermediate level".
Such an "intermediate level" may be identified as being at the end of the fourth stage. This is shown in
Figure 7. The RADM, presented in § 4.2, is defined at this "intermediate level".
Page 17 of 30
Intermediate Level
Figure 7 – Reference Process Model
Page 18 of 30
5.5.4.2 Reference Abstract Data Model
The RADM has been built based on the tentative DM consolidated with the responses to the survey by each
Initiative, and somewhat abstracted where appropriate. This abstraction may be extended for future RADM
versions.
Displayed as a UML diagram in Figure 8, the RADM is composed of the following main elements:
• At the top level, the database is composed of tiles, one Library, and metadata.
o A tile contains instances of object classes (areal, linear and point objects) for an area of the world.
Note: sizes of tiles are not constrained.
o The library contains the object classes (areal, linear and point objects) for the whole database.
o Each of the instances is to be linked to one (or more) object class(es) of the library in order to be
represented in the simulation.
o Additionally, the notion of special areas (Airport, urban areas …) may be separated from the tiles
in order to ensure continuity when it is located at the border of two or more tiles.
o All of the above may be archived in a repository with cataloguing information based on the
database metadata.
• Shared between instances and classes is the notion of layer, presented vertically from the left to the right
of the diagram :
o
o
o
o
The elevation, as a grid with metadata, associated to a tile;
The features, associated to the tile (for instances) or to the library (for the classes);
3D objects (static or moving) associated to the library;
Textures (for 3D objects and features), with metadata, associated to the library;
• The attributions displayed at the bottom of the diagram (in Figure 8), complements the description of the
features (instances and classes). Among the attributions, the “rendering attributes” are linked to the
textures.
o The attributions are detailed in sub-diagrams for each case. As an example, the case linear class is
displayed in the diagram in Figure 9, together with the application for the profile of a linear object
(typically a road).
Page 19 of 30
GRID
-hooked to
Elevation MetaData
1
1
Elevation Data
Elevation
1
Spatial Ref
1
1
1
0..1
1
1
1
1
Tile
Lin Attrib
0..*
0..*
Are Attrib
0..1
Linear Instance
Feature Instances
0..*
{OR}
1..*
1
0..*
0..1
Pt Attrib
-with attributes
Point Instance
1
1 or possibly more
Rendering Attribute
1..*
1
1
Library
1..*
1
0..*
Point Classe
0..1
0..*
Additional Attributes
for rendering
-is Attrib_Render
0..1
1..*
Pt Class
Attrib
Lin Class
Attrib
1
Visual Attrib only
refers to 1 record
0..*
0..*
1..*
0..1
Links between OF
components and
Texture files
*
0..*
Terrain Imagery
Light Map Text.
0..*
0..*
0..*
1
To support Texture
comutation
1
0..*
Effect Text.
{OR}
1
0..*
Generic Terrain Txt
1
Feature Textures
JPEG, ...
Texture MetaData
3D Model Texture
1
Texture Classes
Catalog
1 or more texture
of 1 kind only
Mov Object
0..*
3D Object
Attrib
3D Object
0..*
Metadata
Static Object
-to file
0..*
*
1
0..1
Linear Classe
Feature Classes
1..*
1
0..1
Rendering Attrib
Commonality
between
Areal and Lin
Are Class
Attrib
0..*
0..1
Areal Classe
Link between
Instance and
Library Class
Urban area
Airport
1
DB
Objects separated
from the Tiles
1
*
-is connected to library class
0..*
Special Areas
Feature Instances belong
to Tile OR to Special Areas
1
0..1
Areal Instance
1
1..*
1
-is 3D Obj
0..*
0..1
Repository
0..*
0..*
-is Attrib_Render
0..1
Figure 8 – Reference Abstract Data Model
Page 20 of 30
SINDBAD::Linear Classe
Z
1
1 profile per Linear Object
Except Light string
X
0
0..1
Linear Class Param
Linear Profile
1
0..*
1..*
1 or more sections to allow
different rendering at section Level
Linear Class Attributes
-Defines
1..*
Rendering Attributes for the Profile
Section
profile for
Linear Object
1
Linear Section
3D View
Expansed Linear Object
1
0..*
Description of each Section +
Rendering Attribute for the Section
1..*
0..*
*
Vertex
SINDBAD::Rendering Attrib
-X, Y=0, Z
Figure 9 – Attributions – Case of Linear Classes
5.5.4.3 Convergences and Divergences
The initiatives have been assessed (step 7 and 8) against the RDGPM, and main areas of convergence and
divergence have been identified. They are shown on the figure below, with the following items:
Many areas of Convergence
DB
 GIS Format
Tiles
 Layers, Tiles
Tile (X – Y)
 LOD …
Elevation
DTED, …
Features
Point instances
Shape files
Linear instances
Airport Features
Aerial instances
OF, Shape
Imagery
Rules
TIF, …
?
Other Layers
Indirect to
Library
?
Libraries
Library
Aerial classes
Linear classes
Point classes
Classes
Xml ?
Many areas of Variability
Mapping Table
 Feature-Attribution Relationships –
Attribution Dictionaries
Attributes
?
Direct to Library
Object
indirect
indirect
?
 Naming conventions, Standard
Options, Rules
Textures
JPEG,..
Objects
OF
Static
Moving
Figure 10 – Areas of Convergences & Divergences
• The convergence areas (in purple) :
o Source data formats: All Initiatives use GIS technology and associated formats, which fosters
natural convergence of all initiatives based on source data. However, using the same source data
formats may not be sufficient to allow a full convergence.
Page 21 of 30
• Using raster formats like DTED, GeoTiff, JPEG2K can be enough for having a rather good
convergence. Moreover, conversion tools exist between all these formats.
• Using Shapefiles format with its user-defined attribution schema can lead to divergence. This
aspect fits in with the attribution issue discussed below.
• Additionally, use of GIS formats implies taking into account evolution of the GIS domain.
o Layers: Also derived from the GIS community (consistent with the source data formats) and
applied to simulation, the basic layers (elevation, features, texture, 3D objects) are commonly
shared, with similar formats amongst the initiatives. But what is in the layers, at what detail, at
what resolution may be different to take into account specific purposes and it must be looked at
closely.
o Tiles: Source data are often delivered by producers using regular tiles. Additionally the DB
generation process can often use parallel processing, which also leads to cutting the domain into
regular tiles. Similarly, preparing the data for use during runtime may require the use of tiles.
Despite the use of the general tiling concept, there is a great variety of requirements among the
initiatives, from the “no specific tile size” (AFCD approach) to the CDB fully defined tile schema.
Considering that tiles can be adjusted at any time using the GIS tools capabilities, this is not a main
technical issue. However, these adjustments have a cost and should be minimized.
• The divergence areas (in yellow):
o Internal format: Relying on the use of layers with their relevant source data formats, a desired
“integrated database” is the state of aggregation of the data from the layers, which presents a
significant added value in terms of reusability (because of operator work) while keeping away from
what is specific to the target applications. Setting aside the distortion corrections (e.g. alignment of
elevation data with feature data), which are now often performed by the source data providers,
there is the definition of library of object classes and the linkage of these with the object
instances. Depending on the initiative, the notion of “integrated database” may or may not make
sense. For instance, AFCD’s scope does not cover this notion, leaving it to the responsibility of the
simulation database provider (who receives the AFCD data). At the opposite end, SE Core, CDB,
and French Air Force initiatives have “integrated databases”, but with significant differences in
their internal formats, which reduces the reusability of the database and impacts the correlation of
the database generation results at the target application level.
o Attribution: Environmental data is often/ generally derived from GIS data, with specific
simulation requirements integrated via a set of attributes associated with various features.
Attributes and attribution rules (governing how such features and components may be attributed)
are different among the initiatives.
o Dictionary: Dictionaries contain the terms, labels, and concepts that allow the data providers to
designate and/or describe the features and components of the environment and their attributes.
Iinitiatives do not use the same dictionaries.
Utilization of attribution and dictionary are an important source of discrepancies between initiatives. The
subject is addressed in the section below.
5.5.4.4 Focus on dictionary and attribution issues
a
Introduction
The notions of attribution and dictionary are sometimes confused, as the terms and concepts from a
dictionary are equated to the instances of those concepts in a specific data model. Furthermore, the concepts
(features and attributes) and the attribution rules of the various initiatives often use terms or concepts that are
Page 22 of 30
not covered by the various standard dictionaries, and each initiative defines a specific dictionary for their
purposes.
b
Dictionaries and Mapping
Several standard dictionaries of terms and concepts are widely used currently (or will be used in the future)
by the various initiatives and programs. Among them:
•
•
•
•
The DGIWG Feature and Attribute Coding Catalog (FACC),
The ISO/IEC Environmental Data Coding Specification (EDCS),
The DGIWG Feature Data Dictionary (DFDD),
The NSG (National System for Geospatial Intelligence) Feature Data Dictionary (NFDD).
To allow unambiguous exchange of environmental data between initiatives and the various programs that use
the initiatives’ data, mapping efforts will be necessary. Other projects have undertaken mapping efforts to
provide authoritative mappings between various standard dictionaries. Though it may appear tedious in the
absolute due to the high number of concepts that must be handled, the problem can be considered relatively
simpler, given the common practices in the panel of initiatives involved; and hence the limited number of
items to be considered with regard to those in the dictionaries.
However, this mapping principle may not suffice with regards to attribution rules associated to specific
modeling of the environment, as the complexity from semantics remains. For example, an attribute may:
• Be relevant to different entity types (for instance point, linear or areal features) and/or;
• Be used at different abstraction levels of the data model (for instance Feature Class level or Feature
Instance level) and/or;
• Have different ranges of values and/or;
• Refer to a sub-model, more or less complex, allowing flexibility in the extension of the data model.
To understand the complexity of the mapping problem, the nature of the attributes and attribution rules must
be understood. The principles of CDB and French Air Force initiative respective attribution schemas are
presented below.
c
Principles of the attribution schemas used by CDB and FAF Initiative
Both initiatives use a similar approach to define their attribution rules. Attributes are associated to Geospatial
entities as point, linear or areal features. A set of attributes is associated to each type of feature, with
attribution rules defining:
•
•
•
What types of attribute can be or have to be defined for what features instances or classes,
For each attribute, what type and range of values can be assigned, whether or not any default value is
included, and whether the attribute is optional or not,
For certain attributes, reference to other attribution rules to complement the feature’s description,
implemented as tables (or lists), or via a more complex schema.
Several categories of attributes may be identified:
• The first category concerns attributes corresponding to the real world’s characteristics of the feature,
generally supplied with the source data; for example: Feature Classification Code (FCC), the height of
the feature, the type of roof for a building.
Page 23 of 30
• The second category concerns attributes manually or automatically produced during the generation
process of the database, for the following purposes:
o to overload attributes from the first category to obtain a more detailed modeling of certain
characteristics of the environment; for example, sub-classification of materials of a component,
o to create a link to a more comprehensive description of the feature; for example:
• The name assigned to a point feature allowing reference by its name to a 3D object model
described in an OpenFlight data file,
• The name of a light point type assigned to a point feature allowing reference by its name to a
detailed description (parameters, tables of values) with physical characteristics of the light
source,
o to allocate to the feature additional characteristics, determining further operations either in a
subsequent step of the database generation process or within the target applications during runtime:
• Further operations in the database generation process: can involve the generation of the
surfaces corresponding to the profile of a road applied to a linear road feature, or the planting
of trees (with a given density) within an areal feature or along a linear feature.
• To some extent these kinds of attributes can equate to an entry point to a procedural
operation (algorithms) used for the automatic generation of database content. These
procedural operations sometimes referred to as “procedural generation”, can be realized
either during the publishing step of the process or during runtime. The divergence in the
performance of the procedural operations between the various initiatives may lead to
differences in the representation of the environment, entailing a lower interoperability level
between the applications.
• Further operations by the target application: the computation of the rendering characteristics
of the surfaces. The texture type to be applied by the visual systems is an example of this
type of operation.
• The third category concerns structural attributes allowing managing the underlying data model
associated with attribution rules, and particularly the extension mechanism of the attribute rules.
As an example in this last category, Figure 11 shows an overview of the attribution schema of both initiatives
in a case of linear features. Two levels of attribution are defined:
o Attributes related to feature instances in the database,
o Attributes related to feature classes from the library (for example, for linear features such as road,
highway, street, etc.), which are then inherited by the feature instances.
Page 24 of 30
Figure 11 – Principle of Attribution Schema
For each row of the feature instance records table, a set of attributes are defined in the feature instance level
attributes table, containing values or names. One of the attributes can contain a class name pointing to group
attributes or attribution rules specific to that class (for example runway, taxiway, road 2 lanes, etc.). The
Class Name can act as the key to access the class level attributes or attribution rules description in a library
(shown by link 1).
At the instance level, the feature instance attributes list can be extended to define complementary attributes
or attribution rules, to describe more complex data such as material model or light point model for example
(shown by link 2).
In a similar way, feature class attributes or attribution rules can be also extended to associate more extensive
description to a feature class, such as a type of texture to be used for visual rendering, or the shape of the
profile for a road (shown by link 3).
d
Conclusion on Attribution and Dictionary Issues
The example above describes the principles of attribution rules associated with the RADM. It shows that the
notion of attribution involves the concept of a data model, which is much more complex than a simple list of
attributes with their associated values.
While comparing the data models adopted by each initiative, the attributes and/or the attribution rules appear
as the most significant divergence area. In addition to the convergence of the source data, where a consensus
seems to be established (primary layers and their formats), the harmonization of the environmental databases
and their associated creation processes requires finding a consensus on attributes and attribution rules. Two
tasks are needed for this harmonization:
Page 25 of 30
• The easier one: identification of a common list of features and attributes (concept, range of values,
application domain), using standard dictionaries, to be associated to the environmental objects (classes
and instances);
• The harder one: identification and definition of common attribution rules.
The second task is harder than the first, but both of these are probably the most important work packages that
could be addressed within a Product Development Group (PDG).
5.5.5
Discussion for Significant Result Area 5: SOLUTION AREAS
5.5.5.1 Standard solution areas
With the Reference Process Model being satisfactorily shared by all initiatives, the notion of a standard
solution area will include improvements to the RADM so as to increase its common factors with each
initiative’s Process Model.
Note: The idea is not to define a solution that all initiatives must comply with, but rather to define a reference
implementation and/or model against which each initiative can position itself, contributing to make lossless
conversions possible between all initiatives via this reference.
The mapping of the “Areas of convergence and divergence” (from Figure 10) onto the RADM (as presented
in Figure 8) is displayed in Figure 12 below, with the following results:
• The upper part of the RADM (highlighted in solid purple) means that all initiatives may share (even
though the RADM may not cover all cases) a similar view of the high level concepts of a database:
o The database is composed of geo-referenced tiles containing a set of layers: elevation, features,
object, texture …
o Feature instances of the real world are attached to tiles, and their rendering characteristics (visual,
behavior …), and are provided by the objects (and their attributes) from the library to which they
are linked.
• The middle part of the RADM (highlighted in dashed purple) may also be shared by all initiatives, as it
is supported by their use of common GIS and other formats as for instance:
o
o
o
o
DTED, GeoTIFF, … for elevation;
Shapefiles for features;
OpenFlight for 3D objects;
JPEG2K, GeoTIFF … for textures.
• The lower part of the RADM (highlighted in yellow) corresponds to the attribution aspect which is
often user-defined and not constrained by the formats. As a consequence, this is an area of divergence
between initiatives.
• Miscellaneous: other possible areas of divergence have been identified (yellow areas):
o The Special areas, including for example airports and urban areas, that may be described either as
features not related to tiles, or as OpenFlight or other format objects;
o The linkage between the objects of the Library and the Features;
Page 26 of 30
GRID
-hooked to
Shape
Files
1
1
Tile
{OR}
Lin Attrib
0..*
0..*
Are Attrib
0..1
Linear Instance
0..1
1..*
1
0..*
0..1
Pt Attrib
-with attributes
Point Instance
1
1
1 or possibly more
Rendering Attribute
1..*
1
1
Library
1..*
0..*
Point Classe
0..1
0..*
Additional Attributes
for rendering
1..*
Pt Class
Attrib
Lin Class
Attrib
1
Visual Attrib only
refers to 1 record
0..*
0..*
1..*
0..1
Links between OF
components and
Texture files
*
0..*
Terrain Imagery
Light Map Text.
0..*
0..*
Catalog
1 or more texture
of 1 kind only
Mov Object
0..*
3D Object
Attrib
3D Object
0..*
Metadata
Static Object
OF
-to file
0..*
*
1
0..1
Linear Classe
Feature Classes
1..*
1
Rendering Attrib
Commonality
between
Areal and Lin
Are Class
Attrib
0..*
0..1
Areal Classe
Link between
Instance and
Library Class
Urban area
Airport
Objects separated
from the Tiles
1
-is connected to library class
0..*
Special Areas
Feature Instances belong
to Tile OR to Special Areas
1
Feature Instances
0..*
Feature
Layer
Areal Instance
1
1..*
DB
0..1
Variability
1
0..1
1
1
-is Attrib_Render
Common Format
1
1
*
0..1
Convergence
DTED
Elevation MetaData
1
1
Elevation Data
Elevation
1
Elevation
Layer
Spatial Ref
1
Object
Layer
1
-is 3D Obj
0..*
0..1
Repository
0..*
Texture
Layer
1
To support Texture
comutation
1
0..*
Effect Text.
{OR}
1
0..*
Generic Terrain Txt
1
Feature Textures
JPEG, ...
Texture MetaData
3D Model Texture
1
Texture Classes
0..*
0..*
o Metadata associated to the database, which eventually feeds the catalog associated to the
repository.
-is Attrib_Render
0..1
Figure 12 – Standardization Areas
Page 27 of 30
5.5.5.2 Work areas and Products
Based on these results, standardization efforts are needed in the following areas: data model, formats,
attribution and “miscellaneous” (including metadata).
This will be divided along two work areas, leading to two products:
• The Environmental Data Model Foundations product with:
o The upper part of the RADM with the principles of the database including the notions of Tiles,
Layers, Library, ...
o The middle part of the RADM with a set of common layers and associated data formats, for
example, but not limited to:
1.
Elevation;
2.
Features;
3.
3D models;
4.
Texture / Imagery.
o An (optional) tiling scheme to facilitate reuse.
• The Environmental Detailed Features description product with the definition and implementation
of the lower part of the RADM, taking into account:
o Objects: Identification of object instances and classes (such as features, 3D objects, textures) within
the Library, and the linkage 3 between instances and classes;
o Dictionary: choice of semantics and mapping with existing dictionaries;
o Attribution: two tasks are needed in this area:
1.
Identification of a common list of features and attributes (concept, range of values,
application domain), based on the dictionary, to be associated to the environmental objects
(classes and instances);
2.
Identification and definition of common attribution rules.
Some of the miscellaneous issues will be looked at as needed in the above tasks (Links for instance). For
metadata, the work performed by NPSI 4 and shared by NPSI will be referred to.
Note: This needs to remain open to technological evolution in the next 5 years.
5.5.5.3 Time & Effort Required
The two products will be developed simultaneously according to the following schedule.
Depending on the rate of progress in the development of the products and their interdependencies, the first
product may be balloted first.
The following schedule also takes into account the elaboration of the compliance testing process.
3
4
Other layers (elevation, imagery) being correlated by georeferencing via GIS tools
NPSI Schema 2.3: NPSI Standard for Reusable Source Dataset Metadata
Page 28 of 30
Milestone Date(s)
Activity(s) Description
Q1 & Q2 year 1
Q3 & Q4 year 1
Q1 & Q2 year 2
Q3 & Q4 year 2
Q1 & Q2 year 3
Draft of the standard products by a core team
Comment/resolution cycle 1
Draft/comment/resolution cycle 2
Draft/comment/resolution cycle 3
Balloting & finalization
A participating organization may need to allocate one and a third man x year of effort.
5.5.5.4 Recommendation for future extensions
The approach has been deliberately focused on Aircrew Training and Mission Rehearsal to foster
convergence in that community and create a reference point to help aggregate other communities in the
future.
Given the LVC requirements, we will need to take into account:
• Other requirements: ground maneuver related, urban areas, buildings;
• Advancing Technology: new formats (e.g., CityGML), …
Yet, the selected approach is extremely flexible because of the following characteristics:
• Extensibility of layers and formats;
• Translation of attributions and mapping of dictionaries;
• Extensibility of attributions and dictionaries.
The standard products will be extended by involving the interested customers in the Product Support Group
(PSG) that will be set up by the end of the PDG to maintain these standard products.
5.6
SUMMARY OF TECHNICAL FINDINGS
No.
1.
2.
3.
4.
5.
Finding Description
Survey shows that main DBGS initiative worldwide use the same core of geospatial source
data formats, and same high level DBG process flow. This can be modeled by a Reference
Database Generation Process Model (RDGPM).
A RDGPM, composed of a Reference Process Model and a Reference Abstract Data Model
(RADM) has been drafted during the RIEDP SG.
The initiatives have been assessed against this RDGPM: areas of convergence and
divergence have been identified. Utilization of attribution and dictionary are an important
source of discrepancies between them.
Based on these results, standardization efforts are needed in the two work areas, leading to
two products : The Environmental Data Model Foundations and the Environmental Detailed
Features Description
The Environmental Data Model Foundations product is composed of two (tightly coupled)
parts, the Reference Process Model (RPM) and the Reference Abstract Data Model (RADM).
These form the foundations for existing and/or emerging database generation projects to
compare, contrast, and map their data generation process and data model capabilities to these
models. In this regard, use of the Environmental Data Model Foundations will serve as a
Page 29 of 30
No.
6.
5.7
Finding Description
guide in establishing database generation process models and their corresponding data
models within the community, and will improve the reuse and interoperability of data
products. In addition, the Environmental Data Model Foundations may aid in the
development of the Environmental Detailed Features Description product.
The Environmental Detailed Features Description product will provide the required
information for identifying instances and/or classes of environmental features and objects
that, along with their specific attributes, value ranges, and metadata, will be utilized in
environmental data products. The use of the Environmental Detailed Features Description as
a standard product will ensure data interoperability through the identification of features,
their definitions (through the use of standardized dictionaries), their corresponding attributes,
and any associated metadata.
RECOMMENDATIONS FOR FUTURE SISO ACTIONS - THE WAY AHEAD
This Final Report is the formal product produced by the SG. It summarizes the work achieved by the core
team during the SG performance period, from April 2010 to September 2012.
No.
1.
2.
Recommendation
Draft a Product Nomination and submit to SAC for approval.
Recommended Products (two) for PDG Product Nomination includes:
• The Environmental Data Model Foundations product, which will be a SISO Guidance
document, and will include the formalization of a Reference Process Model (RPM) and
a Reference Abstract Data Model (RADM), both of which were addressed by the RIEDP
SG;
• The Environmental Detailed Features Description product, which will be a SISO
Standard product, and will improve reuse and interoperability between participating
initiatives identified within the RIEDP SG.
Page 30 of 30
APPENDIX A
A.1
SUPPLEMENTAL / SUPPORTING RESULTS – SURVEY CONDUCTED
SURVEY TEMPLATE APPLIED
Name of Initiative:
Point of Contact:
Environmental Data
Name :
Organization :
Please provide description of environmental
data used in your process.
Elevation,
Planimetry (Features, Vector,...),
Imagery,
3D Models,
Light Points
Material,
Pictures (textures)
Light Maps
Shadow Maps
Urban Areas,
Building interiors,
Networks (road, hydrographic, rail,
power line,...)
Airports,
Navigation data
Atmospheric elements
Coastlines,
Oceanographic data (tide, bathymetry)
Other
Source Data
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
?
Comments and description
?
Please provide List of the various stages of
your process.
Source Data Collection
Source Data Modification/refinement
Source Integration/Reconciliation
Content Generation
Publishing
Export
Other
Operations (and their
localization in the
process)
Among the Environmental Data you have
identified above, what are those that you
consider as Source data (provided by an
external entity: NGA,…) ?
Among the Environmental Data you
have identified above, what are those
that you consider as Source data
(provided by an external entity: NGA,
….) ?
Stages in the process
Email :
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
-
Please provide description of the operations
in each stage of your process.
Management (Identifying, Obtaining,
Cataloging)
Import
Yes or No
Yes or No
Page 31 of 30
Conversion
Preferred representation for elevation in
the process
Preferred representation for vector in the
process
Preferred representation for imagery in
the process
Yes or No
Projection change
Yes or No
Preferred reference frame and datum for
source data in the process
Tiling
Other
Yes or No
Source Data
Modification/Refinement
Changes to Elevation data
Merge & Feathering
Elevation data editing and correction
Smoothening of sampling noise found
within DTED grid posts
Adding peaks, pits, ridgelines, and
valleys that fall outside of the DTED
precisions and grid structure
Other
Changes to Vector data
Reclassification
Other
Changes to Imagery data
Orthorectification
Image-rectification
Geopositioning
Contrast and Color Balancing
Colorization
Image merge
Mosaicing
Feathering
Other
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Changes to Vector data
Aligning Features with Imagery
Features and Elevation alignment
Aligning Features with other Features
Changes to Elevation data
Flattening the terrain for lakes and
airfields
Correlating terrain to rivers
Incorporating cut and fill for roads
Other
Changes to Imagery data
Examples?
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Content Generation
Data creation specific for Geotypical
database development
Elevation
Yes or No
Yes or No
Page 32 of 30
Vector
Creation and Mapping of texture
3D Models Creation or Modification
Geometry
Creation and Mapping of texture
Attribution
LOD generation
Light Features modeling
Models to Features Assignment
Features expansion
Contour smoothing
Object instantiation (vegetation, manmade features)
Networks generation
Build-up areas
Airports
Light systems
Extrusion operations (tunnels,..)
Procedural generation
Operations on material
Material classification
Material Encoding
Other Attribution (physical
characteristics, illumination model,
trafficability, etc)
Other
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
what for?
Yes or No
Yes or No
Yes or No
Yes or No
Publishing
Structuring (Layers, Tiles, LODs, ...)
LODs generation (terrain and
textures)
Polygonization and Terrain
generation (TIN, regular grid,
constrained terrain mesh, coastline
pinning, etc)
Run Time Data Base Generation
Other
Yes or No
Yes or No
Exports
See below
Yes or No
Yes or No
Other
Target applications
Please provide description of the target
applications fed by your process.
SAF/CGF
Visual (OTW)
Sensor (IR, NVG, E/O, etc.)
Radar
Mission support (terrain following, line
of sight, height above terrain, collision
detection, etc.)
Plan view display
Maps
Other
Imports/exports (and
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Yes or No
Please provide description of the import and
Page 33 of 30
their localizations in the
process)
export functions provided by your process.
Source data formats (DTED, Geotiff,
JPEG 2000, …)
OneSAF OTF
CTDB
OTB
JCATS Terrain
AFCD
NPSI
SE Core MDB/CER
CDB
French DB
SEDRIS STF
CADRG
UHRB
Openflight
Terrapage
VBS2
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Import, export,
both, neither
Other
Data Representation
Please provide description of the Data
representation underlying your process in
this area :
Environmental Representation
Model (for which data?)
Do you use a standard data model (such
as SEDRIS DRM), or specialized data
model (please specify/describe)
Spatial reference frame
What reference frame (sometimes called
coordinate systems) do you use (e.g.
UTM, Augmented UTM, geodetic,
geocentric, …)
What reference datums or models doo
you use (e.g. WGS 84, ED50, NAD27,
…_)
Data Organization
Tiling schemes and objectives:
Page 34 of 30
incremental production
imagery mosaicing
paging
overlap/clipping
Layers
LOD
Case of 3D Models
Case of Airports
Case of lights
Organization for the different targets
Organization for multiple
representations (for different domains,
applications, etc.)
Nature of the links for:
Assignment of Models to Features
Assignment of Texture to models and
features
Case of other attributes
Topological links
Traceability links (for e.g. mean to track
the origin of data in case of multiple
representation of an object)
Other relational links
Other
Software architecture and tools
Libraries
Files structure
Data Base Management System
Naming conventions
Other
Data Formats
What are the
internal data
formats used for
each of the
following types
of data?
Elevation (DTED (levels),…)
Planimetry (DFAD, Shapefile, KML,…)
Imagery (Tiff, GeoTiff, JPEG2K,..)
Pictures (RGB, JPEG, GIF, …)
3D Models (OpenFlight, VBS2, VRML,
X3D, Collada, 3dsMax,…)
Cities (CityGML, UVMAP, UFD)
Buildings (UHRB, BIM, …)
Point Clouds (LIDAR, …)
Material (MatML;..)
Attribution
Other
Metadata
Nature
Reference dictionaries (for which
uses)
DIGEST FACC
EDCS
Yes or No
Yes or No
Page 35 of 30
DIS
Other
Glossary
Please provide your definition of the specific
terms used to describe your process.
List of documentation
Please provide a list of documentation
available describing the process and data
used in your process.
Data about the End User
Please provide data about the M&S program
using your process:
Name of Program
Yes or No
End User
Type of Simulation /
Type of Entity
Further Information
Page 36 of 30
A.2
GUIDELINE FOR SURVEY
Guidelines to support an Informal Survey on on-going Initiatives
A.2.1 Object
This document is a Guideline to support the RIEDP-SG Informal Survey on on-going Initiatives related to
Environmental Data and Processes in Simulation. The Survey is specifically targeting the following
Initiatives: NPSI, AFCD, CDB, MDB, and French approach processes. A template at the end of this
document is expected to be filled by an authoritative representative of each Initiative.
A.2.2 Background
A.2.2.1 General Scope
Production and reuse of environmental data continues to be a significant part of the overall M&S
development and deployment cost. Environmental data includes terrain, ocean, Weather/atmosphere, space,
urban, and all related data required for simulation and modeling of entities and sensors. Capitalizing on costsaving approaches that reduce this overall cost is an important topic of interest to the broader M&S
community.
Various degrees of Standardization that address different aspects of the end-to-end problem exist, and range
from international standards to ad hoc approaches. On-going projects in a number of international
government programs, as well as initiatives and innovative approaches from industry, continue to contribute
to solutions in this area. However, the activities in the community are often fragmented or disjoint, and
sometimes do not or cannot leverage existing capabilities, standards, or lessons-learned. In some cases, these
are driven by special requirements for specific projects or activities. This results in multiple solutions in the
community, differing in their scope, breadth, or depth.
The exceptionally large number of attendees at the 2009 Fall SIW Special Workshop on "Reuse of
Environmental Data" provided an opportunity for the international community involved with the creation,
dissemination, and development of environmental representations and effects databases to discuss existing or
emerging approaches, processes, standards, and lessons learned. The presentations indicated that all
practitioners use the same general approach in the generation of their environmental data products. Source
Data, regardless of detail or complexity, is used in internal data generation processes to produce one or more
final products (usually) specific to a particular set of applications, clients, or systems. However, the data
generation processes differ from one producer or integrator to another.
This implies a desire for harmonization of environmental data representations and processes at the
"integrated" level, while trying to retain the data form (or format) close to the source data, and at the same
time keeping the internal data consistency (intrinsic correlation factor). Added to this, is the desire for
shielding the generalization at this level from specific target application constraints, leaving those to be
addressed separately by each target application during run time which may be a contradiction for
interoperability.
A.2.2.2 RIEDP-SG Scope
The Reuse and Interoperation of Environmental Data and Processes Study Group (RIEDP-SG) was launched
during Spring 2010 SISO Interoperability Workshop. It proposes a 12 to 18 month effort to investigate the
Page 37 of 30
level of interest and best approaches for the development and utilization of standardize-able representations
of environmental data and associated creation processes for use in simulation applications.
Within that broader context, the Study Group will focus on environmental data that can be immediately used
in Aircrew Training and Mission Rehearsal applications. Specifically, the focus of this effort will take into
account the NPSI, AFCD, CDB, MDB, and French approach processes and data models with the expectation
to improve their interoperability and reuse in a standardized approach.
As part of its outcome, the SG will recommend how to expand this focus to cover additional requirements.
Interim reports will be developed and presented at the Fall 2010, and, if needed, at the Spring 2011 SIWs. It
is anticipated that the final report, targeted for either the Spring or Fall 2011 SIW, will recommend the
formation of a Product Development Group to produce specific SISO products and/or to establish a Standing
Study Group to continue and evolve the initiatives started by this Study Group.
A.2.2.3 RIEDP-SG Tasks
The RIEDP-SG will execute the following tasks:
1. Conduct an informal survey on on-going Initiatives
2. Define and document a Reference Database Generation Process:
a. Establish a common terminology
b. Identify common areas in data generation processes between communities
c. Identify requirements for one or more standard solutions
3. 3.Synthesis
a. Assess the time and effort required for PDG activities
b. Produce Interim and Final Reports
A.2.2.4 RIEDP-SG Reflector
Information on the RIEDP-SG is available on the SG Reflector at
www.sisostds.org/discussion
A.2.2.5 Status of the RIEDP-SG
A second meeting was held during ITEC 2010 in London (see Meeting Minutes), with the Kick Off of the
Tasks 1 and 2a.
It was decided to gather from representatives of identified initiatives (see below) detailed information about
their generation processes in order to establish the reference database generation process and to initialize a
common terminology.
Initiative
NPSI
AFCD
MDB-SE/CORE
CDB
French Initiative
Organization
US Navy
USAF
US Army
USSOCOM/PRESAGIS
AAF/ Sogitec & TTS
POC
Kerey Howard, Bruce Riner
Steve Stephens
Connie Perry
Joe Preston/Nick Giannis
Christophe Rind
Page 38 of 30
Mission Land
UK Initiative
NATO/NLR
UK MOD
Arjan Lemmers
Grant Bailey
To facilitate this information collection, it was also decided to provide the representatives with a Guideline
for developing and focusing their answer.
A.2.3 Guidelines
A.2.3.1 Introduction
These guidelines are meant to support the informal survey on identified on-going initiatives. The informal
survey is, in a first step, limited to gathering information in order to:
•
initiate an identification and a description of the differences in the exchange formats and DB generation
processes, at a rather high level;
Initiate a common terminology.
•
Available documentation associated to the different initiatives provides heterogeneous levels of detail.
Through this survey the goal is to align the information on the different initiatives.
Therefore, the guidelines for this preliminary step provide a flexible framework to allow contributors to
elaborate their answer based on data from their documentation, papers, etc… in order to provide a rapid feed
back to the survey.
From this first alignment step, a second step of the survey will go into more detail in order to complete as
needed the alignment of the collected information on each initiative. The result will be a table summarizing
the differences and commonalities of the different initiatives.
A.2.3.2 Expected information
The information expected in response to the first step of the Survey is the following:
•
•
Nature and characterization of environmental data supported by the DB generation process:
Elevation, Planimetry, 3D Models, etc. (see below a more exhaustive list as example).
Detailed description of the Database Generation Process underlying the Initiative:
o Various stages of the process, from Raw Source Data to Target Applications;
o Various “Source” data used;
o Various “Operations” performed on the data at the various stages;
o Various Target applications at the output of the process;
o Data Representations, with representation models, spatial reference frame, data organization,
data formats, dictionaries, … datasets, used at the various stages;
o Possible import/export functions and the formats used, with their localization in the process.
o A glossary/dictionary of the terminology used.
o List of documentation available describing the process and data used.
o Data about the M&S projects using the DB generation process
A template for the answer is shown in Annex A. The Guidelines to fill the form is presented hereafter.
Page 39 of 30
A.2.3.3 More exhaustive list of items expected in the descriptions
a
Environmental Data
For example:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
b
Elevation,
Planimetry (Features, Vector,...),
Imagery,
3D Models,
Material,
Pictures (textures)
Light Points
Light Maps
Shadow Maps
Urban Areas,
Building interiors,
Networks (road, hydrographic, rail, power line,...)
Airports,
Navigation data
Atmospheric elements
Coastlines,
Oceanographic data (tide, bathymetry)
Other?
Stages in the process
For example:
•
•
•
•
•
•
•
•
c
Source Data Modification/refinement
Content Creation
Structuring
Publishing
Export
Other
Source Data
Among the Environmental Data you have identified above, what are those that you consider as Source data
(provided by an external entity: NGA, ….) ?
d
Operations (and their localization in the process)
For example:
•
On Source Data
Page 40 of 30
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
e
o Management (Identifying, Obtaining, Cataloging)
o Import
o Conversion
o Projection change
o Georeferencing
o Correction (elevation anomalies, spatial conflicts, connectivity lacks , etc )
o Simplification
o Image fusion
o Imagery harmonization (orthorectification, mosaicing, color balancing, etc)
Imagery placement
Features placement
Material classification
Attribution (color, texture, material, features, illumination model, traficability, etc)
3D Model editing (creation of 3D representations for culture features: buildings, trees, vehicles, etc.)
Creation of textures
Mapping of texture patterns/imagery to the geometrical representation,
Generation of the model LOD, and the generation of appropriate attribution data
Feature expansion (vegetation, fields, networks, build-up areas, airports, light systems, extrusion
operations
Smooth contours
Object instantiation
Procedural generation
Data structuration
o Tiling
o LOD (Terrain, 3D models, texture, etc.)
o Other
Application tailoring
Polygonization (TIN, regular grid, constrained terrain mesh, coastline pinning, etc)
Publishing
Exports
Other
Target applications
For example:
•
•
•
•
•
•
•
•
f
SAF/CGF
Visual (OTW)
Sensor (IR, NVG, E/O, etc.)
Radar
Mission support (terrain following, line of sight, height above terrain, collision detection, etc.)
Plan view display
Maps
other
Data representation
a. Environmental Representation Model (for which data?)
For example:
Page 41 of 30
•
•
•
SEDRIS DRM
Specific
Other
b.
For example:
•
•
c.
WGS 84
Other
Data Organization (and their localizations in the process)
For example:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Tiling schemes and objectives:
incremental production
imagery mosaicing
paging
overlap/clipping
Layers
LOD
Terrain (geometry, imagery)
3D Models
Multiple representations (for different domains, applications, etc.)
Links :
Topological links,
Traceability links (for e.g. mean to track the origin of data in case of multiple representation of an
object)
other relational links
Other
Dataset is often used in the Environmental Data Documentation. How do understand and use this notion?
d.
Data Formats (and their localizations in the process)
For example:
•
•
•
•
•
•
•
•
•
•
Elevation: DTED (levels),…
Planimetry : DFAD, Shapefile, KML,…
Imagery: Tiff, GeoTiff, JPEG2K,..
Pictures: RGB, JPEG, GIF, …
3D Models: OpenFlight, VBS2, VRML, X3D, Collada, 3dsMax,…
Cities: CityGML, UVMAP, UFD
Buildings: UHRB, BIM, …
Point Clouds (LIDAR, …)
Material: MatML;..
Attribution
Page 42 of 30
•
•
Metadata
Other
e.
Reference dictionaries (for which uses)
For example:
•
•
•
•
g
DIGEST FACC
EDCS
DIS
Other
Imports/exports (and their localizations in the process)
For example:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
h
Source data formats (DTED, Geotiff, JPEG 2000, …)
OneSAF OTF
CTDB
OTB
JCATS Terrain
AFCD
NPSI
SE Core MDB/CER
CDB
French DB
SEDRIS STF
CADRG
UHRB
Openflight
Terrapage
VBS2
Other
Glossary
Definition of the specific terms used to describe the process.
i
List of documentation
List of the documentation related to the process.
j
Data about Customer
List and characterization of the M&S Program using the process in terms of :
•
•
•
End User : Army, Navy, Air Force, SO, Other
Type of Simulation : Live, Virtual, Constructive,
Type of Entity : Naval, Fast Mover Air, Slow Mover Air, Ground, Urban, Other
Page 43 of 30
A.2.4 Annex A – Template
Name of Initiative:
Point of Contact:
Name :
Email :
Organization :
A.2.4.1 Environmental Data
Please provide description of environmental data used in your process.
A.2.4.2 Stages in the process
Please provide description of the various stages of your process.
A.2.4.3 Source Data
Among the Environmental Data you have identified above, what are those that you consider as Source data
(provided by an external entity: NGA,…) ?
A.2.4.4 Operations (and their localization in the process)
Please provide description of the operations in each stage of your process.
A.2.4.5 Target applications
Please provide description of the target applications fed by your process.
A.2.4.6 Data representation
Please provide description of the Data representation underlying your process in these areas:
a
Environmental Representation Model (for which data?)
b
Page 44 of 30
c
Data Organization (and their localizations in the process)
d
Data Formats (and their localizations in the process
e
Reference dictionaries (for which uses)
A.2.4.7 Imports/exports (and their localizations in the process)
Please provide description of the import and export functions provided by your process.
A.2.4.8 Glossary
Please provide your definition of the specific terms used to describe your process.
Please give also your definition for the following terms:
•
Dataset
•
Pinning
A.2.4.9 List of documentation
Please provide a list of documentation available describing the process and data used in your process.
A.2.4.10 Data about the Customer
Please provide data about the M&S project using your process:
Name of Program
End User
Type of Simulation
Type of Entity
Page 45 of 30
A.3
SUMMARY OF ALL INTERVIEWS
A.3.1 UK MoD
This interview was held on Monday 10:30 to 12:00 AM in a meeting room of the International pavilion, with
Grant Bailey as representative of the UK MoD.
Grant explained that he is interested in the RIEDP-SG because the UK MoD is considering the outsourcing
of database production as part of the Defence Training & Simulation Services (DTS2), and interoperability
with NATO and Allied forces is very important.
Grant explained that the UK’s answer to the questionnaire is intentionally vague because of the ongoing
bidding process and that the UK is looking for a solution to their requirements from industry. However, he
gave some information on the content of the expected capability (very similar to SE Core).
Grant understands the approach of RIEDP, as well as the UML model initiated by Sogitec, but he does not
want to make detailed comments because of the reasons explained above.
A.3.2 NATO / Mission Land
Arjan Lemmers from the Netherlands National Aerospace Laboratory (NLR) as project manager for the
NATO Mission Land. This project is interested in the RIEDP-SG for any contributions from the Study
Group to help making choices in the formats for the Mission Land DB.
The NATO Mission land project aims at providing, free for use to the NATO community, a terrain database
representing a fictitious continent in the middle of the Atlantic Ocean. This will include a diverse geotypical environment, from cold areas to deserts, urban and port areas, an island, as well as others. The work
is being done in co-operation with several countries.
It is based on a low fidelity (30m) elevation layer (made by Norway and available), with High Fidelity (15
m) areas (made by several nations and available) and Very High Fidelity inserts (to be done). The vector
layer is being done at the Low Fidelity level, but the work is complicated by some issues (e.g. rivers not
flowing downhill). Should it be based on actual geo-specific data? It seems that Sweden, in charge of the
island part of the DB, has used the data from geo-specific Swedish island. For Imagery, the project is facing
the issues of repetition and blending of textures, as well as the intellectual property rights on these textures.
The formats to be used are not yet selected. Possible formats are Digital Terrain Elevation Data at Level 2
density (DTED 2) and Shapefile or IHO S57 for point, line and area features. Terminology for specifying and
identifying features and attributes in the database will be drawn from the Defence Geospatial Working Group
(DGIWG) Feature and attribute Coding Catalogue (FACC) or the DGIWG Feature Data Dictionary (DFDD)
or the JTC1 SC24 ISO/IEC 18024 Environmental Data Coding Specification (EDCS) for the reference
dictionary.
A.3.3 USAF/AFRL
Steve Stephens (USAF / AFRL) and Mike Sieverding (L-3 Comm/Link Support to AFRL.).
Page 46 of 30
AFRL representatives have expressed interest in the RIEDP-SG since the beginning and provided the cochair of the group. Given the various exchanges between Sogitec and AFRL during the last months and the
high quality and level of detail in their responses to the Questionnaire, the content of the meeting was
focused on commenting on the UML model initiated by Sogitec.
The AFRL representatives are interested in the idea of enhancing the level of reusability by pushing
standardization towards the goals described by the RIEDP-SG, but insist on the requirement that it must not
compromise innovation and competition between various industry solutions for database generation systems
(DBGS).
The AFRL representatives agree with the notions as presented in the UML model:
•
•
•
Layers (elevation, feature, imagery, 3D) and associated formats. It is agreed that the list of formats
cannot be permanent in order to benefit from possible new technologies.
The notion of Library of common object Classes (not to be confused with the Repository of datasets) to
be linked to the Feature Instances
The attributions, with the links to the rendering attributes described in extension files
Comments are made on the following elements:
•
•
Tiles: AFCD does not impose a fixed size for tiles. It is agreed that this is an element of difference
between initiatives, not a technical issue, but possibly impacting time/cost to consume.
Airport: a SINDBAD Airport is a collection of feature instances independent from the tiles. This is a
main difference when compared to the CDB, in which an airport may be split into different tiles if
located at the border. The AFRL representative notes that for the RDM, the Airport object should be
generalized to take into account other areas such as urban areas.
A.3.4 US Army / SE Core
This interview was held on Wednesday from 18:00 to 18:45 AM at a PEO STRI Booth, with Rob Cox from
US Army / SE Core.
Rob explained that SE Core’s answer to the questionnaire was intentionally vague, because the program is
currently in a bidding process.
Rob indicated that he plans to clarify the content of the program and that he will make a detailed presentation
at ITEC 2011 (“Environmental representation and standards” session). He gave some insights into current
SE Core’s capabilities:
•
•
Production of the databases for the virtual simulations of the US Army, including the various target
runtime formats.
The MDB uses some SEDRIS-based ISO/IEC standards: the Spatial Reference Model (SRM), the
Environment Data Coding Specification (EDCS), and partially the Data Representation Model (DRM),
supporting production of the SEDRIS Transmittal Format (STF).
He considers the production of the target applications runtime formats a heavy burden for the SE Core
program to keep up with the evolutions of all the target applications’ formats. Drawing a line in the database
generation process, based on common approaches could be a good solution for SE Core evolution. The goals
described by the RIEDP-SG approach could correspond to the point in the process where the SE Core line
may be drawn. Using Shapefiles as one of the formats in the MDB could also be considered.
Page 47 of 30
A.3.5 US Navy (NAVAIR)
This interview was held on Thursday from14:00 to 15:00 AM in the SOCOM room, with Kerey Howard and
Bruce Riner (NPSI), and Mike Sieverding (L-3 Comm/Link support to AFRL.) who helped with organization
of the meeting. Although Kerey had participated in the Phoenix (IMAGE) meeting, NPSI had not yet
answered the Questionnaire and there seemed to be a misunderstanding somewhere. This meeting clarified
that situation.
A misunderstanding occurred from use of the term “Database” which Sogitec used to designate the correlated
sets of data at the level immediately following the source data level (but not the runtime). When this use of
database was understood by NPSI it clarified the RIEDP-SG is also not interested in generating a common
run time database. Then the main elements of the UML model provided by Sogitec were discussed, in
relationship with the NPSI documentation on Metadata. As this document can also be seen as an XML
model of the database, it should be possible to map it to the UML model and to identify areas of convergence
and divergence. Given the commonality between AFCD and the NPSI Metadata Document, the level of
convergence should be good.
A.3.6 Complementary information on SE Core
(Provided by Rob Cox)
The SE Core Master Database (MDB) is the central repository for the creation of correlated databases used to
train, mission plan, or mission rehearsal in the Live, Virtual, or Constructive (LVC) domains. Within the
DVED the database architecture is coupled with a suite of COTS tools that enable database development.
The SE Core effort will also develop common virtual vehicle models, common virtual sensor simulation
software, and the virtual simulation component of the dynamic environment. The dynamic environment will
include approximate visual effects from simulation (e.g., munitions, mobility, engineering, rubbled buildings,
etc.).
The SE Core process is flexible, data-driven, and extensible. The Standard/Rapid Database Generation
Capability (STDGC) is designed to standardize, align, and clean source data in the Master Terrain Database
Generation Toolkit (MTDGT), which also is used to generate synthetic environment data using the Runtime
Database Generation Toolset (RDGT). Data is exported in various formats from a standard application
programmer interface (API)3. Furthermore, the SE Core process addresses other challenges such as
miscorrelation between simulations and lower database generation costs.
When a database request has been submitted and it has been approved, the process of gathering source data
begins. There are five (5) questions that must be answered as the database request is fulfilled. Those
questions are:
1.
2.
3.
4.
What are the technical requirements (database and system)?
What are the resources required for acquisition?
What are the storage/space requirements for the data?
What coordination of acceptance of the source data must be done and how do we deliver the resultant
data?
5. Are there any conversions that are expected?
Page 48 of 30
The SE Core has also developed an extensive document that outlines the source data investigated for use.
The reference document lists over 160 different types of data that are currently investigated for use in
building an SE Core database.
All data is spatially partitioned based on MIL-PRF-89041A. The imagery is stored based on the US NGA
CIB format. For consistency, the vectors are also partitioned based on the CIB schema with one important
difference; they are not chopped to the tiles, but references the groups of features to the CIB tiles they
intersect. All data is stored in latitude/longitude using the WGS-84 reference datum. If source data uses a
different coordinate system or reference datum, the SEDRIS developed ISO/IEC 18026 – Spatial Reference
Model is used for coordinate conversion or datum transformation.
The SE Core data model is based on the SEDRIS ISO/IEC 18023-1 Data Representation Model (DRM) and
all data concepts are defined by the SEDRIS ISO/IEC 18025 Environmental Data Coding Specification
(EDCS). There are also several tools that are used to certify the data is ready for use. These tools check for
invalid and null geometry and attribution. Plus, the tools check for compliance to the SE Core standards for
geometry, spatial referencing, definition, labeling, etc. It should be noted that the SEDRIS ISO/IEC
standards are also NATO STANAGS.
Note from the RIEDP SG:
"In May 2012, the NATO M&S Group (NMSG) noted a sufficient number of positive answers to the SEDRIS
STANAGs Ratification Request Letter sent to Nations. I.a.w. NATO standardization related regulations,
NMSG agreed in June 2012 via Silence Procedure to recommend to the NATO Standardization Agency
(NSA) their promulgation. The promulgation has been formally requested by the NMSG chair to the NSA in
July 2012. The SEDRIS STANAGs were officially promulgated by NSA on 17 October 2012.
Definitions (from NSA):
•
Ratification is “In NATO Standardization, the process by which a NATO member nation determines its
position regarding the implementation of a NATO standardization agreement” (AAP-42).
•
Promulgation is “In NATO Standardization a formal act by which the Director of the NATO
Standardization Agency publishes a NATO standardization document, following a recommendation by
the tasking authority or delegated tasking authority” (AAP-42).
Page 49 of 30

RIEDP Study Group Final Report - Simulation Interoperability

Transcription

Similar documents

SAMSUNG INDIA SOFTWARE OPERATIONS PVT. LTD. (SISO

coRcIAL. BaNks

Generic Methodology for Verification and Validation (GM

GM- VV - Simulation Interoperability Standards Organization

Parallel Interleaver Architecture with New Scheduling Scheme for

SISO Mag Issue 2 2015 - Singapore Institution of Safety Officers

SISO Programs and Service Expansion in Hamilton NEW TESL

TyMetrix eBillingDesk - College of Law Practice Management

SISO How to Guide[1] copy

Subtittles by Dicapta