TEST SEQUENCE READ ME FILE
June 15, 1998

The Test Sequence you received is documented in Message Sequence Chart (MSC)
notation.  MSCs are an ITU (formerly the CCITT) standard for representing
service sequences.  Since the services in the HLA interface specification can
be represented in a dependency tree (by looking at the service relationships),
MSCs are a convenient way to represent the HLA service sequences.  

Your Test Sequence contains one or more sub-sequences (depending on your
conformance statement).  A sub-sequence contains a set of services required to
accomplish a specific function (e.g., update attribute values).
The services contained in the sub-sequences are based on the pre-conditions
and post-conditions listed in the Interface Specification.
In the Test Sequence, the service sub-sequences are identified by the keyword
"MSC" followed by a sequence name (e.g., MSC RespondToPause).
In the lines following the sub-sequence name, you will find one or more
services required to accomplish this sub-sequence.  For example:

  MSC RespondToPause 
    Initiate Pause
    Paused Achieved

  MSC UpdateAttributes
    Request Id
    Publish Object Class
    Register Object
    Update Attribute Values

The sub-sequences contain the keywords IN and OUT.
"IN" means a service is coming IN to the Federate Under Test (FUT) from the RTI.
"OUT" means a service is going OUT to the RTI from the FUT.
For all services that contain the keyword IN (indicating the service is invoked
by the RTI), the FUT must have an auxiliary federate capable of creating the
necessary conditions so that the RTI invokes this service (see the Conformance
Guide, section 3.2.2 Interface Test Set-Up).  For example, if your FUT can
InitiatePause and AchievePause but does not RequestPause, the FUT is
responsible for supplying a federate that will invoke the RequestPause service.

Some services in a sub-sequence include supplied parameters.  This means
that the sub-sequence is context sensitive and is related to the FUT's SOM.
The sub-sequences that are context sensitive are populated with data (i.e.,
objects, attributes, interactions, and parameters) from your Representative SOM
(see the Conformance Guide, section 2.3.3 Representative SOM Data).
For example, the populated entry
  PublishObjectClass (object_class=Tank, attrib_set={Weight, Color})
in the Test Sequence means that the FUT is expected to publish the attributes
"Weight" and "Color" from the object class "Tank".
If no data appears in the supplied parameter list, e.g.
  PublishObjectClass (object_class, attrib_set)
the FUT can invoke the service using any valid supplied parameters.
All services in a sub-sequence must be consistent.  If a supplied parameter
appears in more than one service of a sub-sequence, the FUT must use the same
supplied parameter in each service.  For example, in the Update Attribute Values
sub-sequence the services must all be invoked for the same object_id.  

In the Test Sequence you received, you will only see the services you asserted
in your Conformance Statement.  These services (and their associated
sub-sequence) are listed in random order.  In other words, you can execute
these sub-sequences in any order you choose (e.g., pause before update
attribute values, or vice versa).  However, you must execute the services
within a sub-sequence in the order specified, as required by the Interface
Specification.  The FUT must prove the sub-sequence with the specified data
(if it is context-sensitive) in order to pass the interface test.

If you have questions, please contact Margaret Horst at 404-894-3578 or
margaret.horst@gtri.gatech.edu.