SEECA Workbench: Single Event Effect Criticality Analysis

Methodology and the why behind the what

This section explains where each step of the workbench comes from, why it is shaped the way it is, and what it cannot do. It is written for the engineer who has been handed a parts list and a mission and told to "do the SEE analysis", and for the systems engineer who has to sign the result.

Why a criticality analysis at all

Total dose is a budget: dose accumulates, a part degrades, and the question is whether it degrades past its limit before the mission ends. A single event effect is not a budget. It is a random arrival, and the question is how often it arrives, what it does when it does, and whether the system notices. That difference is why the traditional reliability toolkit fits SEE so badly and why NASA commissioned a study in the mid 1990s to codify what experienced radiation and systems engineers were already doing informally [1]. The authors' own diagnosis is worth restating in plain words: systems engineers often had an incomplete picture of the actual SEE risk, radiation specialists had an incomplete picture of the mission trade space, and the result was ad hoc treatment that could launch with unrecognised risk or, just as often, spend money and mass hardening things that did not matter [1].

The remedy they proposed has three parts, and the workbench is built around them: describe the system by the functions it performs rather than by its boxes; sort those functions by how bad an SEE would be (criticality); and trace how a device level event propagates to a system level consequence so that the sorting is honest. With those three, an SEE requirement stops being a single number stamped on every part and becomes a set of function level requirements that a design can actually be traded against [1], [2].

Why function, not location

Total dose requirements vary by location because shielding works on the electrons and protons that deposit dose. Heavy ions of the galactic cosmic ray background are not stopped by any practical shielding, and the proton flux that drives upset in sensitive parts is only modestly attenuated, so SEE requirements cannot be relaxed by moving a box deeper into the vehicle [1]. What does change the requirement is what the part does. A bit flip in a solid state recorder protected by error correction is invisible; the same bit flip in the program memory of the flight computer is a reboot; the same bit flip in a register that holds a thruster command is a safety event. Same part, same cross section, same rate, three different requirements.

That is why the workbench keys every row on a function, and why one part can appear in several rows: the analog switch in the loaded case study is one part number in two roles, and its two roles carry different consequences, different tolerable rates and different classes [3]. It is also why the functional breakdown matters more than the parts list. A reorientation manoeuvre involves attitude sensing in one box, command generation in a second and a thruster driver in a third; if the rows are organised by box, the path from an upset in the first to a false firing in the third is easy to miss [1].

Why it is an FMECA that FMECA tools cannot do

The 1996 study describes SEECA as a specialised failure modes, effects and criticality analysis [1], and the 2020 restatement is blunter: it is an FMEA, but the tools do not fit the bill [2]. The reasons are structural. An FMECA failure mode is a permanent failure with a failure rate; most SEEs are recoverable events with an occurrence rate, and the system consequence depends on how long recovery takes, which the part does not know. FMECA severity categories assume the failure has happened; for SEE the same event can be masked, tolerated or catastrophic depending on the mitigation around it. And FMECA has no natural place for the sensitive time window, the fraction of time in which the event actually matters, which can move an SEE consequence by orders of magnitude [1].

What survives from FMECA is the discipline: one row per failure mode, an explicit local effect, an explicit propagated effect, a severity, a detection method and a compensating provision. The workbench keeps all of those columns and adds the ones SEE needs: the class, the tolerable rate or probability, the predicted rate in two environments, the evidence grade, and the margin. The severity numbering (1 worst to 4) follows the four level convention shared by the military FMECA standard and the European space FMECA standard, so a row can be pasted into a conventional criticality matrix if the project keeps one [10], [11].

The three classes and where they come from

The 1996 study proposed three criticality groups for single event upset and noted that the same tree serves other non destructive effects [1]. The 2021 case study states them in one sentence each: Error-Critical, a function where SEE are unacceptable; Error-Vulnerable, a function where a low probability of SEE is required and a response with mitigation, or an accepted risk, is permissible; Error-Functional, a function that may be unaffected by SEE because of error correction, mitigation or redundancy, where a large probability of events may be acceptable [3].

The workbench turns that into a decision tree with four questions. Is the part level effect destructive or permanent, or a latchup without protection? If so the row is Error-Critical whatever the function, because the consequence is a lost part and the only question is the probability of losing it; if the function has an independent spare, the budget is spread over the strings. If not destructive, does the propagated consequence reach severity 1 or 2, loss of mission or permanent loss of a function? A non destructive event that reaches that far, a false pyro command from a flipped register, is still Error-Critical. If not, is the effect masked before it propagates by error correction, voting, filtering or hot redundancy? Then it is Error-Functional and the requirement moves onto the mitigation. Otherwise it is Error-Vulnerable and the requirement is a rate. The tree is this site's rendering of the published logic, and the analyst can override the class on any row; the override is recorded as such in the report because a reviewer should know which classes were derived and which were asserted.

