BOM Methodology Strawman (BMS)

Specification

Version 0.7

15 May 2001

Prepared for:

Simulation Interoperability Standards Organization (SISO) Conference Committee (CC) and

Standards Activity Committee (SAC)

12350 Research Parkway Orlando, Florida 32826-3276

Prepared by:

The Volunteers of the Base Object Model (BOM)

Study Group (SG)

Copyright © 2001 by SISO Incorporated

All rights reserved.

Non-draft versions of this document may be freely redistributed in any form, electronic or otherwise, provided that it is distributed in its entirety and that the copyright and this notice are included. Comments or questions may be submitted via electronic mail to pgustavson@simventions.com. This specification, and other information on the BOM Architecture will be made available via on the web at http://www.sisostds.org/stdsdev/bom/. A list of additional web sites is provided at the conclusion of this document. Questions about products conforming to this specification should be addressed to the vendors of the products. Version history: Version 0.7 May 15, 2001 Version 0.6 March 26, 2001 Version 0.5 March 8, 2001

Keywords: Automation, Behavior, Components, FEDEP, Interoperability, Meta-data, Patterns, Requirements, Reuse, Testing, VV&A

BOM Methodology Strawman (BMS) Specification Table of Contents

Acknowledgements 1. Introduction 1.1. Purpose 1.2. Scope 1.3. Intended Audience 1.4. Referenced Documents 2. BOM Overview 2.1. Background 2.2. BOM Origins 2.2.1. The “Piece Part” Concept 2.2.2. RFOM Study Group 2.2.3. Community White Papers 2.2.4. Component-Based Development 3. Potential Impact 3.1. Next Generation Interoperability 3.1.1. Rapid Federate Integration 3.1.2. Multi-FOM Middleware 3.2. New Interoperability Landscapes 3.2.1. Transforming Simulation Into the Next Media Revolution 3.2.2. Application of BOMs in Experiential Consumer Markets 3.2.3. Commercial Market Potential 4. The Federation Development and Execution Process (FEDEP) 4.1. The Bottom-Up Approach 4.2. The Single SOM/Merge SOM Approach 4.3. Existing/Reference FOM Template Approach 4.4. BOM Integration Approach 5. BOM Architectural Elements 5.1. Types 5.1.1. Interaction BOMs 5.1.2. Trigger BOMs (formerly Attribute-update pair) 5.1.2.1. Object Attribute Update 5.1.2.2. Discreet Object-To-Object Interaction 5.2. BOM Categories 5.2.1. Background 5.2.2. IF BOMs 5.2.3. ECAP BOMs 5.2. Meta Data 5.3. OMT Interface Specification 5.4. Behavior Implementation 6. BOM Development Approaches 6.1. Requirements Meta-Data 6.2. Type Selection

6.2.1. Interaction-based BOM 6.2.2. Trigger-based BOM 6.3. Category Selection 6.4. Level of Tangibility 6.4.1. Concrete BOMs 6.4.2. Abstract BOMs 6.5. Distribution Issues 6.5.1. Resource Repository 6.5.2. BOM Tools 7. BOM Reuse Considerations 7.1. Key Approaches 7.2. Requirements Meta-Data 7.3. Skeleton Design Approach 7.4. Types of Reuse 7.5. History and Feedback 8. Summary Appendixes A. BOM Definition Origin B. Use Cases – A Mechanism for Capturing Functional Requirements B.1. Introduction B.2. Blueprint Centric FEDEP B.2.1. Defining Federation Objectives B.2.2. Development of a Federation Conceptual Model B.2.3. Federation Design B.2.4. Federation Development B.2.5. Integrate and Test the Federation B.2.6. Exercise Federation and Prepare Results B.3. Use Case Template B.4. HLA Use Case Tools B.5. Wrap Up C. Glossary D. Acronym E. Web Sites Bibliography

Acknowledgements List of contributors:

Paul L. Gustavson BOM SG Chair pgustavson@simventions.com John Hancock BOM SG Vice-Chair jhancock@artistech.com Mike O’Connor SAC POC michael.oconnor@itt.com Graham Shanks CC POC GrahamShanks@compuserve.com Chris Stapleton cstaplet@ntmail.ist.ucf.edu Lawrence M. Root lroot@simventions.com Bob Lutz Robert.Lutz@jhuapl.edu Judy Schundua jschandua@caci.com Steve Goss sgoss@simventions.com Roy Scrudder scrudder@arlut.utexas.edu Mark McAuliffe mark_mcauliffe@stricom.army.mil

1. Introduction The Simulation Interoperability Standards Organization (SISO) focuses on facilitating simulation interoperability and component reuse across the DoD, other government, and non-government applications. In pursuit of these objectives, SISO formed the Base Object Model (BOM) Study Group from March 2000 to March 2001 to investigate a promising methodology centered on achieving simulation interoperability through component reuse. 1.1 Purpose This document, identified as the BOM Methodology Strawman (BMS) specification, captures the findings of the BOM Study Group highlighting the methodology for creating, selecting and using BOMs as building blocks in the construction of interoperable environments. The BMS is intended to facilitate rapid development and deployment of HLA federations and simulation interoperable environments using the concept of “patterns” and “components”. 1.2 Scope BOMs are an approved SISO Reference FOM distinguished by Object Model Template (OMT) classes, interactions and associated attributes, and provide a key data artifact in the federation development methodology. The BOM Methodology described in this document offers a componentized overlay to conventional HLA FOMs and SOMs without breaking the HLA paradigm. This document explores the BOM concept providing concrete examples, and describes how BOMs may be built and used to economically develop FOMs. Recommendations regarding capturing meta-data, and providing for BOM to FOM automation support are provided. 1.3 Intended Audience This document is intended for the simulation community and those individuals and organizations interested in the interoperability of systems and objects. Potential consumers of this methodology include those involved in the military (both U.S. and International) that use virtual, constructive and/or live simulations for the purpose of testing, training, analysis, and acquisition. Also, those involved in the commercial sector including education, entertainment, manufacturing, medical and other markets may also find this methodology useful in achieving interoperable environments such as Synthetic Dynamic Environments, Advanced Distanced Learning (ADL), Behavior Modeling, Multiplayer Game Worlds, and Business to Business (B2B) collaboration. 1.4 Related Documents Several specifications, documents and technical white papers provide the technical foundation for designing and developing HLA federations. These specifications are described in the following documents:

• Base Object Model (BOM) Study Group Final Report – May 2001 • HLA Rules – IEEE 1516 • HLA Interface Specification – IEEE 1516.1 • HLA Object Model Template - IEEE 1516.2 • Federation Development and Execution Process (FEDEP) - V 1.5 • Base Object Models (BOMs): Reusable Component Objects for Federation

Development - 98F-SIW-034 • Object Model Use Cases: A Mechanism for Capturing Requirements and

Supporting BOM Reuse - 99S-SIW-115 • A Structural Description of Base Object Models (BOMs) - 99S-SIW-185 • Reference FOM (RFOM) Study Group Final Report - March 1998

2. BOM Overview 2.1. Background The High Level Architecture (HLA), developed in response to the Department of Defense (DoD) Modeling and Simulation (M&S) Master Plan, facilitates interoperability among all types of models and simulations including C4I systems, and encourages the reuse of simulation components. HLA’s uniqueness from its infancy has been its object-based design. This was intended to optimize data distribution, and provide developers the flexibility to define (or refine) their own set of simulation object and interaction classes for data interchange rather than being restricted to a set of fixed Protocol Data Units (PDUs). The collection of these simulation object and interaction classes is typically identified and contained within an “interchange document” known as the Federation Object Model (FOM). The flexibility offered by FOMs allows for greater expansion of the battlespace environment as compared to HLA’s predecessors such as Distributed Interactive Simulation (DIS) and SimNet, which were restricted to a limited set of structured oriented PDUs.

Figure 2.1

Achieving this interaction flexibility, however, requires extensive design and development of FOMs among representatives for each federate. The sequence of activities recommended to build and maintain HLA federations is well described within the HLA Federation Development and Execution Process (FEDEP) model. The burden for developing and documenting FOMs has been lessened through the Object Model Template (OMT) and HLA implementation tools intended to support FOM construction. However, the task for developing FOMs can still be intricate and time consuming. It is believed that the extensive effort and compromise required in developing FOMs is one reason that the M&S community has failed to deliver more FOMs. Because of this, the concern is that the M&S community has been driving toward an “unstated but arising” restrictive FOM reuse philosophy. For instance, most middleware components are restricted to one or two de-facto FOMs. This long-term exclusive use of one or two static FOMs is severely limiting the flexibility, capacity, and capability of simulations to be able to fully reflect their intrinsic capabilities within a distributed virtual environment. Furthermore, a restrictive FOM reuse philosophy unintentionally limits HLA's capability to support a diverse range of conceptual and operational simulation domains. The BOM concept described in this document, however, provides a mechanism for building a greater number of FOMs; FOMs that accurately model (represent) the data and actions associated to the various types of systems that wish to exchange and reflect live and/or simulated data within a distributed virtual environment. 2.2. BOM Origins 2.2.1. The “Piece Part” Concept Examination of the HLA Object Model Template (OMT) document and Federation Development and Execution Process (FEDEP) model provide insight into some prospective concepts that can be used to divert the potential consequences of a restrictive FOM reuse philosophy as described in the previous section. The current OMT identifies the eXtensible Markup Language (XML) format and syntax for identifying HLA object models and their hierarchy. HLA object models are used to describe either an individual system (called a federate) through the Simulation Object Model (SOM), or used to describe a complete set of interacting federates (a federation) through the Federation Object Model (FOM). Thus, a SOM is used as a resume to describe the intrinsic capabilities of a federate, and a FOM is used as an “information model contract” between participating federates. SOM and FOMs are both characterized in terms of their objects, attributes, and parameters and it is the OMT that provides a framework for describing these elements for both FOMs, SOMs, and, as we will soon see, BOMs. According to the OMT, “the primary benefit from the common utilization of the OMT formats for FOMs and SOMs is that it provides a common frame of reference for describing object models in the HLA community. In some cases, this commonality may even allow SOM components to be integrated as “piece parts” in a

FOM, facilitating rapid FOM construction.” 16 This “piece part” concept is further elaborated in the Federation Development and Execution Process (FEDEP) document. The FEDEP model focuses on the sequence of activities recommended to build and maintain HLA federations. One of things the FEDEP document clearly states is that the “reuse and integration of existing FOM “piece parts” is the most desirable method for constructing federations”. Furthermore, it adds that FOM design and development should begin with the exploration of reusing available FOM components previously developed for different but similar federations. 2 This “piece part” component concept described in both the OMT and FEDEP documentation provided the seed that germinated the idea of the Base Object Model concept formally introduced by the Reference FOM (RFOM) Study Group in the Spring of 1998. 2.2.2 RFOM Study Group From September 1997 to March 1998, the RFOM SG worked diligently to define and identify "Reference FOMs" in the context of the needs of all SISO communities. The hope was that these RFOMs could be used to further encourage, guide and increase FOM development and use. Because of this effort, an unambiguous, capstone RFOM definition was unanimously agreed upon (see Table 2-1), and five independent models (Classes) of Reference FOMs were defined. One of the RFOM Classes identified by the RFOM SG was the BOM.

