Mangelnde Qualität kommt teuer
Embedded-Diagnostics für hochverfügbare Systeme
Unzuverlässige Systeme lösen nicht nur beim Anwender Frust aus, sondern können den Hersteller auch viel Geld kosten oder - noch schlimmer - seinen Ruf schädigen. Zuverlässigkeit entsteht jedoch keineswegs zufällig, sondern muss von Anfang an in ein System hineinentwickelt werden. Daher müssen Entwickler in ihre Systeme Funktionen integrieren, um dadurch beispielsweise Fehler im Labor nachvollziehen zu können.
Welche Anforderungen an die Verfügbarkeit eines elektronischen Systems gestellt werden, hängt davon ab, wie kritisch dessen Bedeutung für die jeweilige Anwendung ist. Beispielsweise muss bei einem Passagierflugzeug die ständige Verfügbarkeit bestimmter Echtzeit-Steuerungssysteme gewährleistet sein.
Fällt dagegen das Audiosystem an einem Sitzplatz aus, ist das lediglich eine kleinere Unannehmlichkeit. Bei einem öffentlichen Telefonnetz haben Unterbrechungen von Mobilfunkverbindungen oder ein fehlendes Freizeichen im Festnetz zwar Auswirkungen auf die Geschäftsergebnisse des Betreibers, sind aber nicht so kritisch wie ein fehlgeschlagener Notruf, bei dem es unter Umständen um Leben oder Tod geht. In einer Rechnerumgebung ist der vorübergehende Ausfall des Mailservers nur ein Ärgernis, der Absturz eines Börsenhandelssystems kann die Brokerfirma und ihre Kunden dagegen Millionen kosten.
Jobangebote+ passend zum Thema
Bild 1 veranschaulicht, dass sich Qualität, Zuverlässigkeit und Verfügbarkeit eines Systems direkt aufeinander auswirken. Qualität ist ein subjektiver Begriff, der beschreibt, ob ein Produkt oder Service die Erwartungen aus Benutzersicht erfüllt.
Als gängige Kenngröße für die Kosten, die einem Anbieter durch Qualitätsmängel entstehen, hat sich die »Cost of Poor Quality« (COPQ) etabliert. Diese Messgröße wurde vom IBM-Qualitätsexperten H. James Harrington in seinem 1987 erschienen Buch »Poor Quality Costs« [1] eingeführt.
In einer perfekten Welt mit perfekten Produkten und Serviceleistungen würde es diese Kosten gar nicht geben. Aber die COPQ können sehr hoch sein und sich auf die finanziellen Ergebnisse eines Unternehmens auswirken (z.B. Kosten für Garantiefälle).
Sie können sich aber auch nur indirekt bemerkbar machen und sind dann entsprechend schwieriger zu quantifizieren (z.B. Abwanderung von Kunden). Die COPQ sind ein wichtiges Management-Instrument für Unternehmensprogramme wie »Total Quality Management« (TQM) [2] oder »Six Sigma« [3].
Zuverlässigkeit ist wesentlich konkreter als COPQ. Zuverlässigkeitstechnik beschäftigt sich als Fachgebiet mit der Fähigkeit eines Systems, seine geforderte Funktion für einen bestimmten Zeitraum zu erfüllen. Zuverlässigkeit wird oft als mathematische Größe ausgedrückt, beispielsweise als MTBF (Mean Time Between Failure), und hängt indirekt mit der Qualität eines Systems zusammen.
Die MTBF hat aber auch mit der Systemverfügbarkeit zu tun. Im Allgemeinen wird diese durch die Komponenten- beziehungsweise Systemzuverlässigkeit als MTTR (Mean Time to Repair) definiert.
Zuverlässigkeit entsteht nicht zufällig
Zuverlässigkeit entsteht keineswegs zufällig, sondern muss von Anfang an in ein System hineinentwickelt werden. Elektronikhersteller kommen also nicht umhin, diesen Prozess als festen Bestandteil in ihr Gesamtkonzept zu integrieren, um die Zuverlässigkeit zu gewährleisten. Diese lässt sich mit einem dreigleisigen Konzept realisieren:
- Es werden Funktionen eingebaut, um Ausfälle und Fehlfunktionen des Systems zu verhindern.
- Im System gibt es Redundanzen für jeden »Single Point of Failure«.
- Es werden detaillierte Informationen zu den Fehlerursachen aufgezeichnet, wenn ein System ausfällt oder anderweitig nicht betriebsbereit ist. Irgendwann versagt jedes System den Dienst, deshalb ist eine proaktive Ausfall- und Fehlerdiagnose zur Sicherung der Zuverlässigkeit in das Programm zu integrieren.
Verfügbarkeit lässt sich leicht messen. Sie hat auch direkte Auswirkungen darauf, wie der Anwender die Qualität eines bestimmten Systems wahrnimmt. Verfügbarkeit ist die Umkehrfunktion der »Downtime« (Ausfallzeit) und wird oft in »Neunen« ausgedrückt.
Ein System, das eine Verfügbarkeit von »5 Neunen« aufweist, ist für die Zwecke eines Telefonnetzbetreibers geeignet. Es ist zuverlässig genug, um im Festnetz mit seinen Anforderungen an das Notrufsystem implementiert zu werden. Aufgabenkritische Systeme, wie sie beispielsweise im Aktienhandel, in der Luft- und Raumfahrttechnik sowie in der Medizin zum Einsatz kommen, erfordern eine Verfügbarkeit von »6 Neunen« oder mehr.
Ein Herzschrittmacher zum Beispiel darf maximal ein paar Sekunden im Jahr ausfallen, wenn überhaupt! Die genaue Analyse von Fehlerursachen wirkt sich auf die Qualität, Zuverlässigkeit und Verfügbarkeit aus. Systemdesigner können damit ihre Produkte oder Services verbessern, indem sie Fehlfunktionen in der Zukunft vermeiden.
Wenn ein Software- beziehungsweise Hardwarefehler zum Ausfall eines Systems führt, muss unbedingt seine Ursache ermittelt werden. Auch nach der vollständigen Wiederherstellung der Betriebsfähigkeit des Systems eignen sich diese Informationen zur Fehlerursache für Maßnahmen, um das Design des Systems oder eines seiner Supportprozesse zu verbessern und die Fehlfunktion ein für alle Mal abzustellen. Eine solche Prozessschleife wird während des gesamten Produktlebenszyklus‘ immer wieder durchlaufen.
Mit Fertigungstests lassen sich nicht alle möglichen Fehlermechanismen ermitteln. Im Feld herrschen unter Umständen Bedingungen, die Fehlfunktionen auslösen, die sich aber im Testlabor des Herstellers nicht immer eins zu eins reproduzieren lassen. Der Ausfall von Komponenten im praktischen Einsatz ist unvermeidbar. Manchmal wirkt sich das Versagen einer Komponente auf die Systemverfügbarkeit aus, manchmal aber auch nicht.
Darüber hinaus kann die Ursache für eine Fehlfunktion sofort erkennbar sein, aber auch das ist nicht immer der Fall. Grundsätzlich wird ein Servicetechniker - vielleicht auch der Anwender - versuchen, die Fehlerursache auf eine austauschbare Komponente (Field-Replaceable Unit, FRU) zu reduzieren, um diese dann durch ein funktionstüchtiges Austauschteil zu ersetzen.
Die Möglichkeiten des Technikers oder Anwenders, den Fehler in einer bestimmten FRU zu lokalisieren, hängen von der Granularität der Diagnosetechnik ab, die in das Gesamtsystem eingebaut ist. Das heißt, in dem System müssen sich Fehler gezielt einkreisen lassen. Leider machen Softwaredefekte die Lokalisierung von Fehlern besonders schwierig. Derartige Probleme können letztendlich auch auf Hardwarefehler zurückzuführen sein.
Häufig »hängt sich die Software auf«, sobald die Hardware ausfällt. So kennen die Windows-Anwender den »Blue Screen« nur allzu gut, der bei einem Hardwarefehler eines PC erscheint. In der Regel wird diese Situation durch Hardwareprobleme hervorgerufen, die dann die Systemsoftware abstürzen lassen.
Fehler oft nicht reproduzierbar
Angenommen, die Diagnose-instrumente des Systems kreisen eine Fehlfunktion auf eine FRU ein, dann wird diese in der Regel zur Überprüfung und Reparatur eingeschickt. Und an diesem Punkt schlägt oft die NTF-Problematik (No Trouble Found) zu: Die FRU wird im Labor des Herstellers getestet und erweist sich dabei als uneingeschränkt funktionstüchtig.
Zu diesem Zeitpunkt ist nicht bekannt, ob die Komponente fehlerhaft ist, ob sie der Anwender irrtümlich eingeschickt hat oder ob das Labor die Bedingungen nicht eins zu eins reproduzieren konnte, die zum Zeitpunkt der Fehlfunktion im Feld herrschten. Folglich wird die FRU-Komponente als NTF eingestuft und gilt damit als fehlerfrei.
Die Vorgehensweisen sind in der Praxis zwar unterschiedlich, aber oft werden NTF-Komponenten überholt und dann als Austauschteil im Rahmen von Garantieleistungen wieder an andere Kunden verschickt. Wenn also der Systemdiagnosemechanismus die wahre Fehlerursache nicht identifizieren kann, dann sorgt die FRU vielleicht bei einem oder mehreren weiteren Benutzern für Probleme.
Manche Hersteller legen eine Höchstzahl fest, wie oft eine FRU eingeschickt und als NTF eingestuft werden darf. Nach Überschreiten dieser Obergrenze wird die Komponente dann endgültig ausgemustert. Häufige Ursachen für NTFs sind:
- Der Servicetechniker kann das Problem nicht effektiv diagnostizieren, also entscheidet er sich kurzerhand dazu, eine oder mehrere FRUs einzuschicken. Oft werden mehrere FRUs eines Systems gleichzeitig getauscht, insbesondere dann, wenn der Techniker bei einem größeren Systemausfall unter massivem Zeitdruck steht.
- Der Techniker ist nicht in der Lage, zwischen Softwarepro-blemen und Hardwarefehlern zu unterscheiden.
- Intermittierende, also unregelmäßig auftretende Systemfehler.
In einer Studie hat das Beratungsunternehmen Accenture [4] festgestellt, dass in der Unterhaltungselektronikbranche die Quote der Retouren zwischen elf und zwanzig Prozent liegt und mehr als zwei Drittel davon als NTF eingestuft werden können. Diese Zahlen variieren zwar stark je nach Branche und Produkt, aber es steht außer Frage, dass NTFs und im Allgemeinen alle Systemfehler, deren Ursache nicht gefunden werden kann, sowohl die Hersteller als auch die Anwender enorm viel Geld kosten.
All die bisher angestellten Überlegungen gelten auch für hochintegrierte Halbleiter, denn die lassen sich in vielerlei Hinsicht mit elektronischen Baugruppen vergleichen. Dank dem immer größer werdenden Angebot an Gehäuse-optionen wie Multi-Chip-Module, SoC (System-on-Chip) und SiP (System-in-Package) lassen sich heute Prozessoren, Speicherbausteine, DSPs, SerDes und andere Bausteine in eine Komponente integrieren.
Diese Chips werden allmählich selbst zu Systemen und unterliegen damit den gleichen Qualitäts-, Zuverlässigkeits- und Verfügbarkeitsanforderungen wie Plattformen, die unter Umständen aus mehreren Leiterplatten und aus diesen komplexen Chips bestehen. Die meisten Halbleiter enthalten eine eingebettete Instrumentierung, um damit deren Zuverlässigkeit und Verfügbarkeit zu messen.
Diese Embedded-Instrumentierung, die sich zur Validierung des Chips selbst oder auch des gesamten Systems verwenden lässt, wird oft als BIST (Built-In Self Test) bezeichnet. Beispiele dafür sind Memory-BIST (MBIST), Logik-BIST (LBIST), I/O-BIST, Leistungs-/Temperatur-Überwachungskomponenten und andere.
- Embedded-Diagnostics für hochverfügbare Systeme
- Mangelnde Qualität kommt teuer
Lesen Sie mehr zum Thema
