Redundante Systeme mit PIC: Ausfallsicherheit für kritische Anwendungen

Redundante Systeme mit PIC sind ein bewährter Ansatz, wenn Ausfallsicherheit nicht nur „wünschenswert“, sondern zwingend erforderlich ist – etwa in Prozessanlagen, sicherheitsnaher Aktorik, der Energieverteilung, Pumpen- und Ventilsteuerungen, industrieller Messtechnik oder dauerhaft betriebenen Gateways. In solchen Anwendungen ist ein einzelner Mikrocontroller oft nicht das Problem, sondern ein einzelner Ausfallpunkt im Gesamtsystem: Spannungsregler, Quarz, Speicher, Kommunikationsbus, Sensorleitung oder ein Software-Hänger können ausreichen, um einen Prozess zu stoppen oder in einen unerwünschten Zustand zu bringen. Redundanz bedeutet dabei nicht automatisch „zwei Controller und fertig“. Wirkliche Ausfallsicherheit entsteht erst durch eine durchdachte Architektur: klare Fehlerannahmen, definierte Degradationsmodi, robuste Umschaltlogik (Failover) und nachvollziehbare Diagnose. PIC-Mikrocontroller eignen sich hierfür gut, weil sie in vielen Varianten verfügbar sind, bewährte Reset- und Überwachungsmechanismen bieten und sich in modularen Baugruppen einsetzen lassen. Dieser Beitrag zeigt praxisnah, wie Sie redundante PIC-Systeme planen, welche Redundanzformen sinnvoll sind, wie Voting und Cross-Monitoring funktionieren und welche typischen Stolperfallen (gemeinsame Ursachen, „Common-Mode“-Fehler, falsche Umschaltkriterien) Sie früh vermeiden sollten.

Was „Redundanz“ wirklich bedeutet: Begriffe und Zielgrößen

Redundanz wird im Engineering häufig mit „zwei Einheiten“ gleichgesetzt. Für kritische Anwendungen sollten Sie jedoch präziser unterscheiden:

• Verfügbarkeit: Wie wahrscheinlich ist es, dass das System zu einem Zeitpunkt funktionsfähig ist?
• Zuverlässigkeit: Wie lange läuft das System ohne Ausfall innerhalb eines Zeitraums?
• Funktionale Sicherheit: Wie wird ein sicherer Zustand erreicht, wenn Fehler auftreten?

Redundanz zielt primär auf höhere Verfügbarkeit und robustere Fehlerbeherrschung. Funktionale Sicherheit kann dadurch unterstützt werden, ist aber kein Automatismus. Eine gute, frei zugängliche Einordnung in Richtung Sicherheits-/Zuverlässigkeitskonzepte bietet die IEC-Seite zur funktionalen Sicherheit als Überblick: IEC: Funktionale Sicherheit – Überblick und Kontext.

Verfügbarkeit rechnerisch greifbar machen

Für ein grobes Verständnis hilft eine einfache Verfügbarkeitsnäherung mit MTBF (Mean Time Between Failures) und MTTR (Mean Time To Repair). Die stationäre Verfügbarkeit A lässt sich näherungsweise so ausdrücken:

$A=\frac{\mathrm{MTBF}}{\mathrm{MTBF}+\mathrm{MTTR}}$

Redundanz kann die effektive MTBF erhöhen oder die „wahrgenommene“ MTTR reduzieren (weil ein Failover ohne Serviceeinsatz erfolgt). Diese Formel ersetzt keine detaillierte Zuverlässigkeitsrechnung, ist aber nützlich, um den Einfluss schneller Umschaltung zu verstehen.

Fehlermodell zuerst: Welche Ausfälle sollen abgefangen werden?

Bevor Sie zwei PICs auf eine Platine setzen, definieren Sie, welche Fehler Sie mit Redundanz tatsächlich adressieren. Typische Kategorien:

• Transiente Fehler: EMV-Glitches, sporadische Bitfehler, kurze Versorgungseinbrüche, Bus-Timeouts.
• Systematische Fehler: Software-Bugs, Designfehler, falsche Konfigurationen.
• Random Hardware-Failures: Ausfall eines Regulators, eines Quarzes, Alterung, Lötfehler.
• Umgebungsbedingte Fehler: Temperatur, Feuchtigkeit, Vibration, Korrosion.

Ein wesentlicher Punkt: Redundanz hilft besonders gut gegen zufällige Hardwareausfälle und gegen viele transiente Fehler – deutlich weniger gegen systematische Fehler, wenn beide Kanäle dieselbe Ursache teilen (z. B. gleicher Bug, gleiche falsche Sensorinterpretation).

Redundanzformen für PIC-Systeme: Von „einfach“ bis hochverfügbar

Redundanz ist ein Spektrum. Je nach Kritikalität und Kostenrahmen sind unterschiedliche Ansätze sinnvoll.

