Skip to main content

DENM

Version

Look for the current version via the link in the table at the message-type introduction page

caution

As of mid november 2024, Mobilidata has changed version regarding AMQP headers (version 0.9 to 1.0). This is caused by changes in the C-Roads (TF4 spec release 2.1.0) specification.

Description​

The DENM (Decentralized Environmental Notification Message) standard is a communication protocol for sharing information related to mobility and the environment. It is designed to facilitate the exchange of data between vehicles, infrastructure, and other entities in the transportation ecosystem.

The standard builds on this framework by specifying a set of message types and data elements that can be used to transmit information related to mobility and the environment.

Some examples of the types of information that can be shared using the DENM standard include traffic congestion, road closures, accidents, and hazardous driving conditions. This information can be used by vehicles and other entities to improve safety and efficiency on the road.

Overall, the DENM standard provides a flexible and interoperable way for vehicles and other entities to exchange information related to mobility and the environment. This can help improve safety and efficiency on the road, and support the development of intelligent transportation systems.

Usage​

The reference point from which all traces are drawn is the event location. In case of a stretched event like roadworks, the reference is the location wher the roadworks is starting. There are two types of traces (optional) in the message:

  • Situation Container: eventHistory (single trace)
    This trace describes the route and length of the event. Literally the route that the event-detecting vehicle has driven until the event ended.
  • Location Container: traces (up to 7 traces)
    These awareness traces indicate where to raise he event warning for the end-user. They are drawn on all (max 7) available upstream roadsegments.

caution

Data packages are encoded/decoded to ASN.1 standard, using the 'UPER' encoding rules.

Timestamps​

The 'referenceTime' and 'detectionTime' in DENM are timestamps in milliseconds with epoch '2004-01-01 UTC' including leap seconds. be aware that standard Unix timeis not aware of leapseconds, depending on the used computing method, those seconds have to be added. The timestamps are defined in ISO 8601 [i.10].

Overview

The following figure provides an overview of the construct of a DEN meassage, complete with the possible value ranges. DENM is for all types of warning technically the same.

Alt text

Attributes​

"Denm": {
    "Management": {
        "ActionID": {
            "OriginatingStationID": 1,
            "SequenceNumber": 19733
        },
        ...
    },
    ...
},

The ActionID contains the the unique identifier of a DENM event, which is a combination of OriginationStationID and SequenceNumber.

"Denm": {
    "Management": {
        ...
        "DetectionTime": 625144898831,
        "ReferenceTime": 625144898831,
        ...
    },
    ...
},

DetectionTime and ReferenceTime contain a timestamp which specifies the actual detection time of the original event and the time the event was added to the MI.

"Denm": {
    "Management": {
        ...
        "EventPosition": {
            "Latitude": 509689670,
            "Longitude": 53592259,
            "PositionConfidenceEllipse": {
                "SemiMajorConfidence": 4095,
                "SemiMajorOrientation": 3601,
                "SemiMinorConfidence": 4095
            },
            ...
        },
        ...
    },
    ...
},

EventPosition describes the exact location of the event and contains the coordinate in Latitude, Longitude and Altitude. It also contains extra information on the accuracy of the measurement. To get the values of Latitude and Longitude in WGS84, the following calculation has to be applied: WGS84 Latitude = Latitude * 1e-7 and WGS84 Longitude = Longitude * 1e-7.

"Denm": {
    "Management": {
        ...
        "ValidityDuration": 5966,
        ...
    }
},

How long the DENM message is valid is described in ValidityDuration. This field contains the time in seconds that the message is valid.

"Denm": {
    "Management": {
        ...
        "StationType": 0
        ...
    }
},

The type of the station that sends the DENM message is described in StationType. Currently this is fixed to 0, but can be extended to be used with eg. IoT device stations.

"Denm": {
    ...
    "Situation": {
        ...
        "InformationQuality": 0,
        ...
    },
    ...
},

The quality of the information in the DENM message is described in InformationQuality. This field contains a value between 0 and 7, where 0 is the lowest quality and 7 is the highest quality.

"Denm": {
    ...
    "Situation": {
        ...
        "EventType": {
            "CauseCodeType": 3,
            "SubCauseCodeType": 0
        },
        ...
    },
    ...
},

In EventType more information about the type of the DENM message is described. This field contains a CauseCodeType and SubCauseCodeType which can be linked to the seperate Use Cases.

An overview of all Cause Codes can be found here.

