GB/T 47126-2026Road vehicles - Data communication between sensors and data fusion unit for automated driving functions - Logical interface (English PDF)

3.1 Architecture

3.1.1

Fusion

The behavior of merging signals (3.3.1) from two or more sensors (3.1.5) and sensor clusters (3.1.6) to create a surrounding model (3.1.7).

Figure 8 -- Affine coordinate system

5.1 General rules

This document covers the logical interfaces of sensors and sensor clusters. Therefore, the term "interface" is used in the following sections of this document as an abbreviation of the defined term "logical interface" (3.1.4). The interface description is structured as follows.

- Each interface is described by Logical Signal Groups (LSGs), signal names, Requirement Levels (RLs) (including conditional requirements) and other options;

- Detailed descriptions of each signal in Appendix A;

- General options and general conditional requirements to be used in Appendix B.

The Requirement Level attribute "Conditional" shall be the element used in this document. Logical interconnections between interface signals and complex dependencies shall be defined in the configuration file of the corresponding interface.

5.2 Signals

Table 1 provides descriptions of the signals used by the interfaces defined in 5.3.All

signals are specified in Appendix A. Signal names shall be unique. Similar signals at different interface levels shall have the interface level added to the signal name to ensure unique signal naming.

Table 1 -- Signals. < Signal name>

Generally, for each signal with a value type of "enumeration", a list of enumeration values or enumeration examples is defined in an additional table in Appendix A (see

Table 2). Each list of enumeration examples is for reference only. During the system

design phase, specific enumeration values shall be defined according to the list of enumeration examples in Appendix A. This can be accomplished, by adding new ones, using a subset of existing enumeration examples, or adjusting existing enumeration example values. An implementation of the enumeration example value list shall contain at least one enumeration value and preferably has a default enumeration value (B.1.8).

Enumerations with enumeration example values can allow outputs of multiple enumeration values belonging to different classes. During system design, enumeration values of different classes can be specified using separate enumeration signal identifiers.

Each enumeration with enumeration examples shall have a default enumeration value (B.1.8). Each implementation's enumeration example list shall define at least one enumeration value. Multiple enumeration example values can be clustered, to handle different types of enumeration values, rather than providing multiple enumeration value categories.

Table 2 -- Enumerations. < Signal name>

5.3 Interface

Table 3 provides a description of the logical interface. The interface consists of signals.

For ease of logical grouping, signals can be part of a Logic Signal Group (LSG).

Table 3 -- Interface. < Interface name>

The grayed-out areas in the interface table indicate that the signals contained therein are part of the entity list. The number of valid entities is defined at the beginning of the gray area (i.e., the gray area header).

If an interface provides multiple interface entity types (e.g., a road object interface provides road surface, road markings, road boundaries), the interface may not require all entity types to be provided simultaneously (see B.2.4). Different entry types of the interface are separated by double horizontal lines.

A conditional LSG shall define its usage conditions. Under all other conditions, the LSG is optional (see 3.5.1).

An LSG shall have at least one mandatory signal. If a signal in an optional LSG is used, all signals in that LSG shall conform to its signal requirement level definition.

For a list, the "number of valid < ...> signals" and the requirement level of its LSG are the basic requirement levels for all signals in the list.

The symbol " " indicates that the LSG belongs to another LSG, making it a nested LSG.

If only one signal requirement level is defined for a signal with a signal identifier, then the requirement level for each signal identifier corresponds individually to the requirement level of the signal.

The delivery method for signals with mandatory and static or fixed requirement levels can be optimized; these signals are defined during the system design phase and/or otherwise delivered to sensors and fusion units. In this case, the optimization methods of B.1 apply; for example, interface messages do not explicitly transmit the corresponding mandatory signals. During the system design phase, the additional measures in Appendix B are applicable and applied to define sensors and sensor clusters.

5.4 Specific signal groups

Table 4 provides descriptions of specific signal groups, such as an LSG that references

and extends a specific signal group to implement a similar interface.

Table 4 -- Specific signal groups. < LSG name>

The symbol " " indicates that the signal belongs to a list of signals.

Unchanged inherited signals, signal requirement levels, remarks within the referenced signal group are marked in gray.

5.5 Configuration files

If multiple signals of an interface have semantic dependencies specific to that interface, these dependencies are described in the configuration file, meanwhile additional complex constraints are defined. Each signal in the configuration file has a comment in the remarks section (see the remarks columns in Tables 3 and 4).

6 Logical interface between sensors and sensor clusters and the fusion unit

6.1 General principles

The goal of this document is to support different levels of fusion. Therefore, this document provides three logical interface levels (detection, feature, object levels), with supporting sensor interfaces as a corresponding supplement. Detection information, feature information, object information, supporting sensor information form the basis of fusion. Tracking algorithms that rely solely on information from a single sensor or sensor cluster provide limited object quality. The fusion unit can improve the quality of object recognition or tracking by combining information from different levels, through object-level fusion and feature and/or detection-level fusion. To perform object-level fusion in sensor suite 1), each sensor and sensor cluster shall provide relevant detection feature data for a specific real-world entity object. One advantage of feature-level

