Base Object Model (BOM) Frequently Asked Questions (FAQ)

  1. What is a BOM?
  2. What is a FOM?
  3. What is a SOM?
  4. What is a federate?
  5. What is a federation?
  6. What is meant by ontology?
  7. What does a BOM contain that I don't find in a FOM or SOM?
  8. What is a BOM assembly?
  9. What is the difference between a BOM assembly and a FOM?
  10. Are BOMs only applicable if I am using HLA?
  11. Can UML be used to define BOMs?
  12. How is the functionality described by a BOM supported? Is there a prescribed language for BOM Components?
  13. What is meant by component or piece part? What is the difference?
  14. Explain further what is meant by “Pattern of Interplay”?
  15. Explain further what is meant by “State Machine”?
  16. What do you mean by “conceptual entity”?
  17. What are “Events” in BOMs?
  18. What is meant by “Composability”?
  19. Why would I want to create a BOM? Or use someone else’s?
  20. The idea of reuse has been often discussed but never fully realized within the M&S community.  How does the BOM make reuse a reality?
  21. What is the anticipated impact of BOMs?
  22. What else is needed to support this vision of RAD for simulation compositions beside BOMs?
  23. How do you go about building and using a BOM?
  24. Can a group of OMT object classes and interactions be identified within a BOM without expressing a “Pattern Description”?
  25. What makes a BOM interoperable and platform independent so that any system can discover and use it in an individual simulation system?
  26. How will web services provide the automated infrastructure for the community to explore a BOM repository where a desired component can be used in a user’s system?
  27. How does the BOM fit with the eXtensible Modeling and Simulation Framework (XMSF)?

What is a BOM?

BOMs provide a neutral way to identify the following:

  • conceptual models (as an end state),
  • independent, “piece-part” simulation data exchange models (sdems)
  • mappings among conceptual models and sdems

The Base Object Model (BOM) is a component-based standard for describing a reusable piece part of a federation or an individual federate. Specifically, the BOM specification offers an ontology for characterizing elements of a simulation and relationships among conceptual entities within a simulation environment as a language neutral interface. BOMs can be used to document the interface for one or more of the following piece part elements:

BOMs provide developers and users a modular approach for defining and adding new capabilities to a federate or federation, and in quickly composing object models such as HLA FOMs and SOMs through BOM Assemblies.

<back to the top>

What is a FOM?

A specification defining the information exchanged at runtime to achieve a given set of federation objectives. This includes object classes, object class attributes, interaction classes, interaction parameters, and other relevant information.  – IEEE 1516.0 – Rules

<back to the top>

What is a SOM?

A specification of the types of information that an individual federate could provide to High Level Architecture (HLA) federations as well as the information that an individual federate can receive from other federates in HLA federations. The standard format in which SOMs are expressed facilitates determination of the suitability of federates for participation in a federation.

<back to the top>

What is a federate?

A federate refers to a simulation, an interface to a live system, or a supporting utility such as a Logger, Plan View Display, or Stealth Viewer.

<back to the top>

What is a federation?

A federation is a set of federates capable of interoperating within a distributed environment.

<back to the top>

What is meant by ontology?

By ontology, we adopt the common definition that it is a “formal specification of how to represent the objects, concepts and other entities that are assumed to exist in some area of interest and the relationships that hold among them.”

<back to the top>

What does a BOM contain that I don't find in a FOM or SOM?

A BOM (and BOM Assembly) provides three essential differences from a FOM or SOM.

First, it encourages a modular approach for defining and representing federate and federation capabilities.  Consider that a FOM or SOM provides a monolithic representation that collectively describes all the object classes and interaction classes.  This makes it very difficult to decompose into manageable units.  A change to a part of FOM or SOM, whether small or big, can significantly effect the federates and federates that use the FOM or SOM.

Second, it provides a mechanism for capturing not only richer metadata, such as purpose, use limitation, and use history, but also behavior description such as the actions supporting a pattern of interplay, the state machine for a conceptual entity, and the events that transpire among conceptual entities.

