Entwicklungsziel Zuverlässigkeit
Die MTBF ist nur ein Glied in der Kette
Fortsetzung des Artikels von Teil 2
Zuverlässigkeit auf der Systemebene
Neben der Betrachtung der Qualität der Bauteile sowie der Redundanz gibt es eine Reihe weiterer Optionen, mit denen sich die korrekte Performance unter Fehlerbedingungen oder bei Ausfallereignissen sichern lassen. Dazu zählen:
- Ausbreitung von gefährlichen Ausfallzuständen,
- Eingebaute Test-, Telemetrie- und Event-Logs zur Überwachung und Aufzeichnung der Systemfunktion,
- Equipment-Schnittstellen mit einzelnen Steckverbindern oder mit primären und redundanten Einheiten,
- kritische Befehlssequenzen (z.B. Auftrennung der »Arm«- und »Fire«-Befehle des Systems) sowie
- akzeptable Fehlerraten (BER, ECC) in Speichern und auf Datenverbindungen.
Im Rahmen von geltenden Regulierungen und Zertifizierungen ist oft eine Gefahrenanalyse durchzuführen, um potenzielle Gefahren, die beim Ausfall der Einheit auftreten können, zu erkennen und auszuschließen. Es liegt in der Verantwortung des Entwicklers, das angemessene Verhalten eines Produkts auf der Systemebene sicherzustellen, etwa durch geeignete Arretierungen und ähnliche Maßnahmen. Falls nötig, sollte man diese Schutz- und Korrekturfunktionen als genau definierte Anforderungen auf Subsysteme verlagern, um die Ausfallmodi richtig zu adressieren.
Die genaue Kenntnis des regulären Betriebszustandes des Equipments mit Reports oder Aufzeichnungen über dessen korrekten Status lässt sich auch als Prognosewerkzeug nutzen. Dies ermöglicht einen ausfallsicheren Betrieb und das Aufdecken von Fehlerursachen zur schnelleren Reparatur. Komplexe Systeme sollten auch umfassende Selbsttestfunktionen einschließen, entweder beim Einschalten oder kontinuierlich während des Betriebsablaufs. Folgende Parameter sollten ständig von On-demand-Testroutinen geprüft werden:
- Temperatur der Subsysteme und kritischer Komponenten,
- Strom, der aus der Steckdose gezogen wird,
- Spannungen an verschiedenen kritischen Punkten auf den Subsystemen,
- Reports über Schalterpositionen für primäre/redundante Signale für die Redundanz-Umschaltung und
- Ergebnisse für CRC, arthmetischer Über- oder Unterlauf von Berechnungen (Over-/Underflow), Signale außerhalb des korrekten Bereichs etc.
Die Ergebnisse solcher Tests lassen sich in Form von Zustandsberichten über eine Datenverbindung ausgeben oder in nichtflüchtigen Speichern (Flash oder FRAM) ablegen. Dies geschieht entweder mit Echtzeiterfassung oder einem Zähler, der diese Ereignisse mit einem Zeitstempel versieht, um den Fehler zu seiner Ursache zurückverfolgen zu können.
Achillesferse Steckverbinder
Jobangebote+ passend zum Thema
Besondere Beachtung beim Betrieb eines Systems in rauen Umgebungen gilt den Steckverbindern. Sie sind eine häufige Ausfallursache, da einzelne Anschlüsse im Steckverbinder unterbrochen sein können oder die Kabel durch mechanische Schocks und Vibrationen abfallen können. Also steigt die Zuverlässigkeit durch die Einführung redundanter Verbinder und Kabel. Beim Ausfall des primären Verbinders übernimmt die redundante Einheit (Bild 3). Allerdings steigt damit auch die Komplexität, wenn viele Module zu verbinden sind. Eine gängige Alternative ist der Einsatz von Steckverbindern, die speziell für raue Umgebungen ausgelegt sind, etwa nach MIL-STD 38999.
Ist das System oder Produkt für raue Umgebungen zum Beispiel mit starken elektromagnetischen Störungen vorgesehen, eignet sich eine »Arm and Fire«-Methodik bei Befehlen, die innerhalb des Systems über Datenbusse gesendet werden. In der Anordnung nach Bild 4 wird zunächst ein solcher Befehl zum Empfänger übertragen, der den Empfang bestätigt und einen Timeout startet. Der Empfänger gibt ein NACK-Kommando (Negative Acknowledge Character) aus, solange er nicht das Fire-Kommando erhält. Anderenfalls reagiert er mit einem ACK-Signal, bevor der Timeout abläuft. Erhält der Empfänger irgendein anderes Signal, gibt er NACK aus, und der Vorgang startet von neuem. Somit können unvollständige Signale, beeinträchtigt etwa infolge elektromagnetischer Störungen (EMI), keine unbeabsichtigten kritischen Befehle auslösen.
Ähnlich dem Arm-and-Fire-Prinzip kann man auch sicherstellen, dass alle Datenverbindungen und Speicher über geeignete Maßnahmen zur Fehlerdetektion und -korrektur verfügen, um die Daten zuverlässig zu übertragen und zu speichern. Die Wahl zwischen reiner Fehlerdetektion und Detektion plus Korrektur ist durch die finale Applikation bedingt. Es gibt allerdings eine Reihe von einsetzbaren Codes, die sich vom einfachsten bis zum kompliziertesten Fall skalieren lassen (Tabelle 2), wobei deren Schutzumfang mit der Komplexität des Codes skaliert.
| Verfahren | Fehlerdetektion | Fehlerkorrektur | Anmerkungen |
|---|---|---|---|
| Parity | X | maskierte Fehler möglich | |
| N of M | X | nicht geeignet für mehrere Bits | |
| CRC | X | gut geeignet für Burst-Fehler | |
| BCH | X | X | einfache Dekodierung |
| Hamming | X | X | einer der EDC-Codes |
| Reed Solomon | X | X | Spezialfall von BCH |
Tabelle 2: EDAC-Verfahren (Error Detection And Correction) – einfach bis komplex
- Die MTBF ist nur ein Glied in der Kette
- Zuverlässigkeit berechnen und erhöhen
- Zuverlässigkeit auf der Systemebene
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Software Engineering
Vom Zufallsprodukt zum planbaren Prozess
Partnerschaft mit Freescale
e2v verlängert Lebensdauer von 68k-Mikroprozessoren
Motorsteuerung
Mikrocontroller vs. FPGA
Intoino DIY Kits
Do-It-Yourself-Baukasten für das Internet der Dinge
Video
Xilinx' aktuelle Zynq-Architektur
Stromversorgungsdesign
Grundlagen zur Zuverlässigkeit von Netzteilen
Mit oder ohne Lüfter?
Grundlagen und Tipps zur Entwärmung von Industrie-PCs