Two things the classes are not. They are not device requirements: the 1996 study is explicit that the functional requirement is met through some combination of device hardness, hardware mitigation, software and redundancy, and that the device requirement falls out of that choice rather than the other way round [1]. And they are not fixed for the mission: a function can be Error-Critical during a burn and Error-Functional during cruise, which is why rows are tagged with phases.

Turning a mission requirement into a tolerable rate

The 1996 study says requirements are specified for each functional group as the maximum probability of SEE occurrence permitted, and that they may differ by effect type [1]. It does not say how to get the number, because the number comes from the mission. The 2021 case study shows the derivation in the field: the power chain must not lose the amplifiers during a measurement more than once in 30 minutes, the video chain more than once in 120 seconds, and each of those is converted directly into a rate per device per day and compared with the prediction [3]. The workbench offers four forms of that conversion and one budget.

The availability form deserves a word because it is the one most projects actually hold. Unavailability contributed by a recurring recoverable event is its rate times its outage duration, so the tolerable rate is the unavailability allowance divided by the recovery time. Recovery time is therefore the most powerful number on a vulnerable row and the most often understated: for a ground recovered event it is the contact interval plus the time to notice plus the procedure, not the reboot time of the box. The mission frame carries a ground latency default for exactly this reason, and the row editor asks for the recovery time in seconds so that the arithmetic is visible.

Why destructive effects are budgets, not rates

Burnout, gate rupture, dielectric rupture and unprotected latchup do not recur. They happen once and the part is gone. A rate per day is the wrong description of a thing that can only happen once; the right description is the probability that it happens at least once in the mission, P = 1 - exp(-lambda T) for a Poisson arrival, summed over every copy of the part and every vehicle whose loss counts against the budget. The workbench holds the budget on the function, spreads it over redundant strings as p to the power 1/r on the crude assumption of independent losses, and reports the probability directly. It also lists a "critical rate line", the per function rate that would just spend the budget over the mission, because engineers think in rates and it helps to see how small the allowed rate is: for a one percent budget over five years it is about 5.5e-6 per day.

The starting values of the budget by risk posture are this site's illustrations of how projects of different classes tend to behave, not numbers from any standard, and the mission frame lets you overwrite them. What the workbench will not do is credit a destructive mode as tolerable at some rate: a row whose part level effect is destructive is Error-Critical unless a protection is credited that turns it into an interrupt, and that protection carries its own verification note.

Two environments, not one

The 1996 environment chapter frames the definition problem as two questions: what is the normal environment under which the mitigation and the operations plan must cope, and what is the worst case the mission will encounter, when peak proton belt fluxes or the peak of a solar particle event could cause catastrophic data loss or permanent damage [1]. The workbench keeps both for every phase. The nominal environment sets the mission mean rate, the expected events and the unavailability. The worst case environment produces a separate column, the events expected in one worst day, and two flags: a vulnerable row expecting one or more interruptions on the worst day needs an operations response, and a critical row whose worst day alone carries a visible probability of loss is a candidate for an operational constraint during solar particle events.

The site environments are CREME96 sets behind 100 mil of aluminium: galactic cosmic rays at solar minimum, the ISS orbit, and the worst week, worst day and peak five minute solar particle event spectra [4]. The published camera case study quotes a near Earth interplanetary rate at solar minimum of 1.55e-4 transients per device per day; this engine gives 1.56e-4 with the same Weibull [3]. The same paper quotes 0.48 per day for its October 1989 worst day; this engine gives 0.12 for the worst day set and 0.45 for the peak five minute set. Solar particle event models differ by factors of several in the tail, and that spread is the honest uncertainty on every worst case column here. For other orbits, shielding depths or proton dominated environments, compute the rate in the SEE rate tool and enter it directly on the row.

The propagation ladder

The 1996 study devotes a chapter to propagation and lays out a ladder: device, circuit, subsystem, system, spacecraft, with each level treating the one below as a black box and asking only what the anomaly looks like from outside [1]. Its worked example is a calibration memory upset in an analog to digital converter that shifts every sample by a fixed offset; at the circuit level a temperature reading is offset, at the subsystem level a box appears ten degrees hotter than it is, at the spacecraft level a limit is exceeded and a heater is turned off or a safing entered [1]. Nothing was destroyed and nothing was even wrong for long, and yet the consequence reached the spacecraft.

