The specification addresses the need for a standardized information model capable of supporting TM/TC definitions across the broadest possible range of space domain activities. The goal is to allow TM/TC definitions to be exchanged between different organizations and systems, often at the boundaries of mission phases, without the need for customized import/export, re-validation, or even re-implementation of mission databases. The scope of this specification is limited to satellite telemetry and commanding data constructs necessary to support satellite and payload data design: • Telemetry data definitions including support for CCSDS packets as well as TDM frames. • Data manipulation algorithms to support packaging and unpacking of individual data items. • Commanding data definitions including command identification, argument specification, and validation criteria. • Data representation definitions. • Data properties including such things as its default value, validity criteria, and data dependencies. • The definition of extensible formats such that blocks of information (whether frames of data that are not decommutated or object references or object method calls) can be portrayed in this architecture. The scope of this specification does not extend to: • Data distribution mechanisms. • Command and data protocol specifications. • RF or analog stream characterization. • Data groupings including aggregation and coherent data sets. • Data Representation (visualization properties). • Scheduling configuration properties. • Orbital properties. The specification addresses only the definition of TM/TC data, and not the transfer of live or historical TM/TC data. The schema (.xsd file) in Annex A is normative. A compliant database is an XML file that complies with this schema. Fully compliant implementing software will interpret and/or generate any databases compliant with this specification. Compliant implementing software will interpret and/or generate all database elements required by the schema. The following normative documents contain provisions which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. http://www.w3.org/TR/REC-xml W3C Recommendation - Extensible Markup Language (XML) 1.0 (Second Edition, 6 October 2000) http://www.w3.org/TR/xmlschema-0/ W3C Recommendation - XML Schema Part 0: Primer (2 May 2001) http://www.w3.org/TR/xmlschema-1/ W3C Recommendation - XML Schema Part 1: Structures (2 May 2001) http://www.w3.org/TR/xmlschema-2/ W3C Recommendation - XML Schema Part 2: Datatypes (2 May 2001) For the purposes of this specification, the following terms and definitions apply. Telemetering (from IEEE Std 1000 [1972]) “Measurement with the aid of intermediate means that permit the measurement to be interpreted at a distance from the primary detector.? All measurements on board the spacecraft are transmitted to the ground system in a telemetry stream. Telemetry as used here refers to these measurements whether on-board the spacecraft or transmitted to the ground system. Most telemetry measurements will require engineering unit conversion and measurements will have associated validation ranges or lists of acceptable values. Commands Messages that instruct an action on a remote system. Spacecraft commanding usually implies coding and packaging of the command information, validation and verification, as well as authorization to perform. Telemetry and Commanding data are necessarily related to one another, with some command information originating from telemetry and commands relating to particular telemetry measurements. Therefore, the ability to relate individual telemetry with one another and to commands is a very important part of this specification. Packaging of both telemetry and commands can be performed in a number of ways. The most common way to package data for transmission is to use the CCSDS Telemetry and Commanding Packaging format. List of symbols/abbreviations In general, the XTCE specification favors expressive, fully spelled out terms over abbreviated notation. The exceptions are modifiers used as prefixes or postfixes to objects used within the schema, and of course ‘XTCE’ the name of the standard itself. These terms are listed below. Abbreviations Parm An abbreviation sometimes used for Parameter. XTCE XML Telemetric and Command Exchange format. Prefixes and Postfixes Meta A description. For example a MetaCommand is a command description. Set An unordered collection. For example a MetaCommandSet is an unordered collection of command descriptions. List An ordered collection. For example an ArgumentList is an ordered collection of arguments. Ref A reference (by name) to an object defined elsewhere in the XML document. For example an ArgumentRef is a named reference to an Argument defined elsewhere. The following companies submitted and/or supported parts of this specification: • Lockheed Martin • The Boeing Company • The European Space Agency The following companies submitted and/or supported parts of this specification: • Lockheed Martin • The Boeing Company • The European Space Agency 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. SpaceSystemType {mixed=false, complexContentMixed=false} CommandMetaDataType {mixed=false} -MetaCommandSet : MetaCommandSet_AnonymousType [0..1]{sequenceOrder=4} -ArgumentTypeSet : ArgumentTypeSet_AnonymousType [0..1]{sequenceOrder=3} -CommandContainerSet : CommandContainerSetType [0..1]{sequenceOrder=5} -ParameterTypeSet : ParameterTypeSetType [0..1]{sequenceOrder=1} -ParameterSet : ParameterSetType [0..1]{sequenceOrder=2} -AlgorithmSet : AlgorithmSetType [0..1]{sequenceOrder=7} -StreamSet : StreamSetType [0..1]{sequenceOrder=6} TelemetryMetaDataType {mixed=false} -ContainerKey2{selector=Container, field=Id} Defaults_AnonymousType {sequenceOrder=6} -ParameterTimeAssociation : TimeAssociationType [0..*]{sequenceOrder=2} -DefaultDataEncoding : DataEncodingType [0..*]{sequenceOrder=1} HeaderType -HistorySet : HistorySet_AnonymousType [0..1]{sequenceOrder=6} -AuthorSet : AuthorSet_AnonymousType [0..1]{sequenceOrder=2} -NoteSet : NoteSet_AnonymousType [0..1]{sequenceOrder=4} -validationStatus : validationStatus_AnonymousType{use} -classification = NotClassified -classificationInstructions -version -date ServiceSet_AnonymousType {sequenceOrder=4} -Service : ServiceType [*]{sequenceOrder=1} SpaceSystem The Root Object {sequenceOrder=1} -Header 0..1 -CommandMetaData {sequenceOrder=3} 0..1 {sequenceOrder=5} -ServiceSet 0..1 -TelemetryMetaData {sequenceOrder=2} 0..1 {sequenceOrder=7} -Defaults 1 {XMLattributes=base=xtce:NameDescriptionType} NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} Figure 7.1 - SpaceSystem A SpaceSystem may contain an optional header record. This record contains some basic context on the data itself (e.g., source, version, revision history, notes, and classification). Because Telemetry and Command databases are frequently developed and maintained independently, the XTCE format divides TelemetryMetaData and CommandMetaData into separate, but similar sections. TelemetryMetaData is really nothing more than a grouping for data about Telemetry. TelemetryMetaData has a ParameterTypeSet, a ParameterSet, a ContainerSet, a MessageSet, a StreamSet, and an AlgorithmSet. Following are descriptions of these collection types. TelemetryMetaDataType {mixed=false} -ContainerKey2{selector=Container, field=Id} ContainerSetType {maxOccurs=unbounded} -SequenceContainer : SequenceContainerType -ParameterSet 0..1 {sequenceOrder=2} {key_unique_keyRef,sequenceOrder=3}0..1-ContainerSet {sequenceOrder=6} -MessageSet 0..1 0..1 -StreamSet{sequenceOrder=5} StreamSetType {maxOccurs=unbounded} -VariableFrameStream : VariableFrameStreamType -FixedFrameStream : FixedFrameStreamType -CustomStream : CustomStreamType MessageSet_AnonymousType {sequenceOrder=4} -Message : Message_AnonymousType [*]{sequenceOrder=1} -name {sequenceOrder=7} 0..1 -AlgorithmSet {sequenceOrder=1} 0..1 -ParameterTypeSet ParameterTypeSetType {maxOccurs=unbounded} -IntegerParameterType : IntegerParameterType_AnonymousType -ArrayParameterType : ArrayParameterType_AnonymousType -FloatParameterType : FloatParameterType_AnonymousType -AbsoluteTimeParameterType : AbsoluteTimeDataType -RelativeTimeParameterType : RelativeTimeDataType -EnumeratedParameterType : EnumeratedDataType -BooleanParameterType : BooleanDataType -BinaryParameterType : BinaryDataType -StringParameterType : StringDataType ParameterSetType {maxOccurs=unbounded} -Parameter : Parameter_AnonymousType -ParameterRef : ParameterRefType AlgorithmSetType {mixed=false, maxOccurs=unbounded} -CustomAlgorithm : InputOutputTriggerAlgorithmType -MathAlgorithm : MathAlgorithmType Figure 7.2 - Telemetry MetaData ParameterTypeSet A ParameterTypeSet is an unordered collection of ParameterTypes. ParameterTypes are the MetaData for Parameters; ParameterTypes are instantiated to create Parameters. ParameterType is the description of something that can have a value (a Parameter). Information contained in ParameterType includes the data type, description, alarm limits, engineering units, and string conversion specifications and calibrations. Most Parameters are telemetered parameters (a.k.a measurands) and must also include information about how the Parameter value is encoded for transmission. This information includes size in bits, byte order, data type, and parity checks. All of the encoding information is in the Encoding area. BaseDataType-UnitSet : UnitSet_AnonymousType{sequenceOrder=2} StringDataType -ContextCalibratorList : ContextCalibratorList_AnonymousType [0..1]{sequenceOrder=4} -SizeRangeInCharacters : IntegerRangeType [0..1]{sequenceOrder=1} -DefaultCalibrator : CalibratorType [1]{sequenceOrder=2} -characterWidth : characterWidth_AnonymousType -restrictionPattern -initialValue NumericDataType -ContextCalibratorList : ContextCalibratorList_AnonymousType [0..1]{sequenceOrder=5} -ValidRange : ValidRange_AnonymousType [0..1]{sequenceOrder=2} -ToString : NumberToStringType [0..1]{sequenceOrder=1} -DefaultCalibrator : CalibratorType [1]{sequenceOrder=3} -validRangeAppliesToCalibrated = true IntegerParameterType_AnonymousType -ContextAlarmList : ContextAlarmList_AnonymousType [0..1]{sequenceOrder=3} -DefaultAlarm : NumericAlarmConditionType [1]{sequenceOrder=1} FloatParameterType_AnonymousType -ContextAlarmList : ContextAlarmList_AnonymousType [0..1]{sequenceOrder=3} -DefaultAlarm : NumericAlarmConditionType [1]{sequenceOrder=1} EnumeratedDataType -EnumerationList : EnumerationList_AnonymousType{sequenceOrder=2} -initialValue ParameterTypeSetType {maxOccurs=unbounded} FloatDataType -sizeInBits : sizeInBits_AnonymousType = 32 -initialValue ArrayParameterType_AnonymousType -arrayTypeRef : NameReferenceType{use} -numberOfDimensions{use} BooleanDataType -zeroStringValue = False -oneStringValue = True -initialValue AbsoluteTimeDataType RelativeTimeDataType BaseTimeDataTypeIntegerDataType -sizeInBits = 32 -signed = true -initialValue BinaryDataType -initialValue -RelativeTimeParameterType -AbsoluteTimeParameterType -IntegerParameterType -ArrayParameterType -BinaryParameterType -BooleanParameterType -EnumeratedParameterType -StringParameterType -FloatParameterType NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} Figure 7.3 - ParameterTypeSet ParameterSet A ParameterSet is an unordered collection of Parameters. Parameters are instantiations of ParameterTypes. Parameters are normally a very simple name and reference to a ParameterType. Parameters may also have alias names and may have properties unique to that instantiation. At any point in time (instance) a Parameter has a value; a Parameter is not the value itself. Parameter names are case sensitive, may be any length, cannot contain spaces ‘.’, ‘/’, ‘[‘ or ‘]’ as these are reserved characters. The aliases have no restrictions. ContainerSet A ContainerSet is an unordered collection of SequenceContainers. SequenceContainers are defined in the packaging section. The packaging section contains the information required to assemble an uplink from its component parts and disassemble a downlink from its component parts. The packaging section has been created to be extremely generic so that it may be used to define TDM telemetry streams, packetized streams, or any other package format. A SequenceContainer contains (in the EntryList) an ordered list of raw parameters, parameter segments, stream segments, containers, or container segments. SequenceContainers may inherit from other sequence containers. The inheritance aspect of SequenceContainers is useful not only for minimizing the effort required to describe a family of SequenceContainers, but is also a very powerful and expressive means of container identification – the process of distinguishing one container from others (e.g., minorFrame 20 is a type of minorFrame where the minor frame counter equals 8). SequenceContainer inheritance may be arbitrarily deep. ContainerType{mixed=false, complexContentMixed=false} -RateInStreamSet : RateInStreamSet_AnonymousType [0..*]{sequenceOrder=3} -BinaryEncoding : BinaryDataEncodingType [0..*]{sequenceOrder=4} -DefaultRateInStream : RateInStreamType [0..*]{sequenceOrder=1} BaseContainer_AnonymousType {sequenceOrder=2} -RestrictionCriteria : RestrictionCriteria_AnonymousType{sequenceOrder=1} -containerRef : NameReferenceType{use} ArrayParameterRefEntryType -DimensionList : DimensionList_AnonymousType{sequenceOrder=2} -parameterRef : NameReferenceType{use} -lastEntryForThisArrayInstance = false IndirectParameterRefEntryType -ParameterInstance : ParameterInstanceRefType{sequenceOrder=1} -aliasNameSpace NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} ParameterRefEntryType -parameterRef : NameReferenceType{use} ParameterSegmentRefEntryType -parameterRef : NameReferenceType{use} -sizeInBits{use} -order ContainerRefEntryType -containerRef : NameReferenceType{use} ContainerSegmentRefEntryType -containerRef : NameReferenceType{use} -sizeInBits{use} -order SequenceContainerType -idlePattern : FixedIntegerValueType = 0x0 -abstract StreamSegmentEntryType -streamRef : NameReferenceType{use} -sizeInBits{use} -order ContainerSetType {maxOccurs=unbounded} EntryListType {mixed=false, minOccurs=0, maxOccurs=unbounded} -ParameterRefEntry -ContainerSegmentRefEntry -SequenceContainer -ContainerRefEntry -ParameterSegmentRefEntry -ArrayParameterRefEntry -IndirectParameterRefEntry -StreamSegmentEntry {sequenceOrder=3} -BaseContainer 0..* {XMLattributes=base=xtce:NameDescriptionType} {XMLattributes=base=xtce:ContainerType} {sequenceOrder=1} -EntryList Figure 7.4 - ContainerSet A SequenceContainer may represent a packet, a frame, a sub-frame, or any other grouping/structure of data items. The simple form of a Sequence element is an ordered set of Parameter References or other Container References. XML Telemetric & Command Exchange (XTCE), v1.0 MessageSet A MessageSet is an unordered collection of Messages. Messages are an alternative method of uniquely identifying containers within a Service. A message provides a test in the form of MatchCriteria to match to a container. A simple example might be: When minorframeID=21, the message is the 21st minorframe container. The collection of messages to search through will be bound by a Service. StreamSet A StreamSet is an unordered collection of Streams. Spacecraft uplinks and spacecraft downlinks are digital streams of data and there are a number of processing functions that are done on the stream level. The stream section contains the knowledge for how to assemble, disassemble, and process spacecraft uplink and downlink streams. CustomStreamType -DecodingAlgorithm : InputOutputAlgorithmType{sequenceOrder=2} -EncodingAlgorithm : InputAlgorithmType{sequenceOrder=1} -decodedStreamRef : NameReferenceType{use} -encodedStreamRef : NameReferenceType{use} VariableFrameStreamType -SyncStrategy : SyncStrategy_AnonymousType{sequenceOrder=1} FixedFrameStreamType -SyncStrategy : SyncStrategy_AnonymousType{sequenceOrder=1} -frameLengthInBits{use} -syncApertureInBits = 0 FrameStreamType -StreamRef : StreamRefType [0..*]{sequenceOrder=2} StreamSetType {maxOccurs=unbounded} NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} PCMStreamType-pcmType : pcmType_AnonymousType = NRZL -inverted = false -bitRateInBPS -CustomStream -FixedFrameStream -VariableFrameStream Figure 7.5 - StreamSet AlgorithmSet An AlgorithmSet is an unordered collection of Algorithms. In spacecraft ground systems, it is necessary to perform some specialized processing to process the telemetry, and preprocess commands. There are a number of predefined algorithms and the algorithm section makes it possible to reference externally defined algorithms for arbitrarily sophisticated data processing. NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} SimpleAlgorithmType -ExternalAlgorithmSet : ExternalAlgorithmSet_AnonymousType [0..*]{sequenceOrder=3} -AlgorithmText : AlgorithmText_AnonymousType [0..*]{sequenceOrder=1} InputOutputAlgorithmType -OutputSet : OutputSet_AnonymousType [0..1]{sequenceOrder=2} -thread{use} InputAlgorithmType -InputSet : InputSet_AnonymousType [0..1]{sequenceOrder=1} MathAlgorithmType -MathOperation : MathOperationType{sequenceOrder=1} AlgorithmSetType {mixed=false, maxOccurs=unbounded} InputOutputTriggerAlgorithmType -TriggerSet : TriggerType [0..1]{sequenceOrder=1} -triggerContainer : NameType{use} -priority{use} -name : NameType{use} -shortDescription{use} -MathAlgorithm -CustomAlgorithm Figure 7.6 - AlgorithmSet The CommandMetaData element is very similar to TelemetryMetaData, but also contains information that is specific only to commanding. CommandMetaData has a ParameterTypeSet, a ParameterSet, a ContainerSet, a MessageSet, a StreamSet, and an AlgorithmSet – exactly like TelemetryMetaData. CommandMetaData, however, also has an ArgumentTypeSet and a MetaCommandSet. ArgumentTypeSet_AnonymousType {maxOccurs=unbounded} -ArgumementArrayType : ArgumementArrayType_AnonymousType -IntegerArgumentType : IntegerArgumentType_AnonymousType -FloatArgumentType : FloatArgumentType_AnonymousType -AbsoluteTimeArgumentType : AbsoluteTimeDataType -RelativeTimeAgumentType : RelativeTimeDataType -EnumeratedArgumentType : EnumeratedDataType -BooleanArgumentType : BooleanDataType -BinaryArgumentType : BinaryDataType -StringArgumentType : StringDataType ParameterTypeSetType {maxOccurs=unbounded} -IntegerParameterType : IntegerParameterType_AnonymousType -ArrayParameterType : ArrayParameterType_AnonymousType -FloatParameterType : FloatParameterType_AnonymousType -AbsoluteTimeParameterType : AbsoluteTimeDataType -RelativeTimeParameterType : RelativeTimeDataType -EnumeratedParameterType : EnumeratedDataType -BooleanParameterType : BooleanDataType -BinaryParameterType : BinaryDataType -StringParameterType : StringDataType CommandMetaDataType {mixed=false} -ParameterSet 0..1 {sequenceOrder=2} -MetaCommandSet 0..1 -ParameterTypeSet 0..1 {sequenceOrder=1} {sequenceOrder=4} MetaCommandSet_AnonymousType {maxOccurs=unbounded} -ArgumentNameKey{selector=xtce:ArgumentList/*, field=@name} -BlockMetaCommand : BlockMetaCommand_AnonymousType -MetaCommand : MetaCommandType{key_unique_keyRef} -MetaCommandRef : NameReferenceType -CommandContainerSet 0..1 {sequenceOrder=5} CommandContainerSetType -CommandContainer : SequenceContainerType [*]{sequenceOrder=1} -StreamSet 0..1 {sequenceOrder=6} {sequenceOrder=3} 0..1 -ArgumentTypeSet StreamSetType {maxOccurs=unbounded} -VariableFrameStream : VariableFrameStreamType -FixedFrameStream : FixedFrameStreamType -CustomStream : CustomStreamType -AlgorithmSet 0..1 {sequenceOrder=7} AlgorithmSetType {mixed=false, maxOccurs=unbounded} -CustomAlgorithm : InputOutputTriggerAlgorithmType -MathAlgorithm : MathAlgorithmType ParameterSetType {maxOccurs=unbounded} -Parameter : Parameter_AnonymousType -ParameterRef : ParameterRefType Figure 7.7 - CommandMetaData ArgumentTypeSet An ArgumentTypeSet is an unordered collection of ArgumentTypes. ArgumentTypes (very similar to ParameterTypes) are the MetaData for Command Arguments; ArgumentTypes are instantiated to create Arguments. ArgumentType contains the description of something that can have a value and is used as an operator supplied option to a Command (Command Argument). Information contained in ArgumentType includes the data type, description, valid range, engineering units, and string conversion specifications and calibrations. Most Arguments, are sent via a data link and must also include information about how the value is encoded for transmission. This information includes size in bits, byte order, data type, and parity checks. All of the encoding information is in the Encoding area. MetaCommandSet A MetaCommandSet contains an unordered collection of MetaCommands. MetaCommands are descriptions of commands. MetaCommands have a name, a BaseMetaCommand, an ArgumentList, a CommandContainer, a TransmissionContraintList, a DefaultSignificance, a ContextSignificanceList, an Interlock, Verifiers, and a ParameterToSetList. BaseMetaCommand_AnonymousType {sequenceOrder=1} -ArgumentAssignmentList : ArgumentAssignmentList_AnonymousType [0..*]{sequenceOrder=2} -metaCommandRef : NameReferenceType{use} TransmissionConstraintList_AnonymousType {sequenceOrder=6} -TransmissionConstraint : TransmissionConstraint_AnonymousType [*]{sequenceOrder=1} -SystemName [0..1]{sequenceOrder=3} -abstract = false MetaCommandType {mixed=false, complexContentMixed=false} -TransferredVerifier : TransferredVerifier_AnonymousType [0..1]{sequenceOrder=1} -CompleteVerifier : CompleteVerifier_AnonymousType [0..*]{sequenceOrder=6} -ExecutionVerifier : ExecutionVerifier_AnonymousType [0..1]{sequenceOrder=5} -ReceivedVerifier : ReceivedVerifier_AnonymousType [0..1]{sequenceOrder=2} -AcceptedVerifier : AcceptedVerifier_AnonymousType [0..1]{sequenceOrder=3} -QueuedVerifier : QueuedVerifier_AnonymousType [0..1]{sequenceOrder=4} -FailedVerifier : CommandVerifierType [0..1]{sequenceOrder=7} Verifiers_AnonymousType {sequenceOrder=12} ContextSignificanceList_AnonymousType {sequenceOrder=9} -ContextSignificance : ContextSignificance_AnonymousType [*]{sequenceOrder=2} CommandContainerType {mixed=false, complexContentMixed=false} -BaseContainer : BaseContainer_AnonymousType [0..1]{sequenceOrder=3} -EntryList : CommandContainerEntryListType{sequenceOrder=1} ParameterToSetList_AnonymousType {sequenceOrder=14} -ParameterToSet : ParameterToSet_AnonymousType [*]{sequenceOrder=1} Interlock_AnonymousType -verificationToWaitFor : verificationToWaitFor_AnonymousType = complete -scopeToSpaceSystem : NameReferenceType -verificationProgressPercentage -suspendable = false SignificanceType {mixed=false} -consequenceLevel : consequenceLevel_AnonymousType -spaceSystemAtRisk : NameReferenceType -reasonForWarning NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} ArgumentList_AnonymousType {maxOccurs=unbounded} -Argument : Argument_AnonymousType [*] -CommandContainer {sequenceOrder=5} 0..1 -TransmissionConstraintList {sequenceOrder=7} 0..1 -ContextSignificanceList {sequenceOrder=10} 0..1 {sequenceOrder=4} -ArgumentList 0..1 {sequenceOrder=15} -ParameterToSetList 0..1 {sequenceOrder=11} -Interlock 0..1 -BaseMetaCommand {sequenceOrder=2} 0..1 {sequenceOrder=13} -Verifiers 0..1 -DefaultSignificance {sequenceOrder=8} 0..1 {XMLattributes=base=xtce:NameDescriptionType} Figure 7.8 - MetaCommandType BaseMetaCommand The MetaCommand is derived from this Base. Arguments of the base MetaCommand are further specified in this MetaCommand. ArgumentList An ArgumentList is an ordered collection of Arguments. Many commands have one or more options. These are called command arguments. Command arguments may be of any of the standard data types. MetaCommand arguments are local to the MetaCommand. XML Telemetric & Command Exchange (XTCE), v1.0 CommandContainer A Command Container tells how to package this command – very similar to SequenceContainers, but CommandContainers may also have arguments and fixed values in the sequence. Each MetaCommand may have one CommandContainer. TransmissionConstraintList TransmissionConstraintList is an ordered list of TransmissionConstraints. A CommandTransmission constraint is used to check that the command can be run in the current operating mode and may block the transmission of the command if the constraint condition is true. DefaultSignificance and ContextSignificanceList Some Command and Control Systems may require special user access to our confirmations before transmitting commands with certain levels. The Significance includes the name of the SpaceSystem at risk, and a significance level. MetaCommands will also inherit any Significance defined in the Base MetaCommand. Significance levels are: none, watch, warning, distress, critical, and severe. Additionally, it is possible to change or have different significance levels set as driven by the operating context of the SpaceSystem. Interlock An Interlock is a type of Constraint, but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. An Interlock will block successive commands until this command has reached a certain stage (through verifications). Interlocks are scoped to a SpaceSystem basis. Verifiers A Command Verifier is a conditional check on the telemetry from a SpaceSystem that provides positive indication on the successful execution of a command. There are eight different verifiers, each associated with difference stages in command completion: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple completion verifiers. Completed verifiers are added to the Base MetaCommand verifiers. All others will replace a verifier defined in a Base MetaCommand. ParameterToSetList The ParameterToSetList is an ordered collection of ParametersToSet. A ParameterToSet is a Parameter whose value will be set after the Command has reached a certain stage. New Parameters to Set are appended to the Base Command list. ServiceSet is an unordered collection of Services. A service is a logical grouping of containers and/or messages. ServiceType ContainerRefSet_AnonymousType {sequenceOrder=3} -ContainerRef : ContainerRefType [*]{sequenceOrder=1} NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} MessageRefSet_AnonymousType {sequenceOrder=1} -MessageRef [*]{sequenceOrder=1} {sequenceOrder=4} -ContainerRefSet 0..1 {sequenceOrder=2} -MessageRefSet 0..1 {XMLattributes=base=xtce:NameDescriptionType} Figure 7.9 - ServiceType Defaults has default data encoding for ParameterTypes and ArgumentTypes and default parameter time association that will be applied to all Parameters within this SpaceSystem. These defaults may be overidden by sub-SpaceSystems or by the Types or Parameters themselves. Defaults simply provides a means to avoid repeating attributes such as ‘bit order’ for every Type definition. The W3C XML schema is the normative specification. The schema is provided in Annex A. Any XML document compliant with the specification must validate with the schema and any other rules noted in the ‘appinfo’ annotation. Style notes used within the schema are provided in Annex B. Annex A (normative) 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. SpaceSystemType {mixed=false, complexContentMixed=false} CommandMetaDataType {mixed=false} -MetaCommandSet : MetaCommandSet_AnonymousType [0..1]{sequenceOrder=4} -ArgumentTypeSet : ArgumentTypeSet_AnonymousType [0..1]{sequenceOrder=3} -CommandContainerSet : CommandContainerSetType [0..1]{sequenceOrder=5} -ParameterTypeSet : ParameterTypeSetType [0..1]{sequenceOrder=1} -ParameterSet : ParameterSetType [0..1]{sequenceOrder=2} -AlgorithmSet : AlgorithmSetType [0..1]{sequenceOrder=7} -StreamSet : StreamSetType [0..1]{sequenceOrder=6} TelemetryMetaDataType {mixed=false} -ContainerKey2{selector=Container, field=Id} Defaults_AnonymousType {sequenceOrder=6} -ParameterTimeAssociation : TimeAssociationType [0..*]{sequenceOrder=2} -DefaultDataEncoding : DataEncodingType [0..*]{sequenceOrder=1} HeaderType -HistorySet : HistorySet_AnonymousType [0..1]{sequenceOrder=6} -AuthorSet : AuthorSet_AnonymousType [0..1]{sequenceOrder=2} -NoteSet : NoteSet_AnonymousType [0..1]{sequenceOrder=4} -validationStatus : validationStatus_AnonymousType{use} -classification = NotClassified -classificationInstructions -version -date ServiceSet_AnonymousType {sequenceOrder=4} -Service : ServiceType [*]{sequenceOrder=1} SpaceSystem The Root Object {sequenceOrder=1} -Header 0..1 -CommandMetaData {sequenceOrder=3} 0..1 {sequenceOrder=5} -ServiceSet 0..1 -TelemetryMetaData {sequenceOrder=2} 0..1 {sequenceOrder=7} -Defaults 1 {XMLattributes=base=xtce:NameDescriptionType} NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} Figure 7.1 - SpaceSystem A SpaceSystem may contain an optional header record. This record contains some basic context on the data itself (e.g., source, version, revision history, notes, and classification). Because Telemetry and Command databases are frequently developed and maintained independently, the XTCE format divides TelemetryMetaData and CommandMetaData into separate, but similar sections. TelemetryMetaData is really nothing more than a grouping for data about Telemetry. TelemetryMetaData has a ParameterTypeSet, a ParameterSet, a ContainerSet, a MessageSet, a StreamSet, and an AlgorithmSet. Following are descriptions of these collection types. TelemetryMetaDataType {mixed=false} -ContainerKey2{selector=Container, field=Id} ContainerSetType {maxOccurs=unbounded} -SequenceContainer : SequenceContainerType -ParameterSet 0..1 {sequenceOrder=2} {key_unique_keyRef,sequenceOrder=3}0..1-ContainerSet {sequenceOrder=6} -MessageSet 0..1 0..1 -StreamSet{sequenceOrder=5} StreamSetType {maxOccurs=unbounded} -VariableFrameStream : VariableFrameStreamType -FixedFrameStream : FixedFrameStreamType -CustomStream : CustomStreamType MessageSet_AnonymousType {sequenceOrder=4} -Message : Message_AnonymousType [*]{sequenceOrder=1} -name {sequenceOrder=7} 0..1 -AlgorithmSet {sequenceOrder=1} 0..1 -ParameterTypeSet ParameterTypeSetType {maxOccurs=unbounded} -IntegerParameterType : IntegerParameterType_AnonymousType -ArrayParameterType : ArrayParameterType_AnonymousType -FloatParameterType : FloatParameterType_AnonymousType -AbsoluteTimeParameterType : AbsoluteTimeDataType -RelativeTimeParameterType : RelativeTimeDataType -EnumeratedParameterType : EnumeratedDataType -BooleanParameterType : BooleanDataType -BinaryParameterType : BinaryDataType -StringParameterType : StringDataType ParameterSetType {maxOccurs=unbounded} -Parameter : Parameter_AnonymousType -ParameterRef : ParameterRefType AlgorithmSetType {mixed=false, maxOccurs=unbounded} -CustomAlgorithm : InputOutputTriggerAlgorithmType -MathAlgorithm : MathAlgorithmType Figure 7.2 - Telemetry MetaData ParameterTypeSet A ParameterTypeSet is an unordered collection of ParameterTypes. ParameterTypes are the MetaData for Parameters; ParameterTypes are instantiated to create Parameters. ParameterType is the description of something that can have a value (a Parameter). Information contained in ParameterType includes the data type, description, alarm limits, engineering units, and string conversion specifications and calibrations. Most Parameters are telemetered parameters (a.k.a measurands) and must also include information about how the Parameter value is encoded for transmission. This information includes size in bits, byte order, data type, and parity checks. All of the encoding information is in the Encoding area. BaseDataType-UnitSet : UnitSet_AnonymousType{sequenceOrder=2} StringDataType -ContextCalibratorList : ContextCalibratorList_AnonymousType [0..1]{sequenceOrder=4} -SizeRangeInCharacters : IntegerRangeType [0..1]{sequenceOrder=1} -DefaultCalibrator : CalibratorType [1]{sequenceOrder=2} -characterWidth : characterWidth_AnonymousType -restrictionPattern -initialValue NumericDataType -ContextCalibratorList : ContextCalibratorList_AnonymousType [0..1]{sequenceOrder=5} -ValidRange : ValidRange_AnonymousType [0..1]{sequenceOrder=2} -ToString : NumberToStringType [0..1]{sequenceOrder=1} -DefaultCalibrator : CalibratorType [1]{sequenceOrder=3} -validRangeAppliesToCalibrated = true IntegerParameterType_AnonymousType -ContextAlarmList : ContextAlarmList_AnonymousType [0..1]{sequenceOrder=3} -DefaultAlarm : NumericAlarmConditionType [1]{sequenceOrder=1} FloatParameterType_AnonymousType -ContextAlarmList : ContextAlarmList_AnonymousType [0..1]{sequenceOrder=3} -DefaultAlarm : NumericAlarmConditionType [1]{sequenceOrder=1} EnumeratedDataType -EnumerationList : EnumerationList_AnonymousType{sequenceOrder=2} -initialValue ParameterTypeSetType {maxOccurs=unbounded} FloatDataType -sizeInBits : sizeInBits_AnonymousType = 32 -initialValue ArrayParameterType_AnonymousType -arrayTypeRef : NameReferenceType{use} -numberOfDimensions{use} BooleanDataType -zeroStringValue = False -oneStringValue = True -initialValue AbsoluteTimeDataType RelativeTimeDataType BaseTimeDataTypeIntegerDataType -sizeInBits = 32 -signed = true -initialValue BinaryDataType -initialValue -RelativeTimeParameterType -AbsoluteTimeParameterType -IntegerParameterType -ArrayParameterType -BinaryParameterType -BooleanParameterType -EnumeratedParameterType -StringParameterType -FloatParameterType NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} Figure 7.3 - ParameterTypeSet ParameterSet A ParameterSet is an unordered collection of Parameters. Parameters are instantiations of ParameterTypes. Parameters are normally a very simple name and reference to a ParameterType. Parameters may also have alias names and may have properties unique to that instantiation. At any point in time (instance) a Parameter has a value; a Parameter is not the value itself. Parameter names are case sensitive, may be any length, cannot contain spaces ‘.’, ‘/’, ‘[‘ or ‘]’ as these are reserved characters. The aliases have no restrictions. ContainerSet A ContainerSet is an unordered collection of SequenceContainers. SequenceContainers are defined in the packaging section. The packaging section contains the information required to assemble an uplink from its component parts and disassemble a downlink from its component parts. The packaging section has been created to be extremely generic so that it may be used to define TDM telemetry streams, packetized streams, or any other package format. A SequenceContainer contains (in the EntryList) an ordered list of raw parameters, parameter segments, stream segments, containers, or container segments. SequenceContainers may inherit from other sequence containers. The inheritance aspect of SequenceContainers is useful not only for minimizing the effort required to describe a family of SequenceContainers, but is also a very powerful and expressive means of container identification – the process of distinguishing one container from others (e.g., minorFrame 20 is a type of minorFrame where the minor frame counter equals 8). SequenceContainer inheritance may be arbitrarily deep. ContainerType{mixed=false, complexContentMixed=false} -RateInStreamSet : RateInStreamSet_AnonymousType [0..*]{sequenceOrder=3} -BinaryEncoding : BinaryDataEncodingType [0..*]{sequenceOrder=4} -DefaultRateInStream : RateInStreamType [0..*]{sequenceOrder=1} BaseContainer_AnonymousType {sequenceOrder=2} -RestrictionCriteria : RestrictionCriteria_AnonymousType{sequenceOrder=1} -containerRef : NameReferenceType{use} ArrayParameterRefEntryType -DimensionList : DimensionList_AnonymousType{sequenceOrder=2} -parameterRef : NameReferenceType{use} -lastEntryForThisArrayInstance = false IndirectParameterRefEntryType -ParameterInstance : ParameterInstanceRefType{sequenceOrder=1} -aliasNameSpace NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} ParameterRefEntryType -parameterRef : NameReferenceType{use} ParameterSegmentRefEntryType -parameterRef : NameReferenceType{use} -sizeInBits{use} -order ContainerRefEntryType -containerRef : NameReferenceType{use} ContainerSegmentRefEntryType -containerRef : NameReferenceType{use} -sizeInBits{use} -order SequenceContainerType -idlePattern : FixedIntegerValueType = 0x0 -abstract StreamSegmentEntryType -streamRef : NameReferenceType{use} -sizeInBits{use} -order ContainerSetType {maxOccurs=unbounded} EntryListType {mixed=false, minOccurs=0, maxOccurs=unbounded} -ParameterRefEntry -ContainerSegmentRefEntry -SequenceContainer -ContainerRefEntry -ParameterSegmentRefEntry -ArrayParameterRefEntry -IndirectParameterRefEntry -StreamSegmentEntry {sequenceOrder=3} -BaseContainer 0..* {XMLattributes=base=xtce:NameDescriptionType} {XMLattributes=base=xtce:ContainerType} {sequenceOrder=1} -EntryList Figure 7.4 - ContainerSet A SequenceContainer may represent a packet, a frame, a sub-frame, or any other grouping/structure of data items. The simple form of a Sequence element is an ordered set of Parameter References or other Container References. XML Telemetric & Command Exchange (XTCE), v1.0 MessageSet A MessageSet is an unordered collection of Messages. Messages are an alternative method of uniquely identifying containers within a Service. A message provides a test in the form of MatchCriteria to match to a container. A simple example might be: When minorframeID=21, the message is the 21st minorframe container. The collection of messages to search through will be bound by a Service. StreamSet A StreamSet is an unordered collection of Streams. Spacecraft uplinks and spacecraft downlinks are digital streams of data and there are a number of processing functions that are done on the stream level. The stream section contains the knowledge for how to assemble, disassemble, and process spacecraft uplink and downlink streams. CustomStreamType -DecodingAlgorithm : InputOutputAlgorithmType{sequenceOrder=2} -EncodingAlgorithm : InputAlgorithmType{sequenceOrder=1} -decodedStreamRef : NameReferenceType{use} -encodedStreamRef : NameReferenceType{use} VariableFrameStreamType -SyncStrategy : SyncStrategy_AnonymousType{sequenceOrder=1} FixedFrameStreamType -SyncStrategy : SyncStrategy_AnonymousType{sequenceOrder=1} -frameLengthInBits{use} -syncApertureInBits = 0 FrameStreamType -StreamRef : StreamRefType [0..*]{sequenceOrder=2} StreamSetType {maxOccurs=unbounded} NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} PCMStreamType-pcmType : pcmType_AnonymousType = NRZL -inverted = false -bitRateInBPS -CustomStream -FixedFrameStream -VariableFrameStream Figure 7.5 - StreamSet AlgorithmSet An AlgorithmSet is an unordered collection of Algorithms. In spacecraft ground systems, it is necessary to perform some specialized processing to process the telemetry, and preprocess commands. There are a number of predefined algorithms and the algorithm section makes it possible to reference externally defined algorithms for arbitrarily sophisticated data processing. NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} SimpleAlgorithmType -ExternalAlgorithmSet : ExternalAlgorithmSet_AnonymousType [0..*]{sequenceOrder=3} -AlgorithmText : AlgorithmText_AnonymousType [0..*]{sequenceOrder=1} InputOutputAlgorithmType -OutputSet : OutputSet_AnonymousType [0..1]{sequenceOrder=2} -thread{use} InputAlgorithmType -InputSet : InputSet_AnonymousType [0..1]{sequenceOrder=1} MathAlgorithmType -MathOperation : MathOperationType{sequenceOrder=1} AlgorithmSetType {mixed=false, maxOccurs=unbounded} InputOutputTriggerAlgorithmType -TriggerSet : TriggerType [0..1]{sequenceOrder=1} -triggerContainer : NameType{use} -priority{use} -name : NameType{use} -shortDescription{use} -MathAlgorithm -CustomAlgorithm Figure 7.6 - AlgorithmSet The CommandMetaData element is very similar to TelemetryMetaData, but also contains information that is specific only to commanding. CommandMetaData has a ParameterTypeSet, a ParameterSet, a ContainerSet, a MessageSet, a StreamSet, and an AlgorithmSet – exactly like TelemetryMetaData. CommandMetaData, however, also has an ArgumentTypeSet and a MetaCommandSet. ArgumentTypeSet_AnonymousType {maxOccurs=unbounded} -ArgumementArrayType : ArgumementArrayType_AnonymousType -IntegerArgumentType : IntegerArgumentType_AnonymousType -FloatArgumentType : FloatArgumentType_AnonymousType -AbsoluteTimeArgumentType : AbsoluteTimeDataType -RelativeTimeAgumentType : RelativeTimeDataType -EnumeratedArgumentType : EnumeratedDataType -BooleanArgumentType : BooleanDataType -BinaryArgumentType : BinaryDataType -StringArgumentType : StringDataType ParameterTypeSetType {maxOccurs=unbounded} -IntegerParameterType : IntegerParameterType_AnonymousType -ArrayParameterType : ArrayParameterType_AnonymousType -FloatParameterType : FloatParameterType_AnonymousType -AbsoluteTimeParameterType : AbsoluteTimeDataType -RelativeTimeParameterType : RelativeTimeDataType -EnumeratedParameterType : EnumeratedDataType -BooleanParameterType : BooleanDataType -BinaryParameterType : BinaryDataType -StringParameterType : StringDataType CommandMetaDataType {mixed=false} -ParameterSet 0..1 {sequenceOrder=2} -MetaCommandSet 0..1 -ParameterTypeSet 0..1 {sequenceOrder=1} {sequenceOrder=4} MetaCommandSet_AnonymousType {maxOccurs=unbounded} -ArgumentNameKey{selector=xtce:ArgumentList/*, field=@name} -BlockMetaCommand : BlockMetaCommand_AnonymousType -MetaCommand : MetaCommandType{key_unique_keyRef} -MetaCommandRef : NameReferenceType -CommandContainerSet 0..1 {sequenceOrder=5} CommandContainerSetType -CommandContainer : SequenceContainerType [*]{sequenceOrder=1} -StreamSet 0..1 {sequenceOrder=6} {sequenceOrder=3} 0..1 -ArgumentTypeSet StreamSetType {maxOccurs=unbounded} -VariableFrameStream : VariableFrameStreamType -FixedFrameStream : FixedFrameStreamType -CustomStream : CustomStreamType -AlgorithmSet 0..1 {sequenceOrder=7} AlgorithmSetType {mixed=false, maxOccurs=unbounded} -CustomAlgorithm : InputOutputTriggerAlgorithmType -MathAlgorithm : MathAlgorithmType ParameterSetType {maxOccurs=unbounded} -Parameter : Parameter_AnonymousType -ParameterRef : ParameterRefType Figure 7.7 - CommandMetaData ArgumentTypeSet An ArgumentTypeSet is an unordered collection of ArgumentTypes. ArgumentTypes (very similar to ParameterTypes) are the MetaData for Command Arguments; ArgumentTypes are instantiated to create Arguments. ArgumentType contains the description of something that can have a value and is used as an operator supplied option to a Command (Command Argument). Information contained in ArgumentType includes the data type, description, valid range, engineering units, and string conversion specifications and calibrations. Most Arguments, are sent via a data link and must also include information about how the value is encoded for transmission. This information includes size in bits, byte order, data type, and parity checks. All of the encoding information is in the Encoding area. MetaCommandSet A MetaCommandSet contains an unordered collection of MetaCommands. MetaCommands are descriptions of commands. MetaCommands have a name, a BaseMetaCommand, an ArgumentList, a CommandContainer, a TransmissionContraintList, a DefaultSignificance, a ContextSignificanceList, an Interlock, Verifiers, and a ParameterToSetList. BaseMetaCommand_AnonymousType {sequenceOrder=1} -ArgumentAssignmentList : ArgumentAssignmentList_AnonymousType [0..*]{sequenceOrder=2} -metaCommandRef : NameReferenceType{use} TransmissionConstraintList_AnonymousType {sequenceOrder=6} -TransmissionConstraint : TransmissionConstraint_AnonymousType [*]{sequenceOrder=1} -SystemName [0..1]{sequenceOrder=3} -abstract = false MetaCommandType {mixed=false, complexContentMixed=false} -TransferredVerifier : TransferredVerifier_AnonymousType [0..1]{sequenceOrder=1} -CompleteVerifier : CompleteVerifier_AnonymousType [0..*]{sequenceOrder=6} -ExecutionVerifier : ExecutionVerifier_AnonymousType [0..1]{sequenceOrder=5} -ReceivedVerifier : ReceivedVerifier_AnonymousType [0..1]{sequenceOrder=2} -AcceptedVerifier : AcceptedVerifier_AnonymousType [0..1]{sequenceOrder=3} -QueuedVerifier : QueuedVerifier_AnonymousType [0..1]{sequenceOrder=4} -FailedVerifier : CommandVerifierType [0..1]{sequenceOrder=7} Verifiers_AnonymousType {sequenceOrder=12} ContextSignificanceList_AnonymousType {sequenceOrder=9} -ContextSignificance : ContextSignificance_AnonymousType [*]{sequenceOrder=2} CommandContainerType {mixed=false, complexContentMixed=false} -BaseContainer : BaseContainer_AnonymousType [0..1]{sequenceOrder=3} -EntryList : CommandContainerEntryListType{sequenceOrder=1} ParameterToSetList_AnonymousType {sequenceOrder=14} -ParameterToSet : ParameterToSet_AnonymousType [*]{sequenceOrder=1} Interlock_AnonymousType -verificationToWaitFor : verificationToWaitFor_AnonymousType = complete -scopeToSpaceSystem : NameReferenceType -verificationProgressPercentage -suspendable = false SignificanceType {mixed=false} -consequenceLevel : consequenceLevel_AnonymousType -spaceSystemAtRisk : NameReferenceType -reasonForWarning NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} ArgumentList_AnonymousType {maxOccurs=unbounded} -Argument : Argument_AnonymousType [*] -CommandContainer {sequenceOrder=5} 0..1 -TransmissionConstraintList {sequenceOrder=7} 0..1 -ContextSignificanceList {sequenceOrder=10} 0..1 {sequenceOrder=4} -ArgumentList 0..1 {sequenceOrder=15} -ParameterToSetList 0..1 {sequenceOrder=11} -Interlock 0..1 -BaseMetaCommand {sequenceOrder=2} 0..1 {sequenceOrder=13} -Verifiers 0..1 -DefaultSignificance {sequenceOrder=8} 0..1 {XMLattributes=base=xtce:NameDescriptionType} Figure 7.8 - MetaCommandType BaseMetaCommand The MetaCommand is derived from this Base. Arguments of the base MetaCommand are further specified in this MetaCommand. ArgumentList An ArgumentList is an ordered collection of Arguments. Many commands have one or more options. These are called command arguments. Command arguments may be of any of the standard data types. MetaCommand arguments are local to the MetaCommand. XML Telemetric & Command Exchange (XTCE), v1.0 CommandContainer A Command Container tells how to package this command – very similar to SequenceContainers, but CommandContainers may also have arguments and fixed values in the sequence. Each MetaCommand may have one CommandContainer. TransmissionConstraintList TransmissionConstraintList is an ordered list of TransmissionConstraints. A CommandTransmission constraint is used to check that the command can be run in the current operating mode and may block the transmission of the command if the constraint condition is true. DefaultSignificance and ContextSignificanceList Some Command and Control Systems may require special user access to our confirmations before transmitting commands with certain levels. The Significance includes the name of the SpaceSystem at risk, and a significance level. MetaCommands will also inherit any Significance defined in the Base MetaCommand. Significance levels are: none, watch, warning, distress, critical, and severe. Additionally, it is possible to change or have different significance levels set as driven by the operating context of the SpaceSystem. Interlock An Interlock is a type of Constraint, but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. An Interlock will block successive commands until this command has reached a certain stage (through verifications). Interlocks are scoped to a SpaceSystem basis. Verifiers A Command Verifier is a conditional check on the telemetry from a SpaceSystem that provides positive indication on the successful execution of a command. There are eight different verifiers, each associated with difference stages in command completion: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple completion verifiers. Completed verifiers are added to the Base MetaCommand verifiers. All others will replace a verifier defined in a Base MetaCommand. ParameterToSetList The ParameterToSetList is an ordered collection of ParametersToSet. A ParameterToSet is a Parameter whose value will be set after the Command has reached a certain stage. New Parameters to Set are appended to the Base Command list. ServiceSet is an unordered collection of Services. A service is a logical grouping of containers and/or messages. ServiceType ContainerRefSet_AnonymousType {sequenceOrder=3} -ContainerRef : ContainerRefType [*]{sequenceOrder=1} NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} MessageRefSet_AnonymousType {sequenceOrder=1} -MessageRef [*]{sequenceOrder=1} {sequenceOrder=4} -ContainerRefSet 0..1 {sequenceOrder=2} -MessageRefSet 0..1 {XMLattributes=base=xtce:NameDescriptionType} Figure 7.9 - ServiceType Defaults has default data encoding for ParameterTypes and ArgumentTypes and default parameter time association that will be applied to all Parameters within this SpaceSystem. These defaults may be overidden by sub-SpaceSystems or by the Types or Parameters themselves. Defaults simply provides a means to avoid repeating attributes such as ‘bit order’ for every Type definition. A SpaceSystem may contain an optional header record. This record contains some basic context on the data itself (e.g., source, version, revision history, notes, and classification). Because Telemetry and Command databases are frequently developed and maintained independently, the XTCE format divides TelemetryMetaData and CommandMetaData into separate, but similar sections. TelemetryMetaData is really nothing more than a grouping for data about Telemetry. TelemetryMetaData has a ParameterTypeSet, a ParameterSet, a ContainerSet, a MessageSet, a StreamSet, and an AlgorithmSet. Following are descriptions of these collection types. TelemetryMetaDataType {mixed=false} -ContainerKey2{selector=Container, field=Id} ContainerSetType {maxOccurs=unbounded} -SequenceContainer : SequenceContainerType -ParameterSet 0..1 {sequenceOrder=2} {key_unique_keyRef,sequenceOrder=3}0..1-ContainerSet {sequenceOrder=6} -MessageSet 0..1 0..1 -StreamSet{sequenceOrder=5} StreamSetType {maxOccurs=unbounded} -VariableFrameStream : VariableFrameStreamType -FixedFrameStream : FixedFrameStreamType -CustomStream : CustomStreamType MessageSet_AnonymousType {sequenceOrder=4} -Message : Message_AnonymousType [*]{sequenceOrder=1} -name {sequenceOrder=7} 0..1 -AlgorithmSet {sequenceOrder=1} 0..1 -ParameterTypeSet ParameterTypeSetType {maxOccurs=unbounded} -IntegerParameterType : IntegerParameterType_AnonymousType -ArrayParameterType : ArrayParameterType_AnonymousType -FloatParameterType : FloatParameterType_AnonymousType -AbsoluteTimeParameterType : AbsoluteTimeDataType -RelativeTimeParameterType : RelativeTimeDataType -EnumeratedParameterType : EnumeratedDataType -BooleanParameterType : BooleanDataType -BinaryParameterType : BinaryDataType -StringParameterType : StringDataType ParameterSetType {maxOccurs=unbounded} -Parameter : Parameter_AnonymousType -ParameterRef : ParameterRefType AlgorithmSetType {mixed=false, maxOccurs=unbounded} -CustomAlgorithm : InputOutputTriggerAlgorithmType -MathAlgorithm : MathAlgorithmType Figure 7.2 - Telemetry MetaData ParameterTypeSet A ParameterTypeSet is an unordered collection of ParameterTypes. ParameterTypes are the MetaData for Parameters; ParameterTypes are instantiated to create Parameters. ParameterType is the description of something that can have a value (a Parameter). Information contained in ParameterType includes the data type, description, alarm limits, engineering units, and string conversion specifications and calibrations. Most Parameters are telemetered parameters (a.k.a measurands) and must also include information about how the Parameter value is encoded for transmission. This information includes size in bits, byte order, data type, and parity checks. All of the encoding information is in the Encoding area. BaseDataType-UnitSet : UnitSet_AnonymousType{sequenceOrder=2} StringDataType -ContextCalibratorList : ContextCalibratorList_AnonymousType [0..1]{sequenceOrder=4} -SizeRangeInCharacters : IntegerRangeType [0..1]{sequenceOrder=1} -DefaultCalibrator : CalibratorType [1]{sequenceOrder=2} -characterWidth : characterWidth_AnonymousType -restrictionPattern -initialValue NumericDataType -ContextCalibratorList : ContextCalibratorList_AnonymousType [0..1]{sequenceOrder=5} -ValidRange : ValidRange_AnonymousType [0..1]{sequenceOrder=2} -ToString : NumberToStringType [0..1]{sequenceOrder=1} -DefaultCalibrator : CalibratorType [1]{sequenceOrder=3} -validRangeAppliesToCalibrated = true IntegerParameterType_AnonymousType -ContextAlarmList : ContextAlarmList_AnonymousType [0..1]{sequenceOrder=3} -DefaultAlarm : NumericAlarmConditionType [1]{sequenceOrder=1} FloatParameterType_AnonymousType -ContextAlarmList : ContextAlarmList_AnonymousType [0..1]{sequenceOrder=3} -DefaultAlarm : NumericAlarmConditionType [1]{sequenceOrder=1} EnumeratedDataType -EnumerationList : EnumerationList_AnonymousType{sequenceOrder=2} -initialValue ParameterTypeSetType {maxOccurs=unbounded} FloatDataType -sizeInBits : sizeInBits_AnonymousType = 32 -initialValue ArrayParameterType_AnonymousType -arrayTypeRef : NameReferenceType{use} -numberOfDimensions{use} BooleanDataType -zeroStringValue = False -oneStringValue = True -initialValue AbsoluteTimeDataType RelativeTimeDataType BaseTimeDataTypeIntegerDataType -sizeInBits = 32 -signed = true -initialValue BinaryDataType -initialValue -RelativeTimeParameterType -AbsoluteTimeParameterType -IntegerParameterType -ArrayParameterType -BinaryParameterType -BooleanParameterType -EnumeratedParameterType -StringParameterType -FloatParameterType NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} Figure 7.3 - ParameterTypeSet ParameterSet A ParameterSet is an unordered collection of Parameters. Parameters are instantiations of ParameterTypes. Parameters are normally a very simple name and reference to a ParameterType. Parameters may also have alias names and may have properties unique to that instantiation. At any point in time (instance) a Parameter has a value; a Parameter is not the value itself. Parameter names are case sensitive, may be any length, cannot contain spaces ‘.’, ‘/’, ‘[‘ or ‘]’ as these are reserved characters. The aliases have no restrictions. ContainerSet A ContainerSet is an unordered collection of SequenceContainers. SequenceContainers are defined in the packaging section. The packaging section contains the information required to assemble an uplink from its component parts and disassemble a downlink from its component parts. The packaging section has been created to be extremely generic so that it may be used to define TDM telemetry streams, packetized streams, or any other package format. A SequenceContainer contains (in the EntryList) an ordered list of raw parameters, parameter segments, stream segments, containers, or container segments. SequenceContainers may inherit from other sequence containers. The inheritance aspect of SequenceContainers is useful not only for minimizing the effort required to describe a family of SequenceContainers, but is also a very powerful and expressive means of container identification – the process of distinguishing one container from others (e.g., minorFrame 20 is a type of minorFrame where the minor frame counter equals 8). SequenceContainer inheritance may be arbitrarily deep. ContainerType{mixed=false, complexContentMixed=false} -RateInStreamSet : RateInStreamSet_AnonymousType [0..*]{sequenceOrder=3} -BinaryEncoding : BinaryDataEncodingType [0..*]{sequenceOrder=4} -DefaultRateInStream : RateInStreamType [0..*]{sequenceOrder=1} BaseContainer_AnonymousType {sequenceOrder=2} -RestrictionCriteria : RestrictionCriteria_AnonymousType{sequenceOrder=1} -containerRef : NameReferenceType{use} ArrayParameterRefEntryType -DimensionList : DimensionList_AnonymousType{sequenceOrder=2} -parameterRef : NameReferenceType{use} -lastEntryForThisArrayInstance = false IndirectParameterRefEntryType -ParameterInstance : ParameterInstanceRefType{sequenceOrder=1} -aliasNameSpace NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} ParameterRefEntryType -parameterRef : NameReferenceType{use} ParameterSegmentRefEntryType -parameterRef : NameReferenceType{use} -sizeInBits{use} -order ContainerRefEntryType -containerRef : NameReferenceType{use} ContainerSegmentRefEntryType -containerRef : NameReferenceType{use} -sizeInBits{use} -order SequenceContainerType -idlePattern : FixedIntegerValueType = 0x0 -abstract StreamSegmentEntryType -streamRef : NameReferenceType{use} -sizeInBits{use} -order ContainerSetType {maxOccurs=unbounded} EntryListType {mixed=false, minOccurs=0, maxOccurs=unbounded} -ParameterRefEntry -ContainerSegmentRefEntry -SequenceContainer -ContainerRefEntry -ParameterSegmentRefEntry -ArrayParameterRefEntry -IndirectParameterRefEntry -StreamSegmentEntry {sequenceOrder=3} -BaseContainer 0..* {XMLattributes=base=xtce:NameDescriptionType} {XMLattributes=base=xtce:ContainerType} {sequenceOrder=1} -EntryList Figure 7.4 - ContainerSet A SequenceContainer may represent a packet, a frame, a sub-frame, or any other grouping/structure of data items. The simple form of a Sequence element is an ordered set of Parameter References or other Container References. XML Telemetric & Command Exchange (XTCE), v1.0 MessageSet A MessageSet is an unordered collection of Messages. Messages are an alternative method of uniquely identifying containers within a Service. A message provides a test in the form of MatchCriteria to match to a container. A simple example might be: When minorframeID=21, the message is the 21st minorframe container. The collection of messages to search through will be bound by a Service. StreamSet A StreamSet is an unordered collection of Streams. Spacecraft uplinks and spacecraft downlinks are digital streams of data and there are a number of processing functions that are done on the stream level. The stream section contains the knowledge for how to assemble, disassemble, and process spacecraft uplink and downlink streams. CustomStreamType -DecodingAlgorithm : InputOutputAlgorithmType{sequenceOrder=2} -EncodingAlgorithm : InputAlgorithmType{sequenceOrder=1} -decodedStreamRef : NameReferenceType{use} -encodedStreamRef : NameReferenceType{use} VariableFrameStreamType -SyncStrategy : SyncStrategy_AnonymousType{sequenceOrder=1} FixedFrameStreamType -SyncStrategy : SyncStrategy_AnonymousType{sequenceOrder=1} -frameLengthInBits{use} -syncApertureInBits = 0 FrameStreamType -StreamRef : StreamRefType [0..*]{sequenceOrder=2} StreamSetType {maxOccurs=unbounded} NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} PCMStreamType-pcmType : pcmType_AnonymousType = NRZL -inverted = false -bitRateInBPS -CustomStream -FixedFrameStream -VariableFrameStream Figure 7.5 - StreamSet AlgorithmSet An AlgorithmSet is an unordered collection of Algorithms. In spacecraft ground systems, it is necessary to perform some specialized processing to process the telemetry, and preprocess commands. There are a number of predefined algorithms and the algorithm section makes it possible to reference externally defined algorithms for arbitrarily sophisticated data processing. NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} SimpleAlgorithmType -ExternalAlgorithmSet : ExternalAlgorithmSet_AnonymousType [0..*]{sequenceOrder=3} -AlgorithmText : AlgorithmText_AnonymousType [0..*]{sequenceOrder=1} InputOutputAlgorithmType -OutputSet : OutputSet_AnonymousType [0..1]{sequenceOrder=2} -thread{use} InputAlgorithmType -InputSet : InputSet_AnonymousType [0..1]{sequenceOrder=1} MathAlgorithmType -MathOperation : MathOperationType{sequenceOrder=1} AlgorithmSetType {mixed=false, maxOccurs=unbounded} InputOutputTriggerAlgorithmType -TriggerSet : TriggerType [0..1]{sequenceOrder=1} -triggerContainer : NameType{use} -priority{use} -name : NameType{use} -shortDescription{use} -MathAlgorithm -CustomAlgorithm Figure 7.6 - AlgorithmSet The CommandMetaData element is very similar to TelemetryMetaData, but also contains information that is specific only to commanding. CommandMetaData has a ParameterTypeSet, a ParameterSet, a ContainerSet, a MessageSet, a StreamSet, and an AlgorithmSet – exactly like TelemetryMetaData. CommandMetaData, however, also has an ArgumentTypeSet and a MetaCommandSet. ArgumentTypeSet_AnonymousType {maxOccurs=unbounded} -ArgumementArrayType : ArgumementArrayType_AnonymousType -IntegerArgumentType : IntegerArgumentType_AnonymousType -FloatArgumentType : FloatArgumentType_AnonymousType -AbsoluteTimeArgumentType : AbsoluteTimeDataType -RelativeTimeAgumentType : RelativeTimeDataType -EnumeratedArgumentType : EnumeratedDataType -BooleanArgumentType : BooleanDataType -BinaryArgumentType : BinaryDataType -StringArgumentType : StringDataType ParameterTypeSetType {maxOccurs=unbounded} -IntegerParameterType : IntegerParameterType_AnonymousType -ArrayParameterType : ArrayParameterType_AnonymousType -FloatParameterType : FloatParameterType_AnonymousType -AbsoluteTimeParameterType : AbsoluteTimeDataType -RelativeTimeParameterType : RelativeTimeDataType -EnumeratedParameterType : EnumeratedDataType -BooleanParameterType : BooleanDataType -BinaryParameterType : BinaryDataType -StringParameterType : StringDataType CommandMetaDataType {mixed=false} -ParameterSet 0..1 {sequenceOrder=2} -MetaCommandSet 0..1 -ParameterTypeSet 0..1 {sequenceOrder=1} {sequenceOrder=4} MetaCommandSet_AnonymousType {maxOccurs=unbounded} -ArgumentNameKey{selector=xtce:ArgumentList/*, field=@name} -BlockMetaCommand : BlockMetaCommand_AnonymousType -MetaCommand : MetaCommandType{key_unique_keyRef} -MetaCommandRef : NameReferenceType -CommandContainerSet 0..1 {sequenceOrder=5} CommandContainerSetType -CommandContainer : SequenceContainerType [*]{sequenceOrder=1} -StreamSet 0..1 {sequenceOrder=6} {sequenceOrder=3} 0..1 -ArgumentTypeSet StreamSetType {maxOccurs=unbounded} -VariableFrameStream : VariableFrameStreamType -FixedFrameStream : FixedFrameStreamType -CustomStream : CustomStreamType -AlgorithmSet 0..1 {sequenceOrder=7} AlgorithmSetType {mixed=false, maxOccurs=unbounded} -CustomAlgorithm : InputOutputTriggerAlgorithmType -MathAlgorithm : MathAlgorithmType ParameterSetType {maxOccurs=unbounded} -Parameter : Parameter_AnonymousType -ParameterRef : ParameterRefType Figure 7.7 - CommandMetaData ArgumentTypeSet An ArgumentTypeSet is an unordered collection of ArgumentTypes. ArgumentTypes (very similar to ParameterTypes) are the MetaData for Command Arguments; ArgumentTypes are instantiated to create Arguments. ArgumentType contains the description of something that can have a value and is used as an operator supplied option to a Command (Command Argument). Information contained in ArgumentType includes the data type, description, valid range, engineering units, and string conversion specifications and calibrations. Most Arguments, are sent via a data link and must also include information about how the value is encoded for transmission. This information includes size in bits, byte order, data type, and parity checks. All of the encoding information is in the Encoding area. MetaCommandSet A MetaCommandSet contains an unordered collection of MetaCommands. MetaCommands are descriptions of commands. MetaCommands have a name, a BaseMetaCommand, an ArgumentList, a CommandContainer, a TransmissionContraintList, a DefaultSignificance, a ContextSignificanceList, an Interlock, Verifiers, and a ParameterToSetList. BaseMetaCommand_AnonymousType {sequenceOrder=1} -ArgumentAssignmentList : ArgumentAssignmentList_AnonymousType [0..*]{sequenceOrder=2} -metaCommandRef : NameReferenceType{use} TransmissionConstraintList_AnonymousType {sequenceOrder=6} -TransmissionConstraint : TransmissionConstraint_AnonymousType [*]{sequenceOrder=1} -SystemName [0..1]{sequenceOrder=3} -abstract = false MetaCommandType {mixed=false, complexContentMixed=false} -TransferredVerifier : TransferredVerifier_AnonymousType [0..1]{sequenceOrder=1} -CompleteVerifier : CompleteVerifier_AnonymousType [0..*]{sequenceOrder=6} -ExecutionVerifier : ExecutionVerifier_AnonymousType [0..1]{sequenceOrder=5} -ReceivedVerifier : ReceivedVerifier_AnonymousType [0..1]{sequenceOrder=2} -AcceptedVerifier : AcceptedVerifier_AnonymousType [0..1]{sequenceOrder=3} -QueuedVerifier : QueuedVerifier_AnonymousType [0..1]{sequenceOrder=4} -FailedVerifier : CommandVerifierType [0..1]{sequenceOrder=7} Verifiers_AnonymousType {sequenceOrder=12} ContextSignificanceList_AnonymousType {sequenceOrder=9} -ContextSignificance : ContextSignificance_AnonymousType [*]{sequenceOrder=2} CommandContainerType {mixed=false, complexContentMixed=false} -BaseContainer : BaseContainer_AnonymousType [0..1]{sequenceOrder=3} -EntryList : CommandContainerEntryListType{sequenceOrder=1} ParameterToSetList_AnonymousType {sequenceOrder=14} -ParameterToSet : ParameterToSet_AnonymousType [*]{sequenceOrder=1} Interlock_AnonymousType -verificationToWaitFor : verificationToWaitFor_AnonymousType = complete -scopeToSpaceSystem : NameReferenceType -verificationProgressPercentage -suspendable = false SignificanceType {mixed=false} -consequenceLevel : consequenceLevel_AnonymousType -spaceSystemAtRisk : NameReferenceType -reasonForWarning NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} ArgumentList_AnonymousType {maxOccurs=unbounded} -Argument : Argument_AnonymousType [*] -CommandContainer {sequenceOrder=5} 0..1 -TransmissionConstraintList {sequenceOrder=7} 0..1 -ContextSignificanceList {sequenceOrder=10} 0..1 {sequenceOrder=4} -ArgumentList 0..1 {sequenceOrder=15} -ParameterToSetList 0..1 {sequenceOrder=11} -Interlock 0..1 -BaseMetaCommand {sequenceOrder=2} 0..1 {sequenceOrder=13} -Verifiers 0..1 -DefaultSignificance {sequenceOrder=8} 0..1 {XMLattributes=base=xtce:NameDescriptionType} Figure 7.8 - MetaCommandType BaseMetaCommand The MetaCommand is derived from this Base. Arguments of the base MetaCommand are further specified in this MetaCommand. ArgumentList An ArgumentList is an ordered collection of Arguments. Many commands have one or more options. These are called command arguments. Command arguments may be of any of the standard data types. MetaCommand arguments are local to the MetaCommand. XML Telemetric & Command Exchange (XTCE), v1.0 CommandContainer A Command Container tells how to package this command – very similar to SequenceContainers, but CommandContainers may also have arguments and fixed values in the sequence. Each MetaCommand may have one CommandContainer. TransmissionConstraintList TransmissionConstraintList is an ordered list of TransmissionConstraints. A CommandTransmission constraint is used to check that the command can be run in the current operating mode and may block the transmission of the command if the constraint condition is true. DefaultSignificance and ContextSignificanceList Some Command and Control Systems may require special user access to our confirmations before transmitting commands with certain levels. The Significance includes the name of the SpaceSystem at risk, and a significance level. MetaCommands will also inherit any Significance defined in the Base MetaCommand. Significance levels are: none, watch, warning, distress, critical, and severe. Additionally, it is possible to change or have different significance levels set as driven by the operating context of the SpaceSystem. Interlock An Interlock is a type of Constraint, but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. An Interlock will block successive commands until this command has reached a certain stage (through verifications). Interlocks are scoped to a SpaceSystem basis. Verifiers A Command Verifier is a conditional check on the telemetry from a SpaceSystem that provides positive indication on the successful execution of a command. There are eight different verifiers, each associated with difference stages in command completion: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple completion verifiers. Completed verifiers are added to the Base MetaCommand verifiers. All others will replace a verifier defined in a Base MetaCommand. ParameterToSetList The ParameterToSetList is an ordered collection of ParametersToSet. A ParameterToSet is a Parameter whose value will be set after the Command has reached a certain stage. New Parameters to Set are appended to the Base Command list. ServiceSet is an unordered collection of Services. A service is a logical grouping of containers and/or messages. ServiceType ContainerRefSet_AnonymousType {sequenceOrder=3} -ContainerRef : ContainerRefType [*]{sequenceOrder=1} NameDescriptionType -AliasSet : AliasSetType [0..1]{sequenceOrder=2} -LongDescription [0..1]{sequenceOrder=1} -name : NameType{use} -shortDescription{use} MessageRefSet_AnonymousType {sequenceOrder=1} -MessageRef [*]{sequenceOrder=1} {sequenceOrder=4} -ContainerRefSet 0..1 {sequenceOrder=2} -MessageRefSet 0..1 {XMLattributes=base=xtce:NameDescriptionType} Figure 7.9 - ServiceType Defaults has default data encoding for ParameterTypes and ArgumentTypes and default parameter time association that will be applied to all Parameters within this SpaceSystem. These defaults may be overidden by sub-SpaceSystems or by the Types or Parameters themselves. Defaults simply provides a means to avoid repeating attributes such as ‘bit order’ for every Type definition. The W3C XML schema is the normative specification. The schema is provided in Annex A. Any XML document compliant with the specification must validate with the schema and any other rules noted in the ‘appinfo’ annotation. Style notes used within the schema are provided in Annex B. Annex A (normative) The XTCE normative specification is contained entirely as a W3C XML Schema. This schema is available as a standalone document at http://www.omg.org/space/xtce/SpaceSystem1.0.xsd OMG Document Number: dtc/2005-01-05 $Id: SpaceSystemV1.0.xsd,v 1.15 2005/01/24 05:02:50 gerry Exp $ This is the master schema for the OMG Space Domain Task Force XML Telemetric and Command data Exchange (XTCE) format. The ROOT Element ensure unique parameter name at the system level ensure unique metaCommand name at the system level ensure unique algorithm name at the system level ensure unique service name at the system level SpaceSystem is a collection of SpaceSystem(s) including space assets, ground assets, multi-satellite systems and sub-systems. A SpaceSystem is the root element for the set of data necessary to monitor and command an arbitrary space device - this includes the binary decomposition the data streams going into and out of a device. A service is a logical grouping of container and/or messages. Defaults has default data encoding for ParameterTypes and ArgumentTypes and default parameter time association that will be applied to all Parameters within this SpaceSystem. These defaults may be overidden by sub-SpaceSystems or by the Types or Parameters themselves. Defaults simply provides a means to avoid repeating attributes such as ‘bit order’ for every Type definition. Since the data encoding (bit order and byte order) is normally the same throughout a spacesystem, using this element allows that data encoding to be specified as a default. Default time to associate each ParameterInstance with. Command Meta Data contains information about commands A list of parameter types Parameters referenced by MetaCommands. This Parameter Set is located here so that MetaCommand data can be built independantly of TelemetryMetaData. A set of Command Definitions All commands to be sent on this mission are listed here. In addition this area has verification and validation information Used to include a MetaCommand defined in another sub-system in this sub-system. BlockMetaCommands are simply a list of individual MetaCommands that can be packaged up in a single BlockMetaCommand. The Command Container defines the construction of a Command. All the data about telemetry is contained in TelemetryMetaData A list of parameter types A list of Parameters for this Space System. Holds the list of all potential container definitions for telemetry. Containers may parts of packets or TDM, and then groups of the containers, and then an entire entity --such as a packet. In order to maximize re-used for duplication, the pieces may defined once here, and then assembled as needed into larger structures, also here. Messages are an alternative method of uniquely identifying containers within a Service. A message provides a test in the form of MatchCriteria to match to a container. A simple example might be: [When minorframeID=21, the message is the 21st minorframe container. The collection of messages to search thru will be bound by a Service. The ContainerRef should point to ROOT container that will describe an entire packet/minor frame or chunk of telemetry. A reference to a Service An unordered collection of algorithms This schema definies the dictionary for containers, which in turn describe the physical composition of data in a communication system An abstract block of data; used as the base type for more specific container types RateInStream is used to: a) generate alarms when the Container is updated too frequently or too infrequently, b) provide some 'guidelines' for generating forward link containers, c) provide some guidelines for spacecraft simulators to generate telemetry containers. If necessary, these rates may be defined on a per stream basis. The software should check that any Stream names referenced in the RateInStreamSet actually exist. May be used to indicate error detection and correction, chage byte order, provide the size (when it can't be derived), or perform some custom processing. A list of raw parameters, parameter segments, stream segments, containers, or container segments. Sequence containers may inherit from other sequence containers; when they do, the sequence in the parent SequenceContainer is 'inherited' and if the location of entries in the child sequence is not specified, it is assumed to start where the parent sequence ended. Parent sequence containers may be marked as "abstract". The idle pattern is part of any unallocated space in the Container. Given that this Container is the Base container type, RestrictionCriteria lists conditions that must be true for this Container to be 'this' subContainer type. May be a simple Comparison List, a Boolean Expression, and/or in a Graph of containers established by the NextContainer An abstract type used by sequence containers. An entry contains a location in the container. The location may be either fixed or dynamic, absolute (to the start or end of the enclosing container, or relative (to either the previous or subsequent entry). Entries may also repeat. If no LocationInContainer value is given, the entry is assumed to begin immediately after the previous entry. The location may be relative to the start of the container (containerStart), relatitive to the end of the previous entry (previousEntry), relative to the end of the container (containerEnd), or relative to the entry that follows this one (nextEntry). If going forward (containerStart and previousEntry) then, then the location refers to the start of the Entry. If going backwards (containerEnd and nextEntry) then, the location refers to the end of the entry. May be used when this entry repeats itself in the sequence container. If not supplied, the entry does not repeat. This entry will only be included in the sequence when this condition is true. If no IncludeCondition is given, then it is will be included. A parameter that is not included will be treated as if it did not exist in the sequence at all. Holds a reference to a container name of container Holds a reference to a message name of container Holds a set of services, logical groups of containers OR messages (not both). Unordered Set of Containers SequenceContainers define sequences of parameters or other containers. Contains an ordered list of Entries. Used in Sequence Container An entry that is a single Parameter An entry that is only a portion of a parameter value indicating that the entire parameter value must be assembled from other parameter segments. It is assumed that parameter segments happen sequentially in time, that is the first part if a telemetry parameter first, however (and there's always a however), if this is not the case the order of this parameter segment may be supplied with the order attribute where the first segment order="0". An entry that is simply a reference to another container. An entry that is only a portion of a parameter value indicating that the entire parameter value must be assembled from other parameter segments. It is assumed that parameter segments happen sequentially in time, that is the first part if a telemetry parameter first, however (and there's always a however), if this is not the case the order of this parameter segment may be supplied with the order attribute where the first segment order="0". An entry that is a portion of a stream (streams are by definition, assumed continuous) It is assumed that stream segments happen sequentially in time, that is the first part if a steam first, however, if this is not the case the order of the stream segments may be supplied with the order attribute where the first segment order="0". An entry whose name is given by the value of a ParamameterInstance. This entry may be used to implement dwell telemetry streams. The value of the parameter in ParameterInstance must use either the name of the Parameter or its alias. If it's an alias name, the alias namespace is supplied as an attribute. An entry that is an array parameter. This entry is somewhat special because the entry may represent only a part of the Array and it's important to decribe which diminsions of the array come first in the sequence as well as the size of the array. Where the Dimension list is in this form: Array[1stDim][2ndDim][lastDim]. The last dimension is assumed to be the least significant - that is this dimension will cycle through it's combination before the next to last dimension changes. The order MUST ascend or the array will need to be broken out entry by entry. For partial entries of an array, the starting and ending index for each dimension, OR the Size must be specified. Indexes are zero based. For an ArrayParameterType of size N, their should be N Dimensions An array made up by multiple Entries should not have index's that overlap, but should be continuous. zero based index Used in packaging to define the expected rate that any individual container will be in a Stream A wrapper for those properties that are unique to telemetry parameters. Optional. Normally used when the database is built in a flat, non-hierarchical format Optional condition that must be true for this Parameter to be valid One or more physical addresses may be associated with each Parameter. Examples of phyical addresses include a location on the spacecraft or a location on a data collection bus. Contains the address (e.g., channel information) required to process the spacecraft telemetry streams. May be an onboard id, a mux address, or a physical location. Contains the address (channel information) required to process the spacecraft telemetry streams This time will overide any Default value for TimeAssociation. A telemetered Parameter is one that will have values in telemetry. A derived Parameter is one that is calculated, usually be an Algorithm. A constant Parameter is one that is used as a constant in the system (e.g. a vehicle id). A local Parameter is one that is used purely on the ground (e.g. a ground command counter). A Parameter marked as 'readOnly' true is constant and non-settable Telemetry parameter instances are oftentimes "time-tagged" with a timing signal either provided on the ground or on the space system. This data element allows one to specify which of possibly many AbsoluteTimeParameters to use to "time-tag" parameter instances with. The parameter ref must be to an AbsoluteTime Parameter If true, then the current value of the AbsoluteTime will be projected to current time. I.E., if the value of the AbsoluteTime parameter was set 10 seconds ago, then 10 seconds will be added to it's value before associating this time with the parameter. The offset is used to supply a relative time offset from the time association and to this parameter A reference to an instance of a Parameter. Used when the value of a parameter is required for a calculation or as an index value. A positive value for instance is forward in time, a negative value for count is backward in time, a 0 value for count means use the current value of the parameter or the first value in a container. A reference to a Parameter. Uses Unix ‘like’ naming across the SpaceSystem Tree (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage). To reference an individual member of an array use the zero based bracket notation commonly used in languages like C, C++, and Java. When it's important to know the physical address(s) on the spacecraft that this parameter may be collected from, use this. Holds the list of parameter definitions. A Parameter is a description of something that can have a value; it is not the value itself. An array type. Will be an array of parameters of the type referenced in 'arrayTypeRef' and have the number of array dimensions as specified in 'numberOfDimensions' A type definition used as the base type for a CommandDefinition The MetaCommand is derived from this Base. Arguments of the base MetaCommand are further specified. Optional. Normally used when the database is built in a flat, non-hierarchical format Many commands have one or more options. These are called command arguments. Command arguments may be of any of the standard data types. MetaCommand arguments are local to the MetaCommand. Need to ensure that the named types actually exist Tells how to package this command Appended to the TramsmissionConstraint List of the base command. Constraints are checked in order. A CommandTransmission constraint is used to check that the command can be run in the current operating mode and may block the transmission of the command if the constraint condition is true. Pause during timeOut, fail when the timeout passes Indicates whether the contraints for a Command may be suspended. Some Command and Control Systems may require special user access our confirmations before transmitting commands with certain levels. Will inherit any level defined in the Base MetaCommand. Used when the significance of a command varies by the operating context An Interlock is a type of Constraint, but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. An Interlock will block successive commands until this command has reached a certain stage (through verifications). Interlocks are scoped to a SpaceSystem basis. The name of a SpaceSystem this Interlock applies to. By default, it only applies to the SpaceSystem that contains this MetaCommand. Only applies when the verificationToWaitFor attribute is 'queued' or 'executing'. A flag that indicates that under special circumstances, this Interlock can be suspended. A Command Verifier is a conditional check on the telemetry from a SpaceSystem that provides positive indication on the successful execution of a command. Completed verifiers are added to the Base MetaCommand verifiers. All others will replace a verifier defined in a Base MetaCommand. Transferred to range means the command has been received by a the network that connects the ground system to the spacecraft. Obviously, this verifier must come from something other than the spacecraft. Sent from range means the command has been transmitted to the spacecraft by a the network that connects the ground system to the spacecraft. Obviously, this verifier must come from something other than the spacecraft. A verifier that simply means the SpaceSystem has received the command. A verifier that means the SpaceSystem has accepted the command A verifyer that means the command is scheduled for execution by the SpaceSystem. A verifier that indicates that the command is being executed. An optional Element indicates how far along the command has progressed either as a fixed value or an (possibly scaled) ParameterInstance value. A possible set of verifiers that all must be true for the command be considered completed. When true, indicates that the command failed. timeToWait is how long to wait for the FailedVerifier to test true. Parameters that are set with a new value after the command has been sent. Appended to the Base Command list Sets a Parameter to a new value after the command has been verified (all verifications have passed) Similar to an EntryList type but also may include command arguments or -as a convenience - fixed value entries. The Key = Command Op Code. Each MetaCommand may have one CommandContainer. The sequence may now contain command fields Given that this Container is the Base container type, RestrictionCriteria lists conditions that must be true for this Container to be 'this' subContainer type. May be a simple Comparison List, a Boolean Expression, and/or in a Graph of containers established by the NextContainer A command verifier is used to check that the command has be successfully executed. Command Verifiers may be either a Custom Algorithm or a Boolean Check or the presence of a Container for a relative change in the value of a Parameter. The timeToWait is a time period where the verification must test true. All comparisons must be true When verification is the existance of a Container Used to look for relative change in a Parameter value. Only usefull for numeric Parameters Specifies how much time to provide for the verification. Used by Meta Command to indicate ground Parameters that should be set after completion of a command. Contains an unordered Set of Command Containers Significance provides some cautionary information about the potential consequence of each MetaCommand. If none is supplied, then the current SpaceSystem is assumed to be the one at risk by the issuance of this command No specific meanings have been assigned to these different levels, but they mirror the Alarm levels of Telemetry. This schema defines the structure for an Algorithm. An Algorithm may be one of a growing set of pre defined algorithms or a named escape into a user defined algorithm where (depending on the system) the name of the algorithm may be a java class, a function in a shared library, an external program or some other reference to an outside algorithm. At some later date, this schema may also allow the logic of the user defined algorithm to be defined within the instance document itself (perhaps using MathML?). The simplest form of algorithm, a SimpleAlgorithmType contains an area for a free-form pseudo code description of the algorithm plus a Set of references to external algorithms. External algorithms are usually unique to a ground system type. Multiple external algorithms are possible because XTCE documents may be used across multiple ground systems. This optional element may be used to enter Pseudo or actual code for the algorithm. The language for the algorithm is specified with the language attribute This is the external algorithm. Multiple entries are provided so that the same database may be used for multiple implementation s A set of labeled inputs is added to the SimpleAlgorithmType Names an input parameter to the algorithm. There are two attributes to InputParm, inputName and parameterName. parameterName is a parameter reference name for a parameter that will be used in this algorithm. inputName is an optional "friendly" name for the input parameter. Names and provides a value for a constant input to the algorithm. There are two attributes to Constant, constantName and value. constantName is a variable name in the algorithm to be executed. value is the value of the constant to be used. A set of labled outputs are added to the SimpleInputAlgorithmType Names an output parameter to the algorithm. There are two attributes to OutputParm, outputName and parameterName. parameterName is a parameter reference name for a parameter that will be updated by this algorithm. outputName is an optional "friendly" name for the output parameter. A set of labled triggers is added to the SimpleInputOutputAlgorithmType First telemetry container from which the output parameter should be calculated. Algorithm processing priority. Calibrators are normally used to convert to and from bit compacted numerical data A calibration type where a segmented line in a raw vs calibrated plane is described using a set of points. Raw values are converted to calibrated values by finding a position on the line coorosponding to the raw value. The algorithm triggers on the input parameter. A calibration type where a curve in a raw vs calibrated plane is described using a set of polynomial coefficients. Raw values are converted to calibrated values by finding a position on the curve corresponding to the raw value. The first coefficient belongs with the X^0 term, the next coefficient belongs to the X^1 term and so on. A simple mathematical operation A trigger is used to initiate the processing of some algorithm. A trigger may be based on an update of a Parameter or on a time basis. Triggers may also have a rate that limits their firing to a 1/rate basis. Names a parameter that upon change will start the execution of the algorithm. Holds a parameter reference name for a parameter that when it changes, will cause this algorithm to be executed. This schema provides a language for defining binary stream data. The top level type definition for all data streams that are frame based. This Container (usually abstract) is the container that is in the fixed frame stream. Normally, this is an generalcontainer type from which many specific containers are inherited. This is a reference to a connecting stream - say a custom stream. For streams that contain a series of frames with a fixed frame length where the frames are found by looking for a marker in the data. This marker is sometimes called the frame sync pattern and sometimes the Asynchronous Sync Marker (ASM). The pattern of bits used to look for frame synchronization. CCSDS ASM for non-turbocoded frames = 1acffc1d truncate the mask from the left truncate the pattern from the left Allowed slip (in bits) in either direction for the sync pattern For streams that contain a series of frames with a variable frame length where the frames are found by looking for a series of one's or zero's (usually one's). The series is called the flag. in the PCM stream that are usually made to be illegal in the PCM stream by zero or one bit insertion. The pattern of bits used to look for frame synchronization. A stream type where some level of custom processing (e.g. convolutional, encryption, compression) is performed. Has a reference to external algorithms for encoding and decoding algorithms. Must check to ensure that the attributes encodedStreamRef and decodedStreamRef point to valid Streams Algorithm outputs may be used to set decoding quality parameters. A PCM Stream Type is the high level definition for all Pulse Code Modulated (PCM) (i.e., binary) streams. Holds a reference to a stream name of reference stream Contains an unordered set of Streams. A Sync Strategy specifies the requirements to deem a PCM Fixed Frame Stream "in-sync" or out of sync. The pattern of bits used to look for frame synchronization. A Sync Strategy specifies the strategy on how to find frames within a stream of PCM data. The sync strategy is based upon a state machine that begins in the 'Search' state until the first sync marker is found. Then it goes into the 'Verify' state until a specified number of successive good sync markers are found. Then, the state machine goes into the 'Lock' state, in the 'Lock' state frames are considered good. Should a sync marker be missed in the 'Lock' state, the state machine will transition into the 'Check' state, if the next sync marker is where it's expected within a specified number of frames, then the state machine will transition back to the 'Lock' state, it not it will transition back to 'Search'. After serching for the frame sync marker for some number of bitss, it may be desirable to invert the incoming data, and then look for frame sync. In some cases this will require an external algorithm Maximum number of bit errors in the sync pattern (marker). Used to contain an absolute time. Contains an absolute (to a known epoch) time. Use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e the format ss.ss... with any number of digits after the decimal point is supported. An abstract type used by within the schema to derive other data types by the ground system. An abstract type used by within the schema to describe derive other data types by the ground system. Scale and offset are used in a y =mx +b type relationship (m is the scale and b is the offset) to make adjustmets to the encoded value to that it matches the time units. Binary Encoded time is typically used with a user supplied transform algorithm to convert time data formats that are too difficult to describe in XTCE. Contains an arbitrarily large binary value Contains a boolean value Contains an enumerated value - a value that has both an integral and a string representation. Contains a floating point value Contains an integral value base 10 integer value An abstract type that is a super type of either an Integer or Float Data type. Used to contain a relative time value. Used to describe a relative time. Normally used for time offsets. A Relative time is expressed as PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision. For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: P1Y2M3DT10H30M. One could also indicate a duration of minus 120 days as: -P120D. An extension of Schema duration type. Contains a String Value Describes how a particular piece of data is sent or received from some non-native, off-platform device. (e.g. a spacecraft) Used to describe an arbitrary byte order in multibyte parameters. First byte in list is the first in the stream. Byte significance is the is highest for most significant bytes. If not included, it is assumed that the most significant byte is first, least significant byte last. For all major encodings of integer data Use when different calibrations must be used on the Parameter in different contexts. Use the first one that tests true For common encodings of floating point data Use when different calibrations must be used on the Parameter in different contexts. Use the first one that tests true For common encodings of string data Use when different calibrations must be used on the Parameter in different contexts. Use the first one that tests true Like C strings, they are terminated with a special string, usually a null character. Like PASCAL strings, the size of the string is given as an integer at the start of the string. SizeTag must be an unsigned Integer For binary data or for integer, float, string, or time data that is not in any of the known encoding formats. For any data that is not encoded in any of the known integer, float, string, or time data formats use a To/From transform algorithm. Used to convert binary data to an application data type Used to convert binary data from an application data type to binary data Epochs may be specified as a date or TAI (which correlates to 1 January 1958) Contains an unordered collection of Alias's Used to contain an alias (alternate) name or ID for the the object. For example, a parameter may have a mnemonic, an on-board id, and special IDs used by various ground software applications; all of these are alias's. Some ground system processing equipent has some severe naming restrictions on parameters (e.g., names must less then 12 characters, single case or integral id's only); their alias's provide a means of capturing each name in a "nameSpace". A list of boolean comparisons, or boolean groups that are logically ANDed together. Any ORed conditions in the list are evaluated first. A simple restriction on string for hexadecimal numbers. Must be in 0b or 0B form. Holds an arbitrarily complex boolean expression An ordered list of bytes where the order of the bytes is in stream order. Each byte has an attribute giving its significance. The software must check to ensure that the significance of each byte is unique, and does not contain bytes of greater significance greater than the size of the object A ParameterInstanceRef to a value or another parameter instance Parameter is assumed to be of the same type as the comparison Parameter Value is assumed to be of the same type as the comparison Parameter A simple ParameterInstanceRef to value comparison. The string supplied in the value attribute needs to be converted to a type matching the Parameter being compared to. Numerical values are assumed to be base 10 unless proceeded by 0x (hexadecimal), 0o (octal), or 0b (binary). The value is truncated to use the least significant bits that match the bit size of the Parameter being compared to. Operators to use when testing a boolean condition for a validity check Context calibrations are applied when the ContextMatch is true. Context calibrators overide Default calibrators Contains an Numeric value; value may be provided directly or via the value in a parameter. Uses a parameter to for the value. The parameter value may be optionally adjusted by a Linear function or use a series of boolean expressions to lookup the value. Anything more complex and a DynamicValue with a CustomAlgorithm may be used A slope and intercept may be applied to scale or shift the value of the parameter in the dynamic value A simple element that provides for simple, but common error checking and detection. Bit position starts with 'zero'. Cyclic Redundancy Check definition. Legal values for coefficient's are 0 or 1. Exponents must be integer values. A simple union type combining integer, octal, binary, and hexadecimal types Schema for a Header record. A header contains general information about the system or subsystem. A simple restriction on string for hexadecimal numbers. Must be in 0x or 0X form. Contains an Integer value; value may be provided directly or via the value in a parameter. Uses a parameter to for the value. The parameter value may be optionally adjusted by a Linear function or use a series of boolean expressions to lookup the value. Anything more complex and a DynamicValue with a CustomAlgorithm may be used A slope and intercept may be applied to scale or shift the value of the parameter in the dynamic value Lookup a value using the lookup list supplied. Use the first match found. Mathematical operators Contains either a simple Comparison, a ComparisonList, an arbitrarily complex BooleanExpression or an escape to an externally defined algorithm A simple comparison check All comparisons must be true An arbitrarily complex boolean expression An escape to an externally defined algorithm A simple math operation Value is assumed to be of the same type as the Parameter Value is assumed to be of the same type as the Parameter Used for "directory" style unique names. We need to preclude '.', '/', ':", "[" and "]". Only letters, digits, '_', ' ' and "-" are allowed The type definition used by most elements that require a name with optional descriptions. The short description is intended to be used for quick "memory jogger" descriptions of the object. The Long Description is intended to be used for explanitory descriptions of the object and may include HTML markup. Long Decriptions are of unbounded length It is strongly recommended that the short description be kept under 80 characters in length Used when referencing a directory style "NameType". No characters are prohibited. There are two ways numeric data can be changed to string data: using a Java style NumberFormat, or using an enumerated list. Enumerated lists can be assigned to a single value or a value range. A number or range assigned to a string. A string value associated with a numerical range. A simple restriction on string for hexadecimal numbers. Must be in 0o or 0O form. A list of boolean comparisons, or boolean groups that are logically ORed together. Any ANDed conditions in the list are evaluated first. Used by both the TelemetryMetaData and the CommandMetaData components each may be built independently. Need to ensure that the named types actually exist Used to include a Parameter defined in another sub-system in this sub-system. A polynomial expression. For example: 3 + 2x A term in a polynomial expresssion. Used for custom user properties Specifies the number base Most time values are relative to another time e.g. seconds are relative to minutes, minutes are relative to hours. This type is used to describe this relationship starting with the least significant time Parameter to and progressing to the most significant time parameter. Used to describe a relative time. Normally used for time offsets. A Relative time is expressed as PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision. For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: P1Y2M3DT10H30M. One could also indicate a duration of minus 120 days as: -P120D. An extension of Schema duration type. Hold a structure that can be repeated X times, where X is the Count Value (either fixed or dynamic) that contains the count of repeated structures. Indicates the distance between repeating entries (the last bit of one entry to the start bit of the next entry) a spline is a set on points from which a curve may be drawn to interpolate raw to calibrated values Used to hold the unit(s) plus possibly the exponents for the units Contains a value and an associated string label When the alarm is determined by boolean logic Contains five ranges: Watch, Warning, Distress, Critical, and Severe each in increasing severity. Normally, only the Warning and Critical ranges are used and the color yellow is associated with Warning and the color red is associated with Critical. The ranges given are valid for numbers lower than the min and higher than the max values. These ranges should not overlap, but if they do, assume the most severe range is to be applied. All ranges are optional and it is quite allowed for there to be only one end of the range. Context alarms are applied when the ContextMatch is true. Context alarms override Default alarms A range of numbers. "minInclusive", "minExclusive", "maxInclusive" and "maxExclusive" attributes are borrowed from the W3C schema language. An integral range of numbers. "min", and "max". Alarms associated with numeric data types StaticAlarmRanges are used to trigger alarms when the parameter value passes some threshold value ChangePerSecondAlarmRanges are used to trigger alarms when the parameter value's rate-ofchange passes some threshold value. An alarm condition that triggers when the value changes too fast (or too slow) A MatchCriteria may be specifiec for each of the 5 alarm levels. Each level is optional and the alarm should be the highest level to test true. An escape for ridiculously complex alarm conditions. Will trigger on changes to the containing Parameter. Number of successive values of the Parameter for the Alarm to trigger. The XTCE normative specification is contained entirely as a W3C XML Schema. This schema is available as a standalone document at http://www.omg.org/space/xtce/SpaceSystem1.0.xsd OMG Document Number: dtc/2005-01-05 $Id: SpaceSystemV1.0.xsd,v 1.15 2005/01/24 05:02:50 gerry Exp $ This is the master schema for the OMG Space Domain Task Force XML Telemetric and Command data Exchange (XTCE) format. The ROOT Element ensure unique parameter name at the system level ensure unique metaCommand name at the system level ensure unique algorithm name at the system level ensure unique service name at the system level SpaceSystem is a collection of SpaceSystem(s) including space assets, ground assets, multi-satellite systems and sub-systems. A SpaceSystem is the root element for the set of data necessary to monitor and command an arbitrary space device - this includes the binary decomposition the data streams going into and out of a device. A service is a logical grouping of container and/or messages. Defaults has default data encoding for ParameterTypes and ArgumentTypes and default parameter time association that will be applied to all Parameters within this SpaceSystem. These defaults may be overidden by sub-SpaceSystems or by the Types or Parameters themselves. Defaults simply provides a means to avoid repeating attributes such as ‘bit order’ for every Type definition. Since the data encoding (bit order and byte order) is normally the same throughout a spacesystem, using this element allows that data encoding to be specified as a default. Default time to associate each ParameterInstance with. Command Meta Data contains information about commands A list of parameter types Parameters referenced by MetaCommands. This Parameter Set is located here so that MetaCommand data can be built independantly of TelemetryMetaData. A set of Command Definitions All commands to be sent on this mission are listed here. In addition this area has verification and validation information Used to include a MetaCommand defined in another sub-system in this sub-system. BlockMetaCommands are simply a list of individual MetaCommands that can be packaged up in a single BlockMetaCommand. The Command Container defines the construction of a Command. All the data about telemetry is contained in TelemetryMetaData A list of parameter types A list of Parameters for this Space System. Holds the list of all potential container definitions for telemetry. Containers may parts of packets or TDM, and then groups of the containers, and then an entire entity --such as a packet. In order to maximize re-used for duplication, the pieces may defined once here, and then assembled as needed into larger structures, also here. Messages are an alternative method of uniquely identifying containers within a Service. A message provides a test in the form of MatchCriteria to match to a container. A simple example might be: [When minorframeID=21, the message is the 21st minorframe container. The collection of messages to search thru will be bound by a Service. The ContainerRef should point to ROOT container that will describe an entire packet/minor frame or chunk of telemetry. A reference to a Service An unordered collection of algorithms This schema definies the dictionary for containers, which in turn describe the physical composition of data in a communication system An abstract block of data; used as the base type for more specific container types RateInStream is used to: a) generate alarms when the Container is updated too frequently or too infrequently, b) provide some 'guidelines' for generating forward link containers, c) provide some guidelines for spacecraft simulators to generate telemetry containers. If necessary, these rates may be defined on a per stream basis. The software should check that any Stream names referenced in the RateInStreamSet actually exist. May be used to indicate error detection and correction, chage byte order, provide the size (when it can't be derived), or perform some custom processing. A list of raw parameters, parameter segments, stream segments, containers, or container segments. Sequence containers may inherit from other sequence containers; when they do, the sequence in the parent SequenceContainer is 'inherited' and if the location of entries in the child sequence is not specified, it is assumed to start where the parent sequence ended. Parent sequence containers may be marked as "abstract". The idle pattern is part of any unallocated space in the Container. Given that this Container is the Base container type, RestrictionCriteria lists conditions that must be true for this Container to be 'this' subContainer type. May be a simple Comparison List, a Boolean Expression, and/or in a Graph of containers established by the NextContainer An abstract type used by sequence containers. An entry contains a location in the container. The location may be either fixed or dynamic, absolute (to the start or end of the enclosing container, or relative (to either the previous or subsequent entry). Entries may also repeat. If no LocationInContainer value is given, the entry is assumed to begin immediately after the previous entry. The location may be relative to the start of the container (containerStart), relatitive to the end of the previous entry (previousEntry), relative to the end of the container (containerEnd), or relative to the entry that follows this one (nextEntry). If going forward (containerStart and previousEntry) then, then the location refers to the start of the Entry. If going backwards (containerEnd and nextEntry) then, the location refers to the end of the entry. May be used when this entry repeats itself in the sequence container. If not supplied, the entry does not repeat. This entry will only be included in the sequence when this condition is true. If no IncludeCondition is given, then it is will be included. A parameter that is not included will be treated as if it did not exist in the sequence at all. Holds a reference to a container name of container Holds a reference to a message name of container Holds a set of services, logical groups of containers OR messages (not both). Unordered Set of Containers SequenceContainers define sequences of parameters or other containers. Contains an ordered list of Entries. Used in Sequence Container An entry that is a single Parameter An entry that is only a portion of a parameter value indicating that the entire parameter value must be assembled from other parameter segments. It is assumed that parameter segments happen sequentially in time, that is the first part if a telemetry parameter first, however (and there's always a however), if this is not the case the order of this parameter segment may be supplied with the order attribute where the first segment order="0". An entry that is simply a reference to another container. An entry that is only a portion of a parameter value indicating that the entire parameter value must be assembled from other parameter segments. It is assumed that parameter segments happen sequentially in time, that is the first part if a telemetry parameter first, however (and there's always a however), if this is not the case the order of this parameter segment may be supplied with the order attribute where the first segment order="0". An entry that is a portion of a stream (streams are by definition, assumed continuous) It is assumed that stream segments happen sequentially in time, that is the first part if a steam first, however, if this is not the case the order of the stream segments may be supplied with the order attribute where the first segment order="0". An entry whose name is given by the value of a ParamameterInstance. This entry may be used to implement dwell telemetry streams. The value of the parameter in ParameterInstance must use either the name of the Parameter or its alias. If it's an alias name, the alias namespace is supplied as an attribute. An entry that is an array parameter. This entry is somewhat special because the entry may represent only a part of the Array and it's important to decribe which diminsions of the array come first in the sequence as well as the size of the array. Where the Dimension list is in this form: Array[1stDim][2ndDim][lastDim]. The last dimension is assumed to be the least significant - that is this dimension will cycle through it's combination before the next to last dimension changes. The order MUST ascend or the array will need to be broken out entry by entry. For partial entries of an array, the starting and ending index for each dimension, OR the Size must be specified. Indexes are zero based. For an ArrayParameterType of size N, their should be N Dimensions An array made up by multiple Entries should not have index's that overlap, but should be continuous. zero based index Used in packaging to define the expected rate that any individual container will be in a Stream A wrapper for those properties that are unique to telemetry parameters. Optional. Normally used when the database is built in a flat, non-hierarchical format Optional condition that must be true for this Parameter to be valid One or more physical addresses may be associated with each Parameter. Examples of phyical addresses include a location on the spacecraft or a location on a data collection bus. Contains the address (e.g., channel information) required to process the spacecraft telemetry streams. May be an onboard id, a mux address, or a physical location. Contains the address (channel information) required to process the spacecraft telemetry streams This time will overide any Default value for TimeAssociation. A telemetered Parameter is one that will have values in telemetry. A derived Parameter is one that is calculated, usually be an Algorithm. A constant Parameter is one that is used as a constant in the system (e.g. a vehicle id). A local Parameter is one that is used purely on the ground (e.g. a ground command counter). A Parameter marked as 'readOnly' true is constant and non-settable Telemetry parameter instances are oftentimes "time-tagged" with a timing signal either provided on the ground or on the space system. This data element allows one to specify which of possibly many AbsoluteTimeParameters to use to "time-tag" parameter instances with. The parameter ref must be to an AbsoluteTime Parameter If true, then the current value of the AbsoluteTime will be projected to current time. I.E., if the value of the AbsoluteTime parameter was set 10 seconds ago, then 10 seconds will be added to it's value before associating this time with the parameter. The offset is used to supply a relative time offset from the time association and to this parameter A reference to an instance of a Parameter. Used when the value of a parameter is required for a calculation or as an index value. A positive value for instance is forward in time, a negative value for count is backward in time, a 0 value for count means use the current value of the parameter or the first value in a container. A reference to a Parameter. Uses Unix ‘like’ naming across the SpaceSystem Tree (e.g., SimpleSat/Bus/EPDS/BatteryOne/Voltage). To reference an individual member of an array use the zero based bracket notation commonly used in languages like C, C++, and Java. When it's important to know the physical address(s) on the spacecraft that this parameter may be collected from, use this. Holds the list of parameter definitions. A Parameter is a description of something that can have a value; it is not the value itself. An array type. Will be an array of parameters of the type referenced in 'arrayTypeRef' and have the number of array dimensions as specified in 'numberOfDimensions' A type definition used as the base type for a CommandDefinition The MetaCommand is derived from this Base. Arguments of the base MetaCommand are further specified. Optional. Normally used when the database is built in a flat, non-hierarchical format Many commands have one or more options. These are called command arguments. Command arguments may be of any of the standard data types. MetaCommand arguments are local to the MetaCommand. Need to ensure that the named types actually exist Tells how to package this command Appended to the TramsmissionConstraint List of the base command. Constraints are checked in order. A CommandTransmission constraint is used to check that the command can be run in the current operating mode and may block the transmission of the command if the constraint condition is true. Pause during timeOut, fail when the timeout passes Indicates whether the contraints for a Command may be suspended. Some Command and Control Systems may require special user access our confirmations before transmitting commands with certain levels. Will inherit any level defined in the Base MetaCommand. Used when the significance of a command varies by the operating context An Interlock is a type of Constraint, but not on Command instances of this MetaCommand; Interlocks apply instead to the next command. An Interlock will block successive commands until this command has reached a certain stage (through verifications). Interlocks are scoped to a SpaceSystem basis. The name of a SpaceSystem this Interlock applies to. By default, it only applies to the SpaceSystem that contains this MetaCommand. Only applies when the verificationToWaitFor attribute is 'queued' or 'executing'. A flag that indicates that under special circumstances, this Interlock can be suspended. A Command Verifier is a conditional check on the telemetry from a SpaceSystem that provides positive indication on the successful execution of a command. Completed verifiers are added to the Base MetaCommand verifiers. All others will replace a verifier defined in a Base MetaCommand. Transferred to range means the command has been received by a the network that connects the ground system to the spacecraft. Obviously, this verifier must come from something other than the spacecraft. Sent from range means the command has been transmitted to the spacecraft by a the network that connects the ground system to the spacecraft. Obviously, this verifier must come from something other than the spacecraft. A verifier that simply means the SpaceSystem has received the command. A verifier that means the SpaceSystem has accepted the command A verifyer that means the command is scheduled for execution by the SpaceSystem. A verifier that indicates that the command is being executed. An optional Element indicates how far along the command has progressed either as a fixed value or an (possibly scaled) ParameterInstance value. A possible set of verifiers that all must be true for the command be considered completed. When true, indicates that the command failed. timeToWait is how long to wait for the FailedVerifier to test true. Parameters that are set with a new value after the command has been sent. Appended to the Base Command list Sets a Parameter to a new value after the command has been verified (all verifications have passed) Similar to an EntryList type but also may include command arguments or -as a convenience - fixed value entries. The Key = Command Op Code. Each MetaCommand may have one CommandContainer. The sequence may now contain command fields Given that this Container is the Base container type, RestrictionCriteria lists conditions that must be true for this Container to be 'this' subContainer type. May be a simple Comparison List, a Boolean Expression, and/or in a Graph of containers established by the NextContainer A command verifier is used to check that the command has be successfully executed. Command Verifiers may be either a Custom Algorithm or a Boolean Check or the presence of a Container for a relative change in the value of a Parameter. The timeToWait is a time period where the verification must test true. All comparisons must be true When verification is the existance of a Container Used to look for relative change in a Parameter value. Only usefull for numeric Parameters Specifies how much time to provide for the verification. Used by Meta Command to indicate ground Parameters that should be set after completion of a command. Contains an unordered Set of Command Containers Significance provides some cautionary information about the potential consequence of each MetaCommand. If none is supplied, then the current SpaceSystem is assumed to be the one at risk by the issuance of this command No specific meanings have been assigned to these different levels, but they mirror the Alarm levels of Telemetry. This schema defines the structure for an Algorithm. An Algorithm may be one of a growing set of pre defined algorithms or a named escape into a user defined algorithm where (depending on the system) the name of the algorithm may be a java class, a function in a shared library, an external program or some other reference to an outside algorithm. At some later date, this schema may also allow the logic of the user defined algorithm to be defined within the instance document itself (perhaps using MathML?). The simplest form of algorithm, a SimpleAlgorithmType contains an area for a free-form pseudo code description of the algorithm plus a Set of references to external algorithms. External algorithms are usually unique to a ground system type. Multiple external algorithms are possible because XTCE documents may be used across multiple ground systems. This optional element may be used to enter Pseudo or actual code for the algorithm. The language for the algorithm is specified with the language attribute This is the external algorithm. Multiple entries are provided so that the same database may be used for multiple implementation s A set of labeled inputs is added to the SimpleAlgorithmType Names an input parameter to the algorithm. There are two attributes to InputParm, inputName and parameterName. parameterName is a parameter reference name for a parameter that will be used in this algorithm. inputName is an optional "friendly" name for the input parameter. Names and provides a value for a constant input to the algorithm. There are two attributes to Constant, constantName and value. constantName is a variable name in the algorithm to be executed. value is the value of the constant to be used. A set of labled outputs are added to the SimpleInputAlgorithmType Names an output parameter to the algorithm. There are two attributes to OutputParm, outputName and parameterName. parameterName is a parameter reference name for a parameter that will be updated by this algorithm. outputName is an optional "friendly" name for the output parameter. A set of labled triggers is added to the SimpleInputOutputAlgorithmType First telemetry container from which the output parameter should be calculated. Algorithm processing priority. Calibrators are normally used to convert to and from bit compacted numerical data A calibration type where a segmented line in a raw vs calibrated plane is described using a set of points. Raw values are converted to calibrated values by finding a position on the line coorosponding to the raw value. The algorithm triggers on the input parameter. A calibration type where a curve in a raw vs calibrated plane is described using a set of polynomial coefficients. Raw values are converted to calibrated values by finding a position on the curve corresponding to the raw value. The first coefficient belongs with the X^0 term, the next coefficient belongs to the X^1 term and so on. A simple mathematical operation A trigger is used to initiate the processing of some algorithm. A trigger may be based on an update of a Parameter or on a time basis. Triggers may also have a rate that limits their firing to a 1/rate basis. Names a parameter that upon change will start the execution of the algorithm. Holds a parameter reference name for a parameter that when it changes, will cause this algorithm to be executed. This schema provides a language for defining binary stream data. The top level type definition for all data streams that are frame based. This Container (usually abstract) is the container that is in the fixed frame stream. Normally, this is an generalcontainer type from which many specific containers are inherited. This is a reference to a connecting stream - say a custom stream. For streams that contain a series of frames with a fixed frame length where the frames are found by looking for a marker in the data. This marker is sometimes called the frame sync pattern and sometimes the Asynchronous Sync Marker (ASM). The pattern of bits used to look for frame synchronization. CCSDS ASM for non-turbocoded frames = 1acffc1d truncate the mask from the left truncate the pattern from the left Allowed slip (in bits) in either direction for the sync pattern For streams that contain a series of frames with a variable frame length where the frames are found by looking for a series of one's or zero's (usually one's). The series is called the flag. in the PCM stream that are usually made to be illegal in the PCM stream by zero or one bit insertion. The pattern of bits used to look for frame synchronization. A stream type where some level of custom processing (e.g. convolutional, encryption, compression) is performed. Has a reference to external algorithms for encoding and decoding algorithms. Must check to ensure that the attributes encodedStreamRef and decodedStreamRef point to valid Streams Algorithm outputs may be used to set decoding quality parameters. A PCM Stream Type is the high level definition for all Pulse Code Modulated (PCM) (i.e., binary) streams. Holds a reference to a stream name of reference stream Contains an unordered set of Streams. A Sync Strategy specifies the requirements to deem a PCM Fixed Frame Stream "in-sync" or out of sync. The pattern of bits used to look for frame synchronization. A Sync Strategy specifies the strategy on how to find frames within a stream of PCM data. The sync strategy is based upon a state machine that begins in the 'Search' state until the first sync marker is found. Then it goes into the 'Verify' state until a specified number of successive good sync markers are found. Then, the state machine goes into the 'Lock' state, in the 'Lock' state frames are considered good. Should a sync marker be missed in the 'Lock' state, the state machine will transition into the 'Check' state, if the next sync marker is where it's expected within a specified number of frames, then the state machine will transition back to the 'Lock' state, it not it will transition back to 'Search'. After serching for the frame sync marker for some number of bitss, it may be desirable to invert the incoming data, and then look for frame sync. In some cases this will require an external algorithm Maximum number of bit errors in the sync pattern (marker). Used to contain an absolute time. Contains an absolute (to a known epoch) time. Use the [ISO 8601] extended format CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e the format ss.ss... with any number of digits after the decimal point is supported. An abstract type used by within the schema to derive other data types by the ground system. An abstract type used by within the schema to describe derive other data types by the ground system. Scale and offset are used in a y =mx +b type relationship (m is the scale and b is the offset) to make adjustmets to the encoded value to that it matches the time units. Binary Encoded time is typically used with a user supplied transform algorithm to convert time data formats that are too difficult to describe in XTCE. Contains an arbitrarily large binary value Contains a boolean value Contains an enumerated value - a value that has both an integral and a string representation. Contains a floating point value Contains an integral value base 10 integer value An abstract type that is a super type of either an Integer or Float Data type. Used to contain a relative time value. Used to describe a relative time. Normally used for time offsets. A Relative time is expressed as PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision. For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: P1Y2M3DT10H30M. One could also indicate a duration of minus 120 days as: -P120D. An extension of Schema duration type. Contains a String Value Describes how a particular piece of data is sent or received from some non-native, off-platform device. (e.g. a spacecraft) Used to describe an arbitrary byte order in multibyte parameters. First byte in list is the first in the stream. Byte significance is the is highest for most significant bytes. If not included, it is assumed that the most significant byte is first, least significant byte last. For all major encodings of integer data Use when different calibrations must be used on the Parameter in different contexts. Use the first one that tests true For common encodings of floating point data Use when different calibrations must be used on the Parameter in different contexts. Use the first one that tests true For common encodings of string data Use when different calibrations must be used on the Parameter in different contexts. Use the first one that tests true Like C strings, they are terminated with a special string, usually a null character. Like PASCAL strings, the size of the string is given as an integer at the start of the string. SizeTag must be an unsigned Integer For binary data or for integer, float, string, or time data that is not in any of the known encoding formats. For any data that is not encoded in any of the known integer, float, string, or time data formats use a To/From transform algorithm. Used to convert binary data to an application data type Used to convert binary data from an application data type to binary data Epochs may be specified as a date or TAI (which correlates to 1 January 1958) Contains an unordered collection of Alias's Used to contain an alias (alternate) name or ID for the the object. For example, a parameter may have a mnemonic, an on-board id, and special IDs used by various ground software applications; all of these are alias's. Some ground system processing equipent has some severe naming restrictions on parameters (e.g., names must less then 12 characters, single case or integral id's only); their alias's provide a means of capturing each name in a "nameSpace". A list of boolean comparisons, or boolean groups that are logically ANDed together. Any ORed conditions in the list are evaluated first. A simple restriction on string for hexadecimal numbers. Must be in 0b or 0B form. Holds an arbitrarily complex boolean expression An ordered list of bytes where the order of the bytes is in stream order. Each byte has an attribute giving its significance. The software must check to ensure that the significance of each byte is unique, and does not contain bytes of greater significance greater than the size of the object A ParameterInstanceRef to a value or another parameter instance Parameter is assumed to be of the same type as the comparison Parameter Value is assumed to be of the same type as the comparison Parameter A simple ParameterInstanceRef to value comparison. The string supplied in the value attribute needs to be converted to a type matching the Parameter being compared to. Numerical values are assumed to be base 10 unless proceeded by 0x (hexadecimal), 0o (octal), or 0b (binary). The value is truncated to use the least significant bits that match the bit size of the Parameter being compared to. Operators to use when testing a boolean condition for a validity check Context calibrations are applied when the ContextMatch is true. Context calibrators overide Default calibrators Contains an Numeric value; value may be provided directly or via the value in a parameter. Uses a parameter to for the value. The parameter value may be optionally adjusted by a Linear function or use a series of boolean expressions to lookup the value. Anything more complex and a DynamicValue with a CustomAlgorithm may be used A slope and intercept may be applied to scale or shift the value of the parameter in the dynamic value A simple element that provides for simple, but common error checking and detection. Bit position starts with 'zero'. Cyclic Redundancy Check definition. Legal values for coefficient's are 0 or 1. Exponents must be integer values. A simple union type combining integer, octal, binary, and hexadecimal types Schema for a Header record. A header contains general information about the system or subsystem. A simple restriction on string for hexadecimal numbers. Must be in 0x or 0X form. Contains an Integer value; value may be provided directly or via the value in a parameter. Uses a parameter to for the value. The parameter value may be optionally adjusted by a Linear function or use a series of boolean expressions to lookup the value. Anything more complex and a DynamicValue with a CustomAlgorithm may be used A slope and intercept may be applied to scale or shift the value of the parameter in the dynamic value Lookup a value using the lookup list supplied. Use the first match found. Mathematical operators Contains either a simple Comparison, a ComparisonList, an arbitrarily complex BooleanExpression or an escape to an externally defined algorithm A simple comparison check All comparisons must be true An arbitrarily complex boolean expression An escape to an externally defined algorithm A simple math operation Value is assumed to be of the same type as the Parameter Value is assumed to be of the same type as the Parameter Used for "directory" style unique names. We need to preclude '.', '/', ':", "[" and "]". Only letters, digits, '_', ' ' and "-" are allowed The type definition used by most elements that require a name with optional descriptions. The short description is intended to be used for quick "memory jogger" descriptions of the object. The Long Description is intended to be used for explanitory descriptions of the object and may include HTML markup. Long Decriptions are of unbounded length It is strongly recommended that the short description be kept under 80 characters in length Used when referencing a directory style "NameType". No characters are prohibited. There are two ways numeric data can be changed to string data: using a Java style NumberFormat, or using an enumerated list. Enumerated lists can be assigned to a single value or a value range. A number or range assigned to a string. A string value associated with a numerical range. A simple restriction on string for hexadecimal numbers. Must be in 0o or 0O form. A list of boolean comparisons, or boolean groups that are logically ORed together. Any ANDed conditions in the list are evaluated first. Used by both the TelemetryMetaData and the CommandMetaData components each may be built independently. Need to ensure that the named types actually exist Used to include a Parameter defined in another sub-system in this sub-system. A polynomial expression. For example: 3 + 2x A term in a polynomial expresssion. Used for custom user properties Specifies the number base Most time values are relative to another time e.g. seconds are relative to minutes, minutes are relative to hours. This type is used to describe this relationship starting with the least significant time Parameter to and progressing to the most significant time parameter. Used to describe a relative time. Normally used for time offsets. A Relative time is expressed as PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision. For example, to indicate a duration of 1 year, 2 months, 3 days, 10 hours, and 30 minutes, one would write: P1Y2M3DT10H30M. One could also indicate a duration of minus 120 days as: -P120D. An extension of Schema duration type. Hold a structure that can be repeated X times, where X is the Count Value (either fixed or dynamic) that contains the count of repeated structures. Indicates the distance between repeating entries (the last bit of one entry to the start bit of the next entry) a spline is a set on points from which a curve may be drawn to interpolate raw to calibrated values Used to hold the unit(s) plus possibly the exponents for the units Contains a value and an associated string label When the alarm is determined by boolean logic Contains five ranges: Watch, Warning, Distress, Critical, and Severe each in increasing severity. Normally, only the Warning and Critical ranges are used and the color yellow is associated with Warning and the color red is associated with Critical. The ranges given are valid for numbers lower than the min and higher than the max values. These ranges should not overlap, but if they do, assume the most severe range is to be applied. All ranges are optional and it is quite allowed for there to be only one end of the range. Context alarms are applied when the ContextMatch is true. Context alarms override Default alarms A range of numbers. "minInclusive", "minExclusive", "maxInclusive" and "maxExclusive" attributes are borrowed from the W3C schema language. An integral range of numbers. "min", and "max". Alarms associated with numeric data types StaticAlarmRanges are used to trigger alarms when the parameter value passes some threshold value ChangePerSecondAlarmRanges are used to trigger alarms when the parameter value's rate-ofchange passes some threshold value. An alarm condition that triggers when the value changes too fast (or too slow) A MatchCriteria may be specifiec for each of the 5 alarm levels. Each level is optional and the alarm should be the highest level to test true. An escape for ridiculously complex alarm conditions. Will trigger on changes to the containing Parameter. Number of successive values of the Parameter for the Alarm to trigger.