Diplomarbeit Werner Ziegler

Bei meinem Studium an der Technischen Informatik an der Fachhochschule Albstadt-Sigmaringen habe ich mich für die Vertiefungsrichtung Microcomputertechnik entschieden. Auf den nachfolgenden Seiten möchte ich meine Diplomarbeit vorstellen. Sie trägt den Titel:

Entwicklung und Realisierung von Prüfalgorithmen zur Endkontrolle von Rechnerbaugruppen

und wurde von mir im 9. Semester bei der Firma effeff Fritz Fuss GmbH & Co KGaA in Albstadt durchgeführt. Bei der Durchführung der Arbeit mußte sowohl Hard- als auch Software entwickelt werden, um eine neu entwickelte Rechnerkarte in einem bereits bestehenden Testumfeld überprüfen zu können.

Nach 1,5 Monaten Einarbeitung und Analyse der Gegebenheiten vor Ort meldete ich die Arbeit an 1. April 1995 an. Die Bearbeitung des Projektes erfolgte in enger Zusammenarbeit mit der Abteilung Prüfgerätebau, welche die Geräte zur Endkontrolle herstellt und wartet. Nach erfolgtem Feldtest wurde das Prüfgerät Ende Oktober in Betrieb genommen, meine Diplomarbeit habe ich nach einmonatiger Verlängerung am 4. Dezember 1995 abgegeben. Die theoretische und praktische Vorstellung der Arbeit fand am 30. November in der Fachhochschule statt.

Erstbetreuer meiner Arbeit war Herr Prof. Dr.-Ing. Martin Rieger von der FH Albstadt-Sigmaringen, Zweitbetreuer Herr Dipl.-Ing. Harald Sauter von der Firma effeff Fritz Fuss GmbH & Co. KGaA. Während meiner Diplomandenzeit bekam ich von der Firma 800.- DM Ausbildungsvergütung pro Monat zuzüglich 50.- DM Fahrtkostenentschädigung.

Teile der Arbeit sind unter den nachfolgenden Menüpunkten abrufbar:

  1. Einleitung
    1.1. Ausgangssituation und Aufgabenstellung
    1.2. Vorgehensweise und Strukturierung
    1.3 Zeitplan

  2. Aufbau des Testprints

  3. Kommunikation mit der Testumgebung
    3.1. Beschreibung des BETA-Testers
    3.1.1. Aufbau des BETA-Testers im Überblick
    3.2. Entwicklung des Kommunikationsprotokolls
    3.2.1. Ablauf der Kommunikation
    3.3. Zusatzhardware
    3.3.1. BETA-Simulation
    3.3.2. Hardwareadapter

  4. Implementierung der Testschritte
    4.1. Entwicklungsumgebung
    4.2. Strukturierung der Implementation
    4.2.1. Klassenhierarchie
    4.3. Programmabarbeitung zur Laufzeit
    4.3.1 Erzeugen und Initalisieren der Instanzen
    4.3.2 Aufruf und Ausführung der entsprechenden Instanzen

  5. Inbetriebnahme, Test und Projektabschluß
    5.1. Testplan
    5.2. Feldtest
    5.3. Vergleich zum bisherigen Verfahren
    5.4. Abschluß des Projekts

  6. Zusammenfassung
    6.1. Projektverlauf
    6.2. Beurteilung der Aufgabenstellung und Ausblick

Hinweis: Da hier nur Auszüge der Arbeit dargestellt werden, kann keine Garantie dafür übernommen werden, daß referenzierte Kapitel, Abbildungen, Tabellen, Seiten, Programmteile oder Literaturverweise auch tatsächlich Bestandteil dieser Zusammenfassung sind. Weitere Details können gerne nachgereicht werden. Eine e-mail an mich genügt.

Abstrakt:

Qualität ist ein immer wichtiger werdendes Bewertungskriterium für Produkte. Die Zertifizierung von Fertigungsverfahren nach der internationalen ISO 9000 Normenreihe stellt entsprechende Qualitätsanforderungen an die Endprodukte und sichert somit deren Bestand im internationalen Vergleich.

Nach wie vor spielt hierzu die Endkontrolle eine wichtige Rolle im Fertigungsprozeß. Dabei müssen umfangreiche Überprüfungen möglichst rationell und effizient durchgeführt werden, was speziell auf das jeweilige Endprodukt abgestimmte Prüfverfahren notwendig macht.

Die vorliegende Arbeit beschreibt, wie ein bisher bewährtes System zur Endkontrolle dahingehend erweitert wird, daß nun auch weitaus umfangreichere Überprüfungen in wesentlich kürzerer Zeit durchgeführt werden können.

Es galt, zwei Ziele zu verbinden: das bestehende Testumfeld sollte nicht wesentlich verändert werden, um eine Handhabung ohne zusätzliche Einarbeitung zu ermöglichen. Weiterhin war eine große Testtiefe gefordert; alle ausführbaren Funktionen, und somit alle potentiellen Fehlerquellen sind zu überprüfen.

Somit stellt diese Arbeit gewissermaßen ein Pilotprojekt dar. Die Ausarbeitung des Projekts soll herangezogen werden, wenn es darum geht, die Endkontrolle an komplexere Endprodukte anzupassen.

Welche Vorgehensweise dazu verwendet und welche Lösungswege gegangen wurden, wird in den nachfolgenden Kapiteln ausführlich erläutert.

Abstract:

A criterium for evaluating products which is becoming more and more important is their quality. Certificating methods of manufacturing following the international ISO 9000 series of standards requires corresponding measures of quality of the final products and hereby secures their existence in the international comparison.

The final control still plays an important role in the process of manufacturing. Extensive checks must be performed in the most economical an efficient way. This requires procedures of control which are particularly coordinated with the respective final products.

The paper at issue describes how of a well proved method of final control may be expanded in order to be able to perform more extensive checks in considerably less time.

Two goals had to be combined: the existing test background should not be changed to much so that operation is still possible without additional training. Also, the test had to be sufficiently profound, all functions that had to be carried out and thus all possible sources of errors to be examined.

Consequently, this project should be taken to some extent as a pilot study. Its elaboration should be referred to whenever a system of final control must be adapted to more complex end products.