Table 2-1 Reference FOM (n) A set of HLA OMT compliant tables and associated meta-data which forms:

1. An identification of commonly used and accepted classes of objects, attributes, and interactions that have been supported by multiple federations.

2. A Federation Object Model (FOM) and use-cases that have been used to represent the structure and/or behavior of multiple federations and has gained significant approval and acceptance in the simulation community.

3. An endorsed FOM and meta-data which can be used as is or as a building block for the development and establishment of other FOMs (or public sections of SOMs).

BOMs leveraged the idea of the OMT and FEDEP concepts by placing emphasis on component reuse of FOM (and SOM) “piece parts”. These particular “piece parts”, recognized as BOMs, are defined as "a simulation component representing a single aspect of federation interplay that can be used as a building block of FOMs and SOMs.”3

NOTE: The formulation of the BOM concept can be traced to an exchange of email messages between RFOM SG members through the SISO reflector. The original email message that identified the concept of BOMs and its potential impact can be found in Appendix A.

Like a FOM or SOM, a BOM is documented as a set of the data elements required by the IEEE 1516.2 HLA Object Model Template (OMT) specification. Thus, a BOM consists of one or more classes, interactions, associated attributes, parameters and relevant parent class data (as prescribed by the OMT). Furthermore, BOMs are augmented with additional meta-data to help exploit its potential for reuse. As defined, a BOM represents a single set of Object Model data, and provides a distinct way to represent individual simulation interaction components; components that can be used to build or modify a federation. It is important to understand, however, that a BOM represents an object model set needed to represent a single aspect of simulation interplay. Whereas, a FOM (or a SOM) often represents multiple object model sets need to represent the complete collection of simulation interplay activities. BOMs provide a distinct way to represent simulation interaction and trigger components -- components that can be used to build or add to a federation. 2.2.3. Community White Papers Following the RFOM SG report, which identified the BOM concept as a promising reuse technology, several papers were written and presented at subsequent SIWs that further expanded on the BOM concept5 7 8 9 14 15. As a result of the paper presentation and community interest, BOMs were specifically identified by several groups within the SIW Outbrief Summary Report (OSP) as a potentially useful mechanism for reuse and FOM construction. Those groups included the Sensor Modeling (SENS) Forum, the Federation Development Process (PROC) Forum, the C4I Forum, and the Simulation Interoperability Through Components (SITC) forum. Based on this community interest, the SIW Conference Committee (CC) encouraged the PROC group to solicit papers and organize a special session regarding BOMs. Subsequently, it was recommended by the PROC group that a study group be formed to investigate technical and operational issues related to BOMs. At the Fall 1999 SIW the SAC and EXCOM approved the formation of a BOM Study Group (SG). The BOM SG kick-off meeting commenced at the Spring 2000 SIW with conclusion set for the Spring 2001 SIW. The focus of this study has been to provide a case for SISO BOM standardized and policy, and, through distribution of this document (the BMS), facilitate greater reuse within the HLA community.

2.2.4 Component-Based Development Although somewhat novel for HLA, what the SISO BOM SG has investigated over the course of the past year is not anything new. As illustrated in Table 2.2.4, the idea of component-based development has been a driving force of many other industries for quite sometime.

Table 2.2.4 – Examples of Component Reuse

To better understand the concept of BOMs, let us expand on the Home Construction analogy from Table 3-1. When a person sets out to buy a home (i.e., a Federation), they will either:

1. Buy an existing home (i.e., Reference FOM); or 2. Select from a book of preset floor plans (i.e. conceptual models and template

RFOMs); or 3. Generate his or her own floor plan that is either brand-new or a modification of an

existing one (i.e., build from scratch / use template FOMs). If choice (1) was selected then that individual is ready to move in (i.e., integrate and execute the FOM). If either (2) or (3) was selected then a set of sub-contractors must be located and chosen (i.e., FOM implementers) who can bring their unique knowledge into the plan to allow it to become a reality. These sub-contractors include carpenters, plumbers, electricians, and so forth. They not only bring their unique tools but also the materials and building supplies (i.e., bricks, lumber, piping, and wiring & fixtures) required to perform and to complete the job. These materials are nothing more than prebuilt, adaptable components (i.e., BOMs) used in the construction of a house or building. Imagine a house or building being constructed that required the subcontractors to make

the actual bricks or the windows, or carve out the lumber from a tree. Much like current FOM development, the task would be tiresome and extensive. However, a component-based approach simplifies and accelerates the building process. BOMs appear to provide the key to a more efficient and effective methodology for constructing FOMs, and can be supported by the FEDEP model, OMT and future HLA implementation tools. The full range of flexibility within the M&S community is needed to properly meet the demands of its users. Having ready-made FOMs for the high-end users (as we currently have) and BOMs for the do-it-yourself users and developers allows HLA to be effectively applied throughout the entire M&S community. The impact of this approach can be best understood by comparing the impact component-based development has had on other markets such as software development, electronics engineering, and home construction. In short, these markets have been revolutionized by the component-based approach. The BOM methodology potentially offers a similar impact for the M&S interoperability community.

3. Potential Impact The idea of component-based development in the world of HLA can be realized though the BOM methodology. BOMs are reuseable patterns and components representing threads of simulation interplay useful for constructing a interoperable environments. BOMs have the potential to reduce the time and effort associated to FOM and SOM construction. Therefore, the design and development of “interoperable environments” should begin with the exploration of reusing available simulation object model components. The BOM methodology supports this premise by encouraging simulation interoperability through component reuse. The potential impact of this methodology includes an increase in FOM flexibility, and a simplification of interoperability. In addition, the BOM methodology allows HLA to reach broader domains and markets including Entertainment and Gaming, Advanced Distance Learning, Medical and Biotechnology, and Manufacturing.

3.1 Next Generation Interoperability If next generation FOMs and SOMs were to be built based on BOMs, then the modeling and simulation community might discover the following outcomes:

• Systems (federates) can integrate more rapidly to various number of FOMs, and • HLA middleware will be able to support a broader selection of FOMs.

The following subsections provide further detail as to how the two aforementioned outcomes are accomplished yielding an increase in FOM flexibility and a simplification of interoperability. 3.1.1 Rapid Federate Integration The first outcome is accomplished by applying the concept of component level mapping

between the common “patterns” associated to a federate’s SOM and the FOM that represents the federation the federate wishes to join. This concept of mapping is similar to the Agile FOM and Adaptable Federate concepts described in other SIW papers. However, the difference is that in this case the ability of the participating federate to conform to a FOM is directly linked to the OMT “components” used to compose the SOM and FOM. Therefore, the goal in this type of mapping is to identify the similar “patterns” between the SOM and the FOM. Accomplishing this goal is trivial if the SOM and FOM were constructed using BOMs. 3.1.2 Multi-FOM Middleware To fully understand the second benefit, it is important to investigate the current limitations of HLA middleware. Historically, HLA middleware has often been limited to a specific FOM – most notably the RPR FOM. Although this has served its purpose in allowing legacy and DIS systems to “play HLA”, a single FOM approach restricts a middleware-dependent systems (federates) in its ability to connect and participate in non RPR-FOM type federations.

It is often forgotten that HLA compliancy is dependent upon a designated, agreed upon FOM as well as a designated, agreed upon RTI by all federates within a federation. It is this FOM dependency that identifies true compliancy and provides the ability for multiple systems (federates) to interoperate. However, if next-generation FOMs were constructed based on common known BOM components, a myriad of FOMs representing different capabilities could potentially be produced and configured efficiently and rapidly. Consider that with this approach future middleware systems would be able to be configured dynamically, even to an unknown FOM, based on a known set of BOMs. This concept is analogous to the concept of Legos™. Consider that with Legos a child can build an infinite number of structures based on a limited, known quantity of blocks. Each of these structures appears to be different, reflecting a different model even though the components (blocks) used to build the structure are identical. The structures a child builds is characteristic of a next generation FOM, whereas the Lego™ blocks are characteristic of BOMs. It bears repeating then that if next generation FOMs and SOMs were to be built based on BOMs then we will ultimately find it even easier for middleware to be able to dynamically support a broader selection of FOMs. 3.2 New Interoperability Landscapes BOMs can be used to support a wide variety of interoperability environments that are not necessarily specific to the HLA community. Within the larger simulation community,

which includes those within and outside of the constituency the HLA community has typically supported, BOMs represent “A single aspect of simulation interplay that can be used as a building block in the construction of Interoperable Environments.” These BOM building blocks may very well have more impact on the simulation industry economically and creatively than they do technically. BOMs can be seen as the key to transferring the use of interoperability simulation standards to other industry applications and more importantly to the consumer media market (the mass market). Presently, HLA is most widely used as a military training and testing tool, but it also has potential value as a tool to the commercial industry. As simulation technology becomes more accessible to the consumer markets (ala video games and distributed learning environments), simulation will gain its biggest impact as a communication medium. Simulation standards will have as much of a dramatic effect on communications as did standards of printing, recording, telecommunications and broadcast technology. In order for standards to ultimately survive the test of time, it will eventually need to service the expansive and diverse mass consumer media market. This market is valued into the trillions of dollars annually worldwide and will forge the new economic models for the simulation industry. 3.2.1 Transforming Simulation Into the Next Media Revolution From telling stories of the prehistoric hunt to sharing the immediacy of “history in the making” with CNN, media allows us to communicate the experience of humanity. Simulation will have the ability not just to distribute a limited and passive audio/visual view of the experience, but it will also offer the ability to provide duplication of the experience itself with multi-modal, interactive, immersive experiences in large-scale worldwide networked virtual environments. This experience-based medium will revolutionize media. In sparking that revolution, simulation standards will have even more dramatic results then did the standards of moveable type had with the printing industry; the recording of artistic performance had with motion pictures; and the immediate broadcast of multimedia has had with radio and television. Therefore, simulation standards for consumer use will need to be even more dynamic and interoperable. BOMs provide the critical and obvious development conduit by breaking down the units of virtual environments into smaller and more dynamically interchangeable objects. 3.2.2 Application of BOMs in Experiential Consumer Markets In media markets, content is king. FOMs, SOMs and BOMs become the creative commodity that fuels the information, entertainment and education media industries. The flexibility and adaptability of this content is essential to increase productivity and efficiency as well as a way to open subsequent markets for the reuse of content. BOMs become the basic currency or building blocks to create and deliver media content. The BOM approach, however, cannot be solely developed in the limited application of

