University engineering · ML-D Mission Systems

A Digital Twin lab for configuration, evidence, and V&V reasoning.

Students take a mission requirement to a traceable, bounded engineering conclusion on the same accepted Digital Twin schools use. The public Lab and Mission Control provide software practice; Mission Studio is the signed-in workspace for configured persistent work.

Enter the Digital Twin Lab Run University 3U Mission Control Sign in to Mission Studio

Academic depth

ML-D · Mission Systems

Mission catalogue

13 pilot missions

Workspace

Mission Studio

Truth boundary

SIMULATED · 0 measured

What the lab is for

One lab, two roles: students do the engineering, faculty own the course.

What the lab is

A software-only engineering lab on the same accepted Digital Twin schools use. Missions run on shared models; the University depth shows configuration, provenance and evidence detail rather than a separate simulator.

What students do

Frame a mission requirement, run it, compare two spacecraft configurations, check evidence quality and write a bounded verification-and-validation conclusion.

What faculty do

Choose missions, set the engineering question, map outcomes to their own approved course objectives and assess the work with their own rubric. Grading and accreditation stay with the institution.

Mission Studio, Mission Control and evaluation

Three connected surfaces over one engineering truth.

Where a mission lives

Mission Studio

Create a mission, revise it, run it and keep its evidence together over its whole lifecycle. This is the signed-in workspace for persistent professional and University engineering work.

The engineering instrument

Mission Control

Inspect a run: telemetry channels, units, provenance, same-seed comparison and replay. It is an engineering capability, not a separate product.

Run University 3U Mission Control

A governed evaluator entry

Evaluation

Organisations evaluating the platform receive a provisioned evaluation link. After signing in, an authorised author activates it explicitly; it then opens an evaluation-scoped reference mission. It is not a public route.

One accepted core. Different disclosure.

The academic demand changes; model ownership and physical truth do not.

Digital Twin Lab workflow

A coherent route from requirement framing to evidence review, using accepted lessons and Mission Control.

Open the full workflow

Frame a requirement

Start with an ML-D mission, a bounded configuration, and a claim the accepted runtime can actually test.

Mission objective · success criterion · declared limitation

Open the reference ML-D mission

Inspect configuration identity

Use the university 3U teaching definition and inspect the selected model bindings before interpreting results.

Spacecraft definition · model/version identity · configuration hashes

Inspect advanced identity

Run Mission Control

Execute one deterministic software-only practice run, then inspect units, channel roles, source models, and freshness.

Immutable local replay · simulated and derived channels · zero measured channels

Enter engineer Mission Control

Compare and replay

Use the existing same-seed comparison to study how the school 1U and university 3U teaching definitions change the run.

Shared seed · synchronized replay cursor · baseline/variant deltas

Open synchronized comparison

Review evidence quality

Separate availability, provenance, fidelity, calibration, validation, and parameter source instead of collapsing them into one quality label.

Independent fidelity axes · lineage · limitations · Evidence V2 export

Review fidelity and lineage

Map to the course

Faculty can map MissionLab outcomes and evidence into their own approved CLOs without transferring accreditation authority to CubeSTEM.

Illustrative CLO label · MLO trace · mission evidence · assessment method

Review mapping examples

School and university are deliberately different

They share model truth while exposing different levels of engineering detail.

Guided disclosure

School mission journey

Mission question and bounded controls
Grade-appropriate units, plots, and provenance
Evidence selection and engineering decision

Boundaries

Internal hashes and detailed lineage stay out of the primary journey
Engineering workbenches remain clearly labelled secondary surfaces

Engineer and advanced disclosure

University · ML-D Mission Systems

Configuration, component/model identity, and independent fidelity axes
Channel units, roles, provenance, freshness, hashes, and lineage
Comparison, replay, Evidence V2 export, and V&V limitations

Boundaries

Developer Core access is opt-in local/private; source clients create no browser or learner credential flow
No measured channel, hardware authority, or flight qualification is implied

Engineering evidence stack

Mission Control already owns these presentation capabilities; the university journey points into it rather than creating a parallel dashboard.

ML-D and Mission Control disclosure available in this build.
Layer	What engineers can inspect
Configuration	University 3U teaching definition and bounded scenario selection
Model identity	Component/model IDs, versions, provider context, and hashes
Channels	Units, roles, source fields, freshness, and explicit availability
Provenance	Simulated, derived, reference, estimated, and measured remain distinct
Fidelity	Representation, fidelity, calibration, validation, and parameter source stay independent
Lineage	Definition, execution, compile, run, frame, and evidence identities where provided
Evidence	Same-seed compare, immutable local replay, limitations, JSON and Markdown exports
V&V boundary	Software evidence supports bounded conclusions, not flight qualification

KFU / UMP illustrative programme scenarios

Non-official demonstration content showing how faculty could frame existing missions. These examples are not institution-reviewed mappings or endorsements.

Illustrative · non-officialKFU

Attitude-to-power verification studio

Space systems · controls · electrical power

A student team traces a declared attitude change into modeled solar-energy evidence, checks reproducibility, and writes a bounded V&V conclusion.

Mission: MLX-15
Twin definition: university_3u_engineering

Review scenario and CLO example

Illustrative · non-officialUMP

Orbit-to-contact evidence review

Mission operations · communications · systems engineering

A student team distinguishes modeled visibility from reception and decode, then produces a requirements-based contact-plan evidence review.

