XTCE13 — Access to command arguments in transmission constraints and command verifiers

Sometimes the constraints and/or verifies associated to a command may depend on the value of the arguments of the command sent. For example setting a thermostat to a certain setpoint may have a constraint which will only allow a given setpoint in a specific operational mode.
A verifier can compare the setpoint sent as command argument with the setpoint known in the spacecraft and received as a TM parameter.

To achieve this, arguments references should be allowed in the definition of the constraints/verifiers.

In practice:

• TransmissionConstraintType should extend the ArgumentMatchCriteriaType (instead of MatchCriteriaType)
• CommandVerifierType should allow elements of type ArgumentInputAlgorithmType , ArgumentBooleanExpressionType and ArgumentComparisonType (instead of the non argument variety)

All the Argument* types are superset of the corresponding non-argument types so by doing this change, the schema will be backward compatible.

Note: a similar request could be argued for ParametrToSetType to allow setting a parameter to a value computed based on the user defined argument of the command. However since there is no ArgumentMathOperationType, no easy solution can be immediately seen without adding extra types.

Reballot: Add Argument Context to Constraints and Verifiers

It is generally agreed that the transmission constraint and verifiers for the MetaCommand element are of very limited usefulness without having some way to be contextually tied to the argument values of a MetaCommand.

A couple approaches to solving this problem have been discussed. This approach proposed here introduces a context to these child elements that permits them to be restricted to the value of an argument used in the MetaCommand. This will make these child elements much more useful and also maintain backwards compatibility, which was a concern for some of the other proposed methods.

To implement this enhancement, first it is necessary to create a new schema type named "ArgumentRestrictionListType". In the supporting XSD file, it is placed above the type named "ArgumentType":

<complexType name="ArgumentRestrictionListType">
<annotation>
<documentation xml:lang="en">Defines a list of argument values that restrict a constraint from being realized in the commanding lifecycle.</documentation>
</annotation>
<sequence>
<element name="ArgumentRestriction" type="xtce:ArgumentAssignmentType" maxOccurs="unbounded">
<annotation>
<documentation xml:lang="en">Specifies an argument value that causes this constraint to be realized.</documentation>
</annotation>
</element>
</sequence>
</complexType>

Where the next line is pre-existing:

<complexType name="ArgumentType">

Another new schema type named "ArgumentMathOperationType" is introduced next. In the supporting XSD file, it is placed above the type named "MathOperationType":

<complexType name="ArgumentMathOperationType">
<annotation>
<documentation xml:lang="en">Describe a value to set to a destination Parameter after completion of a commanding lifecycle step.</documentation>
</annotation>
<choice maxOccurs="unbounded">
<annotation>
<documentation xml:lang="en">Describe a postfix (aka Reverse Polish Notation (RPN)) expression for mathematical equations. It uses a stack where operands (either fixed values or ParameterInstances) are pushed onto the stack from first to last in the XML. As the operators are specified, each pops off operands as it evaluates them, and pushes the result back onto the stack. For example, the stack, 4 8 /, would result as 0.5. In this case postfix is used to avoid having to specify parenthesis. To convert from infix to postfix, use Dijkstra's "shunting yard" algorithm.</documentation>
</annotation>
<element name="ValueOperand" type="string">
<annotation>
<documentation xml:lang="en">Use a constant in the calculation.</documentation>
</annotation>
</element>
<element name="ThisParameterOperand" type="string" fixed="">
<annotation>
<documentation xml:lang="en">Use the value of the target parameter in the calculation. It is the calibrated/engineering value only. If the raw value is needed, specify it explicitly using ParameterInstanceRefOperand. Note this element has no content.</documentation>
</annotation>
</element>
<element name="Operator" type="xtce:MathOperatorsType">
<annotation>
<documentation xml:lang="en">All operators utilize operands on the top values in the stack and leaving the result on the top of the stack. Ternary operators utilize the top three operands on the stack, binary operators utilize the top two operands on the stack, and unary operators use the top operand on the stack.</documentation>
</annotation>
</element>
<element name="ParameterInstanceRefOperand" type="xtce:ParameterInstanceRefType">
<annotation>
<documentation xml:lang="en">This element is used to reference the last received/assigned value of any Parameter in this math operation.</documentation>
</annotation>
</element>
<element name="ArgumentInstanceRefOperand" type="xtce:ArgumentInstanceRefType">
<annotation>
<documentation xml:lang="en">This element is used to reference a value of any Argument from this command instance in this math operation.</documentation>
</annotation>
</element>
</choice>
</complexType>

Where the next line is pre-existing:

<complexType name="MathOperationType" abstract="true">

This concludes the addition of new schema types, of which there are two above.

Next, the schema type named "CommandVerifierType" is visited with an addition of a new element that leverages the first new schema type above. The before and after schema type are:

before change:

<complexType name="CommandVerifierType" abstract="true">
<annotation>
<documentation xml:lang="en">A command verifier is used to check that the command has been 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 CheckWindow is a time period where the verification must test true to pass.</documentation>
</annotation>
<complexContent>
<extension base="xtce:OptionalNameDescriptionType">
<sequence>
<choice>
<element name="ComparisonList" type="xtce:ComparisonListType">
<annotation>
<documentation xml:lang="en">Verification is a list of comparisons.</documentation>
</annotation>
</element>
<element name="ContainerRef" type="xtce:ContainerRefType">
<annotation>
<documentation xml:lang="en">Verification is a new instance of the referenced container. For example, sending a command to download memory then receiving a packet with the memory download would be verified upon receipt of the packet.</documentation>
</annotation>
</element>
<element name="ParameterValueChange" type="xtce:ParameterValueChangeType">
<annotation>
<documentation xml:lang="en">Verification is a telemetry parameter value change on the ground. For example, a command counter.</documentation>
</annotation>
</element>
<element name="CustomAlgorithm" type="xtce:InputAlgorithmType">
<annotation>
<documentation xml:lang="en">Verification is outside the scope of regular command and telemetry processing.</documentation>
</annotation>
</element>
<element name="BooleanExpression" type="xtce:BooleanExpressionType">
<annotation>
<documentation xml:lang="en">Verification is a boolean expression of conditions.</documentation>
</annotation>
</element>
<element name="Comparison" type="xtce:ComparisonType">
<annotation>
<documentation xml:lang="en">Verification is a single comparison.</documentation>
</annotation>
</element>
</choice>
<choice>
<element name="CheckWindow" type="xtce:CheckWindowType">
<annotation>
<documentation xml:lang="en">Define a time window for checking for verification.</documentation>
</annotation>
</element>
<element name="CheckWindowAlgorithms" type="xtce:CheckWindowAlgorithmsType">
<annotation>
<documentation xml:lang="en">Define a time window algorithmically for verification.</documentation>
</annotation>
</element>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>

After the change, a new "ArgumentRestrictionList" element is added:

<complexType name="CommandVerifierType" abstract="true">
<annotation>
<documentation xml:lang="en">A command verifier is used to check that the command has been 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 CheckWindow is a time period where the verification must test true to pass.</documentation>
</annotation>
<complexContent>
<extension base="xtce:OptionalNameDescriptionType">
<sequence>
<choice>
<element name="ComparisonList" type="xtce:ComparisonListType">
<annotation>
<documentation xml:lang="en">Verification is a list of comparisons.</documentation>
</annotation>
</element>
<element name="ContainerRef" type="xtce:ContainerRefType">
<annotation>
<documentation xml:lang="en">Verification is a new instance of the referenced container. For example, sending a command to download memory then receiving a packet with the memory download would be verified upon receipt of the packet.</documentation>
</annotation>
</element>
<element name="ParameterValueChange" type="xtce:ParameterValueChangeType">
<annotation>
<documentation xml:lang="en">Verification is a telemetry parameter value change on the ground. For example, a command counter.</documentation>
</annotation>
</element>
<element name="CustomAlgorithm" type="xtce:InputAlgorithmType">
<annotation>
<documentation xml:lang="en">Verification is outside the scope of regular command and telemetry processing.</documentation>
</annotation>
</element>
<element name="BooleanExpression" type="xtce:BooleanExpressionType">
<annotation>
<documentation xml:lang="en">Verification is a boolean expression of conditions.</documentation>
</annotation>
</element>
<element name="Comparison" type="xtce:ComparisonType">
<annotation>
<documentation xml:lang="en">Verification is a single comparison.</documentation>
</annotation>
</element>
</choice>
<choice>
<element name="CheckWindow" type="xtce:CheckWindowType">
<annotation>
<documentation xml:lang="en">Define a time window for checking for verification.</documentation>
</annotation>
</element>
<element name="CheckWindowAlgorithms" type="xtce:CheckWindowAlgorithmsType">
<annotation>
<documentation xml:lang="en">Define a time window algorithmically for verification.</documentation>
</annotation>
</element>
</choice>
<element name="ArgumentRestrictionList" type="xtce:ArgumentAssignmentListType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Optional list of argument values that manifest this post-transmission validation parameter value check. When not present, this check applies to all instances of the command.</documentation>
</annotation>
</element>
</sequence>
</extension>
</complexContent>
</complexType>

Another schema type named "ParameterToSetType" is visited with an addition of a new element that leverages the second new schema type above. The before and after schema type are:

before change:

<complexType name="ParameterToSetType">
<annotation>
<documentation xml:lang="en">Sets a Parameter to a new value (either from a derivation or explicitly) after the command has been verified (all verifications have passed).</documentation>
<appinfo>Value type must match Parameter type.</appinfo>
</annotation>
<complexContent>
<extension base="xtce:ParameterRefType">
<choice>
<element name="Derivation" type="xtce:MathOperationType">
<annotation>
<documentation xml:lang="en">Specify a MathOperation to use to set the Parameter value. See MathOperationType.</documentation>
</annotation>
</element>
<element name="NewValue" type="string">
<annotation>
<documentation xml:lang="en">Specify value as a string compliant with the XML schema (xs) type specified for each XTCE type: integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean; binary=xs:hexBinary; enum=xs:string from EnumerationList; relative time= xs:duration; absolute time=xs:dateTime. Supplied value must be within the ValidRange specified for the Parameter and appropriate for the type.</documentation>
</annotation>
</element>
</choice>
<attribute name="setOnVerification" type="xtce:VerifierEnumerationType" default="complete">
<annotation>
<documentation xml:lang="en">This attribute provides more specific control over when the Parameter value is set. By default, it is when the command have all verifications complete. See VerifierEnumerationType.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>

After the change, the "Derivation" element has a new type definition and updated documentation:

<complexType name="ParameterToSetType">
<annotation>
<documentation xml:lang="en">Sets a Parameter to a new value (either from a derivation or explicitly) after the command has been verified (all verifications have passed).</documentation>
<appinfo>Value type must match Parameter type.</appinfo>
</annotation>
<complexContent>
<extension base="xtce:ParameterRefType">
<choice>
<element name="Derivation" type="xtce:ArgumentMathOperationType">
<annotation>
<documentation xml:lang="en">Specify a simple algorithm to use to set the target Parameter value. See ArgumentMathOperationType.</documentation>
</annotation>
</element>
<element name="NewValue" type="string">
<annotation>
<documentation xml:lang="en">Specify value as a string compliant with the XML schema (xs) type specified for each XTCE type: integer=xs:integer; float=xs:double; string=xs:string; boolean=xs:boolean; binary=xs:hexBinary; enum=xs:string from EnumerationList; relative time= xs:duration; absolute time=xs:dateTime. Supplied value must be within the ValidRange specified for the Parameter and appropriate for the type.</documentation>
</annotation>
</element>
</choice>
<attribute name="setOnVerification" type="xtce:VerifierEnumerationType" default="complete">
<annotation>
<documentation xml:lang="en">This attribute provides more specific control over when the Parameter value is set. By default, it is when the command have all verifications complete. See VerifierEnumerationType.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>

The new "ArgumentRestrictionListType" is used now again to enhance the "TransmissionConstraintType", in addition to the usage in "CommandVerifierType" above.

Previous type definition:

<complexType name="TransmissionConstraintType">
<annotation>
<documentation xml:lang="en">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.</documentation>
</annotation>
<complexContent>
<extension base="xtce:MatchCriteriaType">
<attribute name="timeOut" type="xtce:RelativeTimeType">
<annotation>
<documentation xml:lang="en">Pause during timeOut, fail when the timeout passes</documentation>
</annotation>
<!-- removed for CASTOR: default="PT0S" -->
</attribute>
<attribute name="suspendable" type="boolean" default="false">
<annotation>
<documentation xml:lang="en">Indicates whether the constraints for a Command may be suspended.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>

New type definition with the addition of the sequence of element for "ArgumentRestrictionList":

<complexType name="TransmissionConstraintType">
<annotation>
<documentation xml:lang="en">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.</documentation>
</annotation>
<complexContent>
<extension base="xtce:MatchCriteriaType">
<sequence>
<element name="ArgumentRestrictionList" type="xtce:ArgumentAssignmentListType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Optional list of argument values that manifest this pre-transmission constraint parameter value check.</documentation>
</annotation>
</element>
</sequence>
<attribute name="timeOut" type="xtce:RelativeTimeType">
<annotation>
<documentation xml:lang="en">Pause during timeOut, fail when the timeout passes</documentation>
</annotation>
<!-- removed for CASTOR: default="PT0S" -->
</attribute>
<attribute name="suspendable" type="boolean" default="false">
<annotation>
<documentation xml:lang="en">Indicates whether the constraints for a Command may be suspended.</documentation>
</annotation>
</attribute>
</extension>
</complexContent>
</complexType>

After this, an enhancement to the documentation for the "TransmissionConstraint" element appears to be useful. Only the documentation is added in "TransmissionConstraintListType":

Before:

<complexType name="TransmissionConstraintListType">
<annotation>
<documentation xml:lang="en">Appended to the TramsmissionConstraint List of the base command. Constraints are checked in order. </documentation>
</annotation>
<sequence>
<element name="TransmissionConstraint" type="xtce:TransmissionConstraintType" maxOccurs="unbounded"/>
</sequence>
</complexType>

After:

<complexType name="TransmissionConstraintListType">
<annotation>
<documentation xml:lang="en">Appended to the TramsmissionConstraint List of the base command. Constraints are checked in order. </documentation>
</annotation>
<sequence>
<element name="TransmissionConstraint" type="xtce:TransmissionConstraintType" maxOccurs="unbounded">
<annotation>
<documentation xml:lang="en">A constraint that potentially blocks transmission of this command based on parameter values for all instances or optionally limited to only when specified argument values are used in the command.</documentation>
</annotation>
</element>
</sequence>
</complexType>

Proceeding forward, an update to the annotation for the "AcceptedVerifierType" is made to improve reader clarity.

Previous type definition (only change is in the documentation element):

<complexType name="AcceptedVerifierType">
<annotation>
<documentation xml:lang="en">A verifier that means the SpaceSystem has accepted the command</documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType"/>
</complexContent>
</complexType>

New definition:

<complexType name="AcceptedVerifierType">
<annotation>
<documentation xml:lang="en">A verifier that means the destination has accepted the command.</documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType"/>
</complexContent>
</complexType>

The the type definition for "CompleteVerifierType" needs some enhancement because the new restrictions slightly change the behavior when they are present.

Previous type definition (only change is in the documentation element):

<complexType name="CompleteVerifierType">
<annotation>
<documentation xml:lang="en">A possible set of verifiers that all must be true for the command be considered completed. </documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType">
<sequence minOccurs="0">
<element name="ReturnParmRef" type="xtce:ParameterRefType"/>
</sequence>
</extension>
</complexContent>
</complexType>

New definition:

<complexType name="CompleteVerifierType">
<annotation>
<documentation xml:lang="en">A possible set of verifiers that all must be true for the command be considered completed. Consider that some may not participate due to argument value restriction, if that element is used.</documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType">
<sequence minOccurs="0">
<element name="ReturnParmRef" type="xtce:ParameterRefType"/>
</sequence>
</extension>
</complexContent>
</complexType>

An update to the annotation for the "QueuedVerifierType" is made to improve reader clarity.

Previous type definition (only change is in the documentation element):

<complexType name="QueuedVerifierType">
<annotation>
<documentation xml:lang="en">A verifer that means the command is scheduled for execution by the SpaceSystem.</documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType"/>
</complexContent>
</complexType>

New definition:

<complexType name="QueuedVerifierType">
<annotation>
<documentation xml:lang="en">A verifer that means the command is scheduled for execution by the destination.</documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType"/>
</complexContent>
</complexType>

An update to the annotation for the "ReceivedVerifierType" is made to improve reader clarity.

Previous type definition (only change is in the documentation element):

<complexType name="ReceivedVerifierType">
<annotation>
<documentation xml:lang="en">A verifier that simply means the SpaceSystem has received the command.</documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType"/>
</complexContent>
</complexType>

New definition:

<complexType name="ReceivedVerifierType">
<annotation>
<documentation xml:lang="en">A verifier that simply means the destination has received the command.</documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType"/>
</complexContent>
</complexType>

An update to the annotation for the "SentFromRangeVerifierType" is made to improve reader clarity.

Previous type definition (only change is in the documentation element):

<complexType name="SentFromRangeVerifierType">
<annotation>
<documentation xml:lang="en">Sent from range means the command has been transmitted to the spacecraft by the network that connects the ground system to the spacecraft. Obviously, this verifier must come from something other than the spacecraft. </documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType"/>
</complexContent>
</complexType>

New definition:

<complexType name="SentFromRangeVerifierType">
<annotation>
<documentation xml:lang="en">Sent from range means the command has been transmitted to the spacecraft by the network that connects the ground system to the spacecraft. Typically, this verifier would come from something other than the spacecraft, such as a modem or front end processor.</documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType"/>
</complexContent>
</complexType>

An update to the annotation for the "TransferredToRangeVerifierType" is made to improve reader clarity.

Previous type definition (only change is in the documentation element):

<complexType name="TransferredToRangeVerifierType">
<annotation>
<documentation xml:lang="en">Transferred to range means the command has been received to the network that connects the ground system to the spacecraft. Obviously, this verifier must come from something other than the spacecraft.</documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType"/>
</complexContent>
</complexType>

New definition:

<complexType name="TransferredToRangeVerifierType">
<annotation>
<documentation xml:lang="en">Transferred to range means the command has been received to the network that connects the ground system to the spacecraft. Typically, this verifier would come from something other than the spacecraft, such as a modem or front end processor.</documentation>
</annotation>
<complexContent>
<extension base="xtce:CommandVerifierType"/>
</complexContent>
</complexType>

Once updating the documentation in the type definitions above, the elements themselves would be improved by adding their annotations in the "VerifierSetType".

Before:

<complexType name="VerifierSetType">
<annotation>
<documentation xml:lang="en">Describe a collection of unordered verifiers. A command verifier is a conditional check on the telemetry from a SpaceSystem that that provides positive indication on the processing state of a command. There are eight different verifiers each associated with different states in command processing: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple "complete" and "execution" verifiers. If the MetaCommand is part of an inheritance relation (BaseMetaCommand), the "complete" and "execution" verifier sets are appended to any defined in the parent MetaCommand. All others will override a verifier defined in a BaseMetaCommand. Duplicate verifiers in the list of CompleteVerifiers and ExecutionVerifiers before and after appending to the verifiers in BaseMetaCommand should be avoided. See MetaCommandType and BaseMetaCommandType for additional information.</documentation>
</annotation>
<sequence>
<element name="TransferredToRangeVerifier" type="xtce:TransferredToRangeVerifierType" minOccurs="0"/>
<element name="SentFromRangeVerifier" type="xtce:SentFromRangeVerifierType" minOccurs="0"/>
<element name="ReceivedVerifier" type="xtce:ReceivedVerifierType" minOccurs="0"/>
<element name="AcceptedVerifier" type="xtce:AcceptedVerifierType" minOccurs="0"/>
<element name="QueuedVerifier" type="xtce:QueuedVerifierType" minOccurs="0"/>
<element name="ExecutionVerifier" type="xtce:ExecutionVerifierType" minOccurs="0" maxOccurs="unbounded"/>
<element name="CompleteVerifier" type="xtce:CompleteVerifierType" minOccurs="0" maxOccurs="unbounded"/>
<element name="FailedVerifier" type="xtce:FailedVerifierType" minOccurs="0"/>
</sequence>
</complexType>

After:

<complexType name="VerifierSetType">
<annotation>
<documentation xml:lang="en">Describe a collection of unordered verifiers. A command verifier is a conditional check on the telemetry from a SpaceSystem that that provides positive indication on the processing state of a command. There are eight different verifiers each associated with different states in command processing: TransferredToRange, TransferredFromRange, Received, Accepted, Queued, Execution, Complete, and Failed. There may be multiple "complete" and "execution" verifiers. If the MetaCommand is part of an inheritance relation (BaseMetaCommand), the "complete" and "execution" verifier sets are appended to any defined in the parent MetaCommand. All others will override a verifier defined in a BaseMetaCommand. Duplicate verifiers in the list of CompleteVerifiers and ExecutionVerifiers before and after appending to the verifiers in BaseMetaCommand should be avoided. See MetaCommandType and BaseMetaCommandType for additional information.</documentation>
</annotation>
<sequence>
<element name="TransferredToRangeVerifier" type="xtce:TransferredToRangeVerifierType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Transferred to range means the command has been received to the network that connects the ground system to the spacecraft. Typically, this verifier would come from something other than the spacecraft, such as a modem or front end processor.</documentation>
</annotation>
</element>
<element name="SentFromRangeVerifier" type="xtce:SentFromRangeVerifierType" minOccurs="0">
<annotation>
<documentation xml:lang="en">Sent from range means the command has been transmitted to the spacecraft by the network that connects the ground system to the spacecraft. Typically, this verifier would come from something other than the spacecraft, such as a modem or front end processor.</documentation>
</annotation>
</element>
<element name="ReceivedVerifier" type="xtce:ReceivedVerifierType" minOccurs="0">
<annotation>
<documentation xml:lang="en">A verifier that simply means the destination has received the command.</documentation>
</annotation>
</element>
<element name="AcceptedVerifier" type="xtce:AcceptedVerifierType" minOccurs="0">
<annotation>
<documentation xml:lang="en">A verifier that means the destination has accepted the command.</documentation>
</annotation>
</element>
<element name="QueuedVerifier" type="xtce:QueuedVerifierType" minOccurs="0">
<annotation>
<documentation xml:lang="en">A verifer that means the command is scheduled for execution by the destination.</documentation>
</annotation>
</element>
<element name="ExecutionVerifier" type="xtce:ExecutionVerifierType" minOccurs="0" maxOccurs="unbounded">
<annotation>
<documentation xml:lang="en">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.</documentation>
</annotation>
</element>
<element name="CompleteVerifier" type="xtce:CompleteVerifierType" minOccurs="0" maxOccurs="unbounded">
<annotation>
<documentation xml:lang="en">A possible set of verifiers that all must be true for the command be considered completed. Consider that some may not participate due to argument value restriction, if that element is used.</documentation>
</annotation>
</element>
<element name="FailedVerifier" type="xtce:FailedVerifierType" minOccurs="0">
<annotation>
<documentation xml:lang="en">When true, indicates that the command failed. timeToWait is how long to wait for the FailedVerifier to test true.</documentation>
</annotation>
</element>
</sequence>
</complexType>