military training and testing. Simulations and BOMs offer a completely new layer of content transferability and market potential. Whereas, in today’s video game markets, for example, content is created similar to rigid SIMNET systems. Like the monolithic FOM approach described earlier, a video game’s limited and exclusive content minimizes the potential for it to penetrate a wider share of the consumer market. BOMs, however, will be able to offer an infinite array of content such as virtual characters, fantasy vehicles, cyber-merchandise that is of greater use to a wider audience. Ultimately, BOMs will become independent commodities. This phenomenon is already occurring on Ebay with the auctioning of virtual RPG characters. BOMs represent the unique form of virtual content that will help define Experiential Consumer Media standards. The most important improvement BOMs would provide to the Experiential Consumer Media market is that it would increase productivity and efficiency regarding the production and delivery of content. Currently, highly exclusive standards are employed with little interoperability. However, the production of a diverse set of BOMs would allow the development and delivery of Experiential Consumer Media much like a television movie, but without the passiveness. Without having to reinvent the wheel with proprietary graphic engines and assets, new genres and applications can be discovered which will open new markets for simulation. 3.2.3 Commercial Market Potential Technological innovation has made possible a phenomenal growth of media in the last hundred years. Optical, mechanical and electronic media has remained mostly passive and non-interactive. Through the means of Internet systems, high-bandwidth communications and simulation technologies, simulation can become ubiquitous within our culture. As a result, simulation technology will dramatically transform media from passive entertainment to real-time, interactive, experience-based immersion (three dimensional and multi-modal). Compared to the familiar world of military training and testing, the consumer media market is an entirely separate, yet appropriate application domain for simulation interoperability. This market brings with it entirely different requirements and limitations that will need to be considered in the evolution of BOM standards. The rapid expansion in the use of Experiential Consumer Media will be possible through the increase of high-bandwidth telecommunication lines being installed within public and private facilities. The Internet has shown us that these new markets will have easier access than did the channels of passive media. The largest challenge to this highly lucrative application domain is that users will demand the highest level of fidelity, capacity, efficiency and robustness, and yet the actual users are mostly untrained, inexperienced, highly regulated, unsupervised, demanding and often challenged educationally. The use of BOMs will allow the maximum ability to keep up with market demands and trends in simulation products.

As in the past, the consumer media market, being so large, tends to become the 800-pound gorilla that drives the acceptance of standards. The use of BOMs within the consumer market can lead a transformation of a billion-dollar MS&T industry to a trillion-dollar Consumer Media market through experiential digital media. It can also help forge the future of HLA standards.

4. The Federation Development and Execution Process (FEDEP) The Federation Development and Execution Process (FEDEP) describes the activities involved in HLA federate and federation development and execution. In order to fully understand the basics of the BOM methodology, it is important to first understand the major activities described by the FEDEP model.

Figure 4.1 - FEDEP 6 Step Process The FEDEP model provides a hi-level, adaptable process for creating, maintaining and executing a federation. The key activities for each step is describe below: 2

1. The federation sponsor and federation development team must define and agree on a set of objectives, and document the accomplishments for achieving those objectives.

2. A representation of the real world domain of interest (entities and tasks) is developed, and described in terms of a set of required objects and interactions.

3. Federation participants are determined (if not previously identified) and required functionalities are allocated to the federates.

4. The Federation Object Model (FOM) is developed, federate agreements on consistent databases/algorithms are established, and modifications to federates are implemented (as required).

5. All necessary federation implementation activities are performed and testing is conducted to ensure that interoperability requirements are being met.

6. The federation is executed, outputs generated and analyzed, and feedback provided to the federation sponsor.

The FEDEP is intended to guide HLA federation engineers through the common life-cycle elements of a federation. This guide is also useful in choosing and selecting the automation tools needed to support federation development from start to finish. The following table provides a listing of the major elements associated to these FEDEP steps.

Table 4.1 FEDEP Elements

It is important to draw attention to each of one of these FEDEP Steps. The component-based development approach that is described in this document emphasizes a greater significance and direction regarding the activities associated to FEDEP Steps 1 and 2, the focus being on capturing and using functional requirement meta-data. Consequently, the activities associated to Steps 3 and 4, which focus on FOM design and development, can be greatly reduced and achieved more rapidly and efficiently through this component-based approach and requirements focus. Furthermore, the component-based approach and requirements focus allows for the successful achievement of the activities associated in Step 5 and 6. To fully understand the merit of the component-based approach, it is important to examine each of the major federation engineering approaches supported by the FEDEP as identified below: 6

• The Bottom-Up Approach • The Single SOM/Merge SOM Approach • Existing/Reference FOM Approach • BOM Integration Approach

4.1 The Bottom-Up Approach Clearly, the FEDEP provides the details and efforts required to create SOMs and FOMs from scratch. This approach is often referred to as the Bottom-Up Approach for federation development. The Bottom-Up approach supports the capability to create FOMs that may later become Reference FOMs, since meta-data is captured and documented during the Requirements Stage (FEDEP Steps One and Two). The associated federation meta-data is an important requirement for Reference FOM consideration. The Bottom-Up Approach requires an extensive amount of time and effort for federation development, and is the most common method for developing federations in HLA.

4.2 The Single SOM/Merge SOM Approach The FEDEP also supports the capability for a single SOM or the merging of multiple SOMs to be used initially as a template for creating FOMs. This approach is commonly referred to as the Single SOM / Merge SOM Approach. Although this approach can reduce federation development time, (relative to the Bottom-Up Approach), meta-data from the template SOM(s) typically does not exist or is difficult to migrate into the FOM being constructed. This often results in the bypass of the Requirements Stage of the FEDEP (Steps One and Two). Additionally, the Merge SOM aspect, which is a common approach, requires extensive collaboration between federate representatives and usually results in federate redesign or compromise among federation engineers concerning FEDEP goals.

4.3 Existing/Reference FOM Template Approach An arguably better approach over the Single SOM / Merge SOM approach that is supported by the FEDEP is to include a pre-existing FOM or Reference FOM(s) as a template for creating new FOMs. However, building a new FOM (or SOM) based on a pre-existing FOM may also inhibit the ability to migrate meta-data, again causing a by-pass of FEDEP Steps One and Two. The exception is if the template FOM is an official “Reference FOM”, which would include the existence of meta-data. Meta-data, again, allows for greater automation, allowing elements of the source FOM to be more easily selected. Otherwise, this approach, like the Single SOM / Merge SOM approach, would require careful and meticulous selection and extraction of FOM pieces in the construction of a new federation. This is a time consuming task. Furthermore, even complete reuse of a FOM does not remove the potential need to update, modify, and reengineer the new FOM, since data collection and DDM usually imply that parts of every FOM will be FEDEX specific.

4.4 BOM Integration Approach Because of its flexibility, the FEDEP also allows a federation engineer to produce, use and store “piece parts” as simulation components during the federation development process. These simulation components are identified within this document as Base Object Models (BOMs). During the Requirements Stage (FEDEP Steps One and Two), each key federation objective is captured; this is the core object model meta-data. The collection of these requirements are identified as a Blueprint. The blueprint forms the basis for the conceptual model and can be used to drive incremental and component-based construction of the FOM or SOM.

NOTE: One mechanism recommended for capturing functional requirements and establishing conceptual models is the Use Case methodology borrowed from the Object Oriented Software Engineering world. This methodology is described in further detail in Appendix B.

During the design aspect of the Construction Stage (FEDEP Steps Three and Four), the federation engineer may use the requirements data (captured in FEDEP Steps One and Two) to perform a meta-data match with existing BOMs. If a BOM exists, that helps to satisfy a requirement of the FOM or SOM being developed or updated, then it can be integrated into the FOM or SOM. If there is no satisfying BOM and if the federation engineer is developing a thread or aspect of “federation interplay”, which is the nature of simulation components and BOMs, then a new BOM can be developed and saved for future reuse. In addition to object model meta-data matching, functional requirements provide a basis for testing and validation. This requirements traceability can be used to facilitate FEDEP automation. We will explain more of the BOM Approach in greater detail in the sections that follow. 5. BOM Architecture Elements The most basic characteristic of the BOM architecture is that it is based on the Object Model Template (OMT). Like a FOM or a SOM, a BOM is distinguished by one or more object classes, interactions and associated attributes (in accordance with the OMT). In fact, a BOM looks and acts like a mini-FOM except that it is augmented with additional meta-data (such as requirements, conceptual model data, and use history). The key concept is that a BOM is a “thread” of simulation interoperability. It is not simply an object class piece or specific attribute, it is a complete model of a simulation interplay activity. 5.1 BOM Types There are two types of BOMs that have been recognized by the BOM SG which identify various types of simulation interplay:

• Interaction BOMs and • Trigger BOMs (formerly called Attribute/Update).

5.1.1 Interaction BOMs An Interaction BOM is represented by an interaction class and any associated object classes that are linked by the interaction class. When two or more objects classes (e.g. entities) can affect one another through the instance of an interaction, then this represents an aspect of “simulation interplay”. An example would be a radio transmission, which is an interaction that requires a radio to initiate the transmission and one or more radios to receive the transmission.

NOTE: The current version of the OMT does not provide the capability to associate object classes to an interaction class. This feature, however, was once supported in version 1.1 of the OMT.

If multiple object classes are knowledgeable of an interaction class, then they can be classified together as an Interaction BOM. However, if only one party of multiple objects care about an interaction (or) care the attributes of the other object (and it’s not reciprocal) that these objects cannot be classified within an Interaction BOM. Instead, they can be classified as a Trigger BOM as described in the next section. 5.1.2 Trigger BOMs A Trigger BOM is an object class that either through it is presence or possession of at least one changed attribute elicits a response from one or more other object classes. The idea is that when the condition (state) of an object that is of interest to other objects within a virtual environment has changed, then a response may occur by one or more objects. Originally, this type of BOM was identified as an Attribute Update/Response BOM. However, the term Trigger was found to be more appropriate. Within a virtual world such as depicted within a video game, there can be many types of triggers such as Traps, Exploding Boxes, Breakable Crates, Elevator Switches, and Guard Dogs that are angered by an entity presence (location attribute change). The concept of a Trigger BOM is not too much different from an Interaction BOM as described above, however, there is a slight difference. Interaction BOMs are distinct because the objects associated to the interaction are both knowledgeable of the interaction. For instance, one object might be associated to the generation of the interaction and the other object might be associated to the reception of the interaction. Trigger BOMs do not have that advantage. Only one object knows and/or cares about the other when the condition / response occurs. Typically a trigger occurs when either

• an object attribute has been updated, or • an object action or indirect interaction with an other object has occurred.

5.1.2.1 Object Attribute Update The best example to understand the object attribute update condition is the concept of the wall clock within a restaurant (see Figure 5.1.2.1). If an employee is scheduled to work the 9 to 5 shift, and the clock begins to near the 5 o’clock hour, the employee may begin to monitor the clock waiting for his shift to end. Once the minute and hour attributes of time are updated to 5 o’clock, the employee might immediately clock-out and leave. This is a form of Trigger, in which one or more attributes of an object change, eliciting a response from another object. The clock, of course, has no knowledge of the employee, but the employee might certainly have knowledge of the clock. Therefore, it is important to associate the clock object (and its attributes) as a Trigger element of the employee object.

Figure 5.1.2.1

5.1.2.2 Discreet Object-To-Object Interaction Although interactions can be formally identified in the OMT of a FOM, SOM or BOM as an Interaction Class as discussed earlier, there can be some interactions that occur in which objects affect other objects that are not explicitly identified as an Interaction class. For example, if an individual nears a motion detector for a door, the person either knowingly or unknowingly has triggered the activation of the motion sensor once he crosses its path. In this case, the BOM consists of a Motion Sensor Object, and, associated to it is a trigger element, which is an abstract class that represents a mobile object such as a person, animal, or vehicle. In this case, the concern is not so much about the attributes of the trigger object, but simply the presence of the trigger object. The Motion Sensor Object might react to the presence of the mobile object once it is in its field of view (this is the trigger) by sending a message to the door to open. This next of level on interplay between the sensor and the door may very well be embodied in an Interaction BOM since both objects (the sensor and the door) care about the interaction (see Interaction BOM). Nevertheless, it is the earlier state between the Sensor and the Mobile Object that illustrates an example of a Trigger BOM.

