 |
 |
 |
 |
| |
|||||
|
|
|
Welcome to the world of models of the physical environment as used in M&S for a spectrum of education, training, and military operations; research, development, and analysis; and advanced concepts and requirements development activities. All these M&S activities have traditionally existed in their own isolated worlds. Enter the Defense Modeling and Simulation Office (DMSO) concept of a Data Interchange Format (DIF) and, in the context of data describing the physical environment within which warfighting activities are modeled, SEDRIS. The Synthetic Environment Data Representation and Interchange Specification is a DMSO-funded activity to develop a DoD-wide capability for environmental data interchange. One that recognizes the disparate nature of simulation interests in environmental data, as well as the wide variety of environmental data types required to populate a sufficiently complete representation of the physical world to meet DoD M&S objectives. A capability that eliminates data stovepipes by addressing the sum total of the existing, and anticipated, data interchange requirements, rather than the lowest common denominator intersection of requirements. In standards development, SEDRIS intentionally broke the DOD mold. For example, SEDRIS ignored the traditional data standardization approach of first specifying and developing a Military Specification format. And then populating that format with data, and handing those "transmittals" out to the customer community for evaluation. SEDRIS put the format-development task last, as it's the most technology-dependent part of the solution, and therefore should not be allowed undue influence. Instead SEDRIS focused directly on the real problem, our inability to agree on a coherent view of environmental data across our community, by developing a data model. In particular, an abstract data model that unifies the disparate types of environmental data into a single coherent view of the critical data elements and their inter-relationships. One that recognizes that just as the real world is seamless, so should be the data model used to describe it. Even if current data production practices intentionally introduce stovepipes for organizational and managerial efficiency. (For instance, the National Imagery and Mapping Agency handles terrain-related data, the Air Force Combat Climatology Center handles weather data, and the Fleet Numeric Meteorologic and Oceanographic Center handles ocean data.) From the perspective of the customer, all of these data sets should be accessible through a single, integrated data model. One that supports both polymorphism and multiple levels of detail; and one that recognizes that how the data is organized can be as important as what the data is!
The result has been real progress on a M&S community-wide agreement of how to describe and interchange environmental data in a manner that improves interoperability among disparate M&S applications. One that, while currently focused on pre-exercise data interchange, can also address the run-time environmental data interchange problem. An agreement expressed using a data model and dictionary, whereby current community modeling practices are influencing the evolution of the Defense Data Dictionary System and DoD Data Model in ways that promote DoD-wide interoperability of environmental data. A draft standard now referenced in the Joint Technical Architecture, and beginning to influence the evolution of the Defense Information Infrastructure Common Operating Environment (DII COE) in the area of geospatial data. An evolvable standard that accomplishes today much of what the Virtual Reality Modeling Language aspires to tomorrow. And a practical demonstration of innovative ways of developing DoD standards. For more information, please contact Paul Birkel using the employee directory. |
Solutions That Make a Difference.® |
|
|
Stove
pipes. The mere mention of that term raises the specter of "reinvention
of wheels," failure to leverage previous investments, failure of
fielded systems to interoperate, and waste of scarce developmental and
operational re-sources. To many, stovepiping is about software systems.
To some, it's about data. Huge quantities of data. Data inaccessibly
stored. And not reused, or maybe even no longer reusable. Who knows?
Because there's no data model accompanying it, no data dictionary describing
it, no documented software interface to access it, and no consensus
among potential users about what any of these things should look like.
Just agreement that there's a high sunk cost, and a high potential for
reuse.
SEDRIS
also avoided the traditional approach of hiring a systems contractor
to conduct surveys, analyze the problem, prepare reports, draft a format,
and then implement the specification. Instead, SEDRIS started with a
small team of talented and experienced engineers (one of them from MITRE)
who knew the complexities of the problem from personal experience, and
who developed a solution strategy based on the direct participation
of small teams of experts from almost 40 different contractor and government
organizations with a vested interest in a practical solution. It seeded
that group of SEDRIS associates with a draft data model, data dictionary,
and Application Programmer Interface (API) specification. It then nurtured
that group to extend and refine those drafts, based on existing legacy
data sets (sometimes requiring the reverse engineering of a data model)
and experiments designed to move actual environmental data in and out
of SEDRIS to determine the sufficiency of the data model. Followed by
interchange of typical data sets between unrelated organizations, using
SEDRIS. Only after the data model was tested repeatedly, did SEDRIS
develop a draft format specification, and then one that recognized only
the SEDRIS data model structure. SEDRIS intentionally did not tune the
specification to the data model details to ensure that the data model
could continue to evolve without requiring further format changes (possible
only because the data format is hidden from data customers by the API;
and the API is intentionally designed to minimize dependencies on data
model specifics).