Passive Redundanz (Cold Standby)

Ein zweiter PIC ist vorhanden, aber im Normalbetrieb inaktiv oder im Sleep. Er übernimmt nur, wenn der primäre Kanal ausfällt.

• Vorteile: geringer Energieverbrauch, geringere Alterung im Standby, weniger EMV-Emissionen.
• Nachteile: Failover dauert länger (Wake-up + Initialisierung), Standby-Logik muss zuverlässig sein.
• Typische Anwendung: batteriebetriebene Geräte, Logging-Systeme, seltene Schaltaufgaben.

Aktive Redundanz (Hot Standby / 1oo2)

Zwei PICs laufen gleichzeitig. Einer steuert, der andere überwacht („shadow“). Bei Fehlern wird schnell umgeschaltet.

• Vorteile: sehr schnelle Umschaltung, permanente Diagnose möglich.
• Nachteile: höherer Stromverbrauch, erhöhte Systemkomplexität, Synchronisation erforderlich.
• Typische Anwendung: Steuerungen mit kurzen zulässigen Ausfallzeiten, kontinuierliche Prozesse.

Voting-Architekturen (2oo3 / TMR)

Bei Triple Modular Redundancy (TMR) liefern drei Kanäle Ergebnisse, ein Voter entscheidet per Mehrheit (2-out-of-3). Das ist ein klassischer Ansatz, wenn nicht nur Ausfall, sondern auch falsche Ergebnisse erkannt werden müssen.

• Vorteile: robust gegen Einzelkanalausfälle, Fehler können maskiert werden.
• Nachteile: teuer, hoher Platz-/Energiebedarf, Voter selbst wird kritisch.
• Typische Anwendung: sehr kritische Systeme, in denen Fehlverhalten schlimmer ist als Abschalten.

Der unterschätzte Gegner: Common-Mode-Failures

Die größte Gefahr in redundanten Systemen sind gemeinsame Ursachen. Zwei PICs helfen wenig, wenn beide am selben Versorgungsregler hängen, denselben Quarz nutzen oder dieselbe EMV-Einkopplung abbekommen. Typische Common-Mode-Fehler sind:

• Gemeinsame Versorgungsschiene: Ein Reglerfehler legt beide Kanäle lahm.
• Gemeinsamer Takt/Quarz: Oszillatorprobleme betreffen beide.
• Gleiche Firmware-Basis: Derselbe Bug wirkt synchron in beiden Kanälen.
• Gleiche Sensorik ohne Plausibilisierung: falsche Messung wird doppelt „bestätigt“.
• Gemeinsame EMV-Ereignisse: Störung trifft beide gleichzeitig über Leitungen oder Masseführung.

Die Konsequenz ist klar: Redundanz muss auch auf Komponenten- und Layout-Ebene gedacht werden. Im Idealfall trennen Sie kritische Ressourcen: separate Regler, getrennte Massebereiche (sinnvoll und kontrolliert), getrennte Taktquellen oder zumindest interne Oszillatoren als Fallback.

Versorgungs-Redundanz: Zwei Strompfade, eine stabile Logik

Wenn Ausfallsicherheit im Fokus steht, beginnt Redundanz häufig bei der Versorgung. Ein robustes Konzept umfasst:

• Dual-Source-Eingang: z. B. Netzteil + Batterie, oder zwei unabhängige 24-V-Schienen.
• OR-ing-Konzept: Dioden-OR oder ideal-diode/Power-MUX-Lösungen, um nahtlos umzuschalten.
• Separate Regler pro Kanal: zumindest für die Logikversorgung, damit ein Reglerausfall nicht beide PICs trifft.
• Brown-out Reset pro Kanal: damit ein Kanal bei Unterspannung sauber resettiert statt „halb“ zu laufen.

Ein interner Brown-out Reset ist ein wichtiger Baustein, um undefiniertes Verhalten bei Spannungseinbrüchen zu vermeiden. Für die praktische Einordnung von BOR-Optionen bietet Microchip eine gut verständliche Übersicht: Microchip Developer Help: Brown-out Reset bei 8-bit PIC.

Cross-Monitoring: Zwei PICs, die sich gegenseitig überwachen

Eine sehr praxistaugliche Redundanzform ist Cross-Monitoring: Jeder Kanal überwacht den anderen über definierte Signale und Zustandsinformationen. Typische Bausteine:

• Heartbeat-Linien: Jeder PIC toggelt regelmäßig ein Signal; bleibt es aus, wird ein Fehler erkannt.
• State-/Mode-Exchange: Beide Kanäle tauschen Zustände und Prüfsummen über UART/SPI/I²C aus.
• Watchdog-Kaskade: Ein Kanal kann den anderen über einen externen Reset-Pin in einen definierten Zustand zwingen.
• Diagnose-Fenster: Überwachung nicht nur „lebt/lebt nicht“, sondern „lebt im richtigen Takt und Zustand“.

