ISO 23150-1:2026

International
Standard
ISO 23150-1
First edition
Road vehicles — Logical interface
2026-06
between sensors and data fusion
unit for automated driving
functions —
Part 1:
General information and principles
Véhicules routiers — Interface logique entre capteurs et unité de
fusion de données pour les fonctions de conduite automatisée —
Partie 1: Informations générales et principes
Reference number
© ISO 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Architectural components .1
3.2 Terms for logical interface layers .2
3.3 Structure terms .3
3.4 Measurement terms .4
3.5 Requirement level terms .6
3.6 Road user relevant entity types .7
3.7 Axis and coordinate system terms .9
4 Abbreviated terms . 14
5 Structure of the interface description .15
5.1 General . 15
5.2 Signal and enumeration . 15
5.3 Interface .16
5.4 Specific signal grouping .17
5.5 Profile .18
6 Logical interface from a sensor as well as a sensor cluster to a fusion unit.18
6.1 General .18
6.2 Generic interface .21
6.3 Generic interface header . 22
6.4 Generic interface entity . 23
6.5 General level-independent profiles . 23
6.5.1 Profile: Uniqueness of interface versioning . 23
6.5.2 Profile: Colour model .24
6.5.3 Profile: Additional colours .24
6.5.4 Profile: Vehicle coordinate system . 25
6.5.5 Profile: Sensor pose . 25
6.5.6 Profile: Calibration . 25
6.5.7 Profile: Sensor cluster . 26
6.5.8 Profile: Observations . 26
6.5.9 Profile: Shape classification .27
6.5.10 Profiles Shape Type .27
6.5.11 Profiles Position . 30
6.5.12 Profiles Translation rate . .31
6.5.13 Profile: Road properties .32
6.5.14 Profile: Reference interface list .32
6.5.15 Profile: Recognition classification type .32
6.5.16 Profile: Segment . 33
6.5.17 Profile: Signal to noise ratio . 33
6.5.18 Profile: Measurement status . 33
7 Object level .34
7.1 General . 34
7.2 Generic object level interface . 34
7.3 Generic object level header . 34
7.4 Generic object level entity . 35
7.5 General object level profiles . 36
7.5.1 Profile: Road surface. 36
7.5.2 Profile: Traffic signs .37
7.5.3 Profile: Object pose . 38

iii
8 Feature level .39
8.1 General . 39
8.2 Generic sensor cluster feature interface . 40
8.3 Generic sensor cluster feature header . 40
8.4 Generic sensor cluster feature entity .41
8.5 General feature level profiles .41
9 Advanced detection level . 41
9.1 General .41
9.2 Generic sensor advanced detection interface .42
9.3 Generic sensor advanced detection header .42
9.4 Generic sensor advanced detection entity .43
9.5 Common advanced detection level profiles .43
10 Detection level .44
10.1 General . 44
10.2 Generic sensor detection interface . 44
10.3 Generic sensor detection header . 44
10.4 Generic sensor detection entity .45
10.5 General detection level profiles . . 46
10.5.1 Profile: Reflectivity . 46
10.5.2 Profile: Free-space probability . 46
10.5.3 Profile: Detection classifications . 46
10.5.4 Profile: Dynamics . 46
11 Supportive sensor interfaces . 47
11.1 General .47
11.2 Generic supportive sensor interface .47
11.3 Generic supportive sensor header .47
11.4 Generic supportive sensor entity . 48
11.5 General supportive sensor profiles . 48
12 Sensor input interfaces .48
12.1 General . 48
12.2 Generic sensor input interface. 48
12.3 Generic sensor input header . 48
12.4 Generic sensor input entity . 49
12.5 General sensor input profiles . 49
12.5.1 Profile: Uniqueness of interface versioning of SII . 49
Annex A (normative) Interface signals .50
Annex B (normative) Options and constraints .111
Bibliography .129

iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see http://www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
http://www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement. For an explanation of the voluntary nature of standards, the meaning of ISO
specific terms and expressions related to conformity assessment, as well as information about ISO's
adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
http://www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31, Data
communication.
[1] [2] [3]
This first edition of ISO 23150-1, together with ISO 23150-2 , ISO 23150-11 , ISO 23150-12 , ISO 23150-13
[4] [5] [6] [7]
, ISO 23150-14 , ISO 23150-15 and ISO 23150-20 , cancels and replaces ISO 23150:2023, which has
been technically revised.
The main changes are as follows:
— This document forms a structural revision of ISO 23150:2023 and replaces mainly Clauses 1 to 6 and
Annex B.
A list of all parts in the ISO 23150 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
Introduction
(Highly-)automated driving (AD) functions for road vehicles require a situation awareness of the
surroundings of the vehicle and, preferably, a comprehensive scene understanding. For the fast and reliable
recognition of real-world objects, a sensor suite is necessary to provide information for the fusion unit.
Utilisation of different sensor technologies with different detection capabilities is indispensable to ensure
both complementary and redundant information. The fusion unit analyses and evaluates the different sensor
signals and finally generates a dynamic surround model with sufficient scene understanding.
While current partly-automated functions utilise only particular objects (for example, vehicles, pedestrians,
road markings) to generate a simple surround model, it is necessary for future highly-automated driving
functions to merge not only the recognised objects but also to include other sensor-specific properties
and characteristics of these objects for the generation of a coherent surround model of the surroundings.
To minimise the development efforts for the sensors and the fusion unit and to maximise the re-usability
of development and validation efforts for the different functions on the sensor and fusion unit side, a
standardised logical interface layer between the sensor suite and the fusion unit and a standardised logical
interface layer to the sensor suite are worthwhile and beneficial for both the sensor supplier and the system
supplier.
Key
1 logical interface layer between the fusion unit and AD functions
2 logical interface layer between a single sensor as well as a single-sensor cluster and the fusion unit
3 interface layer on raw data level of a sensor’s sensing element(s) and its processing
Figure 1 — Architecture: sensors/sensor clusters → fusion unit → AD functions
The logical interface layer between a single sensor as well as a single-sensor cluster and the fusion unit (see
Figure 1, key 2) addresses the encapsulation of technical complexity as well as objects including free-space,
features, advanced detections and detections to enable object-level, feature-level, advanced detection-level
and detection-level fusion. Additional supportive information of the sensor as well as the sensor cluster will
supplement the data for the fusion unit.

vi
Key
1 logical interface layer between other in-vehicle electronic control units (ECUs) (for example, odometry) and
a single sensor or a single-sensor cluster
Figure 2 — Architecture: ECUs’ sensor input → sensors/sensor clusters
The logical interface layer between an electronic control unit and a single sensor as well as a single-sensor
cluster (see Figure 2, key 1) addresses the input of a single sensor as well as a single sensor-cluster.
Figure 3 shows the schematic and contextual relationships between the documents relating to logical
interfaces of the ISO 23150 series.
Key
Scope of this document
Figure 3 — Relationship of the ISO 23150 series

