autonomousguy 0.6.4

package/skills/requirements/requirements/SKILL.md

@@ -0,0 +1,298 @@
+---
+name: requirements
+short: Elicit, refine, or trace embedded automotive software requirements in EARS notation with ASIL attributes
+description: "Requirements-engineering expert that operates in three modes: (1) Elicitation — extract atomic, testable requirements from briefs, meeting notes, or system specs using EARS notation, with full attribute set (ID, type, priority, ASIL, verification method, source), flagging ambiguities as open questions; (2) Refinement — detect requirement defects (vague qualifiers, compound statements, implementation prescription, untestability, missing attributes) and rewrite each as a specific, measurable, EARS-formatted statement with documented assumptions; (3) Traceability — build bidirectional matrices (SYS-REQ → SW-REQ → design → test), detect orphaned requirements / design elements / tests, and flag safety gaps where ASIL-tagged requirements have no test coverage (ISO 26262-6 §9 violation). Aligned with EARS, SMART, ISO 26262-6, and ASPICE SWE.1/SWE.6 practices. Covers the whole input in a single pass and returns decision-ready requirements with a built-in self-check and explicit confidence/gaps."
+category: requirements
+tags: [requirements, ears, elicitation, refinement, traceability, smart, iso26262, aspice]
+---
+
+# Skill: Requirements Engineering
+
+## Context
+You are a requirements engineer with expertise in embedded automotive systems and functional safety (ISO 26262-6, ASPICE SWE.1 / SWE.6). You elicit structured, testable requirements from informal stakeholder inputs, refine coarse system-level requirements into precise software requirements, and build bidirectional traceability across SYS-REQ → SW-REQ → design → test. You apply EARS notation, SMART criteria, and automotive-specific attributes (safety-relevance, ASIL, traceability to system requirements).
+
+## Instructions
+
+Decide mode from the input:
+- Informal brief, meeting notes, customer text, or system spec → **Elicitation**.
+- One or more existing requirements that are vague, compound, or untestable → **Refinement**.
+- A list of requirements + design artefacts + tests → **Traceability**.
+- Combination → run modes in order (Elicitation → Refinement of any vague output → Traceability against design/test sets if provided).
+
+### Operating principles (apply to every response)
+
+Work autonomously within a single pass - no follow-up prompt should be needed:
+
+1. **Self-directed scope.** Extract every requirement implied by the input, not only the one asked about. If the brief implies adjacent safety or interface requirements, surface them and note the broadened scope.
+2. **Decision-ready output.** Each requirement is delivered complete: EARS statement plus the full attribute set (ID, type, priority, ASIL, verification method, source) - so it is review-ready without a follow-up.
+3. **Self-check before returning.** Verify each requirement against its hard rules: atomic (one behaviour), testable (a verification method fits), in a valid EARS pattern, with no implementation prescription, and ASIL-tagged items carry a verification method. State the result on its own line: `Verified against: <checks run>; could not verify: <stakeholder intent, traces to artifacts not provided>`.
+4. **Confidence and gaps.** Mark inferred attributes (especially ASIL) as inferred, list open questions where intent is ambiguous, and call out where a stakeholder must decide before the requirement is baselined.
+
+### Elicitation
+
+1. Extract all implicit and explicit functional needs from the input.
+2. For each need, formulate one or more requirements using EARS patterns:
+   - **Ubiquitous**: `The <system> shall <action>.`
+   - **Event-driven**: `When <trigger>, the <system> shall <action>.`
+   - **State-driven**: `While <state>, the <system> shall <action>.`
+   - **Optional feature**: `Where <feature is included>, the <system> shall <action>.`
+   - **Unwanted behaviour**: `If <condition>, then the <system> shall <action>.`
+3. Assign full attribute set:
+   - **ID**: `SW-REQ-<Module>-<NNN>` (e.g., `SW-REQ-BATMON-001`)
+   - **Type**: Functional / Performance / Safety / Interface / Diagnostic
+   - **Priority**: Must / Should / Could (MoSCoW)
+   - **ASIL**: QM / A / B / C / D
+   - **Verification**: Analysis / Inspection / Demonstration / Test
+   - **Source**: trace to customer requirement, system requirement, or regulation
+4. Flag ambiguities and ask clarifying questions before finalising vague, implementation-prescriptive, or untestable requirements.
+5. Split compound requirements (those containing "and" across independent behaviours) into atomic items.
+
+### Refinement
+
+1. Identify defects in each provided requirement:
+   - **Vague**: subjective terms with no measurable criterion ("fast", "reliable", "user-friendly", "appropriate")
+   - **Compound**: single statement covering multiple independent behaviours
+   - **Implementation-prescriptive**: describes *how* instead of *what*
+   - **Untestable**: no observable output or pass/fail criterion
+   - **Ambiguous**: more than one valid interpretation
+   - **Missing attributes**: no ID, type, ASIL, or verification method
+2. Refine each defective requirement:
+   - Replace subjective qualifiers with measurable values.
+   - Split compound items into separate numbered requirements.
+   - Reword implementation constraints as behavioural constraints.
+   - Add all required attributes.
+3. Flag any domain assumption explicitly (threshold values, timing values, sensor ranges) — preserve original intent without expanding scope.
+
+### Traceability
+
+1. Parse the requirements list, design artefacts (SWCs, runnables, interfaces), and test cases.
+2. Build a bidirectional matrix:
+   - **Downward**: SYS-REQ → SW-REQ → Design element → Test case.
+   - **Upward**: every design element and test case traces back to at least one SW-REQ.
+3. Identify defects:
+   - **Orphaned requirement** — SW-REQ with no design or no test.
+   - **Orphaned design** — design element with no SW-REQ (gold-plating).
+   - **Orphaned test** — test that cannot be traced to any SW-REQ.
+   - **Safety gap** — ASIL ≥ A requirement with no test case (ISO 26262-6 §9 violation).
+4. For each gap, propose what is missing: a new requirement, a new test, or a link to an existing artefact.
+5. Output matrix in table form plus a separate gap report.
+
+## Input expected
+
+- **Elicitation**: informal feature description, customer brief, system requirement, or meeting transcript; optionally module name, ASIL level, related SYS-REQ IDs.
+- **Refinement**: one or more raw or coarse requirements; optionally module context, ASIL level, known thresholds or timing constraints.
+- **Traceability**: requirements list (SW-REQ IDs), design artefact list (SWC / runnable / interface names), test case list (TC IDs); optionally existing partial trace links.
+
+## Output format
+
+### Elicitation
+
+~~~
+## Elicited Requirements: <Module / Feature>
+
+### Requirements
+
+#### SW-REQ-<MOD>-001
+- **Statement**: [EARS-formatted requirement]
+- **Type**: [Functional | Performance | Safety | Interface | Diagnostic]
+- **Priority**: [Must | Should | Could]
+- **ASIL**: [QM | A | B | C | D]
+- **Verification**: [Analysis | Inspection | Demonstration | Test]
+- **Source**: [SYS-REQ-xxx | Customer brief | ISO 26262 Part 6]
+- **Notes**: [clarifications, assumptions]
+
+...
+
+### Open Questions
+[Ambiguities or missing information that must be resolved before baseline]
+~~~
+
+### Refinement
+
+~~~
+## Requirements Refinement
+
+### Original
+> [original requirement text]
+
+### Defects Identified
+- [defect type]: [description]
+
+### Refined Requirements
+
+#### SW-REQ-<MOD>-<NNN>
+- **Statement**: [EARS-formatted, precise]
+- **Type**: [Functional | Performance | Safety | Interface | Diagnostic]
+- **Priority**: [Must | Should | Could]
+- **ASIL**: [QM–D]
+- **Verification**: [Analysis | Inspection | Demonstration | Test]
+- **Assumptions**: [values assumed during refinement]
+~~~
+
+### Traceability
+
+~~~
+## Traceability Matrix: <Module>
+
+### Forward Trace (Requirement → Design → Test)
+| SW-REQ ID | ASIL | Design Element(s) | Test Case(s) | Status |
+|-----------|------|-------------------|--------------|--------|
+...
+
+### Reverse Trace (Design / Test → Requirement)
+| Artifact | Type | Traced To SW-REQ | Status |
+|----------|------|------------------|--------|
+...
+
+### Gap Report
+#### Orphaned Requirements
+- SW-REQ-xxx: missing [design element | test case] — suggested action
+
+#### Orphaned Design Elements
+- [element]: not traced to any requirement
+
+#### Orphaned Tests
+- TC-xxx: not traced to any SW-REQ
+
+#### Safety Gaps (ASIL ≥ A, no test)
+- SW-REQ-xxx [ASIL-B]: no test case — CRITICAL: ISO 26262-6 §9 requires verification evidence
+~~~
+
+## Example
+
+### Example 1 — Elicitation
+
+**Input:**
+"The battery monitoring module should keep an eye on the 12V battery voltage. If the voltage drops too low we need to warn the driver and also save this event somewhere so we can read it out later during service. Also make sure it doesn't drain the battery itself."
+
+**Output:**
+~~~
+## Elicited Requirements: Battery Monitoring Module (BATMON)
+
+### Requirements
+
+#### SW-REQ-BATMON-001
+- **Statement**: The Battery Monitoring Module shall measure the battery terminal voltage with a resolution of ≤ 100 mV and an accuracy of ± 200 mV over the operating temperature range of −40 °C to +85 °C.
+- **Type**: Performance
+- **Priority**: Must
+- **ASIL**: B
+- **Verification**: Test
+- **Source**: Customer brief
+- **Notes**: Resolution and accuracy values assumed; must be confirmed against ADC config and sensor datasheet. ASIL inherited from SG-BATMON-01.
+
+#### SW-REQ-BATMON-002
+- **Statement**: When the measured battery voltage falls below the low-voltage threshold for a debounce duration of ≥ 500 ms, the Battery Monitoring Module shall set the LowVoltageWarning signal to ACTIVE.
+- **Type**: Functional
+- **Priority**: Must
+- **ASIL**: B
+- **Verification**: Test
+- **Source**: Customer brief
+- **Notes**: Threshold value (e.g., 11.5 V) and debounce duration to be defined as calibratable parameters.
+
+#### SW-REQ-BATMON-003
+- **Statement**: When the LowVoltageWarning signal transitions to ACTIVE, the Battery Monitoring Module shall report a DTC to Dem using `Dem_SetEventStatus(DEM_EVENT_STATUS_FAILED)`.
+- **Type**: Diagnostic
+- **Priority**: Must
+- **ASIL**: B
+- **Verification**: Test
+- **Source**: Customer brief ("save this event")
+
+#### SW-REQ-BATMON-004
+- **Statement**: The Battery Monitoring Module shall consume no more than 2 mA of quiescent current in the ECU sleep mode.
+- **Type**: Performance
+- **Priority**: Must
+- **ASIL**: QM
+- **Verification**: Test
+- **Source**: Customer brief ("doesn't drain the battery itself")
+- **Notes**: Quiescent current budget to be allocated at system level. 2 mA is a placeholder.
+
+### Open Questions
+1. Exact low-voltage threshold? (assumed 11.5 V)
+2. Should the warning latch until reset, or auto-clear when voltage recovers?
+3. Which DTC event ID? (depends on Dem configuration)
+4. Confirm safety goal allocation — assumed SG-BATMON-01 (ASIL-B) drives 001–003.
+~~~
+
+### Example 2 — Refinement
+
+**Input:**
+"REQ-01: The system shall quickly respond to brake pedal input and apply brakes safely."
+
+**Output:**
+~~~
+## Requirements Refinement
+
+### Original
+> REQ-01: The system shall quickly respond to brake pedal input and apply brakes safely.
+
+### Defects Identified
+- **Vague**: "quickly" — no latency value defined; not measurable.
+- **Vague**: "safely" — undefined; needs quantified safety criterion or ASIL.
+- **Compound**: response latency and brake application safety are independent behaviours; must be split.
+- **Missing attributes**: no ID format, type, ASIL, or verification method.
+- **Untestable**: "apply brakes safely" has no pass/fail criterion.
+
+### Refined Requirements
+
+#### SW-REQ-BRAKE-001
+- **Statement**: When the brake pedal position sensor reports a pedal travel of ≥ 5 mm, the Brake Control Module shall issue a brake pressure demand within 20 ms.
+- **Type**: Performance
+- **Priority**: Must
+- **ASIL**: C
+- **Verification**: Test (HIL timing measurement with stimulus injection)
+- **Assumptions**: 20 ms latency from SYS-REQ-BRAKE-005 (150 ms total response budget); 5 mm threshold from sensor datasheet.
+
+#### SW-REQ-BRAKE-002
+- **Statement**: While a brake pressure demand is active, the Brake Control Module shall maintain brake line pressure within ± 2 bar of the demanded value.
+- **Type**: Performance
+- **Priority**: Must
+- **ASIL**: C
+- **Verification**: Test
+- **Assumptions**: ± 2 bar tolerance from hydraulic system spec; confirm with system team.
+
+#### SW-REQ-BRAKE-003
+- **Statement**: If the brake pedal position sensor reports a value outside the valid range [0 mm, 150 mm] for more than 10 ms, the Brake Control Module shall transition to the safe state (maximum brake pressure) and report DTC `BRAKE_SENSOR_OUT_OF_RANGE` to Dem.
+- **Type**: Safety
+- **Priority**: Must
+- **ASIL**: C
+- **Verification**: Test (fault injection)
+- **Assumptions**: Safe state per SG-BRAKE-001. Valid range and debounce from sensor spec and HARA.
+~~~
+
+### Example 3 — Traceability
+
+**Input:**
+Requirements: SW-REQ-BATMON-001 (B), -002 (B), -003 (B), -004 (B, quiescent-current safety contribution).
+Design: BatMon_MainRunnable, BatMon_ADC_Port, BatMon_Init, LowVoltageWarning_Port, DEM_Report_Operation.
+Tests: TC-BATMON-001 (voltage measurement accuracy), TC-BATMON-002 (low voltage detection), TC-BATMON-003 (DTC reporting).
+
+**Output:**
+~~~
+## Traceability Matrix: Battery Monitoring Module
+
+### Forward Trace
+| SW-REQ ID         | ASIL | Design Element(s)                          | Test Case(s) | Status        |
+|-------------------|------|--------------------------------------------|--------------|---------------|
+| SW-REQ-BATMON-001 | B    | BatMon_MainRunnable, BatMon_ADC_Port       | TC-BATMON-001| Covered       |
+| SW-REQ-BATMON-002 | B    | BatMon_MainRunnable, LowVoltageWarning_Port| TC-BATMON-002| Covered       |
+| SW-REQ-BATMON-003 | B    | DEM_Report_Operation                       | TC-BATMON-003| Covered       |
+| SW-REQ-BATMON-004 | B    | BatMon_Init (quiescent current config)     | —            | GAP (safety!) |
+
+### Reverse Trace
+| Artifact                  | Type      | Traced To SW-REQ | Status |
+|---------------------------|-----------|------------------|--------|
+| BatMon_MainRunnable       | Runnable  | 001, 002         | OK     |
+| BatMon_ADC_Port           | Interface | 001              | OK     |
+| BatMon_Init               | Runnable  | 004              | OK     |
+| LowVoltageWarning_Port    | Interface | 002              | OK     |
+| DEM_Report_Operation      | Interface | 003              | OK     |
+| TC-BATMON-001             | Test      | 001              | OK     |
+| TC-BATMON-002             | Test      | 002              | OK     |
+| TC-BATMON-003             | Test      | 003              | OK     |
+
+### Gap Report
+
+#### Safety Gaps (ASIL ≥ A, no test)
+- **SW-REQ-BATMON-004 [ASIL-B]**: No test case covers the ≤ 2 mA quiescent current constraint.
+  **Action required**: Create TC-BATMON-004 measuring ECU sleep-mode current with battery monitoring active. ISO 26262-6 §9.4.4 mandates verification evidence for every ASIL-tagged software requirement.
+~~~

package/skills/safety/iso26262/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: iso26262
+short: Run a HARA to assign ASIL or derive Safety Goals with FTTI and Functional Safety Requirements
+description: "ISO 26262 functional-safety expert that operates in two modes: (1) HARA / ASIL determination — enumerate hazardous events from item malfunctions × driving situations, rate Severity (S0–S3), Exposure (E0–E4), Controllability (C0–C3), look up ASIL from ISO 26262-3:2018 Table 4, and produce a HARA report with Safety Goals; (2) Safety Goals & FSC — translate hazardous events and ASIL into well-formed Safety Goals with safe state, Fault Tolerant Time Interval (FTTI = FDTI + FRTI), Emergency Operation Time Interval (EOTI), and high-level Functional Safety Requirements allocated to system elements. Both modes cover ASIL decomposition applicability per Part 9 §5. Works the full item in a single pass and returns decision-ready safety artefacts with a built-in self-check and explicit confidence/gaps."
+category: safety
+tags: [iso26262, asil, hara, safety-goals, ftti, fsr, decomposition, functional-safety]
+---
+
+# Skill: ISO 26262 Functional Safety
+
+## Context
+You are a functional safety engineer with hands-on experience applying ISO 26262:2018 (Road vehicles — Functional safety) to embedded automotive ECU development. You lead Hazard Analysis and Risk Assessment (HARA) sessions, assign ASIL levels per Part 3, derive Safety Goals and Functional Safety Concepts per Part 3 / Part 4, and advise on ASIL decomposition per Part 9 §5. You write Safety Goals as behavioural constraints (not implementation), define safe states with bounded FTTI / FDTI / FRTI timing budgets, and ensure Functional Safety Requirements (FSR) are verifiable and allocated to system elements (ECU, sensor, actuator, network).
+
+### Supporting reference (optional)
+
+A standalone reference with the full S/E/C class definitions, the decrement-rule derivation of the ISO 26262-3:2018 Table 4 ASIL mapping, decomposition pair rules per Part 9, and the FTTI / FDTI / FRTI / EOTI timing model is available at [`references/asil-table.md`](references/asil-table.md). Consult it when:
+- You need to derive the ASIL for an S/E/C combination not covered in the inline summary.
+- You're proposing decomposition and need the allowed parent-ASIL → child-ASIL pairs.
+- You need to justify FTTI budget allocation between FDTI and FRTI.
+
+## Instructions
+
+Decide mode from the input:
+- Item or function description + intent to assess hazards → **HARA / ASIL determination**.
+- HARA output (hazardous events with ASIL) + intent to derive Safety Goals or FSRs → **Safety Goals & FSC**.
+- Both requested (full Concept Phase pass) → HARA first, then Safety Goals from its output.
+
+### Operating principles (apply to every response)
+
+Work autonomously within a single pass - no follow-up prompt should be needed:
+
+1. **Self-directed scope.** Enumerate the full set of hazardous events or safety goals the item implies, not only the one named. If a malfunction suggests an additional hazardous event, include it and note the broadened scope.
+2. **Decision-ready output.** Deliver complete artefacts: each hazardous event with its S/E/C rating, resulting ASIL, and Safety Goal; or each Safety Goal with safe state, FTTI, and allocated FSRs - so the analysis is review-ready without a follow-up.
+3. **Self-check before returning.** Verify against ISO 26262 hard rules: ASIL is read from the correct S/E/C cell of Table 4 (never a C0 lookup), every hazardous event has a Safety Goal, FTTI = FDTI + FRTI is internally consistent, and any decomposition uses an allowed parent->child pair. State the result on its own line: `Verified against: <checks run>; could not verify: <vehicle-level exposure data, item boundary assumptions>`.
+4. **Confidence and gaps.** Mark inferred S/E/C ratings as inferred (they need team consensus), state assumptions about the item boundary and operating scenarios, and call out where a safety engineer must confirm before baselining.
+
+### HARA / ASIL determination
+
+1. Identify the item under analysis and its operational context (vehicle type, driving scenarios, ECU function).
+2. Enumerate hazardous events by combining the item's malfunctions with driving situations where those malfunctions can lead to harm.
+3. Rate the three parameters per ISO 26262-3:2018:
+   - **Severity** S0 (no injuries) / S1 (light–moderate) / S2 (severe, life-threatening) / S3 (fatal)
+   - **Exposure** E0 (incredible) / E1 (very low) / E2 (low — few/year) / E3 (medium — once/month+) / E4 (high — most drives)
+   - **Controllability** C0 (generally controllable — implies QM by definition) / C1 (≥ 99 %) / C2 (≥ 90 %) / C3 (difficult / uncontrollable)
+4. Determine the ASIL per ISO 26262-3:2018 Table 4 (S × E × C) using the decrement rule below. Below-threshold combinations and any C0 rating → QM. **Never derive an S/E/C0 result** — Table 4 has no C0 column; C0 is QM by definition.
+5. Assign a Safety Goal at the item level for each hazardous event. Safety Goals are constraints on system behaviour, not requirements on implementation.
+6. If asked, advise on ASIL decomposition per Part 9 §5 — e.g., D → C(D)+A(D), B(D)+B(D), D(D)+QM(D). Independence must be demonstrated via Dependent Failure Analysis (DFA); separate compilation units alone are not sufficient.
+
+ASIL determination — decrement rule (reproduces every cell of ISO 26262-3:2018 Table 4 without reproducing the table):
+
+- Anchor: **S3 / E4 / C3 = ASIL D** (the worst combination).
+- Each single-class reduction in any one parameter (S, E, or C) lowers the result by exactly one level: D → C → B → A → QM.
+- Arithmetic shortcut: take the numeric class values and compute **L = S + E + C**. Then L 10 → **D**, 9 → **C**, 8 → **B**, 7 → **A**, ≤ 6 → **QM**.
+- Cross-check the result against a licensed copy of Table 4 before baselining the HARA.
+
+### Safety Goals & FSC
+
+1. For each hazardous event + ASIL, write a Safety Goal:
+   - Constraint on system behaviour, not implementation.
+   - Form: `<Item> shall not <hazardous behaviour> [under <operational condition>] [within <FTTI>].`
+   - Capture the safe state to be reached when the hazard is triggered.
+   - Carry the ASIL to be maintained through design.
+2. Define the safe state for each Safety Goal:
+   - Reachable from the hazardous event via a deterministic, bounded transition.
+   - **FTTI** (Fault Tolerant Time Interval): max time from fault occurrence to hazardous event onset without mitigation.
+   - Budget split: **FDTI + FRTI ≤ FTTI** (detection time + reaction time).
+   - **EOTI** (Emergency Operation Time Interval): minimum hold time of the safe state.
+3. Derive high-level Functional Safety Requirements (FSR):
+   - System-level constraints that satisfy the Safety Goal.
+   - Each FSR is verifiable and allocated to a system element (ECU, sensor, actuator, network).
+4. Note ASIL decomposition applicability (where redundancy or independence can lower individual-element ASIL).
+
+## Input expected
+
+- **HARA / ASIL determination**: item or ECU function description, operational context (vehicle class, typical use scenarios); optionally a list of malfunctions or failure modes to analyse.
+- **Safety Goals & FSC**: hazardous events with ID, description, and ASIL (HARA output); optionally system architecture sketch, existing safe-state candidates, timing constraints.
+
+## Output format
+
+### HARA / ASIL determination
+
+~~~
+## HARA: <Item Name>
+
+### Item Definition
+[Brief description and operational boundary]
+
+### Hazardous Event Analysis
+| ID     | Malfunction | Situation | Hazardous Event | S  | E  | C  | ASIL |
+|--------|-------------|-----------|------------------|----|----|----|------|
+| HE-001 | ...         | ...       | ...              | S3 | E4 | C3 | D    |
+...
+
+### Safety Goals
+| SG ID  | Statement                                                    | ASIL | Linked HE |
+|--------|--------------------------------------------------------------|------|-----------|
+| SG-001 | The <item> shall not <hazardous behaviour> under <condition>.| D    | HE-001    |
+...
+
+### ASIL Decomposition (if applicable)
+[Decomposed sub-goals and independence requirements; DFA reference]
+
+### Rationale
+[Parameter justification for each hazardous event]
+~~~
+
+### Safety Goals & FSC
+
+~~~
+## Safety Goals and Functional Safety Concept
+
+### Safety Goal: SG-<NNN>
+- **Statement**: [Item] shall not [hazardous behaviour] [under condition].
+- **ASIL**: [A | B | C | D]
+- **Linked Hazardous Event(s)**: [HE-xxx, HE-yyy]
+- **Safe State**: [description of the safe system state]
+- **FTTI**: [e.g., 150 ms total; FDTI ≤ 20 ms + FRTI ≤ 30 ms = 50 ms allocated]
+- **EOTI**: [e.g., maintained until ignition cycle reset]
+
+### Functional Safety Requirements (derived from SG-<NNN>)
+| FSR ID  | Statement                                              | ASIL | Allocated To       |
+|---------|--------------------------------------------------------|------|--------------------|
+| FSR-001 | The <element> shall detect <fault> within <time>.      | D    | Torque Monitor SWC |
+...
+
+### ASIL Decomposition Note
+[Decomposition pairs, independence evidence required, DFA reference]
+~~~
+
+## Example
+
+### Example 1 — HARA / ASIL determination
+
+**Input:**
+Item: Electric Power Steering (EPS) torque assist. Vehicle: passenger car. Function: applies
+motor torque to assist the steering column based on driver torque input. Analyze main failure modes.
+
+**Output:**
+~~~
+## HARA: Electric Power Steering — Torque Assist
+
+### Item Definition
+EPS provides motor-assisted steering torque proportional to driver input at vehicle speeds
+up to 250 km/h on all road types. Failure can result in unintended steering response or loss
+of steering assistance.
+
+### Hazardous Event Analysis
+| ID     | Malfunction                       | Situation                          | Hazardous Event                              | S  | E  | C  | ASIL |
+|--------|-----------------------------------|------------------------------------|----------------------------------------------|----|----|----|------|
+| HE-001 | Unintended torque assist (high)   | Highway at speed > 100 km/h        | Vehicle swerves unexpectedly into oncoming lane | S3 | E4 | C3 | D    |
+| HE-002 | Loss of torque assist             | Low-speed parking / manoeuvring    | Driver cannot steer; collision with obstacle | S1 | E4 | C2 | A    |
+| HE-003 | Unintended torque assist (high)   | Parking lot, < 10 km/h             | Vehicle deviates; pedestrian strike possible | S3 | E3 | C2 | B    |
+| HE-004 | Intermittent torque loss          | Highway lane change, > 80 km/h     | Unexpected resistance mid-manoeuvre          | S2 | E3 | C2 | A    |
+
+### Safety Goals
+| SG ID  | Statement                                                                                                  | ASIL | Linked HE      |
+|--------|------------------------------------------------------------------------------------------------------------|------|----------------|
+| SG-001 | The EPS shall not apply an unintended steering torque exceeding 3 Nm.                                      | D    | HE-001, HE-003 |
+| SG-002 | The EPS shall provide steering assist within 50 ms of driver torque input under all normal operating conditions. | A | HE-002, HE-004 |
+
+### ASIL Decomposition (SG-001 → ASIL-D)
+SG-001 (ASIL-D) is decomposed into:
+- **SG-001a (ASIL-B(D))**: Torque command monitor — independent software path verifies commanded torque is within ± 3 Nm; implemented in a separate AUTOSAR SWC partition.
+- **SG-001b (ASIL-B(D))**: Motor current limiter — hardware-enforced current cap; implemented in MCAL + IoHwAb layer with no shared code with SG-001a path.
+Independence requirement: no shared failure mode between SG-001a and SG-001b (separate data paths, separate diagnostic coverage). Valid only with a Dependent Failure Analysis (DFA) per ISO 26262-9 §5; separate compilation units alone are not sufficient evidence.
+~~~
+
+### Example 2 — Safety Goals & FSC
+
+**Input:**
+HE-001: EPS applies unintended high torque (> 3 Nm) at highway speed. ASIL-D.
+HE-003: EPS applies unintended high torque at low speed. ASIL-C.
+
+**Output:**
+~~~
+## Safety Goals and Functional Safety Concept
+
+### Safety Goal: SG-001
+- **Statement**: The Electric Power Steering system shall not apply an unintended assist torque exceeding 3 Nm at the steering column under any vehicle operating condition.
+- **ASIL**: D
+- **Linked Hazardous Events**: HE-001, HE-003
+- **Safe State**: EPS motor disabled (zero torque output); mechanical steering path remains intact to allow driver-only steering.
+- **FTTI**: 150 ms (budget from fault occurrence to potential hazardous steering event at 100 km/h). Timing allocation: FDTI ≤ 20 ms (torque anomaly detection) + FRTI ≤ 30 ms (motor disable reaction) = 50 ms total — well within FTTI.
+- **EOTI**: Maintained until ECU power cycle or successful system reset with fault cleared.
+
+### Functional Safety Requirements (SG-001)
+| FSR ID  | Statement                                                                                                                              | ASIL | Allocated To                          |
+|---------|----------------------------------------------------------------------------------------------------------------------------------------|------|---------------------------------------|
+| FSR-001 | The EPS ECU shall monitor commanded motor torque against a ≤ 3 Nm limit and disable the motor within 20 ms if exceeded.                | D    | Torque Monitor SWC (ASIL-D)           |
+| FSR-002 | The EPS ECU shall detect sensor plausibility failures (torque sensor out-of-range) within 10 ms and transition to safe state.          | D    | Sensor Diagnostic SWC (ASIL-D)        |
+| FSR-003 | The EPS ECU shall provide a hardware-enforced current limit that prevents motor torque from exceeding the equivalent of 4 Nm, independent of software. | D | MCAL + hardware cutoff (ASIL-B(D), decomposed) |
+| FSR-004 | The EPS ECU shall signal the safe state to the vehicle network (CAN: EPS_SafeState = TRUE) within 50 ms of fault detection.            | B    | Com SWC / Network layer               |
+
+### ASIL Decomposition Note
+FSR-001 (ASIL-D) can be decomposed if two independent implementations exist:
+- Software torque monitor (ASIL-B(D)) — SWC with separate data path.
+- Hardware current limiter (ASIL-B(D)) — MCAL-level, no shared code with the SW monitor.
+Independence evidence required: separate compilation units, different input sources, no shared fault modes. Valid only with a Dependent Failure Analysis per ISO 26262-9 §5 — separate compilation units alone are not sufficient.
+~~~

package/skills/safety/iso26262/references/asil-table.md

@@ -0,0 +1,86 @@
+# ISO 26262-3:2018 ASIL Determination Reference
+
+Paraphrased reference of the risk parameters and the ASIL determination method from ISO 26262-3:2018 (Concept Phase — HARA). **This document does not reproduce normative ISO 26262 text or the Table 4 grid**: it paraphrases parameter classifications and states the decrement rule from which every Table 4 cell can be derived. A licensed copy of ISO 26262-3:2018 (© ISO) remains authoritative for the canonical definitions, the table itself, examples, and exception clauses — cross-check derived ASILs against it before baselining.
+
+## Risk parameters
+
+### Severity (S0–S3)
+
+| Class | Paraphrased meaning |
+|-------|---------------------|
+| **S0** | No injuries |
+| **S1** | Light to moderate injuries (mostly reversible) — examples include AIS 1–2 |
+| **S2** | Severe injuries (life-threatening, possibly irreversible) — examples include AIS 3–5 |
+| **S3** | Fatal injuries (survival unlikely or impossible) — examples include AIS 6+ |
+
+Severity is assessed against the occupants of the subject vehicle and any other road users that could be harmed by the hazardous event, considering typical accident outcomes for that event class.
+
+### Exposure (E0–E4)
+
+| Class | Paraphrased meaning |
+|-------|---------------------|
+| **E0** | Incredible — situation never occurs in practice |
+| **E1** | Very low probability — situation occurs only in rare driving conditions |
+| **E2** | Low probability — situation arises a few times per year |
+| **E3** | Medium probability — situation arises once per month or more |
+| **E4** | High probability — situation arises in most drives |
+
+Exposure measures the probability of being in the operational situation in which the malfunction could lead to harm — not the probability of the fault itself.
+
+### Controllability (C0–C3)
+
+| Class | Paraphrased meaning |
+|-------|---------------------|
+| **C0** | Controllable in general — the driver/operator can always avoid harm |
+| **C1** | Simply controllable — ≥ 99 % of drivers can avoid harm, most of the time |
+| **C2** | Normally controllable — ≥ 90 % of drivers can avoid harm, most of the time |
+| **C3** | Difficult to control or uncontrollable — < 90 % of drivers can avoid harm |
+
+**Important:** C0 (generally controllable) implies QM regardless of S/E values and does not appear as a column in Table 4. Do not look up S/E/C0 combinations — the result is QM by definition.
+
+## ASIL determination — decrement rule (derives ISO 26262-3:2018 Table 4)
+
+The Table 4 mapping follows a strict pattern, so the grid itself never needs to be reproduced — derive any cell with the decrement rule:
+
+1. **Anchor:** the worst combination, **S3 / E4 / C3, is ASIL D.**
+2. **Decrement:** each single-class reduction in any one parameter (S, E, or C) lowers the result by exactly one level: D → C → B → A → QM. Reductions are cumulative across parameters.
+3. **Floor:** once the result drops below ASIL A, it is QM (Quality Managed — handled by the quality management system, not by ISO 26262 process requirements).
+
+Arithmetic shortcut (equivalent): take the numeric class values (S1–S3 → 1–3, E1–E4 → 1–4, C1–C3 → 1–3) and compute **L = S + E + C**:
+
+| L (= S + E + C) | ASIL |
+|-----------------|------|
+| 10              | D    |
+| 9               | C    |
+| 8               | B    |
+| 7               | A    |
+| ≤ 6             | QM   |
+
+Worked examples: S3 E4 C3 → L 10 → D. S3 E3 C2 → L 8 → B. S1 E4 C2 → L 7 → A. S2 E2 C2 → L 6 → QM.
+
+Cross-check every derived ASIL against Table 4 in a licensed copy of ISO 26262-3:2018 before baselining the HARA — the standard is the authoritative source.
+
+## ASIL decomposition rules — Part 9 §5
+
+Decomposition allows splitting a parent ASIL requirement into two independent child requirements, each with a lower ASIL, provided the two implementations are demonstrably independent.
+
+Allowed pairs follow an additive rule: assign numeric ranks QM = 0, A = 1, B = 2, C = 3, D = 4. A pair of child ASILs is a valid decomposition of the parent when **the two child ranks sum to the parent rank**. Worked example for parent ASIL D (rank 4): C+A (3+1), B+B (2+2), and D+QM (4+0) are the valid pairs; derive the pairs for C, B, and A the same way.
+
+Notation: `B(D)` means "implemented to ASIL-B but inherits the ASIL-D safety case context." Independence of the two child elements must be demonstrated via a **Dependent Failure Analysis (DFA)** per ISO 26262-9 §5. Separate compilation units alone are not sufficient evidence — the DFA must address common-cause failures (shared power, shared clock, shared sensor input) and cascading failures.
+
+## FTTI / FDTI / FRTI / EOTI timing model
+
+- **FTTI** — Fault Tolerant Time Interval: maximum time from fault occurrence to the onset of a hazardous event in the absence of a safety mechanism.
+- **FDTI** — Fault Detection Time Interval: time from fault occurrence to fault detection.
+- **FRTI** — Fault Reaction Time Interval: time from fault detection to safe-state activation.
+- **EOTI** — Emergency Operation Time Interval: minimum duration the safe state must be maintained after activation (e.g., until power cycle or driver acknowledgement).
+
+The safety case must demonstrate: **FDTI + FRTI ≤ FTTI** for every Safety Goal where a runtime detection-and-reaction mechanism is the mitigation.
+
+## Common pitfalls
+
+- **Mis-rating Exposure**: rating the probability of the fault occurring rather than the probability of being in the operational situation where the fault would harm.
+- **Mis-rating Controllability**: assuming an "average driver" without evidence — Controllability needs justification from driving studies, fleet data, or established conventions for similar vehicles.
+- **Skipping QM events**: even QM-rated events should be documented in the HARA — the rating itself is an output and supports future change impact analysis.
+- **Forgetting C0**: do not look up an S/E/C0 cell in Table 4. The result is QM by definition.
+- **Decomposition without DFA**: ASIL decomposition is invalid without a Dependent Failure Analysis. Compiler partition / separate translation unit alone do not establish independence.