SEECA Workbench

1. What this tool does

It runs a single event effect criticality analysis as a worklist. You describe the mission (phases, environments, duration, fleet, risk posture), then one row per function, part and effect mode: what the effect does locally, how it propagates, what the system consequence is, what mitigations are credited, and what evidence exists for the rate. The workbench derives the criticality class, converts the mission requirement into a tolerable rate or a probability budget, predicts the rate in the nominal and worst case environments, grades the evidence, reports a status and a margin, flags the worst case exposure, writes the test a null result would have to show to close an open row, draws the assurance argument, and exports the whole thing as a Markdown report, a CSV worksheet and a JSON file you can reload.

2. A ten minute walk through

1. Pick a preset. The COTS camera preset is a published case study whose nominal rate the engine reproduces; the smallsat preset shows every class and every status. Or start empty.
2. Set the mission frame. Duration, number of vehicles, whether a critical loss anywhere in the fleet counts against the budget, the probability budget for critical functions, and how much wider a margin weak evidence must show. The risk posture selector fills these with editable starting points; they are this site's illustrations, not values from a standard.
3. Define the phases. Each phase has a fraction of mission time, a nominal environment, a worst case environment and a default availability. A row can be active in any subset of phases.
4. Add rows. One per function, part and mode. Fill the function first: it is the thing the system loses. Then the part, the mode, the local effect, the propagation and the consequence. Pick the consequence from the list; the class depends on it.
5. Credit mitigations. Tick what the design actually has. Each one changes the model and adds a verification note to the open items.
6. Enter the evidence. A Weibull per device, a rate you computed elsewhere, or a null result. Choose the grade honestly. The reference field is for the report.
7. Read the row panel and the summary. Then the open items: each says what would close it.
8. Export. Download the Markdown report and the JSON. Save in the browser if you want to come back.

3. Inputs, and what they do

• Copies of the part. Multiplies the rate. Eight identical switches carrying one function are eight chances.
• Sensitive fraction. Duty cycle times sensitive window. Multiplies the rate. Justify it from the operating concept; the report lists it as an assumption.
• Independent strings. For destructive modes, the budget is spread over the strings as p to the power 1/r. For non destructive modes it is informational; hot redundancy with switchover is a mitigation that masks.
• Consequence. Six categories with severities 1 to 4. Severity 1 and 2 make a row Error-Critical whatever the mode. "Masked" makes it Error-Functional. The rest are Error-Vulnerable unless a masking mitigation is credited.
• Recovery time. Detection plus recovery, and for ground recovery the contact interval plus the procedure. For an availability requirement it sets the tolerable rate one for one.
• Requirement form. Probability budget (critical), availability, minimum interval between events, maximum count over the mission, or mitigation capacity. Leave it on the default for the class unless the project states it otherwise.
• Evidence form. Weibull per device with the site environments (cosine law for upsets, transients and functional interrupts; no angular enhancement for latchup and burnout, or as you override); a rate entered directly for the nominal and worst case environments; or a null result with fluence, maximum effective LET, confidence, the saturated cross section assumed above the tested LET, and whether the effect has a sharp threshold.
• Evidence grade. A to E. C, D and E are weak and must show the mission frame's weak evidence margin to pass. A null result is always grade D.

4. Reading the output

• Class badge. Derived from the decision tree drawn beside the editor, or set by you; the report says which.
• Predicted per day. Mission mean over the row's phases, per function (all copies of the part), in the nominal environments. The row panel shows each phase and its worst day rate.
• Tolerable per day. The most demanding active phase. For critical rows it is the rate that would just spend the probability budget.
• Margin. Tolerable over predicted, or budget over probability of loss. Above one passes with strong evidence; weak evidence needs the wider margin.
• Flags. Worst day exposure for vulnerable rows, worst day probability for critical rows, protection credited without application evidence, masking credited with an open verification.
• Test prescription. For rows that fail, are marginal or have no data: the effective LET and fluence a clean run would need, or the statement that no null test can close the row.
• Margin map. Every row plotted by margin and severity. Left of the red line fails; the amber band is where weak evidence has not yet earned a pass.
• Assurance argument. The selected row as a goal structured argument. The assumptions are what a reviewer should push on.

5. Caveats

• The environments are five CREME96 sets behind 100 mil of aluminium. Other orbits, shielding depths and proton dominated cases must be computed elsewhere and entered as rates.
• Worst case solar particle event models differ by factors of several. The worst case column is a scale, not a forecast.
• Events are treated as independent Poisson arrivals; redundancy arithmetic ignores time ordering and common cause.
• The class defaults, mission class starting points and evidence margins are this site's choices. Your project's requirements documents override them.
• A null result to 1e7 ions per square centimetre cannot demonstrate a rate below a few times 1e-5 per part per day for a gradual effect in the galactic cosmic ray environment. That is a property of null testing, and the tool will tell you when a row runs into it.
• Nothing you enter leaves your browser. Saving in the browser uses local storage, which some browsers clear; download the JSON for anything you want to keep.

6. References

Back to the tool