Benutzer GUI Aufgabe Funktion HWFertiger•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/Darstellung 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)• Eigenschaften1. 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. Prü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)• Aufruf1. 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, Output1. 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. Sigma2 < Grenzwert

4. sonstige Linearität bei ADCs: DNL, INL

5. Berücksichtigung von Pipelining (getakteteVerarbeitung) , um N Schritte versetzte Zuordnung der Vektoren zueinander

Test-Diagnose (HW-abhängig)• Input1. 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 0..255) 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.