What Is a Database?
For the NI-XNET interface to communicate with hardware products on the external network, NI-XNET must understand the communication in the actual embedded system, such as the vehicle. This embedded communication is described within a standardized file, such as CANdb (.dbc) for CAN, FIBEX (.xml) for FlexRay, or LIN Description File (.ldf) for LIN. Within NI-XNET, this file is referred to as a database. The database contains many object classes, each of which describes a distinct entity in the embedded system.
- Database: Each database is represented as a distinct instance in NI-XNET. Although the database typically is a file, you also can create the database at run time (in memory).
- Cluster: Each database contains one or more clusters, where the cluster represents a collection of hardware products connected over a shared cabling harness. In other words, each cluster represents a single CAN, FlexRay, or LIN network. For example, the database may describe a single vehicle, where the vehicle contains one CAN cluster Body, another CAN cluster Powertrain, one FlexRay cluster Chassis, and a LIN cluster PowerSeat.
- ECU: Each Electronic Control Unit (ECU) represents a single hardware product in the embedded system. The cluster contains one or more ECUs connected over a CAN, FlexRay, or LIN cable. It is possible for a single ECU to be contained in multiple clusters, in which case it behaves as a gateway between the clusters.
- Frame: Each frame represents a unique unit of data transfer over the cluster cable. The frame bits contain payload data and an identifier that specifies the data (signal) content. Only one ECU in the cluster transmits (sends) each frame, and one or more ECUs receive each frame.
- Signal: Each frame contains zero or more values, each of which is called a signal. Within the database, each signal specifies its name, position, length of the raw bits in the frame, and a scaling formula to convert raw bits to/from a physical unit. The physical unit uses a LabVIEW double-precision floating-point numeric type.
- Other object classes include the Subframe, LIN Schedule, and LIN Schedule Entry.
For more information about FIBEX database, please look at FIBEX and the NI-XNET Database Editor.
What Is an Alias?
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 XNET 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 available in the NI-XNET functions palette Database»File Mgt subpalette.
After you create an alias, it exists until you explicitly delete it. If you exit and relaunch LabVIEW, the aliases from the previous use remain. If you uninstall NI-XNET, the aliases are deleted; however, if you reinstall (upgrade) NI-XNET, the aliases from the previous installation remain. Deleting an alias does not delete the database file itself, but merely the association within NI-XNET.
An alias is required for deploying databases to LabVIEW Real-Time (RT) targets. When you deploy to a LabVIEW RT target, the large text file is compressed to an optimized binary format, and that binary file is transferred to the target. For more information about databases with LabVIEW RT, refer to Using LabVIEW Real-Time.
The NI-XNET software provides various methods for creating your application database configuration. The following figure shows a process for deciding the database source.
A description of each step in the process follows the flowchart.
Already Have File?
If you are testing an ECU used within a vehicle, the vehicle maker (or the maker’s supplier) already may have provided a database file. This file likely would be in CANdb, FIBEX, or LDF format. When you have this file, using NI-XNET is relatively straightforward.
Can Use File As Is?
Is the file up to date with respect to your ECU(s)? If you do not know the answer to this question, the best choice is to assume Yes and begin using NI-XNET with the file. If you encounter problems, you can use the techniques discussed in Edit and Select to update your application without significant redesign.
Select From File
There are three options for selecting the database objects to use for NI-XNET sessions: a LabVIEW project, I/O names, and property nodes.
The NI-XNET session in a LabVIEW project assumes that you have a database file. The configuration dialog includes controls to browse to your database file, select a cluster to use, and select a list of frames or signals. For example, if you create a Signal Input Single-Point session, you enter the database and cluster to use, then select one or more signals to read.
If you create sessions at run time, you need to wire objects from the database file to XNET Create Session.vi. The easiest way to do this is to use I/O names for the objects that you need. For example, assume that you want to create a Signal Input Single-Point session and want the VI end user to select signals from the front panel. First, drag XNET Create Session.vi from the NI-XNET functions palette. Change the VI selector to Signal Input Single-Point. Right-click the signal list input and select Create»Control. This creates an array of XNET Signal I/O names on your front panel. Right-click the signal list control and select Browse for Database File to find the database file.
For a CANdb file, you can click the drop-down list for each array element to select from available signals in the file. For a FIBEX or LDF file, right-click signal list and Select Database to select a specific cluster within the file, then click the drop-down list to select signals. After you browse to the file and select a cluster, that information is saved with the VI, so you need to select only signal names from that point onward. Most NI-XNET examples use I/O names to select objects (frames or signals). As a default, the NI-XNET example VIs use an example database file installed with NI-XNET. You can change this file to a different file using the previous steps.
If you create a session at run time, you may want to implement your own front panel controls to select objects from the database, rather than use I/O names. Although the programming is more advanced than I/O names, you can do this using property nodes for the database classes. These property nodes are found in the NI-XNET functions palette Database subpalette.
For example, assume you want a tree control on the VI front panel. The tree shows the frames and signals within a selected cluster. The VI user selects signals from this tree control. The tree control block diagram uses a programming model similar to the Advanced System Example Using Property Nodes. You can look at the Browse Database with Tree.vi example included with NI-XNET for more on this.
Edit and Select
There are two options for editing the database objects for the NI-XNET session: edit in memory and edit the file.
Edit in Memory
First, you select the frames or signals for the NI-XNET session using one of the options described in Select From File. Next, you wire the selected objects to the corresponding property node and set properties to change the value. When you edit the object using its property node, this changes the representation in memory, but does not save the change to the file. When you pass the object into XNET Create Session.vi, the changes in memory (not the original file) are used.
Edit the File The NI-XNET Database Editor is a tool for editing database files for use with NI-XNET. Using this tool, you open an existing file, edit the objects, and save those changes. You can save the changes to the existing file or a new file.
When you have a file with the changes you need, you select objects in your application as described in Select From File.
Want to Use a File?
If you do not have a usable database file, you can choose to create a file or avoid files
altogether for a self-contained application.
Create New File Using the Database Editor
You can use the NI-XNET Database Editor to create a new database file. Once you have a file, you select objects in your application as described in Select From File. As a general rule, for FlexRay applications, using a FIBEX file is recommended. FlexRay communication configuration requires a large number of complex properties, and storage in
a file makes this easier to manage. The NI-XNET Database Editor has features that facilitate this configuration.
Note The current version of NI-XNET supports import of LDF files for LIN, but does not yet support export (save) of a LIN database. Therefore, the NI-XNET Database Editor does not yet support LIN. To view the objects in a LIN LDF file, refer to the NI-XNET examples.
For more information about FIBEX database, please look at FIBEX and the NI-XNET Database Editor.
Create in Memory
You can use XNET Database Create Object.vi to create new database objects in memory. Using this technique, you can avoid files entirely and make your application self contained. You configure each object you create using the property node. Each class of database object contains required properties that you must set (refer to Required Properties). Because CAN is a more straightforward protocol, it is easier to create a self-contained application. For example, you can create a session to transmit a CAN frame with only two objects. For more information, please look at the Creating Database Dynamically.vi example that is included with NI-XNET.