Astrobee Facility Sustaining Overview.pdf

Astrobee Facility Sustaining Overview

NOT EXPORT CONTROLLED

This publication does not contain information which falls under the purview of the U.S. Munitions List (USML), as defined in the International Traffic in Arms Regulations (ITAR), 22 CFR 120-130, and is not export controlled. This publication does not contain information within the purview of the Export Administration Regulation (EAR), 15 CFR 730-774, and is not export controlled. This publication is not intended for distribution outside of the NASA and International Partner communities. Release to the public requires approval through the appropriate NASA Release Process (e.g., FOIA, NASA STI, etc.).

Non-Technical Data – See Control Statement on front page.

Contents Introduction

Hardware Maintenance

Hardware On Orbit

Hardware on the Ground

Labs

Granite Lab

Description

Use

Sustainer Tasks

Flight Lab

Description

Use

Sustainer Tasks

Description

Use

Sustainer Tasks

Computer Resources

Description

Use

Sustainer Tasks

Description

Use

Sustainer Tasks

Software Maintenance

Simulator

Astrobee Robot Software (aka ARS, Flight Software, FSW)

GDS (aka Astrobee Workbench, GUI)

Data pipeline and data management software

TReK

3rd party DDS software

Firmware and embedded Astrobee software

Localization Pipeline

Operating System Updates

Licensing

Configuration management

Operations

User Community

System documentation updates

Technical Interchange meetings

Conferences

Public Outreach

Ops Planning

ConOps

ISS planning, scheduling, and flight products

ISS activity rehearsal

Software Support

Safety and Verification Support

Safety Support

Verification and Testing Support

Astrobee Battery Certification Support

Guest Scientist Software Testing Support

Lab Support

Ops Execution

Robot Operator

Command Line Operator

Crew Communicator

After Ops Execution

Introduction This document provides an overview of the tasks that the Astrobee Facility performs to sustain the Astrobee system. The Astrobee Facility in general includes the people (astrobee team), the hardware, and the labs. This document will use Astrobee Sustainer or The Sustainer to indicate the people who are currently performing the sustaining function.

Hardware Maintenance Hardware On Orbit The on-orbit hardware consists of the Dock, 3 Freeflyers, 23 batteries, 3 perching arms, 1 port tester, and 1 SD card. The Sustainer reviews on-orbit data for performance compared to table 1 in the Guest Science Guide. The Sustainer maintains spares for the on-orbit and ground hardware. There are enough spare parts for refurbishment of 3 full astrobee units, with additional spares for some components. The Sustainer writes procedures for repair and refurbishment of on-orbit hardware when a failure occurs and supports crew sessions where repairs are performed. The Sustainer tracks on-orbit inventory of spares and on-orbit replaceable units (ORUs), such as the perching arms and batteries. When the decision is made to return on-orbit hardware to the ground, the Sustainer writes and executes procedures for repair and refurbishment in collaboration with quality assurance (QA). Over the last 5 years of operation, the dock has been repaired on-orbit 2 times, and astrobees have been returned for repair 2 times.

Hardware on the Ground The ground hardware consists of the following:

● 3 Freeflyers o 1 Freeflyer (Flight spare) at Johnson Space Center (JSC) mainly used for

JSL and EMI testing as needed o 2 Freeflyers (Non-Flight) at Ames, installed in the granite lab, used for facility software maintenance and update testing (see software list below), user software, hardware and co-ops testing, hardware-in-the-loop testing, rehearsal and readiness testing.

● Batteries o 15 batteries (14 Flight spares, 1 non-flight) at JSC mainly used for JSL and EMI testing as needed o 29 batteries (Non-Flight, GFE) at Ames used for powering the freeflyers in the lab, extras to charge on stand-alone chargers for swapping into the Astrobees as needed.

● Battery chargers o 2 at JSC (Flight spares) mainly used for JSL and EMI testing as needed o 2 at Ames (Non-Flight) used for charging lab batteries

● Perching arms.

o 1 at JSC (Flight spare) used for checkout o 2 at Ames (Non-Flight) used for checkout

