Satellite-Ground Control Real-Time System Simulation

A Rust-based simulation of real-time coordination between a CubeSat in low Earth orbit and a Ground Control Station (GCS) with strict real-time constraints.

System Components

Student A: Satellite Onboard Control System (OCS)

1. Sensor Data Acquisition and Prioritization

• Simulate three onboard sensors (Thermal, Gyroscope, Radiation) with distinct intervals and priorities
• Maintain jitter <1ms for critical sensors
• Implement prioritized data in bounded buffer with data loss simulation
• Log dropped samples with timestamps
• Measure scheduling drift (expected vs actual task start times)
• Track latency from sensor read to buffer insertion
• Raise safety alert if critical data missed for >3 consecutive cycles

2. Real-Time Task Scheduling

• Schedule tasks: data compression, health monitoring, antenna alignment
• Implement real-time scheduling strategies (Rate Monotonic or EDF)
• Support preemption (thermal control overrides lower-priority tasks)
• Log all deadline violations
• Measure and report scheduling drift and task execution jitter
• Log CPU utilization (% active vs idle time)

3. Downlink Data Management

• Compress and packetize data for transmission
• Prepare data for downlink within 30ms of visibility window
• Log transmission queue latency and buffer fill rates
• Simulate missed communication if downlink not initialized within 5ms
• Trigger degraded mode if buffer exceeds 80%

4. Benchmarking and Fault Simulation

• Inject faults every 60s (delayed/corrupted sensor data)
• Log all faults and responses
• Evaluate: jitter, drift, deadline adherence, fault recovery time, CPU utilization
• Simulate mission abort if recovery time >200ms

Student B: Ground Control Station (GCS)

1. Telemetry Reception and Decoding

• Receive telemetry via IPC/sockets and decode within 3ms
• Use channels for data transfer (Tokio mpsc)
• Decompress packets from OCS
• Log packet reception latency and reception drift
• Implement exponential back-off for re-requests on missing/delayed packets
• Simulate "loss of contact" if ≥3 packets fail sequentially
• Send feedback to OCS for missing packets

2. Command Uplink Scheduler

• Maintain real-time command schedule
• Enforce deadlines for urgent commands (≤2ms dispatch)
• Validate commands against system state using safety interlocks
• Send responses for data anomalies and corrupted packets
• Log all command deadline adherence and rejection reasons

3. Fault Management and Interlocks

• Simulate reception of fault messages from satellite
• Block unsafe commands until resolved
• Request data from OCS for out-of-range sensor data
• Track interlock latency (detection to command block)
• Document all command rejections
• Trigger critical ground alert if fault response time >100ms

4. System Performance Monitoring

• Benchmark uplink jitter, telemetry backlog, task execution drift
• Record missed deadlines, system load, fault recovery metrics
• Log all real-time actions with timestamps

Shared System Requirements

Both components must:

• Log scheduling drift (use interval instead of sleep)
• Track latency in all pipelines (sensor to buffer, packet to uplink, command to response)
• Record jitter (variation in periodic task timing)
• Handle simulated faults and log recovery time
• Implement safety interlocks and document rejected operations
• Include performance metrics and logs in final report (benchmarking with criterion)

Communication Protocols

OCS → GCS Data Structures:

• SensorReading with type, timestamp, value, status
• SystemHealth with CPU/memory usage, temperature, uptime, degraded mode
• TelemetryPacket with satellite ID, timestamp, health data, sensor readings, fault reports
• FaultReport with fault code, message, timestamp, recovery status

GCS → OCS Data Structures:

• CommandPacket with command ID, timestamp, target, command, deadline, priority
• AckPacket with command ID, receipt time, status, and optional message

Technical Implementation

• Built with Rust using Tokio for async operations
• Use channels (Tokio mpsc) for inter-process communication
• Run simulation for several minutes to collect benchmark data
• Modular code structure with separate OCS/GCS modules

Quality Requirements

• Code must be modular, efficient, and idiomatic Rust
• Proper implementation of concurrency and safety features
• Handle real-time constraints effectively
• Components must integrate seamlessly with correct real-time data exchange