"Denm": {
    ...
    "Location": {
        "EventSpeed": null,
        "EventPositionHeading": {
            "HeadingValue": 2038,
            "HeadingConfidence": 127
        },
        "Traces": [
            [
                {
                    "PathPosition": {
                        "DeltaLatitude": 0,
                        "DeltaLongitude": 0,
                        "DeltaAltitude": 12800
                    },
                    "PathDeltaTime": null
                },
                {
                    "PathPosition": {
                        "DeltaLatitude": 3740,
                        "DeltaLongitude": 2610,
                        "DeltaAltitude": 12800
                    },
                    "PathDeltaTime": null
                },
                ...
            ],
            ...
        ],
    },
    ...
},

The geographic impact of the DENM message is desribed in the Location attribute. This field contains values for the heading of the event and also the different Traces. These Traces are multiline strings described by delta values from the previous points and describe the roads that are impacted by this event.

Example​

An extended description of the DENM ASN.1 can be found here.

DENM AMQP Header example
{
  "custom-mobilidata-useCase": ",12,",
  "custom-mobilidata-publisherType": "PIP",
  "latitude": "51.010456",
  "subCauseCode": "0",
  "quadTree": ",120202132033011022,",
  "custom-mobilidata-dtapEnvironment": "production",
  "originatingCountry": "BE",
  "custom-mobilidata-alertCCodes": "702,401",
  "publisherId": "BE00004",
  "messageType": "DENM",
  "causeCode": "3",
  "protocolVersion:DENM": "1.3.1",
  "publicationId": "BE00004:DENM_ROADWORKS_01",
  "custom-mobilidata-timestamp": "1710751248100",
  "longitude": "4.515842",
  "shardCount": "1",
  "shardId": "1",
  "baselineVersion": "2.1.0",
  "custom-mobilidata-baselineVersion": "1.0.0"
}

When receiving a DENM message, the AMQP header will contain some extra information that is not included in the DENM message itself. This information can be used to filter and process the message.

  • custom-mobilidata-useCase: The use case of the message.
  • quadTree: The quadtree of the message. This can be used to filter the message on the location based on quadkeys.
DENM Message example
010100000001c100000000a68a9231b144a1e48c6c51287d40628466e7b92c3ffffffe11dbba1f0ba70010030001d4a4786c31ce027f6fd923fffeffffe39c41d370518e39c4080b0162e39c41745040ae39c41733040a639c41dd70527639c4199d0469e39c4199f0469639c414db039ce39c414db03a1e39c402690068e39c4166b0397639c4164103ab639c41bf504d7e39c40d6d025ce39c406dd011c639c3fbc90347e39c3f96efeb0e39c40ffffbffff8e71074dc14638e710202c058b8e7105d14102b8e7105ccc10298e710775c149d8e710667411a78e710667c11a58e710536c0e738e710536c0e878e71009a401a38e71059ac0e5d8e71059040ead8e7106fd4135f8e71035b409738e7101b7404718e7123fffeffffe39c41d370518e39c4080b0162e39c41745040ae39c41733040a639c41dd70527639c4199d0469e39c4199f0469639c414db039ce39c414db03a1e39c402690068e39c4166b0397639c4164103ab639c41bf504d7e39c41a3cfb2d639c40346fe84639c40472fe5be39c3fe82ff00e39c48ffffbffff8e71074dc14638e710202c058b8e7105d14102b8e7105ccc10298e710775c149d8e710667411a78e710667c11a58e710536c0e738e710536c0e878e71009a401a38e71059ac0e5d8e71059040ead8e7106fd4135f8e71035b409738e7101b7404718e70fef240d1f8e70fe5bbfac38e7123fffeffffe39c41d370518e39c4080b0162e39c41745040ae39c41733040a639c41dd70527639c4199d0469e39c4199f0469639c414db039ce39c414db03a1e39c402690068e39c4166b0397639c4164103ab639c41bf504d7e39c41a3cfb2d639c40346fe84639c40472fe5be39c3fe82ff00e39c38ffffbffff8e71074dc14638e710202c058b8e70ff7dc0e378e70fd3a3f8438e70f942bedcd8e70f9433eddf8e70f8da3ecc98e70ffffc08598e710045c35338e710040435338e710045c35338e710045c351f8e710045c35318e7113fffeffffe39c41d370518e39c4080b0162e39c41745040ae39c41733040a639c41dd70527639c4199d0469e39c4199f0469639c414db039ce39c414db03a1e39c402690068e39c4166b0397639c4164103ab639c41bf504d7e39c41a3cfb2d639c40346fe84639c40472fe5be39c0

