Emmet Beeker raises two good questions, which I will try to answer here.
First, though, there may be some confusion about the problem that I am
trying to solve.  I am trying to implement an RTI that uses the IEEE
Interface Specification to talk to the federates.  So the statements of ``the
RTI handles this`` are correct, but don`t answer the right question.  I am
trying to learn how the RTI handles this so that I can implement a
single-process federation RTI in a way that it will also do it.  In my SIW
paper I was asking for some changes to the IEEE Interface Specification that
I thought would be necessary for the single-process federation

Here are Emmet`s questions (paraphrased--if I have changed the meanings,
please ask them again) and my attempts to answer them.

(1) Why does the RTI Ambassador need a pointer to its calling federate?

To give an example, the ``update attributes`` method throws an exception if
the calling federate has not published the attributes first.  In order for
the RTI ambassador method to do this, it needs to know which federate has
invoked it so that it can look through the attribute`s list of publishing
federates and compare.

Hartmut Ufer raised a good question earlier this morning when he asked
whether throwing exceptions was the only reason for the pointers.  I have
gone back through my code and I think the answer is yes.  I don`t think the
RTI ambassador uses the calling federate and owning federation pointers for
any other reason.

(2) Why should a stand-alone simulation be certified HLA-compliant?

HLA serves not one, but two purposes:  interoperation and reuse.  While a
standalone federation will not interoperate with anything else, its
federates are still eminently reusable.  If I may give another example, the
application that sparked the single-process federation in the first place
has to do with simulating digital electronic circuits.  I now have
HLA-compliant (I think--they haven`t been certified) single-process federate
simulations of a microcontroller chip, a EEPROM chip, some diodes, a
24-stage frequency divider, and the wires that connect them.  I put them
together in one way to simulate one digital circuit.  The next person can
put them together another way, adding another HLA-compliant single-process
federate simulation of a different chip, to simulate another digital
circuit.  I agree that interoperability has gone out the window (as far as
distributed simulation is concerned--the federates still interoperate), but
there is a great money savings in the reuse of simulation code.

The question of HLA certification is a different kettle of fish and needs to
be addressed separately.  At the moment DMSO has a very well-defined process
for certifying a distributed simulation to be HLA-compliant.  If a
single-process federation meets all the HLA rules and follows the Interface
Specification and has a FOM and SOMs that meet the Object Model Template, it
is HLA-compliant.  DMSO will have to develop a procedure for certifying it.

Joseph McDonnell asked in another post about two simulations that
communicate with each other using HLA but cannot interoperate with anything
else.  This situation exists at present, in an even more extreme form.  It
is possible for a simulation to have its own SOM that is not compatible with
anybody else`s FOM.  This simulation can be certified as HLA-compliant using
DMSO`s present process but cannot interoperate with any other simulation.

John F. Fay
[log in to unmask]

To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link: