Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Kfz-Diagnose und Fahrzeugvernetzung – Softwarestände und Codierungen einordnen

QR-Code

Einleitung

Kfz-Diagnose und Fahrzeugvernetzung – Softwarestände und Codierungen einordnen

Zielgruppe: Ausbildung zur Kfz-Mechatronikerin oder zum Kfz-Mechatroniker

Lernzeit: 60–90 Minuten

Lernform: Systembilder, Videos, fiktive Diagnosedaten, Werkstattfälle und interaktive Aufgaben.

Du lernst, Softwarestände, Codierungen und Diagnoseinformationen miteinander zu vergleichen. Dabei erkennst Du mögliche Abweichungen, ohne vorschnell eine Änderung am Fahrzeug vorzunehmen.

Dein Lernziel: Einen Diagnosebefund fachlich begründen und entscheiden, welche Überprüfung als Nächstes sinnvoll und zulässig ist.

Sicherheitsregel: Keine Softwareupdates, Codierungen oder anderen Veränderungen ohne passende Herstellerfreigabe, betriebliche Berechtigung und freigegebene Arbeitsanweisung. Sämtliche praktischen Übungen finden ausschließlich offline mit fiktiven Daten oder in ausdrücklich autorisierten, isolierten Lehrumgebungen statt. Fremde Netze, reale Produktivsysteme und Kundendaten sind ausgeschlossen. Es werden keine Zugangsdaten benötigt und keine Fahrzeugdaten ungefragt übertragen.

Lerneinheit 1: Vernetzte Steuergeräte verstehen

Zeitbedarf: 10 Minuten

Systembild: Steuergeräte im Netzwerk

CAN-Bus im Modellauto. Quelle: Ernst Otto Derwald, Wikimedia Commons.

Ein modernes Fahrzeug enthält zahlreiche Steuergeräte. Diese tauschen Informationen über Datenbusse aus. Dazu gehören beispielsweise CAN-Bus, LIN-Bus und Automotive Ethernet.

Ein Gateway kann verschiedene Fahrzeugnetzsegmente verbinden.

Vereinfachte Darstellung der CAN-Vernetzung im Automobil.

Allgemeine Bus-Topologie, kein fahrzeugspezifischer Schaltplan.

Merke: Ein Fehler in einem Steuergerät kann Auswirkungen auf die Anzeige oder Funktion eines anderen Steuergeräts haben. Ein Netzwerkfehler ist aber nicht automatisch ein Softwarefehler.

Video: CAN-Bus verstehen

Siemens: CAN Bus Measurements. Englischsprachige Ergänzung zur Fahrzeugkommunikation.

Beobachtungsauftrag: Erkläre anschließend, warum zwei Steuergeräte Informationen austauschen müssen und welche Rolle eine gemeinsame Kommunikationsverbindung dabei spielt.

Basisaufgabe: Skizziere drei fiktive Steuergeräte an einem gemeinsamen CAN-Bus.

Begründetes Feedback: Eine fachlich sinnvolle Skizze zeigt mehrere Teilnehmer an einem Kommunikationsmedium. Eine Aneinanderreihung von Steuergeräten bedeutet nicht zwingend, dass deren Kommunikation immer nacheinander erfolgt.

Lerneinheit 2: Softwarestand, Codierung und Diagnose unterscheiden

Zeitbedarf: 10 Minuten

Steuergerät und Diagnosezugang

Beispiel eines älteren elektronischen Steuergeräts.

Schematischer Aufbau eines CAN-Knotens.

Schematische Belegung einer OBD-II-Diagnoseschnittstelle; keine Arbeitsanweisung zur Kontaktierung.

In der Fahrzeugdiagnose werden unter anderem Identifikationsdaten, Fehlerspeicher und Messwerte ausgewertet.

Information	Bedeutung	Diagnosefrage
Softwarestand	Installierte Programmversion	Welche Version ist vorhanden?
Codierung	Variantenspezifische Konfiguration	Welche Ausführung ist eingestellt?
DTC	Gespeicherter Diagnosehinweis	Welches Ereignis wurde erkannt?
Sollstand	Laut gültiger Herstellerinformation vorgesehener Stand	Welche Kombination ist zulässig?
Freigabe	Dokumentierte Zulässigkeit für den konkreten Anwendungsfall	Darf eine Maßnahme durchgeführt werden?

Wichtig: Eine höhere Versionsnummer ist nicht automatisch für jedes Fahrzeug geeignet. Auch eine Codierung darf nicht allein deshalb geändert werden, weil sie von einem anderen Fahrzeug abweicht.

ODX ist ein standardisiertes Format zur Beschreibung von Diagnosedaten. UDS bezeichnet standardisierte Diagnosedienste.

Basisaufgabe: Begründe den Unterschied zwischen Softwarestand und Codierung.

Begründetes Feedback: Eine gute Erklärung beschreibt die Softwareversion als Programmstand und die Codierung als Konfiguration einer zulässigen Variante. Beide können zusammenhängen, sind aber nicht identisch.

Lerneinheit 3: Herstellerfreigaben richtig einordnen

Zeitbedarf: 10 Minuten

Freigabe vor Veränderung

Vor einer realen Änderung sind die für das Fahrzeug geltenden Herstellerinformationen und betrieblichen Vorgaben zu prüfen.

Ein sicherer Werkstattablauf lautet:

Phase	Entscheidung
Identifizieren	Fahrzeug- und Steuergerätevariante zweifelsfrei feststellen
Dokumentieren	Istzustand und Fehlerspeicher sichern, soweit zulässig
Vergleichen	Softwarestand und Codierung mit passenden Sollangaben vergleichen
Prüfen	Herstellerfreigabe, Arbeitsanweisung und Berechtigung feststellen
Entscheiden	Maßnahme begründen oder Vorgang zur Klärung weitergeben
Kontrollieren	Nach einer autorisierten Maßnahme vorgeschriebene Prüfungen dokumentieren

UN-Regelung Nr. 156 betrifft Softwareupdates und Softwareupdate-Managementsysteme von Fahrzeugherstellern. Die verwandte UN-Regelung Nr. 155 behandelt die Cybersicherheit. Diese Regelungen ersetzen nicht die konkrete herstellerseitige Arbeitsanweisung.

ISO 14229 beschreibt Diagnosedienste. Für die Software-Update-Entwicklung ist außerdem ISO 24089 relevant.

Video: Moderne Fahrzeugdiagnose

Vector Informatik: Einführung in Service-Oriented Vehicle Diagnostics, SOVD. Vertiefung für fortgeschrittene Lernende.

Anwendungsaufgabe: Ein Diagnosesystem meldet, dass eine neuere Software verfügbar sein könnte. Darf sie deshalb sofort installiert werden?

Begründetes Feedback: Nein. Die Verfügbarkeit allein belegt weder die Kompatibilität noch die Freigabe. Erst der fahrzeugbezogene Abgleich mit den gültigen Herstellerinformationen ermöglicht eine sichere Entscheidung.

Lerneinheit 4: Der konkrete Ausbildungsfall

Zeitbedarf: 20 Minuten

Werkstattfall: Komfortfunktion ohne richtige Anzeige

Ausgangslage:

Ein vollständig fiktives Ausbildungsfahrzeug mit der Bezeichnung DemoCar D1 wird in einer isolierten Lehrumgebung untersucht.

Die Anzeige eines Türstatus funktioniert nicht zuverlässig. Ein Türsteuergerät wurde im Übungsfall zuvor ausgetauscht.

Die Auszubildende soll klären, ob die vorhandenen Software- und Codierungsinformationen zur dokumentierten Fahrzeugvariante passen.

Es dürfen keine Daten geschrieben, Steuergeräte umcodiert oder Updates durchgeführt werden.

Systembild des fiktiven Ausbildungsfahrzeugs

**Isoliertes Ausbildungsnetz**
Offline-Lehrrechner	→	Gateway G01
↓
Modelliertes Komfort-CAN-Netzsegment
B02	T03	A04
Komfortsteuergerät	Türsteuergerät	Anzeige

Didaktisches Systembild. Keine reale Fahrzeugtopologie, keine Pinbelegung und keine Verbindung zu einem Kundennetz.