DENM CauseCodes​

disclaimer

This table is for easy reference. If there is any mismatch with the C-roads specs, always trust the C-roads specs.

Cause codeCause DescriptionDirect Cause CodeSub Cause CodeSub Cause Description
1Traffic condition10Unavailable
1Increased volume of traffic
2Traffic jam slowly increasing
3Traffic jam increasing
4Traffic jam strongly increasing
5Traffic stationary
6Traffic jam slightly decreasing
7Traffic jam decreasing
8Traffic jam strongly decreasing
2Accident20Unavailable
1Multi-vehicle accident
2Heavy accident
3Accident involving lorry
4Accident involving bus
5Accident involving hazardous materials
6Accident on opposite lane
7Unsecured accident
8Assistance requested (e-call)
3Roadworks30Unavailable
1major roadwork
2Road marking work
3Slow moving road maintenance
4Short-term stationary roadWorks
5Street cleaning
6Adverse weather condition - adhesion60Unavailable
1Heavy frost on road
2Fuel on road
3Mud on road
4Snow on road
5Ice on road
6Black ice on road
7Oil on road
8Loose chippings
9Instant black ice
10Roads salted
9Hazardous location - Surface condition90Unavailable
1Rock falls
2Earthquake damage
3Sewer collapse
4Subsidence
5Snow drifts
6Storm damage
7Burst pipe
8Volcano eruption
9Falling ice
10Hazardous location - Obstacle on the road100Unavailable
1Shed load
2Parts of vehicles
3Parts of tyres
4Big objects
5Fallen trees
6Hub caps
7Waiting vehicles
11Hazardous location - Animal on the road110Unavailable
1Wild animals
2Herd of animals
3Small animals
4Large animals
12Human presence on the road120Unavailable
1Children on roadway
2Cyclists on roadway
3Motor cyclist on roadway
14Wrong way driving140Unavailable
1Vehicle driving in the wrong lane
2Vehicle driving in the wrong driving direction
15Rescue and recovery work in progress150Unavailable
1Emergency vehicles
2Rescue helicopter landing
3Police activity ongoing
4Medical emergency ongoing
5Child abduction in progress
17Adverse weather condition - extreme weather condition170Unavailable
1Strong winds
2Damaging hail
3Hurricane
4Thunderstorm
5Tornado
6Blizzard
18Adverse weather condition - visibility180Unavailable
1Visibility reduced due to fog
2Visibility reduced due to smoke
3Visibility reduced due to heavy snowfall
4Visibility reduced due to heavy rain
5Visibility reduced due to heavy hail
6Visibility reduced due to low sun glare
7Visibility reduced due to sandstorms
8Visibility reduced due to swarms of insects
19Adverse weather condition - Precipitation190Unavailable
1Heavy rain
2Heavy snowfall
3Soft hail
26Slow vehicle260Unavailable
1Slow moving maintenance vehicle
2Vehicles slowing to look at accident
3Abnormal load
4Abnormal wide load
5Convoy
6Snowplough
7De-icing
8Salting vehicles
27Dangerous end of queue270Unavailable
1Sudden enf of queue
2Queue over hill
3Queue around bend
4Queue in tunnel
91Vehicle breakdown910Unavailable
1Lack of fuel
2Lack of battery
3Engine problem
4Transmission problem
5Engine cooling problem
6Braking system problem
7Steering problem
8Tyre puncture
92Post crash920Unavailable
1Accident without e-Call triggered
2Accident with e-Call manually triggered
3Accident with e-Call automatically triggered
4Accident with e-Call triggered without possible access to a cell network
93Human problem930Unavailable
1Glycaemia problem
2Heart problem
94Stationary vehicle940Unavailable
1Human Problem
2Vehicle breakdown
3Post crash
4Public transport stop
5Carrying dangerous goods
95Emergency vehicle approaching950Unavailable
1Emergency vehicle approaching
2Prioritized vehicle approaching
96Hazardous location indication - Dangerous Curve960Unavailable
1Dangerous left turn curve
2Dangerous right turn curve
3Multiple curves starting with unknown turning direction
4Multiple curves starting with a left turn
5Multiple curves starting with a right turn
97Collision risk970Unavailable
1Longitudinal collision risk
2Crossing collision risk
3Lateral collision risk
4Collision risk involving a vulnerable road user
98Signal violation980Unavailable
1Stop sign violation
2Traffic light violation
3Turning regulation violation
99Dangerous situation990Unavailable
1Emergency electronic brake lights
2Pre-crash system activated
3ESP (Electronic Stability Program) activated
4ABS (Anti-lock braking system) activated
5AEB (Automatic Emergency Braking) activated
6Brake warning activated
7Collision risk warning activated

