← All projects

MAAX Ultraviolet Imager Proof of Concept

A student team proving out an auroral UV camera concept on a weather balloon, run with model-based systems engineering. I'm the team's risk officer.

SponsorsMathWorks & U-M Space Physics Research Lab

RoleRisk Officer, Avionics team

TimelineAug 2026 to present

MethodsMBSE, SysML, FMEA, design reviews

01 / MISSION

Imaging the aurora in ultraviolet

MAAX, the Magnetospheric Auroral Asymmetry eXplorer, is a NASA Heliophysics Small Explorer mission proposal led by the University of Michigan. Its MAAX Ultraviolet Imager (MUVI) would photograph the aurora in two far-ultraviolet bands to study how the northern and southern auroras differ.

Our team of 14 (a mix of AEROSP 388 students and upper-level 488 leads) is building a proof of concept for that imaging analysis. The flight demonstration is a CubeSat-style payload carried to about 90,000 ft by weather balloon, with a lens and filter system, avionics, and a camera. We brief MathWorks and SPRL stakeholders every two weeks and move through formal design reviews.

Concept of operations: the satellite orbits at 37,000 km, the camera takes in two ultraviolet passbands through an iris, baffles, and lenses onto a microchannel plate detector, and compressed images are sent to a ground station — **Fig. 1**Team concept of operations for the camera optics. Light passes through an iris, baffles, and lenses that isolate the LBHS (144 ± 8 nm) and LBHL (173 ± 8 nm) passbands onto a microchannel plate (MCP) detector. Compressed images go to the ground.

02 / REQUIREMENTS

A requirements model, not a document

The project runs on model-based systems engineering. Instead of a requirements spreadsheet, the team keeps a SysML model in which every requirement is an element linked to where it came from and how it will be verified.

L0 · CustomerWhat SPRL and MathWorks need: capture the auroral oval in both passbands, survive the balloon flight, and recover from an unexpected power loss.
L1 · SystemDerived system requirements for resolution, temporal cadence, operating temperatures, mass, and data downlink.
L2 · SubsystemSeparate requirement trees for avionics, software and data, and mechanical, each traced to the L1 requirements it supports.
L3 · ComponentRequirements on specific parts such as the filter wheel, lenses, transmitter, and flight computer, each with a verification method: test, inspection, analysis, or demonstration.

SysML use case diagram showing avionics, software and data, and mechanical subsystems inside the CubeSat, with the flight computer, ground station, and power source as actors — **Fig. 2**Use case diagram for CubeSat operations: how sensor activation, data storage, compression, downlink, and the filter wheel interact across subsystems.

SysML state machine for photographing the aurora: verify power, check current filter, rotate the filter wheel, take a picture, transfer data — **Fig. 3**State machine for photographing the aurora: verify power, check the filter, rotate the filter wheel if needed, image, and transfer.

03 / RISK

Running risk for a 14-person team

As risk officer I lead the team's risk management strategy and the failure mode and effects analysis (FMEA). Each risk is scored from 1 to 5 on severity, probability, and detectability, and the product is its risk priority number:

RPN = Severity × Probability × Detectability     (each 1–5, max 125)

RPN ≤ 30     acceptable · signed off by the risk officer
31 – 75      mitigate   · sub-team leads or risk officer
RPN > 75     critical   · chief technical engineer, chief of systems, or chief of operations

The strategy also defines who owns what. The chief of systems signs off on integration and communication risks, the chief of operations on cost and schedule, the chief technical engineer on safety and technical risks, and I can close any non-critical risk. Severity scores are tied to dollar ranges so a "major" failure means the same thing to every sub-team.

Risk management flow: 488 leads, sub-teams, and the risk officer identify hazards in the FMEA table, determine priority, accept or assign mitigation, redesign if mitigation fails, and re-evaluate before each design review — **Fig. 4**The risk process from the strategy document. Anything above 30 gets an owner and a mitigation plan. If mitigation fails, the affected system is redesigned and every related risk is re-scored.

Fig. 5All 26 risks at the System Requirements Review, across system (SYS), avionics (AVN), mechanical (MEC), and software and data (SAD). The two critical risks both threaten the balloon test itself.

The two critical risks were not exotic hardware failures. SYS.06: cold at altitude could defocus the camera lens and clouds could fog the optics, producing footage nobody can use, and we wouldn't know until the payload was recovered. SYS.07: repeated testing could quietly degrade the UV components before flight. Both scored high mainly because they're hard to detect, which points mitigation toward thermal testing at flight temperatures and toward knowing each component's limits before it goes into a test setup.

The plan re-scores every risk before and after each review. RPNs are expected to drop through PDR and CDR as designs and mitigations firm up, with the goal of every risk under 30 by the flight readiness review. A burn-down chart tracks the total by subsystem. The strategy was signed off by the full team on September 28, 2026.

04 / NEXT

Toward the balloon flight

The objectives and requirements have been carried through several design reviews to a baseline. On the avionics side I'm now integrating the lens architecture, avionics, and camera for the weather balloon flight to 90,000 ft. This page will grow as the project reaches PDR, CDR, and flight.