Tram Chase tchase@simventions.com Real-Time Platform Reference (RPR) Base Object Model (BOM) Composability Standard for Enabling Interoperability A B C.

Tram Chase tchase@simventions.com
Real-Time Platform Reference (RPR) Base Object Model (BOM) Composability Standard for Enabling Interoperability A B C X Conceptual Federate Federation Tram Chase

BOMs are designed for enabling model composability.
Key Concept - Using Base Object Models (BOMs) as Building Blocks Definition Concept Standards BOM – A piece part of a conceptual model, simulation object model, or federation object model, which can be used as a building block in the development and/or extension of a simulation or federation. BOM Palette - x Simulation Components Choose what fits conceptual model? User Requirements A B Simulation Systems foms federates X C Illustration State Machines Pattern of Interplay Events Federate (SOM) Sim / System A Weapons Effect BOM 1 BOM 2 Theater Warfare Representation Detect / Jam Federate A Federate B BOM 3 - or - Federation (FOM) BOM Assembly Repair Resupply Composition Representation Federate X Composite Interface BOM n - or - Model #1 Model #2 Radio Comms Aggregation Model #3 Model #n BOMs are designed for enabling model composability.

RPR BOM Initiative To provide a set of applicable BOMs to community
RPR BOMS Behavior Representations Weapon Effects Repair Resupply Collision Transfer Control Simulation Management Radio Communications Entity/Object Management Minefield Synthetic Environment Object Representations Entity Object Types Env Object Types Minefield Object Types Signal Object Types To provide a set of applicable BOMs to community Leverage RPR FOM 2.0 (& GRIM) Decompose into BOMs Add Additional Metadata (including States from 1278) Encourage participation/input from RPR FOM PDG Other community members Identify and report on benefits (i.e., “ility” support) Composability Extensibility Exchangeability Manageability Understandability Framework for supporting RPR V3 objective? RPR BOM Assembly Release Dates April 05 RPR BOM Set 1.0 released based on v0.10 draft spec Sept 05 RPR BOM Set 1.0 released based on V0.12 draft spec July 06 RPR BOM Set Version 1.0 (FINAL) released State Machines Pattern of Interplay Events With the RPR FOM things are melded together and presented as one combined model group little opportunity for “reusing” common model pieces or exchanging one pattern of interplay for another provide 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. Related Papers 05S-SIW “RPR-BOM Initiative: Providing a Set of Applicable BOMs to the M&S Community” 06S-SIW-115 “From FOMs to BOMs and Back Again”

Hierarchical View of the RPR BOMs…
RPR FOM 2.0 Behavior Rep Weapons Effect Collision Entity/Object Management Minefield Synthetic Env SIMAN Logistics RadioComms Transfer Control Repair Resupply Behavior Representations Weapon Effects Repair Resupply Collision Transfer Control Simulation Management Radio Communications Entity/Object Management Minefield Synthetic Environment Includes Model Mapping Entity Creation Entity Reconst’n Entity Removal Action Request Post Comment Post Event examine the DIS PDU specification original document that the RPR FOM development team used identifies a common set “types and families of Protocol Data Units (PDUs). not explicitly called “patterns of interplay” but close RPR FOM 2.0 DIF Guidance, Rationale, and Interoperability Manual (GRIM) for the RPR FOM little opportunity for “reusing” common model pieces or exchanging one pattern of interplay for another Object Rep EntityObjects EnvObjects MinefieldObjects SignalObjects Object Representations Entity Object Types Env Object Types Minefield Object Types Signal Object Types

RPR BOM Illustration #1 Weapons Effect Federation Activities
State Machines Pattern of Interplay states pattern actions Derived from RPR FOM Weapons Fire is a pattern that is prevalent in many simulations and federations. The conceptual entities include a shooter and a target. The activities 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 activities represents a pattern of interplay, which can be defined and packaged as a BOM. Figure 3.1 illustrates a UML sequence diagram representing this pattern of interplay. The vertical lines in this diagram represent the life-time of the object instances which are labeled at the top. The horizontal lines represent the actions that occur among these object instances. Additionally, this sequence diagram has been decorated with numbered circles identifying the sequence of the action within the pattern of interplay and the states for both the shooter (firing entity) and target (target entity) as boxes beside each objects life-time. The UML diagram we have used to illustrate this BOM has provided a mechanism for understanding the pattern of interplay. However, UML, in itself, is not sufficient for capturing BOMs. It is imperative 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 [7]. In this manner no new notation(s) needs to 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. Federation Activities Federate Capability

