SWP 2.1 Use Cases CAM Aggregation WP 2 - System Definition ...€¦ · ECo-AT_SWP2.1_CAM_Aggregation_v03.50 Confidential SWP 2.1 Use Cases . CAM Aggregation . WP 2 - System Definition

European Corridor - Austrian Testbed for Cooperative Systems

Version: 03.50 | 2016-04-29 | Status: Released Page 1 of 36

Release Date: 2016-04-29

Copyright © ECo-AT The content and information enclosed within this document is the property of ECo-AT project members and copyrighted. All rights, in particular rights of communication, distribution, reproduction, reprinting and translation remain, even in extracts, reserved.

ECo-AT_SWP2.1_CAM_Aggregation_v03.50 Confidential

SWP 2.1 Use Cases CAM Aggregation WP 2 - System Definition Version: 03.50



Confidential ECo-AT_SWP2.1_CAM_Aggregation_v03.50

Overview of changes

No. Version Status Date Type of Change

1 01.00 Released 2014-11-21 First Release

2 02.00 Released 2015-03-16 Second Release

3 03.00 Released 2015-07-15 Third Release

4 03.10 Released 2015-10-28 Third Release – Update

5 03.50 Released 2016-04-29 Third Release – Second Update

Table 1: Document History

Reference to the status- and version administration:

Status:

In progress the document is currently in editing mode

Released the document has been checked and released by quality assurance, it can only be modified if the

version number is updated.

Versions:

Takes place in two stages. Released documents receive the next higher integral version number.

00.01, 00.02 etc. Not released versions, with the status in progress 01, 02, etc. Released version with the status released




Table of contents

1 Document Information ...................................................................................................................... 5 1.1 Purpose of this document ................................................................................................................... 5 1.2 Definitions, Terms and Abbreviations ................................................................................................. 5 1.3 References .......................................................................................................................................... 6

2 Overall Information about Releases for CAM Aggregation .......................................................... 6

3 Considerations for CAM Aggregation ............................................................................................. 8

4 TLS Information ................................................................................................................................. 9 4.1 Comparison TLS vs. CAM ................................................................................................................. 10

5 Functional Description of CAM Traffic Data Aggregation .......................................................... 12 5.1 UC CAM aggregation scenarios ........................................................................................................ 12 5.2 General CAM Traffic Data Aggregation ............................................................................................ 13 5.2.1 CAM aggregation detectionZones ..................................................................................................... 13 5.2.2 CAM aggregation method ................................................................................................................. 16 5.2.3 R-ITS-S self-configuration mode ....................................................................................................... 19 5.2.4 Update of CAM aggregation configuration ........................................................................................ 21 5.2.5 Average speed estimation ................................................................................................................. 24 5.2.6 Buffer of aggregated data ................................................................................................................. 24 5.2.7 Trigger conditions .............................................................................................................................. 24 5.3 Single vehicle data and travel time estimation .................................................................................. 24 5.3.1 Trigger conditions .............................................................................................................................. 25

6 Data element tables......................................................................................................................... 25 6.1 General CAM traffic data aggregation............................................................................................... 25 6.1.1 CAM aggregation data (R-ITS-S C-ITS-S TCC) ...................................................................... 25 6.1.2 CAM aggregation configuration parameters (C-ITS-S R-ITS-S) .................................................. 32 6.2 Single vehicle data ............................................................................................................................ 35




List of Tables

Table 1: Document History ................................................................................................................................ 2 Table 2: Definitions, Terms and Abbreviations .................................................................................................. 5 Table 3: Comparison between TLS and CAM data ......................................................................................... 10 Table 4: Assignment proposal for ITS-G5 station types to TLS (2+0)............................................................. 17 Table 5: CAM aggregation data (R-ITS-S --> C-ITS-S --> TCC)..................................................................... 26 Table 6: CAM aggregation configuration parameters (C-ITS-S --> R-ITS-S) ................................................. 32 Table 7: Single vehicle data (R-ITS-S TCC) ............................................................................................... 35




1 Document Information

1.1 Purpose of this document

This document describes the use case and functionality for a basic “CAM aggregation” (Cooperative awareness message aggregation) service, one of the Day 1 use cases to be implemented in the ECo-AT project. The use case definition essentially serves the following purposes:

1. It creates a common understanding of all project partners in ECo-AT regarding the objectives, the functional elements and the general course of activities and interactions in the particular use case.

2. It is the basis for further, more detailed specifications of the applications, messages and components needed to implement this use case in ECo-AT, in SWP 2.1 and beyond.

One of the planned use cases in ECo-AT was Probe Vehicle Data (PVD). PVD is an important part of (infrastructure based) C-ITS, giving the traffic control center (TCC) valuable data about the status on the road. Until now there is no standard or data format specified for PVD, because there is no consensus with the C2C-CC and the automotive manufacturers for Day 1. For this reason a method for collecting possible data from vehicles, based on an already existing C-ITS data format, is specified in ECo-AT: Cooperative Awareness Message (CAM) aggregation. The roadside ITS stations (R-ITS-Ss) are aggregating the CAMs sent out by vehicles in the coverage area of the R-ITS-S. The first step is to collect data that is similar to the currently available data from established traffic control systems defined in “Technische Lieferbedingungen für Streckenstationen” (TLS – technical delivery conditions for route stations), Ref. [TLS]. Further steps are the definition of data beyond TLS data and functional description of CAM aggregation as available in this document.

