OVERVIEW
of
the
GENERALIZED TETHERED OBJECT SIMULATION SYSTEM
In the early ‘80’s NASA Johnson Spacecraft Center was faced with upcoming space tether experiments to be flown aboard the Shuttle. Such flights would have to pass preflight control system and safety certifications. Based on the author's experience in tether analysis (starting in 1961), then encompassing his key roll in the tether flight experiments on Gemini XI and XII (in the mid 60's), he was approached by JSC to provide the means to perform these Shuttle certifications in the context of JSC’s existing Orbiter engineering simulations. From this effort was born the GTOSS tether analysis capability, a by-product of the author’s software design (which had provided the necessary tether capability for JSC’s existing simulations). The vast generality of GTOSS has resulted in it's currently being used to analyze virtually all dynamics aspects of the Space Elevator, a new development in space transportation.
The GTOSS software system consists of over 500 subroutines representing 60,000 lines of code, with 15 volumes of documentation (over 800 pages) describing user operation, mathematical model derivations, and system software design, and user application interfaces. A total of about 160 megabytes of code and support data constitutes a CD Delivery of GTOSS. GTOSS programming is characterized by top down design, object oriented structure, modular isolation of environment effects simulation, and convenient software hooks provided for user modification. The code is constrained to a highly portable subset of Fortran, and runs on all "mainframe computers" as well as PC's under the Macintosh and Windows OS. Automated verifying of code modification is provided.
GTOSS has been used extensively in the Aerospace industry for the last 25 years. Thus, it has benefited from extensive verification. Here are some Organizations and Projects that have employed GTOSS.
All these described features are available in the GTOSS Version H.9 nominal delivery.
Basic Dynamic Degrees of Freedom
• Up to 9 bodies.
• Bodies can have 6
degrees-of-freedom (there is a 3 degree-of-freedom particle dynamics option to
eliminate rotational dynamics overhead, this is for efficient study of overall
topological behavior).
• Concurrent simulation of up to 25 different tethers.
• Tether inter–connection in any conceivable fashion at up to 8 attach–points per body (each attach point is specified by its coordinates in an arbitrary body axis frame).
• No practical constraints on tether/attach point connectivity.
• Tethers can be attached to the Planet (space elevators, rocket powered slings).
• No restrictive orbital motion assumptions (such as Circularity, LEO, etc).
• No restrictive object "relative motion" assumptions.
• Multiple tethers can be simulated by your mixed choice of models.
• Massless model (ie. a tether can be a linear spring and a dash pot).
• Point Synthesis (ie. Bead) type finite models (on a tether–by–tether basis, up to 500 nodes per tether; with 3 degrees-of-freedom per node). In applicable situations, Homogeneous Strain Tether (HST) options (which constrain the longitudinal response modes) can be selected; these options usually yield a factor of 10 to 50 improvement in computer solution time)
• Non Uniform Tethers Point synthesis finite model allows the tether to be divided into 15 different regions, each with its own elastic modulus, damping factor, and linearly or quadratically varying (ie. interpolated) elastic diameter, aerodynamic diameter, and mass density.
• Deploy/Retrieval-related momentum transport effects into the domain of the tether is included; corresponding forces are included on the affected TOSS objects.
• All tethers can experience distributed electrodynamic forces; these forces reflect current-density that can vary along the length of the tether in contact with the plasma environment (see Environments, below), which in turn depends upon the type of electrodynamic attributes of the tether, such as fully -vs- partially insulated, etc.
• All tethers can experience distributed aerodynamic forces in both the orbital environment and the low atmospheric subsonic environment.
• Tether breaks can occur on specified time, or limit tension at a specified positions.
• Point synthesis tethers can be severed at multiple points (for fragmentation studies).
• Point synthesis tethers can be initialized to a variety of wave form displacements and rates as well as large amplitude skip-rope.
• A tether can be subject to heat gain from the following sources:
- Direct Solar Radiation
- Planet Albedo
- Planet Infrared Radiation
- Aerodynamics
- Electrical (Ohmic)
• A tether can be subject to heat loss from the following sources:
- Radiative heat dissipation
- Heat conduction to and from end bodies
• A tether can experience the following thermal effects:
- Thermal longitudinal expansion
Tether Deployment and Retrieval
Capability
• Presently, Ten different user configurable data–driven deployment scenarios. These can be assigned to any tether, and configured as any combination of:
- Ldot/Length vs Length scenario
- Length rate vs Time scenario
- Length or Length rate pulses vs Time scenario
- Various Tension Control scenarios
- Tension vs Length (data configurable SEDS type deployer) scenario
- End Object Acceleration Control scenarios
- A functional simulation of the TSS type deployer
- User defined (hooks provided for new user-programmed scenarios)
Tether Electrodynamic Features
• Five different user configurable data–driven power generation scenarios. These can be assigned to modulate electric current in any tether, and can be configured as any combination of:
- Power vs Time scenario
- Power vs Planet shadow passage scenario (day/night generation)
- User defined (hooks provided for new user-programmed scenarios)
• Simulation of "bare wire" conducting tethers featuring:
- Non-uniform current-density along length of tether
- Simulation of atmospheric plasma environment
- Bare wire "plasma contact" simulation
- Partial or full wire insulation simulation
Initialization and Execution
Options
• Selection from a variety of 6 DOF dynamic state initialization options.
These
include specification of object translational states via range, and range rate,
libration (of a variety of types) and libration rate, circular orbits, etc;
Object 6 degree-of-freedom rotational states via Euler angles (of a variety of
types, with respect to a variety of reference frames) and Euler rates , or Body
rates, etc.
• Reference Point body can be fixed to the planet frame to allow simulation of objects suspended from structures, or balloons moored to the ground, Space Elevators, etc.
• For the above Reference Point planet fixed option, arbitrary motion of the location of the planet-constrained reference point with respect to the planet can specified by the user in terms of time-varying functions providing position, velocity and acceleration time histories.
• Gravity Gradient Stabilized initialization option (which applies to multiple objects and tethers, including tethers with non-uniform mass and stiffness, ie. tapered tethers).
• Special “Space Elevator” type Centrifugal/Gravity-Gradient Stabilized initialization option (also applies to single or chained non-uniform tethers).
• Finite tethers can be initialized to arbitrary shapes (displacements and rates). This includes longitudinal pulse distortions.
• Finite tethers can be initialized to skip rope states of any mode (ie. 1st, 2nd, 3rd, etc). This is easily specified by the user and applies to large amplitudes (ie. child’s skip rope mode in which the tether maintains tension only due to centrifugal effects rather than the intrinsic static-strain induced tension of classical string theory).
• Total modular isolation of ALL natural environment attributes and evaluations for ease of user replacement of environment models. This makes it simple to configure GTOSS to solve Lunar or other planetary tether problems.
• Gravitational Field Model: An earth Inverse square central force field, plus two different Oblateness models (one is the official Tethered Satellite verification model). Also simple inverse-square gravity models are included for all the solar system planets.
• Globe Shape Model: Earth Spherical globe, and Fischer Ellipsoid.
• Atmospheric Model: Earth; 1976 Standard earth density, speed of sound, and temperature model (3% accuracy to 1000 KM).
• Atmospheric Kinematics Model: Earth; Rotating atmosphere plus superimposed local wind perturbations in the form of user-specified, altitude-dependent, wind speed and azimuth; a gust-type wind perturbation capability is also provided along with user-provided code-hooks to facilitate insertion of arbitrarily complex wind environments.
• Atmospheric Plasma Model: IRI-2001 date and time sensitive ionospheric plasma particle model.
• Magnetic Field Model: Earth; simple tilted, shifted, vector dipole and the World Data Bank II magnetic model with 10 levels of fidelity.
• Inertial Frame Model: Planet centered inertial point, with a choice of: Inertial frame alignment to planet–fixed frame at zero simulation time, or, the B1950 (Mean Aries alignment), or, the J2000 alignment (the most recent astronomical standard). Proper Sun position as a function of Julian time is automatically provided in the later two options.
• An arbitrarily configurable flexible boom can be attached to one object for the purpose of simulating tether/boom dynamic interaction.
• The boom is simulated via a "modal synthesis" approach allowing up to 5 modal coordinates for each of in-plane and out-of-plane response. Cantilevered orthogonal modes are used, with all rigid-body/flexible-boom dynamic coupling terms included.
• Dual stiffness regimes are allowed for simulating small/large deflection joint stiffness effects.
• All objects can experience simple aerodynamic drag.
• TOSS is designed to facilitate incorporation of any type "object attribute" (for instance propulsion and attitude control systems).
• TOSS supports arbitrarily complex simulation of mass properties, control systems, aerodynamics, tether deployment, and power generation, etc. through its documented user–interface data structures, modularized code, and logical hooks which invite and assist in user modification.
• When TOSS is incorporated into a host simulation, all the system models present in the host then function in the tether environment provided by TOSS.
• All Objects have a simplified, user configurable, attitude control system. which provides rate damping on all axes, and allows all-attitude hold mode or single-axis hold modes.
• Tethers can be attached to a planet providing a simulation capability for tethered balloons, kites, “suspended” objects, “space elevators”, etc.
• Standard selectable column formatted time histories.
• Column delimited graph plot files for use with interactive engineering graphing software packages. Supports both time histories as well as tether shape snapshots.
• Animation output files which automatically drive Macintosh based three dimensional solution animation and video production.
• Sequential ASCII output files supporting data export and import (including the TSS standard data verification format definition).
• Structured output system designed to support user modifications for specific output requirements.
GTOSS is a tether
analysis–complex best described by addressing its family of modules,
which are more or less tightly associated as a cooperative whole.
The
GTOSS COMPLEX consists of the following application modules:
•
GTOSS Generalized
Tethered Object Simulation System
•
TOSS Tethered
Object Simulation Sub-system
•
RTOSS Results
Data Base (RDB) sub-system
•
BTOSS Boom
(ie Flexible tether boom) sub-system
•
DTOSS Data-printout
system (an RDB post-processor)
•
CTOSS Column-delimited-graphics
system (an RDB post-processor)
•
STOSS Super
3-D Dynamics Animation system (an RDB post-processor)
•
UTOSS Universal
Data Export/Import system (an RDB post-processor)
•
VTOSS Verification
system for automated verification of TOSS code modifications
The following sections outline each major module, defining its roll in the complete scheme, as well as providing other pertinent information.
TOSS
DESCRIPTION
TOSS is a portable software sub–system specifically designed to be introduced into the environment of any existing vehicle dynamics simulation (called the "Host") to add the capability of simulating multiple interacting objects (via multiple tethers). These objects may interact with each other as well as the host vehicle into whose environment TOSS has been introduced. TOSS is incorporated by adherence to a straightforward set of interface rules set forth in the TOSS Interface Control Definition. With NO small motion limitations, NOR restricting orbital state assumptions, AND with complete generality, TOSS solves the tether dynamics problem relative to a reference point state defined for it by the host simulation. This is called the TOSS Reference Point, or RP.
As delivered, TOSS allows the simulation of up to: nine objects, each with six (or three) degrees of freedom; inter-connected in any conceivable fashion at eight attach points per body; via twenty five tethers. There are no practical constraints on connectivity. All the above limits can be extended via procedures included in the manuals. The tethers can be simulated as a choice of massless (linear springs and dash pots between specified attach points) or as distributed mass bead-string type point synthesis models. A particle dynamics mode can be invoked whereby the computational overhead of end-object rotational dynamics is eliminated (this is efficient for configuration design in which topological stability or overall translational behavior is of interest).
Input is designed for easy data identification, and allows provisions to expedite parameter studies. Extensive initialization options (such as stabilized gravity gradient start–up, Euler angle type selection, etc.) allow user–friendly run setup. TOSS supports arbitrarily complex: mass property; control; and aerodynamic calculations. In general, all code is structured and commented to assist in user modification if desired.
GTOSS
DESCRIPTION
GTOSS is a stand–alone tethered system analysis program, representing an example of TOSS having been married to a host simulation. In order to verify the TOSS design concept and exercise the TOSS ICD ground rules, it was necessary to create a representative, yet easily managed simulation into whose environment TOSS could be incorporated. The resulting union was called GTOSS and has the properties of, and can be viewed as, a system tailored to the purpose of examining dynamic behavior of general tethered object configurations (space stations, constellations, etc). By contrast, TOSS has also been integrated into a Shuttle simulation (to study TSS), with the resulting association exhibiting (and rightfully so) the complexity and specificity of a flight certification quality simulation of the Orbiter. The GTOSS host simulation represents a 6 degree-of-freedom object with 8 tether attachment points. GTOSS has an executable code size of about 500k Bytes.
Input and initialization for GTOSS (as an entity separate from TOSS) is similar to that of TOSS. GTOSS provides output for itself (the host) as well as TOSS by invoking RTOSS to generate a Results Data Base to archive results for display.
RTOSS
DESCRIPTION
RTOSS is the Results Data Base (RDB) Sub–system designed to archive TOSS simulation results for future display processing. While RTOSS was designed primarily to capture TOSS data, it offers Wild–Card files which can be used by any users to capture data of their choice. For instance, GTOSS takes advantage of this feature to capture its host simulation data to an RDB for display post processing. The modular design of RTOSS requires minimal calls (from the host simulation) to invoke the creation and population of an RDB (for instance in GTOSS, this act is transparent to the user). At the end of a run, a set of files with unique names will have been created containing all pertinent time history data.
Also inherent in RTOSS are the routines which will extract data from the RDB and present it in a form most natural for display post–processing. These extraction routines insulate the user from the data structure of the RDB, thus rendering the user's display software invariant to future changes in RDB design. An RDB can be post–processed in arbitrary fashion for interpretation, as described below. Frequently, the incorporation of RTOSS (and its wild-card files) into an existing simulation (in need of a results data base) can satisfy all the data archiving needs of a host simulation.
BTOSS
DESCRIPTION
BTOSS is a module which provides a flexible boom simulation which can be integrated into any Host (similar to the way in which TOSS is). This is a full dynamically accurate slender beam model using normal mode shapes as generalized coordinates and allowing tethers to be attached to the end of the boom.
DTOSS
DESCRIPTION
DTOSS was the first in the family of display post processors designed to utilize the RDB. DTOSS extracts data from the RDB for extensive multi–page printed time history displays. There are currently over 50 different display formats to choose from, each of which aggregates data selected to meet various display needs. Users are also invited to add new page formats to create output for specific needs.
A major benefit of DTOSS type post processing is that RDB data is extracted and presented to the user (for display processing) in a form that renders invisible the schema by which the data is archived in the RDB, thus rendering the display-application-software invariant to future changes in the RDB design.
CTOSS
DESCRIPTION
CTOSS is similar to DTOSS, but is designed to create ASCII plot files (as headers and data columns separated by delimiters, i.e. data tables). The same time history data formats provided by DTOSS (for printing) are available via CTOSS for plotting. In addition to time histories, repetitive tether shape snapshots can be taken in CTOSS. Plot files are optimally configured for interactive graphics programs on desktop or mainframe computers. Since CTOSS generates ASCII plot files (which are easily transported between different computers), it can be run on any mainframe, generating plot files downloadable to desktop workstations.
STOSS
DESCRIPTION
STOSS differs from DTOSS and CTOSS in two ways. First, it generates output data designed to produce 3–D animated graphics display of simulation results. Second, its output is targeted specifically for the Super 3-D™ graphics program available for the Macintosh computer. Any configuration that can be analyzed on GTOSS (no matter how topologically complex), can be easily animated to produce on screen (or video tape, if you have the proper hardware) 3-D movies of the tether behavior. Again, since STOSS generates an ASCII animation command file (which are easily transported across computer platforms), STOSS can be run on any mainframe and the results downloaded to the Macintosh for animation.
UTOSS
DESCRIPTION
UTOSS is designed to expedite the creation of data files to be exported from GTOSS to other facilities for simulation verification, animation or special displays, etc. Furthermore, UTOSS allows data originating in other simulations to be introduced into GTOSS (via a pre-defined import format). The imported data can then be post processed into printouts (via DTOSS), graphs (via CTOSS), or 3-D dynamic animations (via STOSS).
VTOSS
DESCRIPTION
VTOSS automates the process of verifying code changes to GTOSS/TOSS. First, UTOSS is used to create special data snapshots of official verification runs from a verified version of GTOSS. This same process is repeated for a new candidate version of GTOSS. VTOSS then compares these two sets of data, providing complete reports on any discrepancies, and allowing data differences to be filtered in a variety of ways to expedite interpretation of differences which may exist.
General
Simulation Result Display
The above RDB post–processors also function as convenient templates to spawn specialized display processors. Also, hooks are clearly defined, and steps are documented to modify DTOSS, CTOSS, or UTOSS to add new formats.
These coordinate systems are used and managed within in TOSS as follows:
A. TOSS Inertial Frame. Arbitrarily definable, however, its relationship to the planet–fixed frame must be explicitly stated in the TOSS routine invoked to transform inertial frame components to the planet–fixed frame. This routine (and its inverse–routine) can describe an arbitrary relationship between inertial and planet–fixed frames. As delivered, the inertial frame is aligned with the planet–fixed frame at zero simulation time. All dynamics state solutions are implemented in this frame. See Planetary Environment Models for details of delivered inertial frame capabilities.
B. Planet–fixed Frame. This is the frame in which all planetary environment calculations are defined. It can be arbitrarily defined; however, its relationship to the inertial frame must be explicitly stated in the TOSS routine which transforms planet frame components to the inertial frame, and environment calculations must be consistent with its definition. As delivered, GTOSS environment routines assume an earth–fixed frame, the +X axis of which is presumed to pass through the Greenwich meridian, +Z axis through the geocentric North pole.
C. Topocentric Frame. This is a frame aligned along local spherical longitude, latitude, and radius vector to the planet center. It is used for state initialization options and result interpretation.
D. Orbital Frame. This is defined by the kinematic state of a point. The X axis (orbital direction) and Z axis (local vertical) define the current orbital plane. The Y axis is normal to the orbit. Any TOSS entity can have an associated orbital frame, used for state initialization options and result interpretation.
E. Body Axis Frame. A body–fixed frame (and a body station reference point) is associated with each 6 degree-of-freedom object. The frame and body station are arbitrary, but must be consistently used for defining all body attributes (CG location; tether attach–points; aerodynamic reference point; etc). This frame is the reference for body attitude interpretation.
F. Tether Frame. Each finite tether has its own tether frame. The X axis of this frame is aligned along the line of sight between the tether's attach points. The Z axis is orthogonal to the first, but lies in the orbital plane (of a preferred kinematic point). The Y axis is defined to complete the triad. This frame is used for initialization options and result interpretation only. While the tether frame is undefined when the line of attach points is precisely normal to the plane of orbit of the TOSS reference point, it does not effect the tether dynamics solution (which occurs undisturbed in the TOSS inertial frame).
G. Boom Frame. The X axis is aligned along the longitudinal axis of the boom. The Y and Z axis orientations define in/out-of plane boom deflections. The triad has fixed orientation with respect to the object body frame (in terms of user specified Euler angles). This frame, hosting the boom dynamics, solution, and is used for initialization options and result interpretation.
The following summarizes the currently known limitations to the use of GTOSS/TOSS.
• Tether bending and torsional stiffness is not modeled at present (the tether is modeled as a non-linear tensile string).
• Certain Environmental Effects (for example, solar pressure effects) are not incorporated into TOSS at present.
• The orientation of the Tether Frame (used as a convenience for result interpretation) is undefined if attach point line–of–sight becomes exactly perpendicular to an associated orbital plane. This does not affect the integrity of the finite tether solutions (which occur in the inertial frame), but could render initialization unsuccessful.
Much of flight readiness certification
for the NASA TSS Orbiter mission has involved flight dynamics simulation of
the tethered satellite configuration. The GTOSS complex has played a key role
in this process. To enhance confidence in simulation results, NASA has subjected
TOSS to an extensive simulation verification program in which virtually hundreds
of different types of flight situations have been simulated with resultant
predictions being compared between TOSS and identical runs made on the Martin
Marietta (prime contractor on the TSS deployer) high fidelity simulation of
the TSS. While this simulation rectification cannot prove the physical validity
of the simulations (as only real flight data can), comparisons of independent
simulations has enhanced confidence in these tools. In addition, simulations
by Smithsonian Astrophysical Observatory and the Control Dynamics Corporation
have also been reconciled for chosen runs. The "bare wire" current
conduction feature has been extensively verified against an independent (SAO)
simulation used by Marshal Space Flight Center in designing the ProSEDS electrodynamic
reentry project. GTOSS has also been used extensively in the design and operations
of the TIPS mission for the Naval Research Laboratory.
As tethered flight data and experience
has become available, GTOSS results have been compared with actual flight
data. This was done extensively on the TSS program, and revealed that GTOSS
predictions were well within appropriate engineering accuracy in this application.
Version F.11 GTOSS documentation (more or less described below) has been extensively changed (in the form of numerous system-specific, independent volumes) to enhance usability, and to localize the impact of sub-system evolution to specific related manuals.
The version F.11 documentation consists of the following separate volumes, which are (by category):
User Operations Manuals
• GTOSS User Manual
• TOSS User Manual
• General Post Processor User Manual
• DTOSS Specific User Manual
• CTOSS Specific User Manual
• STOSS Specific User Manual
• UTOSS Specific User Manual
• VTOSS User Manual
• Quick Reference Guide
Reference Manuals
• Installation Manual
• RTOSS Reference Manual
• TOSS Interface Control Definition
• Design Document
• Equation Document
• Flexible Boom Reference Manual
• Tether Reference Manual for Host-tethers-only
ADMONITIONS
IMPORTANT
NOTE: MANY CONCEPTS
WHICH THE DOCUMENTATION HAS ASSUMED TO BE COMMON KNOWLEDGE (TO THE USER), ARE
IN FACT INTRODUCED AND DEFINED ONLY IN THE TOSS Interface Control Definition MANUAL
(ICD).
Hence, even if you only use
GTOSS as a stand-alone entity (ie. that is, not incorporating TOSS into
your host simulation, where the ICD must be well comprehended), you will still
find a cursory reading of the ICD to be beneficial.
To effectively use GTOSS, you must read the TOSS user manual (since the GTOSS user manual does not cover material on tethers, etc, but, rather only attributes of the host simulation).
The site installation runs provide valuable examples of run streams which accomplish a variety of simulations, and serve as useful starting points (templates or skeletons) for the creation of your run streams.
Perusal of the input skeleton files (included in the delivery, containing the input data item ID's for every input item known to GTOSS, etc) can function admirably as a complete features expose'.
Given below is a brief resume of the contents of some of the documentation.
GTOSS
User Manual
Defines data pertaining to the Reference Point Generator, and minimum user oriented data required to invoke Results Data Base archiving.
TOSS
User Manual
Defines data pertaining to TOSS objects, tether definition, deployment processes, power generation, and options associated explicitly with TOSS.
General
Post Processor User Manual
Defines the general operations of post processing the Results Data Base which apply to the entire post processing family of routines.
DTOSS
Specific User Manual
Defines the operation of post processing the Results Data Base into time history displays which can be printed.
CTOSS
Specific User Manual
Defines the operation of post processing the Results Data Base into column delimited display files suitable as input to third party plotting software.
STOSS
Specific User Manual
Describes process of creating animations of GTOSS/TOSS results. Gives theory and useful hints for animation effects.
UTOSS
Specific User Manual
Describes general structure and uses of UTOSS. Points out how UTOSS is used to create auto-verification files.
VTOSS
User Manual
Provides information on structure of VTOSS and procedures for auto-verification of GTOSS. Also points out how to use VTOSS to auto-verify host simulations which incorporate TOSS as a tether module.
Quick
Reference Guide
This volume contains a potpourri of information, some of which is unique to this document, others of which has been duplicated from other documents (to which frequent reference is made), but all of which has been found to be highly useful, whether setting up runs, or modifying code.
Installation
Manual
This volume contains information useful to the installation and use of GTOSS. For instance, descriptions of test runs are provided. In addition, explicit examples of physical system modeling with GTOSS are included (showing system geometry and GTOSS run input stream.
RTOSS
Reference Manual
This manual provides an in-depth description of the Results Data Base subsystem. This includes file descriptions, design documentation, etc. It is provided to assist the user who wishes to modify the RDB data archiving, or integrate RTOSS into another (TOSS related) system.
TOSS
Interface Control Definition
The Interface Control Document specifies the ground rules to be followed to implement an interface between TOSS and any other simulation. It is also valuable preliminary reading material for the GTOSS user.
Design
Document
Provides a potpourri of miscellaneous information about the details of design, tradeoffs, and other information that would be useful to one becoming involved with system modifications, etc.
Equation
Document
Provides detailed equation derivations, modeling assumptions, and analytical symbol-to- Fortran variable equivalences.
Flexible
Boom Reference Manual
Provides detailed equation derivations, modeling assumptions, and Host simulation interface procedures for the flexible tether boom subsystem.
Tether
Reference Manual for Host Tethers-only Implementation
Provides everything a user of a Host system needs to know about TOSS tethers in the case of a Host interface implementation in which only TOSS tethers are incorporated (ie the TOSS objects are not available, but rather are being provided in the context of the Host simulation).