5.2 BOM Categories In addition to these types, there are two categories of BOMs that have been identified to help facilitate simulation interoperability:

• Interface (IF) BOMs and • Encapsulated (ECAP) BOMs.

NOTE: These types and categories are independent of each other. In other words, an Interaction type BOM can be represented either by an IF or ECAP BOM. Likewise, a Trigger type BOM can also be represented either an IF or ECAP BOM.

5.2.1 Background The pursuit of reuse has been a goal of the software development community for quite sometime. The simulation community also has had this objective since the introduction of HLA. Theoretically, reuse allows the efforts of design and development to be succinct and efficient, and ultimately the execution and deployment effort to be more successful. In an attempt to achieve and optimize reuse, object-oriented technologists have come up with two similar yet distinct approaches that have tremendous merit and application. One concept is to find and apply “patterns” of an architecture or system to support the analysis and design effort. The other concept is to use “components” in the construction effort. All though these two ideas seem similar, there is a slight difference. According to Martin Fowler, a well-regarding OO technologist, a Pattern is “an idea that has been useful in one practical context and will probably be useful in others.”17 The “component reuse” concept may be more familiar to the greater community. Components are, in essence, pre-built elements that encapsulate the modeling and behavior (methods) of the class(es) that are being represented. These components can be used or inherited “many times, either within the same system or in various systems, without modification of the original component.” These two approaches can both been applied to the BOM methodology through two distinct categories: Interface BOMs and Encapsulated BOMs. The idea of “patterns” can easily be applied to the Interface (IF) BOM category by default of the OMT representation. The idea of “component reuse”, on the other hand, is applied strictly to the Encapsulated (ECAP) BOM category. Both IF and ECAP BOMs are further explored and discussed in following subsections.

5.2.2 IF BOMs An Interface (IF) BOM, represents a “pattern of interoperability” contained within a FOM or a SOM that can be inherited within other FOMs or SOMs. IF BOMs are distinguished by one or more object classes, interactions and associated attributes (in accordance with the Object Model Template). IF BOMS are also augmented with additional meta-data such as requirements, conceptual model data, and use history. Any internal implementation defining how an IF BOM behaves, however, is not provided (contained) within the IF BOM meta-data. The OMT reflects "design elements" more so than "implementation elements", and is used exclusively to represent FOMs and SOMs. Because of this, IF BOMs are the most natural type of BOM to create and use. 5.2.3 ECAP BOMs An Encapsulated (ECAP) BOM, represents a “component” of a federate or federation that can be leveraged within other federates and federations. It is important to identify what type of data is going to be represented. The type of data is the “interface” to an ECAP BOM, and like an IF BOM, this “interface” is distinguished by one or more object classes, interactions and associated attributes in accordance with the OMT. Also, like IF BOMs, ECAP BOMs are augmented with additional meta-data such as requirements, conceptual model data, and use history. However, the internal “implementation” defining the behavioral elements of the BOM is encapsulated outside of the OMT interface . Behavioral elements can be most likely represented within a separate XML document supporting language independence, which is parse-able by participating federates. The ECAP BOM, therefore, shares how data elements will behave and react; it provides the internal model.

NOTE: The OMT (IEEE 1516) provides the interface syntax used to represent the exposed functionality of the BOM (whether it be an IF BOM or ECAP BOM). For more understanding of the OMT and how it is currently used to support documenting a FOM or SOM, it is encouraged that the OMT 1516.2 specification be examined.

5.3 Meta-Data The meta-data associated to BOMs provide missing elements not currently captured with FOM and SOM data. Meta-data is an important artifact and enabler of reuse and can be comprised of many elements including:

• Requirements • Conceptual Model • Accreditation Information (VVA)

• Intended Domain and Scope • Integration Experience

• Process • Products • Lessons Learned • How it was used (Use History)

• Revision History • Graphics

• 2d/3d Models • Textures • Key Frames • Multi-damage States

• Other Stuff

• Sequence Diagrams • Scenario Application

One of the key meta-data components identified above is requirements meta-data. This meta-data describes the purpose, intent and origin of a BOM. Requirements meta-data allows BOMs not only to be more easily understood, but also easier to find, select and apply. In regards to the FEDEP, it contains the key objectives and “real world domain of interests (entities and tasks)” which is useful for discovery, matching and integrating BOMs into a federation. The important thing about meta-data, whether the meta-data is function requirements or revision history, is that it provides a key data artifact enabling automation within an incremental federation development process.

NOTE: Some of the early BOM papers written and presented at the SISO Interoperability Workshop, 99S-SIW-115 and 99F-SIW-112, focused on the concept of Use Cases to capture the necessary requirements meta-data and to formulate the bases of the conceptual model meta-data 8 10. The BOM SG has found merit in this approach and the Use Case concept. The Use Case concept based on these two early papers are shared and described in Appendix B.

5.4 OMT Interface Specification The OMT (IEEE 1516) provides the foundation for the “interface”. The interface represents the exposed functionality (and design) of the BOM (whether it be an IF BOM or ECAP BOM). In order to understand how to capture and represent a BOM it is important to understand the OMT specification. One of the key things about the OMT is that it is BOM neutral. Even though BOMs not specifically mentioned in the OMT, IF BOMs can be supported. The neutrality allows three levels of “validity” within the OMT.

• Well-formed • Valid with respect to the OMT DIF DTD • Complete and consistent with respect to the OMT description

One of the tables provided in the 1516.2 specification is the Object Model Identification Table (see Table 5.4). The “Other” field within this table could be used to capture additional meta-data required for BOMs.

Table 5.4

One of the tricks that can be considered for meta-data and other BOM extensions is to define an adjunct XML schema and allow the "Other" field to contain (as a subset) the data formatted to this adjunct XML schema. The idea is to deposit an XML document with in a parent XML document. The parent XML document in this case would be an OMT formatted BOM document. The other idea is to reference the adjunct XML document using the Reference field. Since XML supports hyperlinks, the other option is to hyperlink (rather than embed) to another XML document. Ultimately, an OMT Schema (rather than a DTD) should be defined for the OMT. An

OMT Schema would allow further extensions and expansion of an OMT-based doc (i.e. BOM) allowing it support and contain the various forms of meta-data needed to further reuse. 5.5 Behavior Implementation This section applies only to ECAP BOMs. The internal implementation defining the behavioral elements of an ECAP BOM must be encapsulated within an exchangeable document associated to the BOM’s interface (design) document. Since an XML document supports language independence, the OMT (schema) can be either extended to include the encapsulated data, or an adjunct XML document can be created separately containing this encapsulated data, which is linked and independent from the OMT-type interface file. In either case, the behavior implementation is parse-able by participating federates due to it’s XML construct. Unfortunately, a specific XML format has not yet been designated for encapsulating behavior for ECAP BOMs by the BOM SG. In addition to investigating the use of XML for capturing behavior, additional independent languages such as Python, Java, and Java Script are also viable and should be researched as another potential platform independent method for capturing and reflecting behavior for an ECAP BOM. 6. BOM Development Approaches In view of the current development approaches (section 4), one can easily surmise that there is no effort-free solution to FOM reuse. However, suppose a different method was adopted for the development of federations. Rather than constructing FOMs from scratch or from the extraction/merging of pre-existing SOMs, and/or FOMs, consider constructing FOMs from prebuilt, reusable components -- components that represent a “single aspect of federation interplay that could be used as a building block of FOMs and SOMs” [3].

NOTE: This section describes many of the issues that need to be addressed in the development of a BOM. This section is oriented more to the developer of BOMs. For those individuals who wish to simply use BOMs, you may wish to skip to the next section.

There are two basic approaches for developing BOMs:

1. the process of extracting “patterns” of interplay from an existing FOM or SOM can take place, or

2. a BOM can be built from scratch. No matter which development approach is taken, the BOM must be supplemented with requirements meta-data that allows it to be re-used.

6.1 Requirements Meta-Data Before diving in and creating a BOM, the key functional requirement associated to a BOM should be captured and documented during the Requirements Stage (FEDEP Steps One and Two). These FEDEP activities produce the core requirement meta-data that is needed to allow the BOM to be re-used by other individuals and organizations. When developing a BOM, especially at the Requirements level, the developer should focus on capturing a “single aspect or thread of simulation interplay” and then identify the intent of that interplay. The Use Case concept described in Appendix A provides a useful mechanism for documenting this intent. 6.2 Type Selection It is also important to decide on the type of BOM you choose to have. The choices are an Interaction-based BOM or a Trigger-based BOM, and the decision often depends on the requirement and scope (see Figure 6-1).

Figure 6-1

6.2.1 Interaction-based BOM As described, earlier one of the most straightforward approaches for constructing a BOM is to extract an interaction from an existing FOM or SOM. The tentacles attached to the interaction as it is being pulled will include the associated objects, attributes and meta-data (see Figure 6-2). The result is an identifiable aspect of simulation interplay.

Figure 6-2

The key in performing this type of decomposition is to already have identified any associated objects (and meta-data) of a single interaction. This object-to-interaction association was a template feature supported previously in OMT 1.1, and is not supported in the most recent versions of the OMT (including 1516.2). However, there are ways to include this information as either OMT extension or through an adjunct OMT file. (See section 5.4 for more information). As a simple example, this concept of an Interaction-based BOM works well for a Radio Transmission, for example, in which a radio signal is the interaction, and the receiving and sending radio types are linked to that interaction. The pattern of simulation interplay includes this one interaction and each of the object classes plus attribute types associated to the interaction. To understand the BOM concept more clearly, a detailed illustration may be helpful: The infamous Restaurant FOM is a frequent example used to understand the OMT documentation and object hierarchy of a FOM. It also illustrates how BOMs can be derived (extracted). Those BOMs can be used to build various other types of “Customer Oriented Business” FOMs. The Restaurant FOM contains several objects and interactions commonly associated to supporting the restaurant business. Suppose the Restaurant FOM in common circulation was modified slightly to resemble the following high-level format:

In order to select “piece parts” from a FOM to build BOM components, it is recommend, in this example, that the Interaction-based BOM Development Approach be considered for the decomposition of the FOM. Consider that the original Object Interaction Table (supported in OMT version 1.1), provided the ability to identify any and all objects associated to the interaction. Unfortunately, this is not supported in the current OMT 1516 specification. However, if the effort of linking object and interactions were performed (and somehow stored as an extension of the OMT), then the objects and attributes tied to an interaction would represent a single aspect of federation interplay. Therefore, a simulation component contained in a FOM is most easily extracted when lifted from the FOM by the interaction class. Attached with the interaction are the associated object classes, attributes and relevant meta-data, if available (see Figure 6-2). Based on this Interaction-based BOM Development Approach, the following preliminary BOMs can be created from the hypothetical Restaurant FOM:

