Understanding the VTD RDB Documentation

RDB (Runtime Data Bus) documentation is one of the most important references when working with VTD integrations, ADAS validation, vehicle dynamics, sensors, HIL systems, or custom applications. The documentation explains every RDB package, structure, enum, bitmask, and protocol definition used by VTD. To know more about RDB refer: RDB in VTD

Opening the RDB Documentation

You can open the RDB documentation using either of the following methods:

Option 1: From VTD GUI

Open VTD GUI → Docs → Open Docu → RDB

Option 2: Directly from the installation directory

<VTD Installation Directory> → Doc → RDB_HTML → index.html

Understanding the RDB Documentation Layout

The RDB documentation is divided into four major sections:

1. RDB Change Log
2. Modules
3. Data Structures
4. Files

1. RDB Change Log

The Change Log contains the history of modifications made to the RDB across VTD releases.

2. Modules

The Modules section acts as the dictionary of RDB, containing all package IDs, enums, constants, and bitmasks that help you understand what a package represents and how to interpret the values stored inside its fields. The Modules section is further divided into four major categories.

A. General Definitions

Contains the fundamental RDB protocol constants and settings, such as communication ports, protocol version, message validation values, and other definitions that govern how RDB communication operates.

These values define the basic behavior of the RDB protocol. For example: RDB_DEFAULT_PORT = 48190 tells us that the default RDB communication port is: 48190

Similarly RDB_VERSION identifies the version of the RDB protocol.

When to use it?

Use this section when:

• Configuring TCP/UDP connections
• Verifying protocol versions
• Debugging communication issues

B. Array Sizes

Contains fixed-size buffer definitions. Examples:

RDB_SIZE_OBJECT_NAME = 32

RDB_SIZE_FILENAME = 1024

Many RDB structures use these constants.

Example: char name[RDB_SIZE_OBJECT_NAME]; which becomes: char name[32];

Example

Suppose an object name is: Ego

Internally VTD reserves 32 bytes for the field regardless of the actual string length.

Understanding these constants is important when writing custom parsers.

C. Enum Definitions

This is one of the most frequently used sections. It contains all RDB enumerations (enums), such as RDB_PKG_ID, RDB_OBJECT_TYPE, RDB_SENSOR_TYPE, and RDB_COORD_TYPE, which define the possible values a field can take and help translate numeric values into meaningful RDB concepts.

Enums represent a single valid value. Suppose an RDB package contains: pkgId = 9

Go to:

Modules

└── Enum Definitions

└── RDB_PKG_ID

You will find: RDB_PKG_ID_OBJECT_STATE = 9

Now we know package ID 9 represents Object State data. This is usually the starting point for understanding any package.

D. Bitmask Definitions

Bitmasks differ from enums because multiple values can exist simultaneously. This section contains RDB flag definitions where multiple states can be combined in a single field, helping decode status information such as vehicle lights, visibility flags, lane states, and wheel states using bitwise operations.

In RDB, a bitmask packs multiple independent status flags into a single integer field, allowing multiple simultaneous states to be set and evaluated together using bitwise operations.

Example

A vehicle is braking while turning left. Instead of sending separate variables, RDB packs both states into one integer field using bitwise OR (|):

Suppose we have Vehicle Light Field = 0x28

i.e. field: lightMask = (RDB_VEHICLE_LIGHT_INDICATOR_L | RDB_VEHICLE_LIGHT_REAR_BRAKE)

                 = 0x20 | 0x08

                 = 0x28  (Binary: 0010 1000)

From this, we can decode: Brake Light ON and Left Indicator ON at the same time. 

We can use it whenever a field contains multiple status flags packed into a single variable.

3. Data Structures

The Data Structures section contains the actual RDB package definitions (C structures) that describe how simulation data such as vehicle states, road information, sensor data, and driver controls are organized and transmitted within an RDB message. This section answers: "How is the data organized?" It is divided into two sections:

A. Data Structures

Clicking a structure shows Structure Name, Data Fields, Detailed Description, Field Documentation

Example: Reading RDB_OBJECT_STATE_BASE_t

You may see fields such as:

uint32_t id;

uint8_t category;

char name[32];

RDB_COORD_t pos;

RDB_GEOMETRY_t geo;

They describe:

For example:

ID = 1

Name = Ego

Position = (100,20)

Length = 4.8 m

Width = 1.9 m

This information is stored inside the Object State package.

B. Data Fields

Every structure page contains a Data Fields section. Data Fields is a reverse lookup section that helps you find which RDB structures contain a particular field name. Instead of asking "What fields are inside RDB_OBJECT_STATE_t?" it helps answer "Which structures contain the field playerId or pos?"

Example 1: If you search for: playerId

you'll see a list of structures such as: RDB_DRIVER_CTRL_t, RDB_ROAD_POS_t, RDB_WHEEL_BASE_t, RDB_ENGINE_BASE_t etc.

Example 2: Using the Data Fields Section to Find Vehicle Velocity

Suppose you want to find where vehicle velocity is stored in RDB.  In Data Structures → Data Fields, search for: velocity or click on ‘v’

You may find only: velocity : RDB_DYN_2_STEER_t

This indicates that velocity is used in a specific dynamics-to-steering interface package and is not the general vehicle speed field most users are looking for.

Additionally, clicking on RDB_DYN_2_STEER_t navigates to the structure in which this velocity is stored.

4. Files

The Files section contains the original source files used to generate the documentation.

The most important file is: viRDBIcd.h

Navigate to: Files → File List → viRDBIcd.h

The Data Structure pages provide a readable format, but the source file provides the exact implementation.

Example:

typedef struct

{

uint32_t id;

uint8_t category;

uint8_t type;

uint16_t visMask;

char name[32];

RDB_GEOMETRY_t geo;

RDB_COORD_t pos;

} RDB_OBJECT_STATE_BASE_t;

The source file shows:

• Exact field order
• Exact data types
• Reserved fields
• Array sizes
• Actual memory layout

This is especially useful when developing:

• Python parsers
• TCP/UDP clients
• Shared memory applications
• Custom RDB tools

Worked Example: How to Read an Unknown Package

Suppose your RDB Viewer or parser reports:

pkgId = 9

Step 1

Go to:

Modules

└── Enum Definitions

└── RDB_PKG_ID

Find: RDB_PKG_ID_OBJECT_STATE = 9

Now we know the package is: OBJECT_STATE

Step 2

Go to:

Data Structures

└── RDB_OBJECT_STATE_t

Step 3

Study the structure. You will find:

RDB_OBJECT_STATE_BASE_t

RDB_OBJECT_STATE_EXT_t

Step 4

Open the referenced field definitions.

For example: ‘category’ may refer to: RDB_OBJECT_CATEGORY

Open the corresponding enum to decode the value.

Step 5

If additional detail is needed, open ‘Files → viRDBIcd.h’ to view the exact implementation.

Key Takeaway

The easiest way to read RDB documentation is to start with the Package ID, identify the corresponding package from Modules → RDB_PKG_ID, open the associated structure under Data Structures, and then use the linked enums and bitmasks to decode individual field values. If you need exact implementation details, refer to Files → viRDBIcd.h, which serves as the source of truth for all RDB definitions. This workflow will help you efficiently understand and decode any RDB package available in VTD.