Warum ein Windowed Watchdog den Unterschied machen kann

Wenn ein PIC in einen „Runaway“-Zustand gerät (zu schnelle Schleife), kann ein normaler Watchdog wirkungslos werden, wenn er zu oft gefüttert wird. Ein windowed Watchdog verhindert das, indem er ein Mindest- und Maximalfenster vorgibt. Wo verfügbar, ist das in redundanten Systemen besonders wertvoll, weil „zu früh“ genauso ein Hinweis auf Fehlverhalten ist wie „zu spät“.

Eine praxisnahe Einführung zu Watchdog-Resets bei PICs bietet Microchip hier: Microchip Developer Help: Watchdog Timer Reset.

Failover-Logik: Wer darf wann übernehmen?

Die Umschaltlogik entscheidet, ob Redundanz im Ernstfall wirklich hilft. Eine robuste Failover-Strategie beantwortet mindestens diese Fragen:

• Wie wird ein Fehler erkannt? Heartbeat-Timeout, Plausibilitätsfehler, CRC-Fehler, Versorgungseinbruch, Selbsttestfehler.
• Wie wird entschieden? lokaler Entscheid (jeder Kanal entscheidet selbst) oder zentraler Voter/Arbiter.
• Wie wird übernommen? Umschalten von Ausgängen/Enable-Linien, Aktivierung eines Treiberpfads, Freigabe einer Kommunikationsrolle.
• Wie werden gefährliche Übergänge vermieden? keine doppelte Aktorik, keine kurzen Glitches, definierte Safe-Zustände.

Ein bewährtes Muster ist „One controls, one enables“: Der aktive PIC steuert zwar Logiksignale, aber die Leistungsausgänge werden über ein Enable-/Safe-Signal freigegeben, das nur ein Kanal zugleich besitzen darf. Dadurch verhindern Sie, dass im Fehlerszenario zwei Kanäle gleichzeitig Leistung treiben.

Voting in der Praxis: 1oo2, 2oo2, 2oo3 – Vor- und Nachteile

Voting-Konzepte werden oft aus dem Safety-Kontext übernommen. Für PIC-basierte Systeme sollten Sie sie pragmatisch betrachten:

• 1oo2 (one out of two): Einer von zwei Kanälen darf eine Aktion auslösen. Hohe Verfügbarkeit, aber Risiko falscher Aktivierung, wenn ein Kanal „spinnt“.
• 2oo2 (two out of two): Beide müssen zustimmen. Sehr sicher gegen Fehlaktivierung, aber geringere Verfügbarkeit (ein defekter Kanal blockiert).
• 2oo3 (two out of three): Mehrheit entscheidet. Hohe Robustheit, aber hoher Aufwand.

Für viele industrielle Anwendungen ist ein hybrider Ansatz sinnvoll: Kritische Aktionen benötigen 2oo2-Freigaben (z. B. Ventil öffnen), weniger kritische Zustandsmeldungen dürfen 1oo2 sein (z. B. Diagnose-LED, Logging). Das reduziert Overhead, ohne Sicherheit zu verschenken.

Synchronisation und Datenkonsistenz: Parameter, Zustände, Zeitskalen

Redundante Systeme scheitern häufig nicht am Failover selbst, sondern an inkonsistenten Zuständen danach. Wenn der Standby-Kanal übernimmt, muss er die relevanten Parameter, Kalibrierwerte und Zustandsautomaten korrekt kennen.

• Konfigurationsdaten redundant speichern: z. B. doppelt in EEPROM/Flash mit CRC und Versionsnummer.
• Zustände regelmäßig spiegeln: Standby erhält zyklisch „State Snapshots“ (mit Sequenznummern).
• Deterministische Zeitbasis: klar definieren, wie Timerstände, PWM-Phasen oder Kommunikationsslots behandelt werden.
• Re-Sync nach Umschaltung: Kommunikationspartner müssen erkennen, dass ein Failover stattgefunden hat (z. B. Session-ID, Restart-Flag).

CRC als einfacher, wirkungsvoller Baustein

Eine Prüfsumme über Konfigurationsdaten oder Zustandsblöcke reduziert das Risiko, dass ein Kanal mit korrupten Parametern startet. Die CRC kann simpel gehalten werden, Hauptsache sie ist konsequent eingesetzt. In vielen PIC-Familien gibt es zudem Hardwareunterstützung oder etablierte Softwarebibliotheken; für Protokolle ist CRC ohnehin Standard.

Redundanz und EMV: Warum zwei Controller nicht automatisch robuster sind

