Turning study into evidence — proposed, not yet built.

Engineering objective

Design a simple digital hardware block and use it to study redundancy, fault detection, and the limits of redundancy under common-mode faults.

Safety problem

A redundant structure only detects faults that affect its copies differently. Understanding what a duplicated or checked block cannot see (shared clocks, shared resets, shared inputs) is the logic-level counterpart of dependent failure analysis.

Proposed methodology

1. Specify a small block with a defined safety function, such as a counter, a state machine, or a short data path.
2. Implement a baseline and variants with duplication and comparison, and with parity or coding.
3. Simulate with directed and randomized stimulus.
4. Introduce faults, including faults that affect both copies identically.
5. Record what is detected, what escapes, and why.

Tools / technologies

Verilog or VHDL; an open-source simulator and waveform viewer (candidates: Icarus Verilog or Verilator, GHDL, GTKWave).

Current status

Proposed. No design or simulation has been completed.

Expected technical deliverables

• Block specification and safety function
• Baseline and safety-mechanism variants in HDL
• Testbench
• Waveforms showing detected and undetected faults
• Short write-up of common-mode limitations

Engineering objective

Study how a DMA controller moves data without CPU involvement, and which safety mechanisms are needed to keep that movement correct.

Safety problem

A DMA controller can write to any address its configuration allows. A corrupted descriptor, address, or data word can silently damage memory that software believes is protected, which makes DMA an important interference path for freedom from interference.

Proposed methodology

1. Review published DMA architectures and the DMA-related content of public microcontroller safety documentation.
2. Model a simplified DMA engine.
3. Define candidate mechanisms: address-range protection, data coding (parity, ECC, or CRC), and descriptor checking.
4. Verify each mechanism with directed tests and fault injection.

Tools / technologies

HDL and simulation as in Exploration 1; published microcontroller documentation as architectural reference.

Current status

Proposed. No model or results yet.

Expected technical deliverables

• Architecture description of the simplified DMA
• List of failure modes and the mechanisms that address them
• Testbench with fault scenarios
• Mapping of each mechanism to the failure modes it covers

Engineering objective

Investigate how RTL-level fault injection can provide evidence for safety mechanism effectiveness and support the diagnostic coverage assumed in a FMEDA.

Safety problem

Diagnostic coverage in a FMEDA is often an estimate taken from standards or experience. Fault injection evidence can strengthen or challenge that estimate, but only if the fault model, the observation points, and the definition of “detected” are chosen deliberately.

Proposed methodology

1. Take a block from Exploration 1 or 2.
2. Define a fault list covering stuck-at faults and transient bit flips.
3. Automate injection and observation.
4. Classify each outcome (detected, undetected, no effect) and measure detection latency.
5. Compare observed coverage with a hand-built FMEDA for the same block.
6. Document the limits: RTL versus gate level, fault sampling, and what the evidence cannot show.

Tools / technologies

HDL simulator with a scripted harness (candidates: Python with cocotb, or simulator scripting); spreadsheet or script for FMEDA-style tallies.

Current status

Proposed. Depends on a block from Exploration 1 or 2. No results yet.

Expected technical deliverables

• Fault model definition
• Injection and classification scripts
• Outcome tables
• Comparison of measured results with FMEDA assumptions
• Discussion of validity limits

Engineering objective

Turn the way I evaluate an MCU's safety mechanisms into a structured, reusable method.

Safety problem

Safety manuals describe mechanisms; the integrator must decide which apply, whether the assumptions of use are met, what remains uncovered, and who verifies what. When that reasoning stays implicit, gaps are discovered late.

Proposed methodology

1. Define a schema linking each mechanism to the failure modes it addresses, its claimed diagnostic coverage, its assumptions of use, the resulting ECU-level requirements, and the verification responsibility (integrator or supplier).
2. Apply it to publicly available documentation and generic examples.
3. Walk through a hypothetical ECU function to test the schema.
4. Define how compensating system-level measures and residual risk are recorded.
5. Constraint: public information and generic examples only. No employer, customer, or supplier proprietary data.

Tools / technologies

Structured tables or a machine-readable format (for example YAML or CSV), small scripts for consistency checks, and public MCU safety documentation.

Current status

Proposed. No framework has been written.

Expected technical deliverables

• Schema and template
• Worked example on public documentation
• Checklist for applicability and feasibility
• Guidance for recording residual risk

Engineering objective

Use simulation to study how quickly unintended steering behavior becomes hazardous, and how that timing relates to the detection and reaction times a safety mechanism must meet.

Safety problem

The fault tolerant time interval bounds how long a fault can persist before a hazardous event may occur. For unintended steering it depends on speed, road geometry, and how far the vehicle can deviate before a hazard. These assumptions are often made analytically and rarely examined.

Proposed methodology

1. Build CARLA scenarios (straight road and curve, at varying speeds).
2. Inject unintended steering offsets or commands of varying magnitude and duration.
3. Measure lateral deviation and time to lane departure.
4. Sweep parameters and relate observed time-to-hazard to candidate detection and reaction budgets.
5. State limits plainly: simulated vehicle dynamics are an approximation, so any result illustrates the method and is not validated vehicle behavior.

Tools / technologies

CARLA simulator, its Python API, scenario scripts, data logging, and plotting.

Current status

Proposed. No scenarios have been built and there are no results.

Expected technical deliverables

• Scenario definitions
• Fault injection scripts
• Plots of deviation against time
• Method write-up for deriving a time budget from simulation
• Limitations section

Where these topics sit against the standard: see Part 11 on the Work Products page and domain 04 on the homepage, which separate professional MCU safety integration experience from the study topics these projects address.