vii
International Standard ISO 23150-1:2026(en)
Road vehicles — Logical interface between sensors and data
fusion unit for automated driving functions —
Part 1:
General information and principles
1 Scope
This document is applicable to road vehicles with automated driving functions. This document concerns
the logical interface between vehicle environmental perception sensors and the fusion unit which generates
a surround model and interprets the scene around the vehicle based on the sensor data. The interface is
described in a modular and semantic representation and provides information on different abstraction
levels based on sensor technology specific information.
This document provides generic interface templates for different interface levels, supportive sensor
interfaces and sensor input interfaces.
This document does not provide electrical and mechanical interface specifications. Raw data interfaces are
also excluded.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1 Architectural components
3.1.1
fusion
act of uniting signals (3.3.1) from two or more sensors (3.1.5) as well as sensor clusters (3.1.6) to create a
surround model (3.1.7)
3.1.2
fusion unit
computing unit where the fusion (3.1.1) of sensor (3.1.5) data as well as a sensor cluster (3.1.6) data is
performed
3.1.3
interface
shared boundary between two functional units, defined by various characteristics pertaining to the
functions, physical interconnections, signal (3.3.1) exchanges and other characteristics of the units, as
appropriate
[8]
[SOURCE: ISO/IEC 2382:2015 , 2124351, modified — Notes to entry have been removed.]
3.1.4
logical interface
interface (3.1.3) between a sensor (3.1.5) as well as a sensor cluster (3.1.6) and the fusion unit (3.1.2), defined
by logical characteristics
Note 1 to entry: Logical means a semantic description of the interface.
Note 2 to entry: Mechanical and electrical interfaces are excluded.
Note 3 to entry: This document uses the term interface as a shortcut for the term logical interfaces.
3.1.5
sensor
in-vehicle unit which detects entities external of the vehicle with pre-processing capabilities serving at least
one logical interface (3.1.4)
Note 1 to entry: A sensor may use one or more sensing elements.
3.1.6
sensor cluster
group of sensors (3.1.5) of the same technology serving common logical interfaces (3.1.4)
Note 1 to entry: A sensor cluster can exceptionally consist of only one sensor.
EXAMPLE A stereo camera, a surround-view camera, an ultrasonic sensor array, a corner radar system.
3.1.7
surround model
representation of the real-world adjacent to the ego-vehicle
3.1.8
in-vehicle communication
communication network used in vehicles to connect devices to exchange information
Note 1 to entry: A in-vehicle communication connects, for example, electric control units and sensors (3.1.5) with each
other.
3.2 Terms for logical interface layers
3.2.1
detection
sensor technology specific entity represented in the sensor coordinate system (3.7.18) based on a single
measurement (3.4.5) of a sensor (3.1.5)
Note 1 to entry: A small amount of history can be used for some detection signals (3.3.1), for example, model-free
filtering may be used in track-before-detect algorithms.
3.2.2
detection level
set of logical interfaces (3.1.4) that provides detections (3.2.1)

3.2.3
advanced detection
sensor technology specific entity represented in the sensor coordinate system (3.7.18) based on multiple
measurements (3.4.5) of a sensor (3.1.5)
Note 1 to entry: Multiple measurements can originate from multiple measurement cycles (3.4.1).
3.2.4
advanced detection level
set of logical interfaces (3.1.4) that provides advanced detections (3.2.3)
3.2.5
feature
sensor technology specific entity represented in the vehicle coordinate system (3.7.16) based on multiple
measurements (3.4.5)
Note 1 to entry: Multiple measurements can originate from a sensor cluster (3.1.6).
Note 2 to entry: Multiple measurements can originate from multiple measurement cycles (3.4.1).
Note 3 to entry: The term feature is used in this document not as function or group of functions as specified in ISO/
[9]
SAE PAS 22736:2021 .
3.2.6
feature level
set of logical interfaces (3.1.4) that provides features (3.2.5)
3.2.7
object
representation of a real-world entity with defined boundaries and characteristics in the vehicle coordinate
system (3.7.16)
Note 1 to entry: The geometric description of the object is in the vehicle coordinate system.
Note 2 to entry: Object signals (3.3.1) are basically sensor technology independent. Sensor technology specific signals
may extend the object signals.
EXAMPLE A potentially moving object (3.6.1), a road object (3.6.2), a static object (3.6.6), a free-space object (3.6.13).
3.2.8
object level
set of logical interfaces (3.1.4) that provides objects (3.2.7)
3.2.9
recognition
representation of a recognized entity on object level (3.2.8), feature level (3.2.6), advanced detection level
(3.2.4) or detection level (3.2.2)
3.2.10
sensor input
data received by a sensor (3.1.5) or a sensor cluster (3.1.6) via the in-vehicle communication (3.1.8)
3.3 Structure terms
3.3.1
signal
entity consisting of one or more values and which is part of a logical interface (3.1.4)
3.3.2
logical signal group
grouping of signals (3.3.1) that has a logical relationship and a name for the grouping

