UDS Support (cancelled)

[mickeyl]

This issue is for keeping track of the necessary work to allow UDS communication as per ISO14229

• Allow configuring the ELM327 adapter initialization
• Implement ELM327 Arbitration and Control Flow commands
• Implement ISO-TP in direction ADAPTER → ECU
• Add service IDs for UDS

[mickeyl]

Apart from the changes I already did in the UDS branch, I sadly have to confess that I have abandoned the idea of adding full UDS support to this library.

After having worked more on UDS (and I can release working code very soon), I have realized that when developing this library, I did base the protocols and the parsing with some OBD2-format-assumptions that no longer hold would I generalize this for introducing full UDS support.

In order not to destabilize this library and add a lot of special casing and/or #ifdefs, I decided not to pursue this plan any further. Instead, I have started to work on a new library that encompasses OBD2 and UDS from the start.

This also allows me to handle some of the other griefs that I always had with this library – in particular the support for multiple adapter types, multiple (non-apple) platforms, and the notion of units right from the start.

Plus: The new library will be implemented in Swift, which – while not being uncontroversial – due to its richness in language concepts allows for a much better translation.

[mickeyl]

Leaving this issue open so that it's immediately visible.

[rs38]

only being curious and willing to learn:
how would UDS support de-stabilize an OBD lib, if OBD is (at least in theory) only special case of UDS sitting upon it from an OSI layer perspective?
Is it keeping compatibility with certain tools that reflected special cases for the tool's sake?

[mickeyl]

@rs38 I'll tell you. As I worked on UDS and KWP, trying to extend this library to cover both protocols, I began to understand how many OBD2-isms were lurking in LTSupportAutomotive. The major deal-breaker though was the missing support for multiple OBD2 adapters, in particular for adapters that handle the ISOTP fragmentation on the controller layer.

Digression: Handling ISOTP fragmentation on the controller (OBD2 adapter) is a necessity for transmitting large ISOTP frames, i.e., when rewriting flash software to an ECU. The vast majority of ELM327 and its clones do not have the capability to handle this, hence you can't use them for something like ECU reprogramming or enhanced diagnostics.

As I layed out an infrastructure that would support multiple adapter types with their own specific command sets, it became clear that I would have to tear a whole lot of the layers in LTSupportAutomotive apart. I learned a lot more about OBD2 since I first designed this library in 2016 – and while it is a good and stable work-horse, there's no way I spend a whole lot of time to retrofit all the new requirements.

Last but not least, I was teased by Swift, in particular Swift 5.5+. Swift 5.5+'s introduction of first class concurrency features allows for a wonderful mapping of hardware communication, which is inherently asynchronous, to programmatic control flow. So it became clear to me that I can only solve the complex requirement of rock-solid ECU reprogramming with a new Swift-Concurrency-based library.