During the past few decades, the automotive industry has benefited from significant technical advances that have resulted in reduced emissions, better fuel efficiency, antilock control for braking systems, and many other improvements. Innovations in environmental, safety, and driver convenience features have resulted in the addition of many new electronic devices to automobile designs.
Bosch developed the Controller Area Network (CAN) bus during the mid-1980s to accommodate the growing requirements for communication between automotive electronic modules. Today, CAN is also used in avionics data communication embedded systems, marine applications, and other applications.
CAN is a 2-wire, multidrop serial bus over which devices connected to the network communicate with each other. Additional information about the CAN bus and National Instruments CAN interface products is available at http://ni.com/can.
As testing applications for CAN devices have evolved, the need to integrate test system elements such as voltage and sensor measurements, actuator control, and discrete I/O has become increasingly evident. The ability to synchronize CAN transmissions with these other elements is an important characteristic of a system that can achieve repeatable measurement results.
2. Need for Hardware Synchronization
You can design a program that uses a loop to “software synchronize” a variety of hardware products because both CAN and DAQ hardware contain a timestamp of when a particular event took place. However, without hardware synchronization, there is no guarantee the accuracy of the the time stamps themselves because of clock drift and start/stop latency.
Clock oscillators are built with inherent frequency instability, or jitter, usually specified in parts per million (ppm). Over time, any two unsynchronized clocks drift relative to each other. In the worst case, two oscillators specified at 20 MHz ±100 ppm can drift 1 ms relative to each other in less than 2 minutes. As the length of time increases, the worst-case clock drift also increases.
For many validation applications, this amount of clock drift is unacceptable, especially if device testing occurs over long periods of time. If the two clocks on a DAQ and CAN board have drifted, then you cannot ensure that the samples obtained from each are correlated. For this reason, RTSI bus synchronization provides a resynchronization pulse from the DAQ device that resynchronizes the two clocks every 100 milliseconds. Using this method, the time bases of the two boards never differ more than a few microseconds (10 microseconds max. with the values mentioned above), minimizing the problem of clock drift in a measurement system.
Using software synchronization, the control of functions starting and/or stopping is dependent on software latency. Since function calls must be serialized in a program, there will be some latency between the start of the DAQ acquisition and the start of the CAN acquisition. This latency results in an unpredictable amount of error between what DAQ considers sample 0 and what CAN considers sample 0. The result is that DAQ and CAN data are not correlated in time, and thus cannot be accurately displayed together without additional data manipulation.
3. Real-Time System Integration (RTSI)
The PXI chassis incorporates the PXI Trigger bus, with seven trigger lines for building flexible synchronization relationships between National Instruments measurement, image acquisition, and motion control devices, as well as CAN interface modules. One or more modules in the system can source timing signals onto the backplane, where they are available to each module in the system for I/O synchronization. Because the timing is implemented in hardware, the application software does not need to intervene in I/O synchronization once the system has been initialized. In PCI-based systems, the same synchronization features are available with the RTSI bus, which uses a ribbon cable to connect between PCI boards via top-mounted connectors.
4. Example Application
To illustrate CAN and DAQ synchronization, let's consider a test for an electric power-assist steering controller. Conventional hydraulic power steering systems use an engine accessory belt to drive the rotary vane pump. The pump provides pressurized fluid that operates a piston in the power steering gear or actuator to assist the driver in turning the wheels. This system continually places a small load on the engine, even when the steering system is not in use. Improvements on this technology have resulted in electric power-assist steering (EPAS).
Figure 1. Diagram of an Electric Power-Assist Steering System
EPAS (Figure 1) uses an electric motor attached to the steering column or rack through a gear mechanism. This process eliminates the pump, hoses, fluid, drive belt, and pulleys of the traditional hydraulic power steering system. Driving the motor applies steering force that adds to the driver’s input. The ECU collects data such as steering wheel torque, vehicle speed, and motor position and applies a control algorithm to manage the level of steering assist that the motor applies. The electric power assist steering system is lighter than traditional hydraulic units, independent of engine speed, and the system draws power only when providing steering assistance, resulting in improved fuel efficiency.
5. System Timing Configuration
The example discussed in this document demonstrates synchronized input of waveform plots from two CAN channels and two analog input (AI) channels. Both CAN and AI channels are sampled into a waveform at the specified sample rate.
In this EPAS test system, the ECU acquires signals such as torque, PWM voltages, and vehicle speed, puts them into a control algorithm, and adjusts the output of the CAN Messages controlling the motor (Figure 2). To validate the EPAS control algorithm, the automotive test engineer can log CAN and DAQ Messages simultaneously, analyze them, and determine if the desired motor output is being produced.
Figure 2. In this diagram for the data acquisition system, the NI PXI-6070E samples the torque, voltage, and speed that are being fed to the ECU under test. The NI PXI-846x CAN module samples the motor voltage output from the ECU.
6. Example LabVIEW Code
Basic Programming Model
The basic CAN/DAQ synchronization programming model of NI-CAN 2.x is very similar to the NI-DAQ API you may already be familiar with. The basic programming model is configure -> read/write -> clear. Using this programming model, CAN and DAQ data can be correlated easily with six basic LabVIEW VIs. Before CAN Channels can be used in LabVIEW, they must be created in Measurement & Automation Explorer or imported from a Vector database file.
Importing CAN Channels
Existing CAN Channels can be imported from Vector database (.dbc) files. To import channels, open Measurement & Automation Explorer and right click on CAN Channels under Data Neighborhood and select Import from CANdb File. The dialogue box will list all available Messages. When you click on a Message, you will have the option of choosing specific Channels within the Message. You can select which Channels you want to import.
Explicitly Configuring Channels
To configure CAN Channels explicitly, open Measurement & Automation Explorer and right click on CAN Channels under Data Neighborhood. Select Create Message. Specify the parameters for the Message as shown in Figure 3.
Once the message is created, it shows up under CAN Channels. To create a Channel, right click on the message you created and select Create Channel. A configuration box similar to the one shown in Figure 4 pops up. As you fill in information about Start bit and No. of bits, the matrix fills with gray boxes to indicate the bits that have already been used in Channel definitions. Blue boxes indicate the bits currently being defined. CAN Channels can also be tested using the Channel Test Panel. You can open this code from the Example Finder (Help>>Examples>>Hardware Input and Output>>CAN>>Channel API>>Synchronization>>Basic>>DAQmx>>CAN Waveform Input and DAQmx Waveform Input.vi)
Once the CAN Channels have been configured or imported, the programming model is easily implemented in LabVIEW. The CAN configuration code, shown in Figure 5, provides the essential steps for initializing CAN and DAQ channels in LabVIEW, using the channel API.
The three sections of the model will be discussed in more detail. The first element of the program is shown in Figure 5. It consists of the following elements:
- NI-DAQmx Create (AI Voltage Basic) - Initializes and configures the DAQmx Channels
- NI-DAQmx Timing (Sample Clock)- Configures the sample clock for the channels
- NI-CAN Init - Initializes a task for the specified channel list.
- NI-CAN Sync Start with NI-DAQ - Defines the PXI Trigger bus routing of the resync trigger and other trigger signals and synchronously starts the acquisitions;
Figure 5. CAN and DAQ interfaces are initialized and PXI Trigger line is configured for timing and triggering signals.
Sample Rate specifies the number of samples to be taken per second. If the sample rate is set to 0 then a single point read will occur. If the sample rate is greater than 0, then a continuous read will occur.
Channel List specifies the CAN Channels, for which communication will occur.
Interface specifies the CAN port used.
Input Mode specifies these Channels read from the CAN network. Other options are output (for write) and timestamped input.
7. Routing Signals
When sharing trigger and timebase signals between DAQ and CAN cards, these signals must be routed. This is done differently depending on whether you are using Channel or Frame API, and also whether you are sending the DAQ signals to the CAN card, or the CAN signals to the DAQ.
The NI-CAN Channel API uses RTSI to synchronize specific functional units on each card. For CAN cards, the functional unit is the interface (port). For DAQ cards, the functional unit is a specific measurement such as Analog Input or Analog Output. Each function routes two signals over the RTSI connection, timebase and start trigger.
When performing CAN/DAQ synchronization instead of unsynchronized CAN programming, remember to do the following:
- Replace "Init Start" with "Sync Start with NI-DAQ."
- Replace "Clear" with "Clear with NI-DAQ."
- "Sync Start with NI-DAQ" uses NI-CAN and NI-DAQ RTSI functions to synchronize the NI hardware products to a common time base and start trigger, and then it starts sampling on both tasks.
- When using "Sync Start with NI-DAQ" to start the tasks, the CAN Clear with NI-DAQ VI must be used to clear the tasks.
The DAQmx Connect Terminals VIs below are used within the VIs in the Synchronization palette of the Channel API to send DAQ signals to a CAN card.
Before beginning to use RTSI between CAN and DAQ, a decision has to be made as to which board should be used as the Master. NI-CAN software allows easy configuration of the Network Interface or CAN Objects as a Master or the Slave.
The software attribute that configures the object as a Master or Slave is the RTSI Mode. The following RTSI Modes are available in NI-CAN:
- Disable RTSI
- On RTSI Input - Transmit CAN Frame
- On RTSI Input - Timestamp RTSI event
- RTSI Output on Receiving CAN Frame
- RTSI Output on Transmitting CAN Frame
- RTSI Output on ncAction call
Modes 2 & 3 configure the object (Network Interface or CAN Object) as a Slave that takes an action on the RTSI signal.
Modes 4-6 configure the object (Network Interface or CAN Object) as a Master.
The VIs below show the ncConnectTerminals VI routing importing the DAQ signal to a CAN card.
8. Read and Write Types
• Timestamped (read only)
• Single Point
Fast access to most recent Message
Sample rate = 0
Continuous data streamed at fixed time interval
Sample rate > 0
There are three modes for Reads and two for Writes. Multiple read and write modes make it easier to customize your application. Single point measurements are useful when you want fast access to the most recent CAN Message. In Single point mode, a message is transmitted/received only when a read/write is called. Timestamped mode will be useful for test applications where CAN/DAQ synchronization is needed, but there is no need for further CAN data processing. In Timestamped mode, the CAN messages are logged with a timestamp. If the CAN module is synchronized (using the resync pulse) with a DAQ module, then the CAN data will correlate directly with the timestamped analog or digital data from the DAQ module.
Continuous mode is useful when you want to log data alongside analog or digital data from a DAQ device. In continuous mode, CAN values are resampled at each clock pulse until a new message is received. CAN networks are event driven. However, there may be times when you prefer to have continuous CAN values. In this case, you can use the Continuous setting on reads and writes. Using Continuous mode, CAN values are transmitted or received at each tick of the clock. In the case where the time base is faster than in the incoming or outgoing rates of the CAN nessages, the CAN messages are copied (resampled) until a new message comes in.
This feature is useful for logging data that is correlated to DAQ data, which is common in automotive CAN/DAQ test applications. In these applications, the same time base is used for CAN and DAQ. The data acquired in Continuous mode can be converted into LV-Waveform-Data-Type.
The section of LabVIEW code in Figure 6 shows the CAN and analog read functions synchronized through the
PXI trigger bus. Because the sample rate was set to 1000, the CAN messages are read 1000 times per second (continuous mode).
- NI-CAN Read –reads samples from a CAN task.
- NI-DAQmx Read – reads data from a buffered data acquisition.
- Build Array – concatenates multiple arrays.
- Align Waveform Timestamps – replaces all the timestamp values (t0) with the value of the index element in the array.
- Unbundle – checks for error status
- NI-CAN Clear with NI-DAQ – clears the CAN and DAQ tasks.
The resulting data is a waveform graph easily compared with the analog measurements. If the DAQ and CAN samples are synchronized, it is possible to display the waveforms together on one graph and view their relationship in time. Without synchronization, this is not possible because the data is not correlated. In our EPAS test system, the ECU sends a new RPM value over the CAN bus when a certain steering-torque threshold is reached. The steering torque is read as an analog input to the DAQ hardware, and the RPM value is represented by a CAN Message. To validate the behavior of the system, you need to verify that the correct CAN Message is transmitted at the time the analog input threshold is exceeded. This process requires the ability to accurately correlate the samples obtained from both the DAQ and CAN hardware. This comparison is shown in Figure 7.
As can be seen in Figure 7, without synchronization there is a slight lag in the start time of the NI-DAQmx Analog Input. This slight offset will drift over time and increase the differences between the read times, because there is no check to keep it together. This can be avoided by using synchronization, which is shown in Figure 8.
With proper synchronization your NI-CAN and NI-DAQmx reads can be simultaneously acquired throughout your test.
You can use simultaneously acquired CAN and analog data to validate an ECU with either the flexible PXI Trigger bus or RTSI bus available for PXI and PCI, respectively. Using the NI-CAN Channel API in LabVIEW provides a simple programming model to complete the synchronization program in six VIs. The comparison can be made in waveform charts using the continuous read mode.