Anschauliches Foto einer CAN-/Steuergeräteanordnung; nicht der fiktive Prüfstand.

Diagnosedatensatz A: Istzustand

Alle nachstehenden Kennungen, Softwarestände, Codierungen, Fehlertexte und Freigaben sind vollständig erfunden.

Steuergerät	Softwarestand	Codierung	Diagnosebefund
G01 Gateway	4.0	G0	Kein Eintrag
B02 Komfortsteuergerät	3.4	B7	Statussignal T03 zeitweise unplausibel
T03 Türsteuergerät	3.1	K6	Kein Eintrag
A04 Anzeige	2.0	A2	Kein Eintrag

Zusätzliche fiktive Prüfinformationen:

Bordnetzspannung: Momentaner Prüfwert 12,4 Volt am Lehrmodell.
Sensor: Der lokale Türzustand ändert sich im fiktiven Messdatensatz plausibel.
Fehlerspeicher: B02 dokumentiert ein sporadisches, nicht plausibles Statussignal.
Fahrzeugvariante: DemoCar D1 ist laut Lehrunterlage als Variante V2 gekennzeichnet.

Beachte: Ein momentan plausibler Messwert schließt einen sporadischen Leitungs- oder Kontaktfehler nicht aus.

Diagnosedatensatz B: Fiktive Freigabematrix

Die folgende Tabelle L-07 ist eine eigens für diesen Kurs erfundene Lehrreferenz. Sie ist keine echte Herstellerfreigabe und berechtigt nicht zu Arbeiten an realen Fahrzeugen.

Lehrvariante	T03 Sollsoftware	T03 Sollcodierung	B02 Sollsoftware	B02 Sollcodierung
V1	3.1	K6	3.4	B7
V2	3.2	K7	3.4	B7

Deine Fehlereingrenzung

Aufgabe A – Basis: Vergleiche die Istwerte von T03 mit den Sollwerten für V2.

Aufgabe B – Anwendung: Formuliere eine mögliche Ursache der fehlerhaften Anzeige und eine alternative Ursache.

Aufgabe C – Transfer: Entscheide, welche rein dokumentierenden Prüfschritte zulässig sind und weshalb Du zunächst keine Codierung veränderst.

Gestufte Hilfen

Hilfe 1 – Orientierung

Vergleiche zunächst nur das Türsteuergerät T03 mit der passenden Zeile der Freigabematrix.

Hilfe 2 – Eingrenzung

Achte getrennt auf Softwareversion, Codierung, Fehlerhinweis und lokale Signalwerte.

Hilfe 3 – Schlussfolgerung

Prüfe, ob die Daten eine Abweichung nachweisen oder bereits die eigentliche Fehlerursache beweisen. Das ist nicht dasselbe.

Musterlösung mit begründetem Feedback

Zu Aufgabe A:

T03 besitzt Softwarestand 3.1 und Codierung K6. Für die fiktive Fahrzeugvariante V2 sind jedoch 3.2 und K7 dokumentiert.

Feedback: Der Soll-Ist-Unterschied ist eindeutig. Daraus folgt allerdings noch nicht, welche der beiden Abweichungen für das Symptom verantwortlich ist.

Zu Aufgabe B:

Eine plausible Hypothese ist eine nicht zur Variante passende Kombination von Software und Codierung. Alternativ kommen Kommunikations-, Kontakt- oder Versorgungsprobleme infrage.

Feedback: Eine gute Diagnose unterscheidet Beobachtung, Hypothese und Nachweis. Fehlerspeichereinträge sind Hinweise und müssen mit weiteren Informationen bewertet werden.

Zu Aufgabe C:

Der vorhandene Datensatz wird dokumentiert, die Zuordnung der Steuergerätevariante geprüft und die Lehrfreigabematrix kontrolliert. Für reale Arbeiten müssten geeignete Herstellerunterlagen, Arbeitsauftrag und Berechtigung vorliegen.

Feedback: Eine sofortige Änderung wäre fachlich unbegründet und möglicherweise unzulässig. Die Freigabematrix des Kurses dient ausschließlich zum Lernen.

