SEE Analysis Workbook

An analysis aid. The numbers carry the grade of the evidence behind them; a row with an analyst's estimate is a reason to test, not a result. Full disclaimer.

1. What it does

It keeps a single event effects analysis as one ledger. You state the ground rules and budgets, describe the mission phases and critical events with their environments, list the functions, import or enter the parts, and write one row per part instance and effect: what the part does, what the circuit and the system do, how it is detected, what clears it, what kind of recovery that is, and the residual impact. Each row gets a rate from a test number, a Weibull, a null result or the EDAC engine, converted into expected occurrences per phase and per critical event. The workbook rolls the counts up by impact level against the budgets, counts coverage, checks the transient and destructive branches, lints the whole thing for the usual mistakes, lists the open items, and writes the report. The criticality classes of the public SEECA guidance are derived as a column.

2. A worked example

• Load the worked example. It is a fictional CubeSat command and data handling board with public parts; open the Ledger tab and click rows to see how each path is filled in, then the Results tab to see what the roll up looks like.
• Start your own. New blank workbook, then Rules and mission: identification, posture (edit the budgets to what your requirements say), ground recovery, phases with durations and storm treatment, critical events, assumptions.
• Functions. List what the equipment does with a criticality; consequences attach to functions.
• Parts. Screen your BOM on the BOM screener, use its Export for SEEA button, and import the file here. Every line arrives with its public data, technology decision and priors, and a suggested list of effects. Map each part to a function, correct the susceptibility ticks, and seed the rows.
• Ledger. Click a row. Fill the propagation, pick the recovery and the impact, choose the rate source and enter its inputs, grade the evidence and cite it. Transient rows get a downstream list; power devices get the voltage check; protected memory gets the EDAC inputs. Close the row when it is done.
• Results. Coverage, expected occurrences against budgets, largest contributors, non compliances, checks and open items.
• Report. Download the Markdown report, the CSV ledger and the JSON workbook; save in the browser to come back.

3. Inputs, and what they do

• Posture and budgets. The posture fills the budgets with an illustration; the numbers you leave are the ones the roll up is compared with. Counts per year are multiplied by the mission years. Loss is a probability over the mission.
• Ground recovery. When not allowed, any row that credits ground recovery is a non compliance.
• Safe mode during a critical event. When it counts as loss, safe mode rows contribute their event probability to the loss figure.
• Phases. Days of flight time (storage does not count), the nominal environment, and the storm treatment: episodes (N worst weeks per year, seven days each) or coincident (the storm matched to the duration for the whole phase). Leave episodes per year blank to use the mission default.
• Critical events. Hours, and coincident by default: the storm matched to the duration is assumed to be happening. Rows can opt out of events they are not exposed to.
• Susceptible to. The effects a part can show; every ticked effect must have a row or the coverage check fails. The import ticks what the public data and the technology class suggest; correct it.
• Copies and sensitive fraction. Copies default to the part quantity; the sensitive fraction is duty cycle times the fraction of time or state in which the event matters. Both multiply the rate. Justify them in the reference or the assumptions.
• Allocation. The fraction of the device's events that produce this row's impact, when one part feeds more than one row of the same effect. The lint warns when allocations of one part and effect add to more than one.
• Rate sources. Direct: per device per day (or per bit with a bit count) in the nominal and the three storm environments; a missing storm rate is filled from the most severe one you gave. Weibull: saturated cross section, threshold, width and shape, with the angular treatment. Null result: fluence, maximum LET, confidence, assumed cross section above the tested LET, sharp or gradual. EDAC: bits, code, scrub, and per bit rates per environment.
• Transient branch. Amplitude and width, then every downstream part with the voltage it sees and its absolute maximum rating. One exceedance fails the row.
• Destructive branch. Rated, survival and applied voltages with a derating factor on the survival voltage; the applied voltage must include transients and overshoot.
• Grade and reference. A to E as on the SEECA workbench; D and E are weak and show up in the open items until replaced.

4. Reading the output

• Occurrences. Expected count over the mission for the row (copies and sensitive fraction included), split by phase and event into nominal, storm and other terms in the editor.
• P(1 or more). One minus the exponential of the count. For a critical event this is the chance the row fires during the event.
• Class. Error critical, vulnerable or functional, derived from the impact and recovery.
• Budget table. Expected counts by impact level against the budgets; loss as a probability. A "no" is a non compliance.
• Largest contributors. The rows that dominate each level; where a design change or a test buys the most.
• Checks. Errors block compliance; warnings and notes are for the reviewer.
• Open items. Rows not closed, weak evidence, missing branch inputs, susceptible effects without rows, and the items you add by hand.
• What would close it. For a row over its share of the budget or without data, the null result test that would demonstrate the limit, from the SEECA prescription.

5. Assumptions

• Events in different rows are independent; counts add and loss probabilities combine as survivals.
• The storm treatment is an assumption of the analysis and is printed in the report as one.
• The five environments are behind 100 mils of aluminum; trapped protons are not included and belong in the other environment rate.
• The site's budgets are illustrations of postures, not values from a standard.

6. Implementation notes

• Everything runs in the page; nothing is uploaded. The workbook file is plain JSON with a documented format (space-rha-seea-workbook, version 1) and the ledger CSV has one row per ledger row with the computed counts.
• Rates use the site's alpha law engine for the Weibull integration, the SEECA engine for bounds and test prescriptions, and the EDAC engine for protected memory; all three are loaded with the page.
• Save in this browser uses local storage; use the file for anything you want to keep.

7. Limitations

• No circuit simulation and no fault tree; the branches check the numbers you enter and the cross reference fields point at the analyses that do the rest.
• No multiple cell upset statistics beyond the EDAC engine's model; no fleet arithmetic beyond running per vehicle.
• Rates for orbits and shielding other than the five environments have to be computed elsewhere and entered directly.

8. References

Back to the tool · BOM Screener · EDAC and Scrubbing · SEE Rates · Guide: how to run a single event effects analysis