RPR BOM Illustration #2 Logistics Activities REPAIR RESUPPLY 1 2 3 1 2
Ready Request/Receive Repair Complete Offering 1 2 3 Ready Requesting Receiving Offering 1 2 3 ResupplyCancel Interaction Class ResupplyOffer Interaction Class ResupplyReceived Interaction Class ServiceRequest Interaction Class RepairComplete Interaction Class RepairResponse Interaction Class ServiceRequest Interaction Class Could be the same Could be the same “The use of [the logistics] interaction classes involves a detailed understanding of the state transitions and timing between events.” - RPR FOM GRIM Conceptual Entities Requester / Consumer Repairer Supplier

The BOM Elements? An Inside Look
Essential metadata needed so that the BOM can be described, discovered and properly reused Model Identification (Metadata) Notes Lexicon (definitions) Object Model Definition HLA Object Classes HLA Object Class Attributes HLA Interaction Classes HLA Interaction Class Parameters HLA Data Types Conceptual Model Pattern Of Interplay State Machine Entity Type Event Type Model Mapping Entity Type Mapping Event Type Mapping An XML based standard for capturing model metadata, aspects of the conceptual model, the class structures of an object model which are to be used by a system (and a federation) for representing the conceptual model aspects, and the mapping that exists between that conceptual model and object model. Conceptual entities and the events which occur among those entities as well as the states attainable by those entities. Not all these pieces are required for a BOM… Mapping of conceptual entities and events to object model object and interaction classes. A BOM is a standards-based approach for describing a reusable component or piece part of a simulation or system. BOMs are unique in that they are able to represent or support discrete patterns of interplay among conceptual entities within a simulation environment. BOMs are intended to serve as building blocks for supporting composability. This includes the composition of HLA object models, federate capabilities, and / or federation agreements irregardless of the hardware platform, operating system, or programming language required of a participating federate. Object classes, interaction classes, and datatypes used to perform the behavior described in the conceptual model. Notes and definitions supporting any of the above mentioned elements BOM template allows BOMs to be captured in a reusable way

Comparing FOMs to BOMs BOM FOM
Model Identification (Metadata) Model Identification (Metadata) HLA Object Classes Conceptual Model Pattern Of Interplay State Machine Entity Type Event Type HLA Object Classes HLA Object Class Attributes HLA Interaction Classes HLA Interaction Classes HLA Interaction Class Parameters Model Mapping Entity Type Mapping Event Type Mapping BOM FOM HLA Dimensions HLA Time Object Model Definition HLA Tags HLA Object Classes HLA Object Classes HLA Synchronizations Break up to make easier to manage/maintain… In the case of the RPR FOM, breaking up the object classes is somewhat intuitive. The class names do a good job of representing the associated functional area. For instance, there are eight classes at the root listed below. ActiveSonarBeam BaseEntity EmbeddedSystem EmitterBeam EnvironmentObject EnvironmentProcess GriddedData Minefield With some analysis, it makes sense to group these classes as follows. The result of our analysis produces four groupings, that can be supported by a BOM: Entity Objects Signal Objects Environment Objects Note that this is only one way of grouping the object classes. They could be broken down further to help isolate areas that are constantly changing for easier maintenance. For example, the BaseEntity classes could be further broken down based upon domain such as land, sea, or air. Once the groups have been decided upon, BOMs must be created that contain the classes, associated attributes, data types, and notes as represented in Figure 3.1. With the help of a tool, this process can be automated to allow drag/drop or cut/copy/paste of classes from a FOM (1.3 or 1516) to a BOM. The tool would automatically populate the BOM with the needed attributes, data types, and notes. The object class table is shown in Figure 3.2 along with the current breakdown of the object classes into our four groupings: Entity Objects, Signal Objects, Environment Objects, and Minefield Objects. HLA Object Class Attributes HLA Transportations HLA Interaction Classes HLA Interaction Classes HLA Switches HLA Interaction Class Parameters HLA Data Types HLA Data Types Notes Notes Lexicon (definitions) Lexicon (definitions)

