MIT License Contribute on GitHub Download PDF Download PDF

Stakeholder Needs

The SeaLion Mission Architecture is guided by a series of stakeholder needs, listed below.

1.1: Primary Mission Objective A1

The SeaLion mission shall establish UHF communication link with Virginia ground station

1.2: Primary Mission Objective A2

The SeaLion mission shall establish S-Band communication link with MC3 ground station

1.3: Primary Mission Objective A3

The SeaLion mission shall successfully transmit “mission data” defined above to ground stations on the Earth.

1.4: Primary Mission Objective A4

The SeaLion mission shall adhere to CubeSat standards.

Reference:

1.5: Primary Mission Objective A5

The SeaLion mission shall validate the operation of the Impedance Probe (IP) as a primary payload in-orbit.

2.1: Secondary Mission Objective B1

The SeaLion mission shall provide a means to validate a Multi-spectral Sensor (Ms-S) in-orbit

2.2: Secondary Mission Objective B2

The SeaLion mission shall provide a means to validate a deployable composite structure (DeCS) in-orbit

3.1: Tertiary Mission Objective C1

The SeaLion mission shall qualify on-orbit the deployment and functioning of the newly developed UHF antenna system and its deployment.

3.2: Tertiary Mission Objective C2

The SeaLion mission shall qualify a CubeSat bus architecture for very-low Earth orbit (VLEO)

3.3: Tertiary Mission Objective C3

The SeaLion shall verify DeCS in-orbit behavior performance.

Stakeholder Needs Mapping

stakeholder needs mapping

User Stories

The SeaLion Mission Architecture’s stakeholder needs are then used to identify a series of user stories which then lead to design decisions captured in data structure and activity definitions.

1: Ping Satellite

As a Ground Station Operator I want to Ping satellite so that I can Establish communication link with satellite.

Example:

Ping the satellite in order to establish UHF communication link with Virginia ground station

Derived From:

2: View Satellite Beacon Data

As a Ground Station Operator I want to view satellite beacon data (alternating between health & mission data), received via UHF so that I can verify that satellite is operating nominally.

Example:

View satellite beacon data (health or mission data) to verify that TLE’s correspond with expected orbit profile and/or to validate that a mission mode was successful

Derived From:

3: Send Request to Set Interrupt Timer

As a Ground Station Operator I want to send a request to set count value at which interrupt timers (i.e., beacon, GPS ping, or orbit propagator) are triggered so that I can finetune parameters for attitude or orbit analysis or to conserve power.

Example:

Update beacon rate to transmit every 30 minutes to conserve power

4: Request Telemetry or EventLog Data

As a Ground Station Operator I want to Request satellite telemetry or eventlog data so that I can verify/validate health status or mission data.

Example:

Request satellite telemetry packets for local verification/validation of onboard AODS computations

4.1: Request Satellite Health Data

As a Ground Station Operator I want to request satellite health data packet so that I can verify/validate AODS sensors & GPS data are within nominal parameters.

Example:

Request satellite health data packet to verify or validate TLE data corresponding to expected orbit profile based on pre-computed orbit propagation model

Derived From:

4.1.1: Request Satellite Health Data via S-Band Radio

As a Ground Station Operator I want to request satellite health data packet via S-band radio so that I can verify/validate AODS sensors & GPS data are within nominal parameters.

Example:

Request satellite health data packet via S-band radio to verify or validate TLE data corresponding to expected orbit profile based on pre-computed orbit propagation model

Derived From:

4.2: Request Satellite Mission Data

As a Ground Station Operator I want to request satellite mission data so that I can validate in-orbit AODS and/or payload performance.

Example:

Request satellite mission data to verify that TLE’s & AODS sensor data correspond with expected orbit profile and/or validate that a mission mode was successful

Derived From:

5: Send Request to Set Mission Mode Duration

As a Ground Station Operator I want to send a request to set mission mode duration so that I can manage time spent per mission mode.

Example:

send a request to set Mission Mode 1 duration to 25 minutes

User Stories Mapping

user stories mapping

User stories as Use Case Diagram

