1. The interface as territory

William Gibson’s Neuromancer made the interface feel like a place. Cyberspace is not just a connection between machines; it is a landscape with its own rules, dangers, and possibilities. The desktop’s interfaces are less dramatic, but they are similarly a territory of their own. The attachments are the cities; the wires, buses, and protocols are the roads between them. Integration is the map of those roads.

Entry 269 closed the operations arc and noted that integration was the obvious next problem. This entry opens the integration arc.

2. What integration means

Integration is the work of making separately defined attachments operate as one spacecraft. It has three layers:

  • Physical integration: mounting, connectors, harness, and thermal contact.
  • Electrical integration: power distribution, grounding, and signal integrity.
  • Data integration: buses, protocols, command routing, and telemetry flow.

Each layer has its own failure modes. A loose connector is a physical failure. A ground loop is an electrical failure. A protocol mismatch is a data failure. Integration is the discipline that prevents all three.

3. The attachment interface model

Every attachment on the desktop should present a clean interface to the rest of the system. A useful model is:

  • Power interface: voltage, current limit, inrush, noise, and switching behaviour.
  • Data interface: physical connector, protocol, message format, and timing.
  • Mechanical interface: mounting points, envelope, mass, centre of mass, and thermal contact.
  • Command interface: the set of commands the attachment accepts and the telemetry it produces.
  • Thermal interface: heat generation, operating temperature range, and cooling path.

If every attachment defines these five interfaces clearly, integration becomes a matter of checking compatibility rather than inventing custom solutions.

4. Physical integration

Physical integration starts with the attachment grid defined in the structural arc. Each attachment occupies a volume, has mounting points, and connects to the main harness. Key concerns:

  • Connector accessibility: can the attachment be mated and demated during assembly or service?
  • Harness routing: are cables short, protected, and clear of moving parts or hot surfaces?
  • Thermal contact: does the attachment conduct heat to the structure or radiator as intended?
  • Vibration and shock: are attachments secured against launch loads?
  • Serviceability: can a robotic arm reach the attachment for replacement?

The desktop’s modular design helps here. If attachments are designed to the same grid and connector standard, swapping one for another is mechanical routine.

5. Electrical integration

Electrical integration distributes power from the battery and solar arrays to every attachment. Key decisions:

  • Voltage buses: a main unregulated battery bus, a regulated 28 V bus, and lower-voltage digital buses as needed.
  • Current protection: fuses or electronic circuit breakers on each load.
  • Grounding: single-point or distributed ground strategy to avoid ground loops.
  • Power sequencing: the order in which attachments are powered on after launch or reset.
  • Noise isolation: separating noisy actuators from sensitive sensors.

The propulsion and ADCS actuators are the noisiest loads. Their power returns should be separated from the returns for the star tracker, gyro, and radio receiver.

6. Data integration

Data integration connects the compute attachment to every other attachment. Options:

  • CAN bus: robust, widely used in spacecraft, moderate data rate. Good for sensors and actuators.
  • SpaceWire: higher data rate, used for high-bandwidth payloads and inter-board links.
  • UART / SPI / I2C: simple point-to-point or bus links for low-level devices.
  • Ethernet: increasingly common for high-data payloads and onboard computing.

For the desktop, a mixed approach is likely:

  • CAN bus for housekeeping, ADCS, power, and thermal subsystems.
  • Ethernet or SpaceWire for the imager and payload data.
  • UART or SPI for low-level sensors and bootloaders.

The flight software abstracts these buses so that higher-level code sees commands and telemetry, not electrical signals.

7. Time and synchronisation

Integration also requires a shared sense of time. The desktop needs:

  • A spacecraft clock, synchronised to GPS time.
  • Time-stamped telemetry and commands.
  • Synchronisation between the imager, star tracker, and GPS for geolocation.
  • A schedule that all subsystems agree on.

Without time synchronisation, an image cannot be reliably matched to an orbit position, and a command scheduled for a future event may arrive early or late.

8. Integration testing

Integration is not complete until it is tested. The test pyramid for the desktop:

  • Unit test: individual attachment functions correctly in isolation.
  • Interface test: two attachments exchange commands and telemetry correctly.
  • Subsystem test: a functional group, such as ADCS, works together.
  • System test: the entire desktop operates in a simulated environment.
  • Environmental test: the integrated desktop survives thermal vacuum, vibration, and electromagnetic interference.

Each test catches errors that the previous level could not. The most expensive errors are the ones found only in orbit.

What this changes

  • Integration is the next arc, following operations.
  • Integration has three layers: physical, electrical, and data.
  • Every attachment should define power, data, mechanical, command, and thermal interfaces.
  • The desktop likely uses CAN for housekeeping, Ethernet or SpaceWire for payload data, and UART/SPI for low-level devices.
  • Time synchronisation is essential for geolocation and scheduling.
  • Integration testing proceeds from unit to system to environmental levels.
  • The next entry will define the power distribution and data bus architecture.