Attachment_B_-_ACS3_Spacecraft_Bus_Requirements.pdf

Advanced Composite Solar Sail System (ACS3) Spacecraft Bus Requirements Document

ACS3 Project Bus Requirements Document

ACS3-06-001

6.1.6 Contamination

Control

The spacecraft bus shall meet contamination control requirements equivalent to at least a 100K clean room.

100K (ISO 8) cleanrooms provide a high enough level of cleanliness to satisfy the needs of the project.

Exceptions will be considered on a case-by-case basis.

6.1.7 RF Compatibility

Testing

The spacecraft bus vendor shall perform a radio frequency (RF) compatibility test with the Mission Operations Center (MOC) prior to launch.

This test will confirm the spacecraft bus radio is compatible with the MOC's ground equipment (e.g., antenna, transmitter, receiver, software, etc.).

6.1.8 Electromagnetic

Compatibility

The spacecraft bus shall be electromagnetically self-compatible.

The spacecraft will launch powered-off, so the only concern is self-compatibility testing (EMC).

Despite being in a production environment, the vendor should perform EMC testing to uncover workmanship defects and unit-to-unit variations in electromagnetic characteristics, as well as design flaws. This may be performed at the spacecraft level to minimize cost/schedule (with increased risk).

6.1.9 Mission Orbit

The spacecraft bus shall operate in a dawn/dusk sun-synchronous orbit with an altitude between 650 and 900 kilometers.

A dawn/dusk sun synchronous orbit is ideal for flying a solar sail in low Earth orbit (LEO). The orbit simplifies attitude control by allowing the solar sail to be aligned with the orbital plane (for minimum aerodynamic drag and maximum on-orbit lifetime), while keeping the solar arrays generally oriented towards the sun, and minimizing the solar radiation pressure torques on the spacecraft (expected to sum to zero over the course of each orbit). Additionally, the ability to avoid sun/shade transitions is desired to minimize sudden thermal extremes on the booms and sail.

A minimum altitude of 650 km is required to meet the mission

ACS3-06-001

means to isolate itself from powering-on when not in the launch dispenser.

spring-loaded on the base plate).

This additional mechanical means (e.g., a remove before flight pin) will help when the spacecraft is not in the dispenser (e.g., during

AI&T).

6.3.5 Recharge Powered-Off

The spacecraft bus shall enable charging of the battery from an external source without being powered-on.

This will enable the battery to recharge on the ground via an umbilical while the spacecraft is powered-off (including the flight computer), even with remove before flight (RBF) pin in place.

6.3.6 Depth of Discharge

Limit

The spacecraft bus shall meet all power requirements with a maximum depth of discharge of 60%.

Taken from ARC-STD-8070. The intent is to preserve battery life and to avoid relying on the tail end of the power versus depth of discharge curve for lithium ion batteries. 60% assumes the number of cycles (defined at discharging below 50%) is between 100 and 5,000 over the lifetime of the battery.

6.3.7 Supply Power

The spacecraft bus shall provide power to the payload, as defined in the Spacecraft Bus to Payload Interface Control Document.

The Payload does not have the means to power itself, and will depend on power from the spacecraft bus to carry out its mission. This does not preclude the ability for the spacecraft bus to cut and restore power to the payload as needed (e.g., the payload is drawing too much current or is non-responsive to commands).

6.3.8 Passivate/Power-

Down

The spacecraft bus shall passivate and power-down at end of mission.

This ensures there is no stored energy in the system (e.g., charged batteries, rotating reaction wheels, etc.) at end of mission. The command is expected to come from the MOC. Successful passivation is defined as having stored energy of less than 15 Joules for re-entry.

6.3.9 Li-Ion Battery Safety

The spacecraft bus shall only use batteries that are UL 1642 certified.

UL 1642, Standard for Lithium Batteries, guarantees a minimum standard for Li-Ion battery safety.

ACS3-06-001

6.5.3 Fundamental

Frequency

The spacecraft (bus and payload) shall have an integrated fundamental frequency greater than 75 Hz.