Third, while it provides richer metadata and behavior description, it does not require some of the other federation and RTI specific OMT information required of a FOM or SOM.  For more information regarding this difference, please see the question that asks if BOMs are only applicable for HLA?

<back to the top>

What is a BOM Assembly?

A BOM Assembly is a composition of BOMs which can result in a FOM, SOM or pattern that encompasses a larger scope.  The Pattern Description within a BOM Assembly is used to identify other BOMs that support the actions (or activities) that are necessary to fulfill a higher-order objective or capability.  This coupling and hierarchy of BOMs is for representing a federate, federation or an aggregation. In fact in support of HLA, a FOM can be generated from a BOM Assembly.

<back to the top>

What is the difference between a BOM Assembly and a FOM?

While a BOM Assembly can be used to represent a composite interface of a federation much like a FOM, the difference is that a BOM Assembly carries with it the metadata that is neglected within a FOM or SOM.  This includes things such as intent and integration experience.  Furthermore, the BOMs that make up a BOM Assembly allow greater support for configuration management and modularity since the components and piece-parts that provide functionality for a federate or federation can be easily cataloged by the interface provided by the BOM.

<back to the top>

Are BOMs only applicable if I am using HLA?

No, actually BOMs (and BOM Assemblies) are not exclusive to HLA federates and federations.  While the BOM standard leverages elements from the HLA Object Model Template (OMT), such as Object Classes, Interaction Classes and Data Types, BOMs are not restricted by the constrains of HLA.  For instance, there is no routing spaces or dimensions defined in a BOM, which would tie it to the Run-time Infrastructure (RTI).   Thus, it is possible for other distributed simulation architectures to utilize BOMs as a mechanism for representing capabilities and building agreements among an enterprise of simulations.

<back to the top>

Can UML be used to define BOMs?

While UML diagrams are used frequently to illustrate BOMs and provide a mechanism for understanding a pattern of interplay, and state machines, UML, in itself, is not sufficient for capturing BOMs.  It is essential to be able to capture the behavior information of patterns, states and events in a context that is appropriate for supporting but not limited to HLA. What is needed is the notation conforming to a standardized template containing the necessary pattern information that is described using HLA OMT constructs.   This template is provided by the BOM Template Specification. In this manner no new notation(s) need be learned for those who are not UML-savvy, additionally it allows for existing and emerging HLA tools to easily adopt and utilize this template.

<back to the top>

How is the functionality described by a BOM supported? Is there a prescribed language for BOM Components?

BOMs are intended to serve as an interface mechanism using XML, but there is no prescribed programming or markup language for supporting BOM component implementations (BCIs).  The functionality described by a BOM interface is intended to be supported independently through one of the following means:

  • a specific system or subsystem, such as the capability provided by a live system
  • application source code for a virtual or constructive simulation
  • a byte code module, such as a Java Bean that might be used by a simulation*
  • a binary object such as a Windows DLL, a Unix Object that might be used by a simulation*
  • a markup or script language, such as a Simulation Reference Language Markup (SRML) module with embedded JavaScript, or a Flash Action Script component*

This separation of a piece part’s interface and its implementation facilitated by the BOM standard allows composability to be supported across a wide range of hardware platforms, operating systems and languages.

*Indicative of a BOM Component Implementation (BCI). See “What is meant by component or piece part?

<back to the top>

What is meant by component or piece part? What is the difference?

A component refers to the embodiment of functionality used for representing or supporting an element of a simulation.  Whereas piece parts, as described in the HLA FEDEP document, are individual classes or whole BOMs that can be used as building blocks in the construction or augmentation of a FOM. In this context, a piece part lacks the functionality a component might embody, but does serve to provide the interface elements of an object model.

To be more precise, the BOM provides, as a piece part, an interface for describing the behavior elements of a simulation and/or relationships among conceptual entities within a simulation environment.  The type of piece parts that can be formally represented by a BOM included object classes, interaction classes, patterns of interplay, state machines, and events.

As far as component support, BOM Component Implementations (BCIs) can be developed and offered that provide the functionally described by a BOM for a specific language or platform.  Examples of BCIs include a Java Bean, a Windows DLL, a Unix DSO, an Active X component, an SRML module which contains JavaScript, or a Flash component which contains ActionScript.

