1. Product Nomination Title: Base Object Model (BOM) Specification

Transcription

1 1. Product Nomination Title: Base Object Model (BOM) Specification 2. Proponent Name(s) and Contact Information Lead: Paul Gustavson Others: Chris Rouget, SAC TAD See Item# 9 for list of volunteers 3. Type of Product: The outcome of the PDG effort is expected to be a Standard Product providing a specification for Base Object Models (BOMs). Product Description One of the approaches of FOM development as described in the FEDEP is to employ a reusable set of object model components to construct and/or modify a FOM, with each component representing an [independent] aspect of federation interplay. Base Object Models (BOMs), which have been investigated within the SISO community, are specifically identified in the FEDEP as a potential facilitator for these object model components. The open standardization of BOMs is essential for establishing a technology capability that facilitates interoperability, reusability and composability. Specifically, a standardized product defining the format and syntax specification, based on the extensible Markup Language (XML), is needed for describing the basic elements of a BOM. Additional XML standards (i.e. Schemas) currently available will be identified and applied to support the various BOM dimensions and BOM ontology. The result of defining and applying such XML schemas will identify the essential meta-data to be captured, cataloged and carried forward within a BOM in order to provide for shared understanding and community reuse. The composition of individual BOMs for defining a simulation or simulation environment is used to produce what is loosely termed a Mega-BOM. A Mega-BOM carries with it the meta-data associated to BOMs plus the dependency and interrelationships between BOMs. As guidance, the BOM specification will also introduce the methodology for establishing Mega-BOMs based on the familiar Rapid Application Development (RAD) component philosophy used successfully within the software development community. (Examples of software components used to develop software include ActiveX/ COM, Java Beans, VCL / CLX components.) Within the HLA domain, a transformation from a Mega-BOM to a FOM, which contains less meta-data, can be produced adhering to the Object Model Template (OMT), thereby

2 supporting HLA federation development. The additional meta-data carried in a BOM is intended to make it easier for object-oriented development tools and designers to discover and use applicable BOMs for the assembly of HLA FOMs or SOMs, and in assembling simulation spaces. 4. Identification of the Community to which product applies: The BOM specification is intended for the distributed simulation community including but not limited to those that use the HLA. From an Operational Viewpoint, BOMs are anticipated to support military and commercial markets in the area of experimentation, analysis, training (i.e. advanced distance learning), and acquisition. Communities that could ultimately benefit from BOMs include defense, education, medical, manufacturing and entertainment. From a Technical Viewpoint, BOMs will be particularly useful to simulation developers who need to rapidly compose interoperable simulations and simulation environments. It is anticipated that an outcrop of simulation component developers will emerge offering third-party BOM components for usage and distribution. Supportive BOM tools and collaborative web services are expected to emerge as well. 5. Problem(s) and/or issue(s) that the proposed product addresses: a) Provide details on the specific need or requirement for this product in the community. SISO s interest is to explore methods that support and promote reuse of simulation components and encourage agile, rapid, and efficient development and maintenance of object models. BOMs are intended to provide a key mechanism in facilitating interoperability, reuse, and composability. Standardization of a BOM specification is needed to enable these capabilities. b) Provide details on the discussion of the need for this product in the community. The need for this capability was initially identified within the FEDEP and OMT documentation describing the concept of using piece parts in composing FOMs and SOMs. This concept has also been described in the community as FOMlets used to compose (and decompose) FOMs. In 1998, the Reference FOM Study Group recognized the need for a component-like approach for rapid FOM/SOM development and formally identified the BOM concept. Several white papers on BOMs increased the interest in the concept and propelled the establishment of the BOM Study Group, which wrapped up in March A BOM Working Group (WG) within SISO was then established to carry the discussion and interest forward. Recently, the operational community has shown greater interest in a component-like approach for supporting simulation interoperability activities. This includes DMSO, which held a Composable M&S Workshop during the summer 2002, and the extensible Modeling and Simulation Framework (XMSF) group, which was also established during summer 2002.

