How to Run a Single Event Effects Analysis: Process, Timing, Roles and Review

A single event effects analysis starts before part selection and documents more than event rates. It follows every susceptible part through the same set of questions, keeps the answers and the arithmetic in one place, and ends in a document a second engineer can check and a program can close against its requirements. This guide describes the process. The SEE Analysis Workbook is the place to keep it; the tools it draws on are listed at the end.

1. What the analysis has to show

Two things, and they are different kinds of question. First, that no part in the design can be permanently damaged by a single particle: latchup that is not limited and cycled, burnout or gate rupture in a power device, dielectric rupture. That is a circuit question, answered by thresholds and voltages, and it has to be answered by prevention because there is no software fix for a destroyed part. Second, that every effect that is not permanent is reversible and tolerable: the function comes back, health and safety are never at risk, no irreversible action is triggered, and the expected number of upsets, transients, functional interrupts and their consequences stays inside what the mission has said it can take. That is a system question, answered by tracing an event from the part to its consequence and counting how often it happens.

The public guidance agrees on this pair. NASA's criticality analysis method sorts functions by how bad an event would be and traces the propagation; the NESC avionics RHA guidelines describe the analysis and its place in the requirements flow; ECSS-Q-ST-60-15C requires it and says what it must document. None of them will do it for you, and none of them tells you what your mission can tolerate. That number comes from the mission, and getting it written down is the first job.

2. The eight parts of a complete analysis

Ground rules. Write the requirement statements the analysis verifies: no permanent damage; effects reversible and tolerable; health, safety and irreversible actions protected; occurrences within budgets. Then the budgets: how many safe mode entries per year, how many hours of outage, how much corrupted data, and what probability of loss over the mission is acceptable. Decide whether ground intervention counts as a recovery and name the critical events, the intervals the hardware has to work through rather than recover after. Every one of these changes the answer for the same part in the same circuit.

Mission frame. Phases with durations in flight time (storage does not count), the environment in each, the operating modes of the equipment, and the critical events with their durations. The solar particle environment is transient and is never applied for a whole mission: long phases take an assumed number of storm weeks per year, critical events assume the storm coincides with them, and the storm is matched to the interval, the peak minutes for intervals under a day, the worst day under a week, the worst week beyond. Which storm and how many is a concept of operations question and it belongs in the assumptions list.

Functional picture. A block diagram of what the equipment does, so that an effect can be traced from a part to a circuit to a function to the system. Consequences attach to functions; a part that serves two functions gets a row for each.

Susceptible parts. A parts list screened for which parts can show which effects and at what threshold, from test data or a defensible prior when there is none. Every instance counts. The BOM screener does this from public data and hands the result to the workbook.

Effects and impacts. For each susceptible instance and effect: what the part does, what the circuit does, what the next level and the system do; how the event or its symptom is detected; what clears it or makes it tolerable; whether recovery is inherent, self clearing, autonomous or ground based; and the worst residual impact after mitigation, on a short scale that ends in loss. Two effects need an electrical check before the functional one. A transient from a regulator or comparator is checked against the absolute maximum ratings of everything downstream, and fails the analysis if it exceeds one whatever the function does. A power device is checked as applied voltage, including transients, against a derated survival voltage from a test or the derating advisor, and if it fails there is nothing to analyze: the part or the voltage changes.

Occurrences. Rates per environment converted to expected counts per phase and critical event, with copies and the sensitive fraction applied, and the probability of one or more from the count. Protected memory is a special row: the single bit errors are corrected and cost nothing, the multi bit residual is computed from the scrub interval with the storm rate matched to that interval, because two upsets in one word between scrubs go as the square of the bit rate. Rates are only needed for rows whose impact is not negligible; deciding that first saves most of the work.

Roll up and compliance. Counts summed by impact level for the board, the subsystem and the system, against the budgets; coverage statistics that say how many susceptible parts exist, how many are analyzed, how many have counts, how many are open; a compliance matrix; a plain list of non compliances; the parts that dominate each level.

Documentation, review and closure. A report with the requirements verified, the assumptions, the functional picture, the ledger, the roll up, the compliance matrix, the open items and the work to go, reviewed independently against a checklist, and closed by meeting the requirements, changing the design, or an accepted waiver. The analysis is done when it matches the flight design, not at a review milestone, and any later change reopens it.

3. When each part has to be done

Before the design is baselined. Destructive susceptibility has to be off the table. A part that can latch up without protection, or a power device operated near its survival voltage, cannot be mitigated later; every remedy is cheaper before the layout exists. This needs the candidate part families and their radiation data, from public sources or from tests scheduled early enough to matter. The mitigations for non destructive effects are architecture: error correction, scrubbing, voting, watchdogs, safe modes cost mass, power and board area, and they have to be planned from the part families the design intends to use. A one page plan by technology family, expected effects and intended mitigations, is what the preliminary design review should see.

After the candidate design exists. The preliminary analysis: every susceptible part on the candidate schematic and parts list through the eight parts above, with bounding assumptions where data are missing, so that the exceptions are known while the design can still change. Refine the analysis before changing the design, change the design before asking for a waiver.

Before committing to the flight build. The final analysis matches the flight schematics and parts list, closes the open items from the preliminary one, and either shows compliance or carries an accepted waiver for each exception. Any design change after that, including a change in how the software responds to an event, reopens the rows it touches.

4. Who supplies what

The environment: someone has to own the mission radiation environment, the phases, and the storm assumptions. The part susceptibility: someone has to say which parts can show which effects, from data or from a prior, and provide rates for the ones with non negligible impacts. The circuit and functional analysis: the designer, because the designer knows what the circuit does when a part misbehaves and what the software does next. The system consequence: the systems and fault protection engineers, because they own the safe modes, the budgets and the critical events. The independent review: someone who did not write it. In a large organization these are five groups; in a small company they may be two people and this site. The site can be the susceptibility and rate supplier, with an evidence grade on every number, but it cannot read your schematic.

5. Common review findings

• Rates in the wrong units. Per bit and per device, per day and per second, mixed on one sheet. Keep everything per device per day and write the bit count on the row.
• Durations that include storage, or a mission length used where a phase length belongs.
• The peak storm rate applied to a two year phase, or the mission average bit rate applied to a multi bit calculation. Match the storm to the interval and say how many storms a year you assumed.
• Memory analyzed without its correction, giving upset counts in the thousands, or with its correction but without the multi bit residual, giving zero.
• One instance analyzed where the board carries four.
• A transient analyzed as a function without listing the parts that see it as a voltage.
• A latchup credited as recoverable with no statement of how the current is limited and the power cycled, or a survival test of the part with the protection in the loop.
• Rates with no traceable source. Every number needs a document, a record or a tool run behind it.
• Impact set to negligible because the analyst could not think of a consequence, rather than because the design tolerates it.
• A safe mode entry during a critical event counted as a safe mode entry rather than as loss of the event.
• The analysis finished against a design that has since changed.

6. A reviewer's checklist

• Are the requirement statements and the budgets written down, and do they match the mission's own documents?
• Do the phases sum to the flight time, with the storm assumption stated per phase and per critical event?
• Does every susceptible part on the screened parts list have a row for every effect it can show, with every instance counted?
• Does every row describe the part behavior, the circuit and system effects, the detection and the provisions in words a designer would recognize?
• Is the recovery type consistent with the impact, and is ground recovery only credited where the rules allow it?
• Does every row with a non negligible impact have a rate with a source and a grade, converted to a count with the right environment for the interval?
• Are memories with correction carried as two rows, single bit and multi bit residual?
• Are transient rows checked against downstream absolute maximum ratings, and power devices against a derated survival voltage?
• Do the counts by impact level meet the budgets, and does the list of largest contributors make physical sense?
• Is every non compliance either fixed by a design change or carried as a waiver, and is every open item owned?
• Does the configuration analyzed match the flight design, schematic revision by schematic revision?

Frequently asked questions

Related tools and pages

• SEE Analysis Workbook: the ledger, the arithmetic, the roll up and the report, with a worked CubeSat example.
• Part Lookup and BOM Screener: susceptible parts, public data, priors and the hand off to the workbook.
• SEE Rate Assessment: rates from cross sections and environments.
• EDAC and Scrubbing: the multi bit residual for protected memory.
• Analog SET Guideline: transient amplitude and width bounds by family.
• Power Device Derating Advisor: survival voltages for the destructive branch.
• Latchup Protection Sizing: the current limit and power cycle a latchup row credits.
• SEE Availability: system availability from the workbook's SEECA format export.
• Guides from elsewhere: the NASA, ESA and manufacturer documents this process leans on.

References