Is it possible to receive ALL responses to a functional request? about iso14229 HOT 6 CLOSED

the issue in our case is that we potentially do not know the physical addresses of the servers in a system and want to send a functional RDBI request on an identifier that we know (e.g. "boardtype") and then let the servers answer to find out their physical addresses. So the physical addresses are not known in advance, but are the subject of the inquiry.

from iso14229.

The use-case makes sense to me. I think we should support it.

The best idea I have for how to implement this is to refactor the client API into an event-based one like that which the server currently exposes. Here's an example of what that might look like in user code:

void fn(UDSClient_t *client, UDSClientEvent_t evt, void *evtdata) {
    switch (evt) {
        case UDS_CLIENT_EVT_IDLE:
           client->options |= FUNCTIONAL;
           UDSSendRDBI(client, ...);
           break;
        case UDS_CLIENT_EVT_RESP_RECVD:
           // process *a* server response here
           int err = UDSUnpackRDBIResponse(client, ...);
           break;
    }
}

Although this would be a major API change I think it could both (1) get us this feature and (2) simplify existing client code.

from iso14229.

This is an interesting use-case which we don't seem to handle at the moment.

Say for example you send a functional RDBI request. There are three servers on the bus with a shared functional address. One server sends a positive response, another server sends a negative response and the third server times out. What do you think this should this look like to the client API?

A possible stopgap solution is to use physical addressing. Instantiate a separate client for each server you'd like to read the hardware version of.

from iso14229.

Hi @driftregion , sorry for the late reply.

I'm not sure if I understand how this event-based approach could be used for a client to receive different answers to a single functional request. What if I want to send other requests from the same type but with other data parameters?

I personally find the current client API very comfortable and straight forward: prepare the client for the request, send the request, wait for the response and do with the response what you want. I would find it good to have the same option but being able to poll for the different answers, something in the lines of:

client->options |= FUNCTIONAL;
UDSSendRDBI(client, ...);

while (request_received = PollFunctionalRequests(client)){
    /* do something with response, it doesn't matter if positive, negative or timeout */
}

Where PollFunctionalRequests(client) like getopt() works, as long as there is something to process the answer is true. When there is nothing to process it breaks out of the loop.

Another point I have noticed is that when using the ISOTP Linux kernel module it is not possible to receive from all possible addresses but from the address the client was initialized with. When initializing the ISOTP sockets for the client in the function LinuxSockTpOpen , the function LinuxSockBind is called for the physical and functional links, whereby the rxid for the functional link is the phys_recv_id. Is there a way to initialize the ISOTP socket in a way that it receives from all addresses without "filtering" / listening to just one address? If this is not possible then it is not possible to receive from different ECUs in the CAN network since the socket is just bound to one address, which makes the whole issue/discussion a bit obsolete.

I hope I could make my point. If it's not understandable please don't hesitate to ask for clarification.

Interested: @slowCoder72

from iso14229.

ISO 15765-3 and -4 have a little more context on physical and functional CAN IDs.

https://en.wikipedia.org/wiki/ISO_15765-2
https://en.wikipedia.org/wiki/Unicast
https://en.wikipedia.org/wiki/Multicast

ISO 15765-3 writes:

Functional addressing (1 to n communication) shall only be supported for SingleFrame transmission.

• Functional requests will only use SingleFrame transmission. For standard CAN, this means the ISO-TP data is no longer than 7 bytes. I believe the underlying technical reason for this is that flow control breaks in multicast.

My understanding of the intent of ISO-14229-1 and ISO-15765-3 is that a tester uses N+1 ISO-TP links where N is the number of servers and the last link is used only for functional transmission (sending functional requests).

I believe your proposed use-case: sending a functional request and listening for responses can be done within the scope of the standards if you initialize an ISO-TP socket for each of the possible response IDs (i.e. each possible server)

What remains unclear to me is an interpretation of "tester". It's capable of sending requests to multiple servers. The current implementation of UDSClient in https://github.com/driftregion/iso14229 assumes only a single server. (see pylessard/python-udsoncan#88 for some related discussion).

Imagining a UDSClient capable of interacting with multiple servers, some specific problems to be solved are:

• ISO-TP link instantiation
  • when using isotp-c, separate ISO-TP receive buffers will need to be allocated for each server
• What does the API for making requests look like now that a server address must be specified?
  • UDSSendTesterPresent(&client, &session)
  • UDSClientSetSrvAddr(&client, srv_addr)

from iso14229.

I think you are right regarding the use of N+1 ISO-TP links when trying to communicate to several servers. I found similar information in other sources, so I guess I was thinking to do something that was not part of the standard. Therefore, I think that trying to develop an UDSClient that can manage multiple connections is not necessary since one just has to create a new client for each connection, and like you mentioned, an extra one for sending functional requests.

I appreciate your engagement. If you still find that a UDSClient capable of interacting with multiple servers is a good idea, we could still discuss it, otherwise I would close this issue.

from iso14229.