Previous | Table of Contents | Next |
Recognizing that spacecraft operations involve much more than simply controlling the spacecraft, the top-level object is not
‘Spacecraft’ but the more generic term ‘SpaceSystem.’ This name provides deference to the fact that a spacecraft operations
center must control antennas, recorders, ground processing equipment, RF hardware, and many other assets that may use this
data specification; each of these objects is a ‘SpaceSystem.’ A SpaceSystem, like all of the major objects in an XTCE database,
may have a short description, a long description (that may contain HTML markup documentation) and a list of alias names. A
SpaceSystem may have a Header, zero or more sub-SpaceSystems, CommandMetaData, and TelemetryMetaData. The CommandMetaData
and TelemetryMetaData components contains the bulk of the Telemetric and Command data. The sub-SpaceSystems give the data
a hierarchical structure.
Note – on the sub-SpaceSystem and the hierarchical structure:
Because a SpaceSystem may itself contain other SpaceSystems, the organization of the data may be organized hierarchical structure
– similar to the structure of a real space system. The hierachical organization offers several important advantages over
a flat entity list:
• Fewer name space collisions – almost every spacecraft contains redundant components for reliability or to accomplish the mission. A communications spacecraft may have a dozen transponders each with the same set of telemetry points and commands. In a flat namespace each of those telemetry points needs to be mapped into a unique name. Using a hierarchical namespace, those identical telemetry points can be simply placed into separate sub-SpaceSystems.
• Better organization – modern spacecraft typically have thousands of commands and tens of thousands of telemetry parameters; this number is trending upward. The directory structure provided by this specification provides an improved way to manage this large volume of data. Each subsystem developer can deliver SpaceSystems representing their subsystem without integration issues.
• Defaults at the SpaceSystem level – many of the attributes needed to define spacecraft parameters (e.g., bit order, byte order) are common to most of the parameters in the spacecraft or spacecraft sub-system. This specification allows these attributes to be assigned at the directory level, thereby avoiding their repetition in each parameter.
• Spacecraft that are normally thought of as a SpaceSystem, may actually be sub-SpaceSystems for a constellation of spacecraft SpaceSystems.
• Natural hierarchy – spacecraft designs are increasing in complexity and are normally comprised of systems of systems. The hierarchical organization allowed by a directory structure reflects this.
Note – on Names:
Parameter, and MetaCommand and other major entity names within this database may be any length but are prohibited from containing
the ‘/’, ‘.’, and ‘:’ characters as these are reserved. The ‘/’ is used as the SpaceSystem separator (Unix and HTTP style).
The ‘:’ is reserved for future use as a selector for data from other SpaceSystems. The ‘.’ is reserved as an attribute selector.