FIBEX and the NI-XNET Database Editor Overview


This document covers the basics of FIBEX and the NI-XNET Database Editor for CAN and FlexRay networks.


Why Databases?

Databases are the tool of choice to manage embedded networks. Although it is possible (and supported) in principle to run a network without a database, using a database is highly recommended to have a consistent set of network parameters for all nodes in the network. This is especially true for FlexRay, where you need to set up about 30 parameters consistently to get a running network.

Additionally, a database can manage the contents of the data exchanged over the network. You can store frames and signals running on the network in a database as well as information about which ECU is transmitting or receiving which data. This information also is needed for each node in the network.


The FIeld Bus EXchange (FIBEX) format, an XML-based standardized file format defined by the ASAM consortium, is used for describing automotive networks. The FIBEX database format is compatible with many different automotive protocols, making it a flexible standard. FIBEX is emerging as the de facto standard for the definition of FlexRay networks and is seeing rapid adoption for CAN networks. FIBEX databases are typically generated by vehicle network designers and shared with engineers working on a particular aspect of the vehicle. With a FIBEX file and an NI-XNET interface, you can easily interact with a vehicle network without having to manually configure interfaces and signal definitions. 

FIBEX contains many aspects for a particular network, including the following: 

  • Transmit and receive schedules
  • Frame definitions
  • Signal definitions
  • Bit-level encoding of signals
  • Network topology
  • ECU information
  • Network configurations, including baud rates and timings

NI-XNET Database Editor

For NI-XNET, NI adopted the ASAM FIBEX standard as a database storage format. The NI-XNET Database Editor is a small stand-alone tool for creating and maintaining embedded network databases. In addition to FIBEX, this database editor can import the NI-CAN database format (.ncd) and CANdb format (.dbc), both of which NI-CAN supports. You also can convert these formats to FIBEX.

In addition, you can use the editor to complete the following:

  • Configure the basic network
  • Define frames and signals exchanged on the network
  • Assign frames to ECUs that send and receive them

The database editor is installed with NI-XNET and is located in Start»All Programs»National Instruments»NI-XNET»Database Editor.


The basic entity of a database is a cluster. A cluster is the description of a single network (for example, a CAN or FlexRay bus).

For CAN, the cluster contains only the baud rate. For FlexRay, there are about 30 global network parameters to set for a cluster. The NI-XNET Database Editor includes an Easy view, where you can set the six most important parameters; the other parameters are then chosen automatically to obtain a functioning network. If you start with FlexRay, this is probably the best method for you. However, if you have a database, you can use the Expert view to set individual parameters.

Usually, a database contains only one cluster. For example, the NI-CAN database and CANdb formats support only one cluster. However, FIBEX supports multiple clusters per database; for example, you can describe all of a car's networks in a single database.



Each cluster can contain an arbitrary number of frames. A frame is a single message that is exchanged on the cluster. In NI-CAN, this is equivalent to an NI-CAN message.

The basic properties of a frame are its identifier (Arbitration ID for CAN, Slot ID for FlexRay) and the payload length, which can be any value between 0 and 8 for CAN and any even value between 0 and 254 for FlexRay.

In addition, you can take advantage of several protocol-specific properties and use the NI-XNET Database Editor to edit these properties in a protocol type-specific way.


Each frame contains an arbitrary number of signals, which are the basic data exchange units on the network. These signals are equivalent to NI-CAN channels.

Some of the signal properties include the following:

  • Start bit: the signal start position within the frame
  • Number of bits: the signal length within the frame
  • Data type: the data type (signed, unsigned, or float)
  • Byte order: little or big endian
  • Scaling factor and offset: for converting physical data to binary representation

Using Aliases and LabVIEW Real-Time

When using a database file with NI-XNET, you can specify the file path or an alias to the file. The alias provides a shorter, easier-to-read name for use within your application.

For example, for the file path

C:\Documents and Settings\All Users\Documents\Vehicle5\MyDatabase.dbc

you can add an alias named MyDatabase. In addition to improving readability, the alias concept isolates your LabVIEW application from the specific file path. For example, if your application uses the alias MyDatabase and you change its file path to


your LabVIEW application continues to run without change.

The alias concept is used in most NI-XNET features for the database classes. The I/O names for database classes include features for adding a new alias, viewing existing aliases, deleting an alias, and so on. You also can perform these tasks at run time using the VIs in the NI-XNET functions palette Database»File Mgt subpalette.

An alias is required for deploying databases to LabVIEW Real-Time targets. When you deploy to a LabVIEW Real-Time target, the large text file is compressed to an optimized binary format, and you need to transfer that binary file to the target. You can use the database editor to transfer this file to the target or perform this programmatically. For more information about using databases with LabVIEW Real-Time, refer to Using LabVIEW Real-Time in the NI-XNET Manual.

Was this information helpful?