Power¶

The power stage combines solar generation, spacecraft loads, and battery energy on the simulation timeline. Use it to answer:

how does state of charge evolve?
when do generation or storage margins close?
how do attitude, service activity, or propulsion change the load?
which array or battery variant closes the same scenario?

flowchart LR ORBIT["Orbit and eclipse"] --> BALANCE["Power balance"] ATT["Attitude and panel incidence"] --> BALANCE LOAD["Subsystem and activity loads"] --> BALANCE PROP["Optional propulsion load"] --> BALANCE BALANCE --> BATTERY["Battery energy and SOC"] BATTERY --> RESULT["Margins, violations, and sizing results"]

Generation And Storage¶

Panels may be body-mounted, fixed deployed, or single-axis steerable. Generation uses solar irradiance, panel area and efficiency, conversion efficiency, eclipse state, and incidence angle. Steerable panels apply angle and slew-rate limits, so the commanded and achieved panel angles can differ.

Battery energy is integrated step by step from net power. The model reports state of charge together with low-SOC, high-SOC, and power-deficit conditions.

power:
  panels:
    - kind: body_mounted
      panel_id: positive-x
      area_m2: 0.3
      efficiency: 0.31
      normal_body: [1.0, 0.0, 0.0]
  battery:
    capacity_wh: 1000
    soc_init_pct: 80
    soc_min_pct: 20
    soc_max_pct: 98
  subsystems:
    - name: spacecraft-bus
      role: bus
      draw_w: 28

Eight-hour power timeline showing solar generation and load above battery state of charge, with eclipse intervals shaded.

The shared timeline makes eclipse, generation, load, and state-of-charge changes directly comparable.

Load Model¶

The total load is additive. Depending on the RunSpec it can include:

Load family	Source
Spacecraft bus	fixed subsystem draws and attitude mode-state increments
Payload	fixed standby/base draw or activity-driven operational draw
Feeder and ISL equipment	manual standby/RX/TX increments or RF-derived equipment assumptions
Observation activity	capture and processing activity counts
Propulsion	standby and throttle-weighted finite-burn electrical load

The assembled load is adjusted by the configured load efficiency before battery integration.

Fixed And Activity-Driven Payloads¶

Use a fixed payload when its draw should not depend on service execution:

power:
  payload:
    policy:
      mode: fixed_only
    loads:
      fixed_w: 24

Use hybrid when payload power should follow the reduced activity profile created by a service/transport run. Its required driver represents the conservative scheduled requirement; served follows realized execution. Hybrid power therefore requires the upstream service and transport context that creates those activity channels.

Finite-slew attitude availability is applied to panel orientation and, by default, to communications and payload activity. This keeps generation and load consistent during acquisition and settling.

Power Sizing¶

power.sizing compares power-domain variants while reusing one fixed upstream scenario. It avoids rerunning propagation, attitude, service, transport, and activity reduction for every array or battery case.

power:
  sizing:
    enabled: true
    variants:
      - id: larger-array
        overrides:
          power:
            panel_area_m2: 0.5
      - id: larger-battery
        overrides:
          power:
            battery:
              capacity_wh: 900

Use sizing variants for power configuration such as panel area or efficiency, battery limits, subsystem and payload loads, and equipment assumptions. Use a normal sweep when the variant changes scenario truth such as orbit, constellation, geography, demand, scheduling, gateway configuration, or attitude mode family.

Outputs¶

Artifact	Contents
`power/timeline_power.parquet`	generation, load components, net power, battery energy, SOC, and eclipse state
`power/power_summary.json`	energy balance, margins, extrema, and violation counts
`power/power_violations.*`	timestamped power and SOC violations
`power/power_panel_angles.*`	commanded and applied panel angles
`power/power_profiles.json`	resolved per-satellite generation, storage, and load assumptions
`power/rf_derived_equipment.json`	resolved RF source and DC-load assumptions when RF-derived equipment is used
`power/sizing/`	status, summaries, profiles, and optional timelines for each sizing variant

The Console power and analysis views read these saved artifacts.

Packaged Examples¶

Question	Example
Does a 24-satellite service timeline sustain its power balance?	`astraeus-resources/examples/user/spacecraft-power-balance.yaml`
Which array and battery variants close a fixed case?	`astraeus-resources/examples/user/power-sizing.yaml`
What is the electrical effect of two finite EP burns?	`astraeus-resources/examples/user/propulsion-power-coupling.yaml`
How do observation, transport, activity, and power behave together?	`astraeus-resources/examples/user/observation-to-delivery.yaml`
How does active-beam load change the energy margin of an otherwise fixed service architecture?	`astraeus-resources/examples/user/studies/integrated-service-power-trade.yaml`

Interpretation Limits¶

Eclipse uses a cylindrical-shadow approximation rather than a penumbra model.
The battery is a lumped deterministic energy store. Thermal behavior, degradation, cell balancing, and detailed charge-control dynamics require a higher-fidelity battery model.
Load resolution is an additive spacecraft-level power balance across declared base, activity, payload, and propulsion consumers.
Results depend on intentional attitude and activity configuration; static defaults may hide operational power peaks.
Cadence limits the timing resolution of short activity and violation events.

For exact fields and sizing restrictions, see the RunSpec reference.