BenutzerGUIAufgabeFunktionHW Fertiger keine Vorkenntnisse braucht nur Gut/Schlecht- Aussage Benutzer führen Auswahl begrenzt ermöglichen Testergebnisse darstellen Diagnose aus den Testmustern durchführen Diagnose darstellen Automatische Testsequenz für Fertigungsprüfung Testumgebung identifizieren Eingabe /Speich. Seriennummer Abfolge von Einzeltests steuern Testergebnisse erzeugen& auswerten Sonderfall EMV - Prüfung Interne Verbindungen prüfen ID,ADDR,Skal., nur mit Testeinschub! I/O-Kanäle (digital) mit Kabelsatz prüfen I/O-Kanäle (analog) mit Kabelsatz prüfen Scanfunktion für Adressen (IFK und I/O-Karten) Testmuster für beliebiges Digital- I/O 'One-Hot' Testmuster für Analogtests und Geräte:z.B. 'Rampe' Testmuster für Systemtests 'Pseudo- Random-Noise' Einzelkarten Einschübe Gesamtsysteme Für Karten gibt es eine definierte Testumgebung Einschübe müssen erkannt werden und brauchen Kabelsatz Gesamtsysteme müssen vor allem bei der Auswertung/Darst ellung anders behandelt werden Techniker Reparaturen Test-Ergebnisse sollen detailliert sein Auswahl möglichst uneingeschränkt Manuelle Tests Einzeltests wie oben, mit Ben.- Interaktion, einmalig, zyklisch, unterbrechbar Entwickler Inbetriebnahme frühe Fehlersuche wie Kommandozeile, wenig Prüfung der Inhalte möglich Basis-Tests Registerebene HEX-Eingabe flexibel, nur r/w

Testausführung (1) Eigenschaften 1.Arbeitet Sequenzen von r/w-Aktionen ab (evtl. definierte Sequenz von Aktionen (r/w), sowohl für Testumgebung als auch für den Prüfling (Test - Objekt)). unklar: Sind dieses Sequenzen steuerbar oder nicht? Wenn starr, dann gibt es für jeden Kartentyp eine andere Testausführung,evtl. sogar mehrere pro Karte. In diesem Fall wäre die Testausführung immer HW-abhängig. 2.führt Schreib-Lesezyklen aus und kann Testmuster (Pattern) einlesen aus Bibliothek/Sammlung (LISTE#1) Das Testmuster enthält nur Nutzdaten, keine Steuerdaten oder Adressen, ist aber prinzipiell von Bitbreite abhängig, Verfahren zum Bilden von Untermengen (nur Teil der Liste einlesen, wenn Adressraum kleiner ist. 3.kann Testmuster intern selbst erzeugen (Option) 4.kennt seine Testumgebung (HW-Merkmale, Benutzerberechtigungen). -> Öffentliche Eigenschaft. P rüfung durch aufrufendes Objekt? 5.Kennt erlaubte Prüflingstypen. Prüfling und Sequenzen müssen zusammenpassen, siehe 1) 6.speichert vom Prüfling gelesene Werte (LISTE#2) und bearbeitet sie (LISTE#3) indem Differenzen markiert werden (evtl. generell in Testauswertung, wegen der Allgemeinheit: hier sind HW-Spezialitäten und Betriebsarten nicht bekannt und können eine sinnvolle Auswertung verhindern) 7.ruft HW-abhängige Diagnose auf 8.Stellt LISTE#2 und LISTE#3 bereit -> Öffentliche Eigenschaft

Testausführung (2) Aufruf 1.wird mit "Parametern" aufgerufen (Kommunikationsparameter: Blocklänge min/max., Latenz, Handshaking); (Testart: Automatisch/Manuell/weitere?) (Auswertung: ohne/mit Diagnose, weitere?.) Evtl. auch Testumgebung bereits als Parameter übergeben 2.HW-Information: Typ des Prüflings (z.B.Kartentyp, damit anzusprechende Adressen festlegen) FIFO Kommunikation (USB, Firewire, Internet) 1.Testmuster senden : Block senden, z.B. wr1,DATA1, rd2,wr3,DATA3, rd4,wr5,DATA5..rdN 2.Rückgabewerte empfangen: Block empfangen DATA 2, DATA 4,......DATA N 3.Die Kommunikationsparameter bestimmen die Erzeugung der Blöcke, bei der PCI-MIL-Karte kann die Blocklänge 1 sein (derzeit üblicher Fall) Die Daten müssen eindeutig zuzuordnen sein, d.h. am besten mit einer eindeutigen Nummerierung -> (minimales) Protokoll notwendig zur Erkennung von Fehlern Zentrale Funktionalität!

Testauswertung (HW-unabhängig) Input, Output 1.Liste#1 mit geschriebenen Daten, Liste#2 mit gelesenen Daten, Regel, nach der die beiden verglichen werden. Rückgabe einer Liste mit Differenzinformationen Funktion (compare) 1.Listen mit Hilfe der angeforderten Regeln vergleichen (Liste#2 mit Liste#1), sowohl Vektoren als auch Bitfelder. Die Listen werden von aufrufendem Objekt übergeben 2.Vergleichsergebnis (Differenz) bewerten, in Liste#3 ablegen 3.Liste#3 zurückgeben an aufrufendes Objekt Regeln (rules) 1.arithmetisch (Vektoren)(=,<>,,|Diff|< Grenzwert 2.boole'sch(Bitfelder)INV, OR, AND, EXOR 3.statistisch (Vektoren)z.B. Sigma 2 < Grenzwert 4.sonstigeLinearität bei ADCs: DNL, INL 5.Berücksichtigung von Pipelining (getakteteVerarbeitung), um N Schritte versetzte Zuordnung der Vektoren zueinander

Test-Diagnose (HW-abhängig) Input 1.Liste#1 (Originaldaten) 2.Vergleichsergebnis (Liste#3) als Bitfeld 3.Zuordnung Signalnamen Bitpositionen/Adressen 4.Info über HW-Struktur (getaktetes I/O, invertierte Signalpfade, Arithmetische/algorithmische Bearbeitung zur Simulation des erwarteten Ergebnisses oder möglicher Fehler) Output Liste#4 (bitorientiert/vektororientiert) mit den Kategorien z.B. "Kurzschluss", "Unterbrechung", "Nichtlinearität", "Offset", "Rauschen")

Scan-Funktionen (Identifizieren der Hardware incl. Testumgebung) Mehrstufiges/hierarchisches Identifizieren von Komponenten, dabei diverse Verzweigungen wegen der Artenvielfalt 1.Interface-Adressen-Scan (IFK-ADDR ) Allgemeine Funktion 2.Parallel-Buserkennung &Interface-Typerkennung Allgemeine Funktion, danach Verzweigung: (Modulbus, NG-Backplane, I/O-Bus, Sweeper, DDS, FKT.-Gen) 3.I/O-Karten-Adressen-Scan (z.B.Modulbus-ADDR 0..31, Kartentyp, Konfiguration "Skalierung", Firmware-Version oder NG –Backplane- Kartentyp/Adressschalterstellung, o.ä) 4.APK-Typerkennung (APK-Typ (Input, Output, Ausführung)) Ergebnisse bereitstellen jeweils als Liste: z.B. ADDR; Typ; Version, -> damit andere Programmteile/Objekte diese Information zum Parametrieren verwenden können.