3 During the Composability Workshop, the following Warfighter needs were identified, which the BOM standard intends to fulfill: o Multi-resolution and composable simulation environments o Faster, less costly database development o Standardized (reusable) components o Reduced Overhead Additional comments centered on the need for component technology, as would be supported by the BOM standard, are identified below. A new generation of models and simulations will be needed to support distributed training; robust and continuous experimentation; and operational planning, execution, and assessment tools. Transformation Study Report, Executive Summary, 27 April To allow maximum utility and flexibility, modeling and simulation environments will be constructed from affordable, reusable components interoperating through an open systems architecture. DMSO Perspective (Vision), September 2002, Phil Zimmerman Some of the recent SIW papers describing topics that BOMs would address are identified below: Document # Title Author 02F-SIW-004 Avoiding Another Green Elephant - A Proposal Dr. Andreas Tolk for the Next Generation HLA Based on the Model Driven Architecture 02F-SIW F-SIW F-SIW-100 The Simulation Reference Markup Language Steven Reichenthal (SRML): A Foundation for Representing BOMs and Supporting Reuse Making Simulation Interoperability and Reuse A James Heusmann, Reality Albert Sciarretta The Use of Base Object Models (BOM) in the Christopher Stapleton Virtual Backlot (VB) c) Have you investigated similar products in the community to ensure that no overlap exists? Absolutely. The BOM SG has made a concerted effort to investigate current and emerging technologies that were seen as being able to support the simulation object model component concept. This effort has continued since the completion of the BOM SG. The BOM SG found that BOMs are really the only potential offering that has been openly identified to specifically support interoperability, reusability and composability

4 for simulation environments. There are, however, existing and emerging technologies and standards to be leveraged by the BOM standard to support various BOM dimensions (specifically meta-data elements). A majority of these technologies and standards are XML-based, including SRML for supporting representing behavior within a BOM. The BOM PDG will further identify supportive standards and how they fit with various BOM dimensions. 6. Maturity of the Proposed Product a) Detailed description on HOW the problem/issue will be solved (approach). The first step is to define the basic elements required of a BOM regardless of the various dimensions it may carry. Leveraging off the experiences associated with or gathered from federation development and the present day OMT, an XML schema will be defined that identifies these base elements and ontology. Since BOMs can carry different dimensions via meta-data, other existing XML Schema-based standards will be identified and associated with the appropriate dimensions. Guidance will be provided to describe how the composition of individual BOMs for defining a simulation or simulation environment can be used to form Mega-BOMs. And, in support of HLA, guidance will be provided on how to generate FOMs and SOMs from BOM compositions. b) Brief Discussion on the Maturity of the proposed product. The BOM concept was born within the Reference FOM study group in Following this study group, a BOM SG was formed which finished in the spring of In addition to the final report, the BOM SG generated the BOM Methodology Strawman (BMS) specification. The work accomplished by the SG and various individuals who have continued to look at BOMs establishes the basis for the standard that is being proposed. This effort is reflected in a number of white papers that have been published and presented at the SIWs. Other work being leveraged is the OMT 1516 specification, the Simulation Reference Markup language (SRML) for capturing and representing behavior, and the successes achieved within the software community with regard to software object components for supporting the Rapid Application Development (RAD) process (i.e. COM / ActiveX, VCL Components, Java Beans). c) Brief Discussion on alternative approaches to the proposed product. Presently, there are no alternative simulation component architectures available that support the objectives identified within the FEDEP, or, recently within the vision shared by DMSO for Composable Modeling and Simulation Environments (CMSE) (see Item 6.b). However, there are outside technology standards that can be applied and leveraged to support the meta-data required for the BOM ontology and various BOM dimensions. BOMs should be viewed as a flexible component-based standard for simulation interoperability that embraces outside XML standards and initiatives such as UML (XMI), SRML, and X3D. Additionally, the BOM component architecture is very much

5 in synch with the concepts and principles centered upon the OMG s Model Driven Architecture (MDA). d) Provide examples of prototypes of the proposed product or reasons why this product will not be prototyped. Once a standard specification has been established for BOMs, the next logical product will be to design and develop actual BOM components (as prototypes), which can be used to establish Mega-BOMs. This will serve to demonstrate the effectiveness and capability of BOMs. e) What impact will the proposed product have on the M&S community? The BOM specification will influence four things within the M&S community: (1) Substantative Interoperability The application of XML and XML Schemas prescribed for BOMs provides a mechanism for defining and validating context, and facilitates understanding of the data being exchanged. Furthermore, the flexibility offered by BOMs allows for greater application of simulation interoperability within other domains. (2) Reusability The meta-data cataloged within a BOM such as intent-of-use, historical use, behavioral information, and potential visual information will facilitate greater reuse of components (which is a stated need of SISO). (3) Composability BOMs will facilitate the ability to rapidly compose simulations and simulation environments both statically (design time) and dynamically (run-time). (4) Adaptability Mega-BOMs produced by BOM compositions can be used to represent the standard data exchange interface for systems and simulations. Unlike the current HLA approach in which all federates must comply with a common FOM, federates can continue to use their specific Mega-BOM interface to play within environments comprised of other simulations and systems represented by their own unique Mega-BOM interface. Adaptability is accomplished by deploying and applying the appropriate XML-based transformations, which represent mappings between common BOMs within a Mega-BOM, by the receiving federate. This minimizes the effort typically spent in re-tooling federates associated to complying with a specific FOM. Furthermore, it is envisioned that the next generation of tools and web services (such as collaborative development environments and repositories) will emerge to support the creation, deployment and use of BOMs for simulation development, maintenance, and run-time support. The PDG established to develop the BOM standard would identify the explicit high-level tool requirements needed to support BOM creation, deployment and use. f) What impact will this proposed product have on the SISO community? BOM standardization will serve to address the operational and technical needs of the SISO community. Furthermore, standardization provides an opportunity for SISO to expand its area of interest and influence within the simulation community. The flexibility

