One Routing Space Proposal to IEEE HLA Standard

1
One Routing Space Proposalto IEEE HLA Standard
Katherine L. Morse katherine_morse_at_cpqm.saic.com
Andreas Kemkes, James Ivers, Richard
Weatherly, Reed Little, James Calvin, Daniel Van
Hook
2
Motivation for the Change

• Restriction of routing attributes and
  interactions to only one routing space
• Outstanding IEEE Interface Specification comment
  313
• No protection for existing federates from
  addition of dimensions to existing routing spaces
• Adding a dimension to a routing space to increase
  filtering specificity requires rewrite of all
  federates using routing space
• Routing subclassed interactions to different
  routing spaces
• Interface Specification comment 255

3
Routing to One Space

• Currently the I/F Spec restricts the user to
  routing object class attributes and interactions
  to one routing space
• Suggested workarounds have additional issues
• Replicate attribute in SOM/FOM and route the
  copies to different spaces
• Requires rewriting sending federate to duplicate
  updates
• Additional overhead for multiple updates sent
  through RTI
• Merge dimensions of desired routing spaces into
  a single routing space
• Requires rewriting federates to add dimensions to
  region creation
• Removes conceptual separateness of routing spaces
• May result in additional DDM overhead in the RTI

4
Subclassed Interactions

• Interactions assigned to routing spaces at the
  class level
• Interactions may be subclassed
• New parameters added
• But subclassed interactions can be routed to
  different routing spaces than their superclasses
• Without DDM, subscribing federates should receive
  subclassed interactions promoted to the level at
  which the federate subscribed
• With DDM currently, subscribing federates will
  never see subclassed interactions routed to a
  different routing space unless they explicitly
  subscribe for the subclass to the other routing
  space, defeating the intention of promotion

5
Overview of Proposed Change

• Routing space concept is removed
• Attributes and interaction classes associated
  with subsets of global set of all dimensions
• Region overlap is calculated using all (and only)
  the dimensions that regions have in common
• SOM/FOM includes default ranges for dimensions so
  the user doesnt have to specify all ranges of a
  regions extents
• A special default value of excluded indicates
  that the dimension is not used in overlap
  calculations unless a range is explicitly given

6
Changes to OMT

• Routing space table replaced by Dimension table
• Routing space name column deleted
• Value when unspecified column added
• Default value given in percentage, 0.0 - 1.0,
  of RTI range for dimensions RTI_MIN, RTI_MAX),
  or excluded
• Routing space column replaced by Available
  dimensions column in Attribute and Parameter
  tables
• Entry of N/A still valid to indicate that DDM is
  not used

7
Routing Space Table vs. Dimension Table
We assume that by default were interested in all
soda flavors. The default Bar_quantity is 1,
which is normalized to RTI_MIN, but we specify a
small range around the default value because the
default value is discrete.
8
Attribute Table Change
Soda_flavor and Bar_quantity are the dimensions
previously associated with the Bar_order routing
space through which Food.Drink and
Food.Drink.Soda were previously routed
9
Parameter Table Change
Interaction Main_course_served was previously
routed through routing space Server_order which
had one dimension, Waiter_id
10
Changes to I/F Spec -Routing Spaces and Default
Regions

• All mention of routing spaces goes away
• Default routing space and default regions
  replaced by a single default region
• Range is RTI_min, RTI_max) for all dimensions
• Like the default routing space and previous
  default regions, it cannot be referred to directly

11
Changes to I/F Spec -Regions Specifications vs.
Realizations

• Differentiate between region specification and
  region realization
• Region specification is a set of extents, each of
  which contains the same set of dimensions
• Region specifications are created and modified
  using Create Region and Modify Region
• Region realization is created when a region
  specification is associated with an instance
  attribute for update, a sent interaction, or a
  class attribute or interaction class for
  subscription
• Register Object Instance with Region, Associate
  Region for Updates, Subscribe Object Class
  Attributes with Region, Subscribe Interaction
  Class, etc.

12
Changes to I/F Spec -Available Dimensions

• The available dimensions of a class attribute are
  the dimensions associated with the class
  attribute in the FED
• Regions associated with an object class attribute
  for subscription or an instance attribute for
  update may only contain available dimensions of
  the attribute
