Site icon bintorosoft.com

Redundante Systeme mit PIC: Ausfallsicherheit für kritische Anwendungen

Red Snapper

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:

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 = MTBF MTBF+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:

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.

Aktive Redundanz (Hot Standby / 1oo2)

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

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.

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:

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:

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:

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:

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:

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.

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:

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:

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

Stolperfallen, die in der Praxis besonders häufig sind

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

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

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

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:

Lieferumfang:

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.

 

Exit mobile version