<back to the top>

Explain further what is meant by “Pattern of Interplay”?

BOMs are unique in that they are able to represent or support discrete patterns of interplay within or among simulations.  A pattern of interplay reflects the relationship of actions among one or more conceptual entities that are carried out to accomplish a common objective, capability, or purpose.

As an example, consider a Weapons Fire effect that is prevalent in many simulation interoperability exercises.  The conceptual entities include a shooter and a target.  The actions between these conceptual entities include a fire and, if successful, a detonation, which results in a damage state update by the target.  This set of actions represents a pattern of interplay, which can be defined and packaged as a BOM.

<back to the top>

Explain further what is meant by “State Machine”?

BOMs are also unique in that they allow the state machine for a conceptual entity, which is to be represented or modeled in a simulation environment, to be defined.  A state machine identifies the various states or conditions of a conceptual entity, and how the actions associated to one or more patterns of interplay may affect these conditions over its life.

Identifying states and the mechanisms that cause a change in condition, known as a state transition, allows a BOM to reveal an interface representation without requiring knowledge of its implementation.  In other words, these states allow us to understand the conditions of a conceptual entity without having to know about the functional model behavior.  Thus this element of a BOM continues to maintain separation from the implementation.

Coincidently, the idea of states was something described in the 1278 DIS specifications, but has never been something that could be captured in the HLA OMT.  There are typically different states of behavior represented by a conceptual entity.  State transitions (and resulting changes in object classes attribute values) result when a “model interacts with a simulation environment.”  In BOM-speak, these actions, which facilitate a state transition, are supported by Events, which can be Messages (directed) or Triggers (undirected), or potentially other BOMs.

<back to the top>

What do you mean by “conceptual entity”?

The term conceptual entity refers to an abstract representation of a real world entity, phenomenon, process, or system. Examples of conceptual entities might be a tank, an environmental effect, a communication infrastructure, or a pilot in operation of a plane.  In UML, this idea of a conceptual entity can be associated with the concept of an “actor”, which refers to an external entity that has behavior and interacts with the system.

It should be noted that a conceptual entity can be defined by one or more object classes within a BOM.

<back to the top>

What are “Events” in BOMs?

In BOM-speak, an Event is a representation of a transient action that occurs among conceptual entities which may affect the state of one or more of the conceptual entities.  Triggers and Messages are the two types of BOM events.  A Trigger is an event, which is not directed to one or more specific receivers, whereas a Message is an event, which is directed to one or more specific receivers.  Typically a Trigger is supported by an HLA type Object Class / Attribute, where a change in the attributes value elicits the trigger.   A Message is typically supported by an HLA type Interaction Class.

An example of a trigger might be an attribute of an object class that changes, and based on the change, the states of other conceptual entities might change. The classic example uses for this example is the time clock, where employees may monitor the clock while working and once the time reaches a certain value, the employees react by taking a break or clocking out for the day.   In this example, the clock is not directing the employee; in fact, it has no knowledge of the employee.

An example of a message is when a directed interaction is targeted for other conceptual entities.  An example of a message might be a radio transmission, which is an interaction that requires at radio to initiate the transmission and the addition of one or more radios to receive the transmission.

The difference between a message and a trigger can sometimes be difficult to distinguish, but the basic principle is that messages are directed exchanges of information (e.g. someone telling something to someone else) where the sender knows about the intended receiver of the message. A trigger is an undirected exchange of information.

<back to the top>

What is meant by “Composability”?

Composability is defined by Petty as “the capability to select and assemble components in various combinations into complete, validated simulation environments to satisfy specific user requirements.” BOMs provide a specification to describe components at the interface level, and also promote independent representation of functionally for any type of platform or language at the implementation level, which are described as BOM component implementations (BCIs).  As a result, BOMs or supporting BCIs can be selected and assembled, in a meaningful way through the various metadata, behavior description, and model definitions that can be exposed.

<back to the top>

Why would I want to create a BOM? Or use someone else’s?