You Can Use BOMs in Multiple Ways!
Model Identification (Metadata) Lexicon (definitions) Conceptual Model Definition Pattern of Interplay State Machine Entity Type Event Type Notes) Model Identification (Metadata) Notes Lexicon (definitions) Model Mapping Entity Type Mapping Event Type Mapping Model Identification (Metadata) Notes Lexicon (definitions) Object Model Definition HLA Object Classes HLA Object Class Attributes HLA Interaction Classes HLA Interaction Class Parameters HLA Data Types Conceptual (Behavioral) Mappings Object (Class Structures)

This is what we did with the RPR BOMs…
Model Identification (Metadata) Model Identification (Metadata) Model Mapping Entity Type Mapping Event Type Mapping Conceptual Model Pattern Of Interplay State Machine Entity Type Event Type Behavior (Conceptual) BOM Object (Class Structure) BOM Object Model Definition Object Model Definition HLA Object Classes HLA Object Class Attributes A BOM is a standards-based approach for describing a reusable component or piece part of a simulation or system. BOMs are unique in that they are able to represent or support discrete patterns of interplay among conceptual entities within a simulation environment. BOMs are intended to serve as building blocks for supporting composability. This includes the composition of HLA object models, federate capabilities, and / or federation agreements irregardless of the hardware platform, operating system, or programming language required of a participating federate. Object Model Definition HLA Interaction Classes HLA Interaction Class Parameters HLA Data Types HLA Data Types Notes Notes Lexicon (definitions) Lexicon (definitions)

This is what we did with the RPR BOMs…
Behavior Representations Weapon Effects Repair Resupply Collision Transfer Control Simulation Management Radio Communications Entity/Object Management Minefield Synthetic Environment Object Representations Entity Object Types Env Object Types Minefield Object Types Signal Object Types We found the easy thing to do was pull out the HLA object classes into object groupings. We also found a logical connection between the “patterns of interplay” being represented by the RPR FOM (going back to DIS PDU families) and the “HLA Interaction classes” that were defined. So we decided to keep the interaction classes with the conceptual model Remember this is just one way!!!

We could have done it this way…
Model Identification (Metadata) Notes Lexicon (definitions) Object Model Definition HLA Object Classes HLA Object Class Attributes HLA Interaction Classes HLA Interaction Class Parameters HLA Data Types Model Mapping Entity Type Mapping Event Type Mapping Model Identification (Metadata) Lexicon (definitions) Conceptual Model Definition Pattern of Interplay State Machine Entity Type Event Type Notes) Behavioral (Conceptual) BOMs We could have put the Mappings in the Object-based BOMs. But we felt that the mappings were better served tethered to the Behavior (Conceptual) BOMs This example also shows that both the interaction classes and object classes could have been isolated from the Behavioral (Conceptual) BOMs Object (Class Structure) BOMs

Or this way… Mappings Behavioral (Conceptual)
Model Identification (Metadata) Notes Lexicon (definitions) Object Model Definition HLA Object Classes HLA Object Class Attributes HLA Interaction Classes HLA Interaction Class Parameters HLA Data Types Model Identification (Metadata) Notes Lexicon (definitions) Model Mapping Entity Type Mapping Event Type Mapping Model Identification (Metadata) Lexicon (definitions) Conceptual Model Definition Pattern of Interplay State Machine Entity Type Event Type Notes) Mappings Behavioral (Conceptual) Object (Class Structures) We could have also made independent mappings – thus making them their own BOMs. There is no real wrong way to break a FOM up into BOMs.