• The available dimensions of an interaction class
  are the dimensions associated with the class in
  the FED
• Regions associated with an interaction class
  attribute for subscription or a sent interaction
  may only contain available dimensions of the
  interaction class

13
Changes to I/F Spec -Defaults in Region
Realizations

• The RTI may make changes when creating region
  realizations from region specifications to
  account for default dimension values
• Explicitly provided dimensions are the specified
  dimensions of the region specification
• All specified dimensions are included in the
  region realization
• The unspecified dimensions are the available
  dimensions less the specified dimensions
• The RTI fills in the defaults for the unspecified
  from the defaults in the FED
• Modifying the region may cause the RTI to
  reevaluate dimension defaults and make further
  changes
• Dimensions may be added or deleted during
  modification, changing the set of unspecified
  dimensions and, hence, defaults

14
Changes to I/F Spec -Region Overlaps

• Regions overlap if and only if their extent sets
  overlap
• Extent sets overlap if at least one extent in
  each set overlaps
• Extents overlap if all ranges of the common
  dimensions overlap
• If two extents dont have any dimensions in
  common, they do not overlap

15
Changes to I/F Spec -APIs

• Create Region
• SpaceHandle replaced by DimensionHandleSet
• Modify Region
• InvalidRegionContext exception added
• getRoutingSpaceHandle and getRoutingSpaceName
• Deleted
• getAttributeRoutingSpaceHandle and
  getInteractionRoutingSpaceHandle
• Replaced by getAvailableDimensionsForClassAttribut
  e and getAvailableDimensionsForInteractionClass
• getDimensionHandle and getDimensionName
• SpaceHandle parameter and SpaceNotDefined
  exception deleted

16
Changes to I/F Spec -FED

• Replace ltSpacesgt by ltDimensionsgt and ltSpaceNamegt
  by ltDimensionNamegt
• Delete ltSpacegt
• Add ltDimensionDefaultgt to ltDimensiongt
• Replace ltSpaceNamegt by ltDimensionNamesgt in
  ltAttributegt and ltInteractionClassgt
• This will all be rewritten if/when we go to XML

17
Changes to I/F Spec -Subclassed Interactions
Ax
RS1
d1
Currently, subscribers to A through RS1 will not
receive interactions of sent at C, nor will
subscribers to C through RS2 receive interactions
sent at E or F. In addition, a federate cannot
send an interaction of class C with both
parameters x and z because theyre associated
with different routing spaces Under the proposed
solution, a federate can subscribe to A with
dimension d1 and it will receive interactions
sent at class C with dimensions d1 and d2, but
promoted to class A and delivered without
parameter z. Region overlap will be calculated
only on d1.
By
Cz
RS2
d1, d2
Dw
Eu
RS1
d1, d3
Fv
RS1
d1, d2, d3
18
Middleware Test Implementation

• Perceptronics emulated the proposed change using
  middleware on top of RTI 1.3 v4
• NO CHANGES WERE MADE TO RTI 1.3
• Map existing APIs to proposed APIs
• Maintain data structures to manage default ranges
  and region realizations from region
  specifications
• Added auxiliary FED file to emulate FED file
  changes
• Ran 7 test cases to prove functional correctness,
  especially of overlap calculations
• Test results provided in addendum

