Skip to content

Support non load commands and activities natively in kadi

Tom Aldcroft edited this page Jun 10, 2020 · 2 revisions

This is an outline of design ideas for supporting non-load commands and the new concept of an "activity" within the kadi commands package. The goal is to reduce reliance on the legacy Chandra.cmd_states and to allow for load review that conditionally includes a planned activity such as an ACIS CTI.

Current software and process

Currently kadi commands uses the infrastructure in Chandra.cmd_states to provide non-load commands such as:

  • SCS 107 run (SIM translation, ACIS stop science and power down)
  • Transition to normal sun
  • ACIS CTI commanding
  • Maneuver (e.g. to cooling attitude during anomaly recovery)
  • Set obsid

That happens via add_nonload_cmds and hardwired command sets. In this process a separate sqlite3 table is maintained with non-load commands.

When there are new non-load commands, typically from a safing action or ACIS long CTI CAP, then an aspect team member (normally Jean) runs commands from the linux command line to put commands into the database. There is a script which checks for SCS-107 and sends an email with suggested commands. See the appendix below for details, but the process is fairly involved.

Kadi commands processing checks the cmd_states non-load commands table and ingests any new commands into its own commands archive (maintained primarily as an HDF5 file), setting the timeline_id to 0 to indicate that commands are non-load. Recall that timeline_id is the identifier for a unique segment of a command load that has been approved for uplink.

Near-term proposal

Interrupting loads and adding (non-load) activities

The first component of the plan for kadi is to allow updating non-load commands directly from a command-line tool in kadi. This introduces the activity nomenclature to somewhat replace non-load commands.

kadi_interrupt_loads --date ${scs107time} [--observing-only]  # Uses `Chandra.cmd_states` to do this
kadi_add_activity --date ${scs107time} --activity scs107

Note the inclusion of the option to interrupt the timelines from this interface, which will replace the current call to:

/proj/sot/ska/bin/python ./add_nonload_cmds.py --dbi sqlite \
                              --server /proj/sot/ska/data/cmd_states/cmd_states.db3 \
                              --date ${scs107time} \
                              --cmd-set scs107 --interrupt \
                              --observing-only \
                              --archive-file /tmp/not_used.py

All support for sybase command states / timelines databases will be dropped

Using and filtering activities in load review

The command archive will include a new concept of an activity which can be associated with non-load commands. Examples include: scs107, maneuver, cti_24hr. This is user-specifiable via an --activity command-line option and can be any unique string.

The activity will be stored as a parameter in each of the corresponding non-load commands that get stored in the archive.

Some provision will be made for adding an arbitrary set of commands from an RTS-like file that includes commands and relative time offsets from the specified activity date.

The primary purpose of the activity will be to allow excluding the activity in determining commanded states. The get_cmds and get_states functions will include a new argument exclude_activities which accepts a string or list of strings to indicate activities to exclude from consideration. This can be mapped to a load review command-line option --exclude-activities which accepts a comma-delimited list of activities to exclude.

Procedurally, an activity would be added as soon as it becomes a possibility, for instance at the time an ACIS CTI CAP is approved (or even somewhat before since it is extremely unusual for such a CAP to get disapproved).

If an activity gets canceled or needs update for some reason, then do:

kadi_remove_activity --start <start> [--stop <stop>] --activity <activity>

Long-term proposal: automatic activities

It is reasonably straightforward to watch telemetry from MAUDE and infer most safing-action activities from telemetry. This will typically be available in MAUDE within 2-3 hours of detecting an anomaly, and frequently sooner.

Getting this all done in a rock-solid reliable manner will require a bit of effort but is certainly possible and worth the effort.

At some point it will also be possible within MAUDE to get access to on-console commanding. This might allow detection of command loads that have been uplinked, which would then get mapped to an available activity which adds the corresponding commands to the kadi command archive. This can work for ACIS CTIs for instance.

Appendix: responding to a safing action

Procedure:
-----

# Check for the presence of the disarm file.  If already there and
# the date / owner implies someone else is doing the update then stop.
ls -l /proj/sot/ska/data/scs107/disarm

# Disable further SCS107 reminders and check ownership:
touch /proj/sot/ska/data/scs107/disarm
chgrp aspect /proj/sot/ska/data/scs107/disarm
chmod g+w /proj/sot/ska/data/scs107/disarm
ls -l /proj/sot/ska/data/scs107/disarm

# Check for heart attack on timelines cron task
# if it exists, don't proceed with this process until that
# is understood
ls -l /proj/sot/ska/data/timelines/task_sched_heart_attack

# Stop timelines cron task
touch /proj/sot/ska/data/timelines/task_sched_heart_attack

# Backup the flight databases
cd /proj/sot/ska/data/sybase_backup
./dump_cmd_tables.sh

# You can also make a backup of the cmd_states sqlite3 table in
# /proj/sot/ska/data/cmd_states/cmd_states.db3
# but this is backed-up via snapshot anyway

# clone the cmd_states project from either github or clone in ~/git
# (if cloning from ~/git, make sure you're working from an updated clone)
mkdir /pool1/scs107
cd /pool1/scs107
git clone [email protected]:sot/cmd_states.git
cd cmd_states

# confirm that the nonload_cmds_archive.py is aspect writeable
chgrp aspect nonload_cmds_archive.py
chmod g+w nonload_cmds_archive.py

# Set the SCS107 time (from telecon email report) as a variable
# example: setenv scs107time '2011:158:15:23:10.000'
# (use of 'setenv' below expects tcsh)
setenv scs107time '<SCS107 time>'

# change to aca user
su aca

# Run add_nonload_cmds.py.  If only observing loads should be interrupted,
# use --observing-only flag as demonstrated below.

/proj/sot/ska/bin/python ./add_nonload_cmds.py --dbi sybase --server sybase \
                              --user aca_ops --database aca \
                              --date ${scs107time} \
                              --cmd-set scs107 --interrupt \
                              --observing-only \
                              --archive-file nonload_cmds_archive.py

# Add the cmds to the sqlite version of the table too, but don't archive again to
# nonload_cmds_archive.py.  Set a bogus/not_used file instead for that operation.

/proj/sot/ska/bin/python ./add_nonload_cmds.py --dbi sqlite \
                              --server /proj/sot/ska/data/cmd_states/cmd_states.db3 \
                              --date ${scs107time} \
                              --cmd-set scs107 --interrupt \
                              --observing-only \
                              --archive-file /tmp/not_used.py

# stop working as aca
<CTRL>-d

# Commit the changes to nonload_cmds_archive.py
git commit nonload_cmds_archive.py \
   -m "Update nonload cmds for SCS107 at ${scs107time}"
git push origin

# Remove timelines heart attack
rm /proj/sot/ska/data/timelines/task_sched_heart_attack

# Get out of the /pool1/scs107 directory
cd

# Delete the cmd_states clone
rm -rf /pool1/scs107

-----
End Procedure