BOM Assemblies Repair BOM WeaponsFire BOM BOM Assembly
Model Identification (Metadata) Notes Lexicon (definitions) Object Model Definition HLA Interaction Classes HLA Parameters HLA Data Types Conceptual Model Pattern Of Interplay State Machine Entity Type Event Type Model Mapping Entity Type Mapping Event Type Mapping WeaponsFire BOM Model Identification (Metadata) Notes Lexicon (definitions) Object Model Definition HLA Interaction Classes HLA Parameters HLA Data Types Conceptual Model Pattern Of Interplay State Machine Entity Type Event Type Model Mapping Entity Type Mapping Event Type Mapping Model Identification (Metadata) Conceptual Model Pattern Of Interplay State Machine Entity Type Event Type BOM Assembly Notes Lexicon (definitions) Model Identification (Metadata) Notes Lexicon (definitions) Object Model Definition HLA Object Classes HLA Attributes HLA Data Types EntityObjects BOM A composition of BOMs that can result in a Federation Object Model (FOM), Simulation Object Model (SOM), or pattern which encompasses a larger scope.

Exporting a FOM BOM Assembly FOM XSLT/ Method of choice
Model Identification (Metadata) Notes Lexicon (definitions) HLA Object Classes HLA Object Class Attributes HLA Interaction Classes HLA Interaction Class Parameters HLA Data Types HLA Dimensions HLA Time HLA Tags HLA Synchronizations HLA Transportations HLA Switches FOM Model Identification (Metadata) Notes Lexicon (definitions) Object Model Definition HLA Object Classes HLA Object Class Attributes HLA Interaction Classes HLA Interaction Class Parameters HLA Data Types Conceptual Model Pattern Of Interplay State Machine Entity Type Event Type Model Mapping Entity Type Mapping Event Type Mapping XSLT/ Method of choice

Object Representations
Entity Object Types Signal Object Types Env Object Types Minefield Object Types Entity Objects Again, this is what we did with the RPR BOMs. These are the HLA Object Classes from the original RPR FOM categorized into four sets. Signal Objects In the case of the RPR FOM, breaking up the object classes is somewhat intuitive. The class names do a good job of representing the associated functional area. For instance, there are eight classes at the root listed below. ActiveSonarBeam BaseEntity EmbeddedSystem EmitterBeam EnvironmentObject EnvironmentProcess GriddedData Minefield With some analysis, it makes sense to group these classes as follows. The result of our analysis produces four groupings, that can be supported by a BOM: Entity Objects Signal Objects Environment Objects Note that this is only one way of grouping the object classes. They could be broken down further to help isolate areas that are constantly changing for easier maintenance. For example, the BaseEntity classes could be further broken down based upon domain such as land, sea, or air. Once the groups have been decided upon, BOMs must be created that contain the classes, associated attributes, data types, and notes as represented in Figure 3.1. With the help of a tool, this process can be automated to allow drag/drop or cut/copy/paste of classes from a FOM (1.3 or 1516) to a BOM. The tool would automatically populate the BOM with the needed attributes, data types, and notes. The object class table is shown in Figure 3.2 along with the current breakdown of the object classes into our four groupings: Entity Objects, Signal Objects, Environment Objects, and Minefield Objects. Environment Objects MinefieldObjects

BOM to FOM: Major Steps Create a BOM Assembly Atomize BOM-Assembly
Pattern Action n BOM (Another Pattern) 1 Create a BOM Assembly Independent BOMs identified in Pattern Description Atomize BOM-Assembly Model Definition only carries one level of object classes / interaction classes Pattern Descriptions link BOMs Transform to FOM (HLA) Recommend use of XSLT BOM Assembly SOM Xformation FOM n BOMs Aggregate Model

Inside a RPR BOM Weapons Effects

BOM Metadata Structure
Model Identification (Metadata) Conceptual Model Pattern Description State Machine Entity Type Event Type Name Type Version Modification Date Security Classification Release Restriction * Purpose Application Domain Description Use Limitation Use History * Keyword Taxonomy/Value * POCs * Type Name Organization Telephone References * Other Glyph Type Image Alternate Text Height Image Model Mapping Entity Type Mapping Event Type Mapping Object Model Definition Object Classes HLA Object Class Attributes HLA Object Classes Interaction Classes HLA Interaction Class Parameters HLA Interaction Classes HLA Data Types The one element that we haven’t talked about to any extent is the Model Identification element, and yet this may be the most important. The Model Identification provides the means to identify and tag the critical metadata for cataloging conceptual models and components. Metadata can be simply described as data about data. It is a way to label and describe information and is used “to aid in the identification, discovery, assessment, and management” of that information (“Final Report on Metadata,” 2000).” The Model Identification provides a structure to document what a BOM (or even other models) is all about – what it contains. One would not purchase a bottle of medicine without first seeing and understanding the label. An unlabeled medicine bottle, soda can, or packaged food product, would go unused. Its content never understood. Likewise, it is important to label a conceptual model or component. This Model Identification structure is based on a combination of other metadata efforts and products such as Dublin Core, the Department of Defense (DoD) Discovery Metadata Specification (DDMS), VV&A Recommended Practice Guide (RPG), and the HLA Object Model Template (OMT), IEEE * Multiples Allowed Model Identification Table primary purpose of this metadata is to allow the discovery and understanding of models & components.