3.3.3
classification
attribute-based differentiation
Note 1 to entry: An attribute is defined by a list of enumerators.
3.4 Measurement terms
3.4.1
measurement cycle
time period from the start of a data acquisition event to the start of the next data acquisition event
Note 1 to entry: A measurement cycle of one sensor (3.1.5) is a consistent view of an observed scene and not overlapping
in time.
3.4.2
measured quantity value
value of a quantity resulting from a measurement (3.4.5)
3.4.3
tracked quantity value
value of a quantity determined from observed sequential changes, using information related to the same
characteristic
3.4.4
predicted quantity value
value of a quantity assessed before it is actually observable, using information related to the same
characteristic
EXAMPLE Related information can be recent and previous measured quantity values (3.4.2), tracked quantity
values (3.4.3) and state variables.
[SOURCE: IEV 192-13-02, modified — EXAMPLE has been added and the word "quantity" has been added to
the term.]
3.4.5
measurement
processing result of a measurement cycle (3.4.1)
3.4.6
tracking
computation process used to calculate the tracked quantity value (3.4.3) of a quantity
3.4.7
prediction
computation process used to obtain the predicted quantity value (3.4.4) of a quantity
[SOURCE: IEV 192-11-01]
3.4.8
error
discrepancy between a measured quantity value (3.4.2), tracked quantity value (3.4.3) or predicted quantity
value (3.4.4) or condition, and the true, specified or theoretically correct reference quantity value or
condition
Note 1 to entry: An error within a system can be caused by failure of one or more of its components, or by the activation
of a systematic fault.
[SOURCE: IEV 192-03-02, modified — "computed, observed or measured value" was modified to "measured
quantity value, tracked quantity value or predicted quantity value", "value" was modified to "reference
quantity value", Note 1 to entry has been adapted and Note 2 to entry was deleted.]

3.4.9
accuracy
closeness of agreement between a measured quantity value (3.4.2), tracked quantity value (3.4.3) or predicted
quantity value (3.4.4) and a true quantity value
Note 1 to entry: The concept accuracy is not a quantity and is not given a numerical quantity value. A measurement
(3.4.5), tracking (3.4.6) or prediction (3.4.7) is said to be more accurate when it offers a smaller error (3.4.8).
Note 2 to entry: The term accuracy should not be used for trueness (3.4.10) and the term precision (3.4.11) should not
be used for accuracy, which, however, is related to both these concepts.
Note 3 to entry: Accuracy is sometimes understood as closeness of agreement between measured, tracked or predicted
quantity values that are being attributed to the measurand.
[10]
[SOURCE: ISO/IEC Guide 99:2007 , 2.13, modified — The terms "measurement accuracy" and "accuracy of
measurement" were deleted, definition was extended for tracked or predicted quantity values and the Notes
to entry have been adapted.]
3.4.10
trueness
closeness of agreement between the average of an infinite number of replicated measured quantity values
(3.4.2), tracked quantity value (3.4.3)s or predicted quantity values (3.4.4) and a reference quantity value
Note 1 to entry: Trueness is not a quantity and thus cannot be expressed numerically, but measures for closeness of
[11]
agreement are given in ISO 5725-1:2023 .
Note 2 to entry: Trueness is inversely related to systematic error but is not related to random error.
Note 3 to entry: The term accuracy (3.4.9) should not be used for trueness.
[10]
[SOURCE: ISO/IEC Guide 99:2007 , 2.14, modified — The terms "measurement trueness" and "trueness of
measurement" were deleted, definition was extended for tracked or predicted quantity values and the Notes
to entry have been adapted.]
3.4.11
precision
closeness of agreement between indications or measured quantity values (3.4.2), tracked quantity value (3.4.3)
s or predicted quantity value (3.4.4)s obtained by replicate measurements (3.4.5), tracking (3.4.6) or prediction
(3.4.7) on the same or similar measurands under specified conditions
Note 1 to entry: Precision is usually expressed numerically by measures, trackings or predictions of imprecision, such
as standard deviation, variance or coefficient of variation under the specified conditions of measurement, tracking or
prediction.
Note 2 to entry: The specified conditions can be, for example, repeatability conditions of measurement, intermediate
[11]
precision conditions of measurement or reproducibility conditions of measurement (see ISO 5725-1:2023 ).
Note 3 to entry: Precision is used to define measurement, tracking or prediction repeatability, intermediate
measurement or prediction precision and measurement, tracking or prediction reproducibility.
Note 4 to entry: Sometimes precision is erroneously used to mean accuracy (3.4.9).
Note 5 to entry: Precision is inversely related to random error but is not related to systematic error.
[10]
[SOURCE: ISO/IEC Guide 99:2007 , 2.15, modified — The term "measurement precision" was deleted, the
word "objects" was replaced by "measurands", definition was extended for tracked or predicted quantity
values, the Notes to entry have been adapted and Note 5 to entry has been added.]
3.4.12
measurement error
measured quantity value (3.4.2) minus a reference quantity value
Note 1 to entry: The concept of measurement error can be used both:

a) when there is a single reference quantity value to refer to, which occurs if a calibration is made by means of
a measurement standard with a measured quantity value having a negligible measurement uncertainty or if a
conventional quantity value is given, in which case the error (3.4.8) is known, and
b) if a measurand is supposed to be represented by a unique true quantity value or a set of true quantity values of
negligible range, in which case the error is not known.
Note 2 to entry: Measurement error should not be confused with production error or mistake.
[10]
[SOURCE: ISO/IEC Guide 99:2007 , 2.16, modified — The terms "error" and "error of measurement" were
deleted and the Notes to entry have been adapted.]
3.4.13
tracking error
quantitative statement about the tracked quantity value (3.4.3) and the reference quantity value
3.4.14
prediction error
quantitative statement about the predicted quantity value (3.4.4) and the reference quantity value
3.4.15
error model
model used to estimate the error (3.4.8)
3.4.16
fixation
short temporal holds of movements that keep alignment of the eyes to a particular point within an area of
interest which falls on the fovea (the middle of the retina responsible for our central, sharpest vision) for a
given time period
[12]
[SOURCE: ISO 15007:2020 , 3.1.4, modified — Notes to entry have been deleted.]
3.5 Requirement level terms
3.5.1
conditional
required under certain specified conditions
Note 1 to entry: One of three obligation statuses applied to a requirement level (3.5.4) of a logical interface (3.1.4)
specification, indicating the conditions under which the signal (3.3.1) or logical signal group (3.3.2) is required. In
other cases, the signal or logical signal group is optional. See also mandatory (3.5.2) and optional (3.5.3).
[13]
[SOURCE: ISO/IEC 11179-3:2023 , 3.2.77, modified — Note 1 to entry has been adapted and Note 2 to
entry has been removed.]
3.5.2
mandatory
always required
Note 1 to entry: One of three obligation statuses applied to a requirement level (3.5.4) of a logical interface (3.1.4)
specification, indicating the conditions under which the signal (3.3.1) or logical signal group (3.3.2) is required. See
also conditional (3.5.1) and optional (3.5.3).
[13]
[SOURCE: ISO/IEC 11179-3:2023 , 3.2.75, modified — Note 1 to entry has been adapted and Note 2 to
entry has been removed.]
3.5.3
optional
permitted but not required
Note 1 to entry: One of three obligation statuses applied to a requirement level (3.5.4) of a logical interface (3.1.4)
specification, indicating the conditions under which the signal (3.3.1) or logical signal group (3.3.2) is required. See
also conditional (3.5.1) and mandatory (3.5.2).