Driven by an approximation for the combined launch dispenser, bus, and payload fundamental frequency. NASA will provide the bus vendor a structural analysis model of the payload to run coupled loads analysis (CLA) with, and a payload mass model to assemble to the bus for sine sweep tests (to verify the CLA).

6.5.4 Fastener Secondary

Locking Features

The spacecraft bus shall use secondary locking features on fasteners external to the spacecraft bus chassis.

To minimize the possibility for space debris. Locking methods must be approved by NASA Ames.

Tailored from ARC-STD-8070, Section 3.2.2.2.

6.5.5 Hazardous Materials

The spacecraft bus shall comply with NASA guidelines for hazardous materials as shown in MSFC-HDBK-527, Materials Selection List for Space Hardware Systems.

Taken from ARC-STD-8070, Section 3.9.1.

6.5.6 Pyrotechnics

The spacecraft bus shall not use pyrotechnic mechanisms.

Risk reduction.

6.5.7 Delayed Mechanisms

Deployment

The spacecraft bus shall not deploy any mechanisms until power-on.

This minimizes any potential physical interference with the launch vehicle.

6.5.8 Deployment

Force/Torque Margins

The spacecraft bus shall demonstrate mission critical deployment and separation systems (e.g., solar arrays and other spacecraft appendages) have functional force or torque margins of at least 50% for the entire range of motion or show a margin of 100% by analysis.

The margin applies under worst-case conditions, including restart from any position within the range of motion including incipient latching events.

6.5.9 Release Mechanisms

for Flight Deployables

The spacecraft bus vendor shall perform a release mechanism test for flight deployable components.

A first motion test of the mechanism should also be performed at the system level.

6.6 Software Requirements

ACS3-06-001

6.6.1 Error Correction

The spacecraft bus shall use an error-correcting memory solution.

To help ensure memory integrity.

6.6.2 Battery State Fault

Recovery

The spacecraft bus shall provide fault detection that monitors battery state and activates a sun-pointing mode for low battery state of charge conditions.

Minimizes risk associated with inadvertent off-sun pointing. Safe mode is likely to be a sun-pointing mode (to guarantee a power positive state while troubleshooting).

6.6.3 Critical Fault Safe

Mode

The spacecraft bus shall automatically enter a safe-mode in the event of a critical fault unless the fault keeps this mode from being entered.

The definition of "critical fault" will be agreed upon between the spacecraft bus vendor and NASA Ames. Of specific interest is returning to a low drag, operational attitude in the event of a fault during sail deployment.

6.6.4 Automated Fault

Response

The spacecraft bus shall execute configurable command sequences upon detection of a fault or limit exceedance.

Guarantees immediate action attempting to correct a fault/limit exceedance, or minimize damage caused by it. Also allows for customization of responses to specific faults. Of specific interest is returning to a low drag, operational attitude in the event of a fault post sail deployment.

6.6.5 Operational Modes

The spacecraft bus shall have a predefined set of operational modes.

Having a set of predefined modes on board helps streamline certain critical and/or frequent spacecraft states needed for efficient and safe spacecraft operations.

Additional modes will be considered with increased knowledge of the spacecraft bus design solution and mission ConOps.

To include a Safe Mode, Pre- Deployment Operations Mode, and Nominal Operations Mode executed by spacecraft bus or MOC command. The need for a Pre-Deployment Operations Mode stems from the large inertia difference between the stowed and deployed (nominal) solar sail

ACS3-06-001

Additional details on the format of commands/telemetry will be provided in the Space-to-Ground

ICD.

6.7.4 Antenna Coverage

The spacecraft bus shall provide 80% of four pi steradian coverage for the command and telemetry links.

80% of four pi steradian coverage is expected to provide enough time-in-view of the ground station(s) during each pass to downlink the total volume of data needed to achieve mission success within the allotted mission duration.

6.7.5 Uplink Data Rate

The spacecraft bus shall receive commands sent by the MOC.

Data rates are flexible so long as there is power margin in the link budget.

