FREEDIAG
The OSI 7 Layer Model and FreeDiag.



[ Home ] [ Download @Sourceforge ] [ Documentation ]
[ Mailing List ] [ Source code @github [primary] ] [ Source code @sf [mirror] ]

freediag and OSI Layers

If you don't know for sure what the "OSI Layers" are, you can google "OSI layers" and read around, because most OSs and comms systems use it in some form or another.

I would say that layers 1 and 2 are universally present and recognisable in all information systems - from layer 3 up, things get more blurred and dificult to distinguish. There is always a Layer 7 (the Application), which (in a poorer design) may implement some of the features of lower layers...

As a quick example, take your common Web browsing (HTML over HTTP over TCP/IP over Ethernet):

Please note that what one layer considers to be a Packet, another layer may see as just part of a Packet - TCP/IP Datagrams can span more than one Ethernet Packet, and an FTP file can be much larger than a TCP/IP datagram.... it depends on the size of each layer's packets.

Now let's look at OBD2/freediag layers.

Our little project is not at all simple, because it tries to deal with a lot of different physical interfaces, which can implement different sets of features. The more expensive ones ("active" or "smart") have their own "intelligence" and therefore can implement features from one, two, or more OSI layers...

Not only that, but this project also aims higher than the simpler OBD applications: it tries to convert the simple Tester/ECU link into a full-blown network stack, with multiple interface connections and protocol sessions simultaneously on the same tester machine (the PC).

The only way to explain each layer separately and completely, is to describe the code for those interfaces I call the "passive" ones ("dumb", or without processors). Their very simple hardware is easilly classified as Layer 1 (all they do is change voltages and currents, because cars use 12V ports, and laptops use 5V ports (mostly), and you don't want car spikes to fry your laptop ports), and this means they don't do any processing of the data coming through. So this kind of interface has to use 100% of the L1 code in freediag.

But extrapolating for the "smart" interfaces is easy: they do by hardware(HW) some of the stuff we otherwise do by software(SW), and that's why each interface driver implementation file (diag_l0_*.c) will state which features the interface HW implements on its own. From there, all the protocol layers above it can access those flags and choose between actually executing each protocol feature, or expecting/requesting the interface to do it automatically. That's the difference between "smart" and "dumb" in freediag... ;) This has a number of impacts on the code, like the execution of message framing and timeouts - some "smart" interfaces will handle them automatically (and therefore take longer to respond), so freediag can't apply the strict protocol timing parameters when talking to them - hence there are "relaxed" timeouts for talking to "smart" interfaces.

(Personally, I don't like "active" or "smart" interfaces because only their manufacturers can fully support them, and we depend on their good will and information to implement their drivers. But I have to admit they come in handy for most people because they take care of the icky details of slow initialization, checksums, timeouts, etc.)

I would expect to find a one-to-one correspondence between OSI layers and the freediag layers (diag_l0_*, diag_l1_*, diag_l3_*, etc.). Unfortunately, I don't think this is the case.... For starters, OSI layers begin counting from 1, and freediag counts from 0... (professional hazard amongst the C coders, I think...;). Anyway, the original authors took some degree of liberty while naming all the stuff they managed into the code. I don't blame them, it IS a confusing task to homogeneise different interfaces from different manufacturers, and different protocols from ISO and SAE, and wanting to build over that... And the OSI layers can be quite tiresome, too...

Looking at freediag specifically (this is what I THINK - so correct me if I'm wrong):

I hope I'm helping people understand the code, and not confusing them further! :)
For further enlightenment, read the source code!

vnevoa.