1.2 Definitions, Terms and Abbreviations

Table 2: Definitions, Terms and Abbreviations

Abbreviation / Term Definition

CAM Cooperative awareness message

C2C-CC Car 2 Car Communication Consortium

C-ITS-S Central ITS station




Abbreviation / Term Definition

LkwÄ Truck or similar vehicle

PkwÄ Passenger car or a similar vehicle

PVD Probe vehicle data

R-ITS-S Roadside ITS station

RW Road works

TLS Technische Lieferbedingungen für Streckenstationen (technical delivery conditions for route stations)

UC Use case

1.3 References

All references in this document can be found in the master table of references available in the “Eco-AT_SWP2.3_MasterTableofReferences_v03.50.pdf” document.

2 Overall Information about Releases for CAM Aggregation

• Release 1: CAM aggregation similar to TLS – first draft

o Which data from TLS can be supported by CAM aggregation?

o Proposal for a general CAM aggregation concept

• Release 2: updated CAM aggregation document

o Added an additional option for the definition of the detection zones: using only the direction/heading information of the roads

o The information about the standard deviation of speed is deleted from the aggregated data (no requirement from the TCC)

o The information about exterior lights is added as further optional data element in the aggregated data (can be used e.g. for fog detection)

o Definition of a meaningful subset of station types (vehicles classes)




o The aggregation data is grouped into a short term aggregation and long term aggregation (requirement from TCC)

Added the possibility of assigning the station types (vehicle classes) to station type groups

o Added data element tables for CAM aggregation data and CAM aggregation configuration data

• Release 3: updated CAM aggregation document

o Added average speed estimation algorithm (time mean speed and space mean speed)

o Added configuration parameters (definition of detection zones and short term aggregation station type groups) in reported aggregated data (self-contained message)

o Added self-configuration of detection zones

o Added MIN, MAX of speed

o Added buffer functionality for long term aggregation

o Added group of station types proposal in accordance with TLS (2+0)

o Added single vehicle data and travel time calculation

o Restructuring of data element tables (e.g. detection zones, station types, exterior lights, collection interval, station type groups)

o Added default value for long term aggregation

• Release 3.1: final CAM aggregation document

o Minor changes in text in Table 3 (Comparison between TLS and CAM data)

o More detailed description about detectionZones (2 methods: detectionZone configuration method 1: rectangle method; detectionZone configuration method 2: heading method)

o A circle is specified (vehicles inside the circle are counted) for the heading method

o Reference position is added to the parameters for the heading method

o Specification of the tolerance angle, ∆, for the heading

o Specification of self-configuration

o Specification of process, when the configuration is updated




o Added trigger conditions

o Added the duration for keeping the stationID/vehicleID mapping in the C-ITS-S

o Added the method for ignoring CAMs for single vehicle data

o Structure of data model (Chapt. 6.1.1 and Chapt 6.1.2) changed

• Release 3.5: editorial changes to the final CAM aggregation document

o Included UC CAM aggregation scenarios

o Changed references table to master table references document

o Updated geoArea and toleranceAngle in Chapt. 6 Data element tables (Table 6, Table 7)

• Day2 (not part of ECo-AT): data aggregation from PVD (specification of PVD is not agreed)

3 Considerations for CAM Aggregation

• The traffic data shall be estimated from CAMs received by an R-ITS-S (from the coverage area of the R-ITS-S)

• Stationary R-ITS-S

o The parameters (road topology, aggregation areas, heading, blocking of roads adjacent/parallel to highway, …) shall be configured manually at the central side.

• Mobile R-ITS-S (with connection to the central ITS station (C-ITS-S))

o The parameters (road topology, aggregation areas, heading, blocking of roads adjacent/parallel to highway, …) shall be configured at the central side. Compared to the stationary R-ITS-S they are more dynamic, because the mobile R-ITS-S can change their position (road works (RW) trailer) based on the location of the short term RW.

• Mobile R-ITS-S (standalone case, without a connection to the C-ITS-S)

o The R-ITS-S has to set the parameters by itself. Self-configuration mode. The R-ITS-S has to “learn” the road topology.

• Different highway scenarios (road topologies)




o It has to be considered if the highway scenario has any influence on the traffic data aggregation. Maybe the algorithm (definition of detection zones in combination with GNSS position tolerance) is not working in all scenarios, especially in the self-configuration mode, e.g.

Highway junction with many ramps

Parallel rural road to the highway

4 TLS Information

The TLS document Ref. [TLS] defines following traffic data for 2+0 sensors (sensor only classifies traffic in classes “trucks and similar vehicles” and “passenger cars and similar vehicles”):

• Byte 4 Traffic volume qKfz [ Vehicle/time interval ]

o Traffic volume of all vehicles

• Byte 5 Traffic volume qLkwÄ [ Vehicle/time interval ]

o Traffic volume of trucks or similar to trucks (passenger cars with trailer, trucks, trucks with trailer, buses)

• Byte 6 Average speed vPkwÄ [0 to 254 km/h, 255]

o Average speed of passenger cars or similar to passenger cars (not classifiable vehicles, motorcycle, passenger cars, vans until 3.5t)

• Byte 7 Average speed vLkwÄ [0 to 254 km/h, 255]

o Average speed of trucks or similar to trucks (passenger cars with trailer, trucks, trucks with trailer, buses)

• Byte 8 Average net time gap t [0 to 25.4 s, 255]

• Byte 9 Assignment b [0–100 % ]

