"A satellite is never where you left it. The whole discipline is knowing where it will be, and being ready when it arrives."
A spacecraft in low orbit crosses the sky above a given station in a handful of minutes, a few times a day. Everything a mission does — taking the image, sending it down, correcting the orbit, recovering from a fault — has to fit inside those minutes, and they have to be known in advance to the second.
NIOSAT computes where a satellite will be, when it can be reached, what it can accomplish between one pass and the next, and how that plan is carried out safely from the ground.
A low-orbit spacecraft is in view of a ground station for a few minutes at a time. Whatever was not uploaded, downloaded or corrected in that window waits for the next one, hours later.
Atmospheric drag, the shape of the Earth and the pull of the sun and moon all move a spacecraft off the orbit it was placed in, so a prediction made last week is not good enough to point an antenna today.
Imaging, downlink, charging, thermal limits and maintenance all compete for the same short pass, and the plan that satisfies one of them usually breaks another.
With tens of thousands of tracked objects in orbit, knowing how close another object will come — and when to move — has stopped being an occasional exercise and become routine operations work.
Taking a current orbital state and carrying it forward under the forces that actually act on it — the non-spherical Earth, atmospheric drag, solar radiation pressure, third-body attraction — rather than under an idealised one.
Turning a propagated orbit into the concrete question an operator asks: from this station, on this day, between which two clock times is the spacecraft above the horizon and high enough to work with.
Modelling attitude, power, thermal behaviour and sensors together, so that a plan is tested against a spacecraft that behaves like the real one before the real one is asked to perform it.
Fitting competing tasks into the windows that exist, subject to power, memory, thermal and pointing limits — and producing a plan that says what was dropped and why.
Position and velocity over the coming hours and days, with the uncertainty carried alongside rather than dropped, because a prediction without its error bar cannot be planned against.
Contact windows per station, with elevation, duration and expected link geometry — the raw material of every operations schedule.
How many observations, downlinks and manoeuvres the spacecraft can actually perform between passes given its power and storage, and which requests will have to wait.
Approach distances against catalogued objects, flagged early enough that a small planned manoeuvre remains an option instead of an emergency.
Planning begins from the latest determined orbit and the spacecraft's reported condition, not from the orbit it was supposed to be in at launch.
The state is carried forward under the full force model, and the result is cut into contact windows for each ground station and each target on the ground.
Requests are placed into those windows against the spacecraft's limits, producing a schedule that is feasible rather than merely desirable.
The schedule is run against the simulator before it is uploaded, and after the pass the telemetry is compared with what the simulation predicted, which is how the model gets better.
Orbit determination and propagation with the force models, coordinate frames and time scales handled explicitly, so a result can be reproduced exactly from the state and the epoch it started from.
A model of the spacecraft — attitude, power, thermal, sensors — that a plan can be executed against, and that doubles as the training environment for the people who will fly it.
The scheduler that turns requests and constraints into a timed sequence of commands, keeping the reason each task landed where it did.
The console operators actually work at, written by us so that what it shows, what it allows and what it records are ours to decide and ours to keep supporting.
Every command sent, every response received and every plan superseded, stored against the pass it belonged to — the layer that makes an anomaly investigable weeks later.
Every sequence is validated against the spacecraft's limits and its current state before it can be sent, and a sequence that would violate one is refused at the console rather than in orbit.
Anything unusual — a new manoeuvre, a recovery procedure, a first-time payload mode — is executed against the simulator before it is executed against the vehicle.
Manoeuvres, mode changes and software uploads require a second operator to confirm, because the one class of error that cannot be corrected on the next pass is the one that ends the mission.
Commands are logged as they are issued, not summarised afterwards, so the sequence of events in an anomaly is a matter of record rather than of memory.
Orekit as the flight dynamics core — propagation, orbit determination, frames, time scales and access windows — the component every other answer on this page is ultimately computed from.
basilisk for spacecraft dynamics and subsystem simulation, which is where a plan is rehearsed and where operators practise a fault before they ever meet one.
nos3 as the environment for running and exercising flight software against simulated hardware, so onboard behaviour can be tested long before there is a vehicle to test it on.
NASTRAN-95 for structural and vibration analysis of spacecraft and ground hardware — the slower, older discipline behind whether a structure survives the ride to orbit.
TEROZ needs to know which satellite will cross a given area and when; KAELO needs the same timing for the data it forecasts from; OBUNETU builds the ground links that carry it all down. NIOSAT is the layer that answers "where, and when".
Satellite operators running small constellations, research institutes flying a single instrument, and government offices that own a mission but not a flight dynamics team.
We have flown nothing. There are no figures from our own bench on this page, no operational heritage behind the architecture, and the operations console described above is a design rather than a product.
Validating our propagation against public tracking data for satellites already in orbit, building the console against a simulated mission, and looking for a first operator willing to run a real pass alongside us.
"The pass will come whether or not you are ready. Everything we build is about being ready."
NIOSAT — Satellite Orbit & Ground Control.