In rauen Umgebungen sind EMV-Ereignisse eine der häufigsten Ursachen für sporadische Fehlfunktionen. Zwei PICs auf derselben Platine können von derselben Störung gleichzeitig betroffen sein, besonders wenn:

• Störung über gemeinsame Leitungen kommt: Versorgung, I/O, Kommunikationsbus.
• Masseführung ungünstig ist: Ground Bounce wirkt auf beide Kanäle.
• Schutzbeschaltung fehlt: ESD/Transienten gelangen ins Board, bevor sie abgeleitet werden.

Der praktische Schluss: Redundanz muss mit EMV-gerechtem Design kombiniert werden. Hilfreich ist dafür ein kompakter Leitfaden zu Board-Level-EMC-Prinzipien, der sich gut auf Mikrocontroller-Systeme übertragen lässt: AN2321: Designing for Board Level EMC (PDF).

Test- und Nachweisstrategie: Redundanz ist nur so gut wie ihr Testplan

Ein redundantes System muss nicht nur im Normalbetrieb funktionieren, sondern vor allem im Fehlerfall vorhersehbar reagieren. Ein belastbarer Testplan umfasst:

• Fehlerinjektion: Heartbeat aussetzen, Bus blockieren, falsche Sensorwerte einspeisen, RAM-Fehler simulieren.
• Versorgungsstörungen: Brown-out provozieren, kurze Dips, Lastsprünge, Start/Stop von Motoren.
• Timing-Tests: Worst-Case-Ausführungszeiten, Interrupt-Stürme, Kommunikationsjitter.
• Failover-Metriken: Umschaltzeit, Zustandstreue, Ausgangsglitches, Wiederanlaufverhalten.
• Langzeittests: Wochenlauf, Temperaturzyklen, Vibration, Feuchte – um „rare events“ sichtbar zu machen.

In regulierten Bereichen (z. B. Medizintechnik) müssen diese Tests zudem mit Risikoargumentation und Traceability verbunden sein. Der Überblick zur funktionalen Sicherheit kann helfen, die Denkweise zu strukturieren: IEC: Funktionale Sicherheit – Grundlagen.

Typische Architekturbausteine für redundante PIC-Steuerungen

• Dual-Power-Konzept: getrennte Regler, OR-ing, getrennte Entkopplung je Kanal.
• Safe-/Enable-Signal: nur ein Kanal darf Leistungsausgänge freigeben.
• Cross-Check-Schnittstelle: UART/SPI mit CRC und Sequenznummern, plus Heartbeat-Linien.
• Unabhängige Überwachung: interner WDT + ggf. externer Supervisor oder externer Watchdog.
• Robuste Reset-Strategie: BOR aktiv, definierte Startzustände, Reset-Ursachen logging.
• Degradationsmodus: bei Teilausfall weiterarbeiten mit reduzierter Funktion statt Totalausfall.

Stolperfallen, die in der Praxis besonders häufig sind

• Redundanz ohne Ressourcen-Trennung: beide PICs hängen am selben Regler und sterben gemeinsam.
• Unklare Umschaltkriterien: System toggelt zwischen Kanälen („Flapping“), weil Grenzwerte zu knapp sind.
• Beide treiben Ausgänge: fehlende Hardware-Arbitrierung führt zu Kurzschluss oder gefährlichen Glitches.
• Standby ist nicht wirklich bereit: übernimmt, aber hat veraltete Parameter oder keinen gültigen Zustand.
• Gleicher Bug in beiden Kanälen: identische Firmware ohne Diversität kann systematische Fehler nicht abfangen.
• Fehlende Diagnose: Failover passiert, aber niemand weiß warum; Service und Qualitätssicherung bleiben blind.

Diversität als Ergänzung: Zwei PICs, aber nicht „zweimal dasselbe“

Wenn Sie systematische Fehler reduzieren wollen, kann Diversität helfen:

• Software-Diversität: unabhängige Implementierung kritischer Algorithmen (z. B. Grenzwertlogik) oder unterschiedliche Toolchains/Compileroptionen.
• Hardware-Diversität: unterschiedliche PIC-Familien oder unterschiedliche Taktquellen/Versorgungspfade.
• Sensor-Diversität: zwei Messprinzipien oder Sensoren unterschiedlicher Technologie (Plausibilitätsvergleich).

Diversität ist kein Muss für jedes Projekt, aber ein starker Hebel, wenn die Fehlerdomäne nicht nur „random“, sondern auch „systematisch“ ist.

Weiterführende Informationsquellen

• IEC: Funktionale Sicherheit – Überblick
• Microchip Developer Help: Watchdog Timer Reset
• Microchip Developer Help: Brown-out Reset (BOR)
• AN2321: Designing for Board Level EMC (PDF)
• ISO 14971: Risikomanagement für Medizinprodukte (Einordnung von Risiko-/Fehlermodellen)

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.