● 2 Docks o 1 Dock at JSC (Flight spare) mainly used for JSL and EMI testing as needed o 1 Dock at Ames (Non-Flight), installed in the granite lab, used for testing with and charging the Astrobees in the lab

● Port Tester o 1 at Ames (Non-Flight), used for checkout and debug

● 1 flat-sat (Non-Flight) o This is a minimal unit consisting of the full avionics stack, 1 touch screen, and 2 payload connectors.

o At Ames, used for fit check and initial software and hardware testing when new design or problems might cause harm to the Astrobee freeflyers

● Test and support equipment o A9SP-1500-M947 – Free Flyer Acoustic Test Stand, at JSC (Non-Flight)

The Sustainer also manages storage of the non-flight units and flight spares.

Labs Granite Lab

Description The Granite Lab is a 2-D testbed where the ground Astrobees can be operated. It utilizes Air Carriage consisting of structure, 3 air bearings, 2 liquid CO2 canisters, 1 regulator, and associated tubing. The Astrobees connect to the Air Carriage, which provide low-friction motion in the X-Y plane. The Astrobee propulsion is strong enough to move the Astrobees and air-bearing structure.

A mock-up of posters with representative images of ISS racks and adjustable LED lighting are installed to produce a similar visual environment to that seen on ISS. This lab also has a network connection to an ISS router that can be connected to the Huntsville Operations Support Center network upon request for end-to-end testing. This is where the two Astrobee ground units and one Astrobee dock are kept at Ames.

Use The Granite Lab is the highest fidelity testing available. Used for testing full hardware and software in the loop, both for Astrobee Software testing, as well as payload testing. It is required that Guest Scientists test in the lab on flight hardware prior to launch and with flight software prior to each on-orbit activity.

Sustainer Tasks The Sustainer tasks in the Granite lab include:

● Maintaining lab safety documentation

● Ordering filled liquid CO2 DOT bottle with dip-tube

● Filling smaller bottles from the liquid

CO2 DOT bottle with dip-tube

● Fixing leaks in the Air Carriage

● Replacing the air bearings as needed

● Charging and replacement of Astrobee backup batteries, as needed

● Cleaning the air bearing table

● Setup and operation of lights and any physical changes to the mock-up

● Orientation changes. For example, astrobee can be mounted in the +Y or - Y up orientation, as in the photo to the right.

● Attaching to mockups

● Attaching payload hardware. For example, REACCH hardware can be seen mounted to the Astrobee in the photo to the right.

Flight Lab

Description The Flight Lab is a secure lab with locking doors, ESD benches, storage, and tools. It also has close proximity to Ames testing labs, which makes for easier transfers when testing is needed.

Use This is used for disassembly, repair and reassembly of Astrobee Units and reassembly.

This is where the Astrobee ground units are repaired, and the flight units that have come back for repair.

Sustainer Tasks The Sustainer tasks in the Flight lab include:

● Maintaining lab safety documentation

● Maintaining ESD certification

● Updating tool and equipment calibrations as needed

Photo Courtesy of Kall Morris Inc (KMI), REACCH 2024 Flight Demonstrator

Operations Lab

Description The operations lab is a common computer space with four computers, two monitors per computer, and a large, shared monitor. These computers run Windows and are primarily used for supporting ISS on-orbit activities.

Use This lab is used for operations, allowing good situational awareness for Astrobee operations and co-location for better communication.

Sustainer Tasks The Sustainer tasks in the Flight lab include:

● Basic computer maintenance

● Identification and installation of required Huntsville Operations Support Center

(HOSC) software and Astrobee specific software

Computer Resources In addition to the computers in the granite and operations labs, there are other computers that support the Astrobee operations. They are dds1, dds2, and hivemind.

DDS1 and DDS2

Description DDS1 and DDS2 are linux computers that are physically located at the HOSC and are the main systems that communicate directly with the Astrobees on ISS. These computers are supported by a unique support contract with the Ames MMOC for system management and updates.

