Testausführung (1)

2. Testausführung (1) • Eigenschaften • 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. • 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. • kann Testmuster intern selbst erzeugen (Option) • kennt seine Testumgebung (HW-Merkmale, Benutzerberechtigungen). -> Öffentliche Eigenschaft. Prüfung durch aufrufendes Objekt? • Kennt erlaubte Prüflingstypen. Prüfling und Sequenzen müssen zusammenpassen, siehe 1) • 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) • ruft HW-abhängige Diagnose auf • Stellt LISTE#2 und LISTE#3 bereit -> Öffentliche Eigenschaft

3. Testausführung (2) • Aufruf • 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 • HW-Information: Typ des Prüflings (z.B.Kartentyp, damit anzusprechende Adressen festlegen) • FIFO Kommunikation (USB, Firewire, Internet) • Testmuster senden : Block senden, z.B. wr1,DATA1, rd2,wr3,DATA3, rd4,wr5,DATA5..rdN • Rückgabewerte empfangen: Block empfangen DATA 2, DATA 4, ......DATA N • 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!

4. Testauswertung (HW-unabhängig) • Input, Output • 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) • Listen mit Hilfe der angeforderten Regeln vergleichen (Liste#2 mit Liste#1), sowohl Vektoren als auch Bitfelder. Die Listen werden von aufrufendem Objekt übergeben • Vergleichsergebnis (Differenz) bewerten, in Liste#3 ablegen • Liste#3 zurückgeben an aufrufendes Objekt • Regeln (rules) • arithmetisch (Vektoren) (=,<>,<,>,|Diff|< Grenzwert • boole'sch (Bitfelder) INV, OR, AND, EXOR • statistisch (Vektoren) z.B. Sigma2 < Grenzwert • sonstige Linearität bei ADCs: DNL, INL • Berücksichtigung von Pipelining (getakteteVerarbeitung) , um N Schritte versetzte Zuordnung der Vektoren zueinander

5. Test-Diagnose (HW-abhängig) • Input • Liste#1 (Originaldaten) • Vergleichsergebnis (Liste#3) als Bitfeld • Zuordnung Signalnamen<-> Bitpositionen/Adressen • 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")

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