6 offered by an open BOM specification standard would allow SISO to reach broader domains and markets including Advanced Distance Learning, Medical and Biotechnology, Manufacturing and Processing, and Game Development and Entertainment. g) What is the impact to the community if this proposed product is not developed? Without an open standard, the simulation interoperability community will continue to lack the necessary reusable component technology for making simulation interoperability and reuse a reality, across Services, domains, and/or disciplines. Presently, the M&S community has been driving toward an "unstated but arising" restrictive FOM reuse philosophy. While HLA provides tremendous flexibility in allowing engineers to define the data format needed to reflect the intrinsic capabilities of their systems and simulations, the process required for developing FOMs has proved to be quite laborious. As a result, limited sets of FOMs have been developed and are in common use. It is in the best interests of the community to identify and explore methods that support and promote the reuse of simulation components and encourage agile, rapid, and efficient development and maintenance of interoperable environments. h) What is the domain implications for this proposed product? This standard is applicable to all simulation domains, and is not dependent upon HLA. It is seen as an enabling technology for supporting not only the defense community, but also the educational, medical, manufacturing, and entertainment communities. i) State which existing SIW Conference forum(s) take an active interest in the development of this proposed product? The BOM WG has served under the auspices of the PROC forum since its inception. Other forums and Study Groups (such as the NTMF and C4ISR SG) have expressed interest in the BOM concept. The discussion that led to this Product Nomination occurred at the Fall 2002 SIW. The work of the PDG will be regularly briefed in the PROC forum as well as to the SAC. 7. Planned compliance testing of the proposed product: This PDG will define how to verify that BOMs (and Mega-BOMs) are compliant with the various XML schemas associated with the meta-data a BOM (and a Mega-BOM) carries. The standard will include the requirements for testing BOMs to ensure they are wellconformed with the standard. Additionally the PDG will encourage input from other SISO forums and outside organizations to establish appropriate compliance testing practices and the meta-data necessary for identifying BOMs that have been verified, validated and accredited (VV&A). BOMs that have gone through this process will foster greater reuse.

7 8. Schedule of product development milestones including reviews and reports: It is anticipated that the requirements for an initial BOM specification draft will be completed before the Fall 2003 SIW. Subsequent updates to the draft will be made based on prototyping efforts and additional community input. The PDG goal will be to push towards community balloting for an open standard before fall Telecon discussions will be planned biweekly. 9. Candidate Volunteers for the Product Development Effort: An additional call needs to go out for interest in supporting the BOM standardization effort; however the following individuals have already expressed interest in supporting the PDG. Steve Goss Paul Gustavson John Hancock Bob Lutz Mark McAuliffe Michael O Connor michael.oconnor@itt.com Steve Reichenthal steven.w.reichenthal@boeing.com Larry Root lroot@simventions.com Chris Rouget cjrouget@preforce.demon.co.uk Chris Stapleton cstaplet@ist.ucf.edu Andreas Tolk atolk@odu.edu Phil Zimmerman pzimmerman@dmso.mil 10. Suggested product periodic review cycle (timeline): For the period of 5 years, the BOM specification should be reviewed on an annual basis to allow for continued prototyping. (It s anticipated that other XML standards that might be found useful in providing additional meta-data can be and should be identified and absorbed). Additionally, a call for papers (CFP) should be issued for each SIW requesting experience by those that have developed and/or used BOMs or have been involved in BOM related efforts and products. Once the initial 5-year review cycle is complete, the BOM specification should then be reviewed and updated as needed every 3 years.