• Byte 10 Standard deviation sKfz [0 to 254 km/h, 255]

o Standard deviation of speed for all vehicles

• Byte 11 Smoothed average speed vKfz [0 to 254 km/h, 255]




o Smoothed average speed for all vehicles

4.1 Comparison TLS vs. CAM

This chapter describes the TLS data and which data can be supported with CAM aggregation.

General

• TLS data is gathered on a by-lane basis, for all vehicles

• CAM data is gathered on a by-detection zone basis, only for ITS-G5-equipped vehicles

Table 3: Comparison between TLS and CAM data

TLS CAM

Vehicle type • All vehicles

• Passenger cars or similar

• Trucks or similar

(=stationType)

• motorcycle

• passengerCar

• bus

• lightTruck

• heavyTruck

• trailer

• specialVehicle

station types can be grouped together, in order to satisfy the requirements from the road operator

Traffic volume Total count of vehicles that crossed the detection zone during the collection interval (all vehicles, trucks)

count of all ITS-G5 vehicles, per detection zone, per stationType during the collection interval

Speed Average speed of all vehicles that crossed the detection zone during the collection interval (passenger cars, trucks)

average speed of all ITS-G5 vehicles, per detection zone, per stationType during the collection interval




Gap The average time that elapses between the departure of the first vehicle from the detector and the arrival of the second vehicle at the detector during the collection interval

Not possible with exclusively CAM (only if ITS-G5 equipped vehicle penetration is close to 100% - in this case it has to be evaluated if the gap can be calculated)

Assignment (occupancy)

The percentage of time during collection the interval that the detector is occupied (activated due to a vehicle being over it)

Not possible with exclusively CAM (only if ITS-G5 equipped vehicle penetration is close to 100% - in this case it has to be evaluated if the gap can be calculated)

Standard deviation (of speeds) and smoothed speed, min. and max. speed

Standard deviation (smoothed average) of speed for all vehicles

CAM offers the possibility to evaluate

• Standard deviation of speed for each single station type

• Standard deviation of speed for all vehicles

• Min. and max. speed of a station type

Status of exterior lights

Not possible Number of vehicles switched on their exterior lights (e.g. beam head lights, daytime running lights, fog lights)

Travel time Not possible If the pseudonym from the vehicle is not changing in between two R-ITS-S the travel time of a vehicle in between two R-ITS-S can be estimated




5 Functional Description of CAM Traffic Data Aggregation

5.1 UC CAM aggregation scenarios

Each use case can be broken down into so called “scenarios”. A scenario is s a sequence of events within

the C-ITS system that forms a mode of operation for the use case. Each use case contains at least one

scenario, but can of course also consist of multiple scenarios, covering different ways of operation possible

for the underlying C-ITS system.

In regard to the “CAM aggregation” use case, the following scenarios are covered:

1. General CAM traffic data aggregation The R-ITS-S receives the CAMs from the vehicles in the coverage area of the R-ITS-S. The R-ITS-S aggregates the relevant data from the CAMs during a specific collection interval (short term collection interval and long term collection interval) per predefined detection zone. After the collection interval is expired the R-ITS-S sends the aggregated data per station type group (short term aggregation) and per station type (long term aggregation) to the C-ITS-S. The C-ITS-S maps the CAM aggregated data specified on IF3 to DATEX II content and forwards the CAM aggregated data via IF1 to the TCC.

2. Single vehicle data The R-ITS-S takes the relevant information (single vehicle data) from the first received CAM of a vehicle. All further CAMs from the same vehicle are filtered out at the R-ITS-S. The R-ITS-S sends the single vehicle to the C-ITS-S. The C-ITS-S maps the single vehicle data specified on IF3 to DATEX II content (including a mapping of the stationID to a vehicleID, because of privacy reasons) and forwards the single vehicle data via IF1 to the TCC.

3. Travel time estimation The process of this scenario is the same as the scenario single vehicle data. Additionally to the process for single vehicle scenario the TCC can combine the single vehicle data from the same vehicle (vehicleID) received from different R-ITS-Ss and estimate the travel time of the vehicle between the R-ITS-Ss.

4. Manual configuration of CAM aggregation at C-ITS-S The CAM aggregation configuration for the R-ITS-S is done on the C-ITS-S and send via IF3 to the R-ITS-S. The R-ITS-S sets this configuration for further CAM aggregation.

5. Self-configuration of CAM aggregation at R-ITS-S The R-ITS-S (e.g. at road works trailers) can detect detection zones by itself. The self-configuration method is limited to “simple” road topologies.




5.2 General CAM Traffic Data Aggregation

5.2.1 CAM aggregation detectionZones

The area around the R-ITS-S is segmented into detectionZones. The R-ITS-S reports the aggregated data for each detectionZone. Each R-ITS-S can have up to eight DetectionZone(s). Two methods are specified, in order to configure a detectionZone:

• DetectionZone configuration method 1: rectangle method

• DetectionZone configuration method 2: heading method

5.2.1.1 DetectionZone configuration method 1: rectangle method

The area around the R-ITS-S is segmented into rectangular detectionZones, each containing an azimuth/heading, which represents the driving direction of vehicles to be detected in that zone, see Figure 1.

Figure 1: detectionZone(s) around R-ITS-S

It has to be mentioned that usually the road is not parallel to the coordinate system, i.e. the sides of the rectangle, defining the detectionZone, are not parallel to the coordinate system. The rectangle is defined as described in Ref. [ETSI 302 931]. With detectionZone configuration method 1 the detectionZone is defined by:




