G Implementation - ECU M&C and Automotive Diagnostic Command Set

[Hooovahh]

There are currently two NI toolkits which add a software layer on top of the automotive CAN bus.  

The Automotive Diagnostic Command Set (ADCS) adds a couple of protocol standards like KWP2000 (ISO 14230), Diagnostics on CAN (ISO 15765, OBD-II), and Diagnostics over IP (ISO 13400).  This is a pretty handy API when all you need is one of these protocols.  But often when you need to communicate to an ECU, you also want have a normal Frame or Signal/Channel API where you get raw frame data, or engineering units on signals.

The ECU Measurement and Calibration (ECU M&C) adds XCP, and CCP capabilities on top of CAN allowing to read and write parameters based on predefined A2L files.  This again is super handy, if the A2L you provide can be parsed, and if all you need to do is talk XCP or CCP to some hardware.  But often times you also need to talk over a Frame or Signal/Channel API.  And what if you need to also talk over some other protocol.

Every time I've had to use one of these toolkits, it has failed me in real world uses, because you generally don't want just one API you want severaal.  And to get that kind of capabilities you often are going to close one API sessions type, and reopen another, then close that and reopen the first.  This gets even more difficult when different hardware types either NI-CAN or NI-XNET are used.  The application ends up being a tightly coupled mess.

This idea is to rewrite these two toolkits, to be as pure G implementation as possible.  The reason I think this would be a good idea, is because with it you could debug issues with file parsing, which at the moment is a DLL call and hope it works, and it would allow for this toolkit to be used, independently of the hardware.  Just give it some raw frames, and read data back.  NI-XNET already has some of this type of functionality in the form of their Frame / Signal Conversion type, where it can convert from frames to signals without needing hardware.  If these toolkits could support this similar raw type of mode then it would allow for more flexible and robust applications, and potentially being able to use these toolkits on other hardware types, or simulated hardware.

[StephenB]

you can open a session with the toolkit, and the standard xnet driver, to the same physical port and use them simultanously.

[Hooovahh]

Yes if you are using XNet hardware, but what about when you are using non-XNet hardware, or what about if you are using non-NI hardware even?  If you are looking to make a bunch of duplicate test stands, and each will have lots of CAN ports it might be attractive based on price to get NI's cheapest solution which are the 8473.  I understand with better hardware you get better features, but having this hardware be limited to one session, and having either of these toolkits take up that one session, is quite limiting, especially when this can be done as a software layer and still allow other communication.

[AristosQueue (NI)]

> or what about if you are using non-NI hardware even?

Oh, that's easy to fix... you just need a valid credit card. Contact NI tech support... they'll help you out. 🙂

Joking aside... this idea is outside my knowledge base... I'll pass it around and see if I can find someone from CAN to comment.

[Hooovahh]

@AQ

I'd be glad to hear anything new on CAN from NI's side.  These two toolkits seem to have gone mostly dormant, with release notes for the last few years just being new hardware support and new LabVIEW version support.  Not that these things aren't appreciated, but I just believe it to be a sign that NI is satisfied with the feature set of these toolkits and isn't investing in them.  Over the years whenever I try to use one of these there is usually some kind of show stopping limitation and since these two toolkits are just a DLL wrapping call, there isn't much troubleshooting or debug possible.

I maybe wrong but from what I remember one or more of these toolkits are written by the Germany NI office, or is somehow affiliated with that office, and getting technical support for these has been an issue.  Certainly there is more than one solution to this, but I figured having the G code of these toolkits might mean more flexibility, and less reliance on NI support.

Maybe this effort is way more than I understand, but I figured I would want this feature, and others can vote with their kudos as well.

[Hooovahh]

Well for the heck of it I decided to take a stab at implementing the ISO 15765 protocol which is what the ADCS uses under the hood.

http://forums.ni.com/t5/Automotive-and-Embedded-Networks/Automotive-Diagnostic-Command-Set-USB-Trans...

Basically this function performs the individual CAN frame reads/writes the same way the locked Diagnostic Service.vi function does.  With this function you should be able to use the ADCS with any hardware, and just replace the frame read/write that takes place in my VI with the one for that hardware.  In testing this I've been able to flash ECUs with Vector, Intrepid, Kvasar, XNet, and NI-CAN hardware, using the ADCS.