ASP Fellowship II cheat sheet

Risk is defined as the combination of the probability of occurrence of harm and the severity of that harm; safety is freedom from unacceptable risk, not zero risk.

Residual risk is the risk remaining after protective measures have been applied; ALARP requires demonstrating that further risk reduction is grossly disproportionate to the benefit gained.

Bow-tie model links threats and preventive barriers on the left to consequences and mitigative barriers on the right, with the top event in the center.

Fault tree gates: AND gate output probability equals the product of independent input probabilities; OR gate output equals 1 minus the product of (1 minus each input probability).

Swiss-cheese model treats accidents as alignment of holes in successive defensive layers; each layer has latent and active failures rather than a single root cause.

Risk matrix cells combine severity and likelihood categories; the matrix ranking is ordinal, so scores from different matrices are not comparable.

Inductive methods (FMEA, HAZOP) reason from cause to consequence; deductive methods (fault tree, event tree) reason from consequence back to causes.

Pareto principle in safety data: a small proportion of hazard types typically accounts for most of the loss; prioritize by contribution to total risk, not by count alone.

A system safety program plan (SSPP) defines scope, organization, responsibilities, tasks, milestones, deliverables, and risk acceptance authority for the program.

MIL-STD-882E organizes safety tasks into eight elements, including hazard identification and evaluation, assessment and mitigation, and tracking and risk acceptance.

Hazard tracking log fields: hazard ID, description, causal factors, severity/likelihood, mitigation, owner, status, residual risk, acceptance signature, closure date.

Risk acceptance authority is delegated by severity level; higher-severity residual risks require sign-off at a more senior level than low-severity risks.

Safety review boards verify that hazards are closed only when objective evidence of effective mitigation exists, not when a scheduled date arrives.

Tailoring of safety tasks must be documented with justification; omitted tasks require a recorded rationale and approval.

Independent safety assessment uses reviewers outside the design team's reporting chain to reduce confirmation bias in hazard closure decisions.

Configuration management ties hazard records to specific hardware/software baselines so that design changes trigger re-evaluation of affected hazards.

HAZOP uses guide words (no, more, less, as well as, part of, reverse, other than) applied to process parameters at defined nodes to generate deviations.

FMEA rates severity, occurrence, and detection; the risk priority number is the product of the three, and ties in RPN should be broken by severity.

Preliminary hazard list/analysis is performed early, before detailed design, using energy sources and generic hazard checklists.

Energy trace and barrier analysis identifies energy sources and evaluates barriers that separate the energy from the target.

A hazard is a potential source of harm; a mishap/accident is the realized event; a causal factor is a condition or action contributing to the hazard.

What-if analysis is a brainstorming technique using structured 'what if' questions against a process or design description.

Hazard tracking must record closure evidence and re-open hazards when design changes, new operational modes, or incidents reveal invalid assumptions.

Sneak circuit analysis looks for unintended paths or logic conditions in electrical/software systems that produce undesired functions without component failure.

Severity categories typically range from negligible to catastrophic; likelihood categories from frequent to improbable; each combination maps to a risk index or level.

Quantitative risk assessment expresses risk as frequency of harm per unit time (e.g., fatalities per year) or per demand; qualitative assessment uses ordinal categories.

ALARP decision rule: if risk reduction cost is grossly disproportionate to benefit, the risk is tolerable; otherwise reduce further.

Individual risk criteria are often stated as maximum tolerable frequency of fatality per person-year; societal risk uses F-N curves plotting cumulative frequency against number of fatalities.

Risk cannot be accepted without documented authority, rationale, and awareness of residual risk by the accepting party.

Comparative risk ranking requires a common severity/likelihood scale; mixing scales across analyses invalidates comparison.

Risk mitigation hierarchy: eliminate the hazard, reduce severity, reduce likelihood, add detection/warning, then administrative controls and PPE.

As-low-as-reasonably-practicable demonstration requires documented cost-benefit reasoning, not merely a statement that risk is low.

Human error types: slips (correct intention, wrong execution), lapses (omission/memory failure), mistakes (wrong intention), and violations (deliberate deviation).

Skill-, rule-, and knowledge-based behavior model: errors differ by level; knowledge-based tasks have higher error probability and slower response.

Human error probability (HEP) is the likelihood a required human action fails; Technique for Human Error Rate Prediction (THERP) provides generic HEP tables adjusted by performance shaping factors.

Performance shaping factors include workload, time pressure, training, procedures, environment, fatigue, and interface design.

Human reliability analysis should model the human as part of the system, including detection, diagnosis, decision, and action phases.

Task analysis decomposes operator tasks into steps to identify error-likely points and required cues/feedback.

Error-forcing context is a condition (e.g., ambiguous alarm, missing feedback) that makes an error highly likely regardless of operator skill.

Human-machine interface design principles: consistent mapping, clear feedback, error-tolerant entry, and avoidance of mode confusion.

Software cannot fail randomly in the hardware sense; software safety addresses systematic faults introduced by requirements, design, and coding errors.

Software safety integrity levels (e.g., IEC 61508 SIL 1-4, DO-178C levels A-E) are assigned from the hazard severity/consequence of the function the software supports.

Safety requirements must be traceable from hazard analysis to software requirements, design, code, and verification evidence.

Defensive programming and independence (diverse software, dissimilar implementations) reduce common-cause software failure risk.

Complex electronic systems require analysis of unintended function, not only failure to function; both must be considered in hazard analysis.

Configuration data and parameter tables are part of the safety-critical software baseline and require the same verification rigor as code.

Common-cause failure analysis examines shared resources (power, clock, bus, libraries) that could defeat redundancy.

Software change impact analysis must re-evaluate hazards when requirements, tools, compilers, or operating systems change.

Inherently safer design hierarchy: minimize, substitute, moderate, and simplify; these are preferred over added-on protective devices.

Safety-critical functions require defined proof-test intervals; the probability of failure on demand rises between tests according to the test interval.

Lockout/tagout isolates hazardous energy before maintenance; verification of zero energy state is required before work begins.

Management of change ensures that modifications to equipment, procedures, or personnel are reviewed for safety impact before implementation.

Permit-to-work systems control hot work, confined-space entry, and other high-risk maintenance activities.

Pre-startup safety review confirms that construction and equipment meet design specifications and that safety systems are functional before operation.

Operator procedures must be validated against actual task performance; procedure usability affects error probability.

Maintenance-induced faults (e.g., incorrect reassembly, wrong part) are a recognized hazard category requiring specific controls.

Standards are consensus documents; regulations are legally enforceable requirements; compliance with a standard does not by itself satisfy a regulation unless the regulation adopts it.

IEC 61508 addresses functional safety of electrical/electronic/programmable electronic safety-related systems and defines SILs.

ISO 26262 applies functional safety to road vehicles; ASIL A-D is assigned from severity, exposure, and controllability.

DO-178C governs airborne software; ARP4754A governs aircraft system development; ARP4761 covers safety assessment processes.

MIL-STD-882E is a U.S. Department of Defense standard for system safety; its task structure is widely referenced in other sectors.

ISO 45001 specifies requirements for occupational health and safety management systems, including hazard identification and risk control.

IEC 61882 provides guidance on HAZOP studies; IEC 60812 covers FMEA and FMECA.

Compliance evidence must be retained and traceable to the specific standard revision invoked at the time of assessment.

Investigation sequence: preserve evidence, gather facts, establish timeline, identify causal and contributing factors, determine recommendations, and track closure.

Root cause analysis methods include 5-Why, fishbone (Ishikawa) diagram, fault tree, and barrier analysis; multiple contributing factors are typical.

Just culture distinguishes human error (console), at-risk behavior (coach), and reckless behavior (sanction) to encourage reporting.

Lessons learned must be disseminated to affected programs and incorporated into procedures, training, and design standards to close the loop.

Leading indicators (near-miss reports, audit findings, training completion) predict future performance better than lagging incident counts alone.

Corrective actions require owners, due dates, effectiveness verification, and re-audit; closure without verification is a recurring weakness.

Incident classification and reporting thresholds are defined by regulation and internal procedure; near misses often have lower thresholds than injuries.

Trend analysis of incident and near-miss data by hazard type, location, and shift identifies systemic weaknesses for continuous improvement.