How Sending with functional addressing in client

[xinkunlong]

I do not know how to send a UDS service with functional addressing in the client
example

#  I want to send extendedDiagnosticSession with functional addressing, I do not know how to configure.
 client.change_session(DiagnosticSessionControl.Session.extendedDiagnosticSession)

[pylessard]

Hi,
There's no interface for you to do so unfortunately. This could probably be added, but there's few question to be answered

• why does it need to be functional?
• do you expect an answer from your server?
• do you want to switch between functional and physical back and forth?

[xinkunlong]

I am so sorry, I have been on a business trip before, so I have never time to reply

• why does it need to be functional?

1. I want to design a software download tool for vehicle flashing, So I need to turn off the communication($28) enable and DTC detection($85) enable of other ECUs through functional addressing, and then refresh the ECU through physical addressing.

• do you expect an answer from your server?

1. No

• do you want to switch between functional and physical back and forth?

1. yes

for example

client.change_session(DiagnosticSessionControl.Session.extendedDiagnosticSession) # use functional addr
client.control_dtc_setting(services.ControlDTCSetting.SettingType.off)  # use functional addr
client.communication_control(services.CommunicationControl.ControlType.disableRxAndTx,0x01)   # use functional addr
client.change_session(services.DiagnosticSessionControl.Session.programmingSession)  # use physical addr
client.unlock_security_access(0x11) # use physical addr
                     ....

[kayoub5]

@pylessard I see that the ticket is closed but I can't find the code for it, does that mean this topic on the roadmap, or simply rejected.

Would you consider a PR that supports this?

[pylessard]

Something's weird. I did add a feature to the can-isotp repo and I remember posting a message to this thread asking if the fix was enough.

Anyway,
Since functional/physical addressing is handled by the ISOTP layer, this feature is handled in the isotp layer.

See this commit : pylessard/python-can-isotp@cde59f4

It is not released yet unfortunately, but can do a release if needed.

Basically, I propose tho change the default_target_address_type parameter when needed. Something like this should work (when using the latest code from github)

stack = isotp.CanStack(bus=bus, address=tp_addr, params=isotp_params)
conn = PythonIsoTpConnection(stack) 
with Client(conn , config=my_config) as client:
    client.do_something()
    isotp_layer.params.set('default_target_address_type', isotp.address.TargetAddressType.Physical)
    client.do_something_else()
    isotp_layer.params.set('default_target_address_type', isotp.address.TargetAddressType.Functional)

[kayoub5]

@pylessard what happens when multiple ecus reply to the functional request?

Use case:

• Tester would like to dump the software version of all the ecus in the network.
• Tester send a functional read_data_by_identifier and wait for all ecus to reply
• Tester collects all the version information

Current ISO-TP implementation can handle this without issues, however the UDS layer will get surprised by multiple responses to the same request.
The UDS layer is expected in this use case to wait for more responses until a timeout expires.

This could also apply to other kind of requests, like ecu reset, and DTC.

Is this already covered somehow? or should I open a new ticket for this use case?

[pylessard]

Right,
This is not supported unfortunately. The UDS client is designed for a 1-to-1 communication.
Still, you are not out of luck. You can make usage of the layer of code below the client level to achieve this. You can invoke the ReadDataByIdentifier service object to generate a request and parse your responses. You can use directly the isotp layer to receive multiple response.

Does that help?

[kayoub5]

@pylessard I see.

Would you accept a PR that makes the client supports 1 to many communication?

[pylessard]

Hi,
I'm not against supporting this. I must admit that I hardly see how this will be done.
My main requirement is to be backward compatible, so unit test must pass. If you intend on breaking interface, you may consider adding parameters or extending the actual client with a subclass.

[prasadghole]

In most of cases like request for TesterPresent service we have to use functional address.

[pylessard]

I think we should close this issue. broadcast is handled at the isotp level. ISO-14229 is not designed for multi-server support (as far as I understood from it).