Which measures to take and which methods to try will be explained thoroughly in the following chapters.

1. Einleitung

1.1 Ausgangssituation und Aufgabenstellung:

Die fortschreitende technologische Entwicklung ermöglicht es, immer komplexere Aufgaben mit vergleichsweise geringem Hardwareaufwand bewältigen zu können. Verständlicherweise steigt somit auch die Komplexität der eingesetzten Hardware. Bisher zur Funktionsprüfung eingesetzte Verfahren sind durch die hohe Komplexität der zu testenden Hardware überfordert, es müssen neue Wege gefunden werden.

Die vorliegende Diplomarbeit beschreibt die Entwicklung eines Testverfahrens für Hardware-Baugruppen, welches die zu testende Hardware aktiv am Testdurchlauf beteiligt. Ein wichtiges Ziel der Diplomarbeit war es, die bisher bei der Firma effeff Fritz Fuss GmbH & Co. KGaA bewährte Testumgebung (BETA-Tester) nicht wesentlich zu verändern. So wurde das bisherige Testverfahren beibehalten und durch die "Aktivierung" der zu testenden Baugruppe erweitert.

Alle Komponenten der zu testenden Baugruppe sollen unter simulierten Realbedingungen überprüft werden. Die Sequenz, in welcher die einzelnen Komponenten getestet werden, soll dabei frei wählbar sein. Dadurch wird eine hohe Flexibilität bei der Testdurchführung und somit ein rationelles Testen gewährleistet.

Zweck der Arbeit war es, durch aktives Testen mit vertretbarem zeitlichen Aufwand bisher nicht feststellbare, interne Funktionsstörungen der Hardware, z.B. Störungen der Bussignale durch defekte Bauelemente, zu erkennen. Dabei soll auch untersucht werden, ob dieses erweiterte Testverfahren sinnvoll, und somit auf weitere Baugruppen anwendbar ist.

Bisher wurde der Testprint auf konventionelle Art funktionsgeprüft und mußte hierzu in zwei verschiedene Anwendungen eingebaut werden, um alle von ihm zur Verfügung gestellten Funktionen überprüfen zu können. Der dazu notwendige Zeitaufwand beträgt ein Vielfaches im Vergleich zu einem Testdurchlauf mit dem BETA-Tester. Somit trägt das Vorhaben sowohl zur Qualitätssicherung als auch Kostensenkung bei.

1.2. Vorgehensweise und Strukturierung

Da die Anpassung an die bestehende Testanordnung im Vordergrund dieses Projektes stand, war es notwendig, sich bereits im Vorfeld intensiv mit den Besonderheiten dieser Testanordnung auseinanderzusetzen. Anhand von Dokumentationen, Testvorschlägen und durch Gespräche mit den jeweiligen Ansprechpartnern war dies gut möglich. Im Anschluß daran wurde ein Blockschaltbild von der zu testenden Hardware-Baugruppe (Testprint) erstellt, um so einen Einblick in das Zusammenspiel der einzelnen Funktionen zu gewinnen.

Aus den gewonnen Erkenntnissen entstand nun in Zusammenarbeit mit der Abteilung Prüfgerätebau (TP-S) das Pflichtenheft [20] als Grundlage für die Diplomarbeit.

Anschließend war es notwendig, die Schnittstelle zwischen bestehender Testumgebung und der Erweiterung zu definieren. Laut Pflichtenheft mußte dazu ein Hardwareadapter entwickelt und ein spezielles Kommunikationsprotokoll verwendet werden. Im Anschluß daran erfolgte die Entwicklung und Implementierung von 38 eigenständigen Testschritten. Diese Testschritte haben die Aufgabe, bestimmte Funktionen der zu testenden Hardware zu überprüfen und das Ergebnis an die Testumgebung weiterleiten.

Um die Testschritte bereits während der Implementierung ersten Überprüfungen zu unterziehen, war es notwendig, den BETA-Tester zu simulieren. Diese Simulation wurde aufgrund der definierten Schnittstelle und des Kommunikationsprotokolls erstellt und ist unter Kapitel 3.3.1. ausführlich beschrieben.

Nachdem einige Testschritte implementiert waren erfolgten erste Testserien im realen Testumfeld mit dem BETA-Tester. So konnte sichergestellt werden, daß der von der Abteilung TP-S zu erstellende Hardwareadapter zusammen mit den Testschritten und Modulen die gewünschte Funktionsprüfung vornimmt.

Als alle Testschritte implementiert und der Hardwareadapter komplett fertiggestellt war, wurde die Testanordnung anhand des erarbeiteten Testplans (siehe Anhang B) überprüft. Hierbei wurde durch gezielte Manipulationen an dem Testprint sichergestellt, daß fehlerhafte Funktionen auch tatsächlich erkannt werden.

Während der gesamten Diplomarbeit wurde täglich im Projektbuch der Fortschritt der Arbeit, aber auch auftretende Probleme sowie deren Lösungen dokumentiert. An wesentlichen Stationen des Projekts wurde der Zeitplan aktualisiert und Entwürfe für die hier vorliegende Ausarbeitung erstellt.

1.3. Zeitplan


Abbildung 1: Geplanter Projektverlauf

2. Aufbau des Testprints

Das erweiterte Testverfahren soll im Rahmen dieser Diplomarbeit die Funktionsfähigkeit eines Rechnerprints, welcher intern unter der Bezeichnung "Einbruchmeldezentrale (EMZ) 561 - MB 256" bekannt ist, überprüfen. Dieser Rechnerprint wird in verschiedenen Produkten der Firma effeff Fritz Fuss eingesetzt und in einer Menge von ca. 500 Stück pro Jahr in der eigenen Fertigung hergestellt. Sein Aufbau und seine Komponenten sollen nachfolgend kurz vorgestellt werden:

Der Rechnerprint (siehe Abb.4) besitzt eine 68HC000 CPU von Motorola, die mit 12 MHz getaktet wird. Ein 68HC901 Peripheriebaustein ist für die Verwaltung der insgesamt 14 Interrupts und die Verarbeitung einer seriellen Schnittstelle zuständig. Ein weiterer Schnittstellenbaustein (80C50A) dient zur Ansteuerung einer zweiten seriellen Schnittstelle. Zusätzlich sind Anschlußmöglichkeiten für Tastatur, Bedien- und Anzeigeplatinen, ein paralleles Druckerport, sowie für eine LAN-Karte vorhanden.