Use They are redundant systems to allow system and software updates to be applied without interrupting the ability to operate ISS sessions. They also act as backups for each other during operations. They run HOSC HPEG processes which allow communication to be established to the Astrobees for things such as ssh, file upload, telemetry, command and control. They run a DDS relay server, which connects to the Astrobees, and which allows multiple client connections from both facility and guest scientist computers to be able to see and control the Astrobees. The HOSC also maintains firewall rules to limit which users (Sustainer and Guest Scientists) have access to which services and ports, which limits who can access Astrobee Imagery during Live Stream. This is a requirement of the ISS Imagery Working Group to limit real-time imagery to only the core Astrobee operations

Sustainer. Locating the computers at the HOSC allows Guest Scientists, in particular non- NASA users, to connect to the relay servers from their location while maintaining security.

Sustainer Tasks The Sustainer tasks in the Flight lab include:

● Basic computer maintenance

● Identification of required HOSC software and Astrobee specific software

● Coordination with system administrators for software installation and updates

● Coordination with HOSC for firewall updates. The firewall controls the purple and green connections in the diagrams to the right.

● Data management

● Network configuration management. See diagrams to the right

Hivemind

Description Hivemind is a Linux server that complies with NASA IT policies, has a large amount of data storage, and allows a web-interface for Guest Scientists to download data.

Use This system is used for the storage, post-processing of data, and dissemination of data once review is completed by the JSC imagery team of any imagery. Post-processing data includes recombining data recordings that were automatically split by the data recorder, fixing of ROS message headers, and extraction of images. The images are then provided via hivemind to JSC’s Building 8 for review prior to being distributed beyond the Astrobee Sustainer.

Sustainer Tasks The Sustainer tasks in the Flight lab include:

● Basic computer maintenance

● Identification, installation, and updates of Astrobee specific software

● Coordination with system administrators for software installation and updates

● Data management

● Software control and updates

● Manage network configuration

Software Maintenance The Astrobee Sustainer manages and maintains, and when appropriate updates the following software and licenses:

Simulator This is the simulation environment which is primarily used for code development and testing prior to testing on the hardware. It is based on a Linux Virtual Machine (VM) that runs the bulk of the Astrobee Robot Software and a hardware emulator to simulate the behavior of the HLP. It includes instructions for setting up the VM with all the needed software installations. The simulator operates under the same operating system (OS< Ubuntu 20.04) as Astrobee, and when the OS is updated, the OS for the simulator must also be updated and tested. Typically, this is an early step in the process of updating the OS on the Astrobee hardware. The Simulator is also used for early testing of Astrobee Robot Software updates. This software is open source and is primarily updated by Guest Scientists, although updates are reviewed, tested, and accepted by the Astrobee Sustainer.

Astrobee Robot Software (aka ARS, Flight Software, FSW) This is the software which runs on the Astrobee themselves. The software runs on the hardware and is also run when running the Simulator. The software is based on ROS, and incorporates a combination of python, C++, and java code. This software is open source and is primarily updated by Guest Scientists, although updates are reviewed, tested, and accepted by the Astrobee Sustainer.

GDS (aka Astrobee Workbench, GUI) This is the main operator interface, which connects to the Astrobee Relay Server on DDS1 or DDS2 and receives and displays real-time telemetry. It is a command-and-control interface to the Astrobee robots. It has not been updated for some time, although bug fixes and potential improvements have been identified.

Data pipeline and data management software This includes scripts for transferring data, verifying data integrity, post-processing data, verifying and changing file permissions, and deleting files.

TReK This is a HOSC software which enables communication to the Astrobee robots. It is platform independent, although the Astrobee Sustainer principally utilizes it on Linux on the DDS1 and DDS2 servers for establishing connection to the Astrobees.

3rd party DDS software This is a 3rd party DDS software that is the basis for the delay-tolerant Astrobee communication. This is a license which the Astrobee maintains.

Firmware and embedded Astrobee software This is software that runs on the various microcontrollers on the Astrobee (e.g the propulsion module light controller). It is maintained in a repository and is not open source.

It has not been updated since Astrobee was launched, and there is no active development.