Lerneinheit 5: Zwei kurze Werkstattfälle

Zeitbedarf: 10 Minuten

Kurzfall A: Fehler trotz passender Software

In einem weiteren fiktiven Datensatz stimmen sämtliche Software- und Codierungsangaben mit der Lehrfreigabematrix überein. Trotzdem ist ein Kommunikationsfehler gespeichert.

Aufgabe: Begründe, warum ein Softwareupdate hier keine ausreichend belegte Erstmaßnahme ist.

Feedback: Übereinstimmende Softwareinformationen lassen zunächst andere Fehlerursachen in den Vordergrund rücken. Ein Kommunikationsproblem kann etwa durch physische Verbindungen entstehen. Die Ursache muss separat nachgewiesen werden.

Kurzfall B: Ein Steuergerät antwortet nicht

In einem isolierten Übungsnetz antwortet das fiktive Gateway nicht. Daher können weitere Steuergeräteinformationen nicht zuverlässig erfasst werden.

Aufgabe: Was ist wichtiger: eine vermeintlich neue Codierung oder die Überprüfung des Diagnosewegs?

Feedback: Zunächst muss die Verlässlichkeit des Diagnosewegs geklärt werden. Fehlende Kommunikationsdaten erlauben keinen gesicherten Vergleich der Softwarestände.

Video: Diagnosesysteme der Zukunft

Vector Informatik: SOVD Explorer. Beispiel für die Visualisierung moderner Diagnosefunktionen.

Video: Diagnose an einem Lehrsimulator

KG ProTech: Einblick in einen Fehlersimulator. Produktdemonstration als ergänzende Anschauung; keine Anleitung für Eingriffe in reale Fahrzeuge.

Transferfrage: Warum eignen sich simulierte Fehler besonders gut für die Ausbildung?

Begründetes Feedback: In isolierten Lehrumgebungen lassen sich Fehler reproduzierbar vergleichen, ohne reale Kundenfahrzeuge oder betriebliche Netze zu beeinträchtigen.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was beschreibt der Softwarestand eines Steuergeräts? (Die installierte Programmversion) (!Die Farbe des Steuergeräts) (!Die Fahrzeugmasse) (!Die Reifenabmessung)

Welche Aufgabe hat eine Codierung? (Die Konfiguration einer vorgesehenen Fahrzeugvariante) (!Die automatische Reparatur aller Fehler) (!Die Messung des Reifenluftdrucks) (!Die mechanische Einstellung der Lenkung)

Welche Funktion kann ein Gateway erfüllen? (Die Verbindung verschiedener Netzsegmente) (!Die Herstellung von Kraftstoff) (!Die Kühlung des Motors) (!Den Austausch der Bremsflüssigkeit)

Was beschreibt ODX? (Standardisierte Fahrzeugdiagnosedaten) (!Die Reifenprofiltiefe) (!Die Ölviskosität) (!Die Bremsbelagdicke)

Was beweist ein gespeicherter DTC zunächst? (Dass ein bestimmtes Diagnoseereignis erkannt wurde) (!Dass das Steuergerät immer defekt ist) (!Dass zwingend ein Update erforderlich ist) (!Dass jede elektrische Leitung unbeschädigt ist)

Was muss vor einer realen Softwareänderung geprüft werden? (Die passende Herstellerfreigabe und betriebliche Berechtigung) (!Nur die Batteriespannung) (!Nur die Bildschirmfarbe des Testers) (!Nur die höchste verfügbare Versionsnummer)

Welche Quelle dient im Ausbildungsfall als fiktive Sollreferenz? (Die Lehrfreigabematrix L-07) (!Ein beliebiger Internetkommentar) (!Eine fremde Fahrzeugdatei) (!Eine ungeprüfte Codierungsempfehlung)

Welche Angaben sind für T03 in der Lehrvariante V2 vorgesehen? (Softwarestand 3.2 und Codierung K7) (!Softwarestand 3.1 und Codierung K6) (!Softwarestand 4.0 und Codierung G0) (!Softwarestand 2.0 und Codierung A2)

