Automotive Functional Safety

Working Rules

• Build or review the item definition before classifying hazards or proposing controls.
• Express hazards as malfunctioning behavior in an operational situation, not as internal faults alone.
• Justify Severity, Exposure, and Controllability separately before proposing an ASIL.
• Derive safety goals, safe states, and FTTI only after the hazardous event is stable.
• Treat ASIL decomposition as an argument that must be demonstrated, not as relabeling.
• Challenge independence, freedom from interference, shared resources, and dependent failures whenever redundancy is claimed.
• Do not claim ISO 26262 compliance simply because a mechanism exists. Check allocation, interfaces, response timing, verification, and evidence.
• Mark missing telemetry, failure-rate sources, diagnostic coverage, fault-injection evidence, tool qualification, or assessment independence as explicit gaps.
• For review tasks, lead with concrete findings and release risks before summaries.

Workflow Routes

Concept and HARA

• Use references/hazard-analysis-risk-assessment.md and references/artifact-templates.md.
• Build the artifact in this order:
  1. item definition
  2. malfunctioning behaviors
  3. operational situations
  4. hazardous events
  5. S/E/C classification with rationale
  6. ASIL
  7. safety goals, safe state, and FTTI
• Prefer compact HARA rows plus rationale blocks over long prose.
• If the user gives incomplete context, state assumptions explicitly instead of inventing hidden project facts.

Safety Concept and Architecture

• Use references/iso-26262-overview.md, references/safety-mechanisms-patterns.md, and references/agent-workflow.md.
• Check allocation from safety goals to FSRs/TSRs/HW/SW responsibilities.
• Review or draft:
  • functional safety concept
  • technical safety concept
  • safe-state strategy
  • degradation behavior
  • safety monitoring
  • ASIL decomposition argument
  • dependent-failure controls
• When architecture is mixed-ASIL or partitioned, ask what proves independence at hardware, software, timing, and communications levels.

Analysis and Metrics

• Use references/fmea-fta-analysis.md.
• Pick the analysis shape that matches the task:
  • FMEA for bottom-up failure-mode review
  • FMEDA for hardware metrics and diagnostic coverage
  • FTA for top-event reasoning and minimal cut sets
• Cross-check analyses instead of treating them as isolated artifacts.
• For metric discussions, separate:
  • failure-rate assumptions
  • safety mechanisms and claimed coverage
  • residual failure behavior
  • resulting SPFM, LFM, and PMHF
• If metrics miss the target, propose the smallest credible design or diagnostic change that closes the gap and state the tradeoff.

Software Safety

• Use references/software-safety-requirements.md.
• Trace the path from safety goals to TSR/FSR, then to SWR, architecture, implementation constraints, and verification.
• Focus software reviews on:
  • fault detection and timeout behavior
  • safe-state transitions
  • defensive logic
  • partitioning or interference risks
  • communications assumptions
  • testability and evidence
• Treat MISRA and MC/DC as supporting evidence, not as substitutes for safety behavior.
• If code seems reasonable but the safety case is weak, say that directly.

Verification, Validation, and Assessment

• Use references/safety-verification-validation.md, references/safety-assessor.md, and references/artifact-templates.md.
• Route work by need:
  • requirements review and static analysis for early evidence
  • requirements-based testing and traceability for implementation maturity
  • fault injection and HIL for mechanism effectiveness and FTTI
  • assessment workflow for readiness, findings, and closure planning
• Classify findings as critical, major, minor, or observation.
• End every readiness review with:
  • unresolved evidence gaps
  • minimum closure actions
  • release or next-phase recommendation

Project Planning and Deliverables

• Use references/functional-safety-deliverables.md when the user asks for project planning, lifecycle mapping, or expected work products.
• Organize large requests by lifecycle phase:
  • concept
  • system development
  • hardware or software development
  • integration and verification
  • validation and assessment
  • production and field monitoring
• Prefer phase-specific outputs, owners, and entry-exit criteria over generic ISO 26262 summaries.

Agent-Style Passes

Use references/agent-workflow.md when the user wants an agent-style workflow or when the problem benefits from role-based passes. By default, emulate the passes sequentially in one answer:

1. Safety engineer / orchestrator pass
2. HARA or analysis specialist pass
3. Architecture / decomposition pass when relevant
4. Validation / assessor pass

Use real delegated subagents only if the user explicitly asks for delegated or parallel agent work.

Output Shapes

• For HARA drafting, prefer:
  • Context
  • HARA table
  • Rationale
  • Safety goals
  • Assumptions
• For concept or architecture work, prefer:
  • Context
  • Safety goals and constraints
  • Architecture or concept
  • Mechanisms and allocation
  • Risks
  • Next-phase deliverables
• For analysis work, prefer:
  • Scope
  • Method
  • Key contributors
  • Metric or top-event result
  • Design implications
• For reviews and assessments, prefer:
  • Scope
  • Findings
  • Missing evidence
  • Recommended next actions

Default Prompts

• Use $automotive-functional-safety to draft a HARA for unintended brake torque loss in an EV brake controller.
• Use $automotive-functional-safety to review this ASIL-D software safety concept for missing mechanisms, evidence gaps, and weak assumptions.
• Use $automotive-functional-safety to assess whether this FMEDA and FTA package is credible for an ISO 26262 review.
• Use $automotive-functional-safety to prepare a functional safety assessment readiness review for this ECU project.