DE19835630A1 - Verfahren und Schaltungsanordnung zur Überprüfung von in ein Datenverarbeitungssystem einzubindenden Programmodulen - Google Patents

Abstract

Die Benutzung eines ersten Kommunikationsweges für einen Offline-Test und die Benutzung eines zweiten Kommunikationsweges für einen Online-Test eines in einem Datenverarbeitungssystem einzufügenden Programmoduls ermöglicht die Verwendung des gleichen Testmoduls für beide Testzyklen.

Description

In Übertragungsnetzwerken, insbesondere in denen Daten mit unterschiedlichen Bitraten innerhalb einer synchronen digita­ len Hierarchie übertragen werden, sind eine Vielzahl von Netzelementen angeordnet. Diese Netzelemente fassen entweder eine Vielzahl von Datenströmen niederer Bitrate zu einem Da­ tenstrom höherer Bitrate zusammen oder es werden mit Hilfe der Netzelemente beispielsweise aus einem Datenstrom höherer Bitrate Teildatenströme aus- oder eingekoppelt.

Gesteuert bzw. eingestellt werden die Netzelemente über ein Equipment Management Operations System, das nachfolgend als übergeordnete Bedienereinheit bezeichnet wird. An die überge­ ordnete Bedienereinheit ist eine Vielzahl der Netzelemente anschließbar. Mit einer übergeordneten Bedienereinheit können die einzelnen Netzelemente im Übertragungsnetzwerk angesteu­ ert bzw. konfiguriert werden. Die Netzelemente sind jeweils so strukturiert, daß über einen im Netzelement integrierten Steuer- und Überwachungsprozessor ein Zugang zu peripheren Einheiten unterschiedlichster Baugruppentypen besteht. Diese peripheren Einheiten sind Steckkarten mit jeweils einem eige­ nen Prozessor, der von dem Steuer- oder Überwachungsprozessor des Netzelementes über Kommandoschnittstellen gesteuert wird. Die übergeordnete Bedienereinheit steuert über Anreize, die auch als Telegramme bezeichnet werden können, den Steuer- und Überwachungsprozessor der Netzelemente. Mit in den Steuer- und Überwachungsprozessor integrierten Anwender-Programmodu­ len werden die Anreize von der übergeordneten Bedienereinheit und von den peripheren Einheiten abgearbeitet.

Bisher wurden Änderungen, beispielsweise in dem Anwender-Pro­ grammodul, durch eine eigene zur Überprüfung der Änderung entwickelten Aktionsanreizer getestet. Ein in der Testumge­ bung angeordneter Aktionsanreizer simuliert und empfängt An­ reize, die von übergeordneten oder untergeordneten Einheiten an das Anwender-Programmodul im Steuer- und Überwachungsrech­ ner abgeschickt werden.

Zu einem Offline-Test eines neu in einen Steuer- und Über­ wachungsrechner integrierten Anwender-Programmoduls müssen dazu eigene Programmodule für den Aktionsanreizer geschrieben werden. Eine erste Überprüfung des neuen Anwender-Programmo­ duls erfolgt innerhalb eines Prüfplatzes mit einem Hostrech­ ner.

Wird nun das neue Anwender-Programmodul beispielsweise in einem Steuer- und Überwachungsrechner innerhalb des Netzele­ mentes implementiert, so müssen hierfür sich vom Offline-Test unterscheidende Testmodule für den Online-Test erstellt werden.

Dies bringt den Nachteil mit sich, daß der Aktionsanreizer mehrfach in unterschiedlicher Ausgestaltung und jeweils zuge­ schnitten auf die jeweilige Testumgebung erstellt werden müssen.

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren und eine Schaltungsanordnung zum Überprüfen von in einem Daten­ verarbeitungssystem einzubindende Programmodule anzugeben.

Gemäß der Erfindung wird die gestellte Aufgabe durch die Pa­ tentansprüche 1 und 5 gelöst.

Die Erfindung bringt den Vorteil mit sich, daß nur ein Test­ modul für einen Offline- und Online-Test benötigt wird.

Die Erfindung bringt den weiteren Vorteil mit sich, daß das Testmodul modular aufgebaut ist.

Die Erfindung bringt den weiteren Vorteil mit sich, daß bei einer Modifikation, einem Einfügen oder Ändern von Leistungs­ merkmalen in bestehende Anwender-Programmodule einzelne An­ reize nur partiell geändert werden müssen.

Die Erfindung bringt den Vorteil mit sich, daß früher er­ stellte Testszenarien oder Anreize ebenfalls zum Test neuer Anwender-Programmodule verwendet werden können.

Weitere vorteilhafte Ausbildungen der Schaltungsanordnung und des Verfahrens sind in den weiteren Patentansprüchen angege­ ben.