Example – Model Identification
This is the metadata Leveraged elements from HLA OMT, Dublin Core, DDMS, VV&A RPG Helps make components/piece-parts meaningful! Category Information Name WeaponsEffect Type BOM Version 1.0 Modification Date Security Classification Unclassified Release Restriction Not for release outside the I/ITSEC community Purpose Warfighter Training, Testing Application Domain Realtime Platform Testing/Training Simulation Description This is an example BOM Use Limitations None Use History Initial release Keyword Taxonomy Military Warfare Keyword Value Engagement POC POC Type Primary author POC Name P. Gustavson POC Organization SimVentions POC Telephone Reference Ref Type Glossary Identification ISBN Conceptual Model Other na Glyph Image Alt WeaponEffectPicture1 Height 32 Width Here is an example of a completed Model Identification for labeling our weapons effect model, a BOM that we intend to use in our Joint training environment. The following suggestions are recommended as pointers to filling out the Model Identification for a conceptual model or component which is captured within a BOM, (Gustavson, Scrudder, Lutz, & Bachman, 2005). First, document a model in such a way that its Purpose is clear, Use Limitations are identified, the Application Domain is understood, and multiple POCs, such as sponsor representative, and developers are known. Encourage integration experience of models to be fed back into the Use History. This is vital for increasing use of the model to support various efforts such as creating a Joint training exercise environment. Use the mechanisms provided to help manage and control the model through the Version, Security Class, and Release Restriction. Take advantage of the ability to Reference other information such as supporting documents, databases, scenarios, and 3D models. In general, keep things descriptive yet concise. This allows candidate models to be more readily found and reused. And, just because a field may be optional doesn’t mean necessarily that it should be ignored.

Example – Pattern Description
Composed of a collection of actions Describe the activities which transpire among the conceptual entities being modeled Each action supported by events or other BOMs Includes support for variations and exceptions Actions Seq Name Event BOM Sender Receiver 1 WeaponFireAction WeaponFire na FiringEntity TargetEntity 2 MunitionDetonationAction MunitionDetonation 3 DamageStateUpdateAction DamageStateUpdate As stated earlier, one of the anticipated applications of BOMs is to capture a pattern of interplay among conceptual entities. This is accomplished in the Pattern Description portion of the BOM. The Pattern Description is composed of a collection of actions that describe the events which transpire among the conceptual entities being modeled. These events are messages or triggers that have been included in the Events section of the BOM. The Pattern Description actions also contain a source and target property which allows the BOM user to denote which conceptual entities the event occurs between. These allow an object class to be tagged as the conceptual entity that fulfills the responsibilities described by the pattern description. The Pattern Description provides a mechanism needed for identifying the actions (including variations and exceptions) necessary for fulfilling a pattern of interplay. A Pattern of Interplay is a specific type of pattern characterized by a sequence of activities (identified as actions) involving one or more conceptual entities. The activities described for these activities may either tie in with a defined “event” within the BOM (as described in section 3.2.3), or may be referenced by a completely unique BOM all together. The latter supports aspects of composability and representation of higher order patterns

Example – State Machine
Name ShooterStates Conceptual Entities FiringEntity State Ready ExitAction CommandToFire NextState Fire Notes WeaponFireAction MunitionFlight MunitionDetonationAction Name TargetStates ObjectEntityClass TargetEntity State Ready ExitAction WeaponFireAction NextState UnderFire Notes MunitionDetonationAction MunitionFlight ImpactDenotation DamageStateUpdateAction “The use of interaction classes involves a detailed understanding of the state transitions and timing between events.” - RPR FOM GRIM

