HLA Evolved Product Development Group

1
HLA EvolvedProduct Development Group 2007 Fall
SIW 18 September 2007 Roy Scrudder, PDG
ChairDoD MS Coordination OfficeRoy.Scrudder_at_osd
.mil(703) 998-0660
2
Agenda

• Introduction Roy Scrudder
• Status Update Roy Scrudder
• Changes to the standards since the Fall 06 SIW
  Meeting
• Framework and Rules Mike Lightner
• Object Model Template Bob Lutz
• IF Spec Reed Little (with assistance from Björn
  Möller and Doug Wood
• Overview of changes major changes to the HLA
  Evolved Specifications - Björn Möller
• Next steps/Balloting Roy Scrudder and Dr.
  Katherine L. Morse
• Adjourn

3
But first, a few words about patents
4
Highlights of the IEEE-SA Standards Board Bylaws
on Patents in Standards

• Participants have a duty to tell the IEEE if they
  know (based on personal awareness) of potentially
  Essential Patent Claims they or their employer
  own
• Participants are encouraged to tell the IEEE if
  they know of potentially Essential Patent Claims
  owned by others
• This encouragement is particularly strong as the
  third party may not be a participant in the
  standards process
• Working Group required to request assurance
• Early assurance is encouraged
• Terms of assurance shall be either
• Reasonable and nondiscriminatory, with or without
  monetary compensation or,
• A statement of non-assertion of patent rights
• Assurances
• Shall be provided on the IEEE-SA Standards Board
  approved LOA form
• May optionally include not-to-exceed rates,
  terms, and conditions
• Shall not be circumvented through sale or
  transfer of patents
• Shall be brought to the attention of any future
  assignees or transferees
• Shall apply to Affiliates unless explicitly
  excluded
• Are irrevocable once submitted and accepted
• Shall be supplemented if Submitter becomes aware
  of other potential Essential Patent Claims
• A Blanket Letter of Assurance may be provided
  at the option of the patent holder
• A patent holder has no duty to perform a patent
  search
• Full policy available at http//standards.ieee.org
  /guides/bylaws/sect6-7.html6

Slide 1
5
IEEE-SA Standards Board Bylaws on Patents in
Standards

• 6.2 Policy
• IEEE standards may be drafted in terms that
  include the use of Essential Patent Claims. If
  the IEEE receives notice that a Proposed IEEE
  Standard may require the use of a potential
  Essential Patent Claim, the IEEE shall request
  licensing assurance, on the IEEE Standards Board
  approved Letter of Assurance form, from the
  patent holder or patent applicant. The IEEE shall
  request this assurance without coercion.
• The Submitter of the Letter of Assurance may,
  after Reasonable and Good Faith Inquiry, indicate
  it is not aware of any Patent Claims that the
  Submitter may own, control, or have the ability
  to license that might be or become Essential
  Patent Claims. If the patent holder or patent
  applicant provides an assurance, it should do so
  as soon as reasonably feasible in the standards
  development process. This assurance shall be
  provided prior to the Standards Boards approval
  of the standard. This assurance shall be provided
  prior to a reaffirmation if the IEEE receives
  notice of a potential Essential Patent Claim
  after the standards approval or a prior
  reaffirmation. An asserted potential Essential
  Patent Claim for which an assurance cannot be
  obtained (e.g., a Letter of Assurance is not
  provided or the Letter of Assurance indicates
  that assurance is not being provided) shall be
  referred to the Patent Committee.
• A Letter of Assurance shall be either
• a) A general disclaimer to the effect that the
  Submitter without conditions will not enforce any
  present or future Essential Patent Claims against
  any person or entity making, using, selling,
  offering to sell, importing, distributing, or
  implementing a compliant implementation of the
  standard or
• b) A statement that a license for a compliant
  implementation of the standard will be made
  available to an unrestricted number of applicants
  on a worldwide basis without compensation or
  under reasonable rates, with reasonable terms and
  conditions that are demonstrably free of any
  unfair discrimination. At its sole option, the
  Submitter may provide with its assurance any of
  the following (i) a not-to-exceed license fee or
  rate commitment, (ii) a sample license agreement,
  or (iii) one or more material licensing terms.

