LIN/CAN Analysetool "CaLiGraph"

Moin zusammen, beflügelt von meinem LIN-Sniffer auf ESP32 Basis und der dafür angefangenen LIN-Analyzer Tool Software habe ich das Projekt erweitert und programmiere nun einen LIN-Bus/CAN-Bus Analyzer.

Funktionale Anforderungen:

1. Verarbeiten, analysieren und visualisieren von Dump-Daten im "CANDUMP" (und später auch mal in anderen) Datenformat
2. Daten können aus Datei (Logdatei) gelesen, aber auch Live von einem Websocket geliefert werden (z.B. mein LIN-Sniffer Tool)
3. Mehrere Betriebsmodus:
   1. Offline-Datenanlyse (Sichtung, Filterung, Darstellung von Log-Inhalten in vielen Möglichkeiten) mit Möglichkeit Inhalte zu "taggen" wenn deren Funktion klar ist
   2. Live-Modus zur Darstellung von Daten mit Änderungsanzeige, etc. während diese reintrudeln
   3. Replay-Modus bei dem Logdateien in Echtzeit, verzögert oder schrittweise, vorwärts/rückwärts durchlaufen werden können
   4. Dashboard zur Darstellung von Werten als Graphen, Drehinstrumente, Schalter, Lichtsignalen, etc.
4. Übersichtsseite in der bekannte und unbekannte Werte dargestellt werden, so eine Art TODO um einen Überblick des Reverse Engineerings zu bekommen und wo man noch arbeiten muss
5. Die Einstellungen können in einer lokalen Config-Datei gespeichert und geladen werden. Zusätzlich soll ein Share-Server (den ich selbst betreibe) die Möglichkeit bieten Settings mit anderen zu teilen

Hier mal ein Mockup (also noch ohne besondere Funktion) zum reinklicken und "fühlen" => https://mk4-wiki.denkdose.de/tools/caligraph/index.html

Meine Idee für das Framework:

• Ein Scanner-Task liest live von einem Sniffer-Tool oder aus einer lokalen Log-Datei
• Das Tool hat grundsätzlich eine Darstellungsseite für die Daten, verbunden mit Rekorderfunktionen zum pausieren, vorwärts- rückwärts laufen lassen, ändern der Abspielgeschwindigkeit.

Für den Producer-Task:

1. WebSocket-Verbindung + candump Parser → erzeugt interne Frame-Objekte
2. IndexedDB-Ringpuffer (Producer)
3. Export-Funktion für candump in Datei

Mit 1. verbindet sich das Tool also per HTTP-Websocket mit einer Datenquelle (z.B. meinem LIN-Sniffer, an einem CAN-Sniffer bin ich bereits dran).
Mit 2. werden die dort abgerufenen Daten in einer Browserinternen Datenbankdatei gepuffert um das RAM nicht zu sehr zu belasten bei langen Logs
Mit 3. kann man die in der DB gepufferten Daten dann im CANDUMP Format in eine lokale Log-Datei für spätere Analysen oder zum teilen ablegen.

Für den Consumer-Task:

1. Pivot-Grid (Consumer, auto-refresh)
2. DVR-Controls (Playhead, Live/Pause/Scrub)
3. Graph-Panel
4. Export-Funktion

In dieser ersten Version habe ich die Möglichkeit integriert einen Datenstrom über Websocket oder Logfile zu laden. Der "Videorekorder" funktioniert auch schon und man hat div. Möglichkeiten die Daten darzustellen und zu filtern.

(1) Ladebereich (Dropzone) für .log Files im CANDUMP Format (es können auch mehrere Logs geladen werden)
(2) Filter-Bereich für IDs - Hier kann man auswählen welche IDs man sehen möchte. Einzelne lassen sich durch Klick ab/anwählen. Damit kann man sich, auch im LIVE Modus auf einzelne IDs beschränken die man untersuchen will.
(3) Spalteninhalte (da muss ich nochmal ran...) - damit soll man wählen können was man alles sieht, die ID is obligatorisch, aber die anderen Daten kann man wählen. Auch soll man bei Daten die verschiedenen Darstellungsformen (HEX, DEZ, BINÄR) wählen können. Das gefällt mir aber noch nicht so...
(4) Das ist der Rekorder, das Herzstück des Monitor-Modes - Hier kann man mittels dem Slider oder den Tasten vor-/zurückfahren in den Logs oder wieder zum Live-Mode wechseln.
(5) Die Logdaten Darstellung - Wenn sich der Wert einer ID vom letzten zum aktuellen Frame ändert, wird die ID-Zeile kurz grün hinterlegt. So weiß man welche Bytes ihren Wert geändert haben. Auch da muss ich nochmal ran, das gefällt mir aktuell noch nicht wie ich es umgesetzt habe...