Closer examination reveals that the “Goods Delivered To Customer BOM” and the “Task Completed For Customer BOM” are very similar in regards to the objects involved. Thus, a more abstract BOM could be generated. The merits of abstraction are discussed in section 6.3. BOMs are the building blocks that enable federation engineers to design component-based federations. These example Interaction BOMs illustrate simulation components that can be reused to support efficient and rapid construction of FOMs such as an Auto Lube FOM, a Flower Shop FOM, or Pizza Delivery FOM.

6.2.2 Trigger-based BOM In the long run, however, Trigger BOMs play a more realistic cause and affect role often associated to simulation events. The reason is that triggers are a more authentic aspect of reality; an object, for example, is not always aware that its presence or a change in one of its attribute may affect the behavior of another object. Incidentally, this behavior can be captured, modeled and encapsulated within an ECAP BOM if desired.

NOTE: This type of trigger modeling is often used to convey physics, Artificial Intelligence (AI), and human behavior within modern computer games, providing a synthetic virtual environment a greater of breadth of dynamic game play.

The Breaktime BOM example described in Section 5.1.2 provides a simple example of a Trigger BOM. Most trigger BOMs are easiest to from scratch, although they can be decomposed from an existing FOM. The key is to identify the attribute updates of a BOM that impact (cause a reaction) of other objects during a Federation Execution. 6.3 Category Selection One of the key decisions to be made is deciding the breadth of the BOM (see Table 6-1). Will it be an IF BOM or an ECAP BOM? Obviously, IF BOMs are easiest since they strictly represent design issues based on the OMT. The implementation of how an IF BOM is represented and modeled (i.e. Behavior), however, is the responsibility of each federate. The ECAP BOM, however, goes well beyond the IF BOM; it provides a formal mechanism to attach behavioral modeling elements within a platform-independent language file such as an XML document. The XML Schema for this approach is something that still needs to be worked out and standardized within the community. The issue is determining how to capture behavioral elements in XML. Other choices in addition to XML, include Python, Java, and JavaScript, which are all robust, platform independent languages.

Table 6-1

6.4 Level of Tangibility Another important issue in building a BOM is deciding upon the level of tangibility, which has to due with the relation of abstraction versus inheritance (see Figure 6-3). Will the BOM be specific to one particular type of simulation interplay thread (concrete), or will it be robust by scaling it back to support multiple forms of a particular simulation interplay thread (abstract)? Therefore, BOMs can range anywhere from being a Concrete BOM or an Abstract BOM.

Figure 6-4 Abstraction –vs- Inheritance

6.4.1 Concrete BOMs A Concrete BOM can almost be used as is, with little modification or inheritance needed -- just plug it in. The disadvantage, however, is that Concrete BOMs are restricted to a specific interplay requirements and therefore are less likely to be reused. 6.4.2 Abstract BOMs By scaling the details back, making it more Abstract, the BOM can be inherited and used more frequently by a greater number of implementers. However, the drawback is that implementation of an abstract BOM will require a larger degree of inheritance to support specific federate user’s needs. The advantage is that this works just like object-oriented software development in the implementation and inheritance classes -- although not necessarily more easily. Abstraction is desirable, but keep in mind that abstract BOMs will require greater adjustment to suit specific needs and causes ECAP BOMs to provide and support greater behavioral modeling meta-data. 6.5 Distribution Issues The most practical way to encourage the reuse of BOMs is to provide a mechanism for distribution. The following SISO BOM Standardization Pipeline has been identified by the BOM SG to assist in BOM distribution. SISO BOM Component Standardization Pipeline:

1. Create a BOM 2. Test and Verify BOM (use it) 3. Submit BOM (with meta-data) to resource repository 4. Make BOM available to public via web 5. Gather Use history as it’s being used

Have user’s rate BOM (aka Amazon.com) 6. Once BOM reaches specific a quantity/quality rate, it can achieve official SISO

endorsement status.

6.5.1 Resource Repository As shown in the pipeline, resources include the necessity for a repository that would contain publicly available BOM components developed by various developers and organizations. Currently, libraries that can support BOMs are not available, which raises the issue as to where or when can BOMs be submitted and obtained from an online repository. The BOM SG anticipates repositories will eventually be available. Currently the forthcoming HLA Object Model Resource Center (OMRC) is compatible with the BOM concept. The OMRC is scheduled to replace the HLA Object Model Library (OML) and HLA Object Model Data Dictionary System(OMDD). It is quite possible that the OMRC could provide the online warehouse for BOMs. This repository will need to provide the following capabilities.

• A mechanism to upload and download BOMs. • A mechanism to add use history (as meta-data) to available BOMs within the

repository in order to encourage further usage of BOMs. • A search engine based on the requirements and use history meta-data.

As BOMs are used and exercised by various federates, use history meta-data should also be appended to the BOM and provided back to the repository where the BOM was attained. The search engine would serve as a useful mechanism for federation engineers to match and find applicable BOMs for their federation development or maintenance effort (based on their requirements). 6.5.2 BOM Tools Finding OMT tools that know how to reflect a BOM so that it can be either built or used is a current deficiency that the BOM SG group anticipates will also be resolved in the near future. Existing tools should support the OMT aspect of a BOM even though it may not provide the appropriate meta-data (for both IF and ECAP BOMs) and XML behavior modeling support (for ECAP BOMs). Tools should evolve to support these capabilities. 7. BOM Reuse Considerations The real winners of BOMs are ultimately the users, however it is important that BOMs are used appropriately and can be easily selected. Otherwise, without guidelines, BOMs could add more complexities and difficulties to the Federation Development Process. The bottom line is knowing how to select and reuse a BOM in the construction of an interoperable environment. NOTE: This section describes many of the issues that need to be addressed or resolved before attempting to select and use a BOM. This section is oriented toward the potential end-user of BOMs. 7.1 Key Approaches There are two key approaches for using BOMs as illustrated in the following table:

• Clean Sheet Federation Development • Second Addition Federation Development

The Clean Sheet Federation Development approach is building a FOM or SOM from scratch using BOMs as add-in components. The Second Addition Federation Development approach is simply using BOMs to supplement an existing FOM. The proceeding table illustrates the summary efforts required for each of these two reuse approaches.

Table 7-1 BOM Reuse Approaches

It is important to note that these two approaches are often contingent upon access to proper tools and BOM repositories, and understanding the importance of requirements meta-data. 7.2 Requirements Meta-data The most important element for either one of the reuse approaches is to “know what you’re looking for”. Never underestimate the importance of the requirements meta-data. Requirements meta-data is important for both the FOM being built and for the BOM being selected. Therefore, when developing a next generation FOM or adding to an existing FOM, the activities associated to FEDEP Steps One and Two should not be dismissed. These two steps facilitate the capturing and documentation of the requirements meta-data and provide the basis for the conceptual model. The collection of functional requirements, identified as a Blueprint, can be used to drive incremental and component-based construction of the FOM or SOM. This Blueprint facilitates traceability and federation development automation for FEDEP Steps Three through Six (see Figure 7.1).

Figure 7.1 Blueprint Centric FEDEP Approach

During the design aspect of the Construction Stage (FEDEP Step Three and Four), the federation engineer can use the functional requirement data to perform a “meta-data match” with existing BOMs.

NOTE: Theoretically, BOMs can be located simply by searching through each BOM’s meta-data until a match is made; this is called meta-data matching. Meta-data matching, however, is always contingent on knowing the requirements for the FOM in construction. One emerging technology that could potentially be used to support meta-data matching is the XML Query language proposed by W3C.

If a BOM exists that helps to satisfy a requirement of the FOM/SOM being developed or updated, then it can be integrated into the FOM/SOM (see Figure 7.2). If there is no satisfying BOM and if the federation engineer is developing “aspects of federation interplay”, which is the nature of simulation components and BOMs, then a new BOM can be developed and saved for future reuse (see section 6).

Figure 7.2 7. 3 Skeleton Design Approach

Figure 7.3

It is also a good idea to create (or add to) a FOM with a skeleton design approach (see Figure 7.3). This sometimes allows prebuilt BOMs to be located that match with the framework element of a FOM under design. When unique threads of interoperability are identified from that skeleton design, the prospect of incorporating a particular BOM can be realized. If a BOM does not exist, it creates an opportunity to build a BOM at that moment (see Figure 7.2). Future FOM/SOM developers will then be able to reuse the BOM later. The Skeleton Design Approach also encourages incremental and iterative FEDEP development.

7.4 Types of Reuse In an ideal world, users of BOMs will hope to find BOMs that can be used “as is”. These are “concrete” BOMs, independent of type or category, which provides almost the complete capability necessary to support the interoperability requirement for the FOM developer. Most BOMs, however, must be inherited due to the level of “abstraction” performed on the BOM during its creation. If a “concrete” BOM cannot be found, which might often be the case, it is important to keep in mind that once an “abstract” BOM is included into a FOM, it can be inherited. Inheritance allows a BOM to be expanded and customized for a particular FOM need. It is anticipated that a majority of BOMs will require some level of inheritance. Finally, when an ECAP BOM is selected, be sure to maximize its capability by transitioning (making available) the behavior modeling contained within the BOMs XML meta-data to the federate. One of the benefits of XML is that it allows data to be shared and accessed independent of language or platform. As a result, this access can be performed dynamically at run-time without modification to federate code. Languages such as Python, Java and JavaScript provide this capability as well.

7.5 History and Feedback Part of making BOMs useful to others is hinged upon use history. It is imperative that as BOMs are used and applied in the construction or modification of FOMs and SOMs, the history regarding its use (and success) is feedback to the BOM development community. This feedback involves sharing the integration experience in the form of BOM meta-data. Like requirements meta-data, history meta-data allows BOMs to be more easily found and used during FOM development. The most likely method to convey history meta-data the community is to simply provide formal structured comments to the on-line repository where the BOM was retrieved. This somewhat analogous to the reader comments that web sites such as Amazon.com provides for potential customers of books and records. 8. Summary The BOM methodology provides an appropriate building block mechanism not only useful for HLA federation development, but also for other markets such as Advanced Distanced Learning and Experiential Consumer Media. BOMs are a promising

simulation technology that will encourage greater abundance of interoperability and content usability across a wider breadth of domains. The HLA community is encouraged to consider applying BOMs during federation development efforts and to pioneer its transformation to other domains through the development of content via BOMs. Conceptually, BOMs will work, but pilot projects and real world examples need to continue to be prototyped and demonstrated in the short term to gain even more in-depth knowledge and applicability, and to provide incentive for others to build, share and use BOMs. It is envisioned that future repositories and tools will make use of BOMs providing easy-to-access and easy-to-use capabilities for developers and users. Once this occurs, the BOM Methodology will provide an opportunity not only for the community to attain high fidelity interoperability and simplified integration through reuse, but also will collectively expand and apply HLA to other territories and domains.