Slide 2
6
IEEE-SA Standards Board Bylaws on Patents in
Standards

• Copies of an Accepted LOA may be provided to the
  working group, but shall not be discussed, at any
  standards working group meeting.
• The Submitter and all Affiliates (other than
  those Affiliates excluded in a Letter of
  Assurance) shall not assign or otherwise transfer
  any rights in any Essential Patent Claims that
  are the subject of such Letter of Assurance that
  they hold, control, or have the ability to
  license with the intent of circumventing or
  negating any of the representations and
  commitments made in such Letter of Assurance.
• The Submitter of a Letter of Assurance shall
  agree (a) to provide notice of a Letter of
  Assurance either through a Statement of
  Encumbrance or by binding any assignee or
  transferee to the terms of such Letter of
  Assurance and (b) to require its assignee or
  transferee to (i) agree to similarly provide such
  notice and (ii) to bind its assignees or
  transferees to agree to provide such notice as
  described in (a) and (b).
• This assurance shall apply to the Submitter and
  its Affiliates except those Affiliates the
  Submitter specifically excludes on the relevant
  Letter of Assurance.
• If, after providing a Letter of Assurance to the
  IEEE, the Submitter becomes aware of additional
  Patent Claim(s) not already covered by an
  existing Letter of Assurance that are owned,
  controlled, or licensable by the Submitter that
  may be or become Essential Patent Claim(s) for
  the same IEEE Standard but are not the subject of
  an existing Letter of Assurance, then such
  Submitter shall submit a Letter of Assurance
  stating its position regarding enforcement or
  licensing of such Patent Claims. For the purposes
  of this commitment, the Submitter is deemed to be
  aware if any of the following individuals who are
  from, employed by, or otherwise represent the
  Submitter have personal knowledge of additional
  potential Essential Patent Claims, owned or
  controlled by the Submitter, related to a
  Proposed IEEE Standard and not already the
  subject of a previously submitted Letter of
  Assurance (a) past or present participants in
  the development of the Proposed IEEE Standard,
  or (b) the individual executing the previously
  submitted Letter of Assurance.

Slide 3
7
IEEE-SA Standards Board Bylaws on Patents in
Standards

• The assurance is irrevocable once submitted and
  accepted and shall apply, at a minimum, from the
  date of the standard's approval to the date of
  the standard's withdrawal.
• The IEEE is not responsible for identifying
  Essential Patent Claims for which a license may
  be required, for conducting inquiries into the
  legal validity or scope of those Patent Claims,
  or for determining whether any licensing terms or
  conditions are reasonable or non-discriminatory.
• Nothing in this policy shall be interpreted as
  giving rise to a duty to conduct a patent search.
  No license is implied by the submission of a
  Letter of Assurance.
• In order for IEEEs patent policy to function
  efficiently, individuals participating in the
  standards development process (a) shall inform
  the IEEE (or cause the IEEE to be informed) of
  the holder of any potential Essential Patent
  Claims of which they are personally aware and
  that are not already the subject of an existing
  Letter of Assurance, owned or controlled by the
  participant or the entity the participant is
  from, employed by, or otherwise represents and
  (b) should inform the IEEE (or cause the IEEE to
  be informed) of any other holders of such
  potential Essential Patent Claims that are not
  already the subject of an existing Letter of
  Assurance.

Slide 4
8
Other Guidelines for IEEE WG Meetings

• All IEEE-SA standards meetings shall be conducted
  in compliance with all applicable laws, including
  antitrust and competition laws.
• Dont discuss the interpretation, validity, or
  essentiality of patents/patent claims.
• Dont discuss specific license rates, terms, or
  conditions.
• Relative costs, including licensing costs of
  essential patent claims, of different technical
  approaches may be discussed in standards
  development meetings.
• Technical considerations remain primary focus
• Dont discuss fixing product prices, allocation
  of customers, or dividing sales markets.
• Dont discuss the status or substance of ongoing
  or threatened litigation.
• Dont be silent if inappropriate topics are
  discussed do formally object.
