Skip to content

Overview#

NOTE: It has not been implemented yet.

NOTE: topic_state_monitor will be used instead of autoware_state_monitor for recording each latency.

Autonomous driving is a real-time system. The Autoware State Monitor checks the real-time constraints of the system.

Introduction of Real-Time

This figure shows the high-level architecture of Autoware. An autonomous driving system consists of a set of functions. Each function would be implemented as a ROS node or a set of ROS nodes. A set of functions would have a real-time constraint.

Path Real-Time Constraint
Sensors > Sensing > Perception > Planning > Control > Vehicle I/F > Vehicle Brake reaction distance
Planning > Control > Vehicle I/F > Vehicle Braking distance accuracy
Vehicle > Vehicle I/F > Control > Vehicle I/F > Vehicle Control accuracy
Sensors > Sensing > Localization Localization accuracy

This table shows examples of real-time constraints. Each column shows a real-time constraint corresponding to a path in the architecture graph.

Formulation#

Formulation of Real-Time

A path in a graph is a finite sequence of edges which joins a sequence of vertices which are all distinct (and since the vertices are distinct, so are the edges). The words trail and walk are not used in this context since each node and edge would have only one role in a path even if they appear multiple times in the path.

A path is an unit that has a real-time constraint. A system has a set of paths.

Each Path_i has a set of nodes. The starting point of Path_i is Node S. The end point of Path_i is Node E. Path_i would have the other nodes Node N between Node S and Node E. Node S and Node E would be a same node if a function that has a real-time constraint is implemented in one node.

Node S is invoked (released) at every p_i period. The release time of j-th job of Path_i is r_{i,j}. Node S would be immediately executed at the release time if Node S is immediately scheduled at the release time by the scheduler of operating system. Node S would not be executed immediately at the release if other nodes are selected to be scheduled on CPUs.

Node N and Node E can be executed once each node subscribes a depending topic in Path_i, i.e., the nodes of Path_i is executed sequentially.

A latency of a j-th job of Path_i is presented by l_{i,j}, which is the latency between r_{i,j} and the completion of j-th job of Node E. l_{i,j} may be larger than p_i.

l_{i,j} = (System time when NodeE finished) - (System time when NodeS invoked)

* TBD: What is "System time" in autoware ?

The relative deadline of Path_i is d_i. If l_{i,j} <= d_i for all j, Path_i meets its real-time constraint.

The period p_i and the relative deadline d_i does not have the parameter j since this formulation assumes that p_i and d_i are static parameters, which are not changed at run-time.

Each node (or topic_state_monitor?) records the execution time of n_i. This information will be used for detecting the deadline miss on the way of Path_i.

Requirements#

# System Requirement Related Component
Requirement 1 The system shall detect deadline misses (i.e., l_{i,j} > d_i). (TBD) Autoware State Monitor
Requirement 2 The system records each Node's execution time (TBD) Topic State Monitor
Requirement 3 The system can trigger some actions once deadline misses are detected. Emergency Handler

Design#

The design of Autoware State Monitor focuses on Requirement 1. Requirement 2 is designed in Emergency Handler.

Introduction of Real-Time

Autoware State Monitor subscribes the topic published by Node E in Path_i. Autoware State Monitor detects a deadline miss of the j-th job of P_i if Autoware State Monitor does not subscribe the topic by r_{i,j} + d_i.

Since Autoware State Monitor would not subscribe the j-th topic of Node E before the deadline, Autoware State Monitor shall detect deadline misses by time-out. Autoware State Monitor saves r_{i,j-1} in the initialization phase to calculate the absolute deadline of j-th job in the detection phase. The initialization phase and the detection phase are executed at every j.

Initialization Phase#

  1. Node S sets r_{i,j-1} into a topic, and publishes the topic into Path_i.
  2. Node N and Node E relays r_{i,j-1} on topics without modification.
  3. Autoware State Monitor saves r_{i,j-1} for the Detection Phase.

Detection Phase#

  1. Autoware State Monitor calculates r_{i,j} = r{i,j-1} + p_i.
  2. Autoware State Monitor calculates the absolute deadline = r_{i,j} + d_i.
  3. If (1) Autoware State Monitor does not subscribe the topic in Path_i and (2) the current time exceeds the absolute deadline, Autoware State Monitor publishes the deadline miss event via /diagnostics topic.

Implementation Challenge#

  • How Autoware State Monitor handles j = 1
  • r_{i,j-1} is not defined at j = 1. j = 1 is the system initialization. Autoware State Monitor could use if-guard or ROS2 node lifecycle to wait the system initialization.
  • How Node S gets r_{i,j-1} in the initialization phase.
  • The design assumes that Node S sets r_{i,j-1} and does not set the start time of Node S into the topic. If the period of Node S is triggered by for example sensor hardware, r_{i,j-1} should consider the latency of the sensor.
  • How system detect deadline miss.

  • MRM must work independently of each node status. In this situation, l_i and each node's end time will not be used for calling MRM.

  • Need to be clear how to get and record sytem time

Another Design#

This section describes another design that is not employed.

Design Reason why not employed
Autoware State Monitor gets r_{i,1}, and calculates r_{i,j} = r_{r,1} + p_i * (j - 1). r_{i,j} might slip forward or backward gradually if p_i stored in Autoware State Monitor is not accurate.