Eine batteriegepufferte eigenständige Echtzeituhr (RTC72421) sowie DIP-Schalter zur Codierung sind ebenfalls Bestandteile des Prints. 8 MB batteriegepufferter RAM-Speicher befindet sich zusammen mit Steckplätzen für zwei 512kB Eproms (27C4001) auf einer separaten Karte (siehe Abb.5), die auf den Rechnerprint aufgesteckt wird. Die Aktivität des Rechnerprints wird von einer Watchdog-Schaltung (MAX 691) überwacht. Dieser Baustein ist auch für das rechtzeitige Umschalten der Spannungsversorgung auf Batteriebetrieb zuständig, falls es zu einem Netzausfall kommt. Bei Kommunikation mit langsamerer Peripherie besteht die Möglichkeit, Wartezyklen (Wait-State) einzufügen, oder ein LAN-Busy Signal zu setzen.

3. Kommunikation mit der Testumgebung

Die Schnittstelle zur Testumgebung stellt der BETA-Tester dar. Aufgrund der Aufgabenstellung mußte die Testanordnung so entwickelt werden, daß die Kommunikation zur Testumgebung über diese Schnittstelle geschieht. Daher war es zuerst notwendig, sich in den Aufbau und die Besonderheiten des BETA-Testers einzuarbeiten. Dabei wird der, im vorhergehenden Kapitel beschriebene, Rechnerprint nachfolgend als Testprint bezeichnet.

3.1. Beschreibung des BETA-Testers

Der BETA-Tester wird in der Endprüfung vielfach eingesetzt und ist an jedem Testplatz vorhanden. Es handelt sich dabei um ein PC-gestütztes Testsystem mit entsprechender Peripherie für die Ein- und Ausgabe. Auf dem PC werden die spezifischen Stapelverarbeitungsprogramme zur Ansteuerung der Peripherie abgearbeitet. Die Peripherie ist über entsprechende Hardwareadapter mit der zu testenden Baugruppe verbunden. Die Baugruppe wird hierzu im Testrahmen von einem Spannrahmen und Niederhaltern fixiert, anschließend pneumatisch auf den Nadeladapter gedrückt. Die elektrisch leitfähigen Nadeln stellen hierbei die notwendigen Verbindungen zu den Signalleitungen auf der Rückseite des Testprints dar. Eine Beschreibung der Testanordnung ist in Abbildung 7 in Form eines Blockschaltbildes dargestellt.

Die E/A-Peripherie des BETA-Testers besitzt 4 Ausgabeports (X1,X2,X5,X6) sowie 4 Eingabeports (X3,X4,X7,X8). Jedes dieser Ports besteht aus je 48 Ein- bzw. Ausgängen. Die zu verarbeitenden Signale müssen statisch mit TTL- bzw. 14.2V-Logik anliegen. Die minimale Zeit zwischen zwei Ausgangssignalwechseln beträgt 10,01 ms. Das Einlesen von Eingangssignalen kann zeitverzögert geschehen, jedoch muß das Signal nach der angegebenen Zeitverzögerung am Eingang anliegen.

Abbildung 8 zeigt den Testrahmen. Darauf sind sowohl die auf der Abdeckplatte montierten Niederhalter, als auch die Anschlußleiste zur BETA-Peripherie zu sehen.

Abbildung 9 zeigt einen Auszug des Nadeladapters. Deutlich zu sehen ist hier auch der Spannrahmen, welcher den eingelegten Testprint fixiert. Bei der Herstellung des Nadeladapters können die Bohrungen sehr präzise angebracht werden. Nachträglich anzubringende Bohrungen bereiten hingegen Schwierigkeiten bezüglich der Genauigkeit. Daher wurden bei der Herstellung mehr Nadelbohrungen vorgesehen als eigentlich notwendig.

Abschließend ist in Abbildung 10 ein in den Spannrahmen eingelegter Testprint teilweise dargestellt. Deutlich sind hier die Niederhalter zu erkennen.

3.1.1. Aufbau des BETA-Testers im Überblick

3.2. Entwicklung des Kommunikationsprotokolls

Die Prüfung des Testprints erfolgt durch das Zusammenspiel von BETA-Testgerät und auf dem Testprint implementierten Testprogramm nach dem Master/Slave-Prinzip. Dabei stellt der BETA-Tester den Master und das Testprogramm den Slave dar. Daraus wurde das nachfolgend beschriebene Kommunikationsprotokoll erstellt.

3.2.1. Ablauf der Kommunikation

Der Testprint soll durch verschiedene, voneinander unabhängige, Testschritte getestet werden. Dabei ist zur Untersuchung jeder Funktion des Testprints ein Testschritt vorgesehen. Alle zur Verfügung stehenden Testschritte sind in den Eproms auf der Speicherkarte des Testprints in Form eines Testprogramms abgelegt. Der Aufruf der einzelnen Testschritte erfolgt vom BETA-Tester, dabei ist die Reihenfolge der Testschritte frei wählbar. Bestimmte Funktionen müssen jedoch durch zusammenhängende Testschritte getestet werden, so z.B. der Reset nach zu geringer Versorgungsspannung (vgl. Kapitel 4.5.).

Die Auswertung der Testschritte erfolgt entweder intern oder extern. Intern bedeutet, das Testergebnis wird vom Testprogramm kontrolliert und eine OK bzw. FEHLER-Meldung an den BETA-Tester übermittelt. Die OK-Meldung ist eindeutig, in der FEHLER-Meldung können weitere Informationen zur Fehlerdefinition enthalten sein. Diese sind in unter 3.3 aufgeschlüsselt. Extern bedeutet, daß der BETA-Tester die entsprechenden Signale über den Hardware-Adapter abgreift und auswertet.

Abbildung 13: Kommunikation zwischen Master und Slave

3.2.2. Ablauf eines Testschritts ohne Fehlerentdeckung