• --------------------------------------------------
  -------------
• If you have questions, contact the IEEE-SA
  Standards Board Patent Committee Administrator at
  patcom_at_ieee.org or visit http//standards.ieee.org
  /board/pat/index.html
• See IEEE-SA Standards Board Operations Manual,
  clause 5.3.10 and Promoting Competition and
  Innovation What You Need to Know about the IEEE
  Standards Association's Antitrust and Competition
  Policy for more details.
• This slide set is available at http//standards.ie
  ee.org/board/pat/pat-slideset.ppt

Slide 5
9
HLA Evolved Status
We Are Here
via SISO IEEE
via IEEE
via SISO
10
HLA Evolved Schedule
06S/Evote/ Telecon Round 3 Comment Resolution
04F SIW Round 1 Comment Resolution
05S/E/F SIW Round 2 Comment Resolution
Project Approved By SAC
Balloting Decision
04S/E SIW Kickoffs
2004
2005
2006
Draft 0 Review
Draft 1 Prep
Draft 1 Review
Draft 2 Prep
Draft 2 Review
2007
2008
Ballot
Ballot Resolution
Re-circ.?
Ballot Resolution
Final Resolutions
11
HLA EvolvedProduct Drafting Group HLA Framework
and Rules Changes 18 September 2007 Mike
LightnerAEgis Technologiesmlightner_at_aegistg.com
[phone]
12
IEEE 1516 Framework and Rules Changes Since PDG
Meeting at Fall SIW 2006

• Made necessary changes based on Modular FOM Tiger
  Team Actions
• Added Definitions for
• FOM Module
• SOM Module
• MOM Module
• Current FOM
• Current FDD
• Regular Object Class Description
• Scaffolding Object Class Description
• Regular Interaction Class Description
• Scaffolding Interaction Class Description
• Repeated Description
• Identical FOM Module

13
IEEE 1516 Framework and Rules Changes Since PDG
Meeting at Fall SIW 2006

• Made necessary changes based on Modular FOM Tiger
  Team Actions (Continued)
• Updated Definitions for
• Federation Object Model (FOM)
• Federation Object Model (FOM) Document Data (FDD)
• Simulation Object Model (SOM)
• Modified supporting text for Rules 1 6 to
  incorporate modular FOM concepts
• Added Definition for Wall-Clock Time
• Changed term MOM Module to MOM and
  Initialization Module and added acronym - MAIM
• Minor editorial and boiler plate changes

14
HLA EvolvedProduct Drafting Group HLA Object
Model Template Changes 18 September 2007 Bob
LutzJohns Hopkins University Applied Physics Lab
15
Round 2 H CodeTechnical Comments

• New Conformance Statement section
• Put on hold until I/F Spec services list was
  final, and until supporting text was finished
• Modular FOM changes

16
H Code Comment Status

• New Conformance Statement section is complete
• Thank you Jake/Randy!!!
• Modular FOM changes are now implemented
• Numerous FOM/SOM references appended with FOM
  Module or SOM Module (especially Inclusion
  Criteria)
• FOM/SOM Module Merging Rules (new Section 7)
• FOM/SOM Module Merging Principles (new Annex C)
• Thank you Paul/Bjorn!!!

17
FOM/SOM ModuleMerging Rules Example
18
FOM/SOM ModuleMerging Principles Example
C.2 Merging Classes The classes (Object
Classes / Interaction Classes) from FOM Modules
(or SOM Modules) to be merged should be compared
against the current FOM (or SOM). Classes with
the same name and ancestry (parent classes),
whether or not they have different
attributes/parameters, shall not be merged. Any
duplicates (equivalent and equivalent-like
classes) already in the FOM (or SOM) are to be
ignored. The following principles for checking
for duplicacy of classes should be applied to
support such activity
1. The class name of the FOM Module (or SOM
Module) being inserted (including its ancestry)
should be compared to see if an equivalent class
name (and ancestry) already exists in the FOM (or
SOM). 2. If some, but not all, sub-elements are
equivalent then a warning should be provided back
to the user. This will allow him/her to know that
the class they desired to be inserted already
exists but is not equivalent, and, therefore, can
not be inserted. 3. Comparison of sub-elements
for an object class include name, sharing,
semantics, attributes, and notes. Children object
classes are not compared. Within the attributes,
what should be compared include name, datatype,
updateType, updateCondition, ownership, sharing,
dimensions, transportation, order, semantics, and
notes. 4. Yada, yada, yada
19
Latest Twists (i.e., Issues)