Warum müssen zusätzliche Messwerte betrachtet werden? (Weil sie verschiedene Fehlerhypothesen eingrenzen können) (!Weil sie jede Reparatur überflüssig machen) (!Weil Fehlerspeicher grundsätzlich falsch sind) (!Weil sie automatisch eine Herstellerfreigabe erzeugen)

Welche Arbeitsweise ist für diesen Kurs vorgesehen? (Offline mit fiktiven und ausdrücklich autorisierten Testdaten) (!Ungefragter Zugriff auf fremde Fahrzeugnetze) (!Übertragung echter Kundendaten an beliebige Dienste) (!Unbefugte Änderung sicherheitsrelevanter Einstellungen)

Memory

Ordne jeweils einen Fachbegriff seiner passenden Bedeutung zu.

Gateway	Netzsegmentvermittlung
Softwarestand	Programmversionskennung
Codierung	Variantenfestlegung
DTC	Fehlerspeichereintrag
ODX	Diagnosedatenbeschreibung
Freigabematrix	Sollkombinationsnachweis

Drag and Drop

Ordne die richtigen Begriffe zu.	Fachbegriff
Versionskennung	Softwarestand
Variantenkonfiguration	Codierung
Fehlerhinweis	DTC
Datenmodell	ODX
Zulässigkeitsprüfung	Freigabematrix

Kreuzworträtsel

Gateway	Welche Komponente kann getrennte Fahrzeugnetzsegmente verbinden?
Codierung	Wie heißt die variantenspezifische Konfiguration eines Steuergeräts?
Software	Wie bezeichnet man Programme eines elektronischen Systems allgemein?
Datenbus	Wie nennt man ein gemeinsames Kommunikationsmedium für elektronische Teilnehmer?
Freigabe	Wie heißt die dokumentierte Zulässigkeit einer bestimmten Maßnahme?
Diagnose	Wie heißt die systematische Feststellung und Eingrenzung eines Fehlers?

LearningApps

Externe Suchergebnisse vor dem Einsatz fachlich prüfen. Keine echten Fahrzeug- oder Kundendaten in externe Anwendungen eingeben.

Lückentext

Die elektronische Einheit zur Verarbeitung von Fahrzeuginformationen heißt

.

Ein

kann unterschiedliche Kommunikationssegmente miteinander verbinden.

Die Kennzeichnung der installierten Programmversion nennt man

.

Die Konfiguration einer vorgesehenen Fahrzeugvariante erfolgt über die

.

Ein gespeicherter

liefert einen Diagnosehinweis und keinen vollständigen Ursachenbeweis.

Das standardisierte Format

beschreibt Fahrzeugdiagnosedaten.

Vor einer realen Schreiboperation ist die passende

zu prüfen.

Zum Vergleich erlaubter Kombinationen dient im Übungsfall die

.

Alle praktischen Aufgaben verwenden ausschließlich fiktive

.

Offene Aufgaben

Bearbeite die Aufgaben mit fiktiven Daten, Papiermodellen, eigenen Zeichnungen oder ausdrücklich autorisierten Offline-Lehrsystemen. Die Reihenfolge führt von Basiswissen über Anwendung zu eigenständigem Transfer.

Leicht – Basisaufgaben

Steuergeräte erkennen: Zeichne ein vernetztes Fahrzeugmodell mit drei Steuergeräten und kennzeichne deren Aufgaben.
Netzwerk erklären: Gestalte eine Bildkarte, die den Datenaustausch zwischen zwei Steuergeräten veranschaulicht.
Softwarestände vergleichen: Erstelle eine kurze Tabelle mit drei erfundenen Versionskennungen und erkläre ihre Bedeutung.
Codierung unterscheiden: Formuliere einen Beispielsatz, der den Unterschied zwischen Codierung und Softwareupdate verständlich erklärt.

Feedback für Basisaufgaben: Entscheidend ist die korrekte Trennung von Hardware, Software, Kommunikation und Variantenkonfiguration. Eine übersichtliche Zeichnung mit zutreffenden Begriffen ist wertvoller als eine komplexe, aber ungenaue Darstellung.

Standard – Anwendungsaufgaben

