Print

Print


Re: HLA Compliance Testing Process (was RE: HLA Standards Changes for the Single-Process Federation) Reed Little <a href="/index.htm?LOGON=A3%3Dind0006%26L%3DZ-ARCHIVE-SIW-CFI%26E%3Dquoted-printable%26P%3D134309%26B%3D--%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26XSS%3D3%26header%3D1" target="_parent" >[log in to unmask]</a> <a href="/index.htm?LOGON=A3%3Dind0006%26L%3DZ-ARCHIVE-SIW-CFI%26E%3Dquoted-printable%26P%3D134309%26B%3D--%26T%3Dtext%252Fhtml%3B%2520charset%3DUTF-8%26XSS%3D3%26header%3D1" target="_parent" >[log in to unmask]</a>
> If Reed Little will get down off his high horse he might contribute
> something positive to the discussion rather than sniping at trivia.

John:  i have nothing more to contribute to the ``John Fay needs these I/F
       spec changes discussion``.  to date, for every correct idea posted on
       this reflector wrt the discussion, i had earlier presented a similar,
       if not identical, suggestion to you in private.  you were the one who
       wanted to take the discussion to the reflector because you couldn`t 
       understand and trust my suggestions.

>                                                                      He is
> correct that the HLA compliance testing process, as posted at the web site
> he gave, does not certify distributed simulations or federations; instead it
> certifies federates.  There is a separate policy and process for verifying
> RTI`s (http://hla.dmso.mil/rti/verify/), which is also called being ``tested
> for compliance.``  I submit that unless one is using debater`s tactics my
> meaning was clear.

it isn`t trivial.  you stated that DMSO would have to develop a
compliance process for the single-process federation (SPF) and i just
pointed out that DMSO tests federates for HLA compliance not federations.  the
difference between a federate and a federation is a primitive HLA concept
and necessary to understand before anything else related to the HLA.
i wanted to ensure that all the reflector readers weren`t confused by your
confusion.


> Reed is missing the fact that the federate compliance testing process as
> posted at the web site at  and
>  is not complete in its details.

i missed nothing.  i did not claim anything about the completeness of the
procedures.

>                                                                    It
> mentions an instrumented RTI (step 3, paragraph 2) without explaining who
> provides it, how it is instrumented, or where it will be executing.  In step
> 4 the process states that ``[t]he Federate Certification Agent will log
> service data from the test,`` again without specifying how or where this is
> done.  These detailed points are important parts of the process.
> 
> The ``Federate Testing Process`` presentation, currently available at the DMSO
> web site at , on slide 40, states ``On
> the scheduled test date, the Certification Agent and the FUT [Federation

there you go again.  it`s ``Federate Under Test``.

> Under Test] establish a network connection`` and ``After the FUT creates the
> Federation, the Test Utility joins the Test Federation and logs service
> invocations via the MOM [Management Object Model]``.  Perhaps Reed can
> explain how these steps in the procedure will work for a federate in a
> single-process federation rather than blithely telling me to go read up on
> HLA compliance testing.

what is different about a ``single-process federate`` ?  seems to me if one
constructs a single-process RTI correctly, ``single-process`` federates look
no different than ``non-single-process`` federates.  they should be able to
join any federation execution, including a Compliance Test Federation.

oh, and by the way.  since the air is so thin up here on the horse, i`m
getting a little dizzy.  so i will not waste any of my remaining
consciousness on this subject.
						reed


To unsubscribe from the Z-ARCHIVE-SIW-CFI list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=Z-ARCHIVE-SIW-CFI