⚡ electrical engineering

Automated, Credible Autocoding of An Unmanned Aggressive Maneuvering Car Controller

This paper presents an extension of a credible autocoding framework to handle nonlinear car controllers by introducing new annotation symbols for general predicates and dynamical systems, demonstrating the generation of code with independently verifiable guarantees of functional properties and runtime error absence.

Original authors: Timothy Wang, Eric Feron

Published 2026-06-04

📖 4 min read☕ Coffee break read

CC BY 3.0

Original authors: Timothy Wang, Eric Feron

Original paper licensed under CC BY 3.0 (http://creativecommons.org/licenses/by/3.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a self-driving race car that needs to perform aggressive, high-speed turns. You write a computer program (a controller) to tell the car how to steer and accelerate. But here's the problem: computers are literal and unforgiving. If your code has a tiny mistake, the car could spin out of control.

Usually, engineers write the code, then test it by crashing the car (virtually or physically) thousands of times to see if it breaks. This paper proposes a smarter way: Automated Credible Autocoding.

Think of this process not as "testing," but as building a mathematical guarantee alongside the code.

The Core Idea: The "Double-Check" System

The authors created a system that does two things at once:

Generates the Code: It takes a high-level design of the car's brain and automatically writes the actual computer instructions (code).
Generates the "Certificate": At the same time, it writes a mathematical proof that says, "I promise this code will never crash or behave badly."

It's like a factory that doesn't just build a car; it also prints a warranty certificate that mathematically proves the engine won't explode, the brakes won't fail, and the steering will always work, before the car even leaves the factory floor.

The Challenge: The "Nonlinear" Twist

In previous work, the authors could do this for simple, predictable systems (like a car driving in a straight line). But real racing involves nonlinear dynamics.

The Analogy: Imagine driving on a straight road. If you turn the wheel a little, the car turns a little. This is "linear" and easy to predict.
The Reality: Now imagine driving on a slippery, curvy mountain road. If you turn the wheel a little, the car might slide, spin, or grip differently depending on the speed and angle. This is "nonlinear." It's chaotic and hard to predict.

The car controller in this paper is designed for these chaotic, aggressive maneuvers. The math behind it is complex (using something called a "Sliding Mode" controller and a "Lyapunov function"), and it doesn't follow simple, straight-line rules.

What They Did: Expanding the Toolkit

The authors took their existing "proof-generating machine" and upgraded it to handle this messy, nonlinear car.

New Tools: They added new "annotation blocks" to their software. Think of these as special sticky notes you can stick onto the design blueprint.
- One note says: "This part of the car is the engine (the plant)."
- Another note says: "This part is the safety rule (the invariant)."
The "Invariant" (The Safety Bubble): In math terms, an "invariant" is a rule that never breaks. For this car, the rule is: "No matter how wild the turn gets, the car's state will always stay inside this invisible safety bubble."
- For simple cars, this bubble is a perfect circle (a quadratic shape).
- For this aggressive car, the bubble is a weird, squiggly shape (a non-quadratic invariant). The authors had to teach their machine to understand these weird shapes.

The Result: A Manual Demonstration

The paper shows how they took the design of this aggressive car controller, added their special "safety bubble" notes, and ran it through their system.

The Output: The system produced code (written in a language called Matlab for this demo) with the safety rules embedded directly into it.
The Catch: Because the car's behavior is so complex, the system couldn't do everything automatically yet. The authors had to manually insert some of the complex safety proofs into the code, like a human expert stepping in to sign off on the trickiest parts of the math.

Why This Matters

The ultimate goal of this work is trust.

Runtime Error Prevention: The math proves that the code won't crash due to things like numbers getting too big or dividing by zero.
Behavioral Guarantee: It proves the car will stay stable even when doing aggressive maneuvers.

The Bottom Line

This paper is a proof-of-concept. It says: "We have a machine that can automatically write code and prove it's safe for simple cars. We have now upgraded that machine to handle a very difficult, aggressive race car. We showed it works, but for the most complex parts, we still need a human to help write the final safety certificate."

They aren't saying this is ready for every car on the road yet; they are saying they have successfully built the bridge between complex, chaotic math and reliable, verified computer code.

Technical Summary: Automated, Credible Autocoding of an Unmanned Aggressive Maneuvering Car Controller

Problem Statement
This paper addresses the challenge of applying credible autocoding frameworks to control systems characterized by fully nonlinear dynamics. While previous work by the authors successfully demonstrated an automated framework for linear and quasi-nonlinear controllers (systems with bounded nonlinearities in feedback), these methods relied on quadratic invariants derived from Lyapunov stability proofs. The specific problem tackled here is the autocoding of a nonlinear car controller that cannot be reformulated as a linear system with bounded nonlinearities. This system utilizes a non-quadratic Lyapunov function, resulting in a non-quadratic invariant that existing prototype tools could not handle. Additionally, the presence of transcendental functions and the need to guarantee runtime error absence (such as overflow) in the generated code present significant hurdles for automatic verification.

Methodology
The authors extend their existing "autocoding with control semantics" framework, which leverages control-theoretic proofs to generate code and verify high-level functional properties. The methodology involves the following steps:

Framework Extension: The authors propose extending the prototype's dataflow annotation language (based on Simulink and Gene-Auto) with new annotation symbols. Specifically, they introduce:
- A generalized synchronous observer block capable of accepting any logic formula expressible by the underlying language, removing restrictions on the structure of the observed properties.
- A generalized plant block capable of defining non-linear state-transition systems, rather than being limited to linear state-space models.
System Modeling: The case study is a sliding-mode based nonlinear car controller designed to stabilize a single-track car model about a steady-state cornering equilibrium. The controller architecture consists of two subsystems:
- A Linear Subsystem: An LQR controller driving the linearized model to an equilibrium point, governed by a quadratic invariant.
- A Sliding Mode Subsystem: A controller managing wheel angular velocities to match commanded slips, governed by a non-quadratic invariant ( $z^T z \leq 1$ ) derived from a non-quadratic Lyapunov function.
Manual Annotation and Translation: Due to the limitations of the current prototype in fully automating the analysis of non-quadratic invariants, the authors demonstrate the process manually. They embed the linearized plant model and auxiliary dynamics into the Simulink model. The stability proofs are expressed as annotations:
- The linear portion uses an existing ellipsoid block for the quadratic invariant.
- The nonlinear portion uses the new generalized synchronous observer to express the non-quadratic invariant.
- The output is translated into Matlab code (used as a proxy for the target C code) with annotations similar to the ACSL (ANSI/ISO C Specification Language) standard.
Verification Logic: The paper details how invariants are mapped to the code. Linear invariants are propagated using affine transformation techniques. For the non-quadratic invariant, the authors employ backward propagation using axiomatic rules from Hoare logic. They note that proving the implication between pre- and post-conditions for the nonlinear case requires a theorem prover, as the presence of saturation operators prevents the use of single general decision procedures for polynomial or smooth functions.

Key Contributions

Extension of Annotation Language: The proposal of new annotation blocks (generalized observer and plant) to support general predicates and dynamical systems, moving beyond the constraints of linear/quadratic assumptions.
Demonstration on Non-Quadratic Systems: A manual demonstration of how the extended framework handles a fully nonlinear controller with a non-quadratic invariant, a scenario previously unsupported by the prototype.
Runtime Error Guarantees: Theoretical derivation showing how the non-quadratic invariant ( $z^T z \leq 1$ ) can be used to establish bounds on system variables (such as wheel angular velocities), thereby serving as a certificate for the absence of runtime errors, provided physical constraints are known.

Results
The paper presents a manually annotated example of the car controller in Matlab, showing the insertion of pre-conditions, post-conditions, and assumptions derived from the control semantics.

For the linear loop, the system successfully identifies the quadratic invariant and propagates it through the code.
For the nonlinear loop, the system successfully inserts the non-quadratic invariant as a condition.
The authors demonstrate that while the framework can generate the annotated code, the automatic verification of the implication $A \to B$ (where $A$ and $B$ are sets defined by the invariants) is not yet fully automated for the nonlinear case due to the complexity of the functions involved (specifically saturation). The verification currently relies on the user inserting the necessary invariant facts to assist the backend analyzer.

Significance and Claims
The paper claims that this work represents a necessary step toward extending credible autocoding to general nonlinear systems. The significance lies in the ability to generate code that carries "certificates" of good system behavior (stability) and runtime safety (boundedness) directly from the control-theoretic proofs.

Modest Claims: The authors are explicit that the current implementation for the fully nonlinear case is not fully automatic. They state that the process "cannot be fully-automated for the most part" and requires the end-user to manually insert stability proofs using the new observer blocks.
Scalability: The paper concludes by acknowledging that the automatic analysis and verification of the documented output code face scalability issues, particularly regarding the need for theorem provers to handle non-polynomial functions arising from saturation and transcendental operations. The work serves as a proof-of-concept for the framework's extensibility rather than a fully realized, automated tool for all nonlinear controllers.