P2 timeout is not checked correctly when response has consecutive frame

[tienlocnguyen]

In client.py, function send_request wait for entire response with timeout is P2 timeout. But as I know, P2 timeout is timeout to the first response(can be first frame) not entire response. So with long response, timeout error will occur

[pylessard]

Hi,
I understand the issue you point out. It might be a little tricky to handle. Do you have the reference in the standard that suggest this is the right behaviour?

[tienlocnguyen]

Hi pylessard,
After double check, I found that ISO 15765-3 define P2client timeout as timeout for waiting start of incoming response(Single or first frame).
But this standard is revised by ISO 14229-3:2012.
So I need more time to check the standard.
Thanks

[pylessard]

Thank you for your input.
I will wait a feedback from you before looking into any solutions.

Regards

[tienlocnguyen]

Hi pylessard,
Could you double check definition of P2 client timeout on 14229-2? I don't have this standard.

[Sauci]

according to ISO-15765-3, the P2_can_client is defined as:
Timeout for the client to wait after the successful transmission of a request message (indicated via N_USData.con) for the start of incoming response messages (N_USDataFirstFrame.ind of a multi-frame message or N_USData.ind of a SingleFrame message).

[martinjthompson]

ISO14229-2:2013(E) defines P2_Client as

Timeout for the client to wait after the successful transmission of a request message (indicated via T_Data.con) for the start of incoming response messages (indicated via T_DataSOM.ind of a multi-frame message or T_Data.ind of a SingleFrame message).

Figure 9 shows the P2Client timer being stopped at SOM.ind - just after the start of the response message, with the following text:

Client T_DataSOM.ind: transport/network layer issues to diagnostic application the reception of a StartOfMessage. Client stops
the P Client timer.

[MatinF]

Hi all,

Is there a standardized timeout/interval specified when performing CAN ISO-TP requests?

Specifically, I am thinking of the following intervals to be satisfied by the ECU and tester:

tester:  Send Single Frame (SF) request
- interval_1
ECU:    Send First Frame (FF) response
- interval_2
tester:  Send Flow Control (FC) frame
ECU:    Send remaining Consecutive Frames (CF)

It is unclear to me if interval_1 and interval_2 above are well-defined - and if so in what standard?

Further, if they are "dynamic" and depend on the specific ECU implementation, how is the tester (e.g. a diagnostic tool) supposed to know how fast to respond with the Flow Control frame after receiving the First Frame from the ECU?

[pylessard]

Hi @MatinF
Timing requirements would be defined by ISO-15765.
For the specific interval you are requesting, I think there is no requirement. Only timeouts value if the delay is too long.
I am referring to ISO-15765-2:2016 section 9.8

[MatinF]

Thanks for the clarification. So just to verify that I've understood this correctly:

1. There is no "minimal wait time" before an ECU sends the First Frame
2. There is no "minimal wait time" before a tester can send the Flow Control frame after receiving the First Frame

In regards to the Timeout, it looks like this is up to 1000 ms based on the above
3) Is it correctly understood that the First Frame will always arrive within 0 to 1000 ms after the Single Frame request?
4) Is it correctly understood that the Flow Control frame must always be sent within 0 to 1000 ms after the First Frame?

I guess what I am unsure about is whether one can rely on the 1000 ms as a standard across all ECUs - or if this is implementation specific. If the latter is the case, do you know if there are some general conventions/good practices to follow in terms of what timings to expect?

Thanks!

[Sauci]

Hello @MatinF,

• Concerning the interval_1:
  I think the transport layer handles the request and the response in two different transactions, and is not responsible of the interval_1 timeout management. This timeout value is managed by the communication layer above the transport layer.
  For example, having the UDS protocol in mind, the tester will send, (for example):
  • 22 xx yy as first transport layer transaction
  • 62 xx yy 12 34 as second transport layer transaction (which might also be a segmented message)
• Concerning the interval_2:
  The interval between the confirmation of the request (client/tester side) and the indication of the first frame reception (client/tester side) is N_Bs from what I see on the screenshot shared by @pylessard, so I would say yes, 1000ms looks correct.

[pylessard]

Thanks for the clarification. So just to verify that I've understood this correctly:

1. There is no "minimal wait time" before an ECU sends the First Frame
   I think this is right

2. There is no "minimal wait time" before a tester can send the Flow Control frame after receiving the First Frame
   I think this is right

3. Is it correctly understood that the First Frame will always arrive within 0 to 1000 ms after the Single Frame request?
   No. But it is not a timing specification question here, you misunderstood the purpose of single frame and first frame. First frames and single frames does not come one after the other, so First Frame is not expected after a single frame, tehrefore, no timeout value applies here.

Single frame carries an isotp frame in a single CAN message. First Frame is the begining of an isotp frame that requires multiple CAN message. So they are both the beginning of a transmission. They are unrelated.

4. Is it correctly understood that the Flow Control frame must always be sent within 0 to 1000 ms after the First Frame?
   I think this is right. 1000ms is very long though. From my experience, you can expect it within few milliseconds.

On a additional note.
a 500kbits link will allow a bit more than 4 messages per milliseconds. A good ECU is able to use 100% of bandwidth. In that case, a response is expected within the following millisecond (if the CAN bus is not too much loaded). Many less good ECU will be able to read 1 CAN message per milliseconds, very often limited by software. I even saw one very bad ECU limited to 1 message per 10 milliseconds (ouch.).

If you want to be safe in your implementation, you can leave a 1 or 2 millisecond delay where there is no specification. That will ensure maximum compatibility.

Regards

[Sauci]

Hello @pylessard,

Concerning the hard-coded delay, I'm not sure to understand. The transport layer also specifies the STMin parameter (minimum separation time between two consecutive frames), which is communicated to the client/tester by the ECU trough the Flow Control frame (byte 3). Wouldn't it be the responsibility of the ECU to tell the client/tester to lower the communication speed?

[pylessard]

Yes, between consecutive frames. (I think)
But the interval pointed out by @MatinF are not defined.
I guess the STmin from previous frame could be reused between last frame and next beginning of transmission.

[MatinF]

Just to clarify:

When I mention the time between the Single Frame and First Frame, by Single Frame I refer to the "request" frame to be sent by the testing tool (which will have the same format as a Single Frame in the ISO TP context). Hence, my question was related to what the defined max timeout would be before the ECU must send the First Frame response to the request.

My understanding here is that this delay may be 1000 ms in theory, but in practice it will most likely be far less (e.g. 1-10 ms).

Similarly, the timeout before the Flow Control must be sent by the tester device should be 1000 ms in practice (i.e. N_Bs), but in practice the Flow Control would typically also be sent far more swiftly after the First Frame response from the ECU (again e.g. within 1-10 ms).

Let me know if I missed something here.