1. September 2010
PTC-Zuheizer bei Gigatronik: Wie ein Steuergerät sich vor Überstrom schützt
Ein elektrischer PTC-Zuheizer muss kräftig heizen — doch Überstrom kann Bauteile zerstören. Das Steuergerät hatte zudem nicht genug Hardware-PWM-Kanäle für alle vier Heizausgänge und lief ohne Betriebssystem in einem festen ~100-ms-Zyklus.
Robuste, sichere Steuergeräte-Software: vier Heizkanäle per Software-PWM ansteuern, den Strom überwachen und im Fehlerfall sicher reagieren — mit sauberer Fehlerklassifikation (heilbar vs. Werkstattfall) und dokumentierter Architektur.
Als Verantwortlicher für IOControl, Supervision und LIN: Überstromerkennung mit Hysterese & Selbstheilung, Enable-Criterias als zweites Sicherheits-Gate, CANdela-konfigurierte Fehlerspeicher-Logik sowie firmenintern genutzte UML-für-C-Designrichtlinien inkl. EA-Codegenerator. Der Zuheizer ging in Serie.
Manche Software fällt auf, wenn sie da ist. Gute Sicherheitssoftware fällt nur auf, wenn sie fehlt. Dieser Artikel handelt von so einer unsichtbaren Schicht — der Supervision eines PTC-Zuheizers — und von einer einzigen, sehr konkreten Frage: Was passiert, wenn zu viel Strom fließt?
Worum es geht: der PTC-Zuheizer
Ein PTC-Zuheizer ist eine elektrische Zusatzheizung für den Fahrzeuginnenraum. Gerade in Hybrid- und Elektrofahrzeugen fehlt die Abwärme des Verbrennungsmotors — also heizt man elektrisch, über PTC-Heizelemente. Das Steuergerät regelt die Heizleistung, indem es die Elemente pulsend ansteuert (Pulsweitenmodulation, PWM): Je höher das Tastverhältnis (Duty Cycle), desto mehr Wärme.
Das klingt harmlos — bis man bedenkt, dass hier ordentlich Strom fließt. Und Strom, der außer Kontrolle gerät, zerstört Bauteile oder wird gefährlich. Genau hier kam meine Arbeit ins Spiel.
Wer baut eigentlich die Software im Auto?
Bevor es technisch wird, eine Sache, die viele überrascht: Kaum jemand im Auto baut „alles selbst”. Automobil-Software entsteht in einer Zulieferkette aus mehreren Stufen (TIER 1, 2, 3). Vereinfacht:
Vom Kunden kam ein Lastenheft (was das Gerät können soll). Jeder von uns war für Module verantwortlich und schrieb dafür ein Pflichtenheft (wie wir es umsetzen) — das der Kunde für jeden ausgelieferten Softwarestand abnehmen musste. Diese Trennung aus Anforderung und Umsetzung, mit formaler Abnahme, ist bis heute die Grundmechanik guter Auftragsentwicklung.
Die Komponenten und der Datenfluss
Ich war Software-Komponentenverantwortlicher für drei Bausteine: LIN, Supervision und IOControl (unten grün). Damit das Fallbeispiel Sinn ergibt, muss man den Datenfluss verstehen — er ist überraschend elegant:
Der Ablauf in Worten: Die gewünschte Innenraumtemperatur kommt über den LIN-Bus. HeatingCtrl ist der Algorithmus, der daraus (abhängig von der Außentemperatur) die Heizanforderung ableitet und entscheidet, welche der vier PWMout-Kanäle mit welchem Duty gesetzt werden. Aber bevor HeatingCtrl das an PWMout schickt, fragt es die Supervision: Sind die Enable-Criterias erfüllt? Ist z. B. PWM4 gesperrt, steuert HeatingCtrl gegen — es legt den fehlenden Anteil auf PWM1–PWM3 (fällt auch PWM3 aus, auf 2 und 1). PWMout berechnet daraus den Duty Cycle und leitet ihn über meine IOControl an den Pin.
Ein Detail, das ich liebe: Der Mikrocontroller besaß nicht vier Hardware-PWM-Module. Deshalb setzte die PWMout-Komponente die Kanäle in Software um und griff dafür auf meine IOControl zu. Die gesamte Software lief ohne Betriebssystem in einem festen Zyklus von rund 100 ms, synchron, mit Interrupts. Und weil ein Software-PWM nie sauber schaltet, blieb der Duty Cycle praktisch immer zwischen ~5 % und ~95 % — nie ganz an, nie ganz aus.
Der Fall: Überstrom an PWMout4
Jetzt zum eigentlichen Lehrstück. Waren alle vier Kanäle aktiv, konnte der Gesamtstrom kritisch werden — besonders auf PWMout4. Die Supervision liest den Strom (über den ADC der IOControl) in jedem ~100-ms-Zyklus und reagiert. So greifen die Komponenten ineinander:
Warum eine Hysterese? Weil ein einzelner Schwellwert „flattert”
Hätte ich bei genau einer Stromschwelle geschaltet, wäre Folgendes passiert: Strom knapp über der Schwelle → Kanal aus → Strom sinkt minimal → Kanal an → Strom steigt → Kanal aus … ein hochfrequentes Flattern, das nichts heizt und alles belastet. Die Lösung ist eine Hysterese: Ich schalte bei 25 A ab, gebe aber erst bei 20 A wieder frei. Dazwischen liegt eine „Totzone”, in der der Zustand stabil bleibt.
Heilbar oder Werkstattfall? Die Fehler-Klassifikation
Der spannendste Teil ist nicht das Abschalten, sondern die Klassifikation des Fehlers. Die Supervision war an die Steuergeräte-Diagnose gekoppelt — Fehlerspeicher und UDS. Dort landeten Fehler aus der Vergangenheit, und je nach Fehlertyp leitete die Supervision daraus zur Laufzeit die Enable-Criterias ab. Über CANdela (von Vector) habe ich jeden Diagnose-Fehler konfiguriert — unter anderem, ob er heilbar ist:
- Überstrom 25–30 A → heilbar. Die Supervision trägt den Fehler in den Fehlerspeicher ein, sperrt PWMout4, und setzt ihn selbst zurück, sobald der Strom wieder unter 20 A liegt. Das Fahrzeug hilft sich selbst.
- Überstrom > 30 A → permanent. Jetzt ist etwas ernsthaft faul. Der Fehler wird latched — er lässt sich nicht im laufenden Betrieb zurücksetzen, sondern nur per Werkstatt-Diagnose (offboard). Sicherheit vor Komfort.
Modelliert habe ich das als Zustandsautomat:
Die Werkzeugkette
Fast die gesamte Diagnose- und Testwelt kam von Vector Informatik: CANoe (Restbussimulation & Test), CANape (Mess- & Kalibrierdaten), CANbedded (Kommunikations-Stack, ein Vorläufer heutiger AUTOSAR-Stacks) und CANdela (Diagnose-Konfiguration). Die zugehörigen Schulungen habe ich absolviert — und meine PIL-Testumgebung (Restbussimulation am Arbeitsplatz, inkl. Labornetzteil zur analogen Spannungssimulation) darauf aufgebaut.
Was man daraus mitnehmen kann
Auch wenn das ein Automotive-Projekt von vor über einem Jahrzehnt ist — die Prinzipien sind zeitlos und tauchen in moderner Software überall wieder auf:
- Hysterese statt harter Schwelle. Ein oberer und ein unterer Schwellwert stabilisieren das System — vom Thermostat bis zum Autoscaling in der Cloud.
- Entprellen (Debouncing). Ein Messwert ist nie sauber. Fehler erst nach stabiler Erkennung zu akzeptieren — und die Selbstheilung genauso zu entprellen — verhindert Fehlalarme.
- Graceful Degradation. Fällt PWM4 aus, verteilt HeatingCtrl die Last auf PWM1–3. Das System wird schwächer, aber es funktioniert weiter — dasselbe Prinzip wie ein Dienst, der bei Teilausfall in einen reduzierten Modus geht, statt komplett auszufallen.
- Defense in Depth. Die Enable-Criterias wirken zweimal: einmal in der Regellogik (HeatingCtrl) und unabhängig davon direkt an der IOControl. Zwei Gates, damit ein einzelner Logikfehler nicht durchschlägt.
- Fehler klassifizieren, nicht nur erkennen. „Heilbar vs. Werkstattfall” ist dieselbe Frage wie „Retry vs. Circuit-Breaker-open” in verteilten Systemen: Wann darf sich etwas selbst erholen, und wann muss ein Mensch eingreifen?
Und ganz nebenbei habe ich in diesem Projekt gelernt, wie viel Freude mir Software-Architektur macht: Aus reinem Arbeitseifer wurde ich für die UML-für-C-Designrichtlinien und die Architektur-Dokumentation im Enterprise Architect (Sparx) zuständig — inklusive eines konfigurierten Code-Generators, der Schnittstellen-Spezifikationen in C erzeugte und den ich dem ganzen Team samt Prozess zur Verfügung stellte. Der rote Faden zu heute ist unübersehbar: Wächter-Logik, Zustandsautomaten und saubere Schnittstellen haben mich nie wieder losgelassen.
Der Zuheizer ging übrigens in Serie.