1 It consists of two or more different and independent sensors or sensor clusters.

- Free space area object interface (7.6). Free space area.

- Sensor or sensor cluster features (related to specific sensor technologies).

- Camera feature interface (8.3);

- Ultrasonic radar feature interface (8.4).

- Sensor or sensor cluster detection (related to specific sensor technologies).

- Millimeter-wave radar detection interface (9.3);

- LiDAR detection interface (9.4);

- Camera detection interface (9.5);

- Ultrasonic radar detection interface (9.6).

- Sensor support information.

- Sensor performance interface (10.3). Has specific sensor attributes, such as current field of view, object recognition rate, reference object recognition rate;

- Sensor health information interface (10.4). Has specific attributes, such as general sensor state, calibration information, sensor cluster definition.

- Sensor or sensor cluster specific inputs.

- General sensor input interface (11.3).

Sensors or sensor clusters can provide multiple logical interfaces simultaneously, or they can provide no interfaces at the object level, or provide one or more interfaces.

Furthermore, sensors or sensor clusters can provide both feature and detection level interfaces. Each sensor or sensor cluster shall provide at least one interface at the object, feature, or detection level; it may optionally provide sensor support interfaces. Sensors or sensor clusters can provide interfaces at all levels. Sensors primarily provide detection level interfaces, while sensor clusters primarily provide feature and/or object interfaces. Sensor clusters consist of sensors; it should avoid sensor clusters that do not contain defined sensors. If a sensor cluster does not provide detection level interfaces, it can be considered a single sensor with multiple sensing elements. Sensor clusters provide consistent data across all their interfaces. The fusion unit does not need to use every interface provided by the sensors or sensor clusters. The interfaces provided by sensors or sensor clusters can be used by other applications (e.g., automated driving functions), not just the fusion unit.

In Figure 10, sensor 1, sensor 2, sensor 3, sensor 4, sensor subclusters {1, 2} and {3, 4} belong to sensor cluster {1, 2, 3, 4}. Information from all sensors and sensor clusters belongs to the same set of information and can be referenced between interfaces. In this

6.4 Configuration file. Uniqueness of interface version

The combination of "Interface version ID {major, minor, patch}" (A.1.2), "Interface ID" (A.1.3), "Number of valid service sensors" (A.1.4), "Sensor ID" (A.1.5) is a unique identifier interpreting the interface message implementation. The order of the "Sensor ID" (A.1.5) signal values is also relevant. If a sensor can use an interface multiple times, this configuration file is adjusted in the corresponding interface, to differentiate each interface implementation.

The sensor input interface defines a configuration file for interface version control uniqueness (11.2.4).

7.1 General principles

Object-level interfaces (OLIs) originate from multiple sensors. Therefore, at the object level, even if only one sensor serves the interface, the term "sensor cluster" is always used. The OLI provides identified real-world entities, meanwhile identification is based on historical data. Identified objects are tracked and filtered over time. Model-based algorithms classify these objects and evaluate them with Existence probability values.

The sensor cluster points its identified objects to one of two predefined vehicle coordinate systems [see signal "Vehicle coordinate system type" (A.1.21)]. The attributes of the identified objects and the resulting signals, are generally independent of the specific sensing technology of the sensor cluster. Additional attributes of the identified objects can depend on the sensor technology, supplementing the interface object description. These sensor technology-dependent signals are grouped by sensor technology in the LSG.

To link identified objects to the sensor cluster or its non-OLI interface entities, each identified object has a unique signal "Object ID" (A.2.3) value, that does not change over time and is referenced by the entity. The "Object ID" (A.2.3) value of signal can only be reused, after an object has not been identified for a specified period and the sensor cluster has therefore determined that the object is no longer visible. Specifically, if a previously identified object is invisible to the sensor cluster for an extended period, there is no guarantee that the same "Object ID" (A.2.3) value will be used when it is re-identified.

To link objects identified by the sensor cluster's OLI, the relevant object set uses the same unique signal "Object group ID" (A.2.4) value, to link all relevant objects. A specific value can indicate that the object is not linked to any other object.

The object identification algorithm is based on multiple measurements from the sensor cluster and is updated over time. Therefore, the attributes of the entire object are not assigned to the time of a single measurement, but rather to the interface object's attributes in conjunction with a consistent estimated time point. The probability of an object's presence is related to the consistent predicted signal set (tracked quantity value or predicted quantity value) of the object at the estimated time point.

The following interfaces are provided at the object level.

- Potential moving object interface (7.3);

- Road object interface (7.4);

- Static object interface (7.5);

- Free space area object interface (7.6).

7.2 General object-level interface

7.2.1 Overview

Table 6 defines the general structure of the OLI.

Table 6 -- General object-level interface

The single object-level entity list for each OLI can also be a set of different specific object type lists (e.g., for the "Road Object Interface" (7.4), there are two entity lists for the object type. road markings and road boundaries, and a single object entity. road surface).

7.2.2 General object-level headers

Table 7 defines the interface headers in the "General Object-Level Headers" (7.2.2),

which have been adapted compared to the general interface headers in 6.2.