Zum spielen habe ich mal ein paar meiner Debug-Logs beigelegt.

Zur grafischen Darstellung von Payload-Bytes habe ich eine "Graph Traces" Option entwickelt. Dazu definiert man einen Graph indem man die ID der darzustellenden Daten angibt (Frame ID) und über eine Formel (JavaScript Syntax) die Berechnung, wie hier im Beispiel "b(2) / 16" was bedeutet: Nehme den Wert aus dem 3. Byte von links der Payload von ID 0x00D und teile den Wert durch 16:

Man erhält dann unten einen schönen Graphen der alle Datenpunkte anzeigt und verbindet:

Über die Bereichswähler am Graph soll man dann den Zeitraum eingrenzen können, also ALL für von Anfang bis zur aktuellen Rekorderposition und die anderen relativ von der aktuellen Rekorderposition rückwärts.

Das gefällt mir alles schon ganz gut soweit Muss noch etwas an der UI und UX arbeiten, aber der Anfang ist gemacht! Als nächstes lasse ich mir was einfallen wie ich erkannte Daten, IDs und deren Payloads dokumentieren kann. Meine Idee ist ein Log zu laden oder einen Live-Log zu starten und in dieser Ansicht (vielleicht nenne ich sie "ANALYZE") dann alle IDs untereinander zu sehen, jeweils mit der Anzahl der Payload-Bytes und ein paar exemplarischen Werten. Z.B. wenn ein Wert immer gleich ist, dann den Wert, wenn es sich ändert dann "*" oder den Wertebereich "1A-8E".

Dann die Möglichkeit der ID eine Bezeichnung zu geben (z.B. "BMS" oder "Battery Sensor"). Um die Bytes zu benennen brauche ich vermutlich was komplexeres, da es teilweise einzelne Bits, oder Bitgruppen sind die eine Funktion ausmachen.

Immer dann wenn ich etwas kommentiere soll das grün hinterlegt werden. Im Tool möchte ich dann als ID-Filter auch sowas wie "Hide known" haben um sich eben auf die noch nicht erkannten IDs/Daten konzentrieren zu können.

Die Idee muss jetzt in meinem Kopf und im Code etwas reifen...

Ab v0.6.3 gibt es nun den ANALYZE Tab. Dort werden alle im Log enthaltenen IDs ihrer Reihenfolge nach aufgelistet:

Die Anzahl Bytes pro ID sind dargestellt. Auch die Werte die dieses Byte im Log hat sind dargestellt, entweder statisch (grau) mit ihrem Wert, oder farbig mit ihrem Wertebereich und der Varianz (Anzahl der unterschiedlichen Werte im Log).

Klickt man eine ID an, expandiert sich die Ansicht und es kommen die analysierten Bytes/Bits zum Vorschein:

Hier kann man der ID direkt ein Label verpassen (z.B. "RSM" oder "Rain-Sensor-Module" oder "Regensensor") welches dann immer im Zusammenhang dieser ID verwendet wird. Weiterhin kann man mit [ EDIT ] einen Editor öffnen der es erlaubt spezifische Inhalte zu deklarieren:

Hier kann man der ID einen Namen geben und einen Kommentar erfassen. Die hell dargestellten Bits sind die die sich im Log geändert haben.

Man kann nun ein oder mehrere Bits markieren und mit "+ Add Field" eine Definition dafür hinzufügen. Oben im Beispiel habe ich das für ID 0x05 (Regensensor) mal gemacht:

• Das Bit 6 von Byte 0 ist "1" wenn der Wischerhebel auf Automatik steht
• Der Tageslicht-Sensor gibt auf Bit 1 von Byte 1 ein "0" wenn es Hell ist und ein "1" wenn es dunkel ist. Man könnte ihn jetzt "Night detector" nennen, dann würde die Bitlogik stimmen, nenne ich ihn aber "Daylight detector" dann muss ich die Logik negieren, was ich über die Formel getan habe.
• Der Regensensor gibt auf Bit 0 von Byte 0 eine "1" bei Regen

Bei ID 0x06 z.B. wird im Byte 0 mit den Bits 1 und 2 die am Wischerhebeldrehrad eingestellte Empfindlichkeit übermittelt, das kann dann so formuliert werden:

Die dokumentierten IDs sind dann anders dargestellt, sodass man sofort erkennt wo man noch ungeklärte IDs/Daten hat:

Ich werde daran noch feilen, aber im Prinzip stelle ich mir das so vor.