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.

[canon193]

Hi @pylessard,

I have just faced this issue during testing read dtc request. The expected data flow is as below:

Tester: Send read DTC request
ECU: First frame response
Tester: Send control flow
ECU: Send consecutive frame
ECU: Send consecutive frame
...

Then I got the P2 timeout after 1 second. From my understanding, the lib is waiting for isotp to send receive done notification during waiting for P2 time. However, according to ISO14229-2, the P2 timeout should be the timing between tester request and first response from ECU (which is the first frame). I believe there should be another notification from isotp like start receiving notification to stop the P2 timeout.
Could you share your oppinion?

Reference from ISO14229-2:

[pylessard]

Just to let you know that isotp v2.x will be released soon and the possibility of doing a blocking send has been added. This will allow starting the timer at the right moment.

I will see how I can bring that api up to the UDS level so it can be used across connections (that supports it)

[pylessard]

isotp v2.x has been released. and udsoncan 1.21 supports it.

using the new parameter from isotp v2.x blocking_send=True, this issue should be resolved.
I am still wondering if I should enable something within the udsoncan API for that

[demedvedev]

Hi,

I believe the problem a still here. I am trying to read DID which is 20b long and get P2Server timeout error.

p2_timeout(float)
Maximum amount of time in seconds to wait for a first response (positive, negative, or NRC 0x78). After this time is elapsed, a TimeoutException will be raised if no response has been received. See ISO 14229-2:2013 (UDS Session Layer Services) for more details. Default value of 1

Python 3.11.8 (tags/v3.11.8:db85d51, Feb 6 2024, 22:03:32) [MSC v.1937 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.

= RESTART: READ.py
Timestamp: 1713366358.755885    ID:      5c4    S Rx                DL:  8    60 00 00 03 35 00 00 00     Channel: 0
2024-04-17 18:05:58 [INFO] Connection: Connection opened

2024-04-17 18:05:58 [INFO] UdsClient: DiagnosticSessionControl<0x10> - Switching session to defaultSession (0x01)
2024-04-17 18:05:58 [DEBUG] Connection: Sending 2 bytes : [1001]
Timestamp: 1713366358.820241    ID:      7aa    S Tx                DL:  8    02 10 01 00 00 00 00 00     Channel: 0
Timestamp: 1713366358.820765    ID:      7ad    S Rx                DL:  8    06 50 01 00 32 01 f4 aa     Channel: 0
2024-04-17 18:05:58 [DEBUG] Connection: Received 6 bytes : [5001003201f4]
2024-04-17 18:05:58 [INFO] UdsClient: Received positive response for service DiagnosticSessionControl (0x10) from server.
2024-04-17 18:05:58 [INFO] UdsClient: DiagnosticSessionControl<0x10> - Received new timing parameters. P2=0.050s and P2*=5.000s.  Using these value from now on.
2024-04-17 18:05:58 [INFO] UdsClient: ReadDataByIdentifier<0x22> - Reading data identifier : 0xf18c (ECUSerialNumberDataIdentifier)
2024-04-17 18:05:58 [DEBUG] Connection: Sending 3 bytes : [22f18c]
Timestamp: 1713366358.839337    ID:      7aa    S Tx                DL:  8    03 22 f1 8c 00 00 00 00     Channel: 0
Timestamp: 1713366358.839795    ID:      7ad    S Rx                DL:  8    10 17 62 f1 8c 43 4a 4d     Channel: 0
Timestamp: 1713366358.847864    ID:      7aa    S Tx                DL:  8    30 08 20 00 00 00 00 00     Channel: 0
Timestamp: 1713366358.849576    ID:      7ad    S Rx                DL:  8    21 30 38 58 56 30 36 35     Channel: 0
Timestamp: 1713366358.889578    ID:      7ad    S Rx                DL:  8    22 32 34 30 30 56 35 20     Channel: 0
2024-04-17 18:05:58 [DEBUG] Connection: No data received: [TimeoutException] - Did not receive IsoTP frame from the Transport layer in time (timeout=0.05 sec) 
2024-04-17 18:05:58 [ERROR] UdsClient: [TimeoutException] : Did not receive response in time. P2 timeout time has expired (timeout=0.050 sec)
Timeout in the communication happens : Did not receive response in time. P2 timeout time has expired (timeout=0.050 sec)
Timestamp: 1713366358.929579    ID:      7ad    S Rx                DL:  8    23 20 20 20 aa aa aa aa     Channel: 0
2024-04-17 18:05:58 [INFO] Connection: Connection closed
Timestamp: 1713366359.410253    ID:      5c4    S Rx                DL:  8    60 00 00 03 35 00 00 00     Channel: 0
Timestamp: 1713366360.410218    ID:      5c4    S Rx                DL:  8    60 00 00 03 35 00 00 00     Channel: 0
Timestamp: 1713366361.410183    ID:      5c4    S Rx                DL:  8    60 00 00 03 35 00 00 00     Channel: 0
Timestamp: 1713366362.410156    ID:      5c4    S Rx                DL:  8    60 00 00 03 35 00 00 00     Channel: 0

pip3 list
Package Version

---

annotated-types 0.6.0
can-isotp 2.0.4
canlib 1.25.393
intelhex 2.3.0
packaging 23.2
pip 24.0
pydantic 2.6.3
pydantic_core 2.16.3
python-can 4.3.1
pywin32 306
setuptools 65.5.0
typing_extensions 4.10.0
udsoncan 1.23.0
wrapt 1.16.0

[pylessard]

you're not having the same issue here.
You server requires a timeout of 50ms, and the lib follows it. But 50ms is very tight for something that runs in pure python on window sin the user space.

Check this parameter : https://udsoncan.readthedocs.io/en/latest/udsoncan/client.html#use_server_timing