Localization Pipeline This includes running crew-minimal sessions to gather mapping data, generating maps from the data, and testing the maps. This also includes making improvements to localization and recovery from lost events. Mapping and localization are done separately due to computing power constraints. Mapping of the JEM is done regularly during what is known as Crew Minimal ISS activities. During these activities, Astrobee robots operate without crew and crew is only required for initial setup and if the robots get stuck among cables or between walls. For mapping activities, the JEM is cleared of stowage and Astrobee lighting is set. An autonomous trajectory is followed by one of the robots while it acquires imaging data. After the on onboard operation, the Sustainer downloads the data (usually in the order of 15-20GB), it gets reviewed by JSC’s Building 8 and once it is approved the Sustainer proceeds with the off-line mapping creation process. The off-line mapping process consists of a Sustainer’s team member going over the imaging data and selecting the portions of the data that will either update the current map or create a new one. This phase of the off-line mapping creation process relies heavily on a series of scripts and tools that makes it faster to finish a new or updated map. Despite these tools, the process is computationally tolling, and it takes between a few hours and a couple of days. Once a candidate map is completed it is tested both in software and in a hardware-in-the-loop simulation at the Granite lab. If it passes all verifications, it is then staged for upload, otherwise the off-line mapping creation process is repeated to improve the map in the areas showing poor performance. Once the candidate map has been approved, an estimated coverage map is created and distributed to Guest Scientists. This coverage map is a three-dimensional heat map that illustrates the areas of the JEM where it is estimated the robots will have a good number of marked landmarks or ML features (e.g. over 15-20 ML) that enable the robots to calculate their pose in real time. The final step is the verification during on board activities and determining if the map provides an appropriate amount of ML features consistent with the three-dimensional coverage heat map. .

Operating System Updates The astrobees run Ubuntu Linux. They were originally launched with Ubuntu 16.04, and recently were upgraded to 20.04. They also utilize ROS 1. The Sustainer implements in hardware, tests and deploys operating system upgrades, and ROS updates.

Licensing The Sustainer maintains licenses for third party software used for Astrobee operations.

Those licenses are Wowza and RTI DDS. Wowza was a one-time purchase and is used for routing of video from the Astrobee SciCam to Building 8 and to the Astrobee ground workstations. Wowza is also responsible for transcoding the SciCam video into a format supported by Building 8. RTI DDS is an RTI implementation of the DDS communication standard and is used for delay tolerant communication between the Astrobees and the relay server and to the GDS workstations. This is a recurring license.

Configuration management The Sustainer manages and approves Astrobee Software pull requests on the open source code repository for the ARS and simulator. These pull requests may be generated by internal developers or guest scientists and may represent bug fixes or feature requests.

The Sustainer manages ground procedures and documentation updates.

Operations The Sustainer also performs operations functions applicable to all Astrobee ISS operations, which include:

● Addressing on-orbit anomalies

● COFR (Certificate of Flight Readiness) certification testing

● Data management

● Data processing

● ISS compatibility testing when changes on either side occur

● Tracking user performance and lessons learned

● Battery tracking and charging

● Mapping and generation of new Astrobee maps

User Community The Sustainer works to support the user community through system documentation updates, technical interchange meetings, conferences and public outreach

System documentation updates System documentation is a combination of the Guest Science Guide and documents in code repositories and confluence. The Guest Scientist Guide is a guest scientist focused compilation of relevant information a guest scientist would need to understand Astrobee and its capabilities and developing hardware and software that interfaces with Astrobee.

Examples of documentation in repositories and confluence include documents from:

Design documents (e.g. electrical, mechanical, conops, etc.), Integration (purchases, integration procedures, QA records), Verification (requirements, verification closures, test results), Safety (PSRP review documents, safety paperwork, safety memos), Ground procedures, and Flight procedures.

Technical Interchange meetings The Sustainer organizes Technical Interchange Meetings (TIMs) twice per year, usually in person, to foster communication and potential collaboration between the various guest scientists using Astrobee. Historically, once per year the meeting is at Ames, once at user facilities as available. During the meeting, guest scientists report on past activities and current status. This meeting is focused on the current Astrobee users and ISS Astrobee related support personnel.