Appendix A – BOM Definition Origin The BOM concept was formally introduced by the RFOM Study Group in 1998. The formulation of this idea can be traced to an exchange of email messages between RFOM SG members through the SISO reflector. The original email message that identified the concept of BOMs and its potential impact is reposted below: pgustav@dv.synetics.com on 10/16/1997 11:10:12 AM To: SIW-RFOM@sc.ist.ucf.edu cc: (bcc: Paul Gustavson/Dahlgren/Synetics) Subject: Re: First Shot I've read comments thus far generated in regards to what is a RFOM and the needs of RFOM. To me there's more agreement than disagreement on most issues. To add to the mix, I think it's important for me to share my thoughts and needs in regards to Reference FOMs (more so because we were all asked to share). Here are my high level somewhat simplistic thoughts (comments welcome). What we all know... -HLAs push is "interoperability" and "re-use". -Based on HLA Rules, Interoperability is not feasible unless everyone is using the same FOM. -Reuse allows less time and effort to produce something. (In our case FOMs/SOMs). Based on those three points I can say that there's no doubt that Reference FOMs can be extremely important and useful for the HLA community. First off, when I say Reference, no matter how hard I try to define and vision it, it comes out meaning a "standard". Where a Reference FOM is a standard FOM which has been widely accepted/approved for re-use within the community for interoperability. And maybe that's okay! If you look at the DoD M&S Master Plan, Objective 1 ("Develop a common technical framework for M&S") There's sub-objective 1-3 ("Data Standardization"). So, standardization arguably has a place for FOMs... The point was made in an earlier email that Reference FOMs could be used as a baseline FOM that "could stand on its own and be used in exercises." Michael O’Connor continued to say (and tell me if I’m interpreting this incorrectly) that Reference FOMs could be used to represent a set of what I call Base Object Models. Base Object Models can be thought of as the FOMlets (maybe we should call them OMlets), or in the business world what would be called RAD Business Objects(1). RAD, for those that don't know, refers to Rapid Application Development. Some common RAD tools include Visual Basic, Delphi, PowerBuilder, Visual Cafe, Notes, etc.... If you're familiar with any of these tools, they all provide a set of object models that the user can re-use

to build applications. (Kinda like the clip art concept mentioned an earlier email). You simply drag an object type down from a toolbar, drop it on a form, and you are given the opportunity to define the proprieties and events (interactions) of an object type. (This happens to relate to some of the work we (as well as others) are doing in HLA Federation Development Tool use area). From this discussion we must ask which should a Reference FOM be... [1] a baseline FOM that's ready for use, but can be supplemented/altered if need be for use in a Federation? [2] a grouping of Base Object Models (clip art, omlets) that can be used to construct FOMs / SOMs? [3] both? [4] something all together different? I'm inclined to vote for [3] with emphasis on Base Object Models where a FOM can be simply reconstructed by linkage of all its Base Object Models. If a federation chooses to use an already built RFOM, than they really don't have to do any development. Just grab the RFOM DIF and go forth with the execution (wish it was actually that easy). If a federation wants to build upon and/or use a subset of a RFOM then they should be allowed to through the use of selecting the Base Object Models they wish to use, and adding new ones if necessary. That brings up another point, if a Federation Engineer (one who develops FOM/SOMs/Scenario) creates a new Object Model, there’s no reason why he shouldn’t be able to "bookmark" that as a BOM and re-use it later (especially if he's using an automated tool). The difficulty here is that this Object Model (or BOM) is not an approved, widely used Object Model within a FOM (at least not initially). But that's OK! Everything has to start somewhere. Okay, this leads to some other questions. Should we (SISO) be in the business of "standardizing" FOMs or just Object Models (BOMs)? If a Federation Engineer creates a great new subclass platform that he calls an Object Model, how can the community embrace his Object Model as accepted/approved? Should we have RFOM Extensions which allow the "standardization" of an individual Object Models (respective to a RFOM)? I'm looking forward to tomorrow's discussion. VR, Paul (1) see IEEE Computer, Oct 1997 – “Implementing with RAD Tools' Native Objects”.

Appendix B – Use Cases – A Mechanism for Capturing Functional Requirements

B.1 Introduction The Federation Development and Execution Process (FEDEP) describes the activities involved in HLA federate and federation development and execution. As described through out this specification, one of the key elements needed by all phases of the FEDEP are the federation requirements. Requirements support federation design and development, identify federate roles and responsibilities, provide the basis for testing and accrediting a federation, and is used as the assessment criteria in validating the performance of a federation execution. An efficient and effective mechanism useful for capturing and tracking requirements is vital and necessary to support and encourage FEDEP activities. The concept of Use Cases, borrowed from the object oriented software engineering world and promoted within the Unified Modeling Language (UML), provides a way for HLA simulation engineers to capture federation requirements and to track those requirements through multiple stages of the FEDEP.

NOTE: The Use Case concept described in this section is not intended to be a direct association nor endorsement of the Unified Model Language (UML).

This section explores Use Cases and identifies a Use Case template mechanism developed by Alistair Cockburn for capturing requirements in an easy-to-read, easy-to-track text format. 12 13 This section includes an examination and exploration of how a collection of Use Cases based on the proposed template provides a Blueprint used to:

1. Capture sponsor requirements and federation objectives; 2. Support scenario development and conceptual analysis; 3. Facilitate meta-data matching (reuse), and incremental, component-based

federation development; 4. Identify critical test points, and provide the basis for test and VV&A plans; and 5. Evaluate the success of a federation execution.

Applied to HLA, a Use Case represents a goal or ‘case of use’ for a federation. A Use Case identifies a typical interaction that an actor has with the federation in order to achieve a desired goal. 11 Depending upon the scope and level of the Use Case, an actor may represent an actual federate participant, or, more commonly, represent a federate/federation Object Model class. In general, actors are external entities generated from a federate that interact with the federation to achieve a desired goal. A complete use case identifies the goal, actor(s) and potential scenarios required for the principal actor to accomplish the goal. The complete collection of Use Cases identified for a federation generates a Blueprint that can be used to support and encourage

FEDEP activities. B.2 Blueprint Centric FEDEP Solid functional requirements can be identified and used at each FEDEP stage by examining the intended goals of the federation. The collection of these functional requirements, documented as Use Cases, establishes a highly useful Blueprint. Like an architectural blueprint for a house or building, a Use Case Blueprint provides a common reference for the development, maintenance, testing and analysis of a federation.

Figure B.2 - Blueprint Centric FEDEP The Use Case Blueprint ensures that the federation purpose is understood, and encourages the active participation and communication of Sponsors, Engineers,

Testers, and Analysts throughout the FEDEP. As illustrated in Figure B.2, the activities described by FEDEP Steps One and Two are used to generate the Use Case Blueprint. The requirements process and feedback loops supported by the FEDEP (specifically between FEDEP Steps One and Two) encourages iterative and incremental development of this Blueprint. The Use Case Blueprint can then be used to support the activities described within FEDEP Steps Three, Four, Five and Six. Let us know explore the relationship of a Use Case Blueprint within each FEDEP Step. B.2.1 Defining Federation Objectives The activities described within the first step of the FEDEP requires that “the federation user and federation development team define and agree on a set of objectives, and document what must be accomplished to achieve those objectives.” 2 Use Cases provide a means for identifying:

• the initial planning documents, and • the federation objective statements.

At this stage in requirements definition, one or more federation engineers, in conjunction with federation sponsor(s), establish the rationale, scope and subsequent goals of the federation and individual federates. The Use-Cases developed at this level begin as Summary Use-Cases due to their high level, conceptual nature. Once the Summary Use-Cases have been identified, another level (or nesting) of requirements and goals are then revealed. These next level requirements and goals provide either additional Summary information or identify a primary task to be accomplished within the federation.

Summary information is documented as a lower-level Summary Use Case whereas, a requirement or goal that identifies a primary task is documented as an Object Model Use Case. The characterization of Object Model Use Cases may then lead to the identification of Sub-Function Use Cases in a similar manner. Figure B.2.1 provides a graphical representation of the Use Case hierarchy.

Figure B.2.1 - Use Case Hierarchy It is important to note that FEDEP Step One requires a federation engineer to simply identify the goals and objectives of a federation. Use Cases identified in Step One will be further elaborated within the activities described by FEDEP Step Two. The benefits of Use Cases within FEDEP Step One of the FEDEP are highlighted in Table B.2.1.

Table B.2.1 FEDEP Step One Use Case Support Step One Elements

Use Case Support Major FEDEP Benefit

Sponsor Needs

Captures sponsor requirements and needs as hi-level Summary Use Cases.

Establishes an explicit and unambiguous statement of sponsor needs.

Federation Objectives Development

Captures detailed set of specific federation objectives as low-level Summary Use Cases and Object Model Use Cases.

Contains measurable federation objectives and initial VV&A/test requirements criteria.

B.2.2. Development of a Federation Conceptual Model The second step of the FEDEP requests for “a representation of the real world domain that applies to the problem space [to be] developed.” 2 It is within FEDEP Step Two that the elaboration of aspects pertaining to goals and requirements occurs for the Use Cases identified in FEDEP Step One. Aspects might include the types of high-level analysis required to ensure proper federation execution or the identification of specific behaviors of instantiated objects controlled by a federate. Once the tasks involved in Step Two are complete, the collection of completed Use Cases becomes a Blueprint identifying:

• the federation conceptual model and requirements, • the general federation scenario for potential Object Models, and • the test criteria needed to evaluate the success of the federation.

The major benefits of Use Cases within Step Two of the FEDEP are identified in Table B.2.2.

Table B.2.2 FEDEP Step Two Use Case Support Step Two Elements

Use Case Support Major FEDEP Benefit

Scenario Development

Captures major entities to be involved and entity capabilities, behavior and relationships as Object Model Use Cases. Includes Preconditions, End Conditions and Scenario Description.

Provides establishment of potential interaction based scenarios.

Conceptual Analysis

Captures the detailed set of specific federation objectives as low-level Summary Use Cases and/or Object Model Use Cases.

Provides a traceability link between the federation objectives and the design implementation

B.2.3 Federation Design The third step of the FEDEP describes the design effort in creating the federation. At this step, the FEDEP requires “federation participants (federates) [to be] determined, and required functionalities [to be] allocated to federates.” 2 The collection of Use Cases developed during Step One and Step Two of the FEDEP produces the Blueprint that can be used to guide the design of the federation, and establish a Federation Development Plan. Each completed Use Case identifies the required functionality of the proposed federation and can be used as an aid in selecting the appropriate and potential federates as well as a federate’s responsibilities. A coordinated Federation Development Plan is an expected output of Step Three. The effort in developing this plan is greatly reduced if a Blueprint has already been established. In fact, the Use Case Blueprint can be a foundation for the Federation Development Plan and should be used to guide the development, testing and execution of the federation. Additionally, the Blueprint (Use Cases) provides the necessary meta-data documentation need to facilitate reuse in other federations. These aspects will be described in greater detail in sections B.2.4, B.2.5 and B.2.6. The summary benefits of Use Cases within FEDEP Step Three are highlighted in Table B.2.3.

Table B.2.3 FEDEP Step Three Use Case Support Step Three Elements

Use Case Support Major FEDEP Benefit

Select Federates

Use Case identifies potential players (actors) necessary

Provides the necessary groundwork for selecting appropriate federates

for the federation Allocate Functionality

Use Case describes the necessary actions required to achieve goal

