Using “replay as LIN slave”, a recording can be played back on the LIN bus using a real LIN master ECU. The following parameters/settings must be taken into account to avoid problems:
•The LIN slave cannot write independently on the bus. It depends on a request by the LIN master.
•Replay can only follow the recording if the LIN master behaves the exact same way as during recording.
• The PC cannot respond in time to a LIN master query, making a special usage of the LIN hardware necessary.
Mode of operation
The following section refers to a replay as LIN slave using active “runtime synchronizing with LIN master” and specified lead and follow-up times. To give an example, the following figure illustrates the path of message data in the recording and a subsequent replay.
First of all, a recording is prepared – represented by the green line. The message value is not yet set or set to the initial value in the data base. After 100 ms, the message is recorded for the first time and receives a new value A. The next value change occurs after 230 ms when the message receives value B. Further value changes take place at 340 ms and 420 ms.
Simplified, the recording includes the following data:
Timestamp Ts |
Value |
100ms |
Value A |
230ms |
Value B |
340ms |
Value A |
420ms |
Value B |
During replay, it is assumed that the LIN master will enquire this data precisely at the recorded times. Therefore, recorded data should be available to the LIN master.
Distinctive features of LIN hardware
The LIN bus is based on the master-slave principle. There is always a master initiating the sending of data by the slaves. To achieve that, the master writes a message header on the bus. The slaves can now respond to the query within a short time period. If the respective slave does not respond in time, this is either registered directly as an error or the data read from the bus is faulty.
Normally, the computer is not able to react fast enough to such a query. This is not only due to the architecture, but also to the used operating systems. Therefore, all data to be sent is stored on the LIN hardware ahead of time. As soon as the LIN master sends a request, the data is sent without the PC.
That means:
•Bus events cannot be reacted to immediately
•All data to be sent must be stored on the hardware prior to sending
•The behavior of the LIN master must be predictable during replay
Sequence of replay
It is not sufficient during replay to write the recorded data on the hardware the same time the LIN master requests it. The data must be written ahead of time. For this purpose, ΔTs (delta T) is used. This time span is subtracted from every sending time to determine the time at which the data is written. In the figure (see above), this time span is marked in yellow. Therefore, the LIN master does not need to request the data at the same time as in the recording. Instead, it can request the data ΔTs before.
The data is available to the LIN master until the next value is set. A deviation to the recording can be determined by measuring the retrieval time. This is calculated into the timing of subsequent data. Ideally, the replay can be adjusted to the master, even compensating for smaller sporadic time shifts.
Only sending events occurring within one ΔTs time span are registered as a deviation. This affects the timing prior to the actual sending time (yellow area), as well as the timing after the actual sending period (orange area).
Starting the replay
The replay is started by starting the simulation. Initially, the replay remains on hold (in the figure: time point Z1). The replay waits for a LIN master event to wake and start. Retrieval or sending of specific message IDs are counted as LIN master events (in the figure: time point Z2).
Afterwards, data is set at the recorded time minus ΔTs. In the figure, this is represented by the red line. For example, data is set at time points Z3 and Z6.
The blue line in the figure shows the value changes the master receives. It receives the first value at time point Z2. This event also activates the replay. The next time the LIN master requests data is at time point Z4. The figure shows that the master has requested the data earlier than in the recording. This deviation is noted and included in the calculation of subsequent timings. Then, either the sending periods are brought forward (in case of earlier requests) or delayed (in case of a delayed request by the LIN master). Thus, the replay can be synched to the timing of the master in the millisecond range.
Another data request takes place at time point Z7. This time point has entered a critical range. The master’s request is delayed so significantly that an overlap in time is created.
This overlap is created by the preceding ΔTs and the succeeding ΔTs of two sending times (in the figure: violet). If both of these times overlap, the preceding ΔTs of the succeeding sending time is shortened. If the master requests data during an overlap, the data of the next sending point is written directly afterwards (see figure under mode of operation, time point Z7).
Effects of LIN master behavior on the replay
•If the LIN master requests data much more often than during the recording, the sampling points within a lead or delay time are included in the calculation of timing deviation.
•If the LIN master samples multiple times during a lead time, only the last sampling instance is included in the calculation.
•If the LIN master samples multiple times during a delay time, only the last sampling instance is included in the calculation.
•After requesting data within an overlap period, the data of the next time point are set directly.
•If data is requested prior to the overlapping period, the data of the next time point is set directly at the beginning of overlapping period.
•If the LIN master does not request a message, the replay continues and the next data is set. In this case, no deviation is registered.