An Architecture for Demonstrating the Interplay of Emerging SISO Standards Curtis Blais MOVES Institute Naval Postgraduate School 700 Dyer Road Rm265 Monterey, CA 93943
[email protected]
Paul Gustavson SimVentions, Inc 11905 Bowman Drive, Suite 502 Fredericksburg, VA 22408-7307
[email protected]
Per M. Gustavsson Ericsson Storgatan 20 Skövde, Sweden 54130
[email protected]
Steven Reichenthal Boeing Corporation 3370 Miraloma Anaheim, CA 92806
[email protected]
Keywords: Base Object Model, Battle Management Language, Distributed Interactive Simulation, Extensible Markup Language, High Level Architecture, Interoperability, Military Scenario Definition Language, Simulation Reference Markup Language ABSTRACT: The Simulation Interoperability Standards Organization (SISO) focuses on facilitating simulation interoperability across government and non-government applications worldwide. A number of standards are emerging that will individually have great impact on the development and operation of simulation systems, as well as interoperation across simulation systems and command and control systems. More importantly, when these standards are applied together, they represent a set of capabilities and technologies which can revolutionize the simulation industry, radically improving the way we develop and deliver interoperable systems. Each of the following standards addresses specific needs that have been shortcomings in M&S interoperability in the past: (1) the Coalition Battle Management Language (C-BML) provides a way to represent the coalition battle management doctrine within a Command and Control environment to enable unambiguous expression of plans and orders for live, constructive, and robotic forces; (2) the Military Scenario Definition Language (MSDL) provides a common way to describe a scenario, including initialization information, that can be shared across multiple systems; (3) the Base Object Model (BOM) standard provides a way to identify piece parts of a simulation or model that can be used as building blocks for composing larger model sets; (4) the Simulation Reference Markup Language (SRML) provides a platform-independent way to represent behavior models which can be rendered quickly and easily (at runtime) by a simulation; and (5) the Distributed Interactive Simulation Extensible Markup Language (DIS-XML) initiative provides a way to represent DIS Protocol Data Units using XML to enhance interchange of dynamic entity state and entity interactions across diverse systems. This paper gives a brief overview of these key standardization efforts, and explores how each standard can interplay with other standards. The paper lays out an abstract architecture for demonstration of the composition of prototype versions of these products to show the community how they will be employed in the future and what benefits will accrue. The paper proposes a plan of action to implement the architecture for demonstration and discussion at the Spring 2007 Simulation Interoperability Workshop.
1. Introduction The Simulation Interoperability Standards Organization (SISO) focuses on facilitating simulation interoperability across government and non-government applications worldwide. A number of standards are emerging that will individually have great impact on the development and
operation of simulation systems, as well as interoperation across simulation systems and command and control systems. Taken together, however, the emerging standards represent a set of capabilities and technologies which can revolutionize the simulation industry, radically improving the way we develop and deliver interoperable systems.
Several standardization activities are ongoing within the SISO, including the following Study Groups: • Common Image Generator Interface • Discrete-Event Systems Specification • Generic Methodology for VV&A in the M&S Domain • HLA Performance Recommended Practice • Extensible Modeling and Simulation Framework (XMSF) Profile • Intelligent Tutoring System Interoperability • Mode 5/S Identification Friend or Foe • Simulation Conceptual Modeling • Transfer of Control • Shareable Content Object Reference Model (SCORM) – Simulation Interface Standards Study Group efforts make a particular problem and proposed solution known to the SISO community in order to determine if the approach warrants transition to Product Development status. Study Groups often prepare technical papers and develop demonstrations to present the concept to the community. However, while SISO documentation for transition to Product Group status (the Product Nomination form) calls for description of prototypes developed that demonstrate the value of the proposed standard (or reasons why prototypes have not been developed), there is no requirement to show compatibility of the product with other SISO standards. The Product Nomination also has a section for describing compliance testing planned for the proposed standard. However, there is no environment maintained by SISO or the community to support compliance testing in a way that would show how the new standard integrates with existing SISO standards. The following standards have progressed to Product Development status: • Base Object Model (BOM) Interface Specification • Coalition - Battle Management Language • Core Manufacturing Simulation Data • Commercial Off-the-Shelf Simulation Package Interoperability • Distributed Interactive Simulation Extension • Environmental Data Representation Standards • High Level Architecture-Evolved • Link 11 A/B Network Simulation Standard • Link-16 Simulation Standard • Military Scenario Definition Language • Real-Time Platform Reference Federation Object Model • Simulation Reference Markup Language • Verification, Validation and Accreditation Overlay to Federation Development
Even at this stage in the standardization process, there is no composite environment for demonstrating implementations of the emerging standards to educate the community about the new standard and to show the benefit gained for system interoperability from its introduction. We believe a demonstration of the ability of an implementation of a new standard working with other existing standards, when appropriate, should be a part of the Product Development process. Clearly several of the SISO standardization efforts are focused on interoperability of military Modeling and Simulation (M&S) systems and Command and Control (C2) systems. However, some of these standards may have application to a broader community. The opportunity to demonstrate the product in a composite environment may stimulate interest across the full SISO community, allowing others to integrate additional systems or software to investigate possible use in their domain. To explore this idea, we have selected 5 of the above 13 product development areas for the purpose of planning an integrated demonstration of these technology standards. Each of the following standards addresses specific needs that have been shortcomings in M&S interoperability in the past: (1) The Base Object Model (BOM) standard provides a way to identify piece parts of a conceptual model or simulation, which can be used as building blocks for composing larger model sets; (2) The Coalition Battle Management Language (CBML) provides a way to represent the coalition battle management doctrine within a Command and Control environment to enable unambiguous expression of plans and orders for live, constructive, and robotic forces; (3) The Distributed Interactive Simulation Extensible Markup Language (DIS-XML) initiative provides a way to represent DIS Protocol Data Units in common structured way using XML to enhance interchange of dynamic entity state and entity interactions across diverse systems; (4) The Military Scenario Definition Language (MSDL) provides a common way to describe a scenario, including initialization information, that can be shared across multiple systems; and (5) The Simulation Reference Markup Language (SRML) provides a platform-independent way to represent behavior models which can be rendered quickly and easily (at runtime) by a simulation. This paper gives a brief overview of these key standardization efforts. This background information is intended to help understand the basic capability offered
by each independent product standard and to begin to convey the potential these product standards offer collectively. The paper then describes a use case to serve as a context for demonstrating the standards and lays out an abstract architecture for composition of prototype versions of these products. The purpose is to show the community how the standards can be employed in the future and what benefits will accrue. The paper proposes a plan of action to implement the architecture for demonstration and discussion at the Spring 2007 Simulation Interoperability Workshop. Finally, the paper concludes with a summary and go-forward recommendation for SISO and the M&S community.
2. Selected Standards Demonstration Environment
for
Initial
The following subsections provide brief overviews of the selected standards for proposed development of the demonstration environment. 2.1 Base Object Model A Base Object Model (BOM) is defined as “a piece part of a conceptual model, simulation object model, or federation object model, which can be used as a building block in the development and/or extension of a simulation or federation.” Essentially, a BOM provides a framework for representing M&S components in two ways: (1) It can specify a conceptual model to be represented by a simulation (or system); (2) It can also be used to specify the data structure, such as an object or interaction class, intended to be used by a simulation (or simulation environment). It should be noted that a BOM can take on either or both of these two forms in representing a profile for a component. Within M&S, the concept of components has been defined as follows: Reusable building blocks which have a known set of inputs and provide expected output behavior, but the implementation details may be hidden. Such components are useful for constructing simulations and/or providing functionality for simulation systems. The important message is that BOMs focus on defining the “interface” of a component not on capturing its “implementation.” This interface concept is what was meant by the term profile earlier. Allowing one to understand how a component is to behave via the conceptual model, and also how a component is structured via the object model, leaves opportunity for
unique implementations. Such component implementations can be developed independently by adhering to the described interface. This, in essence, is the concept behind what is intended for a Service Oriented Architecture (SOA) design. An SOA design places emphasis on a loosely coupled environment of systems, components and other resources – resources that can be exchanged for others. What this SOA approach means is that a BOM paints the picture of what is intended and represented, allowing it to serve as a contract, and the implementation of the BOM behavior is captured independently. Specifically this behavior can be either contained within the simulation internally (by its own code), or by component implementations, such as a Windows DLL, a Unix Object, or in other ways such as the Simulation Reference Markup Language (SRML). The concept of using SRML as a means to capture and catalog behavior is described later in this paper. This separation of interface from implementation allows BOMs to serve as building blocks for supporting composability regardless of the hardware platform, operating system, or programming language required of a simulation. This includes the composition of High Level Architecture (HLA) object models, federate capabilities, and/or federation agreements. It is essentially the responsibility of the simulation to provide the implementation or behavior that is described by the interface (i.e., BOM) for the language and platform it operates under. It’s important to understand the basic structure of a BOM, which provides the framework to support this type of composability. Figure 1 depicts the basic structure offered by the BOM standard. As illustrated, the major elements of a BOM include the metadata, identified as the Model Identification, the Conceptual Model, the Model Mapping and the Object Model Definition. An XML schema has been defined for the BOM standard that characterizes these elements. Like many of the other simulation standard technologies described in this paper, XML is used to represent a defined BOM, providing a language-neutral interface that identifies the essential elements provided by a component or piece part. A developed BOM, which is documented in XML, will identify the XML Schema. This allows the XML parser to validate if a BOM carries the expected information prescribed by the schema.
Model Identification (Metadata) Conceptual Model Pattern Of Interplay State Machine Entity Type Event Type Model Mapping
Name Type Version Modification Date Security Classification
References * Release Restriction *
Other
Purpose
Glyph Type Image Alternate Text Height Image
Entity Type Mapping
Application Domain
Event Type Mapping
Description
Object Model Definition HLA Object Classes HLA Object Classes
POCs * Type Name Organization Telephone Email
Use Limitation Use History * Keyword Taxonomy/Value *
* Multiples Allowed
HLA Object Class Attributes HLA Interaction Classes
Figure 2. Model Identification Metadata Component
HLA Interaction Classes HLA Interaction Class Parameters HLA Data Types Notes Lexicon (definitions)
Figure 1. BOM Structure Elements Perhaps the most reusable aspect of the BOM standard is the Model Identification element. This piece is used to represent the metadata for a BOM so that it can be described, discovered and properly reused. This component has also been adopted by the HLA Evolved Product Development Group (PDG) as the new way to describe (tag) Federation Object Models (FOMs) and Simulation Object Models (SOMs). Because of the general utility of the metadata prescribed, the potential exists to use the Model Identification for resources other than FOMS, SOMS and BOMs. For instance, the Model Identification could be used to describe and catalog MSDL scenarios and other XML-based products. It should be noted that Model Identification is a derivation of the original HLA FOM Model Identification, the Dublin Core metadata standard, the DoD Discovery Metadata Standard (DDMS), and the fusion of relevant information from the Verification, Validation and Accreditation (VV&A) recommended practice guide (RPG). Model Identification is also captured within its own namespace and schema thereby easily allowing the Model Identification component to be used for other purposes. Figure 2 provides an illustration of the metadata elements provided by the Model Identification.
Regarding the Conceptual Model Definition element of a BOM, one of the benefits of BOMs is the ability to capture a pattern of interplay among conceptual entities. This is accomplished in the Pattern of Interplay portion of the BOM. The Pattern of Interplay is composed of a collection of actions that describe the events that transpire among the conceptual entities being modeled. These events are messages or triggers that have been included in the Event Types section of the BOM. Likewise, the conceptual entities are captured in the Entity Types. The Pattern of Interplay actions also contain a sender and receiver property that allows the BOM user to denote which conceptual entities the event occurs between. Another advantage of the BOM is the ability to capture the states of the conceptual entities, which is done in the State Machine section. The events that initiate a transition from state to state are also noted in the state machine. Like an HLA FOM, the BOM can also capture elements of the Object Model Definition. These elements are leveraged from the HLA Object Model Template (OMT) and include the object classes and attributes, interaction classes and parameters, and data types. While the OMT elements are used, not all fields in the tables may be applicable to a BOM as the BOM was built to be HLA friendly but not dependent on the use of HLA. Finally, the Model Mapping elements provide a bridge between the Conceptual Model information and the object model definition. Users can map entities and events to the classes that will fulfill the behavior needs described in the Pattern of Interplay. If a BOM exists that describes an interface to a model, whether it be an object class, pattern of interplay, or state
machine, and that model appears to support the required objectives for the federate or federation, it would be sensible to use that existing model instead of repeating the development process; that is recreating it. Furthermore, such a BOM could provide use history and other related metadata that would assist in the selection process. 2.2 Coalition Battle Management Language There has long been a recognized need to develop a standard battle management language (BML) for expressing plans, orders, reports, and requests in a common format that can be produced and consumed by M&S and C2 systems. Such a language must enable unambiguous expression of orders and commands that can be understood and acted upon by live (real), constructive (simulated), and robotic (real or simulated) forces. A BML must formalize concepts such as the “Who, What, When, Where, Why” (5W’s) information needed to command and control forces.
service C2 and M&S systems. The PDG has laid out a 3phase development effort: (1) specify a sufficient data model to unambigously define a set of military orders using the Command and Control Information Exchange Data Model (C2IEDM) as a starting point; (2) develop a formal grammar (lexicon and production rules) to formalize the definition of orders, requests, and reports; (3) develop a formal battle management ontology to enable conceptual interoperability across software systems [2].
These principles have led researchers to describe three “views” or perspectives on BML [1]: •
BML Doctrine View: Every term in the language must be unambiguously defined and must be rooted in military doctrine. BML should not implement a single service doctrine, but allow different doctrinal viewpoints of services or nations to be defined. This is conveyed in BML by a glossary of terms and definitions.
•
BML Representation View: The representation structures and relates the terms defined in the doctrine in a way that they result in the description of executable missions and tasks. Relevant representations can include conceptual, logical or physical data models or fully formalized ontologies.
•
BML Protocols View: Protocols standardize the way the description of the executable tasks and assigned executing military means is transported from the BML implementation to the target system (C2, simulation, or robot). In the emerging net-centric operational environment, Web-based standards and grid standards offer candidate protocols. In particular, the use of XML to describe information exchange requirements is considered fundamental since it is the currently accepted standard for data description across C2, simulation, and robotic systems.
Figure 3 summarizes the three BML views. It should be clear that BML is a concept that can have numerous realizations across the three views. In March 2006, the SISO Standards Advisory Council approved initiation of a PDG to generate a standard and guidance document for a Coalition BML (C-BML) to promote interoperability across multi-national and multi-
Figure 3. BML Triangle: Doctrine, Representation, and Protocols. 2.3 Distributed Interactive Simulation – Extended Markup Language The Distributed Interactive Simulation (DIS) is an established standard [3] that is being extended with new capabilities through a current SISO PDG. DIS provides a message format and protocol standard enabling distributed simulation systems to communicate simulation state information. DIS is used in many military simulations, including large-scale High Level Architecture (HLA) federations through network bridges commonly called DIS gateways. The protocol defines, among other things, a set of Protocol Data Units (PDUs). The PDUs are specified in a binary format to promote efficiency. A single host may process thousands of PDUs per second, and binary formats are an efficient format from which to extract information. However, the efficiency comes at a cost. Because the data is in a binary format it cannot be easily processed by tools that are unaware of the DIS standard. For example, it might be useful to search an archive of all PDUs exchanged in an exercise in order to find entities that passed through a particular area, or entities that met certain criteria, such as speed or entity type. If the archived PDUs are in the binary IEEE-1278.1 format this task is more difficult than it needs to be; the tools that search the PDU archive need to understand DIS. It would be more useful to reuse
powerful, industry standard tools to process the information, but these tools typically do not understand the binary DIS format. [4] What is needed is a representation of the information contained in a PDU in a maximally useful format for use by other tools, without giving up the performance and backwards compatibility advantages of the IEEE-1278.1 format or the programming convenience of an objectbased Application Program Interface (API). XML is a natural choice to meet these requirements. Once the data is represented in XML format the full range of extant XML tools can be brought to bear on DIS data: archiving, transformation, database, web services, and so on. However, the XML format is less efficient for hosts in high traffic environments to process. What is needed is a way to shift the information contained in a PDU to the most convenient format for any particular context, so binary data can be used in high traffic environments, and XML for archiving and data exchange with systems outside of the traditional DIS problem space. Combined with the need for a programming language representation of the PDUs, there are at least three convenient ways to represent the data: IEEE-1278.1 binary, XML, and programming language objects. The representations of the data and transformations between the representations is shown in Figure 4.
Figure 4. Translating DIS Data across Three Formats [4] XML’s main benefit is that it is ubiquitous and often used as a standard for interchange between formats. While useful, this is really only interoperability on the level of syntax. Much more could be done if there was agreement at the level of data semantics. This requires agreement on the meaning of the XML elements and attributes. The Naval Postgraduate School (NPS) has developed an XML schema that describes the DIS PDUs. Another, equally valid schema written by another author may use different element or attribute names. The same semantic information is denoted by two different names, and exchanging XML data between applications using the two schemas will require manual disambiguation or other mapping operations. Just as existing applications can
exploit commonality due to the standardization of IEEE1278.1 binary PDUs, future applications can benefit from a single, agreed-upon standard for XML representations of DIS. The NPS DIS-XML schema and codebase have been submitted to the SISO DIS Extension Working Group for further study and potential standardization. 2.4 Military Scenario Definition Language MSDL is a scenario development approach providing simulations with a mechanism for loading military scenarios, the ability to create a military scenario for simulation that can be shared between simulations and C4I devices, and a way to improve scenario consistency between federated simulations [5] In April, 2006, the SISO initiated a Product Development Group for MSDL that is closely aligned with standardization of C-BML since many of the information elements are the same (e.g., specification of forces) and initial plans for an operation or exercise often are part of the initialization of a C2 or M&S system, such as the initial Air Tasking Order, ground missions, or amphibious ship-to-shore movements. For this reason, it is planned for the two standards to share a common tasking language and grammar. Standardization of MSDL will enable using communities to save and re-use scenario descriptions across a variety of systems. MSDL is defined by a set of XML Schema files describing valid structure and content of an MSDL document. The draft specification states that military scenarios include “information such as overlays, control measures, terrain, weather and unit relationships, affiliations and organization.” As indicated above, the scenario also captures the results of mission planning, including “plan objectives, scenario situation, and other data that supports execution matrices and related planning annexes.” Primary elements in the XML data structure include [5]: • Options: Identify how task organizations are specified (entity or aggregate based), the data standards being used by the scenario (coordinate systems and associated datum; enumeration standard and version) and any application specific options that have been created by the Command and Control (C2) planning application(s) which created the scenario. • Environment: Provides absolute scenario time (initial time), identification of the terrain (data source and terrain boundaries), and synoptic weather (temperature range, moon rise and set times, sun rise and set times, nautical twilight, clouds/fog/haze visibility and ceiling information), and METOC graphics. • Force Structure: Specifies the sides of the battle to which specific forces are aligned.
• • • • • • •
Task Organizations: Identify units and equipment, where equipment generally equates to entities in a simulation. Installations: Identify military facilities. Overlays: Provide a mechanism for linking Tactical Graphics to specific Overlays or Layers to be placed on a tactical map display. Tactical Graphics: Provide the definition of control measures (by referencing particular Overlay entries). Military Operations Other Than War (MOOTW) Graphics: MOOTW symbol modifiers as defined in MIL-STD-2525B. Threats: Specify non-military (threat) organizations, including characterization of the effects of threat-based actions/activities. Plan: Provides descriptive information on the scenario as well as executable courses of action. Information includes an executive summary of the Operations Order (OPORD), scenario objectives, references to doctrine, and planning documents.
2.5 Simulation Reference Markup Language SRML provides the simulation community an HTML-like (Hyper Text Markup Language) format for use with simulations. The constructs in SRML provide a highly generalized means for representing and executing virtually any kind of simulation behavior. This is provided by the object-oriented, scripting, and extensibility foundation. Just as HTML operates in web browsers, SRML simulation models operate when loaded into SRML Simulation engines. Such an engine provides a common run-time environment and API. The defense simulation community is familiar with the standardized API paradigm which is manifested in the HLA standard. With SRML, modelers who use HLA are not required to own and maintain the inner workings of a simulation engine or its integration with the API, but instead build models at a higher level of abstraction, although the HLA API may be exposed and used directly within an SRML environment. SRML's purpose is to facilitate the interchange of simulation models using XML. At a minimum, it provides the capability to "mark up" arbitrary XML documents in order to describe functional behavior of the elements. A common way of providing this behavior is through the use of "script" elements, just like HTML does but with more control. As such, SRML provides a framework for precise, unambiguous, and executable descriptions of behavior using the same language-independent features afforded by a common web browser.
The flexibility designed into SRML makes it amenable for use with other XML schemas that provide the domainspecific markup. For example, an MSDL or C-BML model may have behavior underlying the data elements marked up with SRML so that the model may be loaded into an SRML simulator and executed directly. XML models marked up with SRML may be stored on web servers and downloaded using HTTP or similar protocol, and then assembled into executable models at run time. Such servers may be either secure or open to the public. Once downloaded, the source code may be inspected and modified, unless the source code had been pre-compiled into a plug-in. Downloading is not the only mechanism for putting models together. An SRML-capable simulation engine may also interoperate with other simulations using an HLA layer. In addition, when using the BOM methodology of dividing a FOM into smaller pieces, the resulting fragments can be executed individually or collectively in a natural way in an SRML simulation engine. Potential benefits from using SRML include reduced cost, more accessibility, and greater interoperability based on the similarities to HTML. A modeler can develop a simulation once and load it into any capable engine. However, it will likely take time and commitment to realize this benefit, given that early in the history of web browsers, behavioral compatibility was poor. Yet, now that the standards and time have brought about a greater maturity, more commonality exists. Likewise, early HLA Run-Time Infrastructures (RTIs) did not work identically, but are now more compatible.
3. Demonstration Approach Earlier work has described the interplay possible between the BOMs and SRML standards. In [6], the authors applied BOMs to process-oriented simulations, which are typically employed in the analysis and design of manufacturing, logistics, industrial, military, and business process. They investigated how several popular and emerging formalizations for describing processes relate to BOMs and how their features can be encapsulated with SRML, federated, and executed with a standardized simulator. This effort provided an example of the composition of various "Process BOMs" into an executing model and identified opportunities for SISO to impact the process-oriented community. .In [7], the authors investigated the application of BOMs and SRML in addressing the HLA Federation Development and Execution Process (FEDEP) [8], showing how using composition rather than inheritance can improve the
reusability and flexibility of the interface assemblies expressed as BOMs and how the underlying code use to model the behavior of an encapsulated BOM can be accomplished using SRML. These precursors to the current effort provided the simulation community valuable insights into the benefits of application of these emerging standards and provide a basis for the current work. Other efforts involving BML, DIS-XML, and MSDL have clearly demonstrated the benefit of the other standards discussed in this paper, but have mainly been in isolated demonstrations to make the benefits of the particular proposed standard as apparent as possible in order to establish rationale for continued standardization effort. What has not occurred is establishment of a wide-reaching demonstration or test environment within which the mutually supporting (and possibly conflicting) capabilities of the various standards could be put on display for evaluation and education. 3.1 Use Case The notional use case selected for the initial demonstration is planning a mission involving the employment of autonomous robotic forces. Robotic systems are interesting in that they need to be directed either by detailed scripted orders, much like the encoded behaviors of constructive forces in simulation systems, or by declarative mission orders providing high-level goals to be achieved and allowing the robots to perform their own low-level planning to achieve the goal, much like how orders to live human forces are given (at each level of command, a certain degree of autonomy and initiative is allowed). The distinction between live and simulated robotic forces is blurred since precisely the same orders are given to both, and each class of robots will use its implemented control mechanisms (according to the architecture of the individual robotic system) to carry out the assigned orders. Using a situation involving robotic forces for the demonstration removes the need to involve live human forces, which would overly complicate the demonstration architecture and execution. Finally, numerous simulation test beds for robotic simulations exist for the purpose of testing and rehearsing robot missions and decision-making before employing those systems in a live mission. Specifically, NPS has developed a simulation test bed for Autonomous Unmanned Vehicles (AUV) that includes implementation of an Autonomous Vehicle Command Language (AVCL) and already incorporates DIS-XML communications of simulated object state information. The NPS AUV Workbench is a candidate environment for integration of the SISO standards selected for the proposed demonstration. Refer to [9] for discussion of AVCL and
its implications for the C-BML specification relative to command and control of robotic forces. The scenario of interest is Anti-Terrorism/Force Protection (AT/FP) of a harbor, where one or more unmanned surface vehicles (USVs), unmanned air vehicles (UAVs), unmanned undersea vehicles (UUVs), and unmanned ground vehicles (UGVs) have the mission of creating a layered defense by patrolling a protected area and alerting response teams (also unmanned, for purposes of this scenario) when a suspect or hostile intruder is detected. Such a scenario has clear implications to military planners as well as cross-over into the public Homeland Security arena. 3.2 Architecture In order to address the proposed use case, the contribution of each of the selected standards needs to be described and any required interactions across the standards need to be identified. Conceptually, the selected standards offer the following capabilities in the context of this scenario: (1) BOM – conceptual modeling of each of the entities (robotic platforms) and specification of interactions (patterns of interplay) among the entities; (2) C-BML – specification of the orders given to each of the robotic platforms, either as scripted behaviors or goal-directed tasks (see [9]) (3) DIS-XML -- runtime state updates that can be used for visualization of the scenario, logging of state changes, and entity messaging; (4) MSDL – description of all initialization data regarding the locale, forces, force structures, environment, control measures and other information to preserve the scenario set-up for re-use; and (5) SRML – representation of entity behaviors and dynamic execution of actions and interactions of the entities. A significant commonality across these selected standards is the use of XML to structure and pass information in the respective standards. An interesting aspect of the development of the demonstration architecture will be seeing how much of the interplay across these standards can be performed using common XML tools and techniques, such as the Extensible Stylesheet Language for Transformations (XSLT) to move information across representations. Figure 5 provides an abstract view of the proposed demonstration architecture, suggesting the roles and interactions across the standards as indicated above (entities in the Operational category would be replaced by the various types of autonomous vehicles identified previously in 3.1).
Figure 5. Abstract Demonstration Architecture.
4. Plan of Action and Milestones for Spring 2007 Demonstration The goal of this proposed activity is to provide a demonstration of the selected standards, working in an integrated fashion in the context of the proposed use case, for the Spring 2007 Simulation Interoperability Workshop (to be held in Norfolk, VA). The following is a preliminary set of tasks and possible timeline for preparing for the Spring SIW demonstration: (1) October 2006: Kick-off meeting (teleconference) involving participants representing the 5 selected standards (BOM, C-BML, DIS-XML, MSDL, and SRML) to plan and coordinate activities. (2) November 2006: Finalize scenario details regarding types and quantities of autonomous vehicles to be represented, what behaviors they will have and how they will be controlled (scripted or goal-driven). Develop initial MSDL description of the scenario.
(3)
(4)
(5)
(6)
(7)
Conduct an inventory of candidate workbenches, platforms, tools etc. to be used. December 2006: Develop BOM object model definitions and conceptual models of the entities. Refine the MSDL scenario description. Create CBML expressions of the orders to be given to and executed by the autonomous vehicles. January 2007: Refine BOM patterns of interplay and state machine descriptions in coordination with SRML description of same. February 2007: Begin integration of various descriptions into executable environment, generating DIS-XML messages to drive independent visualization (e.g., NPS AUV Workbench). March 2007: Finalize integration of the various representations demonstrating use of the selected standards for the chosen scenario. Dry run Spring SIW demonstration narrative and actions. April 2007: Set up and conduct demonstration at Spring SIW.
Additional details will be filled in as the coordination occurs following the 2006 Fall SIW. An additional action between now and the Spring SIW will be submission of a paper abstract and full paper providing further details about the demonstration architecture and preparations leading up to the Spring SIW demonstration.
5. Summary As identified in this paper there are many SISO standardization efforts that have been researched and developed. Each independently provides a unique capability for simulation interoperability. The true success of these standards, however, is in how well they are able to work together. The aim of this paper and planned exercise is to demonstrate how the standards can work together for greater benefit than when they are employed individually. The proposed demonstration architecture will show capabilities of the Base Object Model, Coalition Battle Management Language, Distributed Interactive Simulation – Extensible Markup Language, Military Scenario Definition Language, and Simulation Reference Markup Language. We invite other PDGs to consider how they can participate in the Spring demonstration. Coordination of the effort will be challenging, particularly considering that most efforts supporting SISO are performed on a volunteer basis, but the near and longterm benefits to the community would be significant. Beyond this initial demonstration, we recommend that SISO consider the concept of establishing a standing demonstration test bed, perhaps as extension of the work to be demonstrated in the Spring, that can be used by Product Development Groups to demonstrate how emerging standards fit into the big picture to complement each other and address major interoperability issues. We believe this will greatly benefit the SISO community by offering more opportunities for education and familiarization in the capabilities of emerging standards, and in providing an environment for development and testing of supporting tools, techniques, and methodologies.
6. References [1] A. Tolk, and C. Blais: “Taxonomies, Ontologies, and Battle Management Languages – Recommendations for the Coalition BML Study Group,” Paper 05SSIW-007, Simulation Interoperability Standards Organization, Spring Simulation Interoperability Workshop, San Diego, CA, April 2005.
[2] C. Blais, K. Galvin, and M. Hieb: “Coalition Battle Management Language (C-BML) Study Group Report,” Paper 05F-SIW-041, Simulation Interoperability Standards Organization, Fall Simulation Interoperability Workshop, Orlando, FL, September 2005. [3] IEEE: Standard for Distributed Interactive Simulation – Application Protocols, IEEE 1278a-1998. [4] D. McGregor, D. Brutzman, C. Blais, A. Armold, M. Falash, and E. Pollack: “DIS-XML: Moving DIS to Open Data Exchange Standards,” Paper 06S-SIW132, Simulation Interoperability Standards Organization, Spring Simulation Interoperability Workshop, Huntsville, AL, April 2006. [5] Simulation Interoperability Standards Organization: Specifications for Military Scenario Definition Language (MSDL), Initial Draft, 5 April 2005. [6] S. W. Reichenthal and P. L. Gustavson: “Manufacturing BOMs with SRML for ProcessOriented Federations,” Paper 03F-SIW-109, Simulation Interoperability Standards Organization, Fall Simulation Interoperability Workshop, Orlando, Florida, September 2003. [7] P. Gustavson, K. L. Morse, R. Lutz, and S. Reichenthal: “Applying Design Patterns for Enabling Simulation Interoperability,” Paper 04S-SIW-111, Simulation Interoperability Standards Organization, Spring Simulation Interoperability Workshop, April 2004. [8] IEEE 1516.3, High Level Architecture (HLA) Federation Development and Execution Process (FEDEP), April 2003. [9] D. Davis and C. Blais: “Autonomous Vehicle Control Language for Simulated and Real Robotic Forces,” Paper 06F-SIW-004, Fall Simulation Interoperability Workshop, Simulation Interoperability Standards Organization, Orlando, Florida, September 2006.
Acknowledgements We thank the Defense Modeling and Simulation Office (DMSO) for sponsoring the BOM development effort intended to bring forth an increase in composability within the distributed simulation communities. We also express gratitude to SMART-lab 1 for the sponsoring of Swedish participation in simulation interoperability standardization development.
Author Biographies
1
SMART-lab is a Swedish Defence Materiel Administration facility with an environment installed for analysis and development of the total Swedish defence.
CURTIS BLAIS is a Research Associate at the Naval Postgraduate School with the Modeling, Virtual Environments, and Simulation (MOVES) Institute. His principal research areas at NPS include agent-based simulation of non-traditional warfare and application of Semantic Web technologies to improve interoperability of Command and Control systems and Modeling and Simulation systems. Mr. Blais has a B.S. and M.S. in Mathematics from the University of Notre Dame, and is a Ph.D. candidate in MOVES at the Naval Postgraduate School. PAUL GUSTAVSON is Chief Scientist and co-founder of SimVentions, Inc. He has over 17 years experience supporting a wide variety of modeling and simulation, system engineering, and web technology efforts within the DoD and software development communities. Mr. Gustavson has been a long-time advocate and pioneer of the Base Object Model (BOM) concept for enabling simulation composability, interoperability and reuse. He has also co-authored and edited several software development books and articles related to C++, UML and mobile computing.
PER M GUSTAVSSON is a Research Engineer at the M&S and Information Fusion office at Ericsson Microwave Systems AB (EMW) working with applied research in the area of advanced decision support systems. He is the Vice Chair of the Coalition Battle Management Language Standardization within SISO. He is also an industrial Ph.D. student at University of Skövde, Sweden enrolled at De Montfort University, Leicester, UK with his research interest is multi-hypothesis real-time simulation based decision support systems. Gustavsson holds a M.Sc. in Computer Science, New Generations Representations, Distributed Real-Time Systems and a B.Sc. in Systems Programming both from University of Skövde, Sweden. STEVEN W REICHENTHAL is an Associate Technical Fellow at the Boeing Company. He develops simulations and applications as a member of the Logistics organization in Anaheim, California. He has a Masters degree in Computer Science and an MBA, and has taught software development courses at the California State University in Fullerton as an adjunct professor since 1993.