Mission: MLX-07 · MLX-06
Twin definition: university_3u_engineering

Review scenario and CLO example

Thirteen runnable missions at ML-D depth

Every item remains a PILOT_LESSON pending educator review and classroom evidence. ML-D adds engineering disclosure and V&V demand, not new physics.

Pilot lessonMLX-15

Point the spacecraft. Change the power.

Choose an orientation strategy by comparing how pointing changes modeled solar-energy collection.

Inspect ML-D contract summary

Configuration: Reference hold → Corner-biased hold
Visible channels: solar_energy, battery_soc, equivalent_solar_incidence, geometry_limitation, coupling_policy_hash, composition_compile_identity, composition_semantic_hash, attitude_quaternion, thermal_exposure
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this software cannot tell you about a real spacecraft.

Open at ML-D depth

Pilot lessonMLX-07 · MLX-06

Find the pass. Plan the contact.

Find a modeled visibility window and make a contact plan without claiming signal reception or data delivery.

Inspect ML-D contract summary

Configuration: Short window (2 h) → Extended window (4 h)
Visible channels: orbit_ground_track, pass_window, mission_state, rf_eligibility
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Your evidence shows the satellite was in view. Explain why that is still not proof that any data arrived.

Open at ML-D depth

Pilot lessonMLX-03

Survive the dark side.

Compare two spacecraft profiles through the same modeled eclipse and recommend the more resilient energy strategy.

Inspect ML-D contract summary

Configuration: Small satellite (1U) → Larger satellite (3U)
Visible channels: solar_energy, battery_soc
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this model does not tell you about how a real spacecraft would cope.

Open at ML-D depth

Pilot lessonMLX-02

Can you trust what the spacecraft tells you?

Separate simulated truth from estimated state while comparing perfect and realistic instruments.

Inspect ML-D contract summary

Configuration: Perfect instruments → Realistic instruments
Visible channels: mission_state, attitude_angle, control_error
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this model does not tell you about real instruments.

Open at ML-D depth

Pilot lessonMLX-01

From launcher to first contact.

Inspect a bounded deployment sequence and decide which step prevents a safe first-contact attempt.

Inspect ML-D contract summary

Configuration: This deployment · single bounded case
Visible channels: mission_state, attitude_angle
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this model does not tell you about a real deployment.

Open at ML-D depth

Pilot lessonMLX-04

Point it where you want it.

Compare two bounded control responses and recommend the one that best balances pointing accuracy and actuator demand.

Inspect ML-D contract summary

Configuration: Weak controller → Tuned controller
Visible channels: attitude_angle, control_error
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this model does not tell you about a real control system.

Open at ML-D depth

Pilot lessonMLX-05

Stop the tumble.

Compare modeled detumble responses and select the damping strategy that reaches a stable state most effectively.

Inspect ML-D contract summary

Configuration: Light damping → Strong damping
Visible channels: attitude_angle, control_error, overshoot
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this model does not tell you about stabilising a real spacecraft.

Open at ML-D depth

Pilot lessonMLX-09

Working hard gets hot.

Compare two spacecraft under the same modeled workload and recommend the one that manages temperature and energy more effectively.

Inspect ML-D contract summary

Configuration: Small satellite (1U) → Larger satellite (3U)
Visible channels: solar_energy, battery_soc, thermal_exposure
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this model does not tell you about a real spacecraft in orbit.

Open at ML-D depth

Pilot lessonMLX-08

Take the picture. Get it home.

Choose a camera profile by balancing modeled image detail against storage and downlink delivery.

Inspect ML-D contract summary

Configuration: Simple camera → High-detail camera
Visible channels: mission_state, nadir_eligibility, payload_effective_activity
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this model does not tell you about a real camera in orbit.

Open at ML-D depth

Pilot lessonMLX-10

Make the budgets close.

Evaluate two declared configurations against every modeled mission budget and choose which can proceed.

Inspect ML-D contract summary

Configuration: 1U trainer design → 3U engineering design
Visible channels: mission_state
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this configuration study does not establish about a real spacecraft.

Open at ML-D depth

Pilot lessonMLX-11

Find out what went wrong.

Trace the modeled failure sequence and recommend one policy change that addresses the decisive cause.

Inspect ML-D contract summary

Configuration: This mission · single bounded case
Visible channels: mission_state
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this model does not tell you about recovering a real mission.

Open at ML-D depth

Pilot lessonMLX-13

Write the rule before you need it.

Use modeled fault evidence to write one testable condition-and-action policy rule.

Inspect ML-D contract summary

Configuration: This mission · single bounded case
Visible channels: mission_state
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: Name one thing this model does not tell you about whether your rule is safe to fly.

Open at ML-D depth

Pilot lessonMLX-14

Did you watch it long enough?

Test whether a claim based on a short observation remains supportable after a longer run of the same model and seed.

Inspect ML-D contract summary

Configuration: Short run (30 min) → Long run (2 h)
Visible channels: solar_energy, mission_state, attitude_angle
Evidence quality: Keep simulated, simulated_sensor, estimator_state, derived, reference, and measured distinct. Never label simulated as measured.
V&V limitation: The long run is better evidence. Name one thing it still does not establish.

Open at ML-D depth

Evidence and recognition boundary

Developer API access is opt-in, local and private. There is no public production API, and no hosted learner code execution.

Technical details: developer access and service boundaries