6.7.6 Downlink Data Rates

The spacecraft bus shall send telemetry to the MOC at (TBD1) kbps, (TBD2) kbps, (TBD3) Mbps, and (TBD4) Mbps rates.

TBDs to be supplied via spacecraft bus vendor link budget analysis results.

TBD1 = safe mode rate TBD2 = poor nominal rate TBD3 = nominal rate TBD4 = super nominal rate

Poor/Super nominal rate anticipates a scenario where our link margin is below/above our required margin at the nominal rate. This allows us to increase our margin (in the poor case) or take advantage of increased margin (in the super case).

6.7.7 Uplink Link Margin

The spacecraft bus shall ensure an uplink link margin of greater than 15 dB (TBR).

Based off of calculations using 8 kbps uplink rate. A margin of 15 dB allows the MOC to send commands to the spacecraft at the edges of its antennas' fields of view as a contingency. Ground data needed to calculate the link margin can be found in the Spacecraft Bus RFP Ground Supplement Document.

ACS3-06-001

6.8.3 Minimum Bus H&S

Data Storage

The spacecraft bus shall store a minimum of three

(3) days-worth of MOC-configurable spacecraft bus health and status data.

Spacecraft bus H&S data enables reconstruction of spacecraft performance and trajectory, modeling of the spacecraft state, and supports anomaly analyses.

The ability to store H&S data protects against lost opportunities to downlink data during a pass, or planned periods of time the MOC is not available to receive data.

The telemetry system end-to-end design should permit ground operators to determine the state of the spacecraft, particularly to determine if the spacecraft executed a fault-protection response.

6.8.4 Minimum Payload

H&S Data Storage

The spacecraft bus shall store a minimum of 1 MB of MOC-configurable payload health and status data.

Payload H&S data enables reconstruction of payload performance and supports anomaly analyses. Data will include temperatures, switch status, and operational status of key payload components. 1 MB represents three (3) days' worth of stored payload H&S data.

The ability to store H&S data protects against lost opportunities to downlink data during a pass, or planned periods of time the MOC is not available to receive data.

6.8.5 Selective Telemetry

Transmission

The spacecraft bus shall selectively transmit stored telemetry upon command by MOC.

Allow for selective downlink of portions of the on-board telemetry buffer.

ACS3-06-001

6.8.12 Commanding Options

The spacecraft bus shall perform its required functions through the use of on-board stored operating programs, stored command sequences, and commands sent via the

MOC.

Having the flexibility to command the spacecraft directly from the MOC or via on-board stored operating programs / command sequences provides the needed flexibility in operating the spacecraft.

6.8.13 Absolute/Relative

Time Commands

The spacecraft bus shall support command sequences in both absolute and relative time.

Absolute time means execute at a specified time. Relative time means execute after a period of time (like a delay statement).

6.8.14 Command Memory

Management

The spacecraft bus shall store and delete command sequences as commanded by the MOC.

Memory management for on-board command sequences.

6.8.15 Fault Detection and Limit Exceedance Response

The spacecraft bus shall execute specified command sequences upon detection of a fault or limit exceedance.

Being able to automatically react to a given fault or limit exceedance is a necessary function given the spacecraft will be out of communication with the ground for the majority of the mission.

6.8.16 Command Rejection

The spacecraft bus shall ignore improperly formatted commands and those not sent by the MOC.

This is largely taken care of within CCSDS and COP1 support. CCSDS and COP1 are preferred, but not required. Standard vendor formats will be considered. Not meant to require encryption.

6.8.17 Receiver Command

Continuity

The spacecraft bus shall be continuously receptive to commands.

In case of a failure disrupting nominal MOC to spacecraft communications. After initial ejection and power-up, the receiver must be on at all times and able to receive commands.

6.8.18 Command Logging

The spacecraft bus shall ensure all software generated data products available for downlink include a log of all received, executed, and rejected commands that indicates both time of receipt and time of execution.

This data will provide valuable insight into the day-to-day operation of the spacecraft.