19
Code Example -Hello World w/DDM
Current Subscription Example
countryClassID getObjectClassHandle(Country)
popAttrId getAttributeHandle(Population,
countryClassID ) popRSId rtiamb -gt
getRoutingSpaceHandle( PopulationRS
) popSizeDimId rtiamb -gt getDimensionHandle(
populationSize, popRSId ) s_region rtiamb -gt
createRegion( popRSId, 1 ) s_region -gt
setRangeLowerBound(0, popSizeDimId, Linear(myPop
) ) s_region -gt setRangeUpperBound(0,
popSizeDimId, Linear(MaxPop ) ) rtiamb -gt
notifyAboutRegionModification(s_region) rtiamb
-gt subscribeObjectClassAttributesWithRegion
(countryClassId, s_region, popAttrId)
Proposed Subscription Example
countryClassID getObjectClassHandle(Country)
popAttrId getAttributeHandle(Population,
countryClassID ) popDimHandleSet rtiamb -gt
getAvailableDimensionsForClassAttribute(popAttrId,
countryClassId) popSizeDimId rtiamb -gt
getDimensionHandle( populationSize)//popRSId
deleted s_region rtiamb -gt createRegion(popDimH
andleSet, 1 ) s_region -gt setRangeLowerBound(0,
popSizeDimId, Linear(myPop ) ) s_region -gt
setRangeUpperBound(0, popSizeDimId, Linear(MaxPop
) ) rtiamb -gt notifyAboutRegionModification(s_r
egion) rtiamb -gt subscribeObjectClassAttributesW
ithRegion (countryClassId, s_region,
popAttrId)
20
Code Example -Hello World w/DDM
Current Update Example
u_region rtiamb -gt createRegion(popRSId,
1) u_region -gt setRangeLowerBound(0,
popSizeDimId, Linear(myPop )) u_region -gt
setRangeUpperBound(0, popSizeDimId, Linear(myPop
k)) rtiamb -gt notifyAboutRegionModification(u_
region )
Proposed Update Example
u_region rtiamb -gt createRegion(popDimHandleSet,
1) u_region -gt setRangeLowerBound(0,
popSizeDimId, Linear(myPop )) u_region -gt
setRangeUpperBound(0, popSizeDimId, Linear(myPop
k)) rtiamb -gt notifyAboutRegionModification(u_
region )
21
No Overlap of Excluded Dimensions
Update Region x 1000..9000 y 1000..9000
Subscription Region z 1000..9000
Dimension z of the update region is unspecified,
so it defaults to excluded Dimensions x and y of
the subscription region are unspecified, so they
default to excluded Result Update not reflected
by subscriber because update and subscription
regions have no dimensions in common
22
No Overlap of Default Value
Update Region x 2000..7000 y 2000..4000
Subscription Region x 6000..10000 y
unspecified
Dimension y of the subscription region is
unspecified, so it defaults to 5000..10000 Resul
t Update not reflected by subscriber because
ranges for the y dimension in the two extents
don't overlap
23
Overlap of Default Value with Specified Value
Update Region x 2000..7000 y 4000..6000
Subscription Region x unspecified y
unspecified z 6000..10000
Dimensions x and y of the subscription region are
unspecified, so they default to 1000..4000 and
5000..10000, respectively Result Update
reflected by subscriber because ranges for the x
and y dimensions in the two extents don't
overlap, and update region doesnt have a z
dimension
24
Overlap of Default Values
Update Region x 2000..7000 y unspecified
Subscription Region y unspecified z
6000..10000
Dimension y of both the update region and the
subscription region is unspecified, so it
defaults to 5000..10000 in both regions Result
Update reflected by subscriber because ranges for
the y dimension in the two extents dont overlap,
and y is the only dimension the regions have in
common
25
Override of Excluded Default Values
Update Region x 2000..7000 y 2000..4000
Subscription Region x 9000..10000 y
3000..6000
Both dimensions of both regions are completely
specified, so no defaults are used Result
Update not reflected by subscriber because ranges
for the y dimension in the two extents overlap,
but ranges in x dont
26
Override of Specified Default Values
Update Region x 1000..3000 y 2000..4000
Subscription Region x 5000..8000
All available dimensions of both regions are
completely specified, so no defaults are
used Result Update not reflected by subscriber
because ranges for the x dimension in the two
extents dont overlap, and x is the only
dimension they have in common
27
Multiple Region Realizations from One Region
Specification
attr1 associated with dimensions x, y, z attr2
associated with dimensions y, z Updating
federate creates a single region specification
with dimension y and associates it with both
attr1 and attr2
Update Region 1 x unspecified y
2000..4000 z unspecified
Update Region 1 y 2000..4000 z unspecified
Subscription Region x 6000..10000 y
3000..7000
Dimension x of update region 1 is unspecified, so
it defaults to 1000.4000. Dimension z of both
update region 1 and update region 2 is
unspecified, so it defaults to excluded in both
cases. Result Update of attr1 not reflected by
subscriber because ranges for the x dimension in
the two extents dont overlap. Update of attr1
reflected by subscriber because ranges for the y
dimension on the two extents overlap, and y is
the only dimension they have in common