Conferences The Sustainer also attends and presents at conferences relevant to the Astrobee community, such as POIWG, ISSRDC and IAC. Attendance at these conferences is focused on reaching beyond the current Astrobee users to a technical community of potential collaborators and those who would most likely be interested in utilizing Astrobee.

This helps to raise awareness of past activities and current status. It also raises awareness of Astrobee as a platform for future activities.

Public Outreach The Sustainer also conducts tours and participates in interviews and Guest Scientist PAO activities. This is focused on a very broad audience, generally to support public awareness, engagement and enthusiasm for Astrobee.

Ops Planning ConOps The Sustainer works with Guest Scientists to develop the Concept of Operations (conops) of how the ISS Crew will interact with their payload and with Astrobee, how the payload will interact with Astrobee, and how the ground team will interact with the payload and Astrobee. In particular, the payload to Astrobee conops definition includes where software will run (e.g. HLP, MLP, or LLP), how the payload communicates, and whether the payload sends commands to Astrobee or vice-versa. The interactions of the Sustainer and the payload developer for an on-orbit activity are usually assigned as roles and responsibilities, and specific actions are documented in activity-specific ground procedures. The ground procedures are developed by the Sustainer, although Guest Scientists also help develop procedures. The Sustainer conducts crew training as needed.

The current NASA standard for projects like Astrobee is that video training usually suffices for Crew training requirements.

ISS planning, scheduling, and flight products The Sustainer coordinates ISS increment scheduling, providing inputs to the ISS planners for constraints (e.g. black-out dates) and team availability, coordinates resources (e.g. JSC Bldg. 8 VCC Team), and helps coordinate GO/NOGO decisions on schedule changes.

Working closely with Marshall Space Flight Center (MSFC), the Sustainer is also directly responsible for providing inputs for the development of three main flight products: crew procedures, and two planning tools known as the Payload Activity Requirement Document (PARD), and Payload Planning Overview (PPO). Depending on the science, there may be other required flight documents; however, these three flight products are common to all ISS research.

Astrobee science involves two main categories – hardware required, or software only investigations. Particularly if new hardware is required for science, the process of developing crew procedures begins many months before manifest and subsequent launch to the ISS. Working closely with the Guest Scientist Team, the Sustainer will work various crew procedure drafts. Optimal crew procedures involve detailed hardware photos and sometimes short video clips. In addition to crew procedures, in unique cases, OBT (Onboard Training) videos may be required before the crew can handle the hardware. At minimum there are OBT videos (currently already developed) for general Astrobee use, and specific OBT videos are not needed for Guest Science; well written crew procedures usually suffice. At some point in the crew procedure development process the Sustainer will begin to also work in partnership with designated personnel (POISpecialists) at MSFC who are assigned to each payload to polish the crew procedure to final draft using proprietary MSFC software. The eventual goal is to develop final crew procedures that are approved (baselined) by MSFC. From initial draft to baseline, the Sustainer is responsible for crew procedures.

The PARD and PPO are documents used by the MSFC and JSC planning teams that define what ISS activities and resources are needed and when they are needed on the ISS Crew Timeline for each on-orbit activity. Examples of such resources and activities include but are not limited to real-time ISS camera feeds, Astrobee and other ISS hardware needs, data/commanding bandwidth requests, and ISS environment requirements (stowage and lighting etc.). The maintainer of these two planning products is an assigned MSFC person known as the PARC (Payload Activities Requirements Coordinator) with whom the Sustainer will also work closely with on a regular basis.

Although many of the crew procedures and PARD and PPO documents share similar features among all Astrobee ops sessions, each activity requires unique planning inputs.

Once these flight products are baselined, future changes can be made through OCRs and ECRs (Operations and Engineering Change Requests). Software updates are also managed through the OCR system. Working with the POISpecialist and PARC, the Sustainer is responsible for managing OCR/ECR inputs and updates through MSFC throughout the life of the Guest Science research.

ISS activity rehearsal The Facility also supports rehearsals of an activity prior to execution. Referred to as a Paper sims, these rehearsals use crew and ground procedures and are a virtual walk-through of the entire activity. Paper sims do not typically involve hardware, and rehearsals that do involve hardware called Operations Readiness Tests (ORTs) are covered below in the Lab Testing section.