use case diagram

Data Structures

This section covers each data structure type in the SeaLion Mission Architecture.

Satellite Health Data Packet

Purpose: Data structure for satellite health data packet used for beacon telemetry

Satellite Health Data Packet Template
call_sign: {{call_sign}}
battery_health: {{battery_health}}
temperature_battery: {{temperature_battery}}
mode: {{mode}}
tle_data: {{tle_data}}
Table 1. Satellite Health Data Packet Specification
Field Type Item Type Description Source

call_sign

string

Identifying call sign for the Sealion mission.

battery_health

float

Percent value indicating the remaining charge of the batteries.

temperature_battery

float

The temperature of the battery. Units in Kelvin.

mode

integer

Integer value indicating current mission mode. 0 = Safe, 1 = mission mode 1, 2 = mission mode 2, 3 = mission mode 3.

tle_data

TLE

TLE data from orbit propogator at time of beacon.

Derived From:

Satellite GPS Data

Purpose: Data structure for GPS data used for orbit propagation

Satellite GPS Data Template
time_stamp: {{time_stamp}}
altitude_data_GPS: {{altitude_data}}
lattitude_GPS: {{lattitude}}
longitude_GPS: {{longitude}}
Table 2. Satellite GPS Data Specification
Field Type Item Type Description Source

time_stamp

string

Time stamp when GPS data was acquired.

altitude_data_GPS

float

The altitude data of the satellite from GPS.

lattitude_GPS

float

Lattitude coordinate of the satellite from GPS.

longitude_GPS

float

Longitude coordinate of the satellite from GPS.

Satellite AODS Sensor Data

Purpose: Data structure for satellite AODS sensor data used for attitude determination or incremental orbit propogation

Satellite AODS Sensor Data Template
imu_gyro_x: {{imu_gyro_x}}
imu_gyro_y: {{imu_gyro_y}}
imu_gyro_z: {{imu_gyro_z}}
imu_magnetometer_x: {{imu_magnetometer_x}}
imu_magnetometer_y: {{imu_magnetometer_y}}
imu_magnetometer_z: {{imu_magnetometer_z}}
sun_sensor_pitch_pos: {{sun_sensor_pitch_pos}}
sun_sensor_pitch_neg: {{sun_sensor_pitch_neg}}
sun_sensor_yaw_pos: {{sun_sensor_yaw_pos}}
sun_sensor_yaw_neg: {{sun_sensor_yaw_neg}}
sun_sensor_roll_pos: {{sun_sensor_roll_pos}}
sun_sensor_roll_neg: {{sun_sensor_roll_neg}}
time_stamp: {{time_stamp}}
Table 3. Satellite AODS Sensor Data Specification
Field Type Item Type Description Source

imu_gyro_x

float

The angular rate of the body with to respective to the x-axis in the IMU’s reference frame.

imu_gyro_y

float

The angular rate of the body with to respective to the y-axis in the IMU’s reference frame.

imu_gyro_z

float

The angular rate of the body with to respective to the z-axis in the IMU’s reference frame.

imu_magnetometer_x

float

The magnetic field strength with respective to the x-axis in the IMU’s reference frame.

imu_magnetometer_y

float

The magnetic field strength with respective to the y-axis in the IMU’s reference frame.

imu_magnetometer_z

float

The magnetic field strength with respective to the z-axis in the IMU’s reference frame.

sun_sensor_pitch_pos

float

Sun sensor measurement with respect to positive pitch angle.

  • []

sun_sensor_pitch_neg

float

Sun sensor measurement with respect to negative pitch angle.

  • []

sun_sensor_yaw_pos

float

Sun sensor measurement with respect to positive yaw angle.

  • []

sun_sensor_yaw_neg

float

Sun sensor measurement with respect to negative yaw angle.

  • []

sun_sensor_roll_pos

float

Sun sensor measurement with respect to positive roll angle.

  • []

sun_sensor_roll_neg

float

Sun sensor measurement with respect to negative roll angle.

  • []

time_stamp

string

Time stamp of the last transmission.

Derived From:

