The communication window between a satellite and a ground station is extremely short (usually only 3-10 minutes). The OBC must complete the core tasks of "data compression → transmission to the ground" within this window, while simultaneously processing real-time tasks such as attitude control and sensor data collection. Therefore, the OBC’s computing power must accurately match the task load, avoiding "task delays due to insufficient computing power" or "power waste due to excessive computing power.
The computing power requirement of an OBC is essentially determined by the satellite’s "task type" and "data volume." It is necessary to first clarify the load of two types of tasks:
- Core Tasks: Tasks that directly define the satellite’s mission, requiring the highest computing power. For example:
- Earth Observation (EO) Satellites: Need to process high-resolution images (e.g., 1m resolution, 10km swath width, with a single image data volume of hundreds of MB). High-performance processors (e.g., multi-core ARM, PowerPC) are required to support "real-time image compression" (e.g., JPEG 2000 compression algorithm) to prevent data accumulation and failure to transmit in a timely manner.
- Communication Satellites: Need to process high-bandwidth data streams (e.g., GEO communication satellites have a single-channel data rate of hundreds of Mbps). Priority must be given to ensuring "data forwarding efficiency," and computing power must match the transmission rate of the communication module.
- Auxiliary Tasks: Basic tasks that ensure the satellite’s normal operation, with low computing power requirements. For example: temperature monitoring, voltage collection, attitude fine-tuning, etc. These can usually be handled by the OBC’s "low-power core" without occupying main computing resources.
-
When selecting the OBC’s computing power, it is necessary to avoid computing power waste caused by "mismatched speeds between the processor and peripheral hardware," focusing on the following two core points:
- Matching Between Processor and Data Bus: The processor’s computing speed must be synchronized with the transmission rate of the data bus (e.g., PCIe, SpaceWire). For example, if the OBC uses a 4GHz processor but is paired with a 2GHz data bus, the processor’s computing results cannot be transmitted through the bus in a timely manner, resulting in an actual effective computing power of only 2GHz. The extra 2GHz computing power not only has no practical value but also increases power consumption.
- Matching Between Processor and Storage: The processor’s read/write speed must match the access speed of the memory (e.g., RAM, flash memory). For example, a high-performance processor paired with low-speed RAM will lead to idle computing power due to "waiting for data reading," forming a "storage bottleneck.
-
Before selecting an OBC, the required computing power can be evaluated through the following steps:
- Calculate the "single-orbit mission data volume" (e.g., an EO satellite collects 10 high-resolution images per orbit, with a total data volume of 5GB).
- Determine the "data transmission window duration" (e.g., a 5-minute per-orbit communication window, equivalent to 300 seconds).
- Derive the "data processing rate requirement" (e.g., 5GB of data needs to be compressed and transmitted within 300 seconds, requiring a data processing rate of ≥17MB/s).
- Select a matching processor and bus combination based on the rate requirement (e.g., a 2GHz processor + 2GHz SpaceWire bus to ensure the rate meets the standard).
In summary, the OBC’s computing power must be "selected on demand" — centered on task load, constrained by hardware synergy efficiency, ensuring that computing power can meet task requirements without wasting power.