Provides the necessary assessment criteria for assigning federate responsibilities

Prepare Plan Foundation for a coordinated Federation Development Plan

The effort in developing the Federation Development Plan is greatly reduced, and provides the necessary meta-data documentation need to facilitates reuse

B.2.4 Federation Development The fourth step of the FEDEP describes the analysis, design, and implementation phases of FOM construction. At this step, the FEDEP requires “the FOM [to be] developed, federate agreements on consistent databases/algorithms [to be] established, and modifications to federates [to be] implemented (as required).” 2 The collection of Use Cases provided the foundation for the Federation Development Plan produced from FEDEP Step Three. The Federation Development Plan is used to guide the construction (or modification) of a FOM. It is important to understand that this Federation Development Plan is in essence the Blueprint that has been described so far. The requirements and goals of the federation under construction are identified and documented as Use Cases within the Blueprint. For example, a Use Case within the Blueprint may identify the requirement for an Object Model interaction and identify the associated object classes required to support the interaction. The Blueprint takes the guesswork out of what needs to be defined. By following the Blueprint, Federation Object Model (FOM) components can be designed and developed without the need of extensive queries and surveys among federation engineers. It is also important to note that the Blueprint encourages incremental development of the federation. “Build a little, test a little, learn a lot” is a common engineering philosophy, when put into practice, can produce tremendous benefits in the life-cycle development of software and systems. The same philosophy can be applied to HLA federation development when a Use Case Blueprint is being utilized. The Blueprint identifies the elements required for a federation and any linked elements. If a federation is built to a subset of contingent elements, it can then be delivered, used and tested prior to its completion. Therefore, a Use Case Blueprint streamlines federation design and development. The incremental development that a Use Case Blueprint encourages, also lends itself well in supporting the design and development of component-based federations (see Figure B.2.4). This includes the creation and use of Base Object Models (BOMs).

Figure B.2.4 – Federation Development (w/ BOMs) A BOM is a component that reflects a “single aspect of federation interplay that can be used as a building block for FOMs and SOMs”. 3 Similar to component based software development in which a programmer may use ActiveX, VCL, or JavaBean components to rapidly develop applications, there is similar merit in using BOMs to support federation development. The Use Case Blueprint provides the meta-data necessary to describe the intent of a BOM or other reusable component. For example, if a FOM is being developed or enhanced, a federation engineer may use the Use-Case data contained in the Blueprint to perform a meta-data match against existing BOMs, which are also described by a Use Case. If a BOM exists that helps to satisfy a requirement of the FOM being developed or updated, then it can be quickly and efficiently integrated into that FOM. If a BOM does not currently exist, then the federation engineer may define and store the particular component-based object and the associated Object Model Use Case contained within the Blueprint as a BOM for later reuse. This allows BOMs to be created ‘on-the-fly’ during federation development and maintenance. Because the BOM created ‘on-the-fly’ has a well-defined Use Case associated with it, OM Meta-data matching may be performed during the construction or modification of other federations. The summary benefits of Use Cases within FEDEP Step Four are highlighted in Table B.2.4.

Table B.2.4 FEDEP Step Four Use Case Support Step Four Elements

Use Case Support Major FEDEP Benefit

Develop FOM

Facilitates incremental and component-based federation development.

Helps produce requirement verified FOMs and SOMs with supplemental meta-data. Provides a traceability link between federation objectives, federation design, and the actual FOM implementation.

Establish Federation Agreements

Use Case Scenario describes federate behavior

Federation members (of all levels) understand the expected federation behavior of objects and interactions.

Implement Federate Modifications

Provides the necessary meta-data for understanding the intent of the federation

Ensures conceptual model objective is represented by object classes and interaction classes that are modified

B.2.5 Integrate and Test the Federation The fifth step of the FEDEP describes the aspects of integrating and testing the federation prior to execution. During this step, the FEDEP requires “all necessary federation implementation activities [to be] performed, and testing [to be] conducted to ensure interoperability requirements are being met.” 2 This includes planning, identifying, and integrating federates and federations, and performing an initial federation checkout test. In order to ensure that interoperability requirements are met, the original requirements must be examined and compared. Object Model Use Cases contained within the Blueprint provide an easy-to-read, easy-to-track mechanism useful for comparing interoperability implementations against requirements. The tracking capabilities produced through Use Cases provide a requirements traceability that can facilitate FEDEP automation. Use Cases can be passed to FEDEP Step Four to help identify critical test points, and provide the basis for developing:

• Federation Compliance and Integration Test Plans, • Scenario and Exercise Plans, and • Verification, Validation and Accreditation (V&A) Plans.

A summary of the benefits Use Cases provide within FEDEP Step Five are highlighted in Table B.2.5.

Table B.2.5 FEDEP Step Five Use Case Support Step Five Elements

Use Case Support Major FEDEP Benefit

Execution Planning

Identifies the federation performance requirements and other Federation Execution Planning issues.

Provides the necessary foundation to quickly transition to federation integration and testing.

Federation Integration and Test

Use Cases provide guide for federation integration and the scenario execution.

Identifies critical integration issues and critical test points during checkout, and encourages an iterative “test-fix-test” approach for thorough integration.

B.2.6 Exercise Federation and Prepare Results The sixth and final step of the FEDEP describes the aspects of the federation execution and criteria for analyzing the execution results. Specifically, this step requires “the federation [to be] executed, outputs analyzed, and feedback provided to the federation sponsor.” 2 Use Cases collected during FEDEP Steps One and Two provide the “test evaluations criteria” necessary to ascertain the success or failure of the federation within FEDEP Step Six activities. Additionally, the Use Case Blueprint provides a framework for the High Level Analysis Plan and the basis for the Detailed Data Collection and Analysis (DC&A) plan necessary to support the role of the Analyst. A summary of the benefits of Use Cases within Step Six of the FEDEP is highlighted in table B.2.6.

Table B.2.6 FEDEP Step Six Use Case Support Step Six Elements

Use Case Support Major FEDEP Benefit

Federation Execution

Use Case scenarios guide federation execution and real-time analysis.

Provides a clear concept of expected execution operation including variations and extensions to scenario plan.

Feedback Use Case scenario and the respective success criteria provide a checklist and tracking mechanism useful for post-process analysis.

Provides a mechanism for determining if federation objectives have been met and supporting modifications of that federation. Meta-data results can be linked with Use-Case to support future reuse and repeatability.

B.3 Use Case Template Section B.2 explored the concept of Use Cases and its relationship with the activities described by the FEDEP. A Use Case Blueprint encourages communication and involvement among sponsors, engineers, testers, and analysts through each FEDEP Step activity. However, in order to adequately support use case traceability, a template for documenting Use Cases is necessary. The paper will now examine a template for documenting Use Cases. The Unified Modeling Language (UML) places strong emphasis on Use Cases and

provides a standard diagramming method for representing a Use Case as illustrated in Figure A.3.1.

Figure B.3.1 UML Use Case Diagram

Although Use Cases can certainly be represented this way, the UML Use Case “cartoon” diagrams are not very helpful in allowing us to track requirements through the whole FEDEP process (i.e. it is not directly supportive of testing and federation validation). In order to maximize the use of Use Cases at the various activities described by the FEDEP, it is important to have a linkable, traceable document mechanism. Fortunately, a standardized (de facto) Use Case template currently exists that identifies the important aspects of functional requirements, and is very effective in supporting requirements traceability. The Use Case template proposed within this paper was developed by Alistair Cockburn and is highly regarded in the software development community. 12 13 Mr. Cockburn’s template, hereon referred to as Cockburn’s Template, is considered to provide an “easy-to-read” and “easy-to-track” Use Case requirements mechanism. Applied to HLA, Cockburn’s Template is ideal for HLA FEDEP activities and provides a method for:

• representing HLA goals, requirements and objectives (such as a task/interaction between an actor (simulation object) and the federation), and

• recording a set of scenarios that tracks actor actions from a trigger event to the goal (success conditions) and failures.

Table A.3.1 Cockburn’s Use Case Template

Use Case Title <goal as a short active verb phrase> Goal in Context <a longer statement of the goal in context if needed> Scope <what aspect of federation can be considered the black

box under design> Level <one of : Summary, Primary Task (Object Model), Sub-

function> Preconditions <what we expect is already the state of the world> End Conditions <the state of the world upon successful/failed completion>

Primary, Secondary Actors

<a role name or description for the primary actor>. <other actors relied upon to accomplish use case>

Trigger <the action upon the federation that starts the use case> Scenario Main Step Action 1 <steps of the scenario from trigger to goal delivery, and any

cleanup after> 2 <...>

3 <...> Extensions Step Branching Action 1a <condition causing branching> :

<action or name of sub use case> Variations Step Branching Action 1 <list of variations>

Cockburn’s template is illustrated in Table A.3.1. The Use Case is identified by a Title that reflects the goal in a short active verb phrase. The title and an associated unique ID provide a reference key useful for tracking requirement goals during multiple stages of federation development. The Use Case is further described within the Goal in Context. The Scope, Level, and Trigger provide additional components identifying the Use Case goal. Scope reflects the boundary of the federation. For example, scope might be the “community” if a Use Case reflects a goal of value to the broad federation community, or a “federation” if a Use Case reflects a goal of value bounded by the federation under development. The Level indicates the condition of the goal specifically identified as a Summary goal, Object Model goal, or a Sub-Function goal as described in the FEDEP Step One discussion (Section B.2.1). In addition to capturing the core of a federation goal, Cockburn’s Template provides the capability to identify pre and post conditions. The Precondition identifies the required state of the federation for the Use Case scenario necessary for a Trigger event to occur. The Trigger identifies the action upon the federation that initiates the Use Case scenario. Once the Use Case scenario has been played out, two possible outcomes may result; either the goal was successfully accomplished or it failed. The End Condition describes the state of the federation when the goal was satisfied and should also include the state of the federation when the goal was either abandoned or completed unsuccessfully. Actors are required to either provide or achieve the goal of the Use Case. Each Use Case may have two types of actors: primary actor(s) and secondary actor(s). A Primary actor uses the federation to achieve a goal. Use Cases are incomplete without a primary actor. A typical Use Case will have only one primary actor, however it is possible to identify multiple primary actors if multiple coordinated actors use the federation in conjunction to achieve a goal. A Secondary actor may be required by the federation to assist the primary actor’s goal. Primary actors and secondary actors are

responsible to carry out specific actions required in reaching the goal. Once a Use Case scenario is initiated, it will typically follow a set of steps necessary to realize the goal. The Scenario describes the steps from trigger to goal delivery. Each step can be identified by three parts: the Main, Extensions, and Variations. The scenario Main description identifies the main success scenario in a sequential and abstract step oriented manner. Each step is uniquely numbered so that it can be referenced within the scenario Extension and Variation sections. The Extension section indicates recovery cases of a step. This provides a brief description of Cockburn’s Template labels, but to fully understand this template and the concept of a Use Case Scenario it is helpful to provide an example. Table B.3.2 illustrates an example of a Use Case describing an Air-to-Air Engagement.

Table B.3.2 Air-to-Air Engagement Use Case

Use Case Title Air To Air Engagement Goal in Context Perform Air To Air Engagements on Hostile Tracks over protected Air