Diagnosebericht: Erstelle einen einseitigen Werkstattbericht zum fiktiven DemoCar-D1-Fall mit Befund, Hypothese und nächstem Prüfschritt.
Fehlerhypothesen: Entwickle drei mögliche Erklärungen für eine unplausible Statusmeldung und benenne jeweils einen geeigneten Nachweis.
Soll-Ist-Vergleich: Gestalte eine Prüftabelle, mit der verschiedene fiktive Fahrzeugvarianten sicher verglichen werden können.
Diagnosedaten visualisieren: Gestalte eine Infografik darüber, wie Diagnosedaten beschrieben, gelesen und ausgewertet werden.

Feedback für Anwendungsaufgaben: Gute Bearbeitungen verknüpfen mehrere Hinweise, nennen Unsicherheiten und begründen ihre Schlussfolgerung. Eine Abweichung allein darf nicht als abschließender Fehlernachweis ausgegeben werden.

Schwer – Transferaufgaben

Diagnosestrategie entwickeln: Entwickle einen Entscheidungsbaum, der zwischen Softwareabweichung, Codierungsabweichung und Kommunikationsproblem unterscheidet.
Freigabeprozess gestalten: Entwirf ein Freigabeformular mit Angaben zu Zuständigkeit, Dokumentationsstand, Kompatibilität und Abschlusskontrolle.
Datenschutzkonzept erstellen: Entwickle für einen Ausbildungsbetrieb Regeln zum Umgang mit Diagnoseprotokollen, personenbezogenen Daten und externen Diensten.
Lehrvideo produzieren: Produziere ein zwei- bis dreiminütiges Erklärvideo mit selbst gestalteten Systembildern und fiktiven Daten. Zeige, weshalb ohne Berechtigung und Herstellerfreigabe keine Codierung verändert wird.

Feedback für Transferaufgaben: Sehr gute Ergebnisse berücksichtigen technische Zusammenhänge, alternative Erklärungen, Sicherheitsgrenzen und nachvollziehbare Dokumentation. Entscheidend ist nicht die Zahl vorgeschlagener Änderungen, sondern die Qualität der begründeten Entscheidung.

Lernkontrolle

Die Lernkontrolle bewertet insbesondere Dein Verständnis der Zusammenhänge und die Fähigkeit zur begründeten Fehlereingrenzung.

Vernetzte Fehlerbilder: Erkläre anhand einer eigenen Zeichnung, wie ein Fehler eines Steuergeräts eine andere Anzeige beeinflussen kann, ohne dort selbst einen Defekt auszulösen.
Hypothesen prüfen: Vergleiche zwei plausible Ursachen des DemoCar-D1-Fehlers. Welche Informationen stützen oder schwächen die jeweilige Hypothese?
Versionsabweichung bewerten: Ein fiktives Steuergerät besitzt einen anderen Softwarestand als die Lehrreferenz. Begründe, weshalb dies allein noch keinen Updateauftrag rechtfertigt.
Prüfschritte priorisieren: Ordne die Dokumentenprüfung, den Soll-Ist-Vergleich und die Kontrolle vorhandener Diagnoseinformationen in eine begründete Reihenfolge.
Datenschutz anwenden: Eine Person möchte ein Diagnoseprotokoll aus einem realen Kundenfahrzeug auf eine private Plattform übertragen. Begründe, wie Du fachlich und datenschutzgerecht reagierst.
Diagnosegrenzen erkennen: Erkläre, warum ein momentan korrekter Spannungswert einen sporadischen Kontaktfehler nicht sicher ausschließt.

Lernnachweis

Für Deinen Lernnachweis erstellst Du ein kompaktes Diagnoseportfolio mit ausschließlich fiktiven Daten.

Es soll enthalten:

Systemübersicht: Eine beschriftete Darstellung des fiktiven Fahrzeugnetzwerks.
Steuergeräteidentifikation: Eine strukturierte Tabelle mit Softwareständen und Codierungen.
Vergleich: Die erkannten Abweichungen mit nachvollziehbarer Sollreferenz.
Fehlerhypothese: Mindestens zwei mögliche Erklärungen und ihre jeweilige Begründung.
Freigabeprüfung: Eine Erklärung, welche Unterlagen und Berechtigungen vor einer realen Änderung erforderlich wären.
Abschlussbericht: Eine fachlich begründete Entscheidung einschließlich der noch offenen Prüfungen.

