1. BOMs – Base Object Models
Björn Löfstrand
Manager M&S Services, Pitch Technologies
Arkitekturdag 3, FMV, Stockholm, December 2006

2. BOM Definition Piece-part approach to Modeling
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
SISO-STD
Piece-part approach to Modeling
Conceptual Models
With focus on Simulation
Information Exchange Data Models
With focus on Federated Systems based on HLA
Provides linkage from conceptual elements to constructs for information exchange in a federated system

3. Basic Concept Simulation Conceptual Model
(Representation of relevant “stuff” in the “real world” at a level of description necessary to achieve the goals of the system)
How to find the right levels of description is an art not covered by BOMs.
Some aspects of a conceptual model can be captured in a BOM and used as a building-block for conceptual modeling
BOMs can provide a link between conceptual elemetns such as entities, actions and events to information exchange constructs (e.g. HLA FOM).
Federation of Distributed Systems/Simulation
(Federates with the collective responsibility of modeling the elements defined in the conceptual model)
Model responsibility is allocated to federates and they collaborate through the use of a common Networked Information Infrastructure (e.g. HLA RTI)
BOMs can be used to document Information Exchange Data Models (e.g. HLA FOM)

4. Background Simulation Conceptual Model HLA Object Model Template
Specification of types of entities, attributes, relations, behavior and actions relevant to be represented in the simulation
Independent of how the responsibility of modeling these concepts is allocated to different components (federates) in a federated system (federation)
HLA Object Model Template
A template specification for documenting HLA Federation and Simulation Object Models (FOMs and SOMs) representing the information exchange data model (IEDM)
Represents the type of information needed to be exchange during simulation in order to correctly represent the simulation conceptual model
Federation Development and Execution Process (FEDEP)
Guidance for developing HLA Federations
Recognizes Reference Models and Base Object Models as important approaches to developing FOMs and SOMs

5. Federation Development and Execution Process
Behavior
Actions
Conceptual Entities
Patterns of Interplay
Simulation Conceptual Model
Allocation of Model Responsibilities
Federation Object Model (FOM) 6 5 4 3 1
Perform Conceptual Analysis 2
Analyze Data and Evaluate Results 7
Define Federation Objectives
Design Federation
Develop Federation
Plan,
Integrate, and Test Federation
Execute Federation and Prepare Outputs
FEDEP
Oppourtunities for reuse.
Bridging the gap between conceptual model, through federation design to development of an HLA federation to support the conceptual model.
Maps patterns of interplay in a conceptual model to a “standard” or “reference” how to model simulation interplay using HLA constructs.
FEDEP
IEEE Recommended Practice

6. BOM History BOM PDG / DG SRML 1996 1998 1999 2000 2001 2002 2003 2004
2005
2006
Reference FOM
Study
Group
HLA Evolved
BOM
Study
Group
FEDEP
PDG
SCM
SISO-STD
BOM
RPR
FOM
BOM
Methodology
Strawman
BOM PN
BOM PDG / DG
FOM “piece parts”
(FEDEP, OMT)
SRML
HLA IEEE 1516

7. BOM Rationale Interoperability Reuse Composability
Common understanding on how information is exchanged and interpreted is key in achieving interoperability
BOMs provide a way of documenting not only HLA mechanisms or constructs for information exchange, but also the pattern of interplay that is supported by the exchange.
Reuse
The BOM concept is based on the assumption that piece-parts of simulations and federations can be extracted and reused as modeling building-blocks or components.
The interplay interface between conceptual entities within a simulation can be captured and characterized in the form of reusable patterns.
Composability
The implementation of a pattern of interplay using HLA object model constructs is captured in the BOM and can be used to compose Federation Object Model (FOM)
The patterns of interplay can be used to compose Conceptual Models
Why do we need BOMs ?

8. BOM and Conceptual Models
BOMs can capture some aspects of the Simulation Conceptual Model
The BOM template is not a Conceptual Model Representation Standard
References to other Conceptual Model using other types of Representations is allowed
Primarily used to capture key patterns of interplay between entities in the conceptual model
Provides patterns of interplay as building-blocks when constructing new Simulation Conceptual Models
Conceptual Model
Pattern Of Interplay
State Machine
Entity Type
Event Type
State Machines
Pattern of Interplay
pattern actions
Weapons Effect
states

9. BOMs and HLA Object Models
Object Model Definition
HLA Object Classes
HLA Object Class Attributes
HLA Interaction Classes
HLA Interaction Class Parameters
HLA Data Types
BOMs can capture how information is shared among federates using interactions and attribute updates of simulated entities
The BOM template is not a Federation Agreement Representation Standard
The BOM standard is strongly influenced by HLA but not a required target architecture
Based on IEEE (HLA Evolved) OMT format
Primarily used to capture reusable pieces of OMT information to be used as building-blocks when constructing new FOMs and SOMs.
Opportunity for standardizing common BOMs and for making existing Reference FOMs (e.g. RPR-FOM) BOM based.
Weapons Effect
HLA Interactions and
Attribute Updates
Federate
Federate
Federation Information Exchange Data Model (IEDM)
Federation Object Model (FOM)