Ein Testschritt beginnt mit dem Anlegen des Befehlscode durch den BETA-Tester am "Befehlscode IN" Anschluß. Durch die ansteigende Flanke des Befehls-Strobe wird der Befehlscode vom Testprogramm eingelesen. Anschließend wird sowohl am "Befehlscode OUT" als auch am "Testergebnis" Anschluß zur Kontrolle die Information 0x00 angelegt. Dann wird diese Information vom BETA-Tester ausgelesen und durch das Deaktivieren des Befehls-Strobe bestätigt.

Konnte der Befehlscode interpretiert werden, so wird er mit der abfallenden Flanke des Befehls-Strobe als Quittierung am "Befehlscode OUT" Anschluß ausgegeben. Anschließend wird mit der Abarbeitung des Testschritts begonnen. Jedem Testschritt ist eine bestimmte Ausführungszeit zugeordnet, sie wird einmalig durch Messungen ermittelt. Nach Ablauf der Ausführungszeit wird vom BETA-Tester das korrekte Anliegen des Befehlscode am "Befehlscode OUT"-Anschluß überprüft. Wurde der Befehlscode richtig quittiert, so wird im Falle einer internen Auswertung das Testergebnis ermittelt.

Erfolgt die Auswertung extern, so vergleicht der BETA-Tester die während des Testschritts ermittelten Informationen mit seinen Vorgaben. Bei erfolgreichem Test kann die Einleitung des nächsten Testschritts erfolgen.

Abbildung 15 zeigt die zeitliche Abfolge der einzelnen Signale und Meldungen

3.3. Zusatzhardware

Die Entwicklung des Hardwareadapters und der BETA-Simulation waren Bestandteil der Diplomarbeit. Der Hardwareaufbau wurde gemäß des Pflichtenhefts von der Abteilung TP-S gefertigt. Lediglich ein kleiner Teil der benötigten Adapterfunktionen wurden auch in die BETA-Simulation integriert, die während der Implementation der Testschritte aufgebaut wurde. Um die entwickelten Testschritte unabhängig vom späteren Hardwareadapter in Betrieb nehmen zu können, war es notwendig, die BETA-Simulation aufzubauen.

3.3.1. BETA-Simulation

Die BETA-Simulation bietet die Möglichkeit, Meldungen des vereinbarten Kommunikationprotokolls mit dem Testprint auszutauschen. Dazu muß der entsprechende Befehlscode des gewünschten Testschrittes (vgl. Tabelle 4) an den DIP-Schaltern gestellt werden. Ein eingeschalteter DIP-Schalter repräsentiert hierbei eine logische 0, ein geöffneter Schalter wird als 1 interpretiert. Durch Quittierung der Einstellung mit dem Befehlsstrobe-Taster wird der Befehlscode übernommen, abgearbeitet und das Resultat des Testschritts wird durch die LEDs angezeigt. Somit können Testschritte nur einzeln und nicht, wie später durch das BETA-Stapelverarbeitungsprogramm realisiert, in einer Sequenz abgearbeitet werden, was zur Funktionsprüfung während der Implementierung der Testschritte jedoch vollkommen ausreicht. Bis auf wenige Ausnahmen können mit der BETA-Simulation alle Testschritte ausgeführt werden, die vom Programm zur Verfügung gestellt werden. Zusätzlich benötigte Signale, z.B. bei der Überprüfung der Interrupt-Eingänge wurden durch kurz angelegte Potentiale an den entsprechenden Meßpunkten realisiert. Zur Auswertung aufgetretener RESET-Signale dienen zwei Leuchtdioden (LEDs), die über ein Flip-Flop angesteuert und durch einen Tastschalter zurückgesetzt werden können. Die Einstellung der Wait-State und die RXD/TXD-Verbindungen wurden durch Kurzschlußstecker und Schalter erzeugt, die Simulation der Tastatur durch zusätzliche Logikbausteine realisiert.

Abbildung 17 zeigt die konventionell auf Lochrasterkarte aufgebaute BETA-Simulation, die mit dem Testprint durch Flachbandkabel verbunden ist. Weiterhin ist im rechten mittleren Bildbereich die V24-Schnittstellenkarte zu sehen, über welche während der Implementierung die Monitorsoftware angeschlossen war. Neben den o.g. DIP-Schaltern und Leuchtdioden zur Ein- und Ausgabe der Meldungen sind auch die Steckbuchsen zum Anschluß der BETA-Peripherie erkennbar. Ebenfalls dargestellt ist die, direkt mit der DIN-Buchse des Testprints verbundene Simulation der Tastatur.

Die Testschritte Nr. 33, 34, 36, 37 und 38 benötigen komplexere externe Beschaltungen, die ausschließlich im Hardwareadapter aufgebaut wurden, auf die, für den Testschritt Nr. 36 benötigte, Beschaltung wird in Kapitel 3.3.3. detailliert eingegangen.

3.3.2. Hardwareadapter

Wie bereits in Kapitel 3.1.erwähnt wurde, ist zur Kommunikation der BETA-Peripherie mit dem Testprint ein Hardwareadapter notwendig. Dieser dient zur Anpassung der spezifischen Signale des Testprints an die der BETA-Peripherie und umgekehrt.

Der BETA-Tester stellt nur vergleichsweise langsame Möglichkeiten zur Signalverarbeitung zur Verfügung. Dabei können keine Standardprotokolle, wie z.B. V24 oder RS232 verwendet werden. Signale können nur erkannt und ausgewertet werden, wenn sie statisch zum Zeitpunkt der Abfrage durch das BETA-Stapelverarbeitungsprogramm anliegen. Es kann nicht "gepullt" werden.

Doch nicht diese Schwächen des BETA-Testers machen diesen Hardwareadapter notwendig: Ausgaben an den Schnittstellen des Rechnerprints müssen durch Latch gepuffert werden, bzw. Ausgaben des BETA-Testers dem Rechnerprint durch Latch bereitgestellt werden, daß diese mit den entsprechenden Buszyklen eingelesen werden können. Ohne dieses Zwischenspeichern der Meldungen wäre die Synchronisation zwischen dem BETA-Tester als Master und Rechnerprint als Slave nicht möglich. Abbildung 18 zeigt am Beispiel der Schnittstellen "Ergebnis" und "Befehlscode IN" einen Auszug aus dem Hardwareadapter.

Abbildung 18: Hardware zum Zwischenspeichern der Meldungen

Die Abbildung zeigt einen Ausschnitt das Hardwareadapters, der als BETA-Simulation aufgebaut wurde, jedoch auch die Möglichkeit zur Kommunikation mit der BETA-Peripherie bietet. Exemplarisch für alle Schnittstellen des entwickelten Kommunikationsprotokolls sind hier die Schnittstellen für die Meldungen "Befehlscode IN" und "Ergebnis" dargestellt. Bezogen auf die Datenflußrichtung repräsentiert hierbei die "Ergebnis"-Schnittstelle auch die Schnittstellen "Datenbus OUT" und "Befehlscode OUT", die nahezu identisch aufgebaut sind. Auch die Signalleitung "Befehlsstrobe" ist Bestandteil der Abbildung.

Je nach dem, ob der abgebildete Teil des Hardwareadapters als BETA-Simulation oder direkt als Adapter zur BETA-Peripherie verwendet wird, werden die Meldungen entweder über die DIP-Schalter und LEDs (manueller Betrieb) oder über das entsprechende Xn-Port (siehe Programm 1) der BETA-Peripherie (Stapelverarbeitungsbetrieb) übertragen. Auf Abbildung 17 der BETA-Simulation sind die entsprechenden LEDs, DIP-Schalter und Steckanschlüsse erkennbar.

Wird die Anordnung in Verbindung mit dem BETA-Tester verwendet, müssen sich alle DIP-Schalter in offenem Zustand befinden, um Signalkollisionen zu verhindern. Nun können alle Testschritte im Stapelverarbeitungsbetrieb abgearbeitet werden, die keine zusätzliche Hardwarebeschaltung benötigen, z.B. "Uhrzeit stellen". Die Handhabung bei manuellem Betrieb wurde bereits in Kapitel 3.3.1. erläutert.

Der komplette Hardwareadapter beinhaltet zahlreiche Latch-Bausteine zum Erfassen der Zustände auf dem Daten- und Adressbus, Flip-Flops zum Speichern von Impulsen, verschiedene logische Funktionen zur Realisierung spezieller Abläufe bei entsprechenden Testschritten. Weiterhin sind Transistoren zur Erzeugung von Impulsen, z.B. zur Interruptsimulation und Relais zur Simulation von Steckbrücken und Verbindung der RXD/TXD-Leitungen. Auch die Spannungsversorgung des Testprints und Simulation der 3 Volt Batterie sind durch den Hardwareadapter realisiert. Die im normalen Betriebszustand des Rechnerprints über eine Stiftleiste aufgesteckte RAM-Karte (vgl. Abb. 5) befindet sich ebenfalls auf dem Hardwareadapter und ist direkt mit dem Nadeladapter verbunden.

4. Implementierung der Testschritte

Einleitend zu diesem Kapitel soll nochmals das Zusammenspiel der am Test beteiligten Komponenten deutlich gemacht werden: Auf der zu prüfenden Hardware, dem Testprint, läuft während des Tests ein, vom später im Endprodukt eingesetzten, vollkommen unterschiedliches Programm ab. Die Entwicklung und Implementation dieses Programms war der Hauptbestandteil dieser Diplomarbeit. Das Programm stellt bei der Kommunikation mit dem BETA-Tester den Slave dar. Ebenfalls als Bestandteil dieser Diplomarbeit wurde der zur Kommunikation benötigte Hardwareadapter entwickelt, dieser wurde jedoch größtenteils von der Abteilung TP-S gefertigt. Die Erstellung des, auf dem BETA-Tester ablaufenden, Stapelverarbeitungsprogramms wurde vollständig von der Abteilung TP-S übernommen. Leichte Anpassungen während der Inbetriebnahme der gesamten Testanordnung wurden gemeinsam vorgenommen. Doch dazu mehr in Kapitel 9.3. In diesem Kapitel soll nun die Entwicklung und Erstellung des auf dem Testprint abzuarbeitenden Programms beschrieben werden.

4.1. Entwicklungsumgebung

Als Entwicklungsgeräte standen ein PC 80386 mit Coprozessor und 8MB Hauptspeicher, ein komplett funktionsfähiger Rechnerprint als Referenz, sowie die inkrementell entwickelte BETA-Simulation zur Verfügung. Als Werkzeuge wurde die Entwicklungsumgebung, bestehend aus:

sowie dem Betriebssystem MS-DOS 6.22 von Microsoft eingesetzt.

Durch den XRAY-High-Level Debugger war es möglich, implementierte Programmteile direkt über die serielle Schnittstelle des PC's, auf die Zielhardware zu übertragen. Dazu war jedoch ein spezielles Monitorprogramm auf der Zielhardware notwendig, welches in den Eproms der aufgesteckten RAM-Karte abgelegt war. Dies vereinfachte die Entwicklung der einzelnen Testschritte sehr, verursachte aber auch teilweise Probleme bei der Realisierung spezieller Testschritte, z.B. dem Schritt Nr. 29 (vgl. Tabelle 4 ). Dieser Testschritt überprüft die Funktion der V24 Schnittstelle und den dazugehörenden Interrupt. Nun findet jedoch unglücklicherweise auch die Kommunikation des XRAY- High-Level Debuggers mit dem Monitorprogramm über diese Schnittstelle statt. Aus diesem Grund mußte der entsprechende Testschritt komplett implementiert und dann in Eproms gebrannt werden. Diese wurden gegen die Monitor-Eproms ausgetauscht und so konnte auch die Funktion dieses Testschritts überprüft werden.

Auf diese Weise wird auch die komplette Programmierung des Testprints im Testrahmen zur Verfügung gestellt: Das Programm ist in den beiden Eproms (M27C4001) abgelegt, die auf der RAM-Karte eingesteckt sind. Die RAM-Karte ist Bestandteil des Hardwareadapters und verbleibt im Testrahmen.

Als Meßgeräte standen sowohl Speicheroszilloskop als auch ein Logik-Analyser der Firma Philips zur Verfügung.

4.2. Strukturierung der Implementation

Die Programmstruktur wurde modular aufgebaut und hierarchisch untergliedert. Dabei soll sichergestellt sein, daß das entwickelte Kommunikationsprotokoll als eigentliche Schnittstelle nicht redundant implementiert wird. Da außerdem eine mögliche Erweiterung problemlos realisierbar und eine einfache Wartbarkeit gewährleistet werden sein soll, wurde zur Implementierung die Programmiersprache C++ gewählt. Diese bietet aufgrund strenger Modulabgrenzungen, strikt definierter Schnittstellen, Ableitbarkeit von Funktionen und nicht zuletzt durch den Polymorphismus deutliche Vorteile gegenüber dem "normalen" C und ist deshalb für die Realisierung dieses Projekts gut geeignet.

Die einzelnen Klassen wurden hierbei in verschiedenen Quellcode-Dateien realisiert, um die Übersichtlichkeit zu erhöhen. Deklarationen wurden in entsprechenden Header-Dateien vorgenommen und einige Funktionen in Maschinensprache realisiert. Aus den einzelnen Quellcode-Dateien wurden die Objektfiles erzeugt und diese anschließend mit dem Linker zu einem, auf dem Zielsystem, lauffähigen Programm verbunden. Das Programm wurde dann, entweder in die beiden Eproms gebrannt, oder über den XRAY- High-Level Debugger in das RAM der Zielhardware geladen. Damit nach Änderungen an den Quellcode-Dateien auch die Objektfiles aktualisiert wurden, kam das nachfolgend als Auszug abgebildete Makefile zum Einsatz:

4.2.1. Klassenhierarchie

Das gesamte Projekt ist auf zwei Basisklassen aufgebaut: die Klasse "Tester" und die Klasse "Testschritt". Alle weiteren Klassen und auch Basisklassen sind von der Klasse Testschritt abgeleitet.

Die Basisklasse "Tester" stellt alle notwendigen Elementfunktionen zur Kommunikation mit dem Hardwareadapter zur Verfügung. Aus dieser Klasse wird eine Instanz erzeugt und global bekanntgegeben. So können alle Klassen auf die Elementfunktionen zugreifen.

Die Basisklasse "Testschritt" stellt neben Standardkonstruktor und Standarddestruktor die rein virtuelle Elementfunktion "Run()" zur Verfügung. Diese Elementfunktion ist die Schnittstelle zwischen dem aufrufenden Hauptprogramm und der eigentlichen Testschritt-Implementierung. Somit kann aus der Basisklasse "Testschritt" selbst keine Instanz erzeugt werden, da nur ein Funktionsrumpf, eben die virtuelle Funktion, zur Verfügung gestellt werden könnte. Jede von dieser Basisklasse abgeleitete Klasse überlädt diese Funktion mit spezifischen Programmteilen, behält jedoch die vordefinierte Schnittstelle zum aufrufenden Programm unverändert bei. Hier kommt also ein deutlicher Vorteil von C++ zur Geltung, das Überladen von Funktionen.

Von der Basisklasse "Testschritt" wurde die Klasse "IntTestschritt" als eine weitere Basisklasse abgeleitet. Diese behält wiederum die vordefinierte Schnittstelle bei, stellt jedoch den von ihr abgeleiteten Instanzen weitere Elementfunktionen zur Verfügung. Diese sind speziell auf die Handhabung von Interrupts zugeschnitten und stellen somit wieder eine vordefinierte Schnittstelle zum Interrupthandling dar.

In Abbildung 20 ist diese Klassenaufteilung nochmals graphisch dargestellt. Dabei wurden die Klassen nach den Bezeichnungen der Testschritte benannt. Symbolisch soll auch dargestellt werden, wie ein Aufruf der Run()-Funktion während der Laufzeit aussieht und wie die Kommunikation abläuft. Dabei sollen die Klassennamen nur bildlich für die von ihnen kreierten Instanzen stehen.

4.3. Programmabarbeitung zur Laufzeit

Nach einem Reset-Signal startet der Testprint mit der Abarbeitung des Programmcodes, welcher an der ROM-Basisadresse, also dem Eprom, abgelegt ist. Der Quellcode, der dort abgelegten Initialisierungsroutine, ist in Assembler implementiert und definiert neben der Zuweisung der Interrupt-Vektoren und Adressen der Interrupt-Serviceroutinen auch den Einsprungspunkt ins Hauptprogramm.

4.3.1. Erzeugen und Initialisieren der Instanzen

Aus der Initialisierungsroutine erfolgt ein absoluter Sprung in das Hauptprogramm. Dort wird eine globale Instanz der Basisklasse "Tester" erzeugt und dabei vom Konstruktor der Handshake gestartet Anschließend wird von jeder Testschritt-Klasse eine oder ggf. mehrere statische Instanzen erzeugt und in einem Array jeweils ein Zeiger auf die einzelnen Instanzen angelegt. Dabei entspricht jeder Index des Arrays einem Testschritt.

Teilweise werden mehrere Testschritt-Instanzen aus einer Klasse erzeugt, z.B. fünf Instanzen aus der Klasse "WaitState". Die Erklärung hierfür ist recht einfach: Der Unterschied zwischen diesen Testschritten ist lediglich das entsprechende Zeitfenster, also die Angabe, welche minimale, bzw. maximale Grenze der Wartezyklus-Dauer eingehalten werden muß. Es wäre nicht sinnvoll, denselben Testvorgang mehrfach identisch zu implementieren und lediglich andere Parameterwerte zu verwenden. So werden dem Konstruktor die entsprechenden Parameter übergeben und im privaten Datenbereich der Instanz abgelegt und diese damit initialisiert. So erklärt sich auch die unterschiedliche Anzahl von Testschritten und Testschritt-Klassen: von 4 Klassen werden mehr als eine Instanz erzeugt.

4.3.2. Aufruf und Ausführung der entsprechenden Instanzen

Nachdem alle Instanzen erzeugt und die jeweiligen Zeiger in dem Array abgelegt wurden, wird durch das Hauptprogramm eine Endlosschleife gestartet. In dieser Schleife wird auf die gültige Eingabe eines Befehlscode an der BefehlscodeIN-Schnittstelle des Hardwareadapters gewartet. Dabei werden Elementfunktionen der Basisklasse "Tester" verwendet und es erfolgt die Übergabe der Befehlscode-Quittierung an die Tester-Instanz. Anschließend wird die erhaltene Testschrittnummer als Index für das Array verwendet und die entsprechende Elementfunktion "Run()" gestartet, welche durch den indizierten Zeiger des Arrays dem Testschritt zugeordnet ist. Die Run()-Funktion übergibt am Ende ihrer Abarbeitung der Tester-Instanz die entsprechenden Werte für "Ergebnis" und "Datenbus-OUT" über die öffentlichen Schnittstellen. Nachdem der Testschritt komplett abgearbeitet ist, wird im Hauptprogramm die Funktion der Tester-Instanz zur Ausgabe der aktualisierten Daten an den "Datenbus-OUT", "BefehlscodeOUT" und "Ergebnis" Schnittstellen aufgerufen. Somit ist ein Schleifendurchlauf beendet.

Zur Veranschaulichung dieses Sachverhalts ist in dem nachfolgenden Programm 7 ein Auszug aus dem Hauptprogramm dargestellt.

5. Inbetriebnahme, Test und Projektabschluß

Die Inbetriebnahme der gesamten Testanordnung, also den Komponenten BETA-Tester mit Stapelverarbeitungsprogramm und Peripherie, dem Hardware und Nadeladapter sowie dem auf dem Testprint ablaufenden Programm erfolgte inkrementell. Laut Pflichtenheft [20] war das BETA-Stapelverarbeitungsprogramm und der Hardwareadapter von der Abteilung TP-S zu erstellen. So war es während des Projekts notwendig, in gewissen Zeitabständen die entwickelten Komponenten aufeinander abzustimmen.

Diese Abstimmung erfolgte anfangs mit Hilfe der auf der BETA-Simulation (siehe Abb.:17) zur Verfügung gestellten Anschlüssen für die Peripherie des BETA-Testers. Dabei wurde als Testprint der Rechnerprint verwendet, auf welchem die Testschritte erstellt wurden. Mit dem weiteren Fortschritt bei der Implementierung und dem Aufbau des Hardwareadapters erfolgte die Inbetriebnahme der weiteren Testschritte immer realitätsnäher.

Schließlich war der Stand erreicht, daß die weitere Implementierung der Slave-Software nicht mehr auf der BETA-Simulation überprüft werden konnte, da die notwendigen Funktionen des Hardwareadapters auf der BETA-Simulation nicht realisiert waren. Zu diesem Zeitpunkt mußte nach jeder Änderung in der Implementierung ein neuer Satz Eproms angefertigt und anschließend zusammen mit dem Hardwareadapter seine Funktion überprüft werden. Es stellte sich heraus, daß bei der Entwicklung des Hardwareadapters die Zusammenhänge richtig erkannt wurden, weshalb die Inbetriebnahme des Hardwareadapters keine großen Schwierigkeiten bereitete. Auch die Anpassung der Slave-Software gelang im letzten Abschnitt der Inbetriebnahme recht gut, mit Ausnahme des Adressbustest (vgl. Kapitel 4.3.36.).

Nachdem alle Testschritte auf der Testanordnung abgearbeitet werden konnten, wurde anstelle der bisher zum Testprint benutzten Verbindungsleitungen der Nadeladapter eingesetzt. Somit waren jetzt auch alle mechanischen Bestandteile in die Inbetriebnahme eingebunden. Dadurch war es nun wesentlich einfacher, die Testprints auszutauschen, da keine aufwendigen Verkabelungen mehr notwendig waren.

Nun konnte die Feinabstimmung der Software auf die erlaubten Toleranzen der Testprints erfolgen und ebenso Optimierungen der Bedienerführung und Testsequenz vorgenommen werden. Dabei auftretende Ungereimtheiten wurden behoben. Während dieses Projektstands wurde die "Testschritt- und Fehlerdokumentation M256 CPU-Platte" erstellt, welche als Anhang A dieser Diplomarbeit beiliegt.

5.1. Testplan

Um sicherzustellen, daß auch wirklich jeder Testschritt die Funktion der entsprechenden Komponente richtig überprüft, wurde der Testplan entwickelt. Der Testplan (siehe Anhang B) enthält sog. Negativtests. Bei diesen Negativtests wird ein Defekt in der jeweiligen Komponente gezielt hervorgerufen und die Reaktion des Testschritts ausgewertet. Keine Manipulation auf dem Testprint durfte dabei verborgen bleiben.

Bei manchen Testschritten, z.B. bei der Überprüfung der Wait-Stateszeit, wurden Abweichungen in beide Richtungen simuliert, andere Funktionen, z.B. die Funktion von Adress- und Datenbus konnten nicht manipuliert werden, da dadurch gar kein Anlaufen der Testsoftware möglich wäre. Aus dieser Tatsache heraus kann jedoch auch sicher davon ausgegangen werden, daß ein Defekt auf einem Bussytem in jedem Fall erkannt wird. Somit stellt der Verzicht auf den Negativtest dieser Testschritte kein Problem dar.
Die durchgeführte Manipulation, die erwartete und erhaltene Reaktion darauf, sowie eine Bewertung der Reaktion sind im Anhang B für jeden Testschritt dargestellt.

5.2. Feldtest

Im Anschluß an die erfolgreiche Inbetriebnahme und die Überprüfung der Testanordnung laut Testplan erfolgte der Feldtest. Dieser war in zwei Stufen untergliedert:

In der ersten Stufe wurden von der Fertigung insgesamt 23 Rechnerprints zur Verfügung gestellt. Sie waren bereits auf konventionelle Art funktionsgeprüft worden und dabei wurden bei 8 Rechnerprints Fehlfunktionen festgestellt.

Alle Rechnerprints wurden nun einer Endkontrolle nach den im Rahmen dieser Diplomarbeit entwickelten Prüfalgorithmen unterzogen und dabei das Testergebnis der vorausgegangenen konventionellen Überprüfung in vollem Umfang bestätigt werden.

In der zweiten Stufe wurde eine Fertigungsserie von 170 Rechnerprints mit dem entwickelten Verfahren geprüft und dabei 5 Rechnerprints als defekt erkannt. Bei zwei dieser Rechnerprints konnte die Reparatur aufgrund der Hinweise in der "Testschritt- und Fehlerdokumentation M256 CPU-Platte" sofort erfolgreich ausgeführt werden.

5.3. Vergleich zum bisherigen Verfahren

Der wesentliche Unterschied zwischen konventioneller und neu entwickeltem Testverfahren liegt in der Zeitersparnis. Für die konventionelle Endkontrolle mußte der Testprint in 2 verschiedene Endprodukte eingebaut werden um alle Funktionen überprüfen zu können. Für den Ein- und Ausbau, sowie die Funktionsprüfung wurden dafür ca. 30 Minuten je Testprint benötigt.

Ein Testdurchlauf auf dem BETA-Tester benötigt hingegen nur 102 Sekunden und gibt darüber hinaus im Fehlerfall auch noch Hinweise auf mögliche Fehlerursachen.

Betrachtet man nun beide Verfahren unter den Gesichtspunkten Effektivität, Rationalisierung und Qualitätssicherung, so schneidet die neu entwickelte Vorgehensweise in jedem Fall besser ab. Durch die einfache Handhabung ist die Gefahr von Fehlbedienungen gering, die fest vorgegebene Sequenz stellt eine vollständige Durchführung aller Testschritte sicher, was eine gleichbleibende Qualität gewährleistet. Durch die Zeitersparnis um den Faktor 17 wird die Effektivität gesteigert und ein Beitrag zur Kostensenkung geleistet und somit eine rationellere Fertigung ermöglicht.

Doch die Effektivitätssteigerung beschränkt sich nicht nur auf den Testvorgang selbst. Durch die Hinweise auf mögliche Fehlerursachen in den bereitgestellten Unterlagen und die Einführung der Fehlerbibliothek (siehe Anhang A) kann auch die Reparatur schneller ausgeführt werden.

5.4. Abschluß des Projekts

Mit dem Ergebnis der zweiten Stufe des Feldtests wurde das Projekt beendet, die Anforderungen des Pflichtenhefts sind erfüllt worden, was vom Auftragnehmer bestätigt wurde. Alle Projektunterlagen wurden nach den im Hause effeff Fritz Fuss üblichen Verfahren archiviert.

6. Zusammenfassung

Im Rahmen dieser Diplomarbeit war eine komplette Testanordnung zu entwickeln. Die Entwicklung umfaßte dabei die Analyse der bisherigen Testbedingungen, die Überarbeitung und die Erweiterung der Testvorschläge.

Daraus entstand das Pflichtenheft, welches die Grundlage für das Projekt darstellte. Entsprechend den darin definierten Anforderungen wurde das Projekt in Phasen aufgeteilt.

6.1. Projektverlauf

Zuerst mußte ein Kommunikationsprotokoll ausgearbeitet werden, welches in der Lage ist, mit den bisherigen Testgeräten Informationen auszutauschen. Auch der Entwurf der entsprechenden Hardware war Bestandteil dieser Phase.

Nachdem diese Kommunikations-Voraussetzungen geschaffen waren, wurde die Zusatzhardware sowie die BETA-Simulation entworfen, und letztere auch realisiert. Im Zuge der Inbetriebnahme der BETA-Simulation wurden erste Erfahrungen im Umgang mit dem Testprint und den vorhandenen Softwarewerkzeugen gemacht. Nach erfolgreichem Abschluß dieser Projektphase wurde mit der Implementierung der Testschritte begonnen.

Da die Realisierung der Testalgorithmen nicht ausschließlich im Softwarebereich stattfand, war die ständige Anpassung und Erweiterung der BETA-Simulation auch Bestandteil der Implementierungsphase. Diese war der umfangreichste Projektteil, was auch in der Zeitplanung entsprechend vorgesehen war.

Der Übergang zur letzten Projektphase ist fließend, da auch schon während der Implementierung einige Testschritte zusammen mit dem BETA-Stapelverarbeitungsprogramm in Betrieb genommen wurden. Allerdings wurden in dieser Phase doch noch einige Anpassungen durchgeführt, umfangreichere Änderungen waren nicht notwendig

Die Erstellung der Dokumentation sowie der Test der entwickelten Anordnung bildeten den Abschluß des Projektes.


Der gesamte Projektablauf fand kontinuierlich statt, Verzögerungen in einzelnen Phasen konnten durch den frühzeitigen Abschluß ausgeglichen werden. Alle im Pflichtenheft definierten Anforderung wurden erfüllt, und somit konnte die Diplomarbeit zu einem erfolgreichen Abschluß gebracht werden.

6.2. Beurteilung der Aufgabenstellung und Ausblick

Bei der Bearbeitung des Projektes wurde klar, daß bei der Anpassung von Weiterentwicklungen die Abwärtskompatibilität immer einen Kompromiß darstellt. Durch die Eigenschaften des hier zum Einsatz kommenden BETA-Testers mußten zahlreiche Konventionen eingehalten und Anpassungen vorgenommen werden, die in modernen Testsystemen entsprechender Anbieter bereits integriert sind.

Der BETA-Tester mag sicher seine Existenzberechtigung im Bereich einfacher Logikschaltungen haben, zum Test von komplexen Mikrocomputerkarten sollte seine Eignung nochmals überdacht werden. Zwar wurde durch die vorliegende Diplomarbeit gewisse Grundlagen zur Adaption von Rechnerprints an die BETA-Umgebung geschaffen. Diese beschränken sich aufgrund der Individualität solcher Prints jedoch auf das Kommunikationsprotokoll und die generelle Verfahrensweise. Speziell die Erstellung und Wartung der BETA-Stapelverarbeitungsdatei ist aufgrund der Unübersichtlichkeit keine einfache Aufgabe.

Vielmehr sollte über die Verwendung moderner Testverfahren, wie z.B. dem Boundari-Scan oder dem Background-Debug-Mode, nachgedacht werden. Weiterhin sollte bereits bei der Entwicklung neuer Hardwarebaugruppen über die möglichen Testverfahren nachgedacht werden, um so eine schnellere Produktentwicklung zu ermöglichen.

DIPLOM.HTM Version 2.4 Last changed 20.10.2013 wez