Creating a BOM is a way to document your model in a standardized “metadata rich” format that helps maintain modularity and helps facilitate its reuse by others.  The benefit of BOMs is that it provides a means for supporting the following:

  • Composability – BOMs and any supporting functional models can be combined and used to support federation agreements and/or enable federate capabilities.
  • Exchangeability – BOMs can be swapped and replaced by other BOMs, which provides a means for serving more sponsor-focused interests and greater simulation-asset capabilities.
  • Extensibility – new BOMs can be added more easily to an existing BOM set representing a FOM.
  • Manageability – BOMs can be individually managed, controlled, versioned, verified, and validated.
  • Understandability – BOMs provide more information than SOMs or FOMs which leads to understanding the BOMs intent, limitations, and how it can be integrated and used.  Furthermore, the capability exists to capture the integration experiences for those that have used a BOM.  This is reflected as “use history.”

As to why you should use a BOM, consider that if a BOM already exists that provides the interface to a model that is desired for a particular application (i.e. federation), then wouldn’t it make sense to use that existing model instead of repeating the development process (recreating it)?  Furthermore, the existing BOM would provide use-history and other related metadata that would help assist in making the decision as to whether a model satisfies a project’s requirements.  And if functional components (i.e., BCIs) exist that support that BOM interface for your platform or language, wouldn’t it be helpful to leverage and integrate those components as well?

Consider also how the standardized format prescribed for a BOM can allow for greater automation through the development process.   For example, once the functional requirements and conceptual models have been identified in early in the process, then that information could be used to discover and evaluate candidate BOMs.

<back to the top>

The idea of reuse has been often discussed but never fully realized within the M&S community.  How does the BOM make reuse a reality?

Those involved in the BOM standard development effort have worked hard to overcome many of the common barriers to reuse.  These activities, which focus on breaking through these barriers, include:

  • Focusing on the design level instead of the implementation level
  • Finding ways to promote automation to expedite the discovery and evaluation of BOMs
  • Filling BOMs with appropriate metadata because documentation is often inadequate
  • Finalizing a specification for creating and using BOMs that can be considered for standardization so that we minimize errors and subtle differences in the interfaces

While these goals have been realized, ultimately reuse becomes reality once the experiences and successes are shared by those organizations that apply, build and use BOMs and supporting BOM component implementations (BCIs).  This will result in a validated BOM specification with the necessary guidance to build simulations and simulations spaces with ease and regularity.

<back to the top>

What is the anticipated impact of BOMs?

Perhaps the only fair way to answer that question is to take a look at the impact that components have had in other communities.  Common examples include the electronic component industry and software development industry.

In the software development world, for example, we went from punch cards and single line editors within the past 30 years to the Rapid Application Development (RAD) tools of today, which provide us with fully integrated development environments that allowed access to frameworks and components that we can drag and drop on our application canvas.  For example, in just a few minutes it’s possible to put together a Word-like application simply by reusing pre-developed components within a tool like Visual Basic, Visual C#, Delphi, C++Builder, or JBuilder . The key to this RAD approach is not the tools but the components used by these IDE tools.  These same benefits of RAD are possible in the simulation development world through the advancement of the BOM concept as a formal and open standard, the proliferation of tools, and the availability of BOM components.  Simulation developers will be able to more quickly and easily compose simulations and simulation spaces because a community backed component-based infrastructure is in place and the components are readily available.

Thus, the potential impact is huge: greater reuse, better interoperability, rapid composability, increased FEDEP automation, and perhaps even dynamic adaptability among BOM-based federates during an execution. Plus, it creates greater opportunities to extend modeling and simulation into other industries such as education, manufacturing, medical, and more!

<back to the top>

What else is needed to support this vision of RAD for simulation compositions beside BOMs?

In addition to a BOM standard, BOM components and a set of next generation tools and web services (such as collaborative development environments and repositories) are needed that support the creation, deployment and use of BOMs for simulation development, maintenance, and run-time support. In short we need tools, repositories, and lots of BOMs and representative BOM implementations, but we also need the practical experience behind using BOMs.   We need case studies and integration stories, which are shared within the community and proof out the functional specification.

<back to the top>

How do you go about building and using a BOM?

