no way to compare when less than two revisions
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
— | computertechnik:begriffe_fehlersuche [2022/05/25 14:12] (aktuell) – angelegt - Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ===== Begriffe der elementaren Fehlersuche ===== | ||
+ | |||
+ | |||
+ | ==== Verifizierung ==== | ||
+ | |||
+ | Verifizieren bedeutet, nachzuweisen, | ||
+ | |||
+ | ==== Lokalisierung ==== | ||
+ | |||
+ | Lokalisieren bedeutet, die Fehlerquelle näher zu bestimmen. Meist handelt es sich darum, die zwecks Fehlerbeseitigung auszutauschende Hardware (Funktionseinheit oder Bauelement) aufzufinden. | ||
+ | |||
+ | **Prüfen und Messen** bedeutet, gemessene oder beobachtete Werte oder Verhaltensweisen (Istwerte, Istverhalten) mit Sollwerten bzw. einem Sollverhalten zu vergleichen. Das Prüfen liefert letzten Endes Ja-Nein-Aussagen. Das Messen ist ein quantitatives Prüfen. Es liefert zahlenmäßige Messwerte. | ||
+ | |||
+ | |||
+ | Ein Fehlerverdacht (s. weiter unten) ergibt sich dann, wenn der Istwert oder das Istverhalten vom Sollwert oder Sollverhalten abweicht. Manchmal wird diese Abweichung automatisch erkannt (Testautomaten (im Fertigungsbetrieb), | ||
+ | * die Dokumentation der jeweiligen Hard- und Software, | ||
+ | * die einschlägigen Standards, | ||
+ | * das allgemeine Fachwissen. | ||
+ | |||
+ | |||
+ | **Testen** bedeutet, eine fehlerverdächtige Einrichtung auf Funktionsfähigkeit zu überprüfen oder nachzuweisen, | ||
+ | |||
+ | |||
+ | ==== Verifizierungstest ==== | ||
+ | |||
+ | Ein Verifizierungstest soll eine Ja-Nein-Aussage zur Funktionsfähigkeit liefern. | ||
+ | |||
+ | ==== Lokalisierungstest ==== | ||
+ | |||
+ | Ein Lokalisierungstest soll Aussagen liefern, die zur Bestimmung der Fehlerursache oder der austauschbaren Einheit (Field-Replaceable Unit FRU) nutzbar sind. | ||
+ | |||
+ | ==== Dauertest ==== | ||
+ | |||
+ | Ein Dauertest ist ein Verifizierungs- oder Lokalisierungstest, | ||
+ | |||
+ | ==== Selbsttest ==== | ||
+ | |||
+ | Mit Selbsttest bezeichnet man die Überprüfung einer Hardware durch eingebaute Testvorkehrungen. Dabei kann es sich um residente Programme oder Mikroprogramme handeln, aber auch um besondere Hardware, die Prüfabläufe selbsttätig steuert und überwacht (Build-in Self Test BIST). | ||
+ | |||
+ | **Diagnose** ist der – aus der Medizin allgemein bekannte – Oberbegriff für das genaue | ||
+ | Bestimmen der Fehlerursache. | ||
+ | |||
+ | // | ||
+ | |||
+ | |||
+ | ==== Differentialdiagnose ==== | ||
+ | |||
+ | Der Begriff stammt aus der Medizin und klingt ziemlich abschreckend. Es ist aber etwas Einleuchtendes gemeint: Eine Einrichtung besteht aus mehreren Komponenten. Um die fehlerverdächtige Komponente zu bestimmen, wenden wir Tests an, von denen jeder eine einzelne Komponente oder auch einige von ihnen prüft. Jeder Test liefert eine Ja-Nein-Aussage bezüglich der von ihm geprüften Komponenten (Verifizierungstest). Zeigen mehrere Tests Fehler auf, so ergeben sich die verdächtigen Komponenten als Durchschnitt der Menge aller Komponenten, | ||
+ | |||
+ | ==== Probleme und Fehler ==== | ||
+ | |||
+ | " | ||
+ | |||
+ | ==== Bleibender oder harter Fehler ==== | ||
+ | |||
+ | Der Fehler ist dauernd vorhanden und tritt unter gleichen Betriebsbedingungen | ||
+ | immer wieder auf. Weitere Fachbegriffe: | ||
+ | |||
+ | ==== Flüchtiger oder Aussetzfehler ==== | ||
+ | |||
+ | Der Fehler ist nur zeitweise nachweisbar, | ||
+ | |||
+ | |||
+ | ==== Latenter (verborgener) Fehler ==== | ||
+ | |||
+ | Das ist ein Fehler, der zwar vorhanden ist, der sich aber nur unter bestimmten Umständen bemerkbar macht. Treten diese Umstände (Signalbelegungen, | ||
+ | |||
+ | **Funktionsfehler** sind harte Fehler, die von Anfang an da sind. In der Hardware gibt es zwei Arten: Entwurfsfehler (betreffen alle Geräte oder Funktionseinheiten des jeweiligen Typs) und Fertigungsfehler (betreffen nur einzelne Exemplare). In der Software handelt es sich zumeist um Programmierfehler. Manche Softwarefehler ergeben sich auch aus Datei- oder Kompatibilitätsproblemen (Datei-Inhalte verfälscht (Dateifehler), | ||
+ | |||
+ | **Dateifehler** sind Inhaltsverfälschungen von Dateien. Derartige Fehler passen nicht in das einfache Schema Hardware – Software: | ||
+ | * es sind harte Fehler, | ||
+ | * sie lassen sich zumeist beheben (Datenwiederherstellung, | ||
+ | * die Ursachen sind vielfältig: | ||
+ | | ||
+ | Manche Dateifehler sind vergleichsweise leicht zu erkennen. Sind hingegen Programmdateien, | ||
+ | |||
+ | **Harte Fehler erscheinen oftmals als flüchtige Fehler**, weil sie nur unter bestimmten Umständen auftreten und weil diese Umstände entweder (1) nur selten vorkommen oder weil sie (2) nicht ohne weiteres als solche erkannt werden (da die Zusammenhänge zu komplex sind). Beispiel: Anwendung X bleibt ab und zu hängen – aber nur dann, wenn (1) eine Datei eines bestimmten Typs geöffnet wurde und wenn (2) diese Datei von der Anwendung A erzeugt wurde (während von X selbst und von weiteren Anwendungen B, C erzeugte Dateien des gleichen Formats keinerlei Schwierigkeiten bereiten). Auf einen solchen Zusammenhang muss man aber erst einmal kommen... Das Erfassen von Begleitumständen und Zusammenhängen gehört deshalb zu den wichtigsten Fertigkeiten des Servicetechnikers. | ||
+ | |||
+ | // | ||
+ | |||
+ | |||
+ | **Mit manchen Fehlern muss man einfach leben** | ||
+ | |||
+ | Das betrifft zum Einen reine Zufallswirkungen, | ||
+ | |||
+ | Es kann auch durchaus sein, dass man durch Installation eines Updates die Funktion A in Ordnung bringt, sich aber ein neues Problem mit der Funktion X einhandelt. In solchen Fällen müssen wir uns damit begnügen, das Problem überhaupt zu erkennen und ggf. eine Umgehungslösung (Workaround) zu finden. | ||
+ | |||
+ | |||
+ | **Trivialfehler** sind ganz offensichtliche Fehler, die sich auf einfache Weise beheben lassen, z. B. durch Stecken von Kabeln, Einstellen von Bildhelligkeit und Kontrast, Schließen von Klappen, Auswählen des richtigen Verzeichnisses im Dateidialog usw. | ||
+ | |||
+ | ==== Fehlermechanismus ==== | ||
+ | |||
+ | Mit Fehlermechanismus bezeichnen wir Vorgänge, die Fehler – im Sinne eines Ausfalls oder einer Fehlfunktion – herbeiführen. Solche Vorgänge sind, wenn es um Hardware geht, letzten Endes stets physikalisch oder chemisch bedingt. Wir unterscheiden: | ||
+ | * Fehlermechanismen in Halbleitern, | ||
+ | * Fehlermechanismen in Geräten oder Funktionseinheiten, | ||
+ | * umgebungsbedingte Fehlermechanismen. | ||
+ | |||
+ | Fehlermechanismen, | ||
+ | |||
+ | ==== Fehlerverdacht ==== | ||
+ | |||
+ | Ein Begriff, an dessen Gebrauch man die Professionalität eines Verfassers von Fehlersuchdokumentation oder Prüfsoftware erkennt: kein Fehlerlokalisierungsverfahren ist unfehlbar, also hüte man sich davor, Fehlerursachen eindeutig zu benennen. Was nach Lage der Dinge kaputt sein könnte, ist also keineswegs als wirklich kaputt (erroneous, defective) anzusprechen, | ||
+ | |||
+ | ==== Fehlerhypothese ==== | ||
+ | |||
+ | Eine Fehlerhypothese ist eine vorläufige Annahme zur Ursache oder Art des Fehlers („dies und jenes könnte schuld sein”). Fehlerhypothesen werden typischerweise auf Grundlage von Erfahrung und Intuition aufgestellt. Sie werden durch Prüfen und Messen, durch Testen oder Probieren sowie durch logisches Schließen entweder bestätigt oder widerlegt. Wir nehmen beispielsweise zunächst einmal an, dass an einem bestimmten Fehler die Stromversorgung schuld ist. Ergibt daraufhin die messtechnische Kontrolle, dass die Stromversorgung funktioniert, | ||
+ | |||
+ | Typische Verfahren zum Überprüfen von Fehlerhypothesen: | ||
+ | * Nachmessen. | ||
+ | * Verdächtige Einrichtungen prüfen oder testen. | ||
+ | * Die vermutete Fehlerursache probeweise abstellen. Hardware: Verdächtige Funktionseinheiten, | ||
+ | |||
+ | ==== Fehlermodelle ==== | ||
+ | |||
+ | In der Praxis gilt Murphys Gesetz („alles, was schiefgehen kann, geht auch schief”); manchmal sogar Callahans Corollar („Murphy war ein Optimist”). Auf dieser Grundlage gelingt es allerdings kaum, durch logisches Schließen Fehler zu finden, und beim Schreiben von Testsoftware oder beim Entwickeln von Prüfgeräten stellt sich immer wieder die Frage: Was könnte noch schiefgehen, | ||
+ | Deshalb liegen allen auf Logik gestützten Vorgehensweisen und allen Ansätzen, das Testen, Fehlersuchen usw. zu automatisieren oder wenigstens zu unterstützen, | ||
+ | |||
+ | ==== Die Einzelfehlerhypothese ==== | ||
+ | |||
+ | Diese Annahme liegt praktisch allen Testprogrammen, | ||
+ | |||
+ | //a) Mehrere Symptome, ein Fehler// | ||
+ | |||
+ | Lassen Sie sich nicht verblüffen: | ||
+ | |||
+ | //b) Folgefehler// | ||
+ | |||
+ | Echte Mehrfachfehler entstehen mit hoher Wahrscheinlichkeit dadurch, dass zunächst ein Einzelfehler auftritt, der dann weitere Fehler verursacht. Beispiel: eine defekte Steckkarte bewirkt Überlastung und schließlich Ausfall eines Schaltkreises auf dem Motherboard. | ||
+ | |||
+ | //c) Unabhängige Fehler// | ||
+ | |||
+ | Dass mehrere Fehler wirklich voll unabhängig voneinander auftreten, ist zwar nicht auszuschließen, | ||
+ | |||
+ | //d) Folgefehler eines verdeckten Einzelfehlers// | ||
+ | |||
+ | Manche Fehler, insbesondere solche in Einrichtungen, | ||
+ | |||
+ | Beispiel: Ein Netzteil hat eine Kurzschlusssicherung, | ||
+ | |||
+ | // | ||
+ | |||
+ | - Erst dann, wenn ein Vorgehen auf Grundlage der Einzelfehlerhypothese nicht zum Erfolg geführt hat, sollten Sie Mehrfachfehler in Erwägung ziehen, und zwar zunächst (1) im Sinne von Folgefehlern und erst dann (2) im Sinne von unabhängigen Fehlern. | ||
+ | - Während in ausgesprochen digitaler Hardware Folgefehler vergleichsweise selten sind, ist in Analog- und Leistungsschaltungen (vor allem auch in der Stromversorgung) recht häufig mit Folgefehlern zu rechnen. | ||
+ | |||
+ | |||
+ | ==== Fehlersuchstrategie und Servicekonzeption ==== | ||
+ | |||
+ | Diese Oberbegriffe (im Fach-Englisch Troubleshooting Strategy, Maintenance Philosophy, Maintenance Concepts o. ä.) kennzeichnen die " | ||
+ | |||
+ | |||
+ | //Wie weit soll der Servicetechniker gehen?// | ||
+ | |||
+ | Was soll er vor Ort reparieren, was soll im Servicestützpunkt oder von Dienstleistern repariert, was ans Herstellerwerk zurückgeschickt werden? Heutzutage ist das Tauschen austauschbarer Funktionseinheiten (FRUs) die nahezu ausschließliche Form der Fehlerbeseitigung (manche Anbieter beschränken den Service sogar auf das Tauschen von CRUs – also von Teilen, die eigentlich jeder halbwegs geschickte Laie auswechseln kann...). Alle weiteren Einzelheiten (z. B. ob überhaupt reparieren und wenn ja, wo und von wem) sind Gegenstand betriebswirtschaftlicher Überlegungen. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | [[https:// | ||
+ | |||