Working with Plug-Ins

Refer to the following topics to learn more about creating plug-ins and considerations for restbus simulation applications.

You can use plug-ins to perform real-time restbus simulation, transfer images from the environmental server to the ADAS ECU, and more. Refer to the Replay and HIL AD GitHub Repository for more information about creating and using I/O plug-ins in your system, including instructions for building individual plug-ins and recommendations for using collections of plug-ins to enable more complex functionality.

Note If needed, contact your NI Services representative to gain access to the Replay and HIL AD GitHub Repository.

Restbus Simulation

Restbus simulation allows you to validate ECU functionality by simulating in-vehicle busses. This can reduce test time and cost by allowing you to see how an ECU responds to simulated real-world conditions from a vehicle bus without setting up an entire vehicle network or performing expensive field tests.

Keep the following guidance in mind to enable successful restbus simulation:

  • Since a large number of ECUs can communicate on the same network, you must be able to replace a simulated ECU with a real ECU (or vice versa) to simulate different parts of the full network. For maximum testing efficiency, this transition from real to simulated or simulated to real must be as easy and streamlined as possible.
  • You must maintain the integrity of message timing for both real and simulated ECUs to establish communication between them. Network descriptors (such as .dbc, .ldf, or .arxml) contain the PDU or frame timing properties necessary to correctly simulate in-vehicle network traffic.
  • In addition to ensuring the correct message timing, you must ensure that the PDU or frame timing properties contain the correct CRC, Counters, and Secure On-board Communication (SecOC) parameters. These security and safety profiles can be accessed directly from the restbus simulation engine (if configured) or generated from a restbus simulation model.
  • You can connect other restbus models, vehicle dynamics models, or sensor models to your restbus simulation to complete the simulation of all parameters to ensure correct communication with the ECU. These other models are typically provided by environmental simulators or directly written into a modeling environment.
  • NI recommends using NI-VCOM for restbus simulation applications.

System Timing

Plug-in timing statistics are calculated using timestamps, which mark events as plug-ins cycle through different states.

Timestamps

Plug-ins typically cycle through each of the following three states once per interval:
  • Sleep
  • Logic execution
  • Housekeeping
Several timestamps are marked during each interval:
  • Start sleep—Timestamp for beginning of sleep state
  • Target wake time—Timestamp for target end of sleep state before logic execution
  • Wake time—Timestamp for actual end of sleep state, which can be followed by the logic execution state or the housekeeping state
  • End execution—Timestamp for logic execution completion
  • Start housekeeping—Timestamp for beginning of housekeeping state
Figure 3. Plug-In States and Timestamps

1378

Timestamps are also marked as data transfers between multiple plug-ins from a file on the environment server to the memory in the RT target and then to the hardware interface of the DUT. The following timestamps mark this data transfer:
  • T0—Timestamp for data generation from the first plug-in after being sampled from sensors or the simulator
  • Tx—Timestamp for target time of data input into the FIFO queue for transfer to the next plug-in
  • Tx_Actual—Timestamp for actual time of data input into the FIFO queue for transfer to the next plug-in
  • Rx—Timestamp for data output from the FIFO queue when data is received from the previous plug-in
  • T_Out—Timestamp for target time when the last plug-in should output data
  • T_Out_Actual—Timestamp for actual time when the last plug-in outputs data
Figure 4. Data Transfer Timestamps

1378

Timing Statistics

To calculate plug-in timing statistics, refer to the following table:
Table 3. Calculating Timing Statistics
Statistic Timestamp Formula Description
Cycle Wake Time - Last Wake Time For plug-ins that are configured to run periodically, Cycle equals the set iteration interval since it refers to the interval of logic execution. This result is not relevant for plug-ins set to run on new data.
Exec End of Execution - Wake Time Exec equals the amount of time the plug-in uses to process logic.
Idle Wake Time - Start Sleep Idle equals the amount of time remaining in the cycle. A higher Idle value provides increased ability to handle jitter in the process data loop without impacting loop rate. Ideally, Cycle = Exec + Idle.
Wake Error Target Wake Time - Wake Time Wake Error equals the OS error in waking the loop on a schedule. Setting multiple loops to wake at the same instance causes wake error to increase.
FIFO Queue Latency Rx - Tx FIFO Queue Latency equals the difference between the timestamp of one plug-in receiving data and the timestamp of the previous plug-in sending data.
End to End Rx - T0 This statistic equals the total latency from when the data is first created, including all plug-in processing time and FIFO queue latency.
Output Error T_Out - T_Out_Actual This statistic indicates how closely the data output to the DUT aligns with the desired time. The actual output time being late can cause DUT errors due to data from various sources being uncoordinated.