Der Anwender von SerialSniffer ist in 99% der Fälle ein Software-Entwickler. Typischerweise wird ein externes Gerät über eine serielle Schnittstelle mit einem PC verbunden, auf dem ein Steuerungsprogramm zu dem externen Gerät läuft. Das externe Gerät kann sein: ein Messgerät, ein Diaprojektor, ein Drucker, ein Barcode-Scanner, ... Die serielle Schnittstelle wird „aufgetrennt“ und SerialSniffer dazwischen geschaltet. SerialSniffer reicht zunächst alle Daten von links und rechts und umgekehrt durch, protokolliert und ggf. manipuliert außerdem dabei alle Daten.
Test eines komplexeren Systems: es gibt eine Testanweisung, SerialSniffer protokolliert alles mit und das Log kommt als Anhang an das Testprotokoll. Wie aber testet man, wie das System mit Fehlern auf der seriellen Schnittstelle umgeht? Im schlimmsten Fall stürzt es ab. SerialSniffer bekommt dazu Regeln, welche Daten es wie zu verändern hat. Z.B. Datensätze verkürzen oder zusätzliche Daten (Datenmüll) einfügen, Checksummen verändern etc. Es ist nicht zulässig, diese Änderungen in den Testkandidaten einzubauen, da man ja dann nicht mehr das testen würde, was man eigentlich wollte. Mit SerialSniffer ist dies auch nicht nötig.
SerialRecorder: Wir hatten mal die Aufgabe, einen Fahrtenschreiber für ein Fährschiff zu bauen. Der Schiffscomputer gab auf einer seriellen Schnittstelle alle relevanten Daten aus und zwar als Einbahnstraße (es gingen keine Daten zurück an den Schiffscomputer). Während der Entwicklung ständig zum Testen auf dem Schiff mitzufahren, ging nicht. Also haben wir die Daten mit dem SerialRecorder aufgezeichnet (wie bei einem Tonband) und konnten das dann im Labor beliebig oft wieder abspielen.
Ein Entwickler bekommt ein bestehendes System aus einem externen Gerät und einer PC-Software auf den Tisch. Dokumentation Fehlanzeige. Irgendetwas soll repariert werden oder die PC-Software durch eine neue Version ersetzt werden. Wie bekommt man heraus, wie das Ganze funktioniert? Lösung: Alle Funktionen durchspielen und SerialSniffer den Datenaustausch protokollieren lassen. Der Rest ist übliche Detektivarbeit.
Ein komplexeres System macht hin und wieder Fehler. SerialSniffer protokolliert alle Daten mit und wenn der Fehler auftritt, kann man im Log nachgucken, was passiert ist. Beispiel: Ein Drucker in der Industrie soll Verpackungen bedrucken. Manchmal lässt er eine Packung aus und bedruckt diese nicht. Es stellte sich heraus, dass genau in diesen Fällen der Drucker vom vorgeschalteten System (ein Barcode-Scanner) keine Daten bekommen hat und deswegen auch nichts zu drucken hatte. Der Fehler lag also im Scanner.
Entwicklungsbüro Flache | 24147 Kiel | Tiroler Ring 2 | Tel.: +49 431 6793970-0 | Fax: +49 431 6793970-1 | E-Mail: 
DE
ENG