The workbench asks for the ladder in two text fields, the local effect and the propagation, and then asks you to pick the consequence from a fixed list. The fixed list is deliberate: the consequence is what the class and the requirement hang on, and a free text consequence cannot be sorted. The device level step also matters for which rows exist. The study's table of sensitive areas by device type, memory cells versus control logic in a memory, registers versus combinational logic in a processor, the analog versus the digital section of a converter, is the reason a single part can need several rows with different modes and different consequences [1].

Sensitive windows and duty

An upset only matters if the system reads the upset state before it is overwritten. The 1996 study makes the point with a solid state recorder: an SRAM is written once between downlinks and read once at playback, so an upset that lands between the playback and the next write is overwritten unseen, and the read and write accesses themselves take tens of nanoseconds, so the window in which an upset during access is observed is tiny [1]. The same logic applies to an unused peripheral, to a bus driver hit while the bus is idle, to a register that is reloaded every cycle. The workbench carries a single sensitive fraction per row, the product of the duty cycle and the sensitive window, and multiplies the rate by it.

It is the easiest number on the page to abuse. A fraction below one has to come from the operating concept and the design, not from a wish, and the report records it as an assumption on the row so that a reviewer can ask for the justification. The flags also warn when the worst day rate is high enough that the window argument stops mattering: a transient every few minutes during a solar particle event finds any window eventually.

Evidence grades and what a null result proves

The 2020 restatement lists the evidence a SEECA rests on as test data and mitigation, and names the outcome trades as part or design change, accept as is, mitigate, or test [2]. The workbench grades the evidence on a five step ladder: measured on this part in the application, measured on this part in a generic condition, a similar part or heritage data, a bound from a null result, and nothing. The bottom three are weak, and the mission frame asks a wider margin of them before a row passes, because a heritage rate can be off by an order of magnitude and a null result is not a measurement at all.

What a null result does prove is worth being exact about, because it is the most common form of SEE evidence in a commercial parts programme. No events in a fluence F at a maximum effective LET L caps the cross section at L to about 2.3/F at 90 percent one sided confidence, and by monotonicity caps it at every lower LET as well. It says nothing above L. The workbench therefore integrates two terms: the capped cross section from the low LET end of the heavy ion spectrum up to L, and an assumed saturated cross section above L, for which the die area is the honest default. For a sharp threshold effect such as latchup or burnout, a null result whose fluence times the assumed area is ten events or more establishes that the threshold lies above L and the first term is dropped; for a gradual effect such as an upset or transient it is kept, and it has a floor that surprises people. With the galactic cosmic ray spectrum behind 100 mil of aluminium, the flux above LET 1 is about 180 per square centimetre per day, so a null result to 1e7 ions per square centimetre can never demonstrate a rate below about 4e-5 per part per day for a gradual effect however high the LET. That is a limit of null testing, not of this tool, and it is why tight vulnerable requirements need a measured cross section curve rather than a screen.

The angular model is chosen by the mode. Upset, transient and functional interrupt curves fitted to normal incidence data are integrated with the thin rectangular parallelepiped cosine law that CREME style rate codes use, which is what reproduces the published case study rate [3], [4]. Latchup, burnout, gate rupture and every step shaped bound are integrated with no angular enhancement, because the sensitive volumes are deep and the cosine law's grazing incidence term would otherwise inflate a step at LET 85 by five orders of magnitude. For a non planar part whose angular response is measured, fit it in the alpha law tool and enter the resulting rate directly.

When you need to test, and how much

The 2020 restatement lists among the benefits of SEECA that it can answer the question of when you need to test [2]. The workbench makes that concrete for every row that fails, is marginal or has no data. It searches for the lowest effective LET at which the assumed saturated cross section above that LET would fit inside the tolerable rate (inside half of it for a gradual effect, leaving the other half for the capped term below), and then computes the fluence that would pin the capped term to the remaining allowance at 90 percent confidence, with a floor of 1e6 ions per square centimetre because a smaller run is not a test. If the LET needed exceeds 85, or the fluence exceeds 1e8, the row is reported as not closable by a null test: it needs a measured cross section curve, a defensible smaller area, mitigation or a design change. If the LET needed is low and the fluence small, the row is reported as loose and any standard screen closes it.

The open items panel sorts these by severity and by how far the row is from its limit, which is the order in which test money buys the most. It is a prioritisation, not a test plan; the standards page holds the test method guides and the facilities, and the SEL test LET and beam calculator pages do the run planning.

Mitigation, and what each one does to the model

The 1996 mitigation chapter sorts system level effects into data effects and control effects and walks through the toolkit for each: parity and cyclic redundancy checks that detect, Hamming codes that correct one and detect two, Reed Solomon codes that correct bursts, protocol level retries, watchdogs and health and safety tasks for processors, and it notes that the complexity and overhead of a scheme rise roughly with its power [1]. The 2021 case study adds the analog side: passive filtering that damps a transient below the downstream threshold, and the recognition that some applications cannot be filtered because of timing or impedance and must be argued on rate instead [3].

The workbench's catalogue does not describe mitigations; it changes the model when one is credited, and it records what would have to be shown for the credit to stand. Error correction, voting, filtering and hot redundancy mask the effect and move the row to Error-Functional with a verification note; the note for error correction points to the EDAC tool because an uncorrectable rate is a real number and a masked row is only as good as it. Watchdogs, scrubbing and detect and retry schemes cap the recovery time, which raises the tolerable rate one for one. Current limiting with a power cycle turns a latchup row from destructive to an interrupt, and the flag reminds you that the evidence should include a test with the protection in place. A cold spare adds a string and the budget is spread across strings. Derating of a power device scales the rate by a placeholder until the derating advisor has been run. An operational constraint scales the exposure and the note insists that the constraint be enforced by the flight software or the timeline rather than by intent.

The assurance argument

The 2020 restatement introduces goal structuring notation as the way to keep track of what a SEECA produces, and the 2021 case study shows a full argument for one part: the mission availability requirement as the top goal, the modelled environment as context, the SEECA and the test data as strategy and solution, and every unsubstantiated claim tracked as an assumption [2], [3], [5]. The value is traceability: a reviewer can follow the requirement down to the evidence and see which boxes are assumptions.

The workbench generates that argument from the row. The goal is the function's requirement in the tolerable form; the context is the environment, duration and fleet; the strategy is the class with its derivation; the sub goals are the rate or probability claim and, where mitigation is credited, the claim that the mitigation performs; the solutions are the evidence and the mitigation verification notes; the assumptions are the sensitive fraction, the assumed area above the tested LET, the angular model, independence of strings and anything you typed into the assumptions field; and the justification is the consequence and the propagation. It is drawn in the shapes the public standard uses, rectangles for goals, parallelograms for strategies, rounded solutions, and it is only as good as the row. That is the point: it makes the row's weaknesses visible.

When in the project to do this

Both the 1996 study and the 2021 avionics guideline place SEECA inside the hardness assurance flow rather than at the end of it: define the mission environment, application and lifetime; identify the hazards; evaluate the design; set requirements; mitigate or accept or test; verify; iterate [1], [6]. In practice that means three passes. An early pass, before the architecture is frozen, that assigns classes to functions and decides which mitigations the architecture will carry, because error correction, redundancy and watchdogs are cheap to add on paper and expensive to add after layout. A preliminary pass on candidate schematics and parts lists that produces the first worklist, finds the rows that fail or lack data, and sizes the test programme. And a final pass on the flight design that updates every row to the as built schematics and parts, closes the open items by test, mitigation, design change or documented acceptance, and is reviewed independently. The analysis is not done when the report is written; it is done when every row is closed and the design it describes is the design that flies.

What the document must contain

The 2020 restatement lists the inputs a SEECA needs, the environment description, the hardness assurance plan, the concept of operations with reliability and availability by phase, and the application information including the parts list and worst case analyses, and what it contains, the functional analysis, the criticality and consequence categorisation, the rates of non destructive effects and the likelihoods of destructive ones, and the system level risks [2]. The Markdown export from this page produces the worksheet, the per row detail with per phase rates and flags, the test prescriptions, the assumptions and a review checklist. What it cannot produce is the prose that makes the analysis stand alone: the functional block diagrams, the description of the flight usage, the schematics referenced, the manufacturer data used, the test reports attached, and the compliance matrix against the project's requirements with the closure plan for every exception. Write those around it.

Review checklist

The checklist appended to every exported report, for the reviewer and for the author before the review.

Limits of this workbench

It is a bookkeeping and arithmetic tool for a method, not a substitute for the method. It does not know your design; the functional analysis, the propagation and the consequence are yours, and the class it derives is only as good as those. Its environments are five CREME96 sets behind one shielding depth; anything else must be computed elsewhere and entered as a rate. It treats events as independent Poisson arrivals, which is right for cosmic ray induced effects and wrong for correlated failures. Its redundancy arithmetic ignores time ordering and common cause. Its mission class defaults are illustrations. Its test prescriptions assume a single ion campaign to one effective LET and do not consider protons, which need their own analysis (the proton proxy and SEE rate pages). And it knows nothing about total dose or displacement damage, which change cross sections and thresholds late in life and belong in the hardness assurance plan alongside this analysis.

References