• referencePosition (center of rectangle)

• distanceA (distance between the center point and one side of the rectangle – side A is parallel to the heading)

• distanceB (distance between the center point and the second side of the rectangle – side B is perpendicular to the heading)

• heading (azimuth angle of the side A of the rectangle)

• toleranceAngle

Figure 2 shows the definition of the parameters for the rectangle method.

North

distanceAdistanceB

heading

referencePosition

Figure 2: detectionZone configuration method 1: rectangle method - parameter definition

For the heading a tolerance angle of ∆ = +/- 10° is set. All vehicles that are inside this tolerance are counted for this heading.




North

heading

heading + ∆

heading - ∆

Figure 3: tolerance angle for heading

5.2.1.2 DetectionZone configuration method 2: heading method

A detectionZone can also be represented by just the azimuth component, eliminating the need for geo-coordinates of the rectangle. Figure 4 shows an example of detectionZones just defined by heading (including main highway and ramps). As for detectionZone configuration method 1, a tolerance angle, ∆, is set for the heading. All vehicles that are inside this tolerance are counted for this heading, see Figure 3.

Additional to the heading a circle around a referencePosition defines the full detectionZone, see Figure 5.

Figure 4: detectionZone(s) defined only by direction/heading information




North

heading

referencePosition

sectorRadius

heading + ∆

heading - ∆

Figure 5: detectionZone configuration method 2: heading method

With detectionZone configuration method 2 the detectionZone is defined by:

• referencePosition

• sectorRadius

• heading

• toleranceAngle

5.2.2 CAM aggregation method

The R-ITS-S will collect average speed data (and max. and min. speed) for certain types of vehicles (stationType) for each defined detection zone during a pre-defined collection interval. When the collection interval ends the average speed (and max. and min. speed) and total volume data for each detection zone will be sent to the C-ITS-S, which will forward it to the TCC, and a new collection interval will begin. As further optional information (the data element in the message is optional and has not to be included mandatory) the status of the exterior lights can be sent. This would offer the road operator the ability to detect, e.g. fog on the road, if the vehicles have turned on their fog lights.

In ETSI common data dictionary Ref. [ETSI 102 894-2] the following station types are defined

StationType ::= INTEGER { unknown(0), pedestrian(1), cyclist(2), moped(3), motorcycle(4), passengerCar(5), bus(6), lightTruck(7), heavyTruck(8), trailer(9), specialVehicles(10), tram(11), roadSideUnit(15) } (0..255)




which can be used for vehicle classification. For ECo-AT the following meaningful subset of station types is used

StationType ::= INTEGER { unknown(0), motorcycle(4), passengerCar(5), bus(6), lightTruck(7), heavyTruck(8), specialVehicles(10) } (0..255)

A short term aggregation and a long term aggregation of the vehicle data shall be possible. The short term aggregation is mainly used for traffic management and therefore the station types can be assigned to station type groups (up to 8 groups), e.g. one group for passenger cars and similar and one group for trucks and similar, in order to set different speed limits for passenger cars and trucks by the road operator. The long term aggregation data is mainly used for statistical reason. In this case the traffic information from all of the seven ECo-AT station types is sent to the TCC, without assigning to groups.

In order to be consistent with the TLS (2+0) data, following assignment is proposed for the short term aggregation, see Table 4.

Table 4: Assignment proposal for ITS-G5 station types to TLS (2+0)

TLS (2+0) ITS-G5 station types

All vehicles unknown(0), motorcycle(4), passengerCar(5),

bus(6), lightTruck(7), heavyTruck(8),

specialVehicles(10)

Passenger cars or similar (PkwÄ) unknown(0), motorcycle(4), passengerCar(5)

Trucks or similar (LkwÄ) bus(6) , lightTruck(7), heavyTruck(8)

The collectionInterval will be configurable on a per-R-ITS-S basis (short term aggregation: 30s .. 900s, default 60 seconds, long term aggregation: minimum 30min).

Speed data is collected from vehicle CAM transmissions, which are received by the R-ITS-S during the collectionInterval.

In order for the vehicle to be included in the traffic data computation it must have:

• a StationType in (0, 4, 5, 6, 7, 8, 10)

• a distinct StationID for this collectionInterval

• a heading that matches the defined driving direction of the detectionZone +/- tolerance, ∆




• a referencePosition that is within the detectionZone (rectangle in case of rectangle method and circle in case of heading method)

The R-ITS-S will also maintain the traffic volume and exterior light information (optional) of each type of vehicle (or vehicle group) per detection zone and collectionInterval. At the end of the collectionInterval, the R-ITS-S will send the data to the C-ITS-S. The traffic data will include:

• R-ITS-S ID

• the timestamp of the end of the CollectionInterval

• type of aggregation: short term or long term

• configured by C-ITS-S (manually) or R-ITS-S (self-configured)

• the setting of the CollectionInterval

• detection zone setting

o detection zone ID

o definition of detection zone (rectangle method: reference position, distance A, distance B, heading, tolerance angle; heading method: reference position, sector radius, heading, tolerance angle)

• station type group setting

o short station type group ID

o station types included in short station type group

• report

o per detection zone:

the detection zone ID

per stationType (or groups of stationTypes):

• station type ID (or station type group ID)

• average speed (average speed in time and average speed in space)

• min. and max. speed

• traffic volume (number of vehicles)




• number of vehicle with headlights on (high or low beam) (optional)