Software Support The Sustainer also supports the Guest Scientist to troubleshoot the Simulator+ARS install and operation. Any bug fixes identified in this process are also addressed. The facility also assists the Guest Scientist in testing code on the hardware, troubleshoots and testing communication to the payload hardware. As needed, the Sustainer also provides familiarization and training on ARS operation and use.

Safety and Verification Support Safety Support The Sustainer provides any required updates to the safety data package for the Astrobee Facility. The Sustainer provides inputs for Guest Scientist PSRP reviews and attends Guest Scientist PSRP reviews to help answer Astrobee Facility related questions. The Sustainer does integrate safety assessments for the PSRP to assess what safety topics are already addressed by Astrobee safety and whether the combined system needs further analysis.

These assessments are communicated to the PSRP via memo prior to Phase 3.

Verification and Testing Support The Sustainer submits integrated verifications to the ISS program for the payload+astrobee combination. The Sustainer also supports Guest Scientist verifications as needed, including making arrangements to have Astrobee hardware available for verification testing (e.g. EMI, acoustics) and operating the hardware for verification testing.

The Sustainer works with JSC Bond, JSC Testing facilities (EMI testing, battery cert testing, etc), and various payload representatives to support testing and checkout at JSC.

The Sustainer works with ISS Testing facilities (located at Ames, Marshall, and JSC) to perform ISS compatibility testing of Astrobee hardware in the JSC Testing facilities when changes on either side occur (e.g. PSIVF testing when JSL WAP changes).

Astrobee Battery Certification Support The Sustainer tracks and when needed updates the certification for the Astrobee Batteries.

Historically this support involves coordinating battering testing with the JSC battery group for testing the batteries at JSC to determine whether an extension for the battery certification can be granted.

Guest Scientist Software Testing Support The Sustainer engages every Guest Scientist in the same way: first a new page is created in the Sustainers database. The Guest Scientist proceeds to create their software which generally consists of an Android Package (APK), a screenshot of their APK passing a virus scan, sha1sum/md5sum values, itemized list of their primary and secondary objectives to accomplish during ground and ISS testing. The Sustainer receives the APK, goes over a series of tests to make sure the code works as intended with the Astrobee hardware/software as well with the Guest Scientist’s hardware (if any). Together with the Guest Scientist, the Sustainer writes the ground and crewed procedures and tests the ground procedure at the granite lab with the Guest Scientist’s code. Upon successful validation, the Guest Scientist’s software is queued for upload to the Astrobees on the ISS and installed prior to the ISS activity. This process is iterative, and several granite lab tests of the ground procedure may be necessary before setting the code for upload to the ISS.

Lab Support The Astrobee Sustainer operates the Astrobee hardware in the lab and sets up the environment. Setting up the environment includes mounting any Guest Scientist hardware in the environment, configuring lights, configuring air carriages, replacing CO2 bottles as need. The Sustainer performs a fit check with Guest Scientist hardware on the flat-sat prior to mounting hardware on the Astrobee units. The Sustainer also assists in troubleshooting hardware and software issues in the lab. The Sustainer creates lab procedures, covering setup, operation of the test, and tear-down. The Sustainer conducts Operational Readiness testing, which is a rehearsal including all planning products (discussed in a previous section), software running on the astrobee hardware, and guest scientist hardware. These ORTs also exercise the actual commands that will be executed and can even include flight-like data paths as appropriate. Flight-like data paths are for end-to-end testing, which can connect the Astrobee hardware in the Granite Lab via a MSFC RAPTR and a router at Ames to the HOSC network and DDS1 and DDS2 and allows Guest Scientists to connect to DDS1 and DDS2 and thereby connect to the lab hardware.

The flight-like paths can also be configured, via arrangement to with the JSL/PSIVF team, to the JSL lab at JSC for connecting to flight-like network resources. Test reports can be generated by the Sustainer on request.

