Vorab ist zu diesem Projekt zu sagen, dass es noch in einem frühen Prototypen-Status ist! Aufgrund der aktuellen Winterbedingungen war es mir bisher noch nicht möglich, die Funktion des Systems während einer Fahrt zu testen. Alles ist also eventuell noch sehr instabil und vielleicht noch fern von einem endgültigen Stand.

Ausschlaggebender Grund für dieses Projekt war eine abenteuerliche Tour mit dem Motorrad durch die Sahara im Süden von Marokko. Nicht zuletzt aufgrund von mangelndem Talent beim Befahren von Tiefsand (soviel Ehrlichkeit muss sein...) befand sich das Motorrad auf weiten Strecken dieser Tour im gefühlt permanenten Zustand der bevorstehenden Überhitzung (ebenso wie der Fahrer selbst). Zumindest lief der Lüfter bedingt durch die langsame Fahrt im Sand bei gleichzeitig hohem Leistungsabruf und hoher Außentemperatur im Dauerbetrieb. Nun hat die F800 eine Temperaturanzeige im Cockpit, diese ist aber nur als sehr grobe Balkenanzeige ausgelegt - eine Einschätzung, ob der Lüfter nun ausreichend kühlende Wirkung hat oder nicht fand ich zumindest sehr zweifelhaft. Eine echte Anzeige mit der Angabe von Celsius-Graden wäre mir in dem Moment deutlich lieber gewesen.
Und auch schon als ich vor Jahren die Analyse der Benzinpumpenprobleme betrieben habe (sie Artikel zum Fernmess-Controller), hätte ich als zusätzlichen Messwert gerne den Benzindruck gehabt.
Genau solche Betriebswerte messen moderne Fahrzeuge natürlich permanent und stellen diese auch über die Diagnoseschnittstelle des Fahrzeugs zur Verfügung. Was auf den ersten Blick einfach klingt, ist aber in der Tat ein komplexeres Unterfangen, da hier viele verschiedene Standards zum tragen kommen (OBD-II, UDS, ISO14229, ISO14230, ISO15031, KWP2000, ...), durch die man sich durchkämpfen muss. Einige der Daten (alles was Abgas-relevant ist, OBD-II) sind standardisiert, d.h. es ist klar wo im Fahrzeug man welche Daten abrufen kann und wie diese zu interpretieren sind. Bei anderen Daten (UDS, Unified Diagnostic Services) ist es zwar standardisiert, wie man Daten abrufen kann, aber welche Daten das dann sind und wie man sie zu interpretieren hat, ist vom Fahrzeughersteller frei festlegbar und in der Regel auch nicht veröffentlicht. D.h. diese Informationen muss man sich im Einzelnen selbst erarbeiten, sei es durch Recherche oder Ausprobieren.
Bei der F800 meines Baujahrs erfolgt die Kommunikation mit dem Diagnosesystem des Motorrads über eine K-Line Schnittstelle. Das ist im Wesentlichen eine ein-drahtige, asynchrone, half-duplex Verbindung mit dem Motorsteuergerät. Um Diagnosedaten zu empfangen, richtet man also über diese K-Line einen Request an das Motorsteuergerät, das diesen Request prüft und dann entweder direkt beantwortet oder den Request auf dem CAN-Bus des Fahrzeugs an das entsprechende Steuergerät (z.B. ABS, ZFE, Kombiinstrument, etc.) weiterleitet, von dort eine Antwort empfängt und wiederum an den Requester (also ein Diagnosegerät oder eben meinen Bordcomputer) zurückliefert.
Das Motorsteuergerät stellt also eine Art Gateway-Funktion zur Verfügung, das alle Anfragen erst auf Korrektheit und Plausibilität prüft, bevor es irgendwelche Messages in den CAN-Bus sendet. Dadurch ist einigermaßen sichergestellt, dass man auch mit einer selbstgebauten Hardware wie meiner keine schädlichen oder gar gefährlichen Aktionen im Fahrzeug auslösen kann - ein großer Vorteil gegenüber der Option, den Eigenbau-Bordcomputer direkt mit dem CAN-Bus zu verbinden (siehe z.B. meine Projekte zum CAN-FD Monitor/Sniffer oder dem CAN-Bus-Tracker), was eine andere Möglichkeit zur Realisierung eines solchen Info-Dashboards gewesen wäre.

Mein System besteht aus zwei Einheiten. Zum einen ist es eine zentrale Recheneinheit, die unter der Sitzbank und nahe der Diagnoseschnittstelle des Motorrads installiert ist. Über die Diagnoseschnittstelle (der klobige originale Diagnosestecker wurde gegen einen eigenen kleineren getauscht) erhält das gesamte System die Stromversorgung über eine geschaltete Batteriespannung und natürlich den Zugang zu dem K-Line Interface des Motorrads.

Zentrale Recheneinheit unter dem Sitz mit Anschluss an die Diagnoseschnittstelle

Diese Zentrale ist über eine bidirektionale Schnittstelle mit der zweiten Einheit, der Anzeige- und Bedienkonsole verbunden.

Anzeige- und Bedienkonsole mit 16-Character-Display und 2 Bedientasten

Aktuell werden folgende Betriebswerte ermittelt bzw. errechnet und sind anzeigbar:

