SEE analysis, mission budgets, and open items
Set the ground rules, the budgets and the mission, bring in the parts from the BOM screener, and follow each part and effect through one row of the ledger. The workbook turns every rate into expected occurrences, checks transients and power devices against their ratings, rolls it all up against the budgets, checks itself, and writes the report.
Identification
Ground rules and budgets
Mission frame
Phases
Critical events
How it works
Preparing and reviewing the analysis
Set the rules and the mission
Budgets for each impact level, the requirement statements, the mission phases with their environments, the critical events the design must work through, and how the solar storms are applied to each.
Follow each part and effect through a row
Each row follows one effect on one part instance from the part to the circuit to the system, names the detection, the provisions and the recovery, takes a rate from a Weibull, a null result, the EDAC engine or direct entry, and turns it into expected occurrences.
Roll up against the budgets
Counts add up by impact level, board, phase and critical event, and the loss probability combines the rows' survivals. The checks flag the usual mistakes, open items collect what is left, and the report writes it all down.
What the workbook does, where it sits, and what it is not
A single event effects analysis kept the way a flight program keeps it: ground rules and budgets, the mission phases and critical events with their environments, the functions, every susceptible part instance, and one row per instance and effect that follows the event from the part to the circuit to the system, names the detection, the provisions and the recovery, assigns a residual impact, converts the rate into expected occurrences, and rolls everything up against the budgets. It imports the BOM screener's hand off, computes rates against the site's environments, sends protected memory through the EDAC engine, checks transients against downstream ratings and power devices against derated survival voltages, lints itself for the usual mistakes, and writes the report.
Where it sits. The criticality analysis of the public NASA guidance sorts functions by how bad an event would be; this workbook is the bookkeeping that follows, and it folds that sorting in as one column. Its output is not a class per function but a table per impact level: how many times it is expected over the mission, with what likelihood, from which parts, and whether that is inside what the mission can take. The site's other tools are its suppliers: the BOM screener finds the susceptible parts and the public data, the rate integration and the priors put a number on each row with a grade attached, the EDAC engine gives the multi bit residual for protected memory, the analog SET guideline and the power device derating advisor feed the two electrical branches.
What it is not. It does not replace test data, a circuit simulation of a transient, or an engineer reading the schematic. Every number it produces carries the grade of the evidence behind it, and the report says so.
Reading the results
Review priorities. Whether every susceptible part has its rows and whether every row with a non negligible impact has a count: check completeness before interpreting the totals. Which rows dominate each impact level: a single event analysis is usually driven by one or two parts, and those are where a design change or a test buys the most. And whether the storm assumption is what breaks a budget: if the expected outages sit almost entirely in the storm term, the question becomes whether the requirement should be written per storm rather than per mission, and that is a conversation with the customer, not a redesign.
The report
The Markdown report is written to be read by a reviewer who was not in the room: what was verified, under which assumptions, with what coverage, and what is left. A completed analysis has no open rows, no non compliances, no errors in the checks, and a design that has not changed since; anything else is a preliminary analysis, however good.
Methodology and the why behind the what
This section says where each part of the workbook comes from, why it is shaped the way it is, and what it does not do. It is written for the engineer who has to produce the analysis and for the one who has to review it.
What the analysis verifies
A single event effects analysis is a verification of two things: that no part in the design can be permanently damaged by one particle, and that every effect that is not permanent is reversible, tolerable and inside what the mission has said it can take. The first is a circuit question answered by voltages and thresholds; the second is a system question answered by tracing an event from the part to its consequence and counting how often it will happen. The public guidance from NASA's SEECA work and the NESC avionics RHA guidelines, and the requirements of ECSS-Q-ST-60-15C, all describe this same pair of questions [1], [2], [3]. The workbook states the pair as requirement statements on the first tab and everything after that is evidence for or against them.
Recording effects and checking mission budgets
The criticality analysis in the public guidance sorts functions into those where an event is unacceptable, those where it is tolerated at a low rate, and those where it is absorbed [1], [2]. That sorting is necessary and the workbook keeps it as a column, but it is not what a project signs. What gets signed is a table that says how many safe mode entries, outages and corrupted data sets to expect over the mission, from which parts, and whether that is within the budgets in the requirements. That number only exists if every susceptible part instance has been walked through the same questions and the answers kept in one place with the arithmetic attached. The ledger is that place, and the coverage counters exist because the first question a reviewer asks is what fraction of the susceptible parts were actually analyzed.
The impact scale and the budgets
Five levels: no effect, data corrupted, data or function outage, safe mode or ground recovery, and loss. They are ordered by what they cost the mission, and a row takes the worst level that applies. The first three that cost something are judged as expected counts, because an outage is a thing that happens a number of times; loss is judged as a probability over the mission, because it happens once. The labels are editable so that a project can use its own words; the order is not. The budgets that come with a risk posture are this site's illustrations of what such missions tend to accept, not values from any standard, and the report says the analyst edited them. The one rule that is not editable: a safe mode entry during a critical event can be counted as loss of the event, because the event was defined as the interval the design had to work through.
Mission frame: phases, events and the storm
The same part in the same circuit has a different answer during a four hour deployment and a three year cruise, so the frame is phases with durations and environments, and critical events that the design must work through rather than recover after. The nominal environment is a CREME96 galactic cosmic ray or low Earth orbit set behind 100 mils of aluminum [4]. The solar particle environment is transient and must never be applied for a whole mission; the workbook offers two treatments. For long phases it applies the worst week fluxes for seven days N times a year, with N an explicit assumption of the analysis (one per year is the default illustration; the count varies with the solar cycle and the orbit's magnetic shielding). For critical events it assumes the storm coincides with the event and applies the environment matched to the event's duration: the peak five minutes for intervals under a day, the worst day under a week, the worst week beyond. Matching the storm to the duration is what makes a twenty minute burn and a three year phase comparable. Which storm, and how many, is a question about the concept of operations: an orbit insertion or a descent that must succeed is judged with the storm present, a multi year survey is judged on the expected number of storms it will see, and the workbook makes that choice visible per phase and per event rather than burying it in a rate.
From a rate to a count
Every row carries rates per device per day in each environment, from one of four sources: entered directly (from a test report, a manufacturer's number, or another tool), a Weibull cross section integrated against the site environments with the cosine law for upsets and transients and no angular enhancement for latchup and burnout, a null result turned into a bound, or, for protected memory, the EDAC engine. The expected count for a phase is the nominal rate times the phase duration plus the storm term, times the number of copies and the sensitive fraction; the probability of one or more is one minus the exponential of the count. Counts add across phases and events; probabilities of loss combine as one minus the product of survivals. A missing storm rate is filled from the most severe one available, which is conservative, and the row says so.
Protected memory
Error correction turns a bit upset rate into a much smaller word failure rate, but not zero, and the residual depends on the scrub interval and on the storm: two upsets in one word between scrubs is a rate that goes as the square of the bit rate, so it is the storm environment matched to the scrub interval, not the mission average, that sets it. The workbook therefore takes a per bit rate per environment on the memory row and calls the EDAC engine [5] for the uncorrectable rate in each, then treats those as the row's rates. The single bit row is separate and is normally a no effect row; forgetting the multi bit row, or applying the mission average bit rate to it, are two of the classic errors the lint looks for.
The two electrical branches
A transient on a regulator or a comparator has to be checked as a voltage before it is checked as a function: every part downstream that sees it is listed with the voltage it sees and its absolute maximum rating, and the row fails if any is exceeded, whatever the function does. Derating is not the criterion here; a transient is a stress of microseconds and the question is damage, so the absolute maximum is the limit. The amplitude and width come from a test on the part, a simulation with the flight load, or the bound in the analog SET guideline for the family [6]. A power device is checked the other way: its maximum applied voltage, including transients and bus overshoot, against a survival voltage from a test at the required LET or from the derating advisor, with a derating factor (0.75 by default) on the survival voltage, following the practice in the NASA and JPL power device guidelines [2], [7]. A failure on this branch cannot be analyzed away; the part or the voltage has to change, and the workbook lists it as a non compliance.
Recovery, detection and the class
Each row states how the event or its symptom is seen and what clears it, and picks one of five recovery types: tolerant, self clearing, autonomous, ground, or none. The recovery type and the impact are checked against each other (no effect with ground recovery is a contradiction; no recovery is loss) and against the ground rule on ground intervention. The criticality class of the public guidance is then derived: loss or no recovery is error critical, no effect is error functional, everything in between is error vulnerable and lives on its budget. The class is informational here; the budget is the requirement.
Coverage, lint and what would close a row
The workbook counts parts, instances, susceptible effects without a row, rows with a non negligible impact and no rate, rows not closed, and rows with weak evidence. The lint runs on every change and looks for the mistakes that reviewers find over and over: phase durations that include storage, the peak storm rate used for a two year phase, memories with correction credited in the text but no residual row, transient rows with no downstream list, allocations that add to more than one device's worth of events, counts too large to be true. For a row that fails or has no data it uses the SEECA test prescription [8] to say what a null result would have to show for the row to fit inside the budget share left to it.
When to do it
The workbook has a planning stage because the expensive decisions are made before the parts list exists. Destructive susceptibility must be off the table before the design is baselined: a part that can be destroyed cannot be mitigated by software, and every remedy (a different part, a lower voltage, shielding, another architecture) is cheaper before the layout. Correction, scrubbing, voting, watchdogs and safe modes are architecture, and they cost mass, power and board area, so they have to be planned from the part families the design intends to use. The preliminary analysis follows the candidate design and finds the exceptions while there is still time to fix them; the final analysis follows the flight design and is done when it matches it. Any later change reopens it. The NESC guidelines and ECSS-Q-ST-60-15C both put the analysis on this schedule [2], [3].
The worked example
A fictional 3U CubeSat command and data handling board with fifteen public part numbers, three years at 500 km, a four hour deployment and detumble event, and one worst week storm a year. The parts and their public data come from the BOM screener hand off; the rows were written to exercise every path: no effect rows, a protected SRAM buffer through the EDAC engine, a buck regulator transient checked against the FPGA and processor rails, a latchup prone SRAM whose expected latchup count alone breaks the outage budget and has to be replaced, a null result bound on an MRAM, a small signal MOSFET on the destructive branch, two transceivers with no data, and a processor whose raw SRAM upsets in the storm term dominate the outage count. That last finding is the example's real lesson: the mission budget is exceeded almost entirely by restarts concentrated in storm weeks, which is either a memory protection change or a requirement written per storm rather than per mission, and only the customer can say which. The cross sections are the analyst's fits and estimates, graded as such; they are not test results.
Limits
Five environments, all behind 100 mils of aluminum; other orbits, shielding depths and trapped proton upsets must be computed elsewhere and entered as rates. Single vehicle arithmetic; a fleet is handled by running the workbook per vehicle type and multiplying. No multiple cell upset statistics beyond what the EDAC engine models. No circuit simulation: the transient branch checks the numbers you give it. No fault tree: the cross reference fields carry the identifiers of the FMECA entries and fault protection monitors so that the two analyses can be reconciled, but the reconciliation is done by people.
Files and formats workbook, hand off, report, ledger, SEECA export
Save workbook file and Download the workbook (JSON) write the whole workbook in the open format space-rha-seea-workbook, version 1; Open a workbook file reads it back. Save in this browser keeps one copy in the browser's local storage, and Restore from this browser brings it back; nothing is sent anywhere.
Import BOM screener hand off, on the Parts tab, reads the file that the BOM screener's Export for SEEA button writes (format space-rha-seea-parts, version 1): every BOM line with its public data, technology decision, priors and document references. The board name typed above the parts table is applied to the imported parts.
The Report tab downloads the report as Markdown or copies it to the clipboard, downloads the ledger as CSV, and exports the workbook in the SEECA format that the SEE availability tool opens.