[13]
[SOURCE: ISO/IEC 11179-3:2023 , 3.2.76, modified — Note 1 to entry has been adapted and Note 2 to
entry has been removed.]
3.5.4
requirement level
definition of the obligation status of a logical signal group (3.3.2) a signal (3.3.1) as well as the signal's
identifiers or a signal's enumerators
Note 1 to entry: Each requirement level entry has one of three possible obligation statuses applied: conditional (3.5.1),
mandatory (3.5.2) or optional (3.5.3).
Note 2 to entry: The requirement level of a logical signal group or a signal as well as the signal's identifiers are defined
in the logical interfaces (3.1.4).
Note 3 to entry: No default requirement level is defined for signal enumerators of an exemplary enumerator list.
The requirement level is specified during the system design phase. Enumerators of mandatory enumerator lists are
mandatory.
3.5.5
system design
process of defining the hardware and software architecture, components, modules, interfaces and data for a
system to satisfy specified requirements
[8]
[SOURCE: ISO/IEC 2382:2015 , modified — Note to entries have been removed.]
3.6 Road user relevant entity types
3.6.1
potentially moving object
real-world entity which can potentially move and is relevant for driving situations
Note 1 to entry: A representation of a potentially moving object is part of logical interfaces (3.1.4) on object level (3.2.8).
EXAMPLE A vehicle, a bicycle, a pedestrian, an obstacle.
3.6.2
road object
marking or structure of a road which is relevant for driving situations
Note 1 to entry: A representation of a road object is part of logical interface (3.1.4)s on object level (3.2.8).
EXAMPLE A road marking (3.6.3), a road boundary (3.6.4), the road surface (3.6.5).
3.6.3
road marking
line, symbol or other mark on the surface of a road or a structure intended to limit, regulate, warn, guide or
inform road users
Note 1 to entry: Other marks could be text, numbers, arrows or combinations.
EXAMPLE A lane marking, Botts' dots.
[14]
[SOURCE: ISO 6707-1:2020 , 3.3.5.80, modified — "user" was modified to "road users", "limit" was added
and the Note 1 to entry and EXAMPLE have been added.]
3.6.4
road boundary
structure that limits the road
EXAMPLE A curb stone, a guard rail, the end of the surface of the road.

