Given by Geoffrey Fox but selected by W. Furmanski from DMSO at ARL Training Session IMT Dec 4 97 on Dec 4 97. Foils prepared Nov 29 97
Outside Index
Summary of Material
This selects from the major DMSO HLA Training Resource at |
Core Material |
and Additional Material |
This selects from HLA Overview, HLA Process and Policy |
RTI 1.0 Tutorial, Time Management in the HLA, HLA Object Model Template (OMT) |
and HLA Interface Specification |
From additional material resource, we select Object Model Development Tools (OMDT) |
Outside Index Summary of Material
Defense Modeling & Simulation Office |
(703) 998-0660 Fax (703) 998-0667 hla@msis.dmso.mil |
http://www.dmso.mil/ |
Comments in Green with a left vertical bar |
have been added by NPAC |
and are not endorsed by DMSO |
Original Powerpoint at http://www.dmso.mil/hla/edu_trng/regional/core_mat/ |
This selection at http://www.npac.syr.edu/users/gcf/dmsohlaforarldec97/ |
See also http://osprey7.npac.syr.edu:1998/iwt98/projects/webhla/ |
88 89 90 91 92 93 94 95 96 |
Technical |
Management |
Limited scope simulations, little interoperability prior to 1988 |
DSB: Computer Applications |
to Training & Wargaming |
DIS Standards begun |
ALSP- linking of Service wargames |
DEPSECDEF Memo |
EXCIMS and DMSO established |
SIMNET |
HLA Baseline approved |
HLA begun |
Service M&S Offices established |
DoDD 5000.59 |
DARPA's Program Evaluation Team |
Mar 95 |
Initial |
definition |
of HLA |
Aug 96 |
Baseline |
definition |
of HLA |
Evolution |
DoD-wide Architecture Management Group |
( STOW, CCTT(CATT), JTCTS, BDS-D, BFTT/NSS, WARSIM 2000, NASM, JSIMS, JWARS, T&E, DIS, IADS, JMASS, SBD, DISA/D8) |
Prototypes |
Frequent Reviews Throughout |
DoD Policy Issued |
10 Sept 1996 |
Federation: a set of simulations, a common federation object model, and supporting RTI, that are used together to form a larger model or simulation |
Federate: a member of a federation; one simulation
|
A federate could be large or small grain -- for initial activity of integrating existing pre HLA simulations, a federate is typically large grain size |
However HLA is a "complete" model and one could build simulations where a federate is finr grain object and federation is simulation of these interacting objects |
Federation Execution: a session of a federation executing together |
Object: An entity in the domain being simulated by a federation that
|
Interaction: a non-persistent, time-tagged event generated by one federate and received by others (through RTI) |
Attribute: A named datum (defined in Federation Object Model) associated with each instance of a class of objects |
Parameter: A named datum (defined in Federation Object Model) associated with each instance of a class of interactions |
HLA Rules: A set of rules which must be followed to achieve proper interaction of federates during a federation execution. These describe the responsibilities of federates and of the runtime infrastructure in HLA federations
|
Interface Specification: Definition of the interface services between the runtime infrastructure and the federates subject to the HLA
|
Object Model Templates: The prescribed common method for recording the information contained in the required HLA Object Model for each federation and federate
|
1. Federations shall have an HLA Federation Object Model (FOM), documented in accordance with the HLA Object Model Template (OMT) |
A FOM is like a particular facility in CORBA |
2. In a federation, all representation of objects in the FOM shall be in the federates, not in the runtime infrastructure (RTI) |
3. During a federation execution, all exchange of FOM data among federates shall occur via the RTI |
4. During a federation execution, federates shall interact with the runtime infrastructure (RTI) in accordance with the HLA interface specification |
5. During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time |
6. Federates shall have an HLA Simulation Object Model (SOM), documented in accordance with the HLA Object Model Template (OMT) |
7. Federates shall be able to update and/or reflect any attributes of objects in their SOM and send and/or receive SOM object interactions externally, as specified in their SOM |
8. Federates shall be able to transfer and/or accept ownership of attributes dynamically during a federation execution, as specified in their SOM |
9. Federates shall be able to vary the conditions (e.g., thresholds) under which they provide updates of attributes of objects, as specified in their SOM |
10. Federates shall be able to manage local time in a way which will allow them to coordinate data exchange with other members of a federation |
The HLA OMT is a standardized presentation format for describing HLA object models |
Sort of like Design Rules or Frameworks in ComponentWare |
Rationale:
|
Object Class Structure Table |
Object Interaction Table
|
Attribute/Parameter Table
|
FOM/SOM Lexicon
|
General Case |
Example |
P=Publish and S=Subscribe |
General Case |
Example |
The Columns define characteristic properties of an HLA simulation object which would be defined by IDL in |
CORBA and Java Class definition in RMI/Javabean Approach |
Live |
Participants |
Interface |
Runtime Infrastructure |
Data Collector/ |
Passive Viewer |
Federation Management Declaration Management |
Object Management Ownership Management |
Time Management Data Distribution Management |
RTI is a bit like IIOP with critical addition of time |
management services |
Network |
Ambassadors hold equivalent of stubs and skeletons in CORBA/RMI/COM distributed object models. |
These are proxies for remote objects |
Federate |
Ambassador |
RTI Ambassador |
Interfaces are method calls on objects (C++, Ada-95, Java) |
Federate-initiated serves are invoked on an instance of RTI Ambassador |
RTI-initiated services are invoked on an instance of Federate Ambassador |
RTI Executive is a 1.0-supplied server started by hand |
It's an artifact of 1.0 design, not inherent in RTIs |
There is usually 1 Executive per LAN |
RTI Executive is a naming service for federation executions |
RTI Executive |
This is by hand start up process with naming server etc. |
RTI |
Executive |
FedEx |
Federate invokes createFederationExecution on its RTI Ambassador |
RTI Ambassador reserves name with RTI Executive |
RTI Ambassador spawns FedEx process |
FedEx registers its communication address with RTI Executive |
"Host" for a Federation |
Top level |
Super "Host" |
RTI |
Executive |
FedEx |
Another federate invokes joinFederationExecution on its RTI Ambassador |
RTI Ambassador consults RTI Executive for address of FedEx |
RTI Ambassador invokes joinFederationExecution on FedEx |
This arrangement of separate processes for RTIexec and FedEx is an RTI 1.0 artifact |
RTI Executive, FEDEX's and Federates are arranged hierarchically where you can think of a federate as a single process (as far as HLA is concerned) running in a single computer.
|
RTI Executive |
Fedex Executive |
......... |
Fedex Executive |
Federates |
Data passed between federates by the RTI is entirely parametric to the RTI (i.e. RTI does not Interpret it -- the FOM explains it) |
This contrasts with DIS, where a new data item means a new PDU and changes to DIS infrastructure
|
FOM describes the kinds of things federates will talk about in a federation including: objects and interactions |
FOM (object attributes and their interaction) is agreed by federation designers before execution |
Parts of the FOM are supplied, at execution time, as data to the RTI
|
An interaction represents an event in time that has no continuing state, e.g. a change in an ATC clearance or the firing of a weapon |
An interaction, unlike an object does not persist; it occurs at a specified time |
Federations subscribe to classes of interactions. They are then notified when another federate sends an interaction of that class |
Each interaction class specifies the set of parameters for each instance of that class |
Like object classes, one interaction class can inherit from another |
An interaction is instantiated by messages which are essentially sent and received by methods of objects |
Category |
Functionality |
Federation Management |
Create and delete federation executions |
Join and resign federation executions |
Control checkpoint, pause, resume, |
restart |
Declaration Management |
Establish intent to publish and subscribe |
to object attributes and interactions |
Object Management |
Create and delete object instances |
Control attribute and interaction |
publication |
Create and delete object reflections |
Ownership Management |
Transfer ownership of objects/attributes |
Time Management |
Coordinate the advance of logical time |
and its relationship to real time |
Data Distribution |
Management |
Controls the efficient routing of |
information between federates |
CORBA has services and horizontal facilities |
2.1 Create Federation Execution |
2.2 Destroy Federation Execution |
2.3 Join Federation Execution |
2.4 Resign Federation Execution |
2.5 Request Pause |
2.6 Initiate Pause † |
2.7 Pause Achieved |
2.8 Request Resume |
2.9 Initiate Resume † |
2.10 Resume Achieved |
2.11 Request Federation Save |
2.12 Initiate Federate Save † |
2.13 Federate Save Begun |
2.14 Federate Save Achieved |
2.15 Request Restore |
2.16 Initiate Restore † |
2.17 Restore Achieved |
Services are generic |
capabilities needed |
by all objects and |
federations |
Allow federates to specify the types of data they will send or from the FOM |
Interface receive by object class and attribute name and by interaction class functions include specification of:
|
This is roughly structure of object classes as opposed to particular instance of objects -- the latter is handled by object management service |
RTI |
This is a publish-and-subscribe service
|
Federate A creates obj 1 reflects 2, 3 |
Federate B creates obj 2, 3 reflects 1 |
Federate C reflects 1, 2, 3 |
4.1 Request Id |
4.2 Register Object |
4.3 Update Attribute Values |
4.4 Discover Object † |
4.5 Reflect Attribute Values † |
4.6 Send Interaction |
4.7 Receive Interaction † |
4.8 Delete Object |
4.9 Remove Object † |
4.10 Change Attribute Transportation Type |
4.11 Change Attribute Order Type |
4.12 Change Interaction Transportation Type |
4.13 Change Interaction Order Type |
4.14 Request Attribute Value Update |
4.15 Provide Attribute Value Update † |
4.16 Retract |
4.17 Reflect Retraction † |
These are services |
needed to manipulate |
particular instances |
of objects |
Each attribute of each object has an owner: the owner is the federate responsible for updating that attribute
|
Different attributes of the same object may have different owners. One federate is updating an aircraft's position; another federate, subscribing to the position, is updating icing |
"Privilege to delete" an object is an attribute owned by some federate |
Ownership can change: responsibility for updating an attribute can pass from one federate to another. E.g., an aircraft modeled in an aggregate simulation could transfer ownership of the position attribute to a cockpit |
Ownership exchange may be pushed or pulled |
Federate wishing to give up ownership |
Federate accepting ownership |
step 1 Request |
Attribute |
Ownership |
Divestiture |
(service 5.1) |
step 2 Request |
Attribute |
Ownership |
Assumption |
(service 5.2) |
step 3 Attribute |
Ownership |
Divestiture |
Notification |
(service 5.3) |
step 3 Attribute |
Ownership |
Acquisition |
Notification |
(service 5.4) |
HLA Runtime Infrastructure |
Federate wishing to take ownership |
Federate releasing ownership |
step 1 Request |
Attribute |
Ownership |
Acquisition |
(service 5.5) |
step 2 Request |
Attribute |
Ownership |
Release |
(service 5.6) |
step 3 Attribute |
Ownership |
Acquisition |
Notification |
(service 5.4) |
HLA Runtime Infrastructure |
Control advancement of federates along with federation time
|
Interface functions include
|
Time Management is critical difficulty in simulations as hard to make efficient -- subject of much research! |
Goal: provide services to support interoperability among federates with different local time management schemes in a single federation execution. |
Observation: RTI by itself cannot guarantee interoperability. |
Run Time Infrastructure (RTI) |
training federate: |
real-time execution |
constructive federate: |
time-stepped execution |
Run Time Infrastructure (RTI) |
constructive federate: |
event driven execution |
Run Time Infrastructure (RTI) |
live component: |
real-time execution |
w/ hard deadlines |
Run Time Infrastructure (RTI) |
multiprocessor |
parallel simulation federate: |
optimistic Time Warp execution |
Run Time Infrastructure (RTI) |
Classical discrete event simulation programs process all events in time stamp order |
A mechanism is required to enable federates to interleave processing of local events with those received from other federates |
Logical time (applicable to coordinated time advance federates):
|
federate |
local time and event management |
mechanism to pace execution with wallclock time (if necessary) |
federate specific techniques (e.g., compensation for message latencies) |
wallclock time |
(synchronized with other processors) |
logical time |
FIFO |
queue |
time |
stamp |
ordered |
queue |
Runtime |
Infrastructure |
(RTI) |
state updates |
and interactions |
logical time advance |
requests and grants |
receive |
order |
messages |
time stamp |
order |
messages |
while (simulation still in progress) |
invoke Next Event Request (Tlocal = time stamp of next local event) |
RTI delivers next TSO event w/ time stamp Š Tlocal if any exist (+ others w/ same time stamp) |
RTI advances federate's logical time, invokes Time Advance Grant |
if (TSO message(s) delivered in above Next Event Request service call) |
process the remote event(s) delivered to the federate |
else process next local event |
Goal: merge TSO messages (events from other federates) with local events so all events are processed in time stamp order |
RTI |
federate |
TSO |
messages |
local |
events |
logical |
time |
current |
time |
next |
local |
event |
next |
remote |
event |
Tlocal |
Allow federates to specify the distribution conditions for the specific data they send or expect to receive
|
Interface functions include
|
Critical for efficient implementations -- SIMNET broadcast updates to every process and this does not scale |
Create Subscription Region
|
Create Update Region |
Associate Update Region (with an object instance or interaction)
|
Modify Region or Associate Update Region
|
The routing space, regions, and association data is used by the RTI to distribute data |
When an update region and subscription regions of different federates overlap
|
Change Thresholds
|
In Javabeans, we would set this up as "listeners" which are associated with observers (receivers of events) and which are notified when changes made |
Two Dimensional Interest Space |
Update Region |
Subscription Region |
Overlap Region - Published Data Sent to Subscribing Federate |
Defense Modeling & Simulation Office |
(703) 998-0660 Fax (703) 998-0667 hla@msis.dmso.mil |
http://www.dmso.mil/ |
Current as of 25 Sept 97 |
Tools to support construction of HLA Compliant Simulations |
Feedback from HLA protofederations emphasized need for process descriptions for HLA federation and object model development |
HLA Federation Development and Execution Process (FEDEP) model developed through cooperative effort between HLA protofederations and HLA TSTCore |
Sharing of OM development concepts among HLA protofederations (via the OMT Working Group) provided the foundation of the HLA Object Model Development Process |
HLA protofederation feedback also emphasized need for automated tools to support development processes
|
Fed Object Model |
Library of |
SOMs |
of FOMs |
Sponsor |
Scenario |
Development |
Management |
Requirements |
Common Fed Functionality |
Execution |
Environment |
Federation Execution Data |
Results |
Objects, |
Attributes, |
Interactions |
Determine |
suitability of |
Develop |
Identifies |
Guides |
Defines |
Drives |
Record |
Feeds |
Provides |
input to |
Derives |
Inputs to |
Provides |
input to |
Provides |
input to |
Provides |
input to |
Feedback |
Defines/Refines |
Drives |
Design |
Provides |
input to |
Generates |
FRED |
Scenario Instances |
-- Where |
-- Who |
-- Details |
Feeds |
Fed Commonality |
Object Model |
ED |
Fed Development |
Products |
Modeling and Simulation Resource Repository |
Federation |
Library |
Federation |
Federation |
Test |
Federation |
Execution |
Conceptual |
Analysis |
Other Resources |
HLA FOM |
Scenario Data |
Purpose:
|
Common Features:
|
Windows 95/Windows NT application |
Developed in Visual C++ using the Microsoft Foundation Classes |
Interface designed around HLA OMT tabular views
|
"Smart" copy/paste maintains object model relationships |
Multiple Document Interface allows copy/paste between object models |
Interface for editing FED data (message order, delivery category) |
User's Guide and Reference Manual integrated in Windows Help |
CDIF(Data Interchange Format) interface to COTS CASE tools |
Standalone Java application
|
Multiple platforms
|
Easy to use interface
|
OM Development Wizard
|
Need to re-use objects between simulations |
This is part of function of CORBA trader service and similar in goals to RIB project of NHSE (National High Performance Software Exchange) |
Provides a central repository (currently in Texas) for HLA Federation Object Models (FOMs) and Simulation Object Models (SOMs) |
Supports the Federation Execution Development Process (FEDEP) by
|
A web-accessible repository containing:
|
The OMDDS supports:
|
Define Federation |
Scenario |
Requirements |
Search/Reuse |
Existing FOMs |
Identify Candidate |
Simulations and |
SOMs |
Check/Update |
Consistency with |
OMDD Contents |
Complete FOM, |
building with |
OMDD Contents |
Add FOM and |
SOMs to OML |
Propose new |
OMDD Contents |
A DIF is a specification of the semantics and structure of data to be interchanged between multiple data producers and multiple data consumers |
HLA DIFs are Backus Naur Form (BNF) descriptions of delimited ASCII text |
HLA DIFs support the interchange of object model information among HLA tools |
HLA DIFs provide an open specification for development of new object model tools which will integrate with the existing tool set |
Object Model |
Library |
Object Model |
Data Dictionary |
System |
Object Model |
Development |
Tools |
RTIs |
DoD |
Data Dictionary |
System |
OMT |
DIF |
OMDD |
DIF |
OMT |
DIF |
FED |
DIF |
DDDS Batch Formats |
AEgis OMDT and OML will be made publicly available in late October |
TASC OMDT and OMDDS will be made publicly available later this year, following further testing |
To find out more on release information:
|