One of the supporting documents that is recommended is the “Guide for BOM Use and Development.”  This document identifies how you go about building and using a BOM.

Another resource that is helpful is the Federation Development and Execution Process (FEDEP).   The FEDEP is an IEEE standard, which provides a systems engineering perspective on developing and supporting distributed simulation environments as it relates to the High Level Architecture (HLA).  BOMs are specifically identified in the FEDEP as a potential facilitator for providing reusable object model components used for the rapid construction and modification of simulations and simulations spaces.

<back to the top>

Can a group of OMT object classes and interactions be identified within a BOM without expressing a “Pattern Description”?

Yes, it’s possible to identify the characteristics of a single conceptual entity without also having to define a pattern description.  Keep in mind a BOM is intended to be used to represent and/or support a pattern of interplay.  So if a pattern description is not included in the BOM, then it is anticipated that the BOM is a support element for one or more patterns of interplay.  This includes the following:

  • a state machine describing the behavioral states of a conceptual entity
  • object class(es) needed to represent a conceptual entity
  • event(s) carried out by a conceptual entity that affects other conceptual entities, and which are used to carry out the actions within a patterns of interplay
  • interaction class(es) needed to support interchange among the federates, and which may be needed to fulfill a BOM event such as a message or trigger
  • data type(s) that define the structure for attributes and parameters of an object class or interaction class

<back to the top>

What makes a BOM interoperable and platform independent so that any system can discover and use it in an individual simulation system?

A BOM makes use of the eXtensible Markup Language (XML). The application of the XML and XML Schemas prescribed for BOMs provides a mechanism for defining and validating context, and facilitates understanding of the data being exchanged in a platform independent manner.  The BOM architecture utilizes the XML for the following means:

  • Capturing Patterns of Interplay representing the relationship of activities among conceptual entities (Federation Agreement Level)
  • Defining Relationship of States within a conceptual entity to support patterns (Federate Capability Level)
  • For supporting the essential metadata to be captured, cataloged, and carried forward within a BOM (examples include purpose, integration history, relevant references, etc…)
  • For promoting adaptability via the Extensible Language Transformation (XSLT) between similar but different BOMs
  • For addressing a breadth of community interests

<back to the top>

will web services provide the automated infrastructure for the community to explore a BOM repository where a desired component can be used in a user’s system?

One of the biggest areas of influence is the reuse aspect and cross platform accessibility that web services provide for both the development network and the federation network.  For instance web services can be used to establish a conduit for automation and collaboration and possibly used, earlier on, to support conceptual modeling.  The services that are envisioned include web enabled repositories containing and/or providing the following:

  • Database elements and enumeration information
  • BOMs as reusable patterns that can be fetched
  • Reusable component models that can be dynamically loaded by federates during an execution
  • 3D models that can be utilized for visually representing entities
  • The discovery and deployment of self attaching process agents used to support the adaptability of systems based on “different” interfaces (represented using BOMs and Mega BOMs)

These agents would enable communication and interoperability among disparate systems and could provide federate support during a federation execution.  Web services can also be used to support pattern aggregation (model composition) and dynamic entity aggregation.

<back to the top>

How does the BOM fit with the eXtensible Modeling and Simulation Framework (XMSF)?

As best understood, XMSF is interested in the breadth of elements needed to support web-based M&S interoperability.  The collection of these elements formulates what is called an XMSF Profile.  An example of an XMSF profile might include identified standards for networking, M&S, web-service technologies and, bridges to C4I.  Technologies like BOMs and the Simulation Reference Markup Language (SRML) would fit into a Profile as enabling technologies for XMSF.

Perhaps an easier way to think of it is this way:  Imagine XMSF as being a glove, which is intended to give you a better handle on what’s needed to support web-based M&S interoperability.  BOMs and other technologies such as SRML and SOAP are the fingers to the hand that fit into that glove. You can certainly function without the glove, but the XMSF glove (or Profile) provides a framework for integrating those technologies.

Incidentally, one of the identified needs of XMSF is the ability to “support composable, reusable model components” and “not be constrained by proprietary technology.”   BOMs have been recognized as a fitting and appropriate candidate to support that need.

<back to the top>