I build systems that fail safely.

I spend most of my working hours thinking about the ways things go wrong. Not because I'm pessimistic — because in my field, someone has to be. I'm a Functional Safety Engineer, and for the past five years I've worked on the systems that are supposed to fail quietly, predictably, and never at the worst possible moment.

Across that work, I've achieved the random hardware failure metrics — SPFM, LFM, and PMHF — required to meet ASIL-A through ASIL-D targets per ISO 26262, on systems ranging from restraint control to autonomous driving features.

Right now that includes airbags. At a Tier 1 automotive supplier, I own the full safety story of a Restraint Control System, from the first hazard we identify on paper to the safety case we hand over at the end — the document that says, with evidence, this will do what it's supposed to do, even when something inside it breaks. That's the promise of ASIL-D, the highest integrity level in automotive safety, and getting there means tracing every requirement back to a hazard, every safety mechanism back to a failure mode, until nothing is left unaccounted for. The safety case itself reports how much of that requirement set is actually covered by evidence — and wherever something isn't, I don't leave a gap. I run a risk assessment on it and fold that in as evidence that the residual risk is understood and acceptable.

"Getting to ASIL-D means tracing every requirement back to a hazard — until nothing is left unaccounted for."

My safety work spans the active side too — cars that could see and decide. On earlier OEM and Tier 1 programs, I worked on the safety case for autonomous driving features — lane centering, automated parking, adaptive cruise control — systems that have to make a judgment call every few milliseconds about what's safe to do next. That work taught me something the restraint systems hadn't: safety isn't just about hardware failing gracefully. It's about a system correctly reading the world and knowing when not to act.

Earlier still, on Tier 1 supplier programs, I was the person in the room translating a new feature — a digital mirror, a power window, a clutch actuator — into a hazard analysis, a safety concept, a set of requirements a supplier could actually build against. One of my safety specifications shipped a week ahead of schedule, and I was recognized by the OEM as one of the top-performing engineers among more than eighty engineers on the program.

A safety goal stays abstract until someone decides which microcontroller will execute the function, what that device can actually detect about its own failures, and what it quietly assumes the rest of the ECU will handle. Much of my work sits exactly there.

For a candidate MCU, that means working through the safety manual: which failure modes the vendor's safety mechanisms really cover across the CPU, memories, DMA, watchdogs, clock monitoring, communication interfaces, and other peripherals, and under which assumptions of use. Where a mechanism is not implemented, does not apply to our configuration, or is not strong enough for the target, I work out what has to compensate at the system level, and what diagnostic coverage and residual risk that leaves behind.

The same discipline applies beyond the MCU. Evaluating a safety-related pressure sensor means looking at its diagnostics, the plausibility checks the ECU can apply, and the sensor-to-MCU communication path as one chain rather than separate parts. And the supplier relationship is part of the engineering: development interface agreements, supplier safety documentation, and Safety Element out of Context assumptions decide who is responsible for verifying what.

My work sits across four connected domains. Vehicle- and system-level functional safety defines what must be achieved and how it is allocated. At the ECU level, software and hardware safety are parallel branches that implement it together. Semiconductor safety is a deeper level of abstraction: the devices those ECUs are built on. Reaching it is a matter of supplier integration and technical curiosity, not a phase that follows ECU development.

Professional experience and independent study are marked separately throughout. Select a domain to open it.

Part references follow ISO 26262:2018. The Work Products page maps each part to these domains in more detail.

"How do we prove a system remains safe when the unexpected happens?"

I believe the future of engineering is not simply making systems more intelligent, but making them trustworthy. As vehicles, robots, and AI systems become increasingly autonomous, safety must evolve from verifying components to validating decisions. My work is driven by one question: how do we prove a system remains safe when the unexpected happens?

My experience today is rooted in ISO 26262 for automotive safety, and in the MCU and semiconductor integration that sits underneath it. Closer in, I'm building deeper competence in semiconductor functional safety, RTL design, and hardware safety verification. Further out, I'm increasingly interested in how these principles extend to robotics and AI systems, where the challenge shifts from proving deterministic behavior to building confidence in systems that learn, adapt, and interact with the physical world.