14.1 Introduction to signals

Signals are traffic signs, traffic lights, and specific road marking for the control and regulation of road traffic. Items that do not influence the behavior of traffic models directly are modeled as objects. For more on objects, see Section 13.1, "Introduction to objects".

Figure 128. Signals in ASAM OpenDRIVE

Figure 128 shows exemplary signal definitions for ASAM OpenDRIVE.

Signals have different functions and properties:

They are used to control traffic behavior, for example, with speed limits and turn restrictions, and to alert road traffic about dangerous situations.
They can be static or dynamic. Static signals, such as stop signs, do not change their meaning. Dynamic signals, like traffic lights or variable message boards, may change their meaning during the simulation. Their dynamic content may be defined in ASAM OpenSCENARIO.
They can be valid or invalid. An invalid sign is a sign that has been physically invalidated, such as a crossed-out speed limit in a roadworks zone. A signal is valid unless explicitly stated otherwise.
They can be permanent or temporary. Examples for temporary signals are speed limit signs or traffic lights for road works. See also Figure 60 in Section 11.2, "Lane layers".

Signals shall be placed in relation to a specific road. The position of the signal is described relative to the road reference line, using the s- and t- coordinates. Signals shall be positioned in such a way that it is clear to which road or lane they belong and where their validity starts. Ambiguity about their interpretation shall be avoided.

Traffic rules are different for each country. The country of the signal is specified in the @country attribute. When placing signals in ASAM OpenDRIVE, country-specific legislation and traffic rules should be considered. Legislative changes are indicated by the year when the rules come into force. Traffic rules for the entire ASAM OpenDRIVE file can be defined in the <defaultRegulations> element in the <header> element.

The @height and @width attributes of a signal are not required but are recommended for proper representation of the signal. The @length attribute can be used to specify a thickness of the signal.

In addition to the road markings defined in this section, ASAM OpenDRIVE also supports the following use cases:

For the outer marking lines of a lane, use lane road markings. See Section 11.9, "Lane road markings".
For road markings that are not mandatory for driver and traffic models, use objects. See Section 13.2, "Object outline" and Section 13.8, "Object markings".

A signal with the @type and @subtype attributes is only unique in combination with the @country and @countryRevision attributes. Since some elements that are considered signals in ASAM OpenDRIVE, for example traffic lights, do not have any official @type and @subtype representation, these are specified in the Signal reference 1.0.0 . They can be used with the appropriate @type, @subtype and the @country="OpenDRIVE".

Figure 129. Width and height for signal

Figure 129 shows the attributes ASAM OpenDRIVE provides for a speed regulation signal. It is pointed out how height and width are measured.

A signal with an @orientation of + applies to traffic traveling in the positive road reference line direction. This means the signal with an @hOffset of 0 faces to the drivers traveling in a positive road reference line direction. Any @hOffset given to this signal is applied counter-clockwise from the negative road reference line direction.

A signal with an @orientation of - applies to traffic traveling in the negative road reference line direction. This means the signal with an @hOffset of 0 faces to the drivers traveling in the negative road reference line direction. Any @hOffset given to this signal is applied counter-clockwise from the positive road reference line direction.

Figure 130. Orientation and hOffset for signal

Figure 130 shows a signal which applies to traffic traveling in the positive road reference line direction and which is turned counter-clockwise from the negative road reference line direction. For the <signal> element, the @orientation attribute and @hOffset attribute are defined. To the @orientation attribute the + value is assigned and to the @hOffset attribute a value of 5.7595865 is assigned.

Elements in UML model

<signals> element

In ASAM OpenDRIVE, signals are represented by the <signals> element within the <road> element.

UML class: t_road_signals
XML tag:   <signals> (Multiplicity: 0..1)

Signals are traffic signs, traffic lights, and specific road markings that guide driver and traffic models.

The <signals> element is the container for all signals along a road.

Figure 131. UML class diagram of the Signals class