• number of vehicles with daytime running lights on (optional)

• number of vehicles with fog lights on (optional)

The number of vehicles per collectionInterval can be used as quality parameter for the average speed

information (i.e. a high value of traffic volume is equal to a high quality).

5.2.3 R-ITS-S self-configuration mode

The R-ITS-S (e.g. at road works trailers) shall be able to set the detection zones by itself and not by configuration from the C-ITS-S. The self-configuration mode shall only use the detectionZone configuration method 2 (heading method) and not the detectionZone configuration method 1 (rectangle method). In the self-configuration mode the R-ITS-S shall evaluate a set of received CAMs and estimate the direction of the road that is reported in the aggregated CAM data.

The self-configuration method is limited to “simple” road topologies:

• The self-configuration is limited to 4 headings (road directions) – if there are more headings detected by the R-ITS-S, the self-configuration method shall not be used and the C-ITS-S shall be informed that the configuration has to come from the C-ITS-S.

o Example scenario: the self-configuration method is working in a simple highway scenario with 2 directions plus 2 ramps (leading to 4 headings)

• As referencePosition the position of the R-ITS-S is set

• A circle around the referencePosition is set (sectorRadius = 40m). Only vehicles that are inside this circle are used in the self-configuration mode.

The self-configuration method shall span up a tolerance angle of ∆ = +/- 10° around the heading. The sectors that are spanned up by [heading-∆..heading+∆] shall not overlap. So the difference of 2 headings has to be greater or equal to 2⋅∆.




Road direction #1: [heading1−∆ ... heading1+∆]∆

∆

∆

∆

Road direction #2: [heading2−∆ ... heading2+∆]

|heading1−heading2| ≥ 2⋅∆

Figure 6: condition for detectionZones spanned up by headings

Further the self-configuration mode shall be configurable at the R-ITS-S (shall be able to be switched ON and OFF – default: OFF).

The detailed implementation of how to get the information of heading from the CAMs of the vehicles are vendor specific and shall be verified in the Living Lab. In the following two proposals for implementation are given:

5.2.3.1 R-ITS-S self-configuration method 1 (not mandatory)

All CAMs from vehicles that are inside the circle (with radius sectorRadius) are used for the self-configuration. The mean of the heading information from all CAMs from one vehicle (inside the circle) is taken. With this mean value from all vehicles the general heading can be identified.

5.2.3.2 R-ITS-S self-configuration method 2 (not mandatory)

The R-ITS-S starts to identify the headings, by collecting the vectors of vehicles inside the circle (with radius

sectorRadius). The self-configuration of the detectionZones can be triggered by the information sent from

the vehicles in this area, passing the R-ITS-S and providing CAM data. One part of this data set are the

GPS-positions of the vehicles. As a vehicle is also delivering its stationID, it is possible to identify the first

position and the last position inside the circle.

From the first received position of a vehicle and the last received position of a vehicle in the circle a vector is

built. The position received last can be derived by a simple timeout after the last received CAM. During that

learning phase all vectors which are located within a limited range (tolerance angle: +/- ∆) are combined to

one area (parameter 1). The angle is used to derive all vehicles of one driving direction by considering




random fluctuations due to the changing of lanes and due to imperfect GPS-positions. In a second step the

geographical areas which have the same distance of the normal to the reference point – which is e.g. the

position of the R-ITS-S - are combined to one area or driving direction. The range of the length of the normal

is defined by a parameter (parameter 2). In case of a high precision of the GPS-positioning, this principle

allows also the identification of different lanes of one driving direction.

The algorithm requires two parameters

• Acceptable range for the angle of the vector • Acceptable range for the length of the normal

Detection range

R-ITS-S

Vector of the vehicle

Normal of the vector to the reference point (can be the position of the R-ITS-S)

Last received position

First received position

Figure 7: R-ITS-S self-configuration method 2 - using first and last vehicle position

5.2.4 Update of CAM aggregation configuration

An update of the CAM aggregation configuration can be initiated by the C-ITS-S or by the R-ITS-S (self-configuration). Since the R-ITS-S is continuously aggregating and sending aggregation reports for short term aggregation and long term aggregation, a process when the updated configuration shall be applied has to be




specified. The following description counts for C-ITS-S configuration as well as for self-configuration at R-ITS-S.

In general the CAM aggregation can be grouped in short term intervals and long term intervals, where the short term intervals are fractions from the long term interval. Figure 8 gives a graphical explanation of these intervals. After the first configuration is set (can be from C-ITS-S or self-configured) the first short term interval starts. For clarification, when an updated configuration shall be applied we have to distinguish between the duration before the first long term aggregation interval starts and after the start of the first long term aggregation interval (see dashed line in Figure 8).

Figure 8: CAM aggregation report and configuration explanation

Figure 9 shows the process if an updated configuration is set:

• If there is an updated CAM aggregation configuration set before the first long term aggregation interval started, the new configuration is applied for the next short term aggregation interval (the short term aggregation report for the interval during the updated configuration was set, still reports the short term aggregation with the old configuration – this satisfies that the configuration is used for the whole interval and not only for a fraction of the interval (which would not make sense interpreting the reported data))

o Example from Figure 9: config#2 is set before the first long term interval starts. Config#2 will be applied for the next full short term aggregation interval.




• There will be no long term aggregation report at the start of the first long term interval, because the interval before was not complete

• After the start of the first long term interval, a new configuration will be applied after the reporting of this first long term aggregation interval (counts for short term aggregation reports as well as for long term aggregation reports)

