IVEX Safety Co-Pilot on Infineon AURIXᵀᴹ

IVEX.ai
6 min readApr 28, 2021

--

Autonomous Vehicles (AVs) and Advanced Driver-Assistance Systems (ADASs) are becoming a reality. One of the major challenges to the mass adoption of those amazing vehicles is to make sure the vehicle’s decisions are safe.

Safety Co-Pilot

At IVEX, we are creating the Safety Co-Pilot, a critical component offering a second eye on the safety of AVs’ trajectories. The Safety Co-Pilot consists of several blocks:

  • A trajectory checker
  • A risk analyzer
  • An emergency maneuver lib
  • A decider
An example architecture of autonomous vehicles with the Safety Co-Pilot integrated.

The Safety Co-Pilot works as follows. At each decision-making cycle, the trajectory planning component receives information from the perception component and computes one or several candidate trajectories. The trajectories are then sent to the trajectory checker, which assesses the safety of the candidate trajectories against a set of formalized safety rules. The safety assessment results are then sent to the risk analyzer component, which computes and weights the risk of each trajectory. Based on the computed risk of each trajectory, the decider component makes a decision on which trajectory the AV should follow. If no candidate trajectory is safe enough to follow, the decider will select an emergency maneuver trajectory from a predefined trajectory library. The selected trajectory is then sent to the control component, which in turn interacts with the actuators of the AV.

Trajectory checker

In our white paper, “Real-time safety assessment of trajectories for autonomous driving, we explain the details of the first prototype of the trajectory checker, which is executed on the Infineon AURIXᵀᴹ TC397 automotive platform.

The trajectory checker assesses the safety of AVs’ trajectories against a set of formalized safety rules while a hard real-time guarantee on the computation time. The outputs of the trajectory checker consist of:

  • The types of safety violations
  • The time to the first potential safety violation on a trajectory
  • The severity of safety violations

Implementing a trajectory checker brings many challenges, for example:

  • How to guarantee that the safety rules are consistent? For example, there should not be a situation in which one safety rule requires the car to change to the right lane while another safety rule requires the car to change to the left lane.
  • How to guarantee that the C++ implementation correctly implements the safety rules?
  • How to guarantee the hard real-time execution time of the C++ implementation?

We tackle these challenges by having a rigorous development process using IVEX’s formal language and IVEX’s solver to formalize safety rules, verify safety rules’ consistency, as well as synthesize correct-by-construction and hard real-time guarantee C++ implementation.

Safety policy development process.

The trajectory checker prototype has rules of the same nature as the safety rules from the Responsibility-Sensitive Safety paper from Mobileye. It also consists of several additional safety rules defined by IVEX internally. Rules from different resources such as OEMs or safety authorities can also be integrated into the trajectory checker.

Demonstration on Infineon AURIXᵀᴹ TC397

The first prototype of the trajectory checker is demonstrated on an Infineon AURIXᵀᴹ TC397.

Trajectory checker demonstration.

Example scenario

To understand the outputs of the trajectory checker, let’s take a very simple EuroNCAP scenario. In this scenario, a guest vehicle overtakes and cuts in the ego vehicle at a short distance, which poses a dangerous situation.

Let’s zoom in at particular timestamps, to understand the outputs of the trajectory checker.

The trajectory checker’s outputs in a cut-in scenario.

Initially, the guest vehicle is to the right of the ego vehicle. In Situation 1 at timestamp 4.1s, the guest vehicle is on the right of the ego vehicle. At this timestamp, the trajectory checker foresees that there might be a safety violation in the next 2.5s on the trajectory of the ego vehicle if the guest vehicle performs the worst-case behavior, that is, cutting in and then braking strongly. Due to that possibility, the ego vehicle should be cautious. However, the current situation is still safe and no specific actions are required.

In Situation 2 at timestamp 9.0s, based on the kinematic state of the guest vehicle, the trajectory checker predicts that it will create a cut-in situation in front of the ego vehicle. The ego vehicle must be extremely cautious as there might be a safety violation in the next 1.1s if it keeps following the current trajectory and the guest vehicle brakes after cutting in.

In Situation 3 at timestamp 9.1s, the guest vehicle makes the predicted aggressive move. The trajectory checker observes that if the ego vehicle keeps its current trajectory, it will need to perform a hard brake by about -3.7m/s² in the next 0.2 seconds, which is critical.

In Situation 4 at timestamp 9.3s, since the ego vehicle keeps following the current trajectory, without performing the observed needed brake, the trajectory checker reports that a safety constraint is violated. According to the safety policy, at this time, the ego vehicle should brake by at least -3.64m/s² but it does not.

The closer the ego vehicle gets to the guest vehicle, the higher the braking threshold that the trajectory checker reports. In this way, in Situation 5 at timestamp 10.0s, the ego vehicle is meant to brake by at least -5.08m/s² to not violate the safety rule. Since the ego vehicle does not brake more than that threshold, another violation is reported.

In this scenario, luckily, after cutting in the ego vehicle, the guest vehicle increases its speed. At timestamp 10.5s, the trajectory checker reports that given the current speed of the guest vehicle, there is no further braking requirement for the ego vehicle. However, a collision could have occurred if the guest vehicle did not speed up and the ego vehicle did not brake as required by the trajectory checker.

Performance benchmark

We measure the computation time of the trajectory checker against different input sizes. The input size is defined in terms of the length of the trajectory and the number of the objects. With a five-second trajectory and 30 obstacles, it takes less than 40 milliseconds for the trajectory checker to perform a safety assessment. The trajectory checker can also perform a safety check on 10 trajectories in situations with 5 obstacles in less than 40 milliseconds.

The computation time of the trajectory checker with respect to one trajectory.
The computation time of the trajectory checker with respect to multiple trajectories.

This prototype is the first step on IVEX’s mission to create the Safety Co-Pilot for AVs/ADASs. In the second part of the blog post, we will discuss the implementation of the trajectory checker in detail, including the safety rules and their corresponding formal model.

You can find the full paper at https://arxiv.org/abs/2104.13149

If you are interested in the Safety Co-Pilot and the Trajectory Checker, contact us here.

--

--

IVEX.ai
IVEX.ai

No responses yet