Ops Execution The Sustainer supports real-time operation starting a few days before with a test readiness review. This review includes staging files, gathering screenshots of configurations and verifications, and reviewing a checklist of steps to complete prior to operations. This is done prior to the on-orbit activity to ensure the system and products are in place and ready for ops. The Sustainer handles file management, including new software upload, removal of old data and software, uploading maps, and downloading data from the Astrobees to the DDS1 and DDS2 servers post activity. The Sustainer also performs software and configuration updates, including map installation, FSW updates as applicable, and Guest Scientist software updates. The Sustainer also performs real-time adaptations, hardware troubleshooting and adaptation to timeline changes and loss-of-signal (LOS).

The Sustainer also provides personnel trained for the following roles and responsibilities during the on-orbit activity.

Robot Operator The Robot Operator (aka, GDS operator, GDS_op) operates the free-flyer. This GDS operator is the main interface to the robot, with overall responsibility for task execution, maintaining situational awareness, and recovering from localization loss. The GDS operator must listen in to the audio conferencing system in order to properly communicate in real-time with the rest of the Sustainer’s operations team and the Guest Scientist.

Command Line Operator The Command Line Operator (aka CLI operator, CLI_op) interacts with the free-flyer and dock via command line. This CLI operator is the backup interface to the robot, with responsibility for higher rate text-heavy awareness of software status.

Crew Communicator Crew communicator communicates with Crew via space to ground, and coordinates ground communications with JSC and MSFC.

After Ops Execution After the activity, the Sustainer handles data processing, which includes transferring data from DDS1/DDS2 to Hivemind, processing of files to extract imagery, sending images to JSC Bldg. 8 VCC Team for review, and release of data to Guest Scientist. The Sustainer also coordinates an activity summary and debrief of the activity to capture lessons learned and action items for future activities. The Sustainer also retrieves video and still images from other ISS cameras and audio from space-to-ground communications. Post-session statistics and data tracking are also performed, and finally updates to flight product and crew procedures for future sessions.

After Ops Execution

Accessibility Report

Filename:

Astrobee Facility Sustaining Overview.pdf

Report created by:

Organization:

[Enter personal and organization information through the Preferences > Identity dialog.]

Summary

The checker found problems which may prevent the document from being fully accessible.

Needs manual check: 0

Passed manually: 2

Failed manually: 0

Skipped: 4

Passed: 24

Failed: 2

Detailed Report

Document

Rule Name Status Description

Accessibility permission flag Passed Accessibility permission flag must be set

Image-only PDF Passed Document is not image-only PDF

Tagged PDF Passed Document is tagged PDF

Logical Reading Order Passed manually Document structure provides a logical reading order

Primary language Passed Text language is specified

Title Passed Document title is showing in title bar

Bookmarks Passed Bookmarks are present in large documents

Color contrast Passed manually Document has appropriate color contrast

Page Content

Rule Name Status Description

Tagged content Skipped All page content is tagged

Tagged annotations Skipped All annotations are tagged

Tab order Passed Tab order is consistent with structure order

Character encoding Passed Reliable character encoding is provided

Tagged multimedia Passed All multimedia objects are tagged

Screen flicker Passed Page will not cause screen flicker

Scripts Passed No inaccessible scripts

Timed responses Passed Page does not require timed responses

Navigation links Passed Navigation links are not repetitive

Forms

Rule Name Status Description

Tagged form fields Passed All form fields are tagged

Field descriptions Passed All form fields have description

Alternate Text

Rule Name Status Description

Figures alternate text Passed Figures require alternate text

Nested alternate text Passed Alternate text that will never be read

Associated with content Passed Alternate text must be associated with some content

Hides annotation Passed Alternate text should not hide annotation

Other elements alternate text Failed Other elements that require alternate text

Tables

Rule Name Status Description

Rows Passed TR must be a child of Table, THead, TBody, or TFoot

TH and TD Passed TH and TD must be children of TR

Headers Passed Tables should have headers

Regularity Passed Tables must contain the same number of columns in each row and rows in each column

Summary Skipped Tables must have a summary

Lists

Rule Name Status Description

List items Skipped LI must be a child of L

Lbl and LBody Passed Lbl and LBody must be children of LI

Headings

Rule Name Status Description

Appropriate nesting Failed Appropriate nesting

Back to Top