Reference: https://www.etsi.org/deliver/etsi_ts/102800_102899/10286901/01.03.01_60/ts_10286901v010301p.pdf

Mobilidata solution for updating DENM messages​

info

The ETSI DENM standard is somewhat confusing according to management of messages with a longer duration as 24 hours, which needs some special attention.

The Main cause of the issue is the fact that the standard does not allow a duration value for longer than those 24 hours and that all relevant time values seem to change at the same moment to the same content.

Justified by the limitation in duration of the DENM message to a maximum of 86400 seconds according to the ETSI standard, the Mobilidata application will update the messages posted on the MI-bus, which are still valid, by updating the fields detectionTime, referenceTime and validityDuration according to the rules, named in the standards documents. For normal usage, the referenceTime is less important. If the interpreter of the message must determine the maximum lifetime of the message it must use the addition of detectionTime and validityDuration.

The actionId field will remain unchanged as well as the other content of the message.

Referral to MI-bus posted messages, is to be done be using the actionId which is a constant during the lifetime of a DENM message.

The actionId code itself will be re-used after a cancellation message. But not immediately. If a cancellation is missed, earlier named check is sufficient for determination if it is an updated message or not.

ActionFieldSet ValueRemarks
Create messagestationIdConstant1
actionIdConstant2
detectionTimeTime1Detection time
referenceTimeTime2Generation time (same as detection)
validityDurationSet to value0-86400 seconds
terminationNot present
Update messagestationIdConstant1
actionIdConstant2
detectionTimeTime3Update detection time
referenceTimeTime3Update generation time
validityDurationSet to value0-86400 seconds
terminationNot present
Cancel messagestationIdConstant1
actionIdConstant2
terminationisCancellation(0)

Time2 is mostly the same time as Time1, because of the insecure detectionTime for most events.

After update, the times are anyway equal, due to the standards given [ETSI TS 103 831 V2.1.1 (2022-11), B13 & B39].

Reference to specifications​

According ETSI EN 302 237-3 V1.3.1:

The parameter referenceTime is the identifier for DENM update referring to a specific actionID. The referenceTime represents the time at which a DENM is generated by the DEN basic service, after receiving the application request. For each DENM update, the referenceTime shall be updated and the value shall be greater than the referenceTime value of the previous DENM update for the same actionID. The actionID shall remain unchanged for DENM update, as long as the stationID of the originating ITS-S remains unchanged. The actionID shall remain unchanged when the validityDuration is updated, as long as the stationID of the originating ITS-S remains unchanged.

According ETSI TS 103 831 V2.1.1:

The parameter referenceTime is the identifier for DENM update referring to a specific actionId. The referenceTime represents the time at which a DENM is generated by the DEN basic service, after receiving the application request. For each DENM update, the referenceTime shall be updated and the value shall be greater than the referenceTime value of the previous DENM update for the same actionId. The actionId shall remain unchanged for DENM update, as long as the stationId of the originating ITS-S remains unchanged. The actionId shall remain unchanged when the validityDuration is updated, as long as the stationId of the originating ITS-S remains unchanged.

DetectionTime definition is:

detectionTime is the second component of ManagementContainer and represents the time at which the event is detected. For the DENM repetition, detectionTime shall remain unchanged. For the DENM update, this component shall be the time at which the event update is detected. For the DENM termination, this component shall be the time at which the termination of the event is detected.

ReferenceTime definition is:

referenceTime is the third component of ManagementContainer and represents the time at which a new DENM, an update DENM or a cancellation DENM is generated.

The standard validity value is defined as:

defaultValidity is the default value for DENM validity duration used for DENM protocol operation, as specified in clause 8.2.1.5. Clause 8.2.1.5: The timer T_O_Validity is the time that indicates the end of the DENM validity for the originating ITS-S protocol operation. Its expiration time shall be set to: - the offset of the validityDuration starting from the detectionTime, if the validityDuration is provided by the application; - the default offset of 600 s starting from the detectionTime, if the validityDuration is not provided by the application.

Tags:
Last updated on by Jasper De Keukelaere (imec)