10. BOM Model Mapping
Essential metadata needed so that the BOM can be described, discovered and properly reused
BOMs provides a mechanism to map aspects of the Simulation Conceptual Model to Information Exchange constructs
Allows a simple way of identifying FOM elements when allocating the responsibility of modeling aspects of the Simulation Conceptual Model to different federates
Pattern Actions (Messages and Triggers) are mapped to HLA Interactions and/or Attribute Updates)
Model Identification (Metadata)
Conceptual Model
Pattern Of Interplay
State Machine
Entity Type
Event Type
Model Mapping
Entity Type Mapping
Event Type Mapping
Object Model Definition
HLA Object Classes
HLA Object Class Attributes
HLA Interaction Classes
HLA Interaction Class Parameters
HLA Data Types
Notes
Notes and definitions supporting any of the above mentioned elements
Lexicon (definitions)

11. Example Simulation Conceptual Model
Real-world entities, processes and other phenomenon to be represented in a simulation
Identified Patterns of Interplay
Restaurant visit
- Arrival
- Ordering
- Payment

12. Payment Pattern (Conceptual Model)
Waiter Entity Type
Customer Entity Type
Payment Actions
Ready
Ready
Customer Request Check
Prepare Bill
Wait for Bill
Waiter States
Check Brought To Table
Customer States
Ready
Pay
Customer Pays
Wait for change
Process Bill
ReceiptChangeReturned
Leave restaurant
Ready

13. Federation Design (FEDEP step 3)
Allocation of Model Responsibilities
Waiter
Customer
RTI
The Payment Interplay between the Waiter and Customer needs to be modeled in the distributed simulation.
Payment Event Types and supporting Entity Type characteristics needs to be reflected between federates.
Use the Payment BOM to find out how to exchange this information using HLA.

14. EntityTypes and EventsTypes
Basic Concept
Conceptual Model
BOMs
Federation
Patterns of Interplay,
EntityTypes and EventsTypes
Mapping of CM to HLA OM
FOM
BOM supports the development of HLA federations by linking patterns of interplay in the conceptual model to HLA constructs for information exchange between federates

15. BOM XML Format

16. Current BOM activities ?
BOM Product Support Group (PSG)
offer continuity and a place for developers and users of the standards to ask questions, request explanations, seek support, or register change requests for subsequent versions of the product.

17. BOM Drafting Group (DG)
Questions
BOM Drafting Group (DG)

18. BACKUP SLIDES

19. Payment Pattern Description Table
Category
Information
Notes
Name
RestaurantPayment 1
Seq
Sender
Receiver
Event
BOM
Condition
Action
CustomerRequestCheck
Customer
Waiter
CheckRequest NA 2
CheckBroughtToTable
PaymentDueNotification 3
CustomerPays
Variation
BillPayed_Cash
CashPaymentBOM
BillPayed_Credit
CreditCardPaymentBOM
Exception
BillNotPayed
NonPayingCustomer
NoPaymentBOM
Custmer leaves without paying bill 4
ReceiptChangeReturned
ChangeReturn

20. Payment Entity & Event Types
Entity Type Table
Name
Characteristics
Customer
Assigned Table
Waiter
Assigned Tables
Event Type Table
Name
Source Characteristic
Target Characteristic
Content Characteristic
Trigger Condition
Notes
NonPayingCustomer
Customer_Identifer NA
Customer_NotPaid = TRUE 3
CheckRequest
Waiter_Identifier 4
PaymentDueNotification
Customer_Identifier
Amount
ChangeReturn

21. Waiter Payment States State Machine Table Category Information Notes
Name
WaiterPaymentStates
Conceptual Entity Types
Waiter
State 5
Ready
ExitCondition
ExitAction
RestaurantPaymentBOM.CustomerRequestCheck
NextState
PrepareBill
RestaurantPaymentBOM.CustomerPays
ProcessBill
RestaurantPaymentBOM.CheckBroughtToTable
RestaurantPaymentBOM.ReceiptChangeReturned

22. Entity Type Mapping Table Event Type Mapping Table
Model Mapping CM to HLA
Entity Type Mapping Table
Entity Type
HLA Object/Interaction Class
Characteristics
HLA Attributes/Parameters
Condition
Customer
HLAobjectRoot.PhysicalEntity.Human.Customer
Name
Customer.Id NA
Assigned Table
Customer.tableID
Waiter
HLAobjectRoot.PhysicalEntity.Human.Waiter
Waiter.Id
Assigned Tables
IDArray
IDArray provides list of tables for which waiter is responsible
Event Type Mapping Table