Bewertung:

Kompetenz	Gewichtung	Qualitätsmerkmal
Fachbegriffe	20 %	Softwarestand, Codierung und Diagnosehinweis richtig unterscheiden
Datenanalyse	30 %	Ist- und Sollangaben nachvollziehbar vergleichen
Fehlereingrenzung	30 %	Hypothesen und alternative Ursachen begründen
Sicherheit und Dokumentation	20 %	Freigaben, Berechtigungen und Datenschutz berücksichtigen

Bestanden ist der Lernnachweis, wenn Du die Zusammenhänge fachlich richtig darstellst und keine unbegründeten oder unbefugten Änderungen als Lösungsweg empfiehlst. Die Lehrkraft legt die konkrete Bestehensgrenze fest.

OERs zum Thema

Wikipedia: Fahrzeugdiagnosesystem

Ergänzend:

Geprüfte fachliche Quellen

Fachliche Grundlage, überprüft am 8. Oktober 2026:

ASAM MCD-2 D / ODX: Offizielle Beschreibung standardisierter Fahrzeugdiagnosedaten einschließlich Diagnosediensten, Programmierung und Variantencodierung.
ISO 14229-1:2026: Offizielle Norminformation zu Unified Diagnostic Services. Der Volltext der Norm wird nicht übernommen.
Vehicle Certification Agency: Behördliche Informationen über UN-R155 und UN-R156 sowie Anforderungen an Cybersicherheit und Softwareupdate-Management.
ASAM MCD-2 NET: Offizielle Informationen über die Beschreibung von Fahrzeugnetzen und Netzwerktopologien.
Vector Informatik – SOVD: Technische Einführung in moderne serviceorientierte Fahrzeugdiagnose.

Einordnung: Normen und Standards erklären technische Rahmenbedingungen. Sie sind kein Ersatz für die aktuell gültigen, fahrzeugbezogenen Herstellerinformationen. Die fiktive Lehrreferenz L-07 besitzt keine rechtliche oder technische Gültigkeit außerhalb dieses Kurses.

Mediennachweise und Nutzungsrechte

Die verwendeten Wikimedia-Commons-Dateien wurden anhand ihrer Dateibeschreibungsseiten recherchiert. Die jeweiligen Lizenzbedingungen, insbesondere Namensnennung und gegebenenfalls Weitergabe unter gleichen Bedingungen, sind zu beachten.

Aufbau CANBUS Modellauto.png: Ernst Otto Derwald, CC BY-SA 3.0 DE.
Le bus CAN dans l'automobile.png: Florent.david.lille1, CC BY-SA 3.0.
BusNetwork.svg: GW_Simulations, gemeinfrei.
2008-04-17 ECU.jpg: Ildar Sagdejev, CC BY-SA 3.0.
CAN Node.png: EE JRW, CC BY-SA 4.0.
OBD-II female connector pinout.svg: Johan Zandin, CC0 1.0.
CANbus and ECU.JPG: Ahsanriaz6157, CC BY-SA 4.0.

YouTube-Medien:

Siemens – CAN Bus Measurements: Videolink aus einem Beitrag der offiziellen Siemens-Community.
Vector Informatik – Einführung in SOVD: Videolink aus der SOVD-Fachinformation von Vector.
Vector Informatik – SOVD Explorer: Videolink aus der offiziellen Produktinformation von Vector.
KG ProTech – Fault Simulator: Videolink aus der Darstellung eines Ausbildungs-Fehlersimulators bei EdTech Global.

Rechtehinweis: Die YouTube-Videos sind externe Einbettungen und werden nicht als frei lizenzierte OER ausgegeben. Eine Einbettung ist keine Erlaubnis zum Kopieren, Bearbeiten oder Weiterverbreiten. Verfügbarkeit und Einbettbarkeit können sich ändern. Bei der Übernahme der Wikimedia-Bilder auf andere Plattformen sind ihre individuellen Lizenzbedingungen einzuhalten.