3.6.5
road surface
surface supporting the tyre and providing friction necessary to generate shear forces in the road plane
(3.7.6)
Note 1 to entry: The surface may be flat, curved, undulated or of other shape.
[15]
[SOURCE: ISO 8855:2011 , 2.6]
3.6.6
static object
real-world stationary entity which can be used for information and/or localisation
Note 1 to entry: A representation of a static object is part of logical interfaces (3.1.4) on object level (3.2.8).
EXAMPLE A general landmark (3.6.7), a traffic sign (3.6.8), a traffic sign board (3.6.11), a traffic light (3.6.12).
3.6.7
general landmark
real-world stationary entity which can be used for localisation
Note 1 to entry: A stationary traffic sign (3.6.8) or traffic light (3.6.12) is also regarded as a general landmark.
EXAMPLE A building, a tunnel, a bridge, a sign gantry structure, a tree.
3.6.8
traffic sign
traffic relevant, authorised sign that limits, regulates, warns, guides or informs road users
Note 1 to entry: One traffic sign usually consists of one main sign (3.6.9) and none, one or several supplementary signs
(3.6.10).
EXAMPLE A speed limit which is restricted for trucks.
3.6.9
main sign
traffic sign (3.6.8) which gives a general message, obtained by a combination of colour and geometric shape
and which, by the addition of a graphical symbol or text, gives a particular message for road users
[16]
[SOURCE: ISO 3864-1:2011 , 3.12, modified — The original term was "safety sign", "sign" has been
replaced by "traffic sign" and the phrases "or text" and "for road users" have been added to the definition.]
3.6.10
supplementary sign
traffic sign (3.6.8) that is supportive of a main sign (3.6.9) and the main purpose of which is to provide
additional clarification
[16]
[SOURCE: ISO 3864-1:2011 , 3.14, modified — "traffic sign" now replaces "sign" and "main sign" replaces
"traffic sign".]
3.6.11
traffic sign board
traffic relevant, authorised sign board that limits, regulates, warns, guides or informs road users by abstract
representations of lanes and streets ahead to control traffic on the road
3.6.12
traffic light
traffic relevant, official lights
Note 1 to entry: One traffic light consists of one or several light spots with different light colours
...