• Eingelegter Gang
• Fahrzeuggeschwindigkeit in km/h
• Drehzahl des Motors in U/min
• Gefahrene Distanz in km
• Fahrzeit in Minuten
• Durchschnittsgeschwindigkeit in km/h
• Kühlmittel-Temperatur in °C mit Steigend/Sinkend/Bleibend-Indikator
• Außenluft-Temperatur in °C
• Luftdruck in hPa
• Batteriespannung in V
• Benzinstand in Litern
• Kraftstoffdruck in bar
• Zündwinkel in Grad
• Öffnungsgrad der Drosselklappe in %
• Anliegendes Drehmoment in Nm bzw %
• Abgerufene Motorleistung in PS
• Angesaugte Luftmasse in kg/h
• Lambda des Lambda-Sensors
• Anzahl der Fehler ("DTC") im Fehlerspeicher für jedes Steuergerät

Als Prozessor für die Zentral habe ich einen PIC18F14K50 gewählt. Sonderlich viel spezielle Peripherie ist gar nicht nötig - lediglich ein UART und einige GPIOs. Als Transceiver für das K-Line-Interface verwende ich einen TLIN1027, der normalerweise eigentlich für den Betrieb von LIN-Bussen gemacht ist. Aber K-Line und LIN ähneln sich vom physikalischen Interface so sehr, dass er auch für meine Zwecke gut tauglich ist. Die Spannungsaufbereitung erfolgt über einen gewöhnlichen 5V Linearregler (NCP1117-5). Nach dem Abschalten des Motorrads (VBat) läuft das System noch eine kurze Zeit aus dem Puffer-Kondensator C6 weiter. Der Prozessor erfährt von der abgeschalteten VBat über Pin16 (INT) und nutzt die kurze Zeit, um in einem Interrupt volatile Daten (z.B. gefahrene Strecke und Zeit) im EEPROM des Prozessors abzulegen, um sie beim nächsten Start des Systems weiter nutzen zu können.
Der Connector JP5 verbindet mit 4 Pins die Zentrale mit der Konsole, zum einen über eine bidirektionale UART-Schnittstelle U_RX und U_TX, zum anderen kann die Zentrale die Konsole über IC6 ein- und ausschalten. Die restlichen 2 Pins von JP5 sind noch für eine eventuell spätere Nutzung reserviert. Über RC4 des Prozessors könnte ich damit in einem halb-duplex-Verfahren mit einer zusätzlichen externen Hardware kommunizieren (mir schwebt z.B. ein Schräglagensensor basierend auf einem 6-Achsen Beschleunigungssensor vor) und deren Messdaten direkt in die Anzeige dieser Infozentrale integrieren.

Schaltplan der Zentraleinheit unter dem Sitz

PIC-Code der Zentraleinheit

Die Konsole besteht im Wesentlichen aus einem kleinen PIC16F54, der mit der Zentrale über das UART-Interface kommuniziert, 2 Tasten überwacht und entsprechend das Display FDCC0802 bedient.

Schaltplan der Anzeige- und Bedienkonsole am Lenker

PIC-Code der Anzeige- und Bedienkonsole

Einige Screenshots von dem System

Die Hardware der Zentraleinheit habe ich von Anfang an dahingehend ausgelegt, dass sie auch für die Analyse des Diagnosesystems des Motorrads verwendet werden kann. Wie anfangs erwähnt, müssen viele der im Motorrad vorhandenen Betriebsdaten eigens ermittelt werden, da sie nicht oder nur unvollständig vom Hersteller offengelegt sind. Mit einem angepassten PIC-Code wird die Zentrale in Verbindung mit einem PC zu einem konfigurierbaren Diagnose-Tester, bzw. einem Tester-Emulator.
Die UART-Schnittstelle an der normalerweise die Konsole angeschlossen ist, wird in diesem Setup zu einer Kommunikationsschnittstelle zum PC, über den man flexibel eigene Request-Frames erzeugen kann, um die entsprechende Response vom Motorrad zu analysieren.

Screenshot der PC-Software des Tester-Emulators

PIC-Code des Tester-Emulators

Eine andere Anwendung der Zentrale ist die, dass sie auch die Rolle des Motorrads einnehmen kann - ein Motorrad-Emulator sozusagen. Der Sinn dahinter besteht darin, die Software der Zentraleinheit auch im warmen Labor testen zu können, ohne jedes mal in die Garage zum Motorrad zu müssen.
Man schaltet also zwei Systeme gewissermaßen "gegeneinander", eines davon mit der normalen PIC-Software der Zentraleinheit und einer angeschlossenen Konsole, das andere System hat den PIC-Code des Motorrad-Emulators programmiert und ist über die UART-Schnittstelle mit einem PC verbunden. Dieses zweite System täuscht damit der Zentraleinheit vor, dass es mit einem Motorrad verbunden wäre. Über den PC lassen sich dann einzelne Responses erzeugen, deren Auswirkungen in der Zentrale analysiert werden können..

Screenshot der PC-Software des Motorrad-Emulators

PIC-Code des Motorrad-Emulators

PC-Code für den K-Line-Analyzer (Tester- und Motorrad-Emulator)

Eine weitere wichtige Analyse- und Debug-Hardware für die Arbeiten am K-Line Interface ist mein K-Line Splitter und Sniffer.