o First example from Figure 9: config#3 is set after the start of the first long term interval (before the first long term aggregation report). All short term aggregation reports during the first long term interval are using config#2 (including the short term aggregation report that is at the same time as the first long term aggregation report). Also the first long term aggregation report is using config#2. Config#3 is applied after the first long term aggregation report (for short term aggregation as well as for long term aggregation)

o Second example from Figure 9: config#4 is set during a long term aggregation interval. All short term aggregation reports during this long term aggregation interval are using config#3. Also the reporting of this long term aggregation is using config#3. Config#4 is applied after this long term aggregation interval for short term aggregation as well as for long term aggregation.

Figure 9: CAM aggregation configuration update process




5.2.5 Average speed estimation

Two different average speed estimation methods shall be used (time mean speed and space mean speed). The time mean speed estimation algorithm at the R-ITS-S shall work as following. The mean value of the speed information from all CAMs from a vehicle (stationID) shall be taken. Afterwards the mean value over all vehicles from a stationType (or group of stationTypes) shall be taken.

1𝑁𝑁�

1𝐼𝐼

𝑁𝑁

𝑛𝑛=1

�𝑣𝑣𝑖𝑖,𝑛𝑛

𝐼𝐼

𝑖𝑖=1

i is the index of the received CAM at the R-ITS-S from one vehicle and the overall number of received CAMs is represented with I (i = 1…I). n is the index of the vehicle from one stationType (group of stationTypes) with N as the overall number of vehicles from one stationType (group of stationTypes) (n = 1…N). vi,n represents the speed information from CAM i and vehicle n.

The space mean speed estimation algorithm is defined as following.

𝑁𝑁��1𝐼𝐼�𝑣𝑣𝑖𝑖,𝑛𝑛

𝐼𝐼

𝑖𝑖=1

�

−1𝑁𝑁

𝑛𝑛=1

�

−1

5.2.6 Buffer of aggregated data

If the connection between the R-ITS-S and the C-ITS-S is lost the R-ITS-S shall buffer the long term aggregated data (for max. 3 days) and send the buffered data to the C-ITS-S when the connection is reestablished. The buffer shall be persistent (if there is a reboot of the R-ITS-S the data shall not be lost). Short term aggregated data is not buffered at the R-ITS-S.

5.2.7 Trigger conditions

The short term aggregated data report and the long term aggregated data report shall be sent after the short term aggregation interval and the long term aggregation interval are ended. Both reports are actively sent by the R-ITS-S (push from R-ITS-S).

5.3 Single vehicle data and travel time estimation

The R-ITS-S shall forward single vehicle data to the C-ITS-S that is forwarding the data to the TCC. The R-ITS-S shall take only the information from the first received CAM from a vehicle. All further CAMs from the same vehicle shall not be forwarded to the C-ITS-S. The R-ITS-S sets a timer of 30 sec (the value shall be configurable and tested in the Living Lab) after each received CAM. If there is no CAM received from the same stationID during the timer duration, this stationID shall be deleted from the R-ITS-S table (if a CAM from this stationID is received after time out the vehicle is counted as new vehicle). If there is a new CAM from the same stationID received before time out the timer starts again. The C-ITS-S shall forward data from the R-ITS-S to the TCC. The data shall include:




• stationID (from R-ITS-S to C-ITS-S) / vehicleID (from C-ITS-S to TCC)

• stationType

• time stamp

• position

• speed

• heading

The R-ITS-S sends the stationID to the C-ITS-S. Because of privacy issues the C-ITS-S is mapping the stationID to a new generated vehicleID. There is no information about the stationID at the TCC. With this mapping the vehicles reported to the TCC cannot be matched directly to the stationID from the vehicles on the road. The C-ITS-S shall store the stationID (which means the mapping between stationID and vehicleID) reported by the R-ITS-S for 120 minutes. After 120 minutes the stationID can be deleted from the C-ITS-S mapping table.

With this information at the TCC the travel time between two R-ITS-Ss can be calculated at the TCC (assuming that there was no pseudonym change of the V-ITS-S, which means that the TCC will get the same vehicleID from the C-ITS-S).

5.3.1 Trigger conditions

The single vehicle data shall be sent by the R-ITS-S to the C-ITS-S after the first CAM from a vehicle is received by the R-ITS-S. The C-ITS-S forwards the single vehicle data to the TCC (the stationID is mapped to a vehicleID).

6 Data element tables

6.1 General CAM traffic data aggregation

6.1.1 CAM aggregation data (R-ITS-S C-ITS-S TCC)

The set of data elements described here are used for the short term aggregation as well as for the long term aggregation. The set of data elements can be distinguished by the data element typeIndicator. The set of data elements describes the interface R-ITS-S C-ITS-S as well as the interface C-ITS-S TCC (only roadsideId has to be checked if this is already covered by the OCIT-C protocol).




Table 5: CAM aggregation data (R-ITS-S --> C-ITS-S --> TCC)

Data element Container

M/O

Source Comment Ref

roadsideId

M C-ITS-S The C-ITS-S adds an R-ITS-S identifier

(1 … 9999) to the data before sending it

to the TCC.

Identifier as in OCIT-C (TBD).

camAggregationTimest

amp

M R-ITS-S Timestamp of the end of the

collectionInterval

Comment:

The start and end time of the collection

interval shall be the same for all R-ITS-

S. There has to be a definition of the

