Use cases CubeSats
A CubeSat's budgets, modes and verification in one model
For university and early-stage teams building a CubeSat or another small satellite, where the mission, the bus and the ground segment all have to close on tight mass and power. Cairn keeps the spacecraft as one model: subsystems with their budgets, the requirements on each, the modes it flies in and how each requirement will be verified.
The problem
A small spacecraft closes or doesn't on a few numbers: mass against the deployer's limit, power generated against power drawn in each mode, and a link that has to close with margin. Those numbers move whenever a subsystem changes, and each subsystem lead keeps their own copy.
Every review asks the same questions: what each requirement traces to, how it will be verified, and why this design was chosen over the alternatives. The answers are spread across slides, spreadsheets and memory.
A workflow in Cairn
Lay out the mission and the bus
Describe the mission, say a 3U CubeSat imaging coastal water, and let the interview settle the actors, such as the ground station and its operators, and the first requirements. The Architect then proposes subsystems such as power, attitude control, the on-board computer, comms and the payload.
The interview →Roll up mass and power
Give each part its mass and nominal power, and set a mass budget and a power budget on the spacecraft. Overview adds the parts up against each budget and shows how much of it is used.
System decomposition →Plan verification for each requirement
In the Verification lens, add a method to each requirement: test for random vibration, analysis for the link budget, inspection for the deployer envelope, demonstration for antenna deployment. Record results as they come in and see what has passed and what is still open.
Verification matrix →Model the operating modes
Draw the spacecraft's modes as a state machine, from separation through detumble and safe mode to nominal and downlink, and step through it. Cairn flags a mode nothing reaches and a mode with no way out.
Behavior and state machines →Keep the paths not taken
When body-mounted cells win over deployable panels, record the panels as an alternative set aside, with why they lost (say, a hinge and a release mechanism to qualify) and the principle behind it. Whoever revisits power next sees the reasoning.
Design decisions →See what holds the spacecraft back
In the Causality lens, give each subsystem a maturity stage. The spacecraft can be no further along than its least mature part, and the lens names it: say, a payload still at prototype.
Design decisions →
What Cairn doesn't do yet
- Cairn doesn't ship orbit, link-budget or thermal analysis. Run those where you do today and record each result against the requirement it verifies.
- Maturity is a stage, from concept to mature, not a TRL number.
- There is no shared workspace yet: a project lives in one person's browser and can back up to their account, so subsystem leads can't edit one model at the same time. A copy moves by export and import.
- Cairn doesn't read or write SysML or ReqIF, and it is not a mission assurance or certification record.
Questions
- Does Cairn use TRLs?
- Not as numbers. The Causality lens gives each part a stage, from concept and prototype through development, tested and production to mature, and the spacecraft can be no further along than its least mature part.
- Can the model include the ground segment?
- Yes. The ground station and its operators can be external actors in the model, and interfaces can reach them, so the link to the ground has a place, with its signals.
- Which verification methods can I use?
- Inspection, analysis, demonstration and test, each activity with a status: draft, planned, passed, failed or blocked.
See it on your own system.
Describe what you are building and Cairn interviews you, then builds the first model with you.