Weitere Besonderheiten der Erfindung werden aus den nachfol­ genden näheren Erläuterungen eines Ausführungsbeispieles an­ hand von Zeichnungen ersichtlich.

Es zeigen:

Fig. 1 eine Testumgebung für einen Offline-Test,

Fig. 2 eine Testumgebung für einen Online-Test und

Fig. 3 die Architektur eines Testmoduls.

In Fig. 1 ist eine Testumgebung für einen Offline-Test mit einem Hostrechner gezeigt. Die wesentlichen Einheiten sind ein Testmodul NTE, ein zu testendes Testobjekt TO, z. B. ein Anwender-Programmodul, sowie ein Betriebssystem B eines Host­ rechners HS und ein Interprozeß-Kommunikationsdatenbus IPG der zwischen dem Testmodul NTE und dem Testobjekt TO angeord­ net ist.

Das Testobjekt TO beinhaltet ein oder mehrere Teile eines zu testenden Anwender-Programmoduls, das beispielsweise für eine Verarbeitungseinheit eines Steuer- und Überwachungsprozessors entwickelt wurde. Die für einen Test simulierten Anreize des Testmoduls NTE werden über einen ersten Kommunikationsweg, den interprozeß-Kommunikationsdatenbus IPC, an das Testobjekt TO weitergegeben. Anstelle des Interprozeß-Kommunikations­ datenbus IPC kann auch die Kommunikation innerhalb des Host­ systems über eine Windows Socket Kommunikation erfolgen. Der Hostrechner HS steuert die nötigen Protokolle zwischen dem Testobjekt TO und dem Testmodul NTE.

Die Ausgestaltung der Ansteuerungsfunktion hängt von dem In­ terprozeß-Kommunikationsdatenbus IPC sowie der Ausführungs­ laufzeit innerhalb des Hostrechners HS ab. Im einfachsten Fall lassen sich Send- und Receive-Kommandos auf entsprechen­ de Send- oder Receive-Aufrufe des Interprozeß-Kommunikations­ datenbusses IPC abbilden. In einzelnen Fällen muß vor dem ersten Send- oder Receive-Kommando erst eine entsprechende Initialisierung der Kommunikation stattfinden, mit der ein Kommunikationskanal geöffnet und zugewiesen wird. Die Initia­ lisierung kann mittels eines Open-Kommandos angestoßen werden. Bei dem Receive-Kommando ist eine Unterscheidung zu treffen, ob die Anwendung warten muß, bis eine Nachricht tat­ sächlich empfangen werden kann oder ob ein Aufruf gleich zu­ rückkehrt, auch wenn keine Nachricht empfangen wurde.

Sowohl bei einer Kommunikation über den Interprozeß-Kommuni­ kationsdatenbus IPC als auch über einen ersten und zweiten Protokoll-Stapel PSH, PST wird der eigentlichen Nutz-Nach­ richt, die das zu überprüfende Anwender-Programmodul verar­ beiten kann, ein Kopf hinzugefügt. Von wem dieser Kopf hinzu­ gefügt wird, hängt davon ab, ob die Nachricht gesendet oder empfangen wird.

Im Vorspann bzw. Kopf des Anreizes werden zur Bearbeitung des Anreizes dazu folgende Informationselemente vermerkt: Identifikator; Zeit; Kennzeichen für eine Peripherie­ schnittstelle, Q-Schnittstelle - z. B. eine Q3 Schnittstelle; Kennzeichen für Kodierungsregel - z. B. Schicht 7 eines OSI-Schichtenmodels, lean encoding, Richtung und Kommentar.

Nachfolgend eine Abfolge zur Ansteuerung des Interprozeß-Kom­ munikationsdatenbusses IPC mit denen ein Anreiz vom Testmodul NTE zum Testobjekt TO geschickt wird. Nachdem eine Vereinba­ rung und Bestimmung der Variablen im Kopf des Anreizes abge­ schlossen ist, wird ein Speicherplatz für den zu übertragen­ den Anreiz bestimmt und dieser im Speicherplatz zwischenge­ speichert. Nachdem vom Tester ein Empfangsprozeß eingegeben, ein Übertragungskanal gewählt und ein Zeiger auf den Anreiz gerichtet ist, wird dieser an den Empfänger im Testobjekt TO weitergegeben. Der Empfänger gibt daraufhin den Speicher frei. Zum Versenden des Anreizes erfolgt ein Aufruf an den Interprozeß-Kommunikationsdatenbus IPC.

In Fig. 2 ist eine Testumgebung gezeigt für ein in einem Zielsystem TS, beispielsweise in einem Netzelement eines Übertragungsnetzwerkes, zu integrierendes Programmodul. Daß zu integrierende Programmodul wird nachfolgend als Testobjekt TO bezeichnet. Das Zielsystem wird auch als Targetsystem be­ zeichnet. Die wesentlichen Einheiten der Testumgebung zum Test für einen Online-Test sind das Testmodul NTE, ein erster Protokoll-Stapel PSH im Hostrechner HS, ein zweiter Proto­ koll-Stapel PST und Verteiler V im Zielsystem TS. Der im Zielsystem TS angeordnete zweite Protokoll-Stapel PST korres­ pondiert über eine Verbindungsleitung K mit dem zweiten Pro­ tokoll-Stapel PSH im Hostrechner HS.

Bei dieser Anbindung des Testmodules NTE ist die Ausprägung der Ansteuerungsfunktion von der Zugangsschnittstelle des ersten Protokoll-Stapels PSH abhängig. Eine Verbindung zwischen dem Testmodul NET wird über eine Verbindungsproze­ dur, z. B. einem CONNECT mit dem Protokoll-Stapel PSH im Host­ rechner HS verbunden, bevor Anreize transferiert werden kön­ nen. Beim Receive-Aufruf wird nicht gewartet bis eine Nach­ richt tatsächlich angekommen ist, sondern gleich wieder die Kontrolle an den Anwender zurückgegeben. Als weitere Bei­ spiele für einen Protokoll-Stapel können ein OSI-Stack, ein TCP/IP- oder ein HDLC-Stack angeführt werden.

Bevor der Anreiz vom Testmodul NTE über die Verbindungslei­ tung K zum Testobjekt TO gesendet wird, muß vor einer Einbe­ ziehung des ersten Protokoll-Stapels PSH dieser initialisiert und eine Verbindung zum Testmodul NTE aufgebaut werden. Ent­ sprechende Prozeduren sind bei einem Senden von beispiels­ weise einer Anreizantwort vom Testobjekt TO zum Hostrechner H abzuwickeln.

In Fig. 3 sind die wesentlichen Teile der Architektur des Testmoduls NTE wiedergegeben. Die Architektur des Testmoduls NTE gliedert sich im wesentlichen in zwei Einheiten auf. Die erste Einheit NTEA des Testmoduls NTE dient zur Erstel­ lung von Anreizen oder Anreizsequenzen, die zweite Einheit NTEB des Testmoduls NTE dient zur Auswahl der Anreize oder Anreizsequenzen und der Ansteuerung für einen Offline-Test oder Online-Test sowie zur Archivierung der empfangenen An­ reize oder Anreizsequenzen.

Über die erste Einheit NTEA des Testmoduls NTE kann der Tes­ ter Anreize auf der Grundlage von Schnittstellenbeschreibun­ gen bilden, kopieren oder modifizieren.

Mit der zweiten Einheit NTEB des Testmoduls NTE ist der Tes­ ter in der Lage, Testszenarien zu stimulieren, Testzyklen an­ zustoßen, zu verändern und aktuelle Testergebnisse mit Soll-Testergebnissen zu vergleichen.

Die wesentlichen Bestandteile der ersten Einheit NTEA des Testmoduls NTE sind eine Speichereinheit DF zum Abspeichern von Anreiztypen, die mittels den Guidelines for Definition of Managed Objects GDMO und der Abstract Syntax Notation One ASN.1 spezifiziert sind, ein Übersetzer P, eine Anreizerstel­ leinheit TE sowie ein Anreiz-Repository TR zur Abspeicherung der von der Anreizerstelleinheit TE gebildeten Anreize.

In der zweiten Einheit NTEB des Testmoduls NTE sind die we­ sentlichen Einheiten ein Tool Commande Language Interface TCLI, ein Adapter zwischen dem Tool Command Language Inter­ face und ein Kommunikationsmodul KM sowie der zweite Proto­ koll-Stapel PST. Über das Kommunikationsmodul KM können An­ reize wie oben bereits beschrieben geladen, verschickt und empfangen werden. Über ein erstes Modul TI des Kommunikati­ onsmoduls KM hat man einen Zugriff auf die Speichereinheit DF, über ein zweites Modul Read/Write RWT des Kommunikations­ moduls KM hat man einen Zugriff auf die Anreize, die im An­ reiz-Repository TR abgelegt sind. Über das zweite Modul Read/Write RWT hat man auch einen Zugriff auf einen Daten­ speicher TLF, in dem die Anreiz-Log-Files TLF abgespeichert sind. Über das dritte Modul Send/Receive SRT des Kommunikati­ onsmoduls KM können Anreize vom und zum Testobjekt TO gesen­ det und empfangen werden, das entweder in einem Hostrechner HS oder Targetsystem TS integriert ist.

Über eine erste Schnittstelle OFFS in der ersten Einheit NTEA des Testmoduls NTE kann der Tester neue Anreize entwerfen. Über eine zweite Schnittstelle ONS kann der Tester zusätzli­ che Testszenarien bilden und aktuelle Testdaten mit Solltest­ daten vergleichen.

Der im ersten Teil NTEA des Testmoduls NTE angeordnete Über­ setzer P transformiert die in einem Speicher S hinterlegten Schnittstellenbeschreibungen in eine von der Anreizerstel­ leinheit TE lesbare Maschinensprache. Bei einer Veränderung der Definition der Schnittstelle wird jeweils eine neue Datei gebildet. Der Anreiz bzw. das Telegramm, das durch die Anrei­ zerstelleinheit TE gebildet wird, wird im Anreiz-Repository TR in einem Editorformat gespeichert bzw. gesichert.

Ein Zugang zum zweiten Teil NTEB des Testmoduls NTE ist, wie oben erwähnt, durch das Tool Command Language Interface TCLT bzw. Shell möglich. Über eine zweite Schnittstelle ONS des Moduls Tool Command Language Interface TCLI hat zum einen der Tester Zugriff auf die Tools in der Testumgebung, und zum an­ deren können über die Schnittstellen Daten in einem Tool Command Language Script TCLS abgelegt werden. Dieses Tool Command Language Interface TCLI erlaubt dem Tester die Aus­ führung von Tool Command Language Kommandos in einem Interak­ tiven Mode. Ebenso ist ein Start von Tool Command Language Script im Batch Mode möglich. Mit den Mitteln des Tool Com­ mand Language Interfaces TCLI hat der Tester die nötige Flexibilität, die Eigenart eines jeden existierenden und zu testenden Systems zu simulieren. Dies ist möglich, weil das Tool Command Language Interface die gleichen Erklärungen für eine Flußkontrolle wie eine gebräuchliche Programmierungs­ sprache aufweist. Die Tool Command Language Interface TCLI Kommandos und die Tool Command Language Interface Beschrei­ bungen werden sofort ausgeführt, da die Tool Command Language Sprache nicht übersetzt wird. Nach der Ausführung eines Tool Command Language Kommandos geht die Programmausführung zurück zum Tool Command Language Shell.

Claims (6)

1. Verfahren zur Überprüfung von mindestens einem Programmo­ dul, das in einem Anwender-Programmodul eines Datenverarbei­ tungssystems zu integrieren ist, dadurch gekennzeichnet,
daß bei einem Offline-Test Anreize über einen ersten Kommuni­ kationsweg in einem Hostrechner (HS) zwischen einem in einem Hostrechner (HS) integrierten Testmodul (NTE) und dem Pro­ grammodul erfolgen,
daß bei einem Online-Test Anreize über einen zweiten Kommuni­ kationsweg zwischen dem im Hostrechner (HS) integrierten Testmodul (NTE) und dem in das Datenverarbeitungssystem in­ tegrierte Programmodul erfolgen.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der erste Kommunikationsweg durch ein Interprozeß-Kommu­ nikationsprotokoll (IPC) bestimmt wird.

3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der zweite Kommunikationsweg mit einem Q-Schnitt­ stellen-Protokoll erfolgt und die Daten über einen ersten Proto­ koll-Stapel (PSH) im Hostrechner (HS) über eine Verbindungsleitung (K) zu einem zweiten Protokoll-Stapel (PST) und einem Vertei­ ler (V) zu dem Testobjekt (TO) in einem Zielsystem (TS) führt.

4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Anreize Testkommandos sind.

5. Schaltungsanordnung zur Überprüfung von Programmodulen die in Anwender-Programmodulen eines Datenverarbeitungssystems zu integrieren sind, dadurch gekennzeichnet,
daß zwischen einem Testmodul (NTE) und einem Testobjekt (TO) ein erster Kommunikationsweg (IPC) zur Anreizübertragung für einen Offline-Test, und
daß zwischen einem Testmodul (NTE) und einem in einem Zielsy­ stem integrierten Testobjekt (TO) ein zweiter Kommunikations­ weg für einen Online-Test vorgesehen ist.

6. Schaltungsanordnung nach Anspruch 5, dadurch gekennzeichnet, daß der zweite Kommunikationsweg ausgehend von dem in einem Hostrechner (HS) integrierten Testmodul (NTE) durch einen ersten Protokoll-Stapel (PSH) im Hostrechner (HS) und einen zweiten Protokoll-Stapel (PST) im Zielsystem (TS), einer den ersten und zweiten Protokoll-Stapel (PSH, PST) verbindende Verbindungsleitung (K) und einem Verteiler (V) der zwischen dem zweiten Protokoll-Stapel (PST) und dem zu testenden Testobjekt angeordnet ist, gebildet ist.