common start time (e.g. every full

minute, every full hour). This is

important for the evaluation at the TCC.

The reporting of the aggregated data

can have an offset between the R-ITS-

Ss, in order to decrease the network

load (not all R-ITS-S are reporting at the

same time)

aggregationType M R-ITS-S Indication if it is a short term aggregation

or a long term aggregation:

• Shortterm: short term

aggregation

• Longterm: long term

aggregation

selfConfiguredZone M R-ITS-S This element indicates if the detection

zone was configured by input from the

C-ITS-S or self-configured at the R-ITS-

S:

Configured by C-ITS-S: 0

Self-configured: 1




collectionInterval M R-ITS-S Setting of the collectionInterval in

seconds

detectionZones M R-ITS-S detectionZone M R-ITS-S 1 … 8 detectionZoneId M R-ITS-S detectionZoneId from 1 … 8

This ID gives the information about the

zone around the R-ITS-S. Up to 8 zones

can be defined. Note: only active

detectionZones are reported

geoArea M R-ITS-S Definition of detection zones:

• as rectangle described in Ref.

[ETSI 302 931] incl. azimuth

(heading) (with mandatory data

elements: shape (rectangular),

center (=referencePosition),

distanceA, distanceB, angle

(=heading)) or

• only heading (azimuth)

information in degrees as

defined in Ref. [ETSI 302 931]: INTEGER {wgs84North(0),

wgs84East(900),wgs84South(1800

), wgs84West(2700),

unavailable(3601)} (0..3601)

Unit: 0,1 degrees

(with following mandatory data

elements: shape (circular),


distA (=sectorRadius), angle

(=heading))

Note: use the unavailable state for an

inactive detectionZone.

The second method (only heading) is

the preferred one, because heading

information usually is more accurate

than position information.




toleranceAngle M R-ITS-S Tolerance angle as offset (+/-) in relation

to the heading (angle) in geoArea. All

vehicles that are inside this tolerance

are counted for this heading.

groups M R-ITS-S stationTypeGroup M R-ITS-S 1 … 8 shortStationType

GroupId

M R-ITS-S The shortStationTypeGroupId defines a

group of vehicle classes. There can be

up to 8 station type groups (1 … 8).

Following station types (subset of ETSI

CAM station types, Ref. [ETSI 102 894-

2]) can be assigned to station type

groups: StationType ::= INTEGER { unknown(0), motorcycle(4), passengerCar(5), bus(6), lightTruck(7), heavyTruck(8), specialVehicles(10), } (0..255)

E.g., shortStationTypeGroupID (1)

contains motorcycle(4),

passengerCar(5), lightTruck(7)

shortStationTypeGroupID (2) contains

bus(6), heavyTruck(8)


unknown(0)

all other groups are empty

Open question: shall the length of

station type groups be fixed (always 8)

or variable (if there are less groups, just

send this number of groups)?

stationType M R-ITS-S 1 … 7 – add all station types that are

included in shortStationTypeGroupId: StationType ::= INTEGER { unknown(0),




motorcycle(4), passengerCar(5),


specialVehicles(10), } (0..255) reports M R-ITS-S zoneReport M R-ITS-S 1 … 8 detectionZoneId

M R-ITS-S detectionZoneId from 1 … 8





typeOrGroupRe

ports

M R-ITS-S

report M R-ITS-S 1 … 8 stationGr

oupIdOrT

ype

M R-ITS-S In the case of short term aggregation it

describes the station type group.

• Short term aggregation: There

can be up to 8 station type

groups (1 … 8). For further

explanation see

shortStationTypeGroupID in

Table 6

Note: only non-empty stationGroups are

reported.

In case of long term aggregation it

describes the station type:

• Long term aggregation: in this

case always the information

about all station types is sent

(unknown(0), motorcycle(4), passengerCar(5), bus(6),

lightTruck(7), heavyTruck(8),

specialVehicles(10))

Note: only non-empty station types are

reported.

averageS

peedTime

M R-ITS-S Average speed in time for the

detectionZoneId and




stationTypeGroupID during the

collection interval in centimeter/s (0,01

m/s) as it is defined Ref. [ETSI 102 894-

2] DE_SpeedValue SpeedValue ::= INTEGER {standstill(0), oneCentimeterPerSec(1), unavailable(16383)} (0..16383)

A speed value. For values equal to or greater than 163,82 m/s, the value shall be set to 16 382. When the information is not available (i.e. no CAM received from station matching group), the value shall be set to 16 383. Unit: 0,01 m/s

averageS

peedSpac

e

M R-ITS-S Average speed in space for the

detectionZoneId and






minSpeed

M R-ITS-S Min. speed for the detectionZoneId and





A speed value. For values equal to or greater than 163,82 m/s, the value shall be set to 16 382. When the information




is not available (i.e. no CAM received from station matching group), the value shall be set to 16 383. Unit: 0,01 m/s

maxSpee

d

M R-ITS-S max. speed for the detectionZoneId and






trafficVolu

me

M R-ITS-S Number of vehicles per detectionZoneId

and stationTypeGroupID during the

collection interval. If there was no

received CAMs from vehicles during the

collection interval the value is 0 and the

value for average speed shall be set to

16 383.

The trafficVolume data element can be

also used as quality parameter at the

TCC (high number of trafficVolume is

equal to a high quality)

beamHea

dlightsOn

O R-ITS-S Number of vehicles (trafficVolume) for

the detectionZoneId and