• Problems discovered with current OMT glyph
  representation
• The encoding of the data isnt specified anywhere
  so it is unclear how to convert this into binary
  data
• If successfully converted to binary data, it is
  unclear what format (GIF/JPG/PNG/ICO/BMP) the
  resulting byte-array is.
• The Restaurant example in the OMT spec has an
  extra attribute typeGIF, which is not in Table
  1 of the OMT standard

20
Latest Twists (i.e., Issues)

• Suggested solution for OMT glyph issues
• Introduce the sub-field Type for Glyph
• This subfield provides the type of the image
  data. Valid values are GIF, JPG and PNG
• Clarify the sub-field Source
• This subfield provides the image representing
  the object model. The field shall contain
  base64-encoded image data using the GIF, JPG or
  PNG file format. The data format shall be
  specified in the Type field.
• Remove the Height and Width sub-fields.
• This is always included in the standard file
  formats.

21
What Happens Next?

• Wednesday afternoon breakout session (Sanibel) to
  finalize (and perhaps implement) final OMT
  changes
• Final review of these changes to be conducted by
  DG and other key PDG members shortly thereafter
• All other PDG-approved changes have already been
  reviewed by OMT DG
• On to balloting (?)

22
HLA Evolved ChangesFall 2006 Fall 2007Reed
LittleBjörn MöllerDoug Wood

• Transportation Types Data Logging
• Java
• WSDL
• C
• OMT and MOM Module

23
Request/Report Interaction Transportation Type
for a Federate

• What if the federate does not publish the
  requested Interaction?
• Hard to generate an exception locally when this
  information is requested. This may not be known
  locally (on the requesting federate LRC)
• Exception removed from Request
• New handling in the Report
• In case the specified federate does not publish
  the specified interaction the transportation type
  specified in the FDD shall be reported.

24
More Transportation Type 1

• Report Attribute Transportation Type (callback)
• In case the attribute is unowned the
  transportation type specified in the FDD shall be
  reported.
• Request Attribute Transportation Type Change
• New precondition The specified instance
  attributes are not in the process of changing
  transportation type
• New exception One or more instance attribute is
  already in the process of changing transportation
  type.

25
More Transportation Type 2

• Request Interaction Transportation Type Change
• New precondition The specified interaction class
  is not in the process of changing transportation
  type.
• New exception The interaction class is already
  in the process of changing transportation type.

26
Data Logging

• Clarification Registering federate for an object
  instance shall be reported as producing
  federate upon object instance discovery
• See also Java Supplementary Reflect Info

27
Java Encoding Helpers

• Increased flexibility support for non-standard
  byte-alignment has been added
• Earlier implementation enforced HLA-compliant
  byte alignment (for example 4 byte boundaries)
• Support for non-standard alignment has been
  requested when standard HLA data types are mixed
  with non-standard RPR FOM types
• The use of this functionality is optional
• Reuse Improved support for reuse of encoding
  helper objects.
• Data from previous encoding operation is now
  guaranteed to be cleared.

28
Standardized Time Types in Java

• Improved mechanism for accessing the
  implementation specific classes
• Java Service Registry A service is a
  well-known set of interfaces and (usually
  abstract) classes. A service provider is a
  specific implementation of a service
• The user always uses the standardized service
  interface
• The RTI implementor can use whatever class name
  that he wants internally
• This replaces the earlier approach with a
  standardized concrete class and a fill-in-the
  blanks implementation

29
Evolved Transportation Types in Java

• Earlier Java used an enum (static enumeration)
  to represent transportation types
• Prohibits the dynamics of additional
  transportation types
• This has been replaced by a Handle per
  transportation type

30
Java Supplementary Reflect Info