Space Scope Federation - Defense of “No Fly Zone” Level Primary Task (a.k.a. Object Model Level) Preconditions Air Threat, “No Fly Zone” Region End Conditions Air Threat Destroyed (s), Air Threat Departed (s), Air Threat Remains (f)Primary, Secondary Actors

Air Threat, Air Defense AAM

Trigger Air Threat Entered “No Fly Zone” Scenario Main Step Action 1 Air Threat Enters “No Fly Zone”

2 Vector Interceptors To Air Threat

3 Locate Target

4 Lock on Target

5 Threat Verification

6 Employ Ordinance (“Employ Ordinance” use case)

7 Battle Damage Assessment Extensions Step Branching Action 3a Enemy Fire (“Evasive Maneuvers” use case) Variations Step Branching Action 2 Detection via AWACS, or

Ground Controller (GCI), or Fighters in CAP

As shown in the example, scenarios are comprised of a series of steps. These steps contain the primary (or main) execution plan for the participating actors and may include “extensions” or “variations” of the execution plan . An extension is a condition causing branching and may identify an additional Use Case. For example in our Air-to-Air Engagement Use Case the third step in the Scenario is to “lock on target”, however what if the threat turns and begins to fire on the interceptor. This is identified as an extension or exception within the Air-to-Air Engagement execution plan (see extension step 3a), and it must be handled differently before resuming the execution plan. In this case, our interceptor has a requirement to perform “Evasive Maneuvers” described by another Use Case upon enemy fire. A variation represents circumstantial change in the execution plan, but does not cause an exception. For example, in our Air-to-Air Engagement Use Case, the second step in the Scenario is to “Vector Interceptors to Air Threat.” There are at least three ways Interceptors would be vectored to the “No Fly Zone.” One is an AWACS (a potential secondary Actor) detected the threat, or a Ground Controller (GCI) detected the air threat, or finally existing fighters in Combat Air Patrol (CAP) detected the threat. These are all variations, rather than extensions because these elements did not cause an exception to the scenario. Variations allow abstract Use Case scenario steps to be rapidly defined by providing a mechanism for further amplification of the various elements that might be used to support and/or satisfy the step. Therefore, Scenario steps are in essence sub-goals and may represent other Use Cases (via a main step or an extension to a main step). Therefore, Use Case nesting is a natural behavior when defining a collection of Use Cases. The collection of Use Cases forms a blueprint made up of a hierarchy of requirements, described in Table B.3.3, identifying three distinct levels of goals: Summary Goals, Object Model Goals, and Sub Function Goals.

Table B.3.3 Use Case Levels Type Description Example Summary Use Case

Collection of user (sponsor) level goals. Includes mix of high level Summary Use Cases may encapsulate multiple lower Summary Use Cases.

Sponsor Needs, Federation Objectives

Primary Task Use Case

Represents an Object Model Task / Interaction to be performed

“Air to Air Engagement”, or “Aerial Bomb Attack on Surface Targets”

Sub Function Use Case

A scenario step and granule execution detail of the federation. Drawn from Scenario Steps of the Object Model Use Case

“Fire missile”, or “Illuminate incoming threat”

In addition to the Use Case template, Alistair Cockburn also developed a related ‘meta-data’ template, which makes provisions for additional characteristic data that reflects

related meta-data information. The meta-data includes the identification of a Use Case or Priority, Open Issues regarding the Use Case, a link to any Superordinate or Subordinate Use Cases (for sub-level linking), data regarding the Revision History, and allows for additional Comment Information to be included as illustrated in Table B.3.4.

Table B.3.4 Related Meta-Data Template (Use Case) RELATED INFORMATION

<Use case name/#>

Priority: <how critical to the federation> Open Issues <list of issues awaiting decision affecting this Use Case > Superordinates <name of any Use Case(s) that reference this one> Subordinates <links to any sub Use Cases> Revision History

<document the revision history of the Use Case>

Comment Information

<additional meta data>

This template has a number of applications. It can also be used to help define additional meta-data for, Base Object Models, or other component elements as illustrated in Table B.3.5.

Table B.3.5 Related Meta-Data Template (BOM) RELATED INFORMATION

<BOM name/#>

Priority: <how critical to the federation> Open Issues <list of issues awaiting decision affecting this BOM > Superordinates <name of any BOM(s) that reference this one> Subordinates <links to any sub BOMs> Revision History

<document the revision history of the BOM>

Comment Information

<additional meta data>

B.4 HLA Use Case Tools There are several tools used to support the capturing of requirements as Use Cases. One such tool is OMCase™ used to support the activities described in FEDEP Step One and Two. OMCase™ uses Cockburn’s Template in XML to establish a Federation Blueprint that captures sponsor objectives, identifies scenario elements, and facilitates requirements traceability, and component-based design of federations. An example of a Use Case Blueprint documented by OMCase™ is shown in Figure B.4. However, in order for the information within the Blueprint to benefit the entire federation development

process (as described in Sections B.2.3, B.2.4, and B.2.5), a mechanism to make this information available to other HLA tools that address Steps 3, 4, and 5 of the FEDEP must exits. Two methods are available today, the first is via a Blueprint DIF (i.e., the XML file) and the second is via an Integrated Development Environment (IDE) that is CAFDE based. 5

Figure B.4 OMCase™

B.5 Wrap Up The collection of Use Cases, identified as the Blueprint, represents a “set of objectives,” and “the real world domain of interests (entities and tasks) described in terms of a set of required objects and interactions.” 2 The Use Case Blueprint ensures that the federation purpose is understood, and encourages the active participation and communication of Sponsors, Engineers, Testers, and Analysts throughout the FEDEP. Cockburn’s Template provides the necessary mechanism to document Use Cases and provides a standard template for Reference FOM requirements meta-data. Tools supporting the Use Case traceability via Cockburn’s Template and supporting an architecture that allows the sharing of the Use Case Blueprint information with other tools (i.e. FEDEP DIFs, and CAFDE), promise to promote and encourage the following capabilities:

• Simplifies Requirements Capturing • Provides An Easy Way To Share (Communicate) with Sponsors, Engineers, and

Analysts • Supports Federation Verification and Validation • Facilitates Automation of the FEDEP • Encourages Object Model Component Reuse (i.e. BOMs)

The development and use of these Blueprints is highly recommended to better support the development, testing and analysis of HLA federations.

Appendix C - Glossary This section provides an ordered list of defined terms and concepts used throughout the document. Federation - A set of software applications interacting under a common object model and network interface (e.g. RTI) to form a unified simulation environment. Interoperability - The ability of software and hardware on multiple machines for multiple vendors to communicate and understand each other. Patterns – “An idea that has been useful in one practical context and will probably be useful in others.” – Martin Fowler. Component - An encapsulated (black box) unit with a known set of inputs and expected output behavior, but the behavior details are not exposed. Component Reuse - “The ability to use a particular component many times, either within the same [system] or in various [systems], without modification of the original component. Encapsulated BOM - Represents a “component” of a federate or federation that can be leveraged within other federates and federations. Interface BOM - Represents a “pattern of interoperability” contained within a FOM or a SOM that can be leveraged within other federates and federations.

Appendix D - Acronyms This section provides an ordered list of defined acronyms used throughout the document. ADL Advanced Distanced Learning B2B Business To Business BNF Backus-Nauer Format BOM Base Object Model DIF Data Interchange Format FED file Federation Execution Development file FEDEP Federation Development Execution Process FEPW Federation Execution Planner’s Workbook FOM Federation Object Model HLA High Level Architecture M&S Modeling and Simulation MSRR Modeling & Simulation Resource Repository MEL Master Environmental Library MOM Management Object Model MSOSA Modeling & Simulation Operational Support Activity OMDD Object Model Data Dictionary OMDT Object Model Development Tools OML Object Model Library OMS Object Model Synchronization OMT Object Model Template RAD Rapid Application Development RID file RTI Initialization Data file RFOM Reference FOM RTI Runtime Infrastructure SOM Simulation Object Model XML eXtensible Markup Language

Appendix E –Web Sites The following URLs provide more information about Base Object Models on the Internet:

• http://www.sisostds.org/stdsdev/bom/index.htm • http://www.baseobjectmodel.com • http://www.cafde.org/boms • http://www.simventions.com

Bibliography

1. Under Secretary of Defense for Acquisition and Technology, "Department of Defense Modeling and Simulation Master Plan, DoD 5000.59-P," October 1995.

2. Defense Modeling and Simulation Office (DMSO), “High Level Architecture, The Federation Development and Execution Process, Version 1.5”, December 8, 1999.

3. Hancock, J., et al. “Reference FOM Study Group Final Report” SISO Reference Product March 1998.

4. Reference FOM Study Group Reflector, 16 October 1997 (see Appendix A). 5. Gustavson, P., Goss, S., Bachman, J., Root, L., “HLA Computer Aided

Federation Development Environment (CAFDE)”, 1998 Spring Simulation Interoperability Workshop Papers (98S-SIW-001), March 1998.

6. Bouwens, C., Miller, R., Harkrider, S., Lutz, R., Scrudder, R., “Object Model Development: Tools and Techniques”, 1998 Spring Simulation Interoperability Workshop Papers (98S-SIW-142), March 1998.

7. Gustavson, P., Hancock, J., McAuliffe, M., “Base Object Models (BOMs): Reusable Component Objects for Federation Development”, 1998 Fall Simulation Interoperability Workshop Papers (98F-SIW-034), September 1998, http://www.sisostds.org/.

8. Gustavson, P., Root, L., McAuliffe, M., “Object Model Use Cases: A Mechanism for Capturing Requirements and Supporting BOM Reuse”, 1999 Spring Simulation Interoperability Workshop Papers (99S-SIW-115), March 1999, http://www.sisostds.org/.

9. Hancock, John, P, Schandua, J., Gustavson, P., “A Structural Description of Base Object Models (BOMs)” 99S-SIW-185 Spring 99 Simulation Interoperability Workshop, March 1999.

10. Gustavson, Paul L., et al. “Use Cases – A Blueprint Approach for Federation Development, Testing, and Analysis” 99F-SIW-112 Fall 99 Simulation Interoperability Workshop, September 1999.

11. Fowler, M., “UML Distilled: Applying the Standard Object Modeling Language”, Addison - Wesley, 1997.

12. Cockburn, A., "Structuring Use Cases with Goals", HaT.TR.95.1, Journal of Object-Oriented Programming (JOOP), Sept and Nov 97, two part series.

13. Cockburn, A., “Basic Use Case Template”, TR.96.03a, Human and Technology, 26 October, 1998, http://members.aol.com/acockburn/.

14. Synetics, “CAFDE Architecture, An Open Interface for HLA Implementation Tools”, Version 1.1, 26 September 2001, http://www.cafde.org/.

15. Gustavson, Paul L., et al. ” BOMs: The Promised Land?”, Simulation Technology Magazine Vol. 4 Issue 2 January 4 2001.

16. IEEE, "High Level Architecture: Object Model Template (OMT) Specification", Version 1516.2, 13 April 2000.

17. Fowler, M., “Analysis Patterns: Reusable Object Models”, Addison – Wesley, 1997