TLE

Purpose: Data structure for the TLE data computed from GPS data or orbit propagator

TLE Template
tle_line_1: {{tle_line_1}}
tle_line_2: {{tle_line_2}}
Table 4. TLE Specification
Field Type Item Type Description Source

tle_line_1

TLELine1

Data for TLE line 1

tle_line_2

TLELine2

Data for TLE line 2

Derived From:

TLE Line 1

Purpose: Data structure for the first line of the TLE data

TLE Line 1 Template
line_number: {{line_number}}
satellite_number: {{satellite_number}}
classification: {{classification}}
international_designator_1: {{international_designator_1}}
international_designator_2: {{international_designator_2}}
international_designator_3: {{international_designator_3}}
epoch_year: {{epoch_year}}
epoch: {{epoch}}
first_dt: {{first_dt}}
second_dt: {{second_dt}}
bstar: {{bstar}}
eph_type: {{eph_type}}
element_number: {{element_number}}
checksum: {{checksum}}
Table 5. TLE Line 1 Specification
Field Type Item Type Description Source

line_number

string

Line number of element data (Column 01)

satellite_number

string

Satellite number (Column 03-07)

classification

string

Classification of satellite (Column 08)

international_designator_1

string

International designator 1 (last two digits of launch year) (Column 10-11)

international_designator_2

string

International designator 2 (launch number of the year) (Column 12-14)

international_designator_3

string

International designator 3 (piece of the launch) (Column 15-17)

epoch_year

string

Epoch year (last two digits of year) (Column 19-20)

epoch

string

Epoch (day of the year and fractional portion of the day) (Column 21-32)

first_dt

string

First time derivative of the mean motion (Column 34-43)

second_dt

string

Second time derivative of the mean motion (leading decimal point assumed) (Column 45-52)

bstar

string

BSTAR drag term (leading decimal point assumed) (Column 54-61)

eph_type

string

Ephemeris type (Column 63)

element_number

string

Element number (Column 65-68)

checksum

string

Checksum (modulo 10) (letters, blanks, periods, plus signs = 0; minus signs = 1) (Column 69)

Derived From:

TLE Line 2

Purpose: Data structure for the second line of the TLE data

TLE Line 2 Template
line_number: {{line_number}}
satellite_number: {{satellite_number}}
inclination: {{inclination}}
raan: {{raan}}
ecc: {{ecc}}
perigee: {{perigee}}
mean_anomaly: {{mean_anomaly}}
mean_motion: {{mean_motion}}
rev_epoch: {{rev_epoch}}
checksum: {{checksum}}
Table 6. TLE Line 2 Specification
Field Type Item Type Description Source

line_number

string

Line number of element data (Column 01)

satellite_number

string

Satellite number (Column 03-07)

inclination

string

Inclination (degrees) (Column 09-16)

raan

string

Right ascension of the ascending node (degrees) (Column 18-25)

ecc

string

Eccentricity (leading decimal point assumed) (Column 27-33)

perigee

string

Argument of perigee (degrees) (Column 35-42)

mean_anomaly

string

Mean anomaly (degrees) (Column 44-51)

mean_motion

string

Mean motion (revs per day) (Column 53-63)

rev_epoch

string

Revolution number at epoch (revs) (Column 64-68)

checksum

string

Checksum (modulo 10) (letters, blanks, periods, plus signs = 0; minus signs = 1) (Column 69)

Derived From:

Mission Data

Purpose: Defines EVR (event) elements to be recorded to the eventLog during a mission mode

Mission Data Template
entry_tle: {{entry_tle}}
obc_sensors: {{obc_sensors}}
mission_data: {{mission_data}}
exit_tle: {{exit_tle}}
Table 7. Mission Data Specification
Field Type Item Type Description Source

entry_tle

TLE

TLE at time of beginning of mission mode

obc_sensors

AODSSensorData

AODS Sensor data

mission_data

string

Data recorded during mission mode

exit_tle

TLE

TLE at time of end of mission mode

Derived From:

Data Structures Mapping

data structures mapping

Finite State Machine

fsm