• To be able to handle several optional arguments
  in Java several variants of the method (service)
  are needed.
• N optional arguments give N square variants
• Optional arguments have now been collected in one
  argument with a Supplementary Reflect Info
  struct
• Includes the Convey Producing Federate, Convey
  Sending Regions, etc
• This principle is used for Supplementary Reflect
  Info, Supplementary Receive Info and
  Supplementary Remove Info

31
WSDL Updates

• WSDL has been updated to support any change
  requried elsewhere in this presentation
• Calls for encoding and decoding the standardized
  time types have been added

32
C Encoding Helpers

• Basic encodings
• Handles
• Logical time
• Fixed/Variant Record
• Fixed/Variant Array
• Opaque data
• C data types (e.g., HLAASCIIchar, HLAfloat32BE,
  ...)
• Create complex encoding instances by composing
  instances of basic encodings
• Supports automatic code generation

33
C Standard Time Types

• Integer and floating point time declarations
  added to API
• HLAinteger64Time and HLAfloat64Time
• All RTI must provide implementations
• Link time compatibility between RTI
  implementations
• No need to borrow time libraries between RTI
  implementations
• Does not preclude federations from providing own
  time implementation
• Encodings included in specification
• Supports WSDL API

34
Modular FOM IF spec

• The RTI is only responsible for creating the
  union of the FOM modules (and the MAIM) for the
  FDD content
• FDD is the data that initializes the RTI,
  including object class names, interaction class
  names, attribute parameter names,
  transportation types, etc
• Not Semantics, Data types, Notes, etc
• Federate and federation objects (MOM) shall
  maintain lists of loaded modules
• The full XML content of the modules can be
  requested using MOM interactions

35
Modular FOM OMTReferences.Type

• Table 1 References.Type descriptionThis
  subfield shall specify the form of the reference
  material. The following predefined values may be
  used for this field
• Standalone
• Dependency
• Composed From
• Alternatively, other values may be used to
  indicate the general type of reference source,
  such as "Text Document", "Spreadsheet", or
  "Powerpoint File".

36
Modular FOM OMTReferences.Identification

• Table 1 References.Identification
  descriptionThe following conditions shall be
  met
• If the Reference Type subfield "Standalone",
  this subfield shall contain the value "NA".
• If the Reference Type subfield "Dependency",
  this subfield shall identify the name of all
  dependent FOM Modules or SOM Modules.
• If the Reference Type subfield "Composed From",
  this subfield shall identify the names of all FOM
  Modules or SOM Modules that have been merged to
  form the current object model.

37
About the HLA Evolved MOM Module

• In HLA Evolved all of the predefined concepts are
  provided in a special FOM module
• HLAobjectRoot and HLAinteractionRoot
• Predefined HLA data types, including the new
  standardized time types
• The entire MOM (Management Object Model)
• If you dont need to extend the MOM this module
  will be provided automatically by the RTI
• Result The FOM module(s) provided by the
  application will be considerably smaller.
  Minimized risk for incorrect definitions of
  predefined concepts

38
MOM and Initialization Module(MAIM)

• Initially called the MOM Module by the Modular
  FOM TT
• contains more than just the MOM
• Renaming the MOM Module to MAIM
• This I/F Spec initiated action must be similarly
  implemented in OMT for consistency
• Suggested solution
• All references to the MOM Module has to change to
  "MOM And Initialization Module" or MAIM
• General references to MOM alone do not change
• Remove MOM data from the FOM examples
• Document that it builds upon the MAIM

39
Result of Renaming

• Several Attributes, Parameters and Interactions
  called MOM have been renamed, for
  example HLAFederation.HLAMOMmoduleDesignatorRe
  named to HLAFederation.HLAMAIMDesignator

40
Naming of Standard MAIM

• In many cases a user will not provide a MAIM
• The RTI shall then automatically provide the
  standard (and correct) MAIM
• It is possible to request the designator of the
  MAIM that was used
• So how do you tell that the standard MAIM was
  used?
• A standardized designator HLAstandardMAIM has
  been introduced for this.
• May not be used for a user-supplied MAIM

41
HLA Evolved at a Glance