Table 1: Operational Context Examples Commander's intent and guidance Coordination measures Scope of operations (e.g, Airspace Coordination Order, Command relationships Waterspace Management Mission assignments/objectives Schedule of operations Task force order of battle(OOB )and Air Tasking order planned disposition of forces Resource management plans Courses of Action(COA Weather forecasts Rules of engagement (ROE Unit readiness/health and status Operational Net Assessment (ONA · Shared track data Context Aware The NCW future demands a broader range of warfare systems and processes that are more interoperable and automated. we need our warfare and modeling and simulation (M&s) systems, like our people, to be context-aware and context-driven. The desired result is computer support for the warfighter that is more sophisticated, knowledgeable and proactive. These improvements require that the warfare and m&s systems, like the people they support, will need to understand and use operational context. This is true whether the automation is embedded in decision support systems, autonomous vehicles, or intelligent software agents. People and programs can only reason about, and react to available information (i.e, information that is accessible and can be understood and processed). Thus, warfare system and process automation requires the ubiquitous exchange of operational context information between information system This relationship between automation, operational context, and interoperability defines a critical needed DoD transformation. We must be able to represent operational context, about the full scope of military operations, in a manner that can be understood by future Naval, Joint, and Coalition warfare systems. This requires a fundamental new interoperability baseline! It is a new baseline because of its broad range of content and the need for a single systemindependent representation of operational context. But why emphasize the need for a single system-independent representation, cant each system simply chose its own way to represent context? Independent system-specific models offen create unsolvable interoperability problems. Beware the tower of babel Unfortunately, independent system-specific models often create unsolvable interoperability problems. Consider these two system-unique models of classification uncertainty System"A probabilistic classification description(e. g, track X is 60%sub, 30% surface, 10% air) and system"B"a single best guess(e.g, track X is unknown, sub, surface, or air). This is one small example of what often is thought of as a classic "Tower of Babel"problem. There is no unambiguous translation between System A"and System"B"! Shared understanding is limited when information is lost or can not
Table 1: Operational Context Examples • Commander's intent and guidance • Scope of operations • Command relationships • Mission assignments/objectives • Task force order of battle (OOB) and planned disposition of forces • Courses of Action (COA) • Rules of engagement (ROE) • Operational Net Assessment (ONA) • Coordination measures (e.g., Airspace Coordination Order, Waterspace Management) • Schedule of operations • Air Tasking Order • Resource management plans • Weather forecasts • Unit readiness/health and status • Shared track data Context Aware The NCW future demands a broader range of warfare systems and processes that are more interoperable and automated. We need our warfare and modeling and simulation (M&S) systems, like our people, to be context-aware and context-driven. The desired result is computer support for the warfighter that is more sophisticated, knowledgeable and proactive. These improvements require that the warfare and M&S systems, like the people they support, will need to understand and use operational context. This is true whether the automation is embedded in decision support systems, autonomous vehicles, or intelligent software agents. People and programs can only reason about, and react to, available information (i.e., information that is accessible and can be understood and processed). Thus, warfare system and process automation requires the ubiquitous exchange of operational context information between information systems. This relationship between automation, operational context, and interoperability defines a critical needed DoD transformation. We must be able to represent operational context, about the full scope of military operations, in a manner that can be understood by future Naval, Joint, and Coalition warfare systems. This requires a fundamental new interoperability baseline! It is a new baseline because of its broad range of content and the need for a single system-independent representation of operational context. But why emphasize the need for a single system-independent representation, can’t each system simply chose its own way to represent context? "Independent system-specific models often create unsolvable interoperability problems." Beware the Tower of Babel Unfortunately, independent system-specific models often create unsolvable interoperability problems. Consider these two system-unique models of classification uncertainty. System “A” uses a probabilistic classification description (e.g., track X is 60% sub, 30% surface, 10% air) and system “B” a single best guess (e.g., track X is unknown, sub, surface, or air). This is one small example of what often is thought of as a classic “Tower of Babel” problem. There is no unambiguous translation between System "A" and System "B"! Shared understanding is limited when information is lost or can not
be unambiguous exchanged between systems. XML, nor any technology, can"fix"this problem! Only a shared model (i.e, shared vocabulary - semantics(meaning) and syntax (format) and associated meta-data(.e, relationships or grammar that define logically how the vocabulary elements can be used) can ensure shared understanding and interoperability Today much effort is being applied to improving military operations by directly nterfacing functional systems. This"N-squared"approach is a brute force assault on the Tower of Babel problem, relying on point-to-point information exchanges and translations between the"N"systems, each typically of limited scope. This bottom-t approach will provide near-term improvements but will also fall short of the NCW transformational objective because it does not promote broad and shared situational awareness and understanding. It is also expensive because each interface is unique to design, limited in functionality, and an ongoing expensive to develop and maintain. And don't forget that it may not be possible to exchange some types information because of underlying model differences. XML applied in a similar manner will suffer similar limitations. " My"XML won't be the same as"your"XML, and there may not be a way to convert between the two Top-Down Generic ontology Thus, the holistic operational transformation sought by dod requires a complementary transformation in the way that we design, and implement systems. We must move from the N-squared approach to a l-to-N approach where all share a common"language". This might be somewhat sobering to those that expected that all interoperability issues can simply be handled with a clever unique interface. To the contrary, our objective future lies in the ability to evolve to systems and processes that share an operational context model based on a common ontology. Thus, M&s systems and frameworks will need to similarly converse and reason using this same ontology. How mi ght we represent and share operational context? Today, operational context is initially built through a top-down planning process. Each echelon effectively adds detail to the Operations Order, Daily Intentions message, etc. At each level watchstanders receive this common guidance and read it for general knowledge and then reread the specific details most relevant to his or her functional responsibilities. The passing of operational context to our warfare systems must be similarly streamlined. Context must be entered or generated once and shared, each system distilling what is relevant to its function or tasking. Thus, the operations planning process/systems outputs should be direct scenario inputs to M&s systems, and the selected course-of-action should be directly readable and executable through the C2 and tactical systems. We must ensure that the warfighter is not a data entry clerk for our automated systems. During tactical execution operational context will change and we will need efficient, low/no workload, methods to share these changes in an automated manner across the naval. Joint and Coalition forces
be unambiguous exchanged between systems. XML, nor any technology, can “fix” this problem! Only a shared model (i.e., shared vocabulary - semantics (meaning) and syntax (format)) and associated meta-data (i.e., relationships or grammar that define logically how the vocabulary elements can be used) can ensure shared understanding and interoperability. Today much effort is being applied to improving military operations by directly interfacing functional systems. This "N-squared" approach is a brute force assault on the Tower of Babel problem, relying on point-to-point information exchanges and translations between the "N" systems, each typically of limited scope. This bottom-up approach will provide near-term improvements but will also fall short of the NCW transformational objective because it does not promote broad and shared situational awareness and understanding. It is also expensive because each interface is unique to design, limited in functionality, and an ongoing expensive to develop and maintain. And, don't forget that it may not be possible to exchange some types information because of underlying model differences. XML applied in a similar manner will suffer similar limitations. "My" XML won’t be the same as "your" XML, and there may not be a way to convert between the two. Top-Down Generic Ontology Thus, the holistic operational transformation sought by DoD requires a complementary transformation in the way that we design, and implement systems. We must move from the N-squared approach to a 1-to-N approach where all share a common "language". This might be somewhat sobering to those that expected that all interoperability issues can simply be handled with a clever unique interface. To the contrary, our objective future lies in the ability to evolve to systems and processes that share an operational context model based on a common ontology. Thus, M&S systems and frameworks will need to similarly converse and reason using this same ontology. How might we represent and share operational context? Today, operational context is initially built through a top-down planning process. Each echelon effectively adds detail to the Operations Order, Daily Intentions message, etc. At each level watchstanders receive this common guidance and read it for general knowledge and then reread the specific details most relevant to his or her functional responsibilities. The passing of operational context to our warfare systems must be similarly streamlined. Context must be entered or generated once and shared, each system distilling what is relevant to its function or tasking. Thus, the operations planning process/systems outputs should be direct scenario inputs to M&S systems, and the selected course-of-action should be directly readable and executable through the C2 and tactical systems. We must ensure that the warfighter is not a data entry clerk for our automated systems. During tactical execution operational context will change and we will need efficient, low/no workload, methods to share these changes in an automated manner across the Naval, Joint and Coalition forces
We need an ontology that is country, service, process, system, application, technology, and contractor independent To achieve the NCW transformation, sharing operational context and achieving ubiquitous interoperability demand we work top-down, from a shared ontology. If you stop to think about it this derived requirement is in fact consistent with the best practices within the XML community. That is, XML succeeds when a functional community ormed and interested participants agree to share a namespace and its associated ontology. Additionally, and perhaps most important, as a basis for interoperability we need an ontology that is country, service, process, system, application, technology, and contractor independent. That is, generic, appropriate to all and specific to none. In the Joint and Combined arena we can not rely on identical hardware and software to enable/ensure interoperability, rather we must rely on system-independent information exchange specifications. This is again consistent with the underlying tenants of XML XML succeeds when a functional community is formed and interested participants agree to share a namespace and its associated ontology With the Navy and dod we have pursued functional data managers, effectively working to implement system-independent functional definitions supporting information exchange. For tomorrow we require a new baseline, defined at the enterprise level, that is independent of both function and system Functional stovepipes preclude composing an integrated representation of military operations and in general operational context. Thus, we must seek a new information exchange standard that addresses the broad scope of battlespace information/ operational context we have been discussing Generic hub It turns out that a large group of nato nations have for the past 20 years working to define and demonstrate data interoperability to support command and control information exchange between countries. Over the last ten years this has lead to the creation of the Land C2 Information Exchange Data Model (LC2IEDM), or Generic Hub(GH, now version 5). This model, despite its legacy title, is a rich Joint battlespace operational context model. Many Nato countries have developed prototypes, are fielding systems and are progressing Generic Hub's NATO future. At least one country has begun development of a Gh to HLA interface within the US the army has been most active in the generic hub efforts GH provides a way of describing who, what, where when, how, and why. It is very generic, joint, and coalition by design GH provides a way of describing who, what, where, when, how, and why It is very generic, joint, and coalition by design. It is explicitly designed to ensure data
"We need an ontology that is country, service, process, system, application, technology, and contractor independent." To achieve the NCW transformation, sharing operational context and achieving ubiquitous interoperability demand we work top-down, from a shared ontology. If you stop to think about it this derived requirement is in fact consistent with the best practices within the XML community. That is, XML succeeds when a functional community is formed and interested participants agree to share a namespace and its associated ontology. Additionally, and perhaps most important, as a basis for interoperability we need an ontology that is country, service, process, system, application, technology, and contractor independent. That is, generic, appropriate to all and specific to none. In the Joint and Combined arena we can not rely on identical hardware and software to enable/ensure interoperability, rather we must rely on system-independent information exchange specifications. This is again consistent with the underlying tenants of XML. "XML succeeds when a functional community is formed and interested participants agree to share a namespace and its associated ontology." With the Navy and DoD we have pursued functional data managers, effectively working to implement system-independent functional definitions supporting information exchange. For tomorrow we require a new baseline, defined at the enterprise level, that is independent of both function and system. Functional stovepipes preclude composing an integrated representation of military operations and in general operational context. Thus, we must seek a new information exchange standard that addresses the broad scope of battlespace information / operational context we have been discussing. Generic Hub It turns out that a large group of NATO nations have for the past 20 years working to define and demonstrate data interoperability to support command and control information exchange between countries. Over the last ten years this has lead to the creation of the Land C2 Information Exchange Data Model (LC2IEDM), or Generic Hub (GH, now version 5). This model, despite its legacy title, is a rich Joint battlespace operational context model. Many NATO countries have developed prototypes, are fielding systems and are progressing Generic Hub's NATO future. At least one country has begun development of a GH to HLA interface. Within the US the Army has been most active in the Generic Hub efforts. GH provides a way of describing who, what, where, when, how, and why. It is very generic, joint, and coalition by design. GH provides a way of describing who, what, where, when, how, and why. It is very generic, joint, and coalition by design. It is explicitly designed to ensure data
interoperability and the technical implementation is hardware and software independent Further, a database to database replication mechanism has been specified, implemented, and demonstrated (most recently linking nine command and control systems from seven countries). The GH battlespace information is captured in an entity-relationship model that enables arbitrarily complex statements to be made about forces, plans, capabilities, courses of action. orders health and status. etc. See table 2. The models meta-data captures relationships between information elements and is crucial because relationships explicitly provide much of situational awareness and understanding that supports decision making, See Figure 1. GH provides the rich and generic ontology required to capture, share, and use operational context. Thus, it provides a rational, mature, Joint and Coalition framework for interoperability and building more sophisticated and automated warfare systems, for modeling and simulation, planning, analysis, command and control and tactical operations Table 2: Generic Hub Content Examples Force Composition, Disposition Targeting Sustainment Deployment, Movement, and Mobility and Transportation oeuvre Weapon Systems C4I and Other Information Systems Environmental Conditions Mission information Physical, Land, Sea, Air, Space Command Control. communications Civil Political Cultural economic Intelligence RULE-OF-ENGAGEMENT CANDIDATE- TARGET-LIST APABILITY REPORTING-DATA ACTION CONTEXT OBJECT-TYPE OBJECT-TEM Figure 1. Key Entities of the Generic Hub Data Model
interoperability and the technical implementation is hardware and software independent. Further, a database to database replication mechanism has been specified, implemented, and demonstrated (most recently linking nine command and control systems from seven countries). The GH battlespace information is captured in an entity-relationship model that enables arbitrarily complex statements to be made about forces, plans, capabilities, courses of action, orders, health and status, etc. See table 2. The model's meta-data, captures relationships between information elements and is crucial because relationships explicitly provide much of situational awareness and understanding that supports decision making, See Figure 1. GH provides the rich and generic ontology required to capture, share, and use operational context. Thus, it provides a rational, mature, Joint and Coalition framework for interoperability and building more sophisticated and automated warfare systems, for modeling and simulation, planning, analysis, command and control, and tactical operations. Table 2: Generic Hub Content Examples • Force Composition, Disposition, Sustainment • Mobility and Transportation • Weapon Systems • C4I and Other Information Systems • Mission Information • Command, Control, & Communications • Intelligence • Targeting • Deployment, Movement, and Manoeuvre • Force Security • Environmental Conditions • Physical, Land, Sea, Air, Space Civil, Political, Cultural, Economic CANDIDATE-TARGET-LIST CAPABILITY RULE-OF-ENGAGEMENT REPORTING-DATA OBJECT-TYPE OBJECT-ITEM LOCATION CONTEXT ACTION Figure 1. Key Entities of the Generic Hub Data Model
Maritime Coalition The Naval Undersea Warfare Center, the Naval Postgraduate School, and Institute for Defense Analysis have been collaborating and exploring the use of gh in a maritime coalition context. This initial work has successfully applied gh and XMl in a diverse number of areas including The GH5 formal specification was used to autogenerate a gH5 complete XML Schema. Thus, one way to immediately apply the intellectual work that stands behind he Generic Hub is as an enterprise-level(military operational context) XML namespace and tag set. See side bar and information posted to the doD XML DOD XML Repository: As part of the continuing activities within the Navy to leverage the capabilities of the Generic Hub as the Information Exchange Data Model (EDM), a set of XML tags and the corresponding W3C schema for validation(SD) have been created and submitted to the DOD XML Registry. They provide an enterprise-level military operations XML namespace. The tags and the XSD files can be found by searching for GH5"at http://dides.ncr.disa.millmlreg/user/index.cfi Tactical track data was passed by Gh XMl message between a submarine combat control system [CORBa data server interface]and a Gh operational context server This required determining how to map the content of the track message to the gh ontology Operations plans, in this case a Marine Corps Amphibious Raid, was represented in GH4 database and exported as an Xml document and then visualized by autogenerating a dynamic 3D scene using a XMl technologies and a X3d browser- based presentation GH5 is also being used to specify a new nato translation interface for Global Command and Control System(GCCS). The Situational Awareness Data Interface (SADI)is based on an interface control document defined by GH5. See SADI side ba Situational Awareness Data Interoperability(SADI) is a project, under Military Communications Electronics Board MCEB)sponsorship to define and initiate convergence on a common data exchange approach for situational awareness systems. Ultimately, this project is intended to support the objectives of oint Vision 2020(/2020)and the Global Information Grid(GIG) by facilitating the flow of situational awareness information across the seams between both U.S. and allied(or coalition) forces. Any system would then have to translate to a single interface
Maritime Coalition The Naval Undersea Warfare Center, the Naval Postgraduate School, and Institute for Defense Analysis have been collaborating and exploring the use of GH in a maritime coalition context. This initial work has successfully applied GH and XML in a diverse number of areas including: • The GH5 formal specification was used to autogenerate a GH5 complete XML Schema. Thus, one way to immediately apply the intellectual work that stands behind the Generic Hub is as an enterprise-level (military operational context) XML namespace and tag set. See side bar and information posted to the DoD XML repository. DoD XML Repository: As part of the continuing activities within the Navy to leverage the capabilities of the Generic Hub as the Information Exchange Data Model (IEDM), a set of XML tags and the corresponding W3C schema for validation (XSD) have been created and submitted to the DoD XML Registry. They provide an enterprise-level military operations XML namespace. The tags and the XSD files can be found by searching for "GH5" at http://diides.ncr.disa.mil/xmlreg/user/index.cfm. • Tactical track data was passed by GH XML message between a submarine combat control system [CORBA data server interface] and a GH operational context server. This required determining how to map the content of the track message to the GH ontology. • Operations plans, in this case a Marine Corps Amphibious Raid, was represented in GH4 database and exported as an XML document and then visualized by autogenerating a dynamic 3D scene using a XML technologies and a X3D browserbased presentation. GH5 is also being used to specify a new NATO translation interface for Global Command and Control System (GCCS). The Situational Awareness Data Interface (SADI) is based on an interface control document defined by GH5. See SADI side bar. Situational Awareness Data Interoperability (SADI) is a project, under Military Communications Electronics Board (MCEB) sponsorship, to define and initiate convergence on a common data exchange approach for situational awareness systems. Ultimately, this project is intended to support the objectives of Joint Vision 2020 (JV 2020) and the Global Information Grid (GIG) by facilitating the flow of situational awareness information across the seams between both U.S. and allied (or coalition) forces. Any system would then have to translate to a single interface