4130.1 The SMOC will provide the capability to support two-way
communications through NISN with the DSN. Details of the support
requirements and data transfer formats for this interface are provided in
the ICD Between JPL and GSFC for Missions Using the DSN.
4130.2 The SMOC shall support two-way data and voice
communications through NISN with the DSN network.
Response: Requirements will be met
4131.1 Planning Sources: The following sources will provide inputs
for the SMOC planning capability.
4131.1.1 The SwRI will provide a consolidated science activity plan to the
SMOC at least five working days prior to load.
4131.1.2 The DSN will provide IMAGE spacecraft schedule contact
information.
4131.2 Planning Capabilities: The SMOC will contain the following
planning capabilities:
4131.2.1 Absolute and relative time management.
4131.2.2 The SMOC will validate the science plan against the database.
4131.2.3 DSN Scheduling
4131.3 Planning Products: The SMOC will produce the following
planning products:
4131.3.1 Predicted ephemeris (3 week)
Response: Requirements will be met
4140.1 The SMOC Command Management System (CMS) shall provide the
following capabilities:
4140.1.1 Maintain SCU ground reference image
4140.1.2 Accept planning products
4140.1.3 Accept command inputs from SwRI
4140.1.4 Create, edit, generate, and delete SCU loads
4140.1.5 Generate reports
4140.1.6 Record all transmitted commands
Response: Requirements will be met
4143.1 The SMOC shall provide a mechanism to construct any
real-time command packet by specifying the bit pattern of the complete
command packet in hexadecimal.
4143.2 The SMOC shall provide a mechanism to construct any
real-time command transfer frame by specifying the bit pattern of the
complete command transfer frame in hexadecimal.
4143.3 The SMOC shall provide a mechanism to construct real-time
commands from operator specified mnemonics that are predefined in the
command database.
4143.4 The SMOC shall provide the capability to uplink processor
loads that are stored as named files on the system. These loads include
memory loads, table loads, and stored command processor loads.
4143.5 Processor dumps may be commanded mnemonically. The SMOC
shall provide the capability to compare the dump results to the
corresponding load files.
4143.6 The SMOC shall provide the ability to edit the contents of
the load or dump image and then to reload the edited image.
4143.7 The SMOC shall be capable of maintaining multiple versions
of each load image in order to support multiple flight configurations and
testing scenarios.
4143.8 The SMOC shall be able to define tables in RDL and display
the contents on telemetry pages or from STOL.
4143.9 The SMOC shall provide the user with the following
processor support tools through the language:
4143.9.1 Print the contents of any load or dump image.
4143.9.2 Compare the contents of any load image with its dump image.
4143.10 The SMOC shall support commanding in a "lights out" (unattended) state.
Response: Requirements will be met.
4143.11 LMMS will provide an emergency backup manual command generation
capability which can be used if the primary ground system is not
functional during launch site operations.
4143.12 A stand-alone manual capability shall be provided at the umbilical
console.
4143.13 The manual command generator shall be capable of issuing predefined
command sequences, issuing commands generated interactively in the "raw"
format, and controlling the characteristics of the command uplink interface
(such as bit rate, encoding scheme, etc.).
Note: The FEDS shall be capable of functioning as a manual command
generator.
Response: TBR
4144.1 The SMOC CMS shall provide the following:
4144.1.1 Maintain SCU ground reference image
4144.1.2 Accept planning products
4144.1.3 Accept command inputs from SwRI
4144.1.4 Create, edit, generate and delete command loads
4144.1.5 Provide SCU loads for uplink to the spacecraft
4144.1.6 Generate reports
4144.2 The SMOC CMS shall provide the capability to ingest the
command database.
4144.3 The SMOC CMS shall provide the capability to display a list
of commands in the command database.
4144.4 The SMOC CMS shall generate a command database installation
report that contains information about the installation of a command
database, including any loads or activities affected by the new command
database.
4144.5 The SMOC CMS shall visually identify critical commands in
an activity.
4144.6 The SMOC CMS shall provide the capability to create, edit,
print, and delete sets of command sequences called activities. Each
activity includes:
4144.6.1 A user-defined name
4144.6.2 One to 255 activities/commands
4144.6.3 Zero or more activity parameters
4144.6.4 A nominal assignment of either Absolute Time Sequence (ATS) or
Relative Time Sequence (RTS)
4144.6.5 A text remark
4144.7 The SMOC CMS shall limit RTS capable activities to one RTS
table.
4144.8 The SMOC CMS shall allow the user to print the activity
dictionary.
4144.9 The SMOC CMS shall provide the capability to create, edit,
delete, and print spacecraft events.
4144.10 The SMOC CMS shall create the following event definitions based on
selected planning products:
4144.10.1 Ground station pass
4144.10.2 Eclipse
4144.10.3 South Atlantic Anomaly (SAA) zone crossing
4144.10.4 Apogee
4144.10.5 Perigee
4144.10.6 Ascending node
4144.10.7 Descending node
4144.10.8 Generic duration
4144.11 The SMOC CMS shall allow the user to create vector event
definitions based on electronically received extended precision vector
(EPV) input.
4144.12 The SMOC CMS shall allow the user to select the types of events to
extract from the planning product.
4144.13 The SMOC CMS shall provide the capability to create, edit, print,
and delete triggers. There are two types of triggers:
4144.13.1 Greenwich Mean Time (GMT) triggers: Activities/Commands are
scheduled based on a specific GMT.
4144.13.2 Event triggers: Activities/Commands are scheduled based on times
from a spacecraft event that satisfies the conditions of a trigger.
4144.14 Event trigger logic shall enable the user to specify 1 to 100
conditional tests based on the attributes of the spacecraft event.
4144.15 Each conditional test specified in the event trigger logic must
result in a value of TRUE for the activities/commands to be included in the
activity plan.
4144.16 The SMOC CMS shall allow activities/commands to be scheduled
relative to the spacecraft events start or stop time.
4144.17 The SMOC CMS shall visually identify critical commands or an
activity containing critical commands in a trigger definition.
4144.18 The SMOC CMS shall allow the user to add, edit, and delete
activity/command requests.
4144.19 The SMOC CMS shall electronically ingest external input files.
4144.20 The SMOC CMS shall allow the user to enter only those commands that
are currently defined in the command database.
4144.21 The SMOC CMS shall allow the user to enter only those activity
definitions that are currently defined in the activity dictionary.
4144.22 For variable submnemonics, the SMOC CMS shall allow the user to
enter values in one of the following formats (collectively known as raw
counts):
4144.22.1 Decimal (digits 0 through 9, with optional sign)
4144.22.2 Hexadecimal (digits 0 through F, prefixed with X)
4144.22.3 Octal (digits 0 through 7, prefixed with 0)
4144.22.4 Binary (digits 0 or 1, prefixed with B)
4144.23 For variable submnemonics that are defined as type double-precision
real in the command database, the SMOC CMS shall allow the user to enter
values in EUs as well.
4144.24 The SMOC CMS shall not allow the user to enter a value that is
outside the range defined for the submnemonic in the command database.
4144.25 The SMOC
CMS shall not allow the user to enter numeric input that exceeds the size
of a variable submnemonic field, as defined in the command database.
4144.26 The SMOC CMS shall not allow the user to enter input in EUs that
generate a floating point exception.
4144.27 When a value is provided for a parameter, the SMOC CMS shall not
allow the user to enter a value that is outside the range defined for any
of the variable submnemonics attached to the parameter.
4144.28 When a value is provided for a parameter, the SMOC CMS shall not
allow the value provided to exceed the size of a variable submnemonic
field, as defined in the command for any of the variable submnemonics
attached to the parameter.
4144.29 When a string is specified as the value of a parameter, the SMOC
CMS shall verify that for each of the fixed submnemonic groups attached to
the parameter the string is one of the set of submnemonics defined by the
command database for the fixed submnemonic group.
4144.30 When a submnemonic is chosen for a fixed submnemonic group, the
SMOC CMS shall verify that the submnemonic is valid; that is, it is one of
the set of submnemonics defined by the command database for the fixed
submnemonic group.
4144.31 The SMOC CMS shall generate a validation report for external input
files.
4144.32 The SMOC CMS shall allow the user to select external input files to
be merged into the activity plan during the triggering process.
4144.33 The SMOC CMS shall provide the capability to manually create, edit,
print, and delete constraint definitions.
4144.34 The SMOC CMS shall provide the following types of constraint
definitions:
4144.34.1 Command Sequence Dependencies: If command A is present in a load,
then command C cannot appear in the load until after command B.
4144.34.2 Command Timing Dependencies: If command A is present in the load,
then command B must appear no sooner than the relative time C, and no later
than the relative time D.
4144.34.3 Command Time Delay: If command A is present in the load, then
command B cannot exist in the load any sooner than the relative time C.
4144.35 The SMOC CMS shall provide an activity plan that consists of one or
more activity plan periods.
4144.36 The SMOC CMS shall provide an activity plan period that contains a
planning segment and zero or more loads that have been created for that
period.
4144.37 The SMOC CMS shall allow the user to delete the contents of a
planning segment.
4144.38 The SMOC CMS shall allow the user to delete individual
activities/commands from the planning segment.
4144.39 The SMOC CMS shall allow the user to purge all activity plan
periods whose stop time precedes the current day by the file retention
period definition in the constants file.
4144.40 When activity plan periods are deleted during a purge, the SMOC CMS
shall automatically delete any planning segments associated with the
deleted activity plan period.
4144.41 When activity plan periods are deleted during a purge, the SMOC CMS
shall automatically delete any loads associated with the deleted activity
plan period.
4144.42 When completing a purge, the SMOC CMS shall automatically create
new activity plan periods to be appended to the activity plan so that the
activity plan spans the required number of days.
4144.43 For each activity plan period in the activity plan, the SMOC CMS
shall display the activity plan period's start and stop times.
4144.44 For each activity plan period in the activity plan, the SMOC CMS
shall display the primary command load name and all alternate load names.
4144.45 For the selected load in each activity plan period in the activity
plan, the SMOC CMS shall indicate if the load contains uncorrected errors,
contains manual edits, has been generated, has been transferred, has been
uplinked, and has been patched.
4144.46 For the selected load in each activity plan period in the activity
plan, the SMOC CMS shall display the load's destination, the number of ATS
commands contained in the load, and the size of the load in bytes.
4144.47 The SMOC CMS shall allow the user to set the duration of the
activity plan.
4144.48 The SMOC CMS shall allow the user to delete a load.
4144.49 The SMOC CMS shall require the user to supply an absolute time for
each command/activity added to a planning segment or load.
4144.50 The SMOC CMS shall allow the user to add and/or delete individual
commands/activities to a planning segment or load.
4144.51 The SMOC CMS shall allow the user to modify the time tag and
parameters of an individual command/activity within a planning segment.
4144.52 The SMOC CMS shall not allow an activity to be included in a
planning segment unless values are supplied for all parameters associated
with the activity.
4144.53 The SMOC CMS shall not allow a command to be included in a planning
segment or load unless all of the command's variable submnemonics are
supplied with a value and all of the command's fixed submnemonic groups are
supplied with a fixed submnemonic.
4144.54 The SMOC CMS shall visually identify critical commands/activities
containing critical commands in a planning segment or load.
4144.55 The SMOC CMS shall enable the user to split an activity plan period
by start and stop time, if the period contains no loads.
4144.56 The SMOC CMS shall allow the user to merge neighboring activity
plan periods that contain no loads.
4144.57 The SMOC CMS shall not allow activity plan periods to overlap.
4144.58 The SMOC CMS shall allow the user to slip the activity plan by a
user-provided delta time (+/- HH:MM:SS).
4144.59 When slipping the activity plan, the SMOC CMS shall add the
user-provided delta time to the following:
4144.59.1 The start and stop times associated with each activity plan
period in the activity plan.
4144.59.2 The scheduled execution time for each command (except the update
ephemeris command) and activity contained in the activity plan period's
planning segment.
4144.59.3 The scheduled execution time for each command (except the update
ephemeris command) and activity contained in each of the activity plan
period's loads.
4144.60 When triggering, the SMOC CMS shall update planning segments in all
activity plan periods with the triggered list of activities/commands.
4144.61 The SMOC CMS shall notify the user of all primary and alternate
loads that are out of date with respect to the newly triggered
activities/commands. A load is considered out of date if the newly
triggered activities/commands that are replacing the contents of the
planning segment, associated with the load, are not identical to the
triggered activities/commands currently contained in the load.
4144.62 Before triggering new activity/command input into the activity
plan, the SMOC CMS shall ensure that all previously triggered
activities/commands shall be removed from the planning segments.
4144.63 The SMOC CMS shall allow the user to designate a load to be either
prime or alternate.
4144.64 The SMOC CMS shall not allow more than one primary load in any
activity plan period.
4144.65 The SMOC CMS shall allow zero or more alternate loads in any
activity plan period.
4144.66 The SMOC CMS shall do continuity management only for prime loads.
4144.66.1 Continuity Management: While demoting a load, if the load has any
commands falling into the next period as a result of expanding ATS
activities in this load, the SMOC CMS shall include them in the next
period's free segment and issue warning messages to the user.
4144.66.2 Continuity Management: While demoting a load, the SMOC CMS shall
release the RTS tables set aside for this load's RTS usage.
4144.66.3 Continuity Management: While promoting a load, the SMOC CMS shall
verify that there is no conflict in using the RTS tables assigned for
the RTS,s in this load. If a conflict arises, the SMOC CMS shall
issue notifications and shall not promote the load. Otherwise, the
SMOC CMS shall reserve the RTS tables for the current load and promote the
load. A conflict arises when more than one RTS is assigned to and is using the same RTS table.
Response: Requirements will be met.
Author and Curator:
Dr. D.R. Williams, dwilliam@nssdc.gsfc.nasa.gov, +1-301-286-1258