Figure 131 shows the UML class diagram of the ASAM OpenDRIVE Signals class.

<signal> element

In ASAM OpenDRIVE, a signal is represented by the <signal> element within the <signals> element.

UML class: t_road_signals_signal_road
XML tag:   <signal> (Multiplicity: 0..*)

Used to provide information about signals along a road. Consists of a main element and an optional lane validity element. The element for a signal is <signal>.

Table 122. Attributes of the <signal> element
Name	Type	Use	Unit	Introduced	Description
`countryRevision`	string	optional			Defines the year of the applied traffic rules
`country`	e_countryCode	optional			Country code of the road, see ISO 3166-1, alpha-2 codes.
`dynamic`	t_yesNo	required			Indicates whether the signal is dynamic or static. Example: traffic light is dynamic
`hOffset`	double	optional	rad		Heading offset of the signal (relative to @orientation, if orientation is equal to “+” or “-“) Heading offset of the signal (relative to road reference line, if orientation is equal to “none” )
`height`	t_grEqZero	optional	m		Height of the signal, measured from bottom edge of the signal.
`id`	string	required			Unique ID of the signal within the OpenDRIVE file
`invalidated`	boolean	optional		1.9.0	Indicates whether the signal is currently invalidated. Example: crossed out traffic sign.
`length`	t_grEqZero	optional	m	1.8.0	Length of the signal’s bounding box. @length is defined in the local coordinate system u/v along the u-axis
`name`	string	optional			Name of the signal. May be chosen freely.
`orientation`	e_orientation	required			"+" = valid in positive s- direction "-" = valid in negative s- direction "none" = valid in both directions
`pitch`	double	optional	rad		Pitch angle of the signal, relative to the inertial system (xy-plane)
`roll`	double	optional	rad		Roll angle of the signal after applying pitch, relative to the inertial system (x’’y’’-plane)
`s`	t_grEqZero	required	m		s-coordinate
`subtype`	string	required			Subtype identifier according to country code or "-1" / "none"
`t`	double	required	m		t-coordinate
`temporary`	boolean	optional		1.9.0	Indicates whether the signal is temporary or permanent. Example: temporary speed limit sign in road works situation.
`text`	string	optional			Additional text associated with the signal, for example, text on city limit "City\nBadAibling"
`type`	string	required			Type identifier according to country code or "-1" / "none". See extra document.
`unit`	e_unit	optional			Unit of @value
`value`	double	optional			Value of the signal, if value is given, unit is mandatory
`width`	t_grEqZero	optional	m		Width of the signal’s bounding box. @width is defined in the local coordinate system u/v along the v-axis
`zOffset`	double	required	m		z-offset of signal’s origin relative to the elevation of the road reference line

XML example

<signals>
    <signal s="3981.4158159146"
            t="-14.0503"
            id="5000162"
            name="Vorschriftzeichen"
            dynamic="no"
            orientation="+"
            zOffset="3.8835"
            country="DE"
            countryRevision="2017"
            type="274"
            subtype="100"
            value="100"
            unit="km/h"
            height="0.77"
            width="0.77"
            hOffset="5.7595865">
    </signal>
</signals>

Rules

The following rules apply to signals:

asam.net:xodr:1.7.0:road.signal.signal_type: Signals shall have a specific type and subtype.

asam.net:xodr:1.7.0:road.signal.priority: If present, signals shall be used in priority to other traffic rules.

asam.net:xodr:1.7.0:road.signal.use_country_code: A country code shall be added to refer to country-specific rules using the @country attribute.

The year the traffic rules come into force may be specified in the @countryRevision attribute.
Signals may be valid for one direction or both directions.
Signals may be dynamic or static.
Signals without @invalidated shall default to @invalidated=false.
A signal’s placement may either be temporary or permanent, as indicated by @temporary.
Omitting @temporary shall default to @temporary="false".
Traffic actors should ignore objects with @invalidated="true".
Omitting @invalidated shall default to @temporary="false".

Related topics