stationTypeGroupID that had headlights

on (high or low beam).

daytimeR

unningLig

htsOn



stationTypeGroupID that had daytime




running lights on.

fogLightO

n



stationTypeGroupID that had fog lights

on.

6.1.2 CAM aggregation configuration parameters (C-ITS-S R-ITS-S)

The configuration of the CAM parameters is done at the C-ITS-S (which is located at the road operator facility (TCC)).

Table 6: CAM aggregation configuration parameters (C-ITS-S --> R-ITS-S)


M/O

Source Comment Ref

roadsideId M C-ITS-S Identifier for the R-ITS-S for which the

configuration is valid.

Identifier as in OCIT-C (TBD).

shortCollectionInterval O C-ITS-S Setting of the short term aggregation

collection interval for the R-ITS-S in

seconds (30s … 900s (default value:

60s))

Unit: s

longCollectionInterval O C-ITS-S Setting of the long term aggregation

collection interval for the R-ITS-S in

multiples of the shortCollectionInterval

(60 … 600 (default value: 60)).

e.g. shortCollectionInterval=60s and

longCollectionInterval=120

60s*120=7200s = 2h

Unit: multiples of shortCollectionInterval

detectionZones M C-ITS-S detectionZone M C-ITS-S 1 … 8




detectionZoneId M C-ITS-S detectionZoneId from 1 … 8





geoArea M C-ITS-S Definition of detection zones:

• as rectangle described in Ref.

[ETSI 302 931] incl. azimuth

(heading) (with mandatory data

elements: shape (rectangular),


distanceA, distanceB, angle

(=heading)) or

• only heading (azimuth)

information in degrees as

defined in Ref. [ETSI 302 931]: INTEGER {wgs84North(0),

wgs84East(900),wgs84South(1800

), wgs84West(2700),

unavailable(3601)} (0..3601)

Unit: 0,1 degrees

(with following mandatory data

elements: shape (circular),


distA (=sectorRadius), angle

(=heading))

Note: use the unavailable state for an

inactive detectionZone.

The second method (only heading) is

the preferred one, because heading

information usually is more accurate

than position information.

toleranceAngle M R-ITS-S Tolerance angle as offset (+/-) in relation

to the heading (angle) in geoArea. All

vehicles that are inside this tolerance




are counted for this heading.

groups M C-ITS-S stationTypeGroup M C-ITS-S 1 … 8 shortStationTyp

eGroupID

M C-ITS-S The shortStationTypeGroupID defines a

group of vehicle classes. There can be

up to 8 station type groups (1 … 8).

Following station types (subset of ETSI

CAM station types, Ref. [ETSI 302 931])

can be assigned to station type groups: StationType ::= INTEGER { unknown(0), motorcycle(4), passengerCar(5), bus(6), lightTruck(7), heavyTruck(8), specialVehicles(10), } (0..255)

E.g., shortStationTypeGroupID (1)

contains motorcycle(4),

passengerCar(5), lightTruck(7)


bus(6), heavyTruck(8)


unknown(0)

all other groups are empty

Open question: shall the length of

station type groups be fixed (always 8)

or variable (if there are less groups, just

send this number of groups)?

stationType M C-ITS-S 1 … 7 – add all station types that are

included in shortStationTypeGroupID: StationType ::= INTEGER { unknown(0),



specialVehicles(10), } (0..255)




6.2 Single vehicle data

Table 7: Single vehicle data (R-ITS-S TCC)


M/O

Source Comment Ref

stationID / vehicleID M R-ITS-S / C-ITS-

S

Identifier for the vehicle: the stationID

from CAM is sent from the R-ITS-S to

the C-ITS-S. At the C-ITS-S the

stationID is mapped to a vehicleID that

is send from the C-ITS-S to the TCC.

stationType M R-ITS-S Station type of the vehicle StationType ::= INTEGER { unknown(0),



specialVehicles(10), } (0..255)

timestamp M R-ITS-S Timestamp of the received CAM position M R-ITS-S Position of the vehicle reported in the

CAM as defined in Ref. [ETSI 102 894-

2]

DF_ReferencePosition ReferencePosition ::= SEQUENCE { latitude Latitude, longitude Longitude, positionConfidenceEllipse PosConfidenceEllipse , altitude Altitude }

speed M R-ITS-S Speed of the vehicle reported in the


2]

DE_SpeedValue SpeedValue ::= INTEGER {standstill(0), oneCentimeterPerSec(1), unavailable(16383)} (0..16383)

A speed value. For values equal to or greater than 163,82 m/s, the value shall be set to 16 382. When the information is not available (i.e. no CAM received from station matching group), the value shall be set to 16 383.




Unit: 0,01 m/s

heading M R-ITS-S Heading of the vehicle reported in the


2]

DF_Heading Heading ::= SEQUENCE { headingValue HeadingValue, headingConfidence HeadingConfidence }

Heading in a WGS84 co-ordinates system. The DF shall include the following information:

• headingValue: a heading value. It shall be presented as defined in clause A.35 HeadingValue,

• headingConfidence: the accuracy of the reported heading value with a predefined confidence level. It shall be presented as defined in clause A.34 HeadingConfidence.

(End of Document)

Documents

SWP 2.1 Use Cases CAM Aggregation WP 2 - System Definition ...€¦ · ECo-AT_SWP2.1_CAM_Aggregation_v03.50 Confidential SWP 2.1 Use Cases . CAM Aggregation . WP 2 - System Definition