Example - Entities NOTE: FiringEntity and TargetEntity could be supported by the same EntityType

Example - Events There are three types of characteristics that support an event: source, target and content. Source and Target specify the ”direction” of events. Content defines the information exchanged in the course of the event. There is also a trigger condition which indicates the condition under which this event could be invoked. If the BOM developer specifies a target characteristic, the event type could be said to be a ”Message” and if there is no target but a trigger condition, it is a ”Trigger”.

Model Mapping / Object Model Def
Model Identification (Metadata) Conceptual Model Pattern Description State Machine Entity Type Event Type maps the relationship between the elements in the Conceptual Model space and the interface description elements described in the HLA Object Model Space WeaponsEffect Entity Types Event Types What things in my Training Environment will support Weapons Effect? Model Mapping Entity Type Mapping Event Type Mapping required simulated capabilities defined in the context of an interface description (object classes / interaction classes). represents the information necessary for execution and exchange. Platforms WeaponFire Object Model Definition HLA Object Classes HLA Object Class Attributes HLA Interaction Classes HLA Interaction Class Parameters HLA Data Types Lifeforms Detonations Now that we have filled our BOM with both Conceptual Model content and Object Model content, we should also provide a mapping between the Conceptual Model view and the interface elements of the Object Model view, otherwise it is difficult to understand how the conceptual model can be fulfilled and what the intended capabilities of the object model are. This provides the basis for simulation software design and for the interchange among other simulations, which is particularly important for defining a Joint environment for training. BOMs provide a mechanism for mapping this relationship through an Entity Type Mapping and an Event Type Mapping and are illustrated in the next two tables. Another aspect of BOM content that is useful is the interface description. For a BOM, this interface description, which is identified as the Object Model Definition, is described using HLA Object Model Template (OMT) constructs. The specific HLA OMT constructs used include: HLA object classes, HLA interaction classes, and their attributes and parameters. The use of HLA OMT provides a familiar construct for the simulation software designer, however it is not intended to restrict the use of a BOM to HLA specific implementations. The guidance for filling in the HLA object classes, HLA interaction classes, attributes and parameters for use within a BOM is discussed in the “Guide for BOM Use and Development,” which also refers to the HLA OMT Specification for understanding these tables (SISO-STD DRAFT-V0.11, 2005). Examples for each of these OMT-based tables used to represent a BOM are provided below. Defining a common interface using HLA OMT constructs, which provides a familiar syntax to simulation engineers, allows it to be implemented in multiple environments and frameworks. The use of the HLA OMT provides a familiar construct for the simulation software designer, but does not restrict the use of a BOM to HLA specific implementations. Munitions Collisions Sensors Radio Signal Enviro Objects Repair Resupply Radios Ack Minefield Objects Enviro Object Transactions

Model Mappings FiringEntity
Entity Type Mapping Table Entity Type HLA Object/Interaction Class Characteristics HLA Attributes/Parameters Condtn FiringEntity HLAobjectClassRoot.BaseEntity.PhysicalEntity.Lifeform.Human ID Human.EntityIdentifier NA Location Human.Spatial.SpatialFP.WorldLocation TargetEntity HLAobjectClassRoot.BaseEntity.PhysicalEntity.Platform Platform.EntityIdentifier Platform.Spatial.SpatialFP.WorldLocation Velocity Platform.Spatial.SpatialFP.VelocityVector Event Type Mapping Table Event Type HLA Object/Interaction Class Characteristics HLA Attributes/Parameters Condition Weapon Fire HLAinteractionRoot. WeaponFire FiringEntity_Identifier .FiringObjectIdentifier NA TargetEntity_Identifier .TargetObjectIdentifier MunitionEntity_Identifier .MunitionObjectIdentifier Munition Detonation HLAinteractionRoot. MunitionDetonation MunitionDetonation. FiringObjectIdentifier MunitionDetonation. TargetObjectIdentifier Damage StateUpdate HLAobjectClassRoot. BaseEntity.PhysicalEntity Damage sustained from weapon fire PhysicalEntity. DamageState .DamageState != .previousDamageState

Object Model Def – Attributes Examples
Object Model Def - HLA Object Class Examples Object Model Def – Attributes Examples

Object Model Def - HLA Interaction Class Examples
Object Model Def –Parameters Examples

Filling in the BOM “Object Model Def” Information Available Choices / Default Values
HLA Object Class / Attribute Values Attribute Datatype Update Type Update Condition Ownership P/S Available Dimensions Transportation Order Available Values User defined Static, Periodic, Conditional, NA rate value, on change, condition value, NA D, A, N, DA, NA P, S, PS, N, NA NA HLAreliable, HLAbesteffort, NA Receive, Timestamp, NA Default Selection - HLA Interaction Class / Parameter Values Interaction Parameter Datatype Available Dimensions Transportation Order Available Values User defined Static, Periodic, Condition NA HLAreliable, HLAbesteffort Receive, Timestamp, Default Selection -

Filling in the Object Classes A Graphical Illustration
NA NA NA NA NA NA For BOMs, you are allowed to use the “NA” value to tag many of the fields of the Object Class and Object Class Attributes For an HLA FOM or SOM, however, you may need to specify these fields with something other than NA NA NA

Filling in the Interaction Class A Graphical Illustration
n/a n/a n/a For BOMs, you are allowed to use the “NA” value to tag many of the fields of the Interaction Class and Object Class Parameters For an HLA FOM or SOM, however, you may need to specify these fieds with something other than NA n/a

Backup Slides

Why is Model Composability Desirable?
Creating a simulation requires breaking the problem into parts that can be addressed separately To reduce the effects of interruption To permit specialization To facilitate computing alternative ways of handling a given component To maintain the software over time To reduce risk by relying upon previously proven components where possible Understanding complex systems requires decomposition. No one can comprehend the whole’s details Testing systems is simplified if done module by module then at the system level Controlling M&S costs / economic incentives Costs are correlated with the amount of new code writing Maintaining and modifying M&S Individual modules can be substantively modified or updated as software as necessary, without endangering the overall system. Creating a simulation of a large, complex system requires breaking the problem down into parts that can be addressed separately To reduce the effects of interruption To permit specialization To facilitate computing alternative ways of handling a given component To maintain the software over time To reduce risk by relying upon previously proven components where possible Understanding complex systems requires decomposition. No one can comprehend the whole’s details – much less explain them. Testing systems is simplified if done module by module then at the system level Controlling M&S costs / economic incentives Costs are correlated with the amount of new code writing Maintaining and modifying M&S Individual modules can be substantively modified or updated as software as necessary, with out endangering the overall system. “Modularity is necessary when dealing with complex systems, and some degree of composability is surely possible and desirable.” - Paul Davis (RAND)

BOM Support for MDA Objectives
Define a model that specifies your system and its behavior without providing the details of how the computational infrastructure will support it The role of abstractions Model should describe the system from several perspectives Structure, collaboration, activity, sequence, state UML with executable extensions Model should provide increased portability through abstraction Model should provide sufficient detail Completely specify behavior with action specification Use of ASL, state charts, sequence charts Satisfy mission requirements Transform the system model to executable code with model compiler tools tailored for target environment Possibly several build stages: compile to lower level language, then object code, then binary Rebuild as needed from the system model Requirements changes Different or updated environments BOM BOM BOM Action Semantic Language. Action semantics describe the imperative that is the dynamic behaviro. BOM

Tram Chase tchase@simventions.com Real-Time Platform Reference (RPR) Base Object Model (BOM) Composability Standard for Enabling Interoperability A B C.

Similar presentations

Presentation on theme: "Tram Chase tchase@simventions.com Real-Time Platform Reference (RPR) Base Object Model (BOM) Composability Standard for Enabling Interoperability A B C."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Tram Chase tchase@simventions.com Real-Time Platform Reference (RPR) Base Object Model (BOM) Composability Standard for Enabling Interoperability A B C.

Similar presentations

Presentation on theme: "Tram Chase tchase@simventions.com Real-Time Platform Reference (RPR) Base Object Model (BOM) Composability Standard for Enabling Interoperability A B C."— Presentation transcript:

Similar presentations

About project

Feedback