The Sensor Architecture in Smart-AHS

Marco Antoniotti, Akash Desphande, Francois Dufraisse, Marco Zandonadi

Introduction

Smart-AHS sensor subsystem architecture has been designed to be expandable and easy to use. The design is given as a set of superclasses that are used as the foundation of various types of sensors. Since sensor technology can vary, it was necessary to abstract the behavior of sensing devices by factoring their common features.

Smart-AHS provides the following three-layered sensor architecture of SHIFT types:

• TargetDetector . This is the bottom layer, which provides the functionality of perfect sensors, outputting exact range and range rate with respect to the detected vehicle (if any). This means that noise isn't dealt with at this level. The TargetDetector type should be considered private and shouldn't be used by the Smart-AHS user. It is intended to be used by sensor designers only.
• SensorModel . This is the middle layer, which works as a filter. The perfect results of the lower level are distorted in a way that depends on the model. Noise can be added both to range and range rate and false alarms can also be generated. The SensorModel type should be considered private and shouldn't be used by the Smart-AHS user. It is intended to be used by sensor designers only.
• Sensor . This is the top layer, which is used to hide the complex details of the lower levels from the user (in fact it is the only public part of the architecture). The main function of this type is that of setting up the lower level mechanisms and of providing the user with the results coming from the middle layer.

New sensors can be written by inheriting from the described superclasses (which preserves the interfaces). Also note that the described root types are to be considered abstract. This means that their implementation isn't complete. They should be used only as supertypes. This structure has been used to implement a realistic radar sensor model, which also takes into account weather conditions.

In order to improve performance, some optimization techniques have been used. The roads are divided in cells and sensors actually check for other vehicles only in the neighboring cells. This avoids checking all the vehicles in the simulated world, which is an n² time process. The managment of cells is taken care of by a special type called SEP (Sensor Environment Processor).

Using Sensors

The user only needs to be aware of the SEP type, the Sensor type and their subtypes. The other layers are hidden.

The SEP type

Implementing sensors brought up a performance problem. How is a sensor to determine whether a car is within range? The easiest solution is to look for such a car in the set of all the cars in the world. This is obviously very expensive.

To avoid this, road sections have been subdivided in cells. Each cell corresponds to a set of vehicles. Cars move from cell to cell: when they cross a cell border, they add themselves to the new cell and remove themselves from the old one.

The SEP takes care of updating the cells. The means by which this task is performed is hidden from the user. All the user has to know is how to instantiate the SEP and how to connect it to the other components.

If the istantiation happens inside the vehicle, the create statement looks like this (from now on the italic font is used to denote a reference to a specific component):

SEP sep := create (
  SEP,
  the_vehicle     := self,
  current_segment := starting_segment,
  current_section := starting_section,
  current_cell    := cells (starting_section)[0]
);

The inputs of the SEP can be set with the following connections:

rxp (sep)             <- rxp (vrep);
ryp (sep)             <- ryp (vrep);
rzp (sep)             <- rzp (vrep);
current_lane (sep)    <- lane (vrep);
current_segment (sep) <- segment (vrep);
current_section (sep) <- section (vrep);
followLane (sep)      <- followLane (vrep);
the_vehicle (sep)     <- self;

vehicle_sensors (sep) <- {...};    

The outputs of the SEP are:

• number current_cell_number
• set(Vehicle) current_cell
• set(Vehicle) previous_cell
• set(Vehicle) next_cell
• set(Vehicle) overlap_cell

Note that cell specific informations such as cell length are set up in the Section type. The number of cells is obtained from the length of the section and that of the cells.

The Sensor Type

A Smart-AHS vehicle has one SEP and zero or more sensors. Four sensor links are provided in the Vehicle type: frontSensor, rearSensor, leftSensor and rightSensor. Others may be added in the subtypes of Vehicle.

The Sensor abstract superclass requires the following inputs:

• timer sample_timer
• Vehicle vehicle
• VREP vrep
• SEP sep

The timer type is used to select a sampling time for the sensor.

The outputs of the sensor are the following:

• number range
• number rangeRate
• target detectedTarget

Range is the distance in meters from the detected vehicle. Actually the range is calculated by subtracting half the length of the following car and half the length of the leading car from the distance between the two cars. This method assumes that cars have circular shapes.

Range rate is the difference between the speed of the detected vehicle and the speed of the current vehicle.

The target type encapsulates the detected vehicle. It has the following outputs:

• Vehicle vehicle_detected

Note that the distance in the target doesn't take into account the length of the vehicles.

Currently Implemented Sensors

A few sensors have been implemented on top of the described architecture. Their source code can be studied as an example of implementation.

• range_sensor : it detects the nearest vehicle around it (by "around it" we mean the vehicles in the previous, current and next cell). No noise is simulated, so detections are perfect. Two additional parameters can be provided as input:
• number maxRange: maximum range of detection.
• symbol direction: this can be assigned the value $front or $rear, depending on the desired direction of detection.
• RadarSensor : it detects the nearest vehicle in the area defined by the following parameters, using a radar sensor model. Three additional parameters can be provided as input:
• number fov: field of vision angle
• number minRange: minimum range of detection
• number maxRange: maximum range of detection

Designing New Sensors

TargetDetector

The lowest level of the architecture fulfills the purpose of detecting targets if any. It does not simulate any noise. Its function is purely geometric: e.g. to understand wether a vehicle exists, that falls within the sensor range. For this reason TargetDetectors can be categorized according to the shape of their detection field.

The inputs of this type are:

• Vehicle vehicle
• VREP vrep
• SEP sensor_ep
• sensor enclosingSensor
• timer sample_timer

The outputs are the same as the sensor class. They are actually processed by the upper level before being passed to the sensor. Three transitions take place. It is important that all of them be present:

idle -> update {sample_timer:timer_tick}

It takes place when the timer ticks. It does the detection work and updates the outputs to reflect the results of the detection.

update -> updateUpperLevels {enclosingSensor:update_values}

This one is needed to synchronize with the upper levels once the computation is finished. On this level it's just a signal to notify that the values in the outputs are ready to be read.

updateUpperLevels -> idle {enclosingSensor:values_updated}

It goes back to the initial state.

SensorModel

This is the middle layer and it serves as a noise generator. The perfect results of the Target Detector are read and distorted according to a specific model.

The only input of this type is the fap (false alarm probability) which is optional in some models. It is a value between 0 and 1 and it's used to generate false alarms.

The outputs are:

• number dp
• number range
• number rangeRate
• target detectedTarget

Dp is the detection probability, which is calculated according to the model. The last three values are read from the corresponding targetDetector but can be changed according to some function of fap and of dp.

The state variables are not inherited, so they are included in the root class only as conceptual placeholders. They are:

• sensor enclosingSensor
• TargetDetector targetDetector
• number rE
• number rrE

RE and rrE are the range error and the range rate error.

There must be at least one transition synchronizing on enclosingSensor:update_values. It reads the values in the lower levels and distorts them. Of course there may be more than one such transition (e.g. one for regular detection, one for failed detection, one for false alarms and so on).

Sensor

The public interface ( input and outputs ) of the higher layer has been described already so we'll talk about the private one here.

Two state variables (targetDetector and sensorModel) should be used to link the sensor to its TargetDetector and to its SensorModel. A setup clause should be present to istantiate and initialize correctly these two components.

Two local events are exported:

• update_values
• values_updated

They are used for synchronization with lower levels.

Reading the values from the TargetDetector can be done in two ways. The easiest way is via a flow:

flow
  default {

    range     = range(targetDetector);
    rangeRate = rangeRate(targetDetector);
  };

The second one is via transitions such as:

idle -> update {update_values},
update -> idle {values_updated};

Note that two such transitions must be present anyway because they are used by lower level types and also because in this way the sensor signals it is updating its values to other interested types (e.g. automated cruise control types).

Implementation

Some implementation techniques can be studied by reading the sensors/sensor.hs file in the Smart-AHS distribution.