Chaos Engineering makes up an essential component of our validation methods used in developing resilient, safety-critical autonomous vehicle software systems.

There's an adage in some functional-safety circles that goes something like, "The risk and danger live in the interfaces." Which, among other things, is a succinct way of stating that it's in the integration points where things most commonly breakdown. In a traditional safety-critical development process this focus on danger at the interface level is partially borne out of the assumption that the rigors of formalized safety-critical development processes (i.e. ISO 26262, IEC 61508, etc.) will have squeezed out serious issues in the design and various components that make up a system.

As it turns out, it is true that there's enormous opportunity for failure at the integration points between different systems and components, but it's also true that even some of the most rigorous SDLC processes available today leave room for unintended, undefined, or undesirable emergent behaviors elsewhere in the implementation. This problem is exacerbated significantly by the scale and complexity of the systems that are required to facilitate and operate an autonomous vehicle.

By automatically exploring the input space of chaos in a given system, we try to build stronger inductive proofs of our system's resilience semantics, so that we can augment the deductive proofs of correctness we derive from the use of formal methods in other facets of our solutions. The ultimate goal being to make assurances about safety-properties and resiliency-behaviors that would be otherwise impossible without the use of Chaos Engineering.