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