DE19651334A1 - Betriebstestvorrichtung und Verfahren zur Ausführung eines Betriebstests für ein zu testendes System - Google Patents

Description

Die Erfindung betrifft eine Betriebstestvorrichtung und ein Verfahren zur Ausführung eines Betriebstests für ein zu testendes System. Insbesondere betrifft die Erfindung eine Betriebstestvorrichtung zum Testen von Betriebsfunktionen in einem Kommunikationssystem, wie einem Telefonnetz, insbesondere einem Mobilfunknetz, beispielsweise zur Durchführung eines Lasttests oder eines Konformitätstests für ein Mobilfunksystem.

Jedes Produkt durchläuft, unabhängig davon, ob es Hardware- Komponenten oder Software-Komponenten oder Hardware-/Soft­ ware-Komponenten kombiniert beinhaltet, vom Entwurfstadium bis zum Ende seiner Betriebszeit einen bestimmten Entwicklungsprozeß (Life Cycle). Wie in Fig. 21a gezeigt wird beispielsweise für ein System, welches Software- Komponenten beinhaltet, typischerweise nach der Anforderungsanalyse RA ("Requirements Analysis"), dem Grobentwurf HLD ("High Level Design") und dem Feinentwurf DD ("Detailed Design") eine Codierung C des Programms vorgenommen, die von Tests gefolgt ist. Danach wird die Software an den Kunden ausgeliefert, in Betrieb genommen und weiter vom Produzenten gewartet ("Operation & Maintenance"), bis schließlich mit der "Outphasing"-Phase die Unterstützung durch den Produzenten endet. Die Tests sind unterteilt in verschiedene Testphasen, vom Basistest BT über den Funktionstest FT, den Integrationstest IT, den Systemtest ST bis zum Abnahmetest AT durch den Kunden. In der Testmethodik unterscheidet man zwischen dem White-Box-Test, in dem interne Funktionen oder Bestandteile des Geräts getestet werden, und dem Black-Box-Test, in dem nur die Schnittstelle nach außen getestet wird, um zu überprüfen, ob das Gerät den vorgegebenen kundenspezifischen Anforderungen standhält. In den Basis- und Funktions-Testphasen wird überwiegend nach der White-Box-Testmethodik vorgegangen. Im Integrationstest, Systemtest und Abnahmetest wird vorwiegend die Black-Box- Methodik verwendet (diese Unterteilung ist jedoch nicht völlig starr; die Bedeutung des Black-Box-Tests steigt hin zu späteren Testphasen, die des White-Box-Tests nimmt im gleichen Maße ab).

Der Abnahmetest ist eine wichtige Phase des Testens, da hier das System oder Gerät im Beisein des Kunden unter Testbedingungen getestet werden soll, die den später beim Einsatz zu erwartenden Betriebsbedingungen möglichst realistisch entsprechen sollen. Der Kunde entscheidet dann auf Grundlage des Abnahmetests, ob das Produkt die spezifizierten Anforderungen unter realen Betriebsbedingungen erfüllen kann. Da sich bedingt durch Korrekturen die Codierungsphase C oft bis in die durch Black-Box-Testmethodik ausgezeichneten Phasen verlängert, sind an den Integrationstest, den Systemtest und den Abnahmetest strenge Zeitanforderungen zu stellen. Bei komplexeren Systemen, bei denen eine große Zahl von Kompatibilitäten und Betriebsfunktionen getestet werden müssen, ist der Abnahmetest keine triviale Aufgabe und benötigt somit viel Zeit, insbesondere wenn man berücksichtigt, daß nach Korrekturen viele Tests, die vorher erfolgreich vom zu testenden System durchgeführt wurden, wiederholt werden müssen, um negative Auswirkungen der Korrekturen auf andere Teile des Testsystems auszuschließen (Regressionstest) Deshalb ist es nötig, in dieser Phase Werkzeuge (Test Tools) einzusetzen, die ein effizientes Arbeiten ermöglichen.

Fig. 21c zeigt den allgemeinen Aufbau einer Betriebstestvorrichtung zum Black-Box-Test eines zu testenden Systems SUT (System under Test), wobei die Betriebstestvorrichtung einen Testmustergenerator TCG, eine Ausgabeeinrichtung PRN und eine Schnittstelle INT (Interface) umfaßt. Über die Schnittstelle INT gibt die Betriebstestvorrichtung Testbefehle an das Testsystem SUT aus, um dessen Betriebsfunktionen zu überprüfen. Der Testmustergenerator TCG erzeugt eine große Vielzahl von Mustern von Testbefehlen, um sämtliche Betriebsfunktionen zu überprüfen. Über das Interface INT werden vom SUT durch die Testbefehle erzeugte Reaktionen in Form von Signalen an die Testvorrichtung zurückgeführt, die dann eine Fehlerauswertung vornimmt. Fehler sind an einer nicht spezifikationsgemäßen Reaktion des SUT (unerwartete Signale) kenntlich. Eventuelle Fehler werden auf der Ausgabeeinrichtung PRN anzeigt. Dem Interface INT wie auch dem Testmustergenerator TCG kommt dabei eine große Bedeutung zu, da letztlich Muster von Testbefehlen ausgegeben werden sollen, die den realen Betriebsbedingungen so gut wie möglich entsprechen müssen. Beispielsweise soll der Testmustergenerator Software-Fehler in einem zu testenden System durch ein statistisches Verwendungstestverfahren StUT ("Statistical Usage Testing") aufdecken. Das heißt, es werden Testbefehle erzeugt, die eine extensive Verwendung des SUTs mit den gleichen Verwendungscharakteristiken (Häufigkeit und Dauer der Nutzung der einzelnen Funktionen, beschrieben durch spezifische Wahrscheinlichkeitsverteilungen) wie in einer realen Betriebsumgebung simulieren. Eine große Anzahl von ausgeführten Testmustern oder Testfällen kann somit diejenigen Fehler aufdecken, die auch beim realen Einsatz des zu testenden Systems am häufigsten auftreten werden. Von der Anzahl der mit den Testbefehlen aufgefundenen Fehlern nach mehreren Korrekturstadien kann die Anzahl von noch verbleibenden Fehlern, beispielsweise der Software des Systems, abgeschätzt werden. Daraus kann ein Wert über die mittlere Zeit bis zum nächsten Fehler MTTF ("Mean Time to Failure") bestimmt werden, der dem Kunden letztlich anzeigt, welche Qualität das System beim realen Einsatz aufzeigen wird (Zertifizierung des Systems). Der automatische Testmustergenerator führt einen automatischen Black-Box-Test für das Testsystem SUT aus, in dem Eingaben von einem oder mehreren Benutzern des SUT, je nach Systemumgebung, simuliert werden. Um ein aussagekräftiges Maß für die unter realen Betriebsbedingungen zu erwartenden Betriebseigenschaften zu erhalten, kommt also der Erzeugung der Testmuster, d. h. der Testbefehle, größte Wichtigkeit zu, wobei die dafür benötigte Zeit so kurz wie möglich sein soll, um die Kosten für den Test zu minimieren. Bei komplexen Systemen ist dies keine triviale Aufgabe, wie nachstehend beispielhaft für ein in Fig. 21b dargestelltes Mobilfunksystem erläutert wird.

Ein typisches Mobilfunksystem, welches beispielsweise dem GSM-Standard ("Global System for Mobile Communications") genügt, umfaßt ein Netz aus einer oder mehreren zentralen Vermittlungsstellen MSC ("Mobile Services Switching Centre"), die jeweils mit einigen lokalen Vermittlungsstellen BSC ("Base Station Controller") verbunden sind, welche wiederum mit jeweils mehreren Sendestationen BTS ("Base Transceiver Station") kommunizieren, und den Mobilfunktelefonen MS (Mobile Station). Die MS kommunizieren mit den BTS mittels Funkwellen, also über die sogenannte "Luft-Schnittstelle" ("Air Interface"). Alle übrigen Komponenten sind über feste Datenleitungen untereinander verbunden (in bestimmten Fällen können dies auf physikalischer Ebene Richtfunkstrecken sein, aber im Sinne der Netzwerkstruktur sind auch diese auf logischer Ebene feste Leitungen). Mit dem Mobilfunksystem ist üblicherweise ein herkömmliches Telefonnetz PSTN über eine (oder auch mehrere) MSCs gekoppelt.

Um einen System- oder Abnahmetest ST, AT (siehe Fig. 21a) für ein derartiges System durchzuführen, muß sowohl ein Lasttest LT (Load Test) als auch ein Konformitätstest CT (Conformance Test) und eventuell auch ein Störtest DT (Disturbance Test) durchgeführt werden, möglichst in Kombination (Fig. 21b unten). Im Lasttest (Load Test, LT), bei dem die Leistungsfähigkeit der Vermittlungsstellen MSC und BSC bei der Vermittlung einer großem Zahl von Gesprächen untersucht wird, wird eine hohe Last von Gesprächen in Form von Signalisierverkehr direkt an die Vermittlungsstellen angelegt. Hier wird beispielsweise eine Last von bis zu 500 000 von der MSC/BSC zu vermittelnden Gesprächen simuliert und das dabei resultierende Verhalten ausgewertet. Dazu muß der Lastgenerator die Kommunikationsprotokolle des verwendeten Signalisiersystems kennen und sie für eine entsprechende Zahl (im Beispiel 500 000) von Instanzen, das sind unabhängige Prozesse, die den Signalisierverkehr einzelner Gespräche generieren, simulieren.

Beim Störtest (Disturbance Test, DT) wird das Verhalten des Systems im Falle von Betriebsstörungen, z. B. Unterbrechung von Zeichengabestrecken oder Ausfall einzelner Netzwerkkomponenten, untersucht. Ein Mobilfunknetz verfügt über hinreichende Redundanzen, um solche Störungen ganz oder wenigstens teilweise zu kompensieren, etwa durch Umleiten der Gespräche auf eine andere Vermittlungsstelle. Dazu werden im Störtest bewußt Signalisierstrecken unterbrochen bzw. Prozessoren in MSCs oder BSCs abgeschaltet. Solche Störungen werden heutzutage manuell hervorgerufen, z. B. durch das Herausziehen von Steckkarten aus der Vermittlungsstellen- Hardware. Es wäre aber auch möglich, dies durch eine Vorrichtung, die die betreffenden elektrischen Leitungen auf Befehl öffnen und schließen kann, zu automatisieren und damit präzise wiederholbar zu machen.

Im Konformitätstest (Conformance Test, CT) wird überprüft, wie das detaillierte Verhalten der einzelnen Dienste des Mobilfunknetzes, wie z. B. Rufumleitungen, Konferenzschaltungen usw. aussieht, wenn mobile Stationen MS untereinander oder mit Telefonen des Festnetzes PSTN kommunizieren. Dies könnte z. B. die korrekte Funktion der Dienste, aber auch die Einhaltung von maximal erlaubten Verbindungsaufbauzeiten o.a. betreffen. Bei der Vielzahl von Betriebsfunktionen, die den mobilen Teilnehmern in einem Mobilfunknetz heutzutage zur Verfügung gestellt werden, müssen bei dem Konformitätstest eine Vielzahl von Funktionen simuliert werden.

Herkömmliche Lösungen bestehen darin, mehrere Mobiltelefone per Koaxialleitung an ein kleines Testnetz aus MSCs, BSCs und BTSs anzuschließen (ein Test über die Luftschnittstelle selbst verbietet sich, da externe Mobilfunknetze dadurch gestört würden). Dann werden die gewünschten Betriebsfunktionen mit Hilfe der Mobiltelefone von Hand aufgerufen, um z. B. einen Wählvorgang, einen Gesprächsaufbau oder ein Gespräch durchzuführen, wobei die dabei aufgetretenen Fehler, kenntlich z. B. durch ein fehlendes Klingelsignal oder ein fehlendes Freizeichen, manuell ausgewertet werden. Ausgefeiltere computergestützte Testvorrichtungen beinhalten ferner die Simulation der Luft­ schnittstelle (Air Interface Simulation AIS) mit veränderlichen Dämpfungsgliedern in den Koaxialleitungen zwischen den Mobiltelefonen und den BTSs, um die Bewegung der einzelnen mobilen Stationen zu simulieren und die dabei aufgetretenen Fehler, z. B. beim Wechsel in andere Funkzellen, genannt "Handover", auszuwerten. Derzeit können in der Praxis typischerweise nur drei, in Ausnahmefällen (Konferenzschaltungen) bis zu fünf Mobiltelefone gleichzeitig für einen Konformitätstest verwendet werden, und zu ihrer Bedienung sind mehrere Testpersonen notwendig.

Wenn man berücksichtigt, daß in einem realen Mobilfunksystem die Anzahl der an der Kommunikation teilhabenden mobilen Stationen weitaus größer ist und eine Vielzahl von Funktionen zur Verfügung gestellt werden, ist jedoch die Anzahl von nur einer Handvoll Mobiltelefonen, die manuell einem derartigen Konformitätstest unterzogen werden können, äußerst gering, so daß es wünschenswert ist, ein automatisiertes Testen mit einer größeren Anzahl von Mobiltelefonen durchführen zu können. Dadurch kann auch die Zahl der erprobten Testmuster bei gleichem Zeitaufwand wesentlich gesteigert werden. Um eine MTTF-Messung und damit eine Zertifizierung des Systems zu ermöglichen, müssen Testmuster mit der gleichen Charakteristik wie im realen Einsatz des getesteten Systems ausgeführt werden. Es müssen zum Beispiel in einer Mobiltelefon-Kommunikationsvorrichtung Kundenserviceleistungen, wie z. B. Konferenzschaltungen, Voice-Mail Service, Datenübertragung, etc., bereitgestellt werden, die zum Teil über die jeweiligen Telefone aktivierbar sein müssen. Zudem werden bestimmte Funktionen, wie ein einfaches Telefongespräch, von einem großen Personenkreis sehr häufig verwendet, während andere speziellere Funktionen, beispielsweise Anrufweiterleitung, Mailbox-Funktionen etc., nur von einem beschränkten Personenkreis genutzt werden und dies im Verlauf eines Tages mit wechselnder Häufigkeit. Um also einen charakteristischen MTTF-Wert, der die statistischen Gegebenheiten berücksichtigt, messen zu können, müssen die Nutzungshäufigkeiten der Betriebsfunktionen im realen Einsatz des Mobilfunknetzes statistisch erfaßt oder (im Falle von völlig neuen Betriebsfunktionen) geschätzt und im Betriebstest mit einer möglichst großen Anzahl von mobilen Teilnehmern statistisch repräsentativ nachgebildet werden.

Ein Mobiltelefon-Kommunikationsvorrichtung ist daher ein komplexes System, das in der Regel durch einen Verbund von Hardware- und Softwarekomponenten bereitgestellt und betrieben wird.

Wie oben erwähnt, verlangt die Komplexität von Mobiltelefon- Kommunikationssystemen ein genaues Testen von einzelnen Komponenten, bzw. des gesamten Systems. Umfangreiche Tests werden zur Lokalisierung von beim Betrieb auftretenden Software- und Hardware-Fehlern im System, vor der Freigabe von Systemen und vor der Freigabe von Weiterentwicklungen durchgeführt. Herkömmliche Testsysteme erlauben jedoch kein umfassendes automatisches Testen der Hardware und der Software eines Telefonnetzes.

Beispielsweise beschreibt die DE 32 11 967 eine Schaltungsanordnung für eine Einrichtung, mit der unterschiedliche Betriebs- und Prüfabläufe in einer Fernsprechvermittlungsanlage oder in einer damit im Zusammenhang stehenden Einrichtung bewirkt werden und ein nicht ordnungsgemäßer Verlauf angezeigt wird, insbesondere für eine zur Verkehrssimulation in Fernsprechvermittlungsanlagen eingesetzten und mit entsprechenden Teilnehmernachbildungen ausgerüsteten Einrichtungen. Durch die Teilnehmernachbildungen können anlagetypische Funktionen, wie zum Beispiel "Belegen", "Wählen", "Rufen", "Sprechen" nachgebildet bzw. simuliert werden. Nach Maßgabe des fest vorgegebenen Prüfprogramms einer programmgesteuerten Prüfeinrichtung werden bestimmte durch einen Pegelsender erzeugte Tonspannungen an die Teilnehmernachbildungen angelegt. Es erfolgt eine Überwachung durch die Bewertung der übertragenen Hörtöne, des Rufstromes und gegebenenfalls von Zählimpulsen.

Das in der DE 32 11 967 beschriebene Verfahren weist beispielsweise den Nachteil auf, daß z. B. Hardwarefehler nicht simuliert werden können. Hardwarefehler zum Lokalisieren von beim Betrieb aufgetretenen Fehlern von Übertragungsstationen oder zum Testen des Kommunikationssystems werden gegenwärtig durch Entfernen bzw. durch Wiedereinsetzen von kompletten Einschüben z. B. einer Übertragungsstation und durch Analysieren von Betriebsabläufen im System lokalisiert.

Dieses Verfahren unterstützt jedoch weder die Wiederholbarkeit von Testfällen noch unterstützt es die in zeitkritischen Situationen erforderliche Genauigkeit. Die Wiederholbarkeit von Testfällen ist erforderlich, um zu verifizieren, daß ein Fehler beseitigt worden ist, wenn eine Reihe von Tests wiederholt, z. B. für die Zulassung von Weiterentwicklungen des Systems, durchgeführt werden muß, oder wenn eine Testsequenz zu inkorrekten Ergebnissen geführt hat und dieselbe Testsituation ein weiteres Mal erzeugt werden muß. Speziell bei einem Echtzeitsystem, wie einem Kommunikationssystem, ist die Reproduktion eines Testfalles mit sehr genauen Zeitvorgaben, wie zum Beispiel für Regressionstests nötig.

Zudem ist das manuelle Durchführen von Testfällen zeitaufwendig und verlangt die Gegenwart von Testpersonal am zu testenden Gerät, durch das zum Beispiel Hardware- Komponenten entfernt bzw. wiedereingesetzt und Telefone, gegebenenfalls von Hand, bedient werden können.

Weiterhin erlaubt das Entfernen von Hardware-Komponenten einer Übertragungsstation lediglich eine Testgranularität, d. h. die Feinheit des Rasters, mit dem ein Fehler lokalisiert werden kann, die den entfernten Hardware-Komponenten entspricht.

Obwohl voranstehend die Probleme beim Testen eines Produkts speziell für ein Mobilfunksystem beschrieben worden sind, treten diese Probleme in gleicher Weise beim Testen beliebiger komplexer Systeme auf, d. h. es ist allgemein wünschenswert eine Betriebstestvorrichtung zur Verfügung zu stellen, die einen Betriebstest mit Testbedingungen ausführt, die den realen Betriebsbedingungen möglichst gut entsprechen. Außerdem muß die Betriebstestvorrichtung, wie voranstehend erwähnt, einen derartigen, komplexen Betriebstest in möglichst kurzer Zeit ausführen.

Aufgabe der vorliegenden Erfindung ist es somit,

• - eine Betriebstestvorrichtung und ein Verfahren zur Ausführung eines Betriebstests für ein Testsystem bereitzustellen, die einen Betriebstest in kurzer Zeit und mit Testmustern ausführen können, welcher tatsächlich zu erwartende Betriebsbedingungen beim Einsatz des Testsystems in einer realen Umgebung nachbildet.

Diese Aufgabe wird gelöst (Anspruch 1) durch eine Betriebstestvorrichtung zur Ausführung eines Betriebstests für ein Testsystem, welches Betriebszustände entsprechend einem in einer realen Betriebsumgebung eingesetzten realen Betriebssystem aufweist, unter Testbedingungen, umfassend:

• a) einen Testmustergenerator zum Erzeugen einer Anzahl von Testmustern mit Testbefehlen, die jeweils eine gewünschte Betriebszustandsänderung in dem Testsystem hervorrufen sollen;
• b) eine Testvorrichtungs-Schnittstelle zum Empfang der Testbefehle und zur Ausgabe von entsprechenden Bediensignalen an das Testsystem zum Herbeiführen der gewünschten Betriebszustandsänderungen;
• c) wobei der Testmustergenerator umfaßt:
  • - einen Test-Zustandsmodell-Generator zum Erzeugen eines Test-Zustandsmodells des Testsystems aus Information über die Hardware-Konfiguration des Testsystems, Information über die möglichen Betriebszustände des realen Betriebssystems, aus Verkehrswerten, die beim realen Betrieb des Betriebssystems ermittelte Übergangswahrscheinlichkeiten für die Betriebszustände anzeigen und aus den erlaubten Testbefehlen des Testsystems
  • - einen Test-Zustandsmodellspeicher, in dem das Test- Zustandsmodell gespeichert wird;
  • - einen Test-Zustandsmodell-Simulator, der das Test­ zustandsmodell statistisch durchläuft und dabei gewünschte Betriebszustandsübergänge generiert; und
  • - einen Test-Zustandsmodell-Befehlsgenerator zum sukzessiven Erzeugen der Testbefehle der Testmuster auf Grundlage der vom Test-Zustandsmodell-Simulator generierten Betriebszustandsübergänge.

Ferner wird diese Aufgabe gelöst (Anspruch 31) durch ein Verfahren zum Ausführen eines Betriebstests für ein Testsystem, welches Betriebszustände entsprechend einem in einer realen Betriebsumgebung eingesetzten realen Betriebssystem aufweist, unter Testbedingungen, umfassend die folgenden Schritte:

• a) Erzeugen einer Anzahl von Testmustern mit Testbefehlen, die jeweils eine vorgegebene Betriebszustandsänderung in dem Testsystem anzeigen, mit einem Testmustergenerator;
• b) Empfangen der Testbefehle und Ausgeben von entsprechenden Bediensignalen an das Testsystem (SUT) zum Herbeiführen der vorgegebenen Betriebszustands- Änderungen über eine Testvorrichtungs-Schnittstelle; und
• c1) Erzeugen eines Zustandsmodells des Testsystems aus Informationen über die Hardware-Konfiguration des Testsystems, Informationen über die möglichen Betriebszustände des Testsystems im realen Betrieb, Informationen über die zur Herbeiführung von Betriebszustandsänderungen im Testsystem notwendige Testbefehle und aus Verkehrswerten, die beim realen betrieb dem Testsystems ermittelte Übergangswahrscheinlichkeiten für die Betriebszustände anzeigen, mit einem Test-Zustandsmodell-Generator;
• c2) sukzessives Erzeugen von den Übergangswahrscheinlichkeiten gemäßen zufallsgesteuerten Zustandsänderungen im Test-Zustandsmodell mit einem Test-Zustandsmodell-Simulator; und
• c3) Erzeugen der Testbefehle der Testmuster auf Grundlage der vom Test-Zustandsmodell-Simulator erzeugten Zustandsübergänge und den gemäß dem Test-Zustandsmodell mit diesen Zustandsübergängen verknüpften Testbefehlen durch einen Test-Zustandsmodell-Befehlsgenerator.

Bei der erfindungsgemäßen Betriebstestvorrichtung und dem Verfahren erzeugt ein Testmustergenerator Testbefehle gemäß den durchlaufenen Zuständen eines in einer Monte-Carlo- Simulation simulierten Test-Zustandsmodells des Testsystems. Das Test-Zustandsmodell wird auf Grundlage von Information über die Hardware-Konfiguration und die verfügbaren Betriebsmittel des Testsystems, aus Information über die möglichen Betriebszustände des Testsystems beim realen Einsatz, aus den Testbefehlen, die zur Herbeiführung dieser Betriebszustände erforderlich sind, und aus Verkehrswerten, die beim Betrieb ermittelte Übergangswahrscheinlichkeiten zwischen den Zuständen anzeigen, erzeugt. In der Monte-Carlo- Simulation werden die Betriebszustände im Zustandsmodell durch zufällige, aber der statistischen Verteilung gemäß häufige Übergänge durchlaufen und Testbefehle auf Grundlage des jeweils gewählten Übergangs zum nächsten Zustand erzeugt. Dabei werden die in der Realität häufigen Übergänge auch in der Simulation häufig auftreten, so daß Fehler bei diesen Übergängen, die beim Kunden früh eintreten würden, auch früh in der Simulation offengelegt werden. Dieses Prinzip des statistischen Nutzungstestens (Statistical Usage Test, StUT) ermöglicht somit eine kostengünstige Ermittlung der am häufigsten auftretenden und damit schwerwiegendsten Fehler, im Gegensatz zum gewöhnlichen, traditionellen Testen, bei dem der Tester die Testmuster zwar nach bestem Wissen und Gewissen, aber dennoch letztlich zufällig, ohne statistische Signifikanz und ohne Anspruch auf Vollständigkeit auswählt, und so oft auch Fehler in häufig genutzten Funktionen des Testsystems unentdeckt bleiben.

Gemäß einer vorteilhaften Ausführungsform der Erfindung (Anspruch 33)

• a) handelt es sich bei dem Testsystem (d. h. dem zu testendem System) um eine Kommunikationsvorrichtung, welche eine Vielzahl von Telefonen, insbesondere von Mobiltelefonen, eine Vielzahl von elektrischen Verbindungsleitungen, sowie mindestens eine Übertragungsstation zur Übertragung von Signalen in der Telefon-Kommunikationsvorrichtung enthält; wobei
• b) die Testvorrichtungs-Schnittstelle und der Testmustergenerator eine Testvorrichtung zum Testen der Telefon-Kommunikationsvorrichtung unter betriebsmäßiger Lastbedingung bilden, wobei die Testvorrichtung umfaßt:
  • b1) eine zentrale Signalverarbeitungsvorrichtung mit
    • b11) mindestens einer programmierbaren Datenverarbeitungsvorrichtung, von der die Testbefehle zum Testen der Telefon- Kommunikationsvorrichtung geliefert werden;
      und
    • b12) einer mit der programmierbaren Datenverarbeitungsvorrichtung verbundenen Wandlervorrichtung, die ausgebildet ist, um von der programmierbaren Datenverarbeitungsvorrichtung unter der Steuerung der Testbefehle erzeugte digitale Testsignale in die Bediensignale zu wandeln;
      und
  • b2) mindestens eine mit der Wandlervorrichtung verbundene Unterbrechungsvorrichtung, die ausgebildet ist, um gemäß der Bediensignale einzelne oder Gruppen der elektrischen Verbindungsleitungen für durch die Bediensignale der Wandlervorrichtung vorgegebene Zeitabschnitte gezielt zu unterbrechen, wobei
  • b3) aufgrund der gezielten Unterbrechungen in der Telefon-Kommunikationsvorrichtung Signaländerungen hervorgerufen werden, die bei Abweichung von den zugehörigen Soll-Signaländerungen signalisierbar sind.

Die Unterbrechungsvorrichtung (nachstehend auch als Störelement bezeichnet) kann in vorteilhafter Weise aus einer Vielzahl von gesteuerten Schaltern bestehen, die von der programmierbaren Datenverarbeitungsvorrichtung der zentralen Signalverarbeitungsvorrichtung programmgesteuert bedient werden. Es lassen sich dadurch einzelne oder Gruppen von elektrischen Verbindungsleitungen in der Übertragungsstation oder zwischen verschiedenen Übertragungsstationen für definierte Zeitabschnitte unterbrechen. Auch läßt sich eine sehr hohe Testgranularität erreichen, d. h. Fehler können exakt lokalisiert werden. Eine betriebsmäßige Lastbedingung kann z. B. durch einen Lastgenerator, der eine Vielzahl von Gesprächen simuliert, erzeugt werden. Dabei wird durch den Lastgenerator während des Testens eine vorbestimmte Netz- Grundlast erzeugt.

Gemäß einer weiteren Ausführungsform kann die Unterbrechungsvorrichtung (Störelement) zwischen der oder den Schaltungskarten und der Schaltungskartenhalterung der Übertragungsstation oder an den Vorderseiten der in die Schaltungskartenhalterung eingeschobenen Schaltungskarten der Übertragungsstation angeordnet sein. Weiter kann die Unterbrechungsstation auch zwischen verschiedenen Übertragungsstationen angeordnet sein und es können auch mehrere Unterbrechungsstationen auf die genannten Weisen angeordnet sein.

Bei derartigen Ausführungsformen besteht ein weiterer allgemeiner Vorteil darin, daß auch Hardwarekomponenten und in Speichervorrichtungen gespeicherte Konfigurationsdateien vorgesehen werden können, über die die Mobiltelefone und/oder die festen Telefone, auch verschiedenen Typs, z. B. von verschiedenen Herstellern, automatisch über eine Schnittstelle bedient und überwacht werden können. Es können so durch Ansteuern der Tastatur und der Mikrophone, sowie durch Abhören der Rufvorrichtungen und der Lautsprecher von Telefonen Teilnehmer und deren Verhalten simuliert werden. Es können so auch Teilnehmerbewegungen und die Übergabe von Gesprächen zwischen zwei Übertragungsstationen simuliert werden.

Somit können die Testprogramme zusätzlich Anweisungen enthalten, wann und auf welche Weise Telefone bedient werden sollen und Telefon-Bewegungen simuliert werden. Damit ist ein Testen einer Kommunikationsvorrichtung, auch in Verbindung mit Telefonen unterschiedlicher Hersteller, möglich und bestimmte Teilnehmerserviceleistungen können automatisch aktiviert werden. Über die Sprechkanäle können durch die Testvorrichtung zudem auch, von Testanweisungen d. h. den Testbefehlen gesteuert, Identifizierungssignale übertragen werden, die jeweilige an einem Gespräch beteiligte Telefone identifizieren. Dazu wird ein Sprechkanal zwischen jedem Paar von Telefonen einer Vielzahl von Telefonen bei einem Zweitelefongespräch oder einer Konferenzschaltung mit drei oder mehreren Teilnehmern aufgebaut. Danach wird ein ein erstes Telefon eindeutig identifizierendes Muster von Tonimpulsen mit einer vorbestimmten Frequenz über den Sprechkanal von dem ersten Telefon übertragen. Der Empfang des über den Sprechkanal übertragenen Musters von Tonimpulsen wird an einem zweiten am Gespräch beteiligten Telefon überwacht. Dabei findet die Übertragung des Musters von Tonimpulsen zwischen dem ersten und dem zweiten Telefon in der Gegenwart von Sprachkomprimierung und Sprachdekomprimierung statt. Das Muster von Tonimpulsen ist so gewählt, daß eine Identifikation des ersten Telefons auch möglich ist, wenn das Muster von Tonimpulsen am zweiten Telefon bei Verwendung von Sprachkomprimierung und Sprachdekomprimierung empfangen wird.

Somit kann die korrekte Schaltung von Verbindungen bei Zweitelefongesprächen oder Konferenzschaltungen festgestellt, dokumentiert und ausgewertet werden. Weiter werden damit auch Langzeittests und ein umfassendes automatisches "black box Testen" möglich.

Bei einer weiteren Ausführungsform kann die zentrale Signalverarbeitungsvorrichtung über die programmierbare Datenverarbeitungsvorrichtung, die z. B. ein handelsüblicher Computer sein kann, mit einer Vielzahl von externen, programmierbaren Datenverarbeitungsvorrichtungen, die ebenfalls handelsübliche Computer sein können, über ein Netzwerk zum Austausch von Daten verbunden sein. In diesem Fall dient die programmierbare Datenverarbeitungsvorrichtung der zentralen Signalverarbeitungsvorrichtung als Server, der über einen Serverprozeß mit der Wandlervorrichtung verbunden ist und der über hierarchische Kommunikations-Prozesse, im folgenden Client-Prozesse genannt, mit der Vielzahl der externen, programmierbaren Datenverarbeitungsvorrichtungen oder Datensichtstationen verbunden ist. Somit können mit der Vielzahl dieser Stationen Testanweisungen ausgeführt werden, die über Client-Prozesse an den Server der zentralen Signalverarbeitungsvorrichtung Daten übermitteln, der darauf folgend digitale Steuersignale erzeugt und diese in einem Serverprozeß an die Wandlervorrichtung überträgt, die die Unterbrechungsvorrichtung in der Übertragungsstation steuert, bzw. die Telefone steuert und überwacht. Dies erlaubt es, die externen Datenverarbeitungsvorrichtungen auch weit entfernt von der Datenverarbeitungsvorrichtung der zentralen Signalverarbeitungsvorrichtung anzuordnen und mit dieser über z. B. ein lokales Netzwerk (LAN) oder über ein Internet, oder über eine andere Datenfernübertragungs­ vorrichtung anzuschließen. Es muß die Ausführung von Testanweisungen somit nicht vorort vorgenommen werden, d. h. Tests können auch über große Entfernungen vorgenommen werden (remote testing) und so kann die Testvorrichtung effektiver genutzt werden.

Weitere vorteilhafte Ausführungsformen und Verbesserungen der Erfindung ergeben sich aus den Unteransprüchen.

Nachstehend wird die Erfindung anhand ihrer Ausführungsformen unter Bezugnahme auf die beigefügten Zeichnungen beschrieben.

In den Zeichnungen zeigen:

Fig. 1a allgemeine Ansicht der Betriebstestvorrichtung der Erfindung;

Fig. 1b den Aufbau des Testmustergenerators TCG aus Fig. 1a;

Fig. 2a eine Ansicht, die den Aufbau der Betriebstestvorrichtung zum Testen eines Telefonnetzes (z. B. eines Mobilfunknetzes) zeigt;

Fig. 2b eine mögliche Testumgebung zum Ausführen eines Lasttests, Störtests und/oder eines Konformitätstests in dem in Fig. 21b schematisch dargestellten Mobilfunknetz;

Fig. 2c eine allgemeine Ausführungsform der Betriebstestvorrichtung für die Anwendung auf ein Telefonnetz;

Fig. 3a eine Ausführungsform der Betriebstestvorrichtung, bei der Zustandsänderungen an die Testvorrichtung zurückgekoppelt werden;

Fig. 3b der Aufbau des zugehörigen Testmustergenerators TCG-F, wenn Zustandsänderungen wie in Fig. 3a gezeigt an den TCG zurückgekoppelt werden;

Fig. 3c ein Beispiel eines Test-Zustandsmodells auf der Basis einer zeitkontinuierlichen Markoffkette zur Erzeugung von Testbefehlen für ein Telefonnetz;

Fig. 4a eine Ausführungsform TCG-PN des Testmustergenerators TCG zum Erzeugen von Testbefehlen unter Verwendung eines stochastischen Petri-Netz-Zustandsmodells des zu testenden Systems;

Fig. 4b ein Beispiel eines unfarbigen stochastischen Petri- Netzes zur Erzeugung von Testbefehlen für ein Telefonnetz mit zwei Telefonen;

Fig. 4c ein Beispiel eines farbigen stochastischen Petri- Netzes zur Erzeugung von Testbefehlen für ein Telefonnetz mit einer beliebigen Zahl von Telefonen;

Fig. 4d das Beispiel aus Fig. 4c realisiert mit latenzbehafteten Stellen anstelle von zeitbehafteten Transitionen;

Fig. 5a eine Ausführungsform TCG-PNF des Testmustergenerators entsprechend Fig. 4a, jedoch einschließlich einer Rückführung von Zustandsänderungen (Synchronisation) vom Testsystem;

Fig. 5b das Beispiel aus Fig. 4c ergänzt um eine Erkennung und Auswertung von rückgekoppelten Signalen des Telefonnetzes unter Ausnutzung von Synchronisationsstellen;

Fig. 5c zeigt einen Ausschnitt aus einem farbigen Netz, dem die Identitäten der Telefone und die von ihnen abonnierten Dienste "Multiparty" (Konferenzgespräch) und "Call Forwarding" (Rufumleitung) in Synchronisationsstellen in Form von farbigen Marken abgelegt werden;

Fig. 6 eine Ausführungsform TCG-PNR des Testmustergenerators, wobei eine Rücksetzung der Zustände des Petri-Netz-Zustandsmodells auf gespeicherte Zustände möglich ist;

Fig. 7a eine Ausführungsform TCG-PNFR des Testmustergenerators, wenn die Ausführungsformen der Fig. 4a, 5a und 6 kombiniert werden;

Fig. 7b einen Ausschnitt aus dem Petri-Netz gemäß Fig. 5b, in dem eine Synchronisation und Rücksetzung bei Fehlern vorgesehen ist, wie sie vom Testmustergenerator aus Fig. 7a ermöglicht wird;

Fig. 8a Bestandteile und Funktionsweise unfarbiger stochastischer Petri-Netze;

Fig. 8b Erweiterungen der unfarbigen stochastischen Petri- Netze in Form von farbigen Marken bzw. Stellen und latenzbehafteten Stellen;

Fig. 8c Ansicht eines Beispiels für ein Petri-Netz-Modell eines einfachen Telefonnetzes auf einem als Editor ausgeführten Petri-Netz-Modell-Generator (PNM-G);

Fig. 9-11 Blockschaltbilder von Ausführungsbeispielen des Kommunikationssystems;

Fig. 12 ein Flußdiagramm eines Testablaufs;

Fig. 13 ein Blockschaltbild eines Teils einer Testvorrichtung;

Fig. 14 ein Flußdiagramm eines Teils eines Testablaufs;

Fig. 15 ein Blockschaltbild einer in einer Übertragungsstation angeordneten Unterbrechungsvorrichtung;

Fig. 16 ein Blockschaltbild eines Teils einer Unterbrechungsvorrichtung;

Fig. 17 eine Anordnung von einer Vielzahl von Unterbrechungsvorrichtungen in einer Übertragungsstation;

Fig. 18 ein Beispiel einer Wandlervorrichtung;

Fig. 19 ein Beispiel einer Anordnung einer Unterbrechungsvorrichtung zwischen Übertragungsstationen;

Fig. 20 ein Blockschaltbild eines Kommunikationssystems;

Fig. 21a ein Diagramm, welches den Entwicklungsprozeß eines Software-Produkts, insbesondere in der Testphase, zeigt;

Fig. 21b den Aufbau eines realen Mobilfunknetzes nach GSM-Stan­ dard, und ein GSM-Minimal-Testnetz, welches einem Lasttest, einem Störtest und einem Konformitätstest unterzogen wird;

Fig. 21c eine allgemeine Darstellung einer Testumgebung zum automatischen Black-Box-Testen eines Testsystems.

Fig. 1 zeigt eine erste Ausführungsform der Betriebstestvorrichtung, die einen Black-Box-Test nach dem StUT-Verfahren ("Statistical Usage Testing") ermöglicht. Die Hauptanwendung dieser Betriebstestvorrichtung ist das Testen einer System-Software für Telefonnetze, wie nachstehend noch unter Bezugnahme auf Fig. 2 erläutert wird. In Fig. 1a ist das hier nicht näher spezifizierte zu testende System SUT ("System under Test"), ein Testmustergenerator TCG ("Test Case Generator"), eine dazwischengeschaltete Schnittstelle INT ("Interface"), eine Aufzeichnungseinrichtung für Testergebnisse TRR ("Test Result Recorder"), ein realer Einsatz des Testsystems SUT-RA ("SUT-Real Application") und eine Meßeinrichtung für Verkehrsdaten USMS ("Usage Statistics Mesurement System") gezeigt.

Das Testsystem SUT entspricht von der Hardware-Konfiguration her der realen Anwendung SUT-RA, so wie es später nach dem Testen in der realen Betriebsumgebung eingesetzt wird.

Der Testmustergenerator TCG erhält die Hardware-Konfiguration des zu testenden Systems SUT, Information über die Zustände, die das reale Testsystem einnehmen kann bzw. soll, über mögliche Übergänge zwischen den Zuständen und über die notwendigen Befehle an das SUT, um solche Übergänge im SUT zu bewirken. Bei diesen Zuständen handelt es sich nicht nur um rein imaginäre Größen, sondern z. T. um tatsächlich eingenommene Betriebszustände des Testsystems SUT oder seiner Benutzer, die zum Test als Verkehrsquelle ebenfalls simuliert werden müssen. Diese Zustände werden durch entsprechende Signale nach außen vom Testsystem angezeigt. Wenn die Betriebstestvorrichtung beispielsweise zum Testen eines Systems verwendet wird, das zur Steuerung einer Verkehrsampel-Anlage verwendet wird, zeigen die Signale den Zustand rot, gelb, grün einer jeweiligen Ampel an. Für das Testen von anderen Systemen im Black-Box-Verfahren können diese Signale beispielsweise den Durchfluß von Material, das Anhalten von Werkstücken etc. in einer Fertigungsanlage anzeigen. Beim Black-Box-Test werden diese Signale als einzige Information über den inneren Zustand des SUT ausgewertet, wodurch er sich gegenüber dem White-Box-Test auszeichnet, bei dem der innere Zustand des SUT direkt untersucht werden kann.

Ferner erhält der Testmustergenerator TCG Verkehrsparameter, die entweder aus Messungen mit Hilfe einer Meßeinrichtung für Verkehrsdaten (USMU) in der realen Betriebsumgebung gewonnen werden, oder geschätzt werden, sofern die zu testenden Funktionen neu sind und demgemäß noch nicht in der realen Anwendung des Testsystems (SUT-RA) eingesetzt wurden. Diese Verkehrsparameter sind Parameter von Wahrscheinlichkeitsverteilungen, die anzeigen, wie sich die Zustände statistisch in der realen Betriebsumgebung ändern. Die Verteilungen zeigen also die Zustands- Übergangswahrscheinlichkeiten an, die beim Einsatz des Testsystems SUT in der realen Betriebsumgebung zu erwarten sind.

Bei der voranstehend erwähnten Verkehrsampel-Steuerung könnten diese Verkehrswerte beispielsweise anzeigen, mit welcher Häufigkeit zu einer bestimmten Tageszeit eine Ampel an einer Kreuzung auf rot geschaltet wird, wenn die Ampelsteuerung automatisch durch die jeweilige Anzahl der wartenden Fahrzeuge vorgenommen wird, welche wiederum durch eine tageszeitabhängige statistische Verteilung charakterisiert ist. Die an den TCG übermittelte Information über die Hardware-Konfiguration des zu testenden Systems SUT zeigt an, welche Betriebsmittel, die einem Test unterzogen werden können, in dem Testsystem SUT vorhanden sind, beispielsweise die Anzahl der im Testsystem aufgebauten Verkehrsampeln und Fahrzeuge.

Die Schnittstelle INT ist erforderlich, um die Testbefehle des Testmustergenerators TCG in Signale umzuwandeln, die eine aktive Steuerung, beispielsweise der Ampeln, in dem Testsystem, vornehmen können.

Die Aufzeichnungseinrichtung für Testergebnisse TRR protokolliert alle ausgeführten Testmuster und die beobachteten Signale des SUT mit, damit bei einer späteren Auswertung (automatisch oder von Hand) nachgeprüft werden kann, ob die Testmuster zu den gewünschten Zustandsänderungen geführt haben, d. h. ob das Testmuster erfolgreich abgearbeitet wurde oder nicht.

Wie in Fig. 1b gezeigt, enthält der Testmustergenerator TCG einen Test-Zustandsmodellgenerator TSTM-G ("Test State Model Generator"), einen Test-Zustandsmodellspeicher TSTM-S ("Test State Model Storage"), einen Test-Zustandsmodell-Simulator TSTM-Sim ("Test State Model Simulator") und einen Test- Zustandsmodell-Befehlsgenerator TSTM-CG ("Test State Model Command Generator"). Optional kann noch ein Testmusterspeicher TCS ("Test Case Storage") vorhanden sein, um erzeugte Testmuster erst später auszuführen und/oder um sie wiederverwenden zu können. Der Test- Zustandsmodellgenerator TSTM-G ist eine Vorrichtung zur Erzeugung eines Test-Zustandsmodells des Testsystems auf der Basis eines Zustandsmodells des SUT, Parametern für das Modell, und Testaktionen, die den jeweiligen Übergängen zugeordnet sind. Im Gegensatz zum Zustandsmodell des SUT, in dem lediglich die möglichen Zustände und möglichen Zustandsübergänge des SUT ohne weitere Parameter wie Übergangswahrscheinlichkeiten beschrieben sind, ist das Test- Zustandsmodell sehr viel konkreter. Die Zustände können hier beispielsweise mit Zeiten verknüpft sein, die in Echtzeit oder Simulationszeit die Lebensdauer des jeweiligen Zustands durch eine geeignete Wahrscheinlichkeitsverteilung (z. B. exponentialverteilt oder konstant) modellieren. Wenn von einem Zustand mehrere Übergänge in verschiedene Folgezustände möglich sind, sind die Übergänge mit individuellen Wahrscheinlichkeiten behaftet. Alternativ können die Übergänge mit Zeiten behaftet sein, so daß sich die Lebensdauer eines Zustandes aus der Dauer bis zum zuerst eintretenden Übergang ergibt. Schließlich kann das Modell auch Übergänge nur zu diskreten Zeitpunkten erlauben, wobei Übergänge aus einem Zustand in den gleichen Zustand zurück möglich sind. Die Lebensdauer eines Zustands entspricht hier der Zahl von Zeittakten vom ersten Eintritt in den Zustand bis zum erstenmal ein Übergang in einen anderen Zustand erfolgt.

Zur Erzeugung eines geeigneten Test-Zustandsmodells muß der Test-Zustandsmodellgenerator Informationen erhalten über alle möglichen Zustände und Übergänge zwischen diesen Zuständen (Zustandsmodell des Testsystems), über die Verkehrsparameter (d. h. Lebensdauern der Zustände, Übergangswahrscheinlichkeiten etc.) über die bei Zustandswechseln auszuführenden Testbefehle, die entsprechende Zustandsänderungen im Testsystem bewirken sollen, und über die verfügbare Testhardware (Betriebsmittel für den Test). Aus diesen Informationen erzeugt der TSTM-G ein Test-Zustandsmodell, das alle nötigen Informationen für einen statistischen Test des Testsystems mit der verfügbaren Testhardware enthält. Dieses Modell wird im Test- Zustandsmodellspeicher TSTM-S abgelegt.

Der Test-Zustandsmodell-Simulator TSTM-S kann nun eine Monte- Carlo-Simulation des Test-Zustandsmodells durchführen, indem er zufällige Zustandsänderungen auf Grundlage der stochastischen Parameter des Test-Zustandsmodells (Lebensdauern, Übergangswahrscheinlichkeiten etc.) erzeugt. Der Test-Zustandsmodell-Befehlsgenerator TSTM-CG setzt die erzeugten Zustandsänderungen in Befehle für das Testsystem SUT um, so daß eine zufällige Abfolge von Zuständen im Test- Zustandsmodell eine zufällige Folge von Testbefehlen als Testmuster für das SUT erzeugt, die entsprechende Zustandsänderungen in diesem bewirken sollen. Ist dies der Fall, so ist das Testmuster erfolgreich vom SUT verarbeitet worden, andernfalls wurde ein Fehler im SUT gefunden. Informationen über korrekte oder fehlerhafte Verarbeitung von Testmustern sind den Aufzeichnungen der Signale und der erzeugten Testmuster zu entnehmen, die von einer geeigneten Aufzeichnungseinrichtung TRR während des Tests angefertigt werden.

Das heißt, aus den eingegebenen Verkehrswerten, den möglichen Zuständen und Übergängen des Testsystems, den Testbefehlen, die an das Testsystem gegeben werden müssen, um in ihm entsprechende Übergänge herbeizuführen, und der aktuellen Hardware-Konfiguration des Testsystems wird ein Test- Zustandsmodell erzeugt. Auf Grundlage dieses Modells wird eine Anzahl von Testmustern mit Testbefehlen durchfahren, in exakt der gleichen Vorgehensweise und statistischen Häufigkeit, wie dies beim Einsatz des gegenwärtig noch zu testenden System in einer realen Betriebsumgebung zu erwarten ist.

Für das oben angegebene Ampelbeispiel erzeugt der Testmustergenerator TSTM-CG Testbefehle, die statistisch den Verkehrsfluß simulieren, der die Ampelanlage in ihre einzelnen Zustände umspringen läßt. Mit der erfindungsgemäßen Betriebstestvorrichtung können beliebige Testsysteme auf Grundlage eines Zustandsmodells statistisch getestet werden. In nur kurzer Zeit kann lediglich auf Grundlage der möglichen SUT-Zustände und Zustandsänderungen, der Befehle, welche die Zustandsänderungen bewirken, der Verkehrswerte und der aktuellen Hardware-Konfiguration des Testsystems ein Test durchgeführt werden, der das Testsystem unter solchen Testbedingungen testet, die tatsächlich beim Einsatz des Testsystems unter realen Betriebsbedingungen herrschen.

Die Verarbeitung der Testmuster durch das SUT kann in Echtzeit durchgeführt werden, wobei der TCG die erzeugten Muster sofort über das Interface INT an das Testsystem SUT sendet und alle simulierten Zeiten der realen Zeit entsprechen. In einer anderen Ausführung der erfindungsgemäßen Betriebsvorrichtung können die Testmuster zuerst generiert und in einem Testmusterspeicher TCS abgelegt werden, um erst später während des eigentlichen Tests vom TCG geladen und ausgeführt zu werden. Vorteile dieser Ausführungsform sind die Möglichkeit, die Testmuster vor der Ausführung sichten und editieren zu können (etwa um Duplikate zu vermeiden), sie an andere Orte versenden zu können, um den Test dort auszuführen, und um sie bei wiederholten Tests mehrfach ausführen zu können, ohne daß eine neue Simulation nötig ist.

Fig. 2a, 2b, 2c zeigen Ausführungsformen der erfindungsgemäßen Betriebstestvorrichtung zum Testen eines Telefonnetzes auf Grundlage des Zustandsmodells eines Mobilfunksystems und/oder eines Telefon-Festnetzes. Eine spezielle Software-Steuerung SWCtrl ("Software Control") ist zur Steuerung der Komponenten des Testmustergenerators TCG vorgesehen. Zum Black-Box-Test eines Telefonnetzes kann als Schnittstelle INT (siehe Fig. 1a) auf vorhandene Geräte wie Lastgeneratoren zurückgegriffen werden, die komplexere Aufgaben als die einfache Weiterleitung von Befehlen an das Testsystem (SUT) übernehmen, so daß die Schnittstelle INT zum Testsystem hier als eigene Vorrichtung zur Ausführung von Testmustern TCE ("Test Case Executor") ausgeführt ist. Dies kann beispielsweise auch ein Gerät sein, das angeschlossene Telefone oder Mobiltelefone ansteuert.

Für das in Fig. 2b gezeigte Mobilfunksystem erzeugt der Testmustergenerator TCG gleichzeitig Testbefehle für einen Lasttest LT, einen Konformitätstest CT und einen Störtest DT.

Beim Lasttest werden die Vermittlungsstellen MSC und BSC mit einer hohen Zahl von simulierten Telefonverbindungen belastet. Beim Konformitätstest werden einzelne Dienste des Mobilfunknetzes durch individuelle Steuerung von Mobiltelefonen MS und eines Luftschnittstellen-Simulators AIS (Air Interface Simulator) getestet. Der AIS simuliert mit Hilfe von variablen Dämpfungsgliedern die im realen Mobilfunknetz auftretenden Signalpegelveränderungen aufgrund der Bewegungen der Mobilteilnehmer zwischen den BTS-Sta­ tionen, die zu Handovern von Gesprächen zwischen den BTS-Sta­ tionen führen. Zusätzlich können über die Steuerung von Telefonen eines Fest-Telefonnetzes (PSTN) Vermittlungen zwischen dem Festnetz und dem Mobilfunknetz getestet werden.

Beim Störtest DT schließlich werden Leitungen zwischen den Vermittlungsstellen oder Komponenten innerhalb einer Vermittlungsstelle mittels geeigneter Störelemente (Unterbrechungsvorrichtungen) außer Funktion gesetzt, um die Fähigkeit des Mobilfunknetzes, sich bei Störungen selbst zu rekonfigurieren, zu verifizieren.

Für die verschiedenen Tests gibt es in Fig. 2b jeweils eine eigene Vorrichtung LT-TCE, DT-TCE und CT-TCE zur Ausführung von Testmustern TCE für jede Testart, weil die jeweiligen Schnittstellen zum Mobilfunknetz sehr unterschiedlich aussehen (Signalisierleitungen beim Lasttest, Mobiltelefone bzw. Festnetz-Telefone beim Konformitätstest und Störelemente, d. h. Unterbrechungsvorrichtungen, beim Störtest). Natürlich könnte eine mögliche Ausführung der Testvorrichtung auch mehrere dieser TCEs in einem Gerät vereinigen, sofern dieses über geeignete Schnittstellen zum Mobilfunknetz verfügt.

Wie in Fig. 2b ersichtlich kann die Software-Steuerung des TCG auch über ein Datennetz von einer entfernten Station erfolgen, wodurch die Nutzung der Testhardware von Standorten möglich wird, an denen eine solche Test-Hardware nicht zur Verfügung steht ("Remote Test").

Fig. 2c zeigt, analog zu dem allgemeinen Blockschaltbild in Fig. 1a, schematisch die Geräte und Datenflüsse im Testaufbau für das Testen des Telefonnetzes. Die Zustände, die das reale Telefonnetz bzw. seine Teilnehmer einnehmen können, lassen sich aus den formalen Spezifikationen des Telefonnetzes ableiten, beispielsweise in einem GSM-Netz einfache Zustände wie der Ruhezustand ("Idle"), der Wählzustand ("Dialing"), der Klingel-Zustand ("Ringing"), der Besetzt-Zustand ("Busy"), der Verbunden-Zustand ("Connected") usw. für die einzelnen Telefone. Moderne Mobilfunknetze stellen eine Vielzahl von derartigen Grundzuständen bereit, aber auch Zustände, die sich auf erweiterte Dienste beziehen, wie beispielsweise der Anruf-Umleitungs-Zustand ("Call Forwarded") etc. Die Verkehrsparameter, die dem Testmustergenerator eingegeben sind, sind (falls verfügbar) aus tatsächlich gemessenen Werten eines unter realen Betriebsbedingungen eingesetzten Telefonnetzes abgeleitet. Diese sind nicht ausschließlich systemspezifisch, sondern auch spezifisch für die Umgebung, in der sie gemessen wurden (Ort, Uhrzeit usw.), so daß sie für die Erzeugung eines orts- und zeitspezifischen Test-Zustandsmodells verwendet werden können, und zwar unabhängig von der Hardware-Konfiguration des Testsystems. Dazu werden in einem Telefonnetz statistische Verkehrsdaten gemessen, z. B. die Häufigkeit, daß mobile Teilnehmer einen kurzen einfachen Anruf während einer bestimmten Tageszeit (9-10 Uhr) durchführen, ohne spezielle Dienste (Anrufumleitung, Fax etc.) zu nutzen. Solche Messungen können lokal begrenzt auf bestimmte Gebiete durchgeführt werden, um die dortige lokale Charakteristik des Verkehrs zu messen (z. B. könnte die Häufigkeit von kurzen Gesprächen in dünner besiedelten Gegenden geringer sein als in Großstädten, in denen viele Geschäftsleute überwiegend kurze Gespräche führen). Somit existieren unterschiedliche Übergangswahrscheinlichkeiten für Zustandsänderungen von Mobiltelefonen MS, Base Station Controllern BTS oder Mobile Services Switching Centers MSC in dünnbesiedelten Gegenden, im Gegensatz zu denjenigen in Großstädten.

Der Testmustergenerator erhält außerdem Informationen über die aktuelle Hardware-Konfiguration und die Betriebsmittel des zu testenden Telefonnetzes, beispielsweise die Anzahl der Mobilstationen, die von den Teilnehmern abonnierten Dienstmerkmale des Netzes, die Anzahl der Testnetz-Telefone etc. Schließlich müssen dem Testmustergenerator TCG die Befehle zur Bewirkung von Zustandsänderungen im Telefonnetz bekanntgemacht werden, um beispielsweise vom Klingel-Zustand in den Verbunden-Zustand mittels des Befehls "Hörer abnehmen" zu gelangen. Aus diesen Informationen erzeugt der Testmustergenerator ein Test-Zustandsmodell des Telefonnetzes, in dem alle möglichen Zustandsänderungen mit ihren Wahrscheinlichkeiten und den auszuführenden Befehlen angepaßt an die verfügbare Testhardware enthalten sind. Der Testmustergenerator TCG erzeugt also auf Grundlage wiederum des erzeugten Test-Zustandsmodells statistisch (zufällig, nicht in deterministischer Abfolge) Testbefehle, die über die Vorrichtung zum Ausführen von Testmustern TCE ("Test Case Executer") auf den Hardware-Komponenten des Test- Telefonnetzes ausgeführt werden. Das heißt, es werden tatsächliche Rufe von den in dem Test-Telefonnetz vorhandenen Mobiltelefonen erzeugt, das Test-Telefonnetz vermittelt diese Anrufe und erzeugt Klingelsignale, Freizeichensignale etc., welche die Zustandsänderungen im Test-Telefonnetz reflektieren. Der TCE setzt also die vom TCG erzeugten Befehle in tatsächliche Zustandsübergänge im Test-Telefonnetz um.

Ein anders gearteter TCE für einen Störtest kann beispielsweise auch absichtlich Fehler erzeugen, beispielsweise die Unterbrechung einer Leitung zwischen zwei Mobilvermittlungsstellen MSC, wie in Fig. 2b gezeigt. Das heißt, der TCE führt gemäß der statistisch erzeugten Testbefehle tatsächliche Zustandsänderungen in dem Mobilfunksystem herbei. Der Test Case Executer TCE ist mithin ein Bestandteil der Betriebstestvorrichtung, die Signale für tatsächliche Zustandsänderungen in dem Test-Telefonnetz erzeugt. Sie bildet beispielsweise Teilnehmer (Mobiltelefone) und deren Zustandsänderungen, wie Wählen, Telefonieren, Abheben etc., nach (Konformitätstest) oder Störeinflüsse auf die Vermittlungsstellen (Störtest) oder den Signalisierverkehr einer großen Zahl von Telefonteilnehmern (Lasttest).

Gemäß einer weiteren Ausführungsform der Erfindung, wie in den Fig. 3a, 3b, 3c gezeigt, erzeugt der Testmustergenerator TCG-E nicht nur die Testbefehle, sondern erhält er auch im Vergleich mit Fig. 1a eine Rückkopplung über Signale aus dem Testsystem als Antwort auf die statistisch erzeugten Testbefehle. Diese Rückkopplung erfolgt in Form von Signalen, die von einer bidirektionalen Schnittstelle BD-INT ("Bidirectional Interface") vom Testsystem SUT an den Testmustergenerator gemeldet werden (Fig. 3a). Diese Signale können zur Fehlerauswertung verwendet werden, wie in Fig. 3b gezeigt. In einer einfachen Ausführung erzeugt der Test- Zustandsmodell-Simulator TSTM-Sim Zustandsfolgen, die vom Test-Zustandsmodell-Befehlsgenerator TSTM-CG in Testmuster, d. h. Folgen von Testbefehlen, umgesetzt werden. Im TSTM-Sim ist ein Zustandsspeicher StS (State Storage) enthalten, in dem der aktuelle Zustand des Test-Zustandsmodells während der Simulation festgehalten wird. Der TSTM-Simulator speichert für jeden Testbefehl, der an das SUT geschickt wird, das erwartete Signal in einem Puffer B ab. Über die bidirektionale Schnittstelle BD-INT werden die beobachteten Signale vom SUT empfangen und in einem zweiten Puffer A abgelegt. Auf beide Puffer A, B greift ein Vergleicher CMP ("Comparer") zu, der die Signale in den beiden Puffern A und B vergleicht. Bei Übereinstimmung werden die Signale in beiden Puffern gelöscht. Bei Nichtübereinstimmung wird vom Vergleicher ein Fehler ausgegeben, weil das Testsystem offensichtlich von seiner im Test-Zustandsmodell festgelegten Spezifikation abweicht.

Beispielsweise könnte der Testmustergenerator einen Testbefehl an die Mobilstation X zum Anwählen der Nummer einer bestimmten Mobilstation Y erzeugen. Dem Test- Zustandsmodell gemäß wird erwartet, daß die angerufene mobile Station Y klingelt sowie daß die Station X ein Freizeichen hört, und somit legt der Test-Zustandsmodell-Simulator die erwarteten Signale "Y klingelt" und "X hört Freizeichen" im Puffer B ab (die Signale müssen nicht unbedingt in einer bestimmten Reihenfolge gespeichert werden, sondern könnten Zeitmarken enthalten, die angeben, innerhalb welcher zeitlichen Intervalle die Signale erwartet werden). Treffen die entsprechenden beobachteten Signale vom SUT (rechtzeitig) ein, so erzeugt der Vergleicher keinen Fehler; andernfalls wird ein Fehler gemeldet (Signal traf gar nicht oder nicht rechtzeitig ein).

Der Testmustergenerator TCG erzeugt somit statistisch auf Grundlage des Test-Zustandsmodells sukzessive Zustandsänderungen, erzeugt die dazu gehörigen Testbefehle und wertet die vom Test-Telefonnetz rückgekoppelten Signale bezüglich der erwarteten Signale aus. Damit könnte die in Fig. 1a notwendige Aufzeichnungseinrichtung für Testergebnisse sich darauf beschränken, Fehler aufzuzeichnen, die der Testmustergenerator TCG erkannt hat.

Fig. 3c zeigt eine mögliche Ausführungsform, bei welcher der Zustandsmodell-Generator TSTM-G als Test-Zustandsmodell eine zeitkontinuierliche Markoffkette erzeugt, welche von dem Test-Zustandsmodell-Simulator TSTM-Sim in zufälliger Weise durchlaufen wird. Links sieht man eine graphische Darstellung der Markoffkette, rechts eine Tabelle der Parameter aller möglichen Übergänge und unten ein bei einem Durchlauf erzeugtes mögliches Testmuster einschließlich des Zeitfortschritts, Ausgabe des TSTM-CG und Signale des SUT. Die verschiedenen Knoten ○ bezeichnen die möglichen Zustände des gesamten Telefonnetzes. Diese ergeben sich aus möglichen Kombinationen der Zustände einzelner Telefonteilnehmer, wie sie aus der Telefonnetz-Spezifikation entnommen werden können. Kann ein einzelner Teilnehmer beispielsweise die Zustände "idle" (ruhend), "dialing" (wählend), "ringtone" (hört Freizeichen), "ringing" (läutet), "busytone" (hört Besetztzeichen) und "connected" (verbunden) annehmen, so ergeben sich bei zwei Teilnehmern etwa gültige Zustände wie "A idle, B idle", "A dialing B, B idle" und "A, B connected", während "A idle, B connected" kein gültiger Zustand des Netzes mit zwei Teilnehmern wäre.

Die Kanten → zeigen die möglichen Übergänge zwischen den Zuständen an. In einer solchen zeitkontinuierlichen Markoffkette sind für die einzelnen Übergänge anstelle von diskreten Wahrscheinlichkeiten mittlere Zeitdauern definiert, die Parameter einer Zufallsverteilung - der Exponentialverteilung - sind. Jeder mögliche Übergang dauert im Mittel die ihm zugeordnete Zeit, wobei sich allerdings im konkreten Einzelfall zufällige Zeiten ergeben, deren Wahrscheinlichkeit aus der Exponentialverteilung folgt. So kann ein Übergang mit einer mittleren Zeit von 10 s auch nach 5 s oder 30 s erfolgen, wobei die Wahrscheinlichkeit, daß ein Übergang innerhalb eines vorgegebenen Zeitintervalls (0,t) erfolgt, aus der Wahrscheinlichkeitsfunktion der Exponentialverteilung F(t) = 1-exp(-t/T), T = mittlere Dauer, berechnet werden kann. Für 0 s-5 s beträgt die Wahrscheinlichkeit bei T = 10 s beispielsweise F(5 s) = 39,34%, für 0 s-10 s F(10 s) = 63,21% und für 5 s bis 10 s F(10 s)-F(5 s) = 63,21%-39,34% = 23,87%.

Somit ergibt sich die Verweildauer in einem Zustand als minimale Zeit bis zum Eintreten eines möglichen Übergangs. Die Wahrscheinlichkeit, daß ein bestimmter von mehreren möglichen Übergängen eintritt, berechnet sich aus der Wahrscheinlichkeit, daß die konkrete, zufällig generierte Zeitdauer dieses Übergangs kleiner ist als das Minimum der Dauern der übrigen Übergänge. Die mittleren Zeiten T für die einzelnen Übergänge werden aus den Verkehrswerten ermittelt.

In einem Markoff-Test-Zustandsmodell werden für zwei PSTN-Tele­ fone A und B wie in Fig. 3c gezeigt, bereits 14 mögliche Zustände benötigt, wobei in dem gezeigten Modell nicht einmal die Fälle enthalten sind, in denen ein Teilnehmer seine eigene Nummer anwählt. Auch diese unsinnige Situation muß vom Telefonnetz korrekt gehandhabt und müßte deshalb getestet werden. Der Test-Zustandsmodell-Simulator TSTM-Sim erzeugt statistisch eine Zustandsfolge in der Kette aufgrund der exponentialverteilten Übergangsdauern, beispielsweise für den im unteren Teil von Fig. 3c dargestellten Fall. Beide Teilnehmer starten im Zustand "A idle, B idle", in dem sie so lange verharren, bis einer der beiden möglichen Übergänge nach "A dialing, B idle" (A beginnt zu wählen, B tut nichts) oder "A idle, B dialing") (B wählt, A tut nichts) eintritt, was jeweils im Mittel nach 3600 s geschieht (siehe Spalte "mittl. Dauer" in der Parametertabelle Fig. 3c). Im Mittel tritt irgendeiner von beiden nach 1800 s ein, was dann auch die mittlere Verweildauer im Zustand "A idle, B idle" ist. Im Beispiel startet A mit dem Wählen nach 2170 s, d. h. zufällig tritt der Übergang nach "A idle, B dialing A" zuerst ein. Wie aus der Parametertabelle ersichtlich ist, wird dabei ein Testbefehl "B: offhook, dial A" ausgeführt, d. h. der Test- Zustandsmodell-Befehlsgenerator TSTM-CG sendet den Befehl, den Hörer abzunehmen, an das Telefon B, gefolgt von einem Wählbefehl mit A als Parameter (im konkreten Einsatz würde hier A durch die Rufnummer des Telefons A ersetzt). Diese Befehle sollen im Testsystem dazu führen, daß Telefon B die entsprechenden Tasten drückt, was durch eine geeignete Vorrichtung zur Ausführung von Testmustern TCE (Test Case Executer), an welche die Telefone angeschlossen sind, erreicht werden kann. Im Beispiel wird zufällig nach 2 s ein Übergang nach "A dialing B, B dialing A" (beide Telefone rufen sich gegenseitig an) erzeugt. Die Wahrscheinlichkeit, daß dieser Übergang stattfindet, beträgt bei den angegebenen mittleren Übergangsdauern nur 0,2% (dies folgt aus den Eigenschaften der Exponentialverteilung, auf die hier nicht näher eingegangen werden soll), aber diese Situation tritt ja auch in der Realität nur äußerst selten ein.

Beim nächsten Übergang nach "A busytone, B busytone" (A Belegtton, B Belegtton) wird kein Befehl an das SUT gesendet, sondern während der 4-sekündigen Dauer bis zum Übergang treffen Signale vom SUT ein, die vom Vergleicher CMP ausgewertet werden (siehe unten). Im Zustand "A busytone, B busytone" verharren die Telefone 6 Sekunden, bevor zuerst Telefon B und 4 Sekunden später Telefon A auflegt und das System wieder im Ausgangszustand "A idle, B idle" st.

Wie bereits unter Bezugnahme auf Fig. 3a, 3b beschrieben, kann der Testmustergenerator TCG die rückgekoppelten Signale einer Fehlerauswertung unterziehen. Das Markoff-Test- Zustandsmodell kann aber die rückgekoppelten Signale nicht für die Erzeugung von neuen Testbefehlen verarbeiten, sondern es können lediglich die zurückgekoppelten Signale mit den erwarteten Signalen verglichen werden. Dazu dient die rechte Spalte "erwartetes Signal" in der Parametertabelle. Der Vergleicher CMP kann die empfangenen Signale mit diesen erwarteten Signalen vergleichen und bei Nichtübereinstimmung einen Fehler melden. Es wäre sogar denkbar, zu den erwarteten Signalen zulässige Zeitlimits zu definieren, so daß auch ein nicht rechtzeitig eingetroffenes Signal als Fehler erkannt würde.

Wie aus Fig. 3c ersichtlich, werden bereits mit nur zwei Telefonen 14 Zustände ○ in dem Markoffketten-Zustandsmodell benötigt. Mit der gewöhnlicherweise großen Anzahl von unabhängigen Teilnehmern (Mobiltelefonen oder herkömmlichen Telefonen) in einem Telekommunikationsnetz steigt der Umfang des Markoffketten-Test-Zustandsmodells stark an. Das Markoffketten-Test-Zustandsmodell eignet sich aber für das effiziente Testen mit einer begrenzten Anzahl von Telefonen, oder für das Testen von Testsystemen mit nur einer einzelnen Schnittstelle für Benutzer (die Telefone bilden beispielsweise mehrere Benutzerschnittstellen für ein Telefonnetz).

Unter Bezugnahme auf Fig. 4 wird nachstehend eine Ausführungsform der Betriebstestvorrichtung unter Verwendung eines Petri-Netz-Zustandsmodells erläutert, wobei ein Petri- Netz eine sehr kompakte Beschreibung eines Markoff-Modells mit einem immensen Zustandsraum ermöglicht, welcher zur Beschreibung eines Mobilfunksystems oder eines Telefonsystems mit einigen Dutzend oder mehr Teilnehmern notwendig ist.

Wie in Fig. 8a 1) gezeigt, besteht ein einfaches Petri-Netz- Modell aus Stellen, Transitionen, Kanten und Marken. Stellen sind mit Kreisen ○ angezeigt und bezeichnen z. B. die verschiedenen Zustände der Betriebsmittel, die bei dem Testsystem beteiligt sind, etwa die Betriebszustände der Telefone oder die einer Verbindung. Stellen können eine oder mehrere Marken enthalten, wobei die Marken als kleine schwarze Punkte dargestellt sind. Sie können beispielsweise die in dem Testsystem verfügbaren Betriebsmittel anzeigen, etwa die Telefone. Eine konkrete Verteilung von Marken im Petri-Netz wird als Markierung bezeichnet. Eine bestimmte Markierung entspricht einem ganz bestimmten Zustand des Netzes. Jeder mögliche Zustand des Netzes ist einer bestimmten Markierung eineindeutig zugeordnet. Transitionen sind mit ausgefüllten Rechtecken dargestellt und sie bezeichnen die Aktionen oder auch Interaktionen der Betriebsmittel, z. B. einen Verbindungsaufbau zwischen zwei Telefonen. Sie können Markierungen in neue Markierungen umwandeln und führen damit alle Zustandsübergänge im Petri- Netz herbei. Stellen und Transitionen sind durch Kanten miteinander verbunden, wobei eine Kante stets von einer Stelle zu einer Transition führt (Eingangskante der Transition bzw. Ausgangskante der Stelle) oder von einer Transition zu einer Stelle (Ausgangskante der Transition bzw. Eingangskante der Stelle). Eine Transition kann mit mehreren Stellen verbunden sein. Die Stellen, die über Eingangskanten einer Transition mit dieser verbunden sind, werden als Vorbereich der Transition bezeichnet. In Bild 8a 1) bilden die beiden Stellen oberhalb der Transition deren Vorbereich. Stellen, die über Ausgangskanten einer Transition mit dieser verbunden sind, bilden den Nachbereich der Transition. Im Beispiel bilden die Stelle oben rechts und unten den Nachbereich der Transition; Nachbereich und Vorbereich überlappen sich in diesem Beispiel. Umgekehrt kann eine Stelle mit mehreren Transitionen verbunden sein. Entsprechend bilden Transitionen den Vor- bzw. Nachbereich einer Stelle, wenn sie durch Eingangs- bzw. Ausgangskanten der Stelle mit dieser verbunden sind. Im Beispiel ist die einzige vorhandene Transition der Vorbereich für die Stellen unten und oben rechts, sowie der Nachbereich für die beiden Stellen oben.

Wie in Fig. 8a 2) dargestellt, sieht die Funktionsweise eines solch einfachen Petri-Netzes, welches in der Literatur als "Stellen-Transitions-Netz" bekannt ist, wie folgt aus: Eine Transition ist aktiviert, wenn in allen Stellen ihres Vorbereichs mindestens eine Marke vorhanden ist. Das heißt, eine Transition kann nur dann aktiviert sein, wenn in allen Stellen, von denen eine Kante aus in die Transition hineinführt, wenigstens eine Marke vorhanden ist; eine einzige Stelle ohne Marke deaktiviert die Transition bereits. Im allgemeinen können mehrere Transitionen gleichzeitig aktiviert sein, möglicherweise sogar durch gemeinsame Stellen in den Vorbereichen, d. h. bei sich überlappenden Vorbereichen der Transitionen. In Fig. 8a 2) links sind zum Beispiel die Transitionen T2 und T3 aktiviert, während T1 nicht aktiviert ist, da sich keine Marke in P1 befindet. Eine der aktivierten Transitionen wird zufällig ausgewählt und darf "feuern". Beim Feuern wird je eine Marke aus jeder Stelle des Vorbereichs der Transition abgezogen und in jede Stelle des Nachbereichs der Transition eine neue Marke abgelegt. Dadurch ergibt sich aus einer bestehenden Markierung eine Nachfolgemarkierung und damit ein neuer Zustand des Petri-Netzes. In Fig. 8a 2) wird zufällig T2 für das Feuern ausgewählt. Dabei wird die Marke aus P2 abgezogen und in P5 und P6 werden neue Marken abgelegt. Genausogut hätte T3 feuern können. Dann wären die beiden Marken aus P2 und P3 konsumiert und neue Marken in P3 und P6 abgelegt worden. Die Nachfolgemarkierung wäre in beiden Fällen verschieden; es würden also Übergänge in verschiedene Zustände durchgeführt.

Wenn die feuernde Transition einer anderen aktivierten Transition eine Marke aus dem Vorbereich entzieht, so daß diese danach deaktiviert ist, (wie im Beispiel T2 die Marke aus P2, die auch im Vorbereich von T3 liegt) so lag ein Konflikt vor, der durch die zufällige Auswahl der feuernden Transition gelöst wurde. Transitionen, die keine gemeinsamen Marken im Vorbereich beanspruchen, sind hingegen konfliktfrei und können nacheinander in beliebiger Reihenfolge feuern, wobei sich jeweils die gleiche Endmarkierung ergibt (im Beispiel wären T1 und T2 bzw. T1 und T3 konfliktfrei, wenn P1 eine Marke enthielte). Solche Transitionen können simultan feuern.

Wie in Fig. 8a 1) dargestellt, können die Kanten in Stellen- Transitionsnetzen zusätzlich mit einer Kantenanschrift versehen sein, die ein Kantengewicht anzeigt. Das Kantengewicht gibt an, wie viele Marken die Kante konsumiert bzw. produziert. Eine Eingangskante einer Transition, die mit der Anschrift "3" versehen ist, zieht beispielsweise drei Marken von der zugehörigen Stelle im Vorbereich ab. Sind weniger als drei Marken vorhanden, so ist die Transition deaktiviert und kann nicht feuern. Eine Ausgangskante einer Transition, welche die Anschrift "2" trägt, produziert beim Feuern der Transition zwei neue Marken in der zugehörigen Stelle des Nachbereichs.

Eine weitere Eigenschaft von Stellen-Transitions-Netzen sind die Kapazitäten von Stellen. Wenn eine Stelle eine endliche Kapazität n hat, so kann sie höchstens n Marken aufnehmen. Eine Transition, die durch ihr Feuern die Zahl der Marken in dieser Stelle auf mehr als n erhöhen würde, ist automatisch deaktiviert. Wenn also eine Stelle im Nachbereich einer Transition eine Kapazität von 2 hat, die Stelle bereits eine Marke enthält, und die Transition über einer Ausgangskante mit Anschrift 2 mit dieser Stelle verbunden ist, so ist diese Transition deaktiviert. Durch ihr Feuern würden 2 neue Marken in der Stelle abgelegt, so daß die Kapazität der Stelle um eine Marke überschritten wäre.

Stellen mit endlicher und unendlicher Kapazität sowie Kanten mit und ohne Anschrift können im gleichen Netz gemischt auftreten. Eine Kante ohne Anschrift wird als Kante mit Anschrift 1 interpretiert. Eine Stelle ohn 67453 00070 552 001000280000000200012000285916734200040 0002019651334 00004 67334e definierte Kapazität hat unendliche Kapazität.

Stellen-Transitions-Netze der oben beschriebenen Art wurden 1962 in der Dissertation von Carl Adam Petri erstmals beschrieben und dienten zur Analyse von kommunizierenden endlichen Automaten. Seit dieser Zeit wurden sie zur Spezifikation und Analyse komplexer Systeme mit inhärentem Parallelismus eingesetzt, z. B. zur Analyse von Kommunikationsprotokollen. Daraus wurden mannigfaltige Erweiterungen und neue Typen von Petri-Netzen abgeleitet. Gemäß der Erfindung werden beispielsweise folgende weitere Typen von Kanten mit anderem Verhalten als Erweiterungen vorgesehen.

In Fig. 8a 3) werden folgende Kantentypen des Petri-Netzes verwendet:

Flußkante:
Flußkanten sind Kanten des oben beschriebenen "normalen" Typs, welche als Eingangskanten einer Transition diese aktivieren, wenn in der darüber verbundenen Stelle ○ im Vorbereich der Transition wenigstens die dem Kantengewicht entsprechende Zahl von Marken enthalten ist. Als Ausgangskante einer Transition legen Flußkanten beim Feuern die dem Kantengewicht entsprechende Zahl von Marken in die mit ihnen verbundene Stelle im Nachbereich.

Testkante:
Testkanten überprüfen die Inhalte der zugeordneten Stelle im Vorbereich der Transition. Die Transition kann nur feuern, wenn die dem Kantengewicht entsprechende Anzahl von Marken in der Stelle vorhanden ist. Beim Feuern werden diese Marken entfernt und die gleiche Anzahl von neuen Marken wird in die Stelle wieder hineingelegt, so daß die Transition de facto feuert, ohne die Markierung dieser Stelle zu verändern. Testkanten sind eine Kombination aus Eingangs- und Ausgangs-Flußkante der Transition. Das gleiche Verhalten kann durch zwei antiparallele Kanten zwischen der Transition und der Stelle erreicht werden, welche die gleiche Anschrift tragen.

Verbotskante:
Verbotskanten können nur Eingangskanten von Transitionen sein. Sie deaktivieren Transitionen: Die Transition darf genau dann nicht feuern, wenn wenigstens die dem Kantengewicht entsprechende Zahl von Marken in der zugehörigen Stelle vorhanden ist. Verbotskanten realisieren eine Negation als Eingangsbedingung der Transition.

Abräumkante:
Abräumkanten sind ebenfalls Eingangskanten von Transitionen. Sie besitzen keinen Einfluß auf die Aktivierung oder Deaktivierung einer Transition. Es spielt für das Feuern keine Rolle, ob und wie viele Marken in der zugehörigen Stelle im Vorbereich vorhanden sind. Wenn aber die Transition durch andere Kanten aktiviert ist und feuert, werden alle Marken, die in Stellen enthalten sind, welche über Abräumkanten mit der Transition verbunden sind, entfernt. Da Abräumkanten ohnehin alle Marken aus einer Stelle entfernen, tragen sie kein Gewicht. Sie dienen üblicherweise zum Aufräumen eines Netzes mit unbestimmter Markierung.

Bei sogenannten Stochastischen Petri-Netzen SPN kann die Zufallsauswahl der feuernden Transitionen beeinflußt werden. Dies ist in Fig. 8a 4) dargestellt. Dazu werden den Transitionen stochastische Raten bzw. mittlere Dauern zugeordnet (mittlere Dauer = 1/Rate), die ähnlich wie bei zeitkontinuierlichen Markoffketten gehandhabt werden. Bei der Bestimmung der feuernden Transition ermittelt jede aktivierte Transition eine zufällige, exponentialverteilte Wartezeit, deren Mittelwert durch die stochastische Rate oder mittlere Dauer festgelegt ist; jeder einzelne zufällige Wert kann dabei jedoch größer oder kleiner als der Mittelwert sein. Wenn mehrere Transitionen gleichzeitig aktiviert sind, feuert diejenige zuerst, welche die kürzeste Wartezeit ermittelt hat. Im Mittel feuern solche Transitionen häufiger, deren mittlere Dauern kleiner (bzw. deren stochastische Raten größer) sind als die anderer Transitionen. Wie in Fig. 8a 4) zu sehen ist, feuert eine Transition mit stochastischer Rate 0,1 bei sechsmaligem Feuern im Mittel nur einmal, eine mit Rate 0,5 fünfmal. Diese Zahlen sind natürlich nur Mittelwerte, und im Einzelfall kann dieses Verhältnis auch anders aussehen, wie es den Gesetzen der Stochastik entspricht.

In einer Verallgemeinerung der Stochastischen Petri-Netze, die als Generalisierte Stochastische Petri-Netze GSPN bezeichnet werden, gibt es neben den stochastischen Transitionen mit endlicher stochastischer Rate und Dauer auch solche mit einer unendlichen Rate bzw. unendlich kurzen Dauer. Solche deterministischen Transitionen dürfen bei ihrer Aktivierung sofort feuern und schlagen damit alle stochastischen Transitionen. Dieses Prinzip läßt sich weiter fortsetzen zu einer Staffelung von sogenannten deterministischen Prioritäten, die alle vor den stochastischen Raten Vorrang und untereinander eine feste Anordnung haben. Eine aktivierte Transition mit höherer deterministischer Priorität wird immer vor allen anderen deterministischen Transitionen mit geringerer Priorität gefeuert, und vor allen Transitionen mit stochastischer Rate. Zur einfachen Simulation von Zeit kann die mittlere Dauer der Transition als tatsächliche Zeit betrachtet werden, wie dies im Markoffketten-Beispiel in Bild 3c der Fall war.

Zur Erzeugung von stochastisch verteilten Testmustern kann ein Petri-Netz in analoger Weise wie eine Markoffkette verwendet werden, indem den Transitionen bestimmte Aktionen zugeordnet werden, die beim Feuern ausgeführt werden. In Bild 4a ist die Struktur eines Testmustergenerators auf der Basis eines Petri-Netz-Testmodells dargestellt. Der Testmuster- Generator TCG-PN hat eine völlig analoge Struktur zu dem allgemeinen Testmuster-Generator mit Rückkopplung TCG-F aus Fig. 3b. An die Stelle des Test-Zustandsmodellgenerators TSTM-G tritt ein Petri-Netz-Modell-Generator PNM-G, der das generierte Petri-Netz-Modell im Petri-Netz-Modell-Speicher PNM-S ablegt. Der Petri-Netz-Modell-Simulator PNM-Sim übernimmt die Struktur des Petri-Netz-Modells (Stellen, Transitionen und Kanten) mit den zugehörigen Parametern wie Kantenanschriften und stochastische Raten sowie die Anfangsmarkierung des Netzes, die in einem internen Markierungsspeicher MSt abgelegt wird, und simuliert das Petri-Netz ausgehend von der Anfangsmarkierung in analoger Weise wie der TSTM-Sim in Fig. 3b eine zeitkontinuierliche Markoffkette ausgehend vom Startzustand simuliert. Der PNM-Simu­ lator lädt jeweils die aktuelle Markierung aus dem Markierungsspeicher MSt, wählt die zu feuernde Transition nach dem Monte-Carlo-Prinzip aus und schreibt die sich ergebende Folgemarkierung zurück in den Markierungsspeicher. Die feuernden Transitionen werden dem Petri-Netz-Modell- Befehlsgenerator PNM-CG mitgeteilt, der aus dem Modellspeicher PNM-S die zugehörigen Transitionsaktionen lädt und interpretiert. Als Ausgabe werden Befehle an das SUT gesendet. Beobachtete Signale werden als Rückkoppelung in den Puffer A eingelesen, während die aufgrund der Simulation erwarteten Signale vom Petri-Netz-Modell-Simulator PNM-Sim in Puffer B gespeichert werden. Der Vergleicher CMP ist dann mit dem aus Fig. 3b identisch.

Während Fig. 4a den erfindungsgemäßen Testmustergenerator zeigt, der ein Petri-Netz-Modell verwendet, zeigt Bild 4b eine Ausführungsform eines mögliches Petri-Netz-Testmodells, das dem Modell aus Fig. 3c in seiner Funktionsweise entspricht.

Im Beispielnetz in Fig. 4b sind die stochastischen Raten als mittlere Dauern an den Transitionen vermerkt. Aktionen, die vom PNM-CG an das SUT gesendet werden sollen, sind in den Transitionssymbolen vermerkt. Die beiden Marken in den Stellen "A idle" und "B idle" zeigen zunächst an, daß zwei Telefon-Teilnehmer untätig sind. Jeder von beiden kann nun spontan mit dem Wählen beginnen, da beide Dial-Transitionen ("A dials" und "B dials") aktiviert sind. Beide können auch gleichzeitig wählen. Die mittlere Wartezeit bis zum Wählen eines bestimmten Teilnehmers beträgt 3600 s. Angenommen, die Transition "B dials" feuert, dann wird die Marke aus der "B-Idle"-Stel­ le entfernt, eine Marke in die "B-Dialing"-Stelle gelegt und der in der "B-Dials"-Transition angegebene Aktionsblock vom PNM-CG an das SUT gesendet. Nun sind zwei Transitionen aktiviert: "A dials" und "A free", d. h. entweder beginnt nun auch A zu wählen (dies dauert im Mittel 3600 s) oder nicht (dann geschieht im Mittel nach 7 s ein normaler Verbindungsaufbau). Die Verbotskante von der Stelle "A idle" zur Transition "A not free" verhindert, daß die Transition aktiviert ist, solange A noch nicht wählt. Feuert hingegen "A dials" und zieht damit die Marke aus "A idle" ab, so wird "A not free" aktiviert und "A free" deaktiviert, weil es eine Flußkante von "A idle" nach "A free" gibt. In analoger Weise setzt sich die Simulation des Netzes fort. Die generierten Testmuster entsprechen genau denen, wie sie in Fig. 3c generiert wurden.

Die Zustände der Telefone A und B sind hier nicht mehr in einem Gesamtzustand zusammengefaßt, sondern in individuellen Stellen realisiert. Auf diese Weise spart das Petri-Netz- Modell Stellen. Dieser Vorteil ist bei 2 Telefonen noch nicht so offensichtlich, aber je mehr Telefone simuliert werden, desto stärker kommt er zum Tragen. Die Zahl der Stellen wächst linear mit der Zahl der simulierten Teilnehmer, während bei einer Markoffkette eine exponentielle Zunahme der Zustände notwendig ist.

Eine weitere Verkleinerung des Modells erreicht man mit sogenannten "Farbigen Petri-Netzen" bzw. "Farbigen Stochastischen Petri-Netzen" (Coloured Petri Net, CPN; Coloured Stochastic Petri Nets, CSPN). Bei einem Farbigen Petri-Netz sind die Marken individuell unterscheidbar. Im einfachsten Fall kann man sich die Marken als verschieden gefärbt vorstellen. Es gibt dann etwa eine Menge von roten, gelben, grünen und blauen Marken. Kanten könnten dann Anschriften der Form "Farbe x" tragen. Eine Transition mit zwei Eingangskanten, welche beide die Anschrift "Farbe x" tragen, dürften nur dann feuern, wenn die zugehörigen Stellen im Vorbereich der Transistion Marken der gleichen Farbe enthielten. Genau diese Marken würden dann entfernt. Der Petri-Netz-Simulator würde in dieser Situation nach einer konsistenten Variablenbindung suchen, d. h. er würde Marken derart suchen, daß alle Kantenanschriften "Farbe x" mit dem gleichen Wert von x, also der gleichen Markenfarbe, identifiziert würden, und nur Marken der ausgewählten Farbe könnten über die Kante die Transition aktivieren. Wenn dies mangels vorhandener Marken scheitert, ist die Transition deaktiviert. Es kommt also für die Aktivierung nicht mehr nur auf die Anzahl der Marken in den Stellen des Vorbereichs an, sondern auch auf die Farben der Marken.

In der Praxis verwendet man ein allgemeineres Modell, das die erfügbaren Farben als Werte gewisser Datentypen interpretiert, wobei die Datentypen als Farbmengen (Colour Sets) bezeichnet werden. So könnten "Hellblau", "Himmelblau" und "Tintenblau" die Farbmenge "Blau" bilden oder aber 1, 6 und 49 Werte der Farbmenge "ganze Zahl" oder "integer" sein. Eine Stelle im farbigen Petri-Netz kann nur Marken einer bestimmten Farbmenge halten, und dies ist dann die Farbmenge dieser Stelle. Transitionen können hingegen mit Stellen unterschiedlicher Farbmengen verbunden sein. Mengen von Variablen als Kanteninschriften steuern die Auswahl der Marken, da für sie eine konsistene Bindung der Markenwerte und die Variablen gefunden werden muß.

Fig. 8b zeigt dieses Konzept. In Fig. 8b 1) ist die Notation eines farbigen Netzes erläutert. Hier werden die den stellen zugehörigen Farbmengen kursiv neben die Stelle geschrieben. Marken werden direkt durch ihren Farben (Werte) dargestellt. Man sieht hier zwei Marken, eine integer-Marke und eine Marke, die ein Tupel aus zwei integer-Werten bildet. In diesem Fall handelt es sich trotzdem nur um eine Marke, die allerdings zwei Felder für Werte beinhaltet. Analog denkbar sind Tupel mit weiteren Feldern und Tupel, die Felder verschiedener Datentypen kombinieren (Fließkommazahlen, Text, kleinere Tupel etc.). Die Kantenanschriften bestehen aus einer durch Kommata getrennten Aufzählung von Marken, bei denen die Werte durch Variablen ersetzt sind. "(x, y)" bezeichnet z. B. eine Zweitupel-Marke, "y, x" bezeichnet zwei integer-Marken, "(x, y), 2(a, b, c)" beschreibt eine Zweitupel- Marke und zwei Dreitupel-Marken. Kanten ohne Anschrift sind in farbigen Netzen nicht mehr erlaubt, und die Anschriften müssen in ihrer Struktur zur Farbmenge der mit der Kante verbundenen Stelle passen (also darf nicht etwa ein Tupel (a, b) an einer Ein- oder Ausgangskante einer Integer-Stelle vermerkt sein).

In Fig. 8b 2) wird demonstriert, wie in einem Farbigen Netz des Vorgang des Feuerns abläuft. Da die obligatorischen Kantenanschriften bereits die Farbmenge einer Stelle anzeigen, sind sie hier zur besseren Übersicht nicht mehr zusätzlich an den Stellen vermerkt.

Zunächst wird nach einer zu den Kantenanschriften der Eingangskanten der Transition passenden Variablenbindungen gesucht, welche die Transition aktivieren. Wird keine gefunden, so ist die Transition deaktiviert. Im Beispiel sind jedoch zwei Bindungen x = 2, y = 1 und x = 1, y = 1 möglich. Beim Feuern wird zufällig eine davon ausgewählt, wobei jede der möglichen Bindungen mit gleicher Wahrscheinlichkeit ausgewählt wird. Gemäß der gewählten Bindung werden über jede Eingangskante die zugehörigen Marken aus den Stellen entfernt. Im Beispiel entfernt z. B. die Kante mit der Anschrift x, y die beiden Marken 2 und 1 aus der Stelle ganz rechts. Die Anschrift (y, x) an der linken Ausgangskante sorgt nun dafür, daß über diese Kante eine neue Marke mit dem Wert (1,2) in die zugehörige Stelle links unten gelegt wird, während vermöge der Anschrift 2y zwei Marken mit dem Wert 1 von der rechten Ausgangskante in der zugehörigen Stelle rechts unten abgelegt werden.

In Fig. 4c wird der Vorteil der farbigen Petri-Netze offensichtlich. Dieses Netz hat nur noch 7 Stellen anstelle von 11 beim unfarbigen Netz aus Fig. 4b. Dennoch realisiert es alle Testmuster, die auch das unfarbige Netz erzeugen konnte und sogar noch weitere Testmuster: Zunächst fällt auf, daß in diesem Netz drei Telefone als Marken in der Stelle "Idle Phones" abgelegt sind. Das Netz simuliert alle Testmuster für drei, aber auch für mehr Telefone, wenn eine entsprechende Zahl von Marken in der Anfangsmarkierung enthalten sind. Eine neue Stelle "Phone Book" enthält noch einmal die gleichen Marken wie "Idle Phones" und steuert die Auswahl des angerufenen Teilnehmers. Dies kann hier im Gegensatz zu den bisherigen Beispielen auch der anrufende Teilnehmer selbst sein: Der Teilnehmer kann seine eigene Nummer wählen. Alle Teilnehmer, deren Nummer gewählt werden kann, sind in dieser Stelle vermerkt. Sie wird bei der "A dials"-Transition nur abgefragt, ohne daß die Markierung geändert wird (Testkante). Es ist nicht schwierig, den Fall, daß ein Teilnehmers sich selbst anwählt, durch eine eigene Transition mit einer anderen stochastischen Rate zu behandeln; im Beispiel wurde jedoch darauf verzichtet. Die stochastische Rate der "A dials"-Transition wurde der Zahl von Teilnehmern angepaßt und auf eine mittlere Dauer von 1200 s gesenkt, so daß jeder einzelne Teilnehmer wie in Fig. 4b im Mittel nach 3600 s einen Wählversuch startet. Nach dem Wählen ist die dem wählenden Teilnehmer entsprechende Marke aus der "Idle Phones"-Stelle entfernt worden und eine neue Tupel-Marke mit den Werten des Anrufers in der ersten und des Angerufenen in der zweiten Komponente ist in der Stelle "A dialing B" abgelegt worden. Beispielsweise könnte dies das Tupel (1,1) sein, also Teilnehmer 1 ruft sich selbst an. In diesem Fall ist die Transition "B free" deaktiviert: Da eine Flußkante mit Anschrift "B" von "Idle Phones" nach "B free" führt und die Kante von "A dialing B" nach "B free" durch die Kantenanschrift (A, B) den Wert von B zwangsläufig an den Wert 1 bindet (zweite Komponente der Marke (1,1) in "A dialing B"), wird in "Idle Phones" keine Marke mit dem gleichen Wert von B, also 1, gefunden, denn diese war ja beim Feuern von "A dials" abgezogen worden. Aus genau dem gleichen Grund wirkt jedoch die Verbotskante von "Idle Phones" nach "B not free" nicht verbietend auf die Transition "B not free", denn Verbotskanten verhalten sich genau entgegengesetzt wie Flußkanten. "B not free" ist also aktiviert und feuert im Mittel nach 5 s. Da A an die erste Komponente von (1,1) gebunden war, wird eine Marke mit dem Wert 1 in die Stelle "A busytone" abgelegt und simuliert damit, daß Teilnehmer 1 ein Besetztzeichen hört, wie es bei einem gewöhnlichen Telefonnetz zu erwarten ist. Dem Teilnehmer bleibt dann keine andere Wahl als nach kurzer Zeit den Hörer auflegen und sich damit wieder zu den "Idle Phones" zu gesellen. Wenn hingegen ein Tupel (1,2) in der Stelle "A dialing B" liegt, so ist der Markenwert 2 noch in "Idle Phones" verfügbar und die Transition "B free" ist aktiviert, während "B not free" nicht aktiviert ist (Verbotskante verhindert die Aktivierung). Gleichzeitig ist ebenfalls die Transition "A dials" aktiviert, es kann also jederzeit ein weiterer Teilnehmer einen Wählversuch beginnen, auch der Angerufene (z. B. 2 wählt 1 an). Erst wenn die Transition "B free" nach einem im Mittel 7 Sekunden dauernden simulierten Verbindungsaufbau gefeuert hat, wird der Angerufene aus der "Idle Phones"-Stelle entfernt (sofern er nicht selbst schon einen Wählversuch unternimmt und damit "B not free" aktiviert) und eine Tupel- Marke mit den Werten des erfolgreich vermittelten Teilnehmer- Paares in "A ringtone, B ringing" abgelegt. Der Angerufene ist jetzt nicht mehr "idle", obwohl er selbst noch keine Aktion durchgeführt hat; ein weiterer Anrufer würde in "A busytone" enden, also ein Besetztzeichen hören. Von dieser Stelle ausgehend kann nun abgesehen von neuen Wählversuchen anderer Teilnehmer entweder der Angerufene B den Ruf entgegennehmen (Transition "B answer" nach im Mittel 10 s) oder der Anrufer A legt auf (Transition "B no reply" nach durchschnittlich 20 s). Im zweiten Fall werden beide Teilnehmer wieder in die Stelle "Idle Phones" gelegt und ein Befehl "A: onhook" vom PNM-CG an das SUT gesendet.

Wie man sieht, ist die Netzstruktur viel einfacher als beim unfarbigen Netz und die Mächtigkeit trotzdem weitaus höher. Alleine durch das Hinzufügen von Marken in "Idle Phones" und "Phone Book" können beliebig viele Telefone angesteuert werden, ohne weitere Stellen oder Transitionen einführen zu müssen. Mit einem derartigen Testmustergenerator auf Grundlage eines farbigen Petri-Netz-Testmodells können Testmuster bzw. Testbefehle zum Durchfahren eines Betriebstests für ein Telekommunikations-System zum ersten Mal automatisch für eine große Anzahl von simulierten Teilnehmern in kürzester Zeit durchgeführt werden.

Die in Fig. 8a 4) gezeigte Realisierung des stochastischen Feuerns wurde in den beiden Beispielen aus Fig. 4b und 4c zusätzlich zur Steuerung des Zeitfortschritt des Netzes verwendet. Da die ermittelten Transitionsdauern alle einer Exponentialverteilung genügen, ist die Modellierbarkeit realer Systeme mit dieser Art von Netzen stark eingeschränkt, wenn dadurch auch eine Analyse vereinfacht wird. In der Realität beobachtet man zum Beispiel bei der Dauer von Telefongesprächen ein Verhalten, das durch eine Gammaverteilung besser approximiert wird als durch eine Exponentialverteilung. Wenn man allerdings andere Verteilungen der Transitionsdauern zuläßt, verliert man die angenehmen Analyseeigenschaften der Stochastischen Petri- Netze.

Die vorliegende Erfindung schlägt einen Ansatz vor, bei dem Transistionsauswahl und Zeitfortschritt getrennt sind. Dieser Ansatz wird in Fig. 8b 3) vorgestellt wird. Hier ist das gleiche (unfarbige) Petri-Netz zu vier verschiedenen Zeiten dargestellt. Die Transition ist hier nicht mehr mit einer stochastischen Rate oder Dauer beschriftet, die in solch einem Netz nur noch für die Auswahl der feuernden Transition verwendet würde. Die stochastische Rate wäre hier für den Zeitfortschritt völlig ohne Bedeutung, da in dieser Art von Netzen Transitionen stets zeitlos feuern. Statt dessen ist die Stelle S2 durch einen doppelten Ring hervorgehoben und mit einer Zeit von 5 s beschriftet. S2 ist eine Stelle mit Latenz, d. h. Wartezeit.

Im Beispiel feuert zunächst T1 zur Zeit 0 s. Dabei vergeht keine Zeit. Im zweiten Bild, immer noch zur Zeit 0 s, ist von T1 eine Marke in die Stelle mit Latenz S2 abgelegt worden. Eine Marke, die in S2 abgelegt wird, ist für 5 s "latent" d. h. gewissermaßen nicht wirklich vorhanden und damit auch nicht aktivierend für die Transition T2. Dies bleibt unverändert bis zum Zeitpunkt 5 s. Dann endet die Latenz der Marke und T2 wird aktiviert. Ohne Zeitfortschritt feuert daraufhin T2 und entfernt die Marke aus S2.

In diesem Beispiel war die Latenz eine Konstante. Sie kann aber auch durch eine Wahrscheinlichkeitsverteilung angegeben werden und damit für jede neu abgelegte Marke einen anderen Wert annehmen. Wenn mehrere Marken nacheinander in dieselbe latente Stelle gelegt werden, so gelten ihre Latenzen individuell vom Augenblick des Ablegens. Eine latente Stelle realisiert mithin ein Warteschlangennetz mit unendlich vielen Bedienstationen, die alle die gleiche, durch die Latenz gegebene Bedienzeit aufweisen. Ersetzt man in Fig. 4c die Stelle "Idle Phones" durch eine Stelle mit 3600 s Latenz, so braucht dieser Wert nicht mehr der Zahl der Marken angepaßt zu werden, sondern mehr Marken (mehr Teilnehmer) führen von alleine zu mehr Wählversuchen pro Zeiteinheit, weil jeder Teilnehmer seine eigene Latenz hat. In gewöhnlichen stochastischen Petri-Netzen wie Fig. 4c feuert hingegen eine Transition nur so häufig wie es ihrer stochastischen Rate entspricht, gleichgültig, wieviele Marken zur Verfügung stehen.

Fig. 4d zeigt das gleiche Petri-Netz wie Fig. 4c mit latenzbehafteten Stellen anstelle von zeitbehafteten Transitionen. Die an den Transitionen vermerkten stochastischen Raten dienen nur noch zur Bestimmung der Transitions-Feuerfolge und damit der relativen Verhältnisse in der Feuerhäufigkeit zwischen den Transitionen, ohne einen Zeitfortschritt zu generieren. Daher werden sie hier nur noch als stochastische Prioritäten bezeichnet. Der Zeitfortschritt ist vollkommen in den latenzbehafteten Stellen enthalten. In diesem Netz entsprechen die Wartezeiten etwa denjenigen aus dem Netz in Fig. 4c. Zum Beispiel ist die Verweildauer eines Tokens in der Stelle "A ringtone, B ringing" in Fig. 4d exponentialverteilt mit Mittelwert 6.67 s (gegeben durch den Ausdruck ran_exp(6.67 s), der den Aufruf eines Zufallsgenerators für die Exponentialverteilung bei der Latenzbestimmung symbolisiert). In Fig. 4c ergibt sich die Verweildauer aus der Überlagerung der exponentialverteilten Feuerungsdauern der beiden Transitionen "B answer" und "B no reply", die wiederum eine Exponentialverteilung mit Rate =Sum­ me beider Transitionsraten (1/(10 s) + 1/(20 s) = 0.15/s) mit Mittelwert 1/(0.15) = 6.67 s ergibt (Mittelwert = Kehrwert der Rate). Die Dauer zwischen Wählversuchen wird in Fig. 4d durch eine Stelle "Start Call" simuliert, bei der zum Feuern eine unfarbige Marke herausgenommen und wieder hineingelegt wird. Da die hineingelegte Marke latent ist, kann die Transition erst wieder nach der Wartezeit von im Mittel 1200 s feuern. Hätte man die Stelle "Idle Phones" als latenzbehaftete Stelle ausgeführt, so wäre diejenige Marke in "Idle Phones", die als angerufener Teilnehmer B ausgewählt wurde, für das Feuern der Transition "B free" nicht verfügbar, sofern sie noch latent wäre.

Vorteil der latenzbehafteten Stellen ist, daß andere Verteilungen als die Exponentialverteilung zur Modellierung von Verzögerungen zur Verfügung stehen. Das Petri-Netz selbst verhält sich aufgrund der stochastischen Prioritäten, wenn der Zeitfortschritt außer Acht gelassen wird, weiterhin wie eine Markoffkette (dies wird als "eingebettete Markoffkette" bezeichnet). Dies wäre nicht der Fall, wenn die Auswahl der Transitionen durch anders geartete Verteilungen gesteuert würde, und damit wären Analysen des Netzes in vielen Fällen nicht mehr durchführbar.

Bei der in Fig. 4 gezeigten Ausführungsform der Betriebstestvorrichtung können vom Testsystem rückgekoppelte Zustandsänderungen zur Fehlerauswertung im Vergleicher VGL verwendet werden, so wie dies in Fig. 3b erläutert wurde. Bei der in Fig. 4 gezeigten Ausführungsform muß jedoch angenommen werden, daß die Zustände des Testsystems, vorgegeben durch die Testbefehle, jeweils exakt dem aktuellen Zustand des Petri-Netzes (d. h. den von den Marken belegten Stellen) entsprechen. Wenn ein Testbefehl nicht zur erwarteten Zustandsänderung im Testsystem SUT führt, geraten das Petri- Netz und das Testsystem hingegen aus der Synchronisation, so daß die weitere Erzeugung von Testbefehlen nicht mehr zu nachvollziehbaren Zustandsänderungen im SUT führen kann und der Testlauf somit abgebrochen werden muß. Natürlich bedeutet ein Verlust der Synchronisation zwischen Zustandsmodell und Testsystem einen entdeckten Fehler im SUT und in manchen Anwendungen mag es ausreichen, den Testlauf nach einem gefundenen Fehler abzubrechen. Zur Bestimmung einer Mean Time To Failure (MTTF) ist es jedoch wünschenswert, nach einem Fehler weiter testen zu können, um eine Statistik der Fehlerhäufigkeit zu messen. Dafür ist es jedoch erforderlich, Informationen über den Zustand des SUT in das Zustandsmodell rückzukoppeln.

Die in Fig. 5 gezeigte Ausführungsform des erfindungsgemäßen Test Oase Generators stellt eine derartige Verbesserung der Erfindung dar. Fig. 5a zeigt zunächst die Struktur eines Testmustergenerators auf der Grundlage von Petri-Netzen mit Rückkopplung TCG-PNF. Der PNM-Simulator enthält als zusätzliches Element einen Signal Handler PNM-SH, der die beobachteten Signale empfängt und verarbeitet. Das Petri- Netz-Modell enthält neben den Transitionsaktionen auch einen Code für den Signal Handler. Dieser modellabhängige Code weist den Signal Handler an, in Abhängigkeit von den beobachteten Signalen Marken in den Markierungsspeicher MSt zu legen. Somit erscheinen die beobachteten Signale des SUT sofort als Marken in gewissen Synchronisationsstellen des Petri-Netz-Modells, um dort das Feuern von Transitionen zu beeinflussen und den Ablauf der Simulation zu verändern. Im Petri-Netz-Modell kann nun durch geeignete Transitionen und latenzbehaftete Stellen entschieden werden, ob das beobachtete Signal dem erwarteten entspricht und zur rechten Zeit eingetroffen ist. Andernfalls kann als Transitionsaktion eine Fehlerausgabe erfolgen.

In Fig. 8b 4) ist ein solches Netzelement des erfindungsgemäßen Petri-Netzes dargestellt, welches das rechtzeitige Eintreffen eines Signals überwacht. Die Transition "Do Action & Start Timer" sendet einen Befehl an das SUT und legt eine farbige Marke in die latenzbehaftete Stelle "Timer" ab, die eine deterministische Latenz t hat. Gleichzeitig wird eine Marke des gleichen Werts in die Stelle "Wait" abgelegt. Eine durch Fettdruck als Synchronisationsstelle gekennzeichnete Stelle "Observed Signal" dient dazu, eine vom Signal Handler erzeugte farbige Marke aufzunehmen, wenn ein Signal empfangen wird. Die Kantenanschriften "x" sollen sicherstellen, daß nur passende Signale akzeptiert werden. Wird beispielsweise das Läuten des Telefons mit der Nummer 3 erwartet, so muß der Signal Handler eine Marke mit dem Wert 3 erzeugen, wenn das entsprechende Signal vom SUT empfangen wird. Trifft eine solche Marke innerhalb der Latenzzeit t ein, und hat sie die zu den Marken in "Wait" und "Timer" passende Farbe, so wird die Transition "on Time" aktiviert und feuert. Man beachte, daß Abräumkanten stets alle Marken aus einer Stelle abräumen, ob sie latent sind oder nicht. Nur durch diese Semantik kann erreicht werden, daß die Abräumkanten ihrem eigentlichen Sinn, eine dicht genau bekannte Markierung in eine wohldefinierte Markierung zu überführen, auch in Netzen mit latenzbehafteten Stellen gerecht werden, da auch latente Marken zur undefinierten Markierung gehören könnten. Wenn also "on Time" feuert, so hat das Netz entschieden, daß das erwartete Signal rechtzeitig eingetroffen ist und die Timer-Marke wird abgezogen. Trifft das Signal jedoch nicht ein, so wird "on Time" nie aktiviert, und statt dessen feuert die Transition "Timeout" nach dem Ablaufen der Latenz der Marke in "Timer". Dadurch entscheidet das Netz, daß das erwartete Signal nicht rechtzeitig eingetroffen ist, und eine geeignete Transitionsaktion könnte einen Fehler drucken. Ein zu spät eintreffendes Signal bleibt danach in "Observed Signal" liegen; es könnte aber auch durch eine weitere Transition, die genau dann aktiv ist, wenn kein Signal erwartet wird (angezeigt durch eine weitere Stelle), sofort abgeräumt werden.

Fig. 5b zeigt das Petri-Netz aus Fig. 4d mit einer Synchronisation zum SUT, d. h. es werden Signale vom SUT im Netz berücksichtigt. Die Struktur des Netzes ist weitgehend identisch mit der aus Fig. 4d. Es gibt hier jedoch drei Synchronisationsstellen "Busytone", "Ringtone" und "B-Ringing", die signalisieren, daß Teilnehmer A ein Besetztzeichen oder Freizeichen hört bzw. das Telefon von Teilnehmer B läutet. Zwei latenzbehaftete stellen "Busytimer" und "Ringtimer" überwachen mit dem oben beschriebenen Konstrukt das rechtzeitige Eintreffen der Signale innerhalb von 10 s. "Ringtimer" erwartet hier gleich zwei Signale, nämlich das Freizeichen bei A und das Läuten bei B. Nur wenn beide Signale als Marken vorliegen und die Werte der Marken dem A- bzw. B-Teilnehmer entsprechen, feuert die Transition "Ring Signals OK". Wenn hingegen der "Ringtimer" abläuft, feuert die Transition "Timeout", die den A-Teilnehmer auflegen läßt und mit Hilfe des Befehls "errormsg" eine Fehlermeldung ausgibt. Nach dem gleichen Verfahren wird der Besetztton verarbeitet. Erwähnenswert sind noch die Abräumkanten von den Synchronisationsstellen zur Transition "A dials". Sie stellen sicher, daß beim nächsten Wählversuch eines Teilnehmers an einen anderen Teilnehmer alle zugehörigen Marken (und nur diese!) aus früheren Gesprächen abgeräumt werden. Da die Abräumkanten keinen Einfluß auf das Feuern der Transition "A dials" haben, spielt es keine Rolle, ob tatsächlich Marken vorhanden sind oder nicht.

Ein ähnlicher Mechanismus kann dazu verwendet werden, die für einen Test verfügbaren Betriebsmittel (Telefone, Basisstationen o. ä.) bzw. deren Charakteristika (z. B. die von den simulierten Teilnehmern abonnierten Sonderdienste wie Rufumleitung, Konferenzgespräche usw., die in einem GSM-Netz für jeden Teilnehmer vom Netzwerkbetreiber einzeln freigeschaltet werden müssen) im Test-Petri-Netz in Form von Marken automatisch zu importieren (Autokonfiguration). Vor dem Beginn der Simulation könnten beispielsweise von der bidirektionalen Schnittstelle BD-INT die Zahl und bei farbigen Petri-Netzen zusätzlich die Identität der angeschlossenen Telefone im Netz bekanntgemacht werden, indem Marken (bei farbigen Netzen mit den Identitäten als Wert) für die betreffenden Telefone in geeignete Stellen abgelegt werden. Wenn für einen Teilnehmer ein Dienst vor oder während der Simulation frei geschaltet wird, könnte in einer dem Dienst zugeordneten speziellen Synchronisationsstelle, die eine Marke für jeden Teilnehmer enthält, der diesen Dienst nutzen darf, eine farbige Marke mit dem Wert des Teilnehmers erscheinen. Voraussetzung hierfür ist, daß die Schnittstelle BD-INT diese Information in Form von Signalen liefert, sei es selbständig bei jeder Änderung oder auf Anforderung durch das Petri-Netz.

Fig. 5c zeigt einen Ausschnitt aus einem farbigen Netz, in dem die Identitäten der Telefone und die von ihnen abonnierten Dienste "Multiparty" (Konferenzgespräch) und "Call Forwarding" (Rufumleitung) in Synchronisationsstellen in Form von farbigen Marken abgelegt werden. In der Transition "Setup Call" wird (hier stark vereinfacht) ein Ruf zwischen zwei Telefonen aufgebaut. Die Transition "Join" ermöglicht das Hinzunehmen eines weiteren Teilnehmers zur Bildung einer Dreierkonferenz, wenn der A-Teilnehmer (derjenige, der den Ruf initiiert hatte) den Multiparty- Dienst abonniert hat. Andernfalls kann der Ruf nur durch die Transition "End Call" beendet werden. Das Netz erlaubt zusätzlich, daß einzelne Teilnehmer eine Rufumleitung zu anderen Teilnehmern schalten können, sofern sie Call Forwarding abonniert haben. In dem Beispielnetz wird der Übersichtlichkeit halber nicht gezeigt, wie ein Teilnehmer bzw. das Telefonsystem auf einen umgeleiteten Ruf reagieren soll.

Die in den fett gedruckten Synchronisationsstellen gehaltenen Marken können vor oder während der Simulation vom Signal- Handler PNM-SH in den Stellen abgelegt werden, wenn entsprechende Signale von der bidirektionalen Schnittstelle BD-INT geliefert werden (autonom oder auf Anforderung vom Petri-Netz).

Wie unter Bezugnahme auf Fig. 4b und Fig. 5b erläutert, werden Marken in einem Anfangszustand, beispielsweise in "Idle Phones" und "Phone Book" plaziert, um die Erzeugung der Testbefehle zu starten. Während der Abarbeitung des Petri- Netzes durch den Petri-Netz-Modell-Simulator PNM-Sim feuern die Transitionen und es werden Marken von Stellen entfernt bzw. zu anderen Stellen hinzugefügt, so daß sich neue Markierungen ergeben. Ein aktueller "Schnappschuß" ("Snap Shot") während einer Abarbeitung des Petri-Netzes weist also eine bestimmte Markierung des Petri-Netzes auf. Bei regelmäßiger Synchronisierung entspricht der äußere Zustand des Testsystems dem inneren Zustand des Testmodells.

Um beliebige Anfangszustände oder Zwischenzustände vorgeben zu können, wäre es wünschenswert, eine Rücksetzung der inneren Zustände und der äußeren Zustände mittels der Testbefehle durchführen zu können. Eine weitere in Fig. 6 gezeigte Ausführungsform des erfindungsgemäße Testcasegenerators ermöglicht eine derartige Rücksetzung.

Fig. 6 zeigt einen Testmustergenerator, dessen PNM-Simulator einen Rücksetzspeicher RSt enthält, der "Snap Shots", d. h. aktuelle Markierungen des Netzes, während der Abarbeitung des Petri-Netzes temporär speichern kann. Diese Snap-Shot- Markierungen können, wie durch einen Pfeil von PNM-Sim zum Speicher PNM-S angedeutet, auch permanent in das gespeicherte Petri-Netz-Modell übernommen werden. Es gibt eine Reihe von Gründen, warum es vorteilhaft ist, eine derartige Speicherung von Markierungen vorzunehmen und das Netz in einem Schritt wieder diese Zustände zurücksetzen zu können. Wenn man das Netz mit verschiedenen Anfangszuständen starten möchte, kann man sich beispielsweise eine Bibliothek der gewünschten Startzustände anlegen (z. B. um verschiedene Dienste des Testsystems individuell zu untersuchen). Wenn Fehler des Testsystems entdeckt werden, kann das Netz die Markierung, bei welcher der Fehler entdeckt wurde, automatisch festhalten und die Situation später von einem menschlichen Tester anhand des Snap Shots analysiert werden. Schließlich ist es sinnvoll, nach einem vom Testmustergenerator entdeckten Fehler des Testsystems zur Neusynchronisation sowohl das Testsystem als auch das Petri-Netz-Modell schnell wieder in einen definierten Zustand zu überführen.

Bei einer durch einen entsprechenden Testbefehl (Transitions- Aktion) veranlaßten Rücksetzung weist der Petri-Netz- Befehlsgenerator den Petri-Netz-Modell-Simulator an, eine Snap-Shot-Markierung aus dem Rücksetzspeicher RSt zu laden und die aktuelle Markierung auf diese Snap-Shot-Markierung zurückzusetzen. Damit wird das Petri-Netz in einem Schritt wieder in den Zustand versetzt, als die Snap-Shot-Markierung gespeichert wurde.

Fig. 7 zeigt eine Ausführungsform, bei der die Ausführungsformen der Fig. 4, 5, 6 kombiniert sind, d. h. es werden Testbefehle auf Grundlage des Petri-Netz- Zustandsmodells erzeugt (Fig. 4), eine Synchronisierung wird mit farbigen Marken durchgeführt (Fig. 5) und eine Rücksetzung auf vorgegebene Markierungen wird ermöglicht (Fig. 6).

Fig. 7b zeigt ein einfaches Beispiel, bei dem Rücksetzbefehle nach einer durch Synchronisationsstellen ermöglichten Entdeckung von Fehlern verwendet werden, um das Netz wieder in den Startzustand zu versetzen. In Fig. 7b ist ein Teil des Netzes aus Fig. 5b dargestellt, ergänzt um Aktionen, die das Speichern und Zurückholen von Snap-Shot-Markierungen übernehmen. Zunächst gibt es eine unfarbige Stelle "Start", von der ausgehend eine Verbots kannte das Feuern der Transition "A dials" verhindert. Statt dessen ist die Transition "Init" aktiviert. Wenn sie feuert, wird die Marke aus "Start" entfernt und die aktuelle Markierung vermöge des Befehls "store "start"" unter dem Namen "start" im Rücksetzspeicher abgelegt. Die Snap-Shot-Markierung "start" enthält also keine Marke mehr in der Stelle "Start", so daß das Netz sofort die Transition "A dials" feuern kann. In den "Timeout"-Transitionen, die feuern, wenn Signale vom SUT nicht rechtzeitig eintreffen, sind Befehle "reset "start"" enthalten, welche die Snap-Shot-Markierung "start" wieder laden. Damit wird das Netz wieder im Ausgangszustand gestartet. Damit auch das SUT in den Ausgangszustand versetzt wird, werden alle verfügbaren Telefone (und nicht nur die an diesem Ruf beteiligten) mittels des Befehls "all: onhook" aufgelegt.

Obwohl die Erzeugung von Testbefehlen, die Synchronisation und die Rücksetzung speziell unter Bezugnahme auf Ausführungsform für ein Telefonnetz beschrieben wurde, ist eine derartige Erzeugung von Testbefehlen, eine derartige Rückkopplung von Zustandsänderungen zur Synchronisation und eine derartige Rücksetzung nicht auf das Testen eines Telefonnetzes beschränkt, obwohl es sich hier besonders vorteilhaft auswirkt. Beliebige Testsysteme können mit den beschriebenen Betriebstestvorrichtungen unter Zuhilfenahme des Petri-Netz-Modells getestet werden, um die "mean time to failure"-Werte zu bestimmen, die für jeden Abnahmetest unabhängig von dem zu testenden System maßgeblich sind.

Abschließend wird unter Bezugnahme auf Fig. 8c ein ausführlicheres Beispiel eines Petri-Netzes angewandt auf ein einfaches Telefonnetz erläutert. Solche Darstellungen von Petri-Netzen können von dem Testmustergenerator unter Verwendung des in Fig. 2a, 2b gezeigten Editors angezeigt werden, vor einer Abarbeitung des Petri-Netzes und auch während einer Abarbeitung des Petri-Netzes.

In Fig. 8c ist ein Petri-Netz-Modell-Generator PNM-G als Editor (NEXT) ausgeführt, mit dem ein Modell für ein sehr einfaches Telefonnetz angefertigt wurde. Es sind mehrere Fenster geöffnet, darunter das Hauptfenster mit den Editorfunktionen und der obersten Ebene des Petri-Netz- Modells (NEXT - "demo"), ein kleineres Fenster, in dem die Transition "A calls B" als Sub-Petri-Netz mit feinerer Granularität modelliert ist (NEXT-Subsystem - "A calls B"), und zwei Dialogfenster, die den Inhalt einer Stelle (NEXT Place) und einer Transition (NEXT Transition) zeigen. Bei diesem Petri-Netz-Modell-Generator ist es möglich, das Modell hierarchisch zu strukturieren, indem Transitionen Subnetze enthalten können; in diesem Fall werden sie vom Editor als weiß ausgefüllte Rechtecke dargestellt. Alle Stellen, die mit solchen Subnetz-Transitionen verbunden sind, sind im Subnetz als Ein-/Ausgabestelle verfügbar. Ein Subnetz wird in einem eigenen Fenster dargestellt und kann wiederum Subnetze beinhalten. So kann auch ein recht komplexes Petri-Netz übersichtlich dargestellt werden, so wie ein komplexes Software-Programm durch Unterteilung in Unterprogramme übersichtlicher wird.

Die stochastischen Prioritäten der Transitionen, die an das Testsystem (SUT) zu sendenden Testbefehle (Action) und mögliche Prädikate (Predicate) sind nicht im Netz selbst dargestellt, sondern in einem Fenster, das für jede Transition durch Mausklick geöffnet werden kann, um die in der Netzdarstellung enthaltene Information auf ein überschaubares Maß zu beschränken. Prädikate sind hierbei logische Ausdrücke, die über den Variablen der Kantenanschriften aufgestellt werden können und die von einer aktivierenden Variablenbindung erfüllt sein müssen, damit die Transition feuern kann (im Beispiel wird z. B. verlangt, daß a ungleich b sein muß, also die Marke b aus "Phone Book" und die Marke a aus "Inactive Subscribers" müssen verschiedene Werte haben, sonst feuert die Transition "A dials B" nicht. Als Testbefehl sendet diese Transition den Befehl "dial from = a to = b", d. h. die Marke a bestimmt den Anrufer, der die Nummer des Angerufenen, repräsentiert durch die Marke b, wählen soll. Die Variablen a und b werden bei der Ausführung des Befehls durch die Werte der Marken ersetzt, die beim Feuern an diese Variablen gebunden wurden. Die Transition feuert mit einer stochastischen Priorität, die hier einer Exponentialverteilung mit Rate 1 entspricht ("Exponential Rate: 1"). Deterministische Prioritäten können ebenfalls gewählt werden.

In dem Fenster, das Informationen über eine Stelle (Place) enthält, kann die Kapazität ("Capacity") der Stelle auf einen endlichen oder unendlichen Wert gesetzt werden. In "Select Type of Place" läßt sich die Farbe einstellen, die alle Marken in dieser Stelle haben müssen; im Beispiel sind das für die Stelle "Connections" Marken der Farbe "Connection", die als Zweitupel von ganzen Zahlen definiert ist. Die Stelle ist mit einer Latenz behaftet, da "Latency Expression" aktiv ist; der Latenzausdruck "_ran_exponential (15 000)" beschreibt hierbei eine Zufallszahl, die von einem Zufallsgenerator für exponentialverteilte Zahlen mit einem Mittelwert von 15 000 erzeugt wird. Jede neue Marke erhält also eine neue, zufällige Latenz gemäß dieser Verteilung, wobei die Latenz hier in ms angegeben wird. Im Feld "Tokens Contained" sind schließlich zwei Marken zu sehen, die aktive Marke (3,2) und die latente Marke (1,4). Beide Marken haben (genau wie auch die Stelle selbst und jede Transition) eine laufende Identifikationsnummer, hier 1973 und 1965, die nur für die interne Verarbeitung verwendet werden und die in der Petri- Netz-Semantik ohne Bedeutung sind. Die Werte 1, 2, 3 und 4 beschreiben konkrete Telefone im Testsystem; ihre Rufnummern brauchen nicht im Modell, sondern nur dem Befehlsgenerator bzw. der Vorrichtung zum Ausführen von Testmustern (INT, TCE) bekannt zu sein, da erst dort der endgültig ausformulierte, an das Testsystem zu sendende Testbefehl erzeugt wird. Das Stellen-Fenster beinhaltet schließlich noch eine Reihe von Knöpfen, über die neue Marken definiert werden können ("New Token"), die Werte von Marken verändert ("Edit Token"), bestimmte Marken gelöscht ("Delete Token") oder alle Marken entfernt werden können ("Delete All Tokens").

Die Struktur des dargestellten Petri-Netzes ist einfach und völlig analog zu dem in Fig. 4d dargestellten Beispiel, wenn auch die konkrete Implementierung des Beispiels nicht völlig identisch ist.

Wie voranstehend beschrieben, kann also bei der erfindungsgemäßen Betriebstestvorrichtung und dem Betriebstestverfahren lediglich auf Grundlage der Hardware- Konfiguration, der möglichen Zustände, der zum Zustandswechsel nötigen Testbefehle und der Verkehrswerte (Übergangswahrscheinlichkeiten bzw. stochastische Prioritäten) ein Test-Zustandsmodell des Telefonnetzes erzeugt und mittels eines Editors angezeigt oder verändert werden. Der Zustandsmodell-Simulator führt eine zufallsgesteuerte Simulation des Petri-Netzes auf Grundlage der Transitionsprioritäten und der aktuellen Markierung aus. Beim Feuern einer Transition wird der Text einer Transitionsaktion an den Befehlsgenerator gesendet, der den Text als Befehl interpretiert und einen entsprechenden Testbefehl an das Testsystem sendet.

Diese Verwendung von Petri-Netzen zum Erzeugen von Testbefehlen oder Testmustern stellt somit eine Betriebstestvorrichtung bereit, die ein komplexes Testsystem, beispielsweise ein Telefonnetz oder ein Mobilfunknetz, mit Testbedingungen testen kann, die den tatsächlich beim Betrieb auftretenden Betriebsbedingungen nahekommen. Der Betrieb ist automatisiert und erlaubt somit eine große, statistisch signifikante Anzahl von Testmustern in kürzester Zeit zu generieren. Somit können die Kosten für einen Integrations-, System- oder Abnahmetest verringert werden.

Obwohl in den voranstehend beschriebenen Figuren in der Telekommunikationstechnik, insbesondere in der GSM-Technik, die dem Durchschnittsfachmann allgemein geläufigen englischsprachigen Ausdrücke angegeben sind, bestehen folgende Äquivalenzen dieser Ausdrücke in der deutschen Sprache:

"idle" → "ruhend"
"dialling" → "wählend"
"ring tone" → "hört Freizeichen"
"ringing" → "läutet"
"busy tone" → "hört Besetztzeichen"
"connected" → "verbunden"
"disconnected" → "getrennt"
"off hook" → "abgehoben" oder "eingeschaltet"
"on hook" → "aufgelegt" oder "abgeschaltet"
"not free" → "nicht frei"
"no reply" → "keine Antwort"
"replace" → "ersetzen"
"quit" → "Ende"
"answer" → "Antwort"
"terminate" → "Beenden"
"idle phones" → "Telefone im Ruhezustand"
"phone book" → "Telefonbuch"
"busy" → "Besetzt-Zustand"
"multi-party enabled" → "Mehrparteiverbindung freigegeben"
"forwarding enabled" → "Rufweiterleitung freigegeben"
"set-up call" → "Anrufaufbau"
"set forward" → "Weiterleitung einstellen"
"2-party-calls" → "Anrufe mit zwei Parteien"
"active forwards" → "aktive Weiterleitungen"
"end call" → "Anruf beenden"
"join" → "vereinen"
"end forward" → "Rufweiterleitung beenden"
"3-party-calls" → "Anrufe mit drei Parteien"
"start call" → "Anruf beginnen"
"store "start"" → "Start "Speichern""
"expect busy tone" → "erwarte Belegtzeichen"
"busy timer" → "Belegtzustand-Zeitgeber"
"ring timer" → "Klingelzustand-Zeitgeber"
"time out" → "Auszeit"
"expect ringing & ring tone" → "erwarte Klingelzustand & Klingelzeichen"
"reset "start"" →"Start "Zurücksetzen""
"ring signals OK" → "Klingelsignale O.K."
"connections" → "Verbindungen"
"active subscribers" → "aktive Teilnehmer"
"breaks" → "Unterbrechung"
"inactive subscriber" → "nicht aktiver Teilnehmer"
"request" → "Anforderung".

Nachstehend wird eine Ausführungsform des Betriebstestsystems beschrieben, wobei es sich bei dem zu testenden System SUT um eine allgemeine Kommunikationsvorrichtung KV handelt und der voranstehend beschriebene Testmustergenerator TCG und die Testvorrichtungs-Schnittstelle INT zusammengenommen eine Testvorrichtung TV bilden. Mittels der erzeugten Testbefehle wird eine Hardwareunterbrechung von elektrischen Verbindungsleitungen (Hardware Disturber) der Kommunikationsvorrichtung vorgenommen.

Fig. 9 zeigt den allgemeinen Aufbau eines Kommunikationssystems KS mit einer derartigen Kommunikationsvorrichtung KV und einer derartigen Testvorrichtung TV gemäß dieser Ausführungsform (KV entspricht somit dem zu testenden System und KV beinhaltet die Testvorrichtungs-Schnittstelle und den Testmustergenerator).

Das Kommunikationssystem KS besteht aus einer Kommunikationsvorrichtung KV und einer Testvorrichtung TV, die miteinander verbunden sind. Weiter sind in Fig. 9 ausgewählte Bestandteile der Kommunikationsvorrichtung, Telefone T₁ bis T_n und Übertragungsstationen UEV₁ bis UEV_n gezeigt. Die T₁ und T₂ bezeichnen Mobiltelefone, während T₃ ein herkömmliches Festnetztelefon beinhaltet. Weiter sind die Übertragungsstationen UEV₁ und UEV₂ Mobilfunkübertragungsstationen, die Funkverbindungen zu Mobiltelefonen aufbauen können. Die Übertragungsstation UEV₃ kann eine Übertragungsstation eines weiteren Kommunikationsnetzes oder eine andere Vorrichtung zur Übertragung von Daten in einer Kommunikationsvorrichtung gemäß der vorliegenden Erfindung sein. Die Kommunikationsvorrichtung muß u. a. sicherstellen, daß ein gerufenes Mobiltelefon im Netz lokalisiert werden kann, so daß, falls sich während eines Gesprächs ein Mobiltelefon aus dem Einzugsbereich einer Übertragungsstation hinausbewegt, das entsprechende Gespräch an eine andere Übertragungsstation übergeben werden kann und daß bestimmte Benutzer- Serviceleistungen aktiviert werden können. Die Kommunikationsvorrichtung ist zum Datenaustausch mit der Testvorrichtung verbunden, mit deren Hilfe Testprogramme (d. h. eine oder mehrere Abfolgen von Testmustern mit Testbefehlen vom Testmustergenerator) und/oder Testanweisungen d. h. die Testbefehle zum Testen der Kommunikationsvorrichtung erzeugt und ausgeführt werden können.

Das heißt, in dieser Ausführungsform wird die beschriebene Kommunikationsvorrichtung KV mit Testbefehlen angesteuert, die von der Testvorrichtung TV, d. h. dem Testmustergenerator TCG, der oben beschrieben wurde, auf Grundlage des Zustandsmodells erzeugt werden.

Fig. 10 zeigt ein Blockschaltbild eines weiteren Ausführungsbeispiels eines Kommunikationssystems gemäß der vorliegenden Erfindung. Eine Testvorrichtung TV besteht aus einer zentralen Signalverarbeitungsvorrichtung ZV, die entfernt von der Kommunikationsvorrichtung KV angeordnet ist. Weiter besteht die Testvorrichtung aus einer Unterbrechungsvorrichtung UV (d. h. einem bereits oben diskutierten Störelement), die innerhalb einer Übertragungsstation UEV der Kommunikationsvorrichtung angeordnet ist, um eine Vielzahl von elektrischen Verbindungsleitungen der Übertragungsstation UEV gezielt bzw. mit genauen Zeitvorgaben unterbrechen zu können. Die Unterbrechungsvorrichtung UV ist zum Empfangen von Bediensignalen mit einer in der zentralen Signalverarbeitungsvorrichtung angeordneten Wandlervorrichtung WV verbunden. Die Wandlervorrichtung steht mit einer programmierbaren Datenverarbeitungsvorrichtung S in Verbindung. Diese Datenverarbeitungsvorrichtung S ist der besagte voranstehend beschriebene Testmustergenerator TCG.

Mit Hilfe der programmierbaren Datenverarbeitungsvorrichtung S können Testanweisungen automatisch oder von einem Bediener interaktiv erzeugt werden. Die Wandlervorrichtung wandelt die gemäß den Testanweisungen erzeugten digitalen Testsignale in Bediensignale um und überträgt diese Bediensignale zur Unterbrechungsvorrichtung UV, durch die während eines Tests einzelne elektrische Verbindungsleitungen oder Gruppen von elektrischen Verbindungsleitungen innerhalb der Übertragungsstation in Abhängigkeit von den Bediensignalen für bestimmte Zeitabschnitte zu unterbrechen.

Gleichzeitig werden die Auswirkungen der Unterbrechungen auf das Kommunikationssystems durch z. B. manuelles Wählen, Sprechen, Aktivieren von Benutzerservices, festgestellt.

In einem anderen Ausführungsbeispiel können Auswirkungen der Unterbrechungen auch über einen Abfrageplatz an der Übertragungsstation UEV festgestellt werden.

Fig. 11 zeigt ein weiteres Ausführungsbeispiel eines Kommunikationssystems gemäß der vorliegenden Erfindung. Hier sind Anschluß- bzw. Antennenkabel von Telefonen T₁ bis T_n und Übertragungsstationen UEV₁ bis UEV_n mit einer Bewegungssimulationsschaltung BS der Testvorrichtung verbunden, die es ermöglicht, Mobiltelefonbewegungen und Luftstrecken zu simulieren, bzw. nachzubilden. Weiter ist die Wandlervorrichtung mit den Telefonen T₁ bis T_n sowie mit einer Unterbrechungsvorrichtung UV innerhalb der Übertragungsstation UEV₁ zur Steuerung der Telefone und der Unterbrechungsvorrichtung durch Bediensignale und zum Empfang von Antwortsignalen von den Telefonen verbunden (d. h. diese Bedien-Antwortsignale entsprechen den in Fig. 5a ff. gezeigten beobachteten Signale des Testsystems, die in den Testmustergenerator für das Petri-Netz TCG-PNF zurückgekoppelt werden). Die Bewegungssimulationsschaltung und die Wandlervorrichtung sind jeweils mit der programmierbaren Datenverarbeitungsvorrichtung S (Testmustergenerator) verbunden.

Während des Testens werden Testanweisungen (Testbefehle) von der programmierbaren Datenverarbeitungsvorrichtung (d. h. die Testbefehle, die vom Testmustergenerator TCG auf Grundlage des Zustandsmodells erzeugt werden) zum Bedienen der Unterbrechungsvorrichtung, wie bereits anhand von Fig. 10 beschrieben, sowie Testanweisungen zum simulierten Bewegen der Mobiltelefone zwischen Übertragungsstationen geliefert. Weiter liefert die Wandlervorrichtung auch Bediensignale zum Bedienen der Tastaturen und Mikrophone der Telefone und empfängt Antwortsignale von den Lautsprechern und Rufvorrichtungen der Telefone.

Es wird darauf hingewiesen, daß die Anschluß- bzw. Antennenkabel der Telefon und der Unterbrechungsvorrichtungen UV_1-n nicht an die Bewegungssimulationsschaltung BS angeschlossen werden müssen, falls keine Bewegungssimulation erforderlich ist. Weiterhin können zusätzliche Unterbrechungsvorrichtungen UV_1-n in einer oder mehreren Übertragungsstationen UEV_1-n vorgesehen sein.

Fig. 12 zeigt ein Flußdiagramm eines Testvorgangs in einem Kommunikationssystem gemäß Fig. 10. Anweisungen (Befehle) zum Testen der Kommunikationsvorrichtung werden in der programmierbaren Datenverarbeitungsvorrichtung S erzeugt, bzw. in einem Speichermedium gespeicherte Testanweisungen oder Testprogramme abgerufen und ausgeführt. Wird die Ausführung der Testanweisungen/Testprogramme erwünscht, werden von der programmierbaren Datenverarbeitungsvorrichtung S digitale Testsignale erzeugt, die zur Wandlervorrichtung WV übertragen und dort in Bediensignale umgewandelt werden. Die Bediensignale steuern die Unterbrechungsvorrichtung UV. Es wird bzw. werden demgemäß eine oder mehrere der elektrischen Verbindungsleitungen innerhalb der Übertragungsstation UEV gezielt für definierte Zeitabschnitte unterbrochen. Gleichzeitig wird die Kommunikationsvorrichtung KV manuell betrieben, z. B. Wählen, Sprechen. Es wird die Funktion der Kommunikationsvorrichtung KV dokumentiert bzw. es werden dokumentierte Daten automatisch in der programmierbaren Datenverarbeitungsvorrichtung S ausgewertet.

Gemäß dem in Fig. 11 gezeigten Kommunikationssystem kann das Betreiben des Netzes auch automatisch unter Steuerung von Testanweisungen/Testprogrammen vorgenommen werden. In diesem Fall werden vom Testmustergenerator TCG erzeugte digitale Testsignale von der Datenverarbeitungsvorrichtung S in der Wandlervorrichtung WV in zusätzliche Bediensignale umgewandelt, um die Tastaturen und die Mikrophone der Telefone T₁ bis T_n zu bedienen. Zudem werden von der Kommunikationsvorrichtung KV über Sprechkanäle übertragene Bediensignale von den Lautsprechern und Bediensignale von den Rufvorrichtungen der Telefone in der Wandlervorrichtung WV in digitale Bedien-Antwortsignale umgewandelt und zur programmierbaren Datenverarbeitungsvorrichtung S übertragen und dort dokumentiert, bzw. ausgewertet.

Über die Sprechkanäle können über die Testvorrichtung TV dabei, durch Testanweisungen gesteuert, Identifizierungssignale übertragen werden, die jeweilige an einem Gespräch beteiligte Telefone identifizieren. Dazu wird ein Sprechkanal zwischen jedem Paar von Telefonen einer Vielzahl von Telefonen bei einem Zweitelefongespräch oder einer Konferenzschaltung mit drei oder mehreren Teilnehmern aufgebaut und ein ein erstes Telefon eindeutig identifizierendes Muster von Tonimpulsen über den Sprechkanal von dem ersten Telefon ausgehend übertragen. Der Empfang des über den Sprechkanal übertragenen Musters von Tonimpulsen wird in einem zweiten am Gespräch beteiligten Telefon überwacht. Dabei findet die Übertragung des Musters von Tonimpulsen zwischen dem ersten und dem zweiten Telefon in der Gegenwart von Sprachkomprimierung und Sprachdekomprimierung, wie z. B. bei GSM üblich, statt. Das Muster von Tonimpulsen ist so gewählt, daß eine Identifikation des ersten Telefons auch möglich ist, wenn das Muster von Tonimpulsen am zweiten Telefon bei Verwendung von Sprachkomprimierung und Sprachdekomprimierung empfangen wird.

Fig. 13 zeigt eine Teilansicht einer Testvorrichtung gemäß der vorliegenden Erfindung. Eine Vielzahl von externen Datenverarbeitungsvorrichtungen oder Datensichtstationen C₁ bis C_n ist über eine Datenfernübertragungsstation DFV an die programmierbare Datenverarbeitungsvorrichtung S angeschlossen. Hier sind die externen programmierbaren Datenverarbeitungsvorrichtungen C₁ bis C_n Klienten, während die programmierbare Datenverarbeitungsvorrichtung S ein Server ist. In dem gezeigten Ausführungsbeispiel können Testanweisungen oder Testprogramme auf den externen Datenverarbeitungsvorrichtungen erzeugt und/oder ausgeführt werden.

Fig. 14 zeigt ein Flußdiagramm eines entsprechenden Testvorgangs. Es können voneinander unabhängige Testprogramme oder Testanweisungen auf einer oder auf mehreren der externen Datenverarbeitungsvorrichtungen ausgeführt werden. Die Testanweisungen werden von den externen Datenverarbeitungsvorrichtungen über die Datenfernübertragungsstation DFV zur programmierbaren Datenverarbeitungsvorrichtung S (Server) in einem sogenannten Client-Prozeß übertragen. Gemäß der im Client-Prozeß übertragenen Anweisungen erzeugt der Server S digitale Steuersignale, die zu der Wandlervorrichtung bzw. zu der Bewegungssimulationsvorrichtung in einem sogenannten Server- Prozeß übertragen werden.

Fig. 15 zeigt ein Blockschaltbild der Anordnung einer Unterbrechungsvorrichtung gemäß der vorliegenden Erfindung in einer Übertragungsstation. Die Unterbrechungsvorrichtung ist zwischen die Kontaktleisten KL₁ und KL₂ einer Schaltungskarte SK bzw. eines Schaltungskartenträgers ST, die normalerweise direkt miteinander verbunden sind, zwischengeschaltet. Es können so gezielt einzelne Leitungsverbindungen zwischen dem Schaltungskartenträger ST und Schaltungskarten SK für bestimmte Zeitabschnitte unterbrochen werden.

Anders als im gezeigten Ausführungsbeispiel können auch eine Vielzahl von Schaltungskarten und zahlreichen Unterbrechungsvorrichtungen in der Übertragungsstation vorgesehen sein.

Fig. 16 zeigt ein weiteres Beispiel einer Unterbrechungsvorrichtung gemäß der vorliegenden Erfindung. Eine Vielzahl von steuerbaren Schaltern sind mit S₁ bis S_n bezeichnet. Einzelne oder mehrere der Schalter können durch Bediensignale von der Wandlervorrichtung WV für bestimmte Zeitabschnitte geöffnet werden. So werden Verbindungsleitungen zwischen einer Schaltungskarte und einem Schaltungskartenträger unterbrochen.

Fig. 17 zeigt eine weitere Ansicht einer Anordnung von Unterbrechungsvorrichtungen gemäß der vorliegenden Erfindung.

Die Übertragungsstation enthält eine Vielzahl von Schaltungskarten SK₁ bis SK_n, die über eine Vielzahl von jeweils von der Wandlervorrichtung steuerbaren Unterbrechungsvorrichtungen UV₁ bis UV_n mit einem Schaltungskartenträger ST verbunden sind.

Fig. 18 zeigt ein Ausführungsbeispiel einer Wandlervorrichtung WV gemäß der vorliegenden Erfindung. Eine digitale Steuerschaltung DS ist mit einer Wandelschaltung AS verbunden. Die digitale Steuerschaltung DS ist mit logischen Schaltungen und Speichern versehen, in denen spezielle Konfigurationsdateien für Telefone bzw. für Übertragungsstationen UEV gespeichert sind, um die Wandlervorrichtung WV anzupassen. Die Schaltung ist mit für die Erzeugung von Bediensignalen erforderlichen Filtern und einer Logik versehen. Von der programmierbaren Datenverarbeitungsvorrichtung S empfangene Testanweisungen werden unter Verwendung der in Speichervorrichtungen der digitalen Steuerschaltung DS gespeicherten Konfigurationsdateien von der digitalen Steuerschaltung DS in digitale Steuersignale umgewandelt, die zur Wandelschaltung AS übertragen werden. In der Wandelschaltung werden die digitalen Steuersignale in analoge, den jeweiligen Zielvorrichtungen (Telefone verschiedener Hersteller, Übertragungsstationen verschiedenen Typs) angepaßte Bediensignale umgewandelt, die darauf folgend zum Bedienen von Unterbrechungsvorrichtungen UV in Übertragungsstationen UEV bzw. zu ausgewählten Telefonen übertragen werden.

Fig. 19 zeigt ein Ausführungsbeispiel eines Teils einer Kommunikationsvorrichtung KV gemäß der vorliegenden Erfindung. Hier ist eine Unterbrechungsvorrichtung UV so angeordnet, daß sie elektrische Verbindungen zwischen verschiedenen Übertragungsstationen UEV unterbrechen kann. Dazu ist die Unterbrechungsvorrichtung UV zwischen zwei Übertragungsstationen UEV angeordnet. In anderen Ausführungsbeispielen können auch weitere Unterbrechungsvorrichtungen UV zwischen weiteren Übertragungsstationen UEV angeordnet sein.

Fig. 20 zeigt ein Blockschaltbild eines weiteren Ausführungsbeispiels eines Kommunikationssystems gemäß der vorliegenden Erfindung. Die Übertragungsstationen UEV ist eine GSM-Übertragungsstation, die eine Mobilservice- Vermittlungsstation MSC, eine Basis-Vermittlungsstation BSC und eine Basis-Sende- und Empfangsstation BTS zum übertragen von Signalen in der Kommunikationsvorrichtung KV enthält. Zwischen die eine Basis-Sende- und Empfangsstation BTS und das mobilen Telefon T ist eine Bewegungssimulationsschaltung BS geschaltet, die, durch die Wandlervorrichtung WV gesteuert, Bewegungen des mobilen Telefons T simuliert. Weiterhin sind das Telefon T und Unterbrechungsvorrichtungen UV₁ und UV₂ mit der Wandlervorrichtung WV verbunden, um durch Bediensignale von der Wandlervorrichtung WV bedient zu werden, und um Antwortsignale zur Wandlervorrichtung WV zu übertragen. Die Wandlervorrichtung WV wird durch eine programmierbare Datenverarbeitungsvorrichtung S gesteuert, wie anhand Fig. 10 bereits beschrieben.

In den Fig. 9-20 bezeichnen:

KS ein Kommunikationssystem,
KV eine Kommunikationsvorrichtung,
TV eine Testvorrichtung,
UEV_1-n eine Übertragungsstation,
S eine programmierbare Datenverarbeitungsvorrichtung einer zentralen Signalverarbeitungsvorrichtung (Server),
WV eine Wandlervorrichtung,
T_1-n ein Telefon,
C_1-n eine externe programmierbare Datenverarbeitungsvorrichtung,
DFV eine Datenfernübertragungsvorrichtung,
SK eine Schaltungskarte der Übertragungsstation,
ST eine Schaltungskartenträger der Übertragungsstation,
KL eine Kontaktleiste,
DS eine digitale Steuerschaltung und
AS eine Wandelschaltung
BS eine Bewegungssimulationsschaltung
ZV eine zentrale Signalverarbeitungsvorrichtung
MSC eine Mobilservice-Vermittlungsstation
BSC eine Basis-Vermittlungsstation
BTS eine Basis-Sende- und Empfangsstation
UV eine Unterbrechungsvorrichtung (Störelement).

Die Ausführungsformen in den Fig. 9-20 beschreiben somit Beispiele zum Testen einer Telefon-Kommunikationsvorrichtung, wobei von einem Testmustergenerator TCG, d. h. von der Datenverarbeitungsvorrichtung, Testbefehle erzeugt werden, aus denen echte Bediensignale für die Ansteuerung der Unterbrechungshardware mittels eines Wandlers erzeugt werden. Genauso wie allgemein in Fig. 5a ff gezeigt können auch die Bedien-Antwortsignale in den Testmustergenerator zurückgekoppelt werden, zur Synchronisation oder zur Rücksetzung. Somit sind sämtliche unter Bezugnahme auf die Fig. 1-8 beschriebenen Ausführungsformen auf die Ausführungsformen in den Fig. 9-20 anwendbar.

In den Fig. 1-8 wurden der Testmustergenerator und die Schnittstelle getrennt betrachtet, jedoch kann die Schnittstelle auch dem Testmustergenerator zugeordnet werden. Zum Beispiel sind in den Fig. 9-20 der Testmustergenerator und die Schnittstelle zu einer Testvorrichtung TV vereint, wobei wiederum die Datenverarbeitungsvorrichtung der zentralen Signalverarbeitungsvorrichtung die Funktion des Testmustergenerators übernimmt und die anderen Einheiten wie die Wandlervorrichtung und die Unterbrechungsvorrichtung der Schnittstelle entsprechen.

Auf welche Art von Testsystem die erfindungsgemäße Betriebstestvorrichtung und das Verfahren angewendet werden, hängt somit lediglich von dem verwendeten Interface INT bzw. TCE (letzteres, falls die Schnittstelle komplexere Aufgaben übernimmt, wie z. B. die Erzeugung von Last und sie damit als Einrichtung zur Ausführung von Testmustern (TCE) ausgeführt ist), das die gewünschten Zustandsänderungen aufgrund der Testbefehle in tatsächliche Signale in dem Testsystem umsetzt und entsprechend der Zustandsänderungen an den Testmustergenerator zurückkoppelt.

Claims (51)

1. Betriebstestvorrichtung zur Ausführung eines Betriebstests (LT, DT, CT) für ein Testsystem (SUT), welches Betriebszustände entsprechend einem in einer realen Betriebsumgebung eingesetzten realen Betriebssystem (SUT-RA) aufweist, unter Testbedingungen, umfassend:

• a) einen Testmustergenerator (TCG) zum Erzeugen einer Anzahl von Testmustern (TC) mit Testbefehlen, die jeweils eine gewünschte Betriebszustandsänderung in dem Testsystem hervorrufen sollen;
• b) eine Testvorrichtungs-Schnittstelle (INT) zum Empfang der Testbefehle und zur Ausgabe von entsprechenden Bediensignalen an das Testsystem (SUT) zum Herbeiführen der gewünschten Betriebszustandsänderungen;
• c) wobei der Testmustergenerator (TCG) umfaßt:
  • - einen Test-Zustandsmodell-Generator (TSTM-G, PNM-G) zum Erzeugen eines Test-Zustandsmodells des Testsystems (SUT) aus Information über die Hardware-Konfiguration des Testsystems (SUT), Information über die möglichen Betriebszustände des realen Betriebssystems (SUT-RA), aus Verkehrswerten, die beim realen Betrieb des Betriebssystems (SUT-RA) ermittelte Übergangswahrscheinlichkeiten für die Betriebszustände anzeigen und aus den erlaubten Testbefehlen des Testsystems (SUT);
  • - einen Test-Zustandsmodellspeicher (TSTM-S, PNM-S), in dem das Test-Zustandsmodell gespeichert wird;
  • - einen Test-Zustandsmodell-Simulator (TSTM-Sim, PNM-Sim), der das Test-Zustandsmodell statistisch durchläuft und dabei gewünschte Betriebszustandsübergänge generiert; und
  • - einen Test-Zustandsmodell-Befehlsgenerator (TSTM-CG, PNM-CG) zum sukzessiven Erzeugen der Testbefehle der Testmuster (TC) auf Grundlage der vom Test-Zustandsmodell-Simulator generierten Betriebszustandsübergänge.

2. Betriebstestvorrichtung nach Anspruch 1, dadurch gekennzeichnet, daß der Test-Zustandsmodell-Befehlsgenerator (TSTM-CG, PNM-CG) das Test-Zustandsmodell in einer Monte-Carlo- Simulation zufällig, aber nach statistischen Gesetzmäßigkeiten, durchläuft.

3. Betriebstestvorrichtung nach Anspruch 2, dadurch gekennzeichnet, daß die Testvorrichtungs-Schnittstelle (INT) Bedien- Antwortsignale von dem Testsystem (SUT), die jeweils eine in dem Testsystem als Antwort auf das jeweilige Bediensignal ausgeführte Betriebszustandsänderung anzeigen, empfängt und entsprechende Bedien- Antwortsignale an den Testmustergenerator (TCG) ausgibt.

4. Betriebstestvorrichtung nach Anspruch 3, dadurch gekennzeichnet, daß der Testmustergenerator (TCG) einen Vergleicher (CMP) beinhaltet, wobei der Test-Zustandsmodell-Simulator (TSTM-Sim, PNM-Sim) erwartete Bedien-Antwortsignale des Testsystems (SUT) auf Grundlage des Zustandsmodells erzeugt und in einem Speicher (Buffer B) ablegt, die vom Testsystem (SUT) im Ansprechen auf die sukzessive übermittelten Testbefehle erzeugten Bedien- Antwortsignale in einem Speicher (Buffer A) speichert, der Vergleicher (CMP) die vom Testsystem beobachteten Bedien-Antwortsignale mit den während der Simulation erzeugten erwarteten Bedien-Antwortsignalen vergleicht und eine Fehlerausgabe erzeugt, wenn die gespeicherten erwarteten und beobachteten Bedien-Antwortsignale nicht übereinstimmen.

5. Betriebstestvorrichtung nach Anspruch 2, dadurch gekennzeichnet, daß der Test-Zustandsmodell-Generator (TSTM-G) ein Test- Zustandsmodell des Testsystems (SUT) auf der Basis eines Markoffketten-Modells erzeugt.

6. Betriebstestvorrichtung nach Anspruch 2, dadurch gekennzeichnet, daß der Testmustergenerator (TCG) Testbefehle erzeugt, die bei einer Zustandsänderung in dem Testsystem eine entsprechende vom Testsystem (SUT) auszuführende Betriebsfunktion anzeigen.

7. Betriebstestvorrichtung nach Anspruch 2, dadurch gekennzeichnet, daß der Test-Zustandsmodell-Generator (PNM-G) ein Test- Zustandsmodell des Testsystems (SUT) auf der Basis eines Petri-Netz-Modells (PNM) erzeugt.

8. Betriebstest-Vorrichtung nach Anspruch 2, dadurch gekennzeichnet, daß das Testsystem (SUT) ein Telefonnetz und/oder ein Mobilfunknetz ist.

9. Betriebstest-Vorrichtung nach Anspruch 8, dadurch gekennzeichnet, daß der Testmustergenerator (TCG) Testbefehle zur Durchführung eines Lasttests (LT) mit Hilfe eines Lasttest-Befehlsgenerators (LT-TCE) an eine Vermittlungsstelle (MSC) und/oder lokale Vermittlungsstelle (BSC) eines Mobilfunknetzes sendet.

10. Betriebstest-Vorrichtung nach Anspruch 8, dadurch gekennzeichnet, daß der Testmustergenerator (TCG) Testbefehle für einen Konformitätstest (CT) mit Hilfe eines Konformitätstest- Befehlsgenerators (CT-TCE) erzeugt, der eine Reihe von Mobiltelefonen (MS) und einen Luft-Schnittstellen- Simulator (AIS) ansteuert und auf diese Weise den Benutzerverkehr eines Mobilfunknetzes erzeugt.

11. Betriebstest-Vorrichtung nach Anspruch 8, dadurch gekennzeichnet, daß der Testmustergenerator (TCG) Testbefehle für einen Störtest (DT) mit Hilfe eines Störtest-Befehlsgenerators (DT-TCE) erzeugt, welcher Leitungen zwischen den Vermittlungsstellen eines Mobilfunknetzes gezielt unterbrechen oder stören und/oder Komponenten innerhalb eines Vermittlungsstellenrechners außer Funktion setzen oder stören kann.

12. Betriebstest-Vorrichtung nach Anspruch 8, dadurch gekennzeichnet, daß das Mobilfunknetz ein GSM-Mobilfunknetz ist und das Telefonnetz ein herkömmliches Fest-Telefonnetz (PSTN) ist.

13. Betriebstest-Vorrichtung nach Anspruch 7, dadurch gekennzeichnet, daß

• a) der Test-Zustandsmodell-Generator (TSTM-G) ausgeführt als Petri-Netz-Modellgenerator (PNM-G) das erzeugte Petri-Netz-Zustandsmodell des Testsystems (SUT) in einen Petri-Netz-Modell- Speicher (PNM-S) schreibt;
• b) der Test-Zustandsmodell-Simulator (TSTM-Sim, PNM-Sim) ein Petri-Netz-Modell-Simulator (PNM-Sim) ist, der einen Petri-Netz-Markierungsspeicher (MSt) enthält, der zur Speicherung eines aktuellen Betriebszustands des Petri-Netzes verwendet wird;
• c) der Petri-Netz-Modell-Simulator (PNM-Sim) aus dem Petri-Netz-Markierungsspeicher (MSt) den aktuellen Zustand des Petri-Netz-Modells als aktuelle Markierung aller Stellen mit Marken (⚫) ausliest, aus dem Petri-Netz-Modell-Speicher (PNM-S) das Petri-Netz-Zustandsmodell (PNM) des Testsystems (SUT) ausliest, einen der durch die aktuelle Markierung und die Struktur des Petri-Netz-Modells gegebenen möglichen Zustandsübergänge zufallsgesteuert auswählt, die neue, durch diesen Zustandsübergang resultierende Markierung berechnet und sie als aktuelle Markierung im Markierungsspeicher (MSt) ablegt; und
• d) der Test-Zustandsmodell-Befehlsgenerator ein Petri- Netz-Modell-Befehlsgenerator (PNM-CG) ist, der vom Petri-Netz-Modell-Simulator (PNM-Sim) über den durchgeführten Übergang benachrichtigt wird, so daß er die entsprechenden Testbefehle, aus denen das generierte Testmuster sich zusammensetzt, aus dem Petri-Netz-Modell-Speicher (PNM-S) lädt und an das Testsystem (SUT) übermittelt.

14. Betriebstest-Vorrichtung nach Anspruch 13, dadurch gekennzeichnet, daß der Test-Zustandsmodellspeicher (TSTM-S, PNM-S) ein Petri-Netz-Modell-Speicher (PNM-S) ist, der vorgesehen ist zum Speichern von

• - Stellen (○) des Petri-Netzes, wobei die Stellen die möglichen Betriebszustände von einzelnen Betriebsmitteln, Diensten oder Komponenten des Testsystems (SUT) anzeigen;
• - Transitionen (|) des Petri-Netzes, wobei die Transitionen die möglichen Zustandsänderungen im Zustandsmodell beschreiben und die dabei auszuführenden Betriebsfunktion in Form von Aktionen beinhalten; und
• - Kanten (→), die Stellen mit Transitionen bzw. Transitionen mit Stellen verbinden und welche die Bedingungen angeben, die vor bzw. nach dem Schalten einer Transition erfüllt sein müssen, wobei diese Bedingungen durch die für die Transition notwendige bzw. aus ihr folgende Markierung der mit der Transition über Kanten verbundenen Stellen gegeben sind; und
• - eine Anfangsmarkierung der Stellen des Petri-Netz- Zustandsmodells (PNM), bestehend aus Marken (⚫), die den Ausgangszustand des Modells vor dem Start der Simulation bzw. der Testmustererzeugung vorgeben.

15. Betriebstest-Vorrichtung nach Anspruch 3 und 13, dadurch gekennzeichnet, daß der Testmustergenerator (TCG) ferner umfaßt:

• - einen Signal-Handler (PNM-SH) zum Empfangen der Bedien-Anwortsignale, zum Erfassen einer aktuellen Zustandsänderung des Testsystems (SUT) aus den Bedien-Antwortsignalen und zum Ausgeben einer aktuellen Zustandsänderung in Form von Marken an den Petri-Netz-Markierungsspeicher (MSt) zur Synchronisation des aktuellen Zustands des Petri- Netzes auf den aktuellen Betriebszustand des Testsystems (SUT).

16. Betriebstest-Vorrichtung nach Anspruch 15 und 6, dadurch gekennzeichnet, daß wenn die Bedien-Antwortsignale nicht nur das bloße Auftreten einer Zustandsänderung sondern auch eine bei der Zustandsänderung im Testsystem (SUT) auf die Ausgabe des Testbefehls hin ausgeführte Betriebsfunktion anzeigen, der Signal-Handler (PNM-SH) nicht nur das Auftreten einer Zustandsänderung sondern auch einen Wert (farbige Marke) entsprechend der ausgeführten Betriebsfunktion zur Aktualisierung des aktuellen Zustands an den Petri-Netz-Markierungsspeicher (MSt) zur Synchronisation übergibt.

17. Betriebstest-Vorrichtung nach Anspruch 14, dadurch gekennzeichnet, daß der Signal-Handler (PNM-SH) aus der Information über die Hardware-Konfiguration eine Anzahl von Marken (⚫) erzeugt, die jeweils ein in dem Testsystem verfügbares Betriebsmittel bzw. dessen Zustand anzeigen (Autokonfiguration).

18. Betriebstest-Vorrichtung nach Anspruch 6 und 17, dadurch gekennzeichnet, daß der Signal-Handler farbige Marken (⚫) erzeugt, die nicht nur das Vorhandensein eines Betriebsmittels im Testsystem sondern auch seine Identität in Form eines Werts anzeigen.

19. Betriebstest-Vorrichtung nach Anspruch 17, dadurch gekennzeichnet, daß der Petri-Netz-Modell-Speicher (PNM-S) eine vorgegebene Anzahl von Synchronisations-Stellen umfaßt, wobei eine Transition (|), die mit einer derartigen Synchronisations-Stelle und ggf. weiteren Stellen (○) über Eingangskanten verbunden ist, nur dann gefeuert werden kann, wenn der Signal-Handler (PNM-SH) eine Zustandsänderung im Testsystem (SUT) über diese Synchronisations-Stelle im Petri-Netz- Zustandsmodell bekannt gibt, indem er aufgrund eines Antwort-Bediensignals eine Marke in die Synchronisations-Stelle legt.

20. Betriebstest-Vorrichtung nach Anspruch 18 und 19, dadurch gekennzeichnet, daß der Petri-Netz-Modell-Speicher (PNM-S) eine vorgegebene Anzahl von farbigen Synchronisations-Stellen umfaßt, wobei eine Transition (|), die mit einer derartigen farbigen Synchronisations-Stelle und weiteren farbigen Stellen (○) über Eingangskanten mit Kantenanschriften verbunden ist, nur dann gefeuert werden kann, wenn der Signal-Handler (PNM-SH) infolge eines Antwort-Bediensignals eine farbige Marke in die Synchronisations-Stelle legt, deren Wert mit dem der Marken in allen den farbigen Stellen (○) übereinstimmt, die über Eingangskanten gleicher Kantenanschrift mit der Transition (|) verbunden sind.

21. Betriebstest-Vorrichtung nach Anspruch 14 und 19, dadurch gekennzeichnet, daß eine Stelle (○) oder eine Synchronisations-Stelle mit einer Latenz (ΔT) versehen ist, so daß eine darin abgelegte Marke erst nach Ablauf einer durch die Latenz vorgegebenen Verzögerungszeit (ΔT) aktiviert wird, wobei die Latenz einen festen oder durch eine stochastische Verteilung gegebenen zufälligen Wert aufweist, welcher von Marke zu Marke dieser stochastischen Verteilung gemäß variiert und Latenzen entweder eine reale Zeitspanne (Echtzeit) oder eine simulierte Zeitspanne (virtuelle oder Simulationszeit) realisieren.

22. Betriebstest-Vorrichtung nach Anspruch 13, dadurch gekennzeichnet, daß

• a) ein Rücksetz-Zustand-Speicher (RSt) vorhanden ist, der mindestens eine Markierung des Petri-Netzes als Rücksetz-Zustand (Snap Shot) speichern kann; und
• b) der Petri-Netz-Modell-Simulator (PNM-Sim) eine Rücksetz-Einrichtung (RS) umfaßt, um einen Rücksetz-Zustand (Snap Shot) aus dem Rücksetz- Speicher (RSt) auszulesen und um den aktuellen Zustand des Petri-Netzes (also die aktuelle Markierung) in dem Petri-Netz-Markierungsspeicher (MSt) auf den ausgelesenen Rücksetz-Zustand zurückzusetzen.

23. Betriebstest-Vorrichtung nach Anspruch 22, dadurch gekennzeichnet, daß im Rücksetz-Zustand-Speicher (RSt) mindestens eine vorgegebene Rücksetz-Markierung (Snap Shot) gespeichert ist und die Rücksetz-Einrichtung (RS) die aktuelle Verteilung der Marken in dem Petri-Netz- Markierungsspeicher (MSt) auf die Rücksetz-Verteilung von Marken setzt.

24. Betriebstest-Vorrichtung nach Anspruch 22, dadurch gekennzeichnet, daß der Rücksetz-Zustands-Speicher (RSt) als Rücksetz- Zustände aktuelle Markierungen (Snap Shots) des Petri- Netzes speichert, die das Petri-Netz bei der Simulation annimmt.

25. Betriebstest-Vorrichtung nach Anspruch 15, 16 und 22, dadurch gekennzeichnet, daß bei fehlender Übereinstimmung zwischen dem aktuellen Zustand des Testsystems (SUT) und dem aktuellen Zustand des Petri-Netzes die Rücksetz-Einrichtung (RS) den Zustand des Petri-Netzes auf einen Rücksetz-Zustand (Snap Shot) zurücksetzt und gleichzeitig Testbefehle zum Zurücksetzen des Testsystems (SUT) auf einen Zustand entsprechend dem Rücksetzzustand erzeugt werden.

26. Betriebstest-Vorrichtung nach Anspruch 8 und 14, dadurch gekennzeichnet, daß

• a) die Marken (⚫) die Teilnehmer des Telefon-Netzes, Verbindungen zwischen ihnen, von ihnen genutzte weitere Netzwerkdienste und/oder Timer darstellen;
• b) die Stellen (○) die Zustände anzeigen, die die Teilnehmer, Verbindungen zwischen den Teilnehmern, von den Teilnehmern genutzte Telefon- Netzwerkdienste oder Timer in dem Testsystem (SUT) einnehmen können; und
• c) die Transitionen (|) Betriebsfunktionen darstellen, durch die die Teilnehmer in dem Netz eine Zustandsänderung herbeiführen können, oder Zustandsänderungen der Teilnehmer selbst widerspiegeln.

27. Betriebstest-Vorrichtung nach Anspruch 26, dadurch gekennzeichnet, daß die Teilnehmer Telefone eines herkömmlichen Telefonnetzes (PSTN) oder Mobiltelefone eines Mobilfunknetzes sind.

28. Betriebstest-Vorrichtung nach Anspruch 14, dadurch gekennzeichnet, daß die Transitionen mit einer deterministischen Priorität oder einer stochastischen Priorität feuern können, so daß sowohl zufällige als auch deterministische Befehlsfolgen als Testmuster erzeugt werden können.

29. Betriebstest-Vorrichtung nach Anspruch 21, dadurch gekennzeichnet, daß latenzbehaftete Stellen zur Testmustergenerierung und Fehlererkennung für das Testsystem (SUT) in Echtzeit verwendet werden, indem die Simulation der Latenzen in Echtzeit durchgeführt wird und auf diese Weise durch Latenzen gesteuerte verzögerte Zustandsübergänge im Petri-Netz-Modell (PN) zu entsprechenden Verzögerungen in den Zustandsübergängen des Testsystems (SUT) führen, und das rechtzeitige Eintreten von Zustandsänderungen im Testsystem (SUT), welches mittels rückgekoppelter Signale des Testsystems (SUT) in Form von in Synchronisations-Stellen erzeugter Marken kenntlich gemacht wird, mit Hilfe latenzbehafteter Stellen, die im Petri-Netz-Modell (PN) als Timer geschaltet sind, überwacht wird.

30. Betriebstestvorrichtung nach Anspruch 2, dadurch gekennzeichnet, daß das Test-Zustandsmodell permanent oder temporär, d. h. während seiner Simulation, in dem Test- Zustandsmodellspeicher (TSTM-S, PNM-S) gespeichert wird.

31. Verfahren zum Ausführen eines Betriebstests (LT, DT, CT) für ein Testsystem (SUT), welches Betriebszustände entsprechend einem in einer realen Betriebsumgebung eingesetzten realen Betriebssystem (SUT-RA) aufweist, unter Testbedingungen, umfassend die folgenden Schritte:

• a) Erzeugen einer Anzahl von Testmustern (TC) mit Testbefehlen, die jeweils eine vorgegebene Betriebszustandsänderung in dem Testsystem anzeigen, mit einem Testmustergenerator (TCG);
• b) Empfangen der Testbefehle und Ausgeben von entsprechenden Bediensignalen an das Testsystem (SUT) zum Herbeiführen der vorgegebenen Betriebszustands-Änderungen über eine Testvorrichtungs-Schnittstelle (INT); und
• c1) Erzeugen eines Zustandsmodells des Testsystems aus Informationen über die Hardware-Konfiguration des Testsystems (SUT), Informationen über die möglichen Betriebszustände des Testsystems im realen Betrieb (SUT-RA), Informationen über die zur Herbeiführung von Betriebszustandsänderungen im Testsystem (SUT) notwendige Testbefehle und aus Verkehrswerten, die beim realen Betrieb des Testsystems ermittelte Übergangswahrscheinlichkeiten für die Betriebszustände anzeigen, mit einem Test- Zustandsmodell-Generator (TSTM-G, PNM-G);
• c2) sukzessives Erzeugen von den Übergangswahrscheinlichkeiten gemäßen zufallsgesteuerten Zustandsänderungen im Test- Zustandsmodell (TSTM) mit einem Test- Zustandsmodell-Simulator (TSTM-Sim, PNM-Sim); und
• c3) Erzeugen der Testbefehle der Testmuster (TC) auf Grundlage der vom Test-Zustandsmodell-Simulator (TSTM-Sim) erzeugten Zustandsübergänge und den gemäß dem Test-Zustandsmodell (TSTM, PNM) mit diesen Zustandsübergängen verknüpften Testbefehlen durch einen Test- Zustandsmodell-Befehlsgenerator (TSTM-CG, PNM-CG).

32. Verfahren nach Anspruch 31, dadurch gekennzeichnet, daß die Bediensignale über eine Vorrichtung zur Ausführung von Testmustern (TCE) als Testvorrichtungs-Schnittstelle (INT) ausgegeben werden.

33. Betriebstestvorrichtung nach Anspruch 1, dadurch gekennzeichnet, daß

• a) das Testsystem (SUT) durch eine Telefon- Kommunikationsvorrichtung (KV) gebildet ist, welche eine Vielzahl von Telefonen (T₁ bis T_n), insbesondere von Mobiltelefonen, eine Vielzahl von elektrischen Verbindungsleitungen, sowie mindestens eine Übertragungsstation (UEV) zur Übertragung von Signalen in der Telefon-Kommunikationsvorrichtung (KV) enthält; und
• b) die Testvorrichtungs-Schnittstelle (INT) und der Testmustergenerator (TCG) eine Testvorrichtung (TV) zum Testen der Telefon-Kommunikationsvorrichtung (KV) unter betriebsmäßiger Lastbedingung bilden, wobei die Testvorrichtung (TV) umfaßt:
• b1) eine zentrale Signalverarbeitungsvorrichtung (ZV) mit
• b11) mindestens einer programmierbaren Datenverarbeitungsvorrichtung (S), von der die Testbefehle zum Testen der Telefon-Kommunikationsvorrichtung (KV) geliefert werden; und
• b12) einer mit der programmierbaren Datenverarbeitungsvorrichtung (S) verbundenen Wandlervorrichtung (WV), die ausgebildet ist, um von der programmierbaren Datenverarbeitungs­ vorrichtung (S) unter der Steuerung der Testbefehle erzeugte digitale Testsignale in die Bediensignale zu wandeln; und
• b2) mindestens eine mit der Wandlervorrichtung (WV) verbundene Unterbrechungsvorrichtung (UV), die ausgebildet ist, um gemäß der Bediensignale einzelne oder Gruppen der elektrischen Verbindungsleitungen für durch die Bediensignale der Wandlervorrichtung (WV) vorgegebene Zeitabschnitte gezielt zu unterbrechen, wobei
• b3) aufgrund der gezielten Unterbrechungen in der Telefon-Kommunikationsvorrichtung (KV) Signaländerungen hervorgerufen werden, die bei Abweichung von den zugehörigen Soll- Signaländerungen signalisierbar sind.

34. Betriebstestvorrichtung nach Anspruch 33, dadurch gekennzeichnet, daß durch die Unterbrechungsvorrichtung (UV) einzelne oder Gruppen von elektrischen Verbindungsleitungen, die innerhalb der mindestens einen Übertragungsstationen (UEV) und/oder zwischen verschiedenen Übertragungsstationen (UEV) angeordnet sind, unterbrechbar sind.

35. Betriebstestvorrichtung nach Anspruch 33 oder 34, dadurch gekennzeichnet, daß durch die Wandlervorrichtung (WV) von der Übertragungsstation (UEV) erhaltene Antwortsignale in digitale Bedien-Antwortsignale umwandelbar sind.

36. Betriebstestvorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Wandlervorrichtung (WV) ausgebildet ist,

• - um von der programmierbaren Datenverarbeitungsvorrichtung (S) unter der Steuerung von weiteren Testanweisungen die Tastaturen und die Mikrophone der Telefone (T_n) betriebsmäßig zu steuern; und
• - um von Lautsprechern und von Rufvorrichtungen der Telefone (T_n) empfangene Antwortsignale in digitale Bedien-Antwortsignale umzuwandeln und zu der programmierbaren Datenverarbeitungsvorrichtung (S) zu übertragen und dort abzuspeichern.

37. Betriebstestvorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Testvorrichtung (TV) zusätzlich eine Anschlußvorrichtung umfaßt, durch die die Wandlervorrichtung (WV) mit jedem der Telefone (T₁-T_n) verbunden ist, und durch die die Bediensignale von der Wandlervorrichtung (WV) zu ausgewählten Telefonen (T_n) und Antwortsignale von von diesen angewählten oder von den ausgewählten Telefonen (T_n) zur Wandlervorrichtung (WV) übertragen werden.

38. Betriebstestvorrichtung nach Anspruch 37, dadurch gekennzeichnet, daß die Anschlußvorrichtung umfaßt:

• - einen Adapter am Telefon, der mit der Tastatur, dem Mikrophon, dem Lautsprecher und der Rufvorrichtung des Telefons verbunden ist; und
• - eine zwischen dem Adapter am Telefon und der Wandlervorrichtung vorgesehene lösbare Verbindungsleitung.

39. Betriebstestvorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Wandlervorrichtung (WV) eine Speichervorrichtung aufweist, und daß telefonspezifische und/oder Übertragungsstations-spezifische Daten in Konfigurationsdateien der Speichervorrichtung der Wandlervorrichtung (WV) gespeichert sind, um so die Wandlervorrichtung (WV) an unterschiedliche Telefone und/oder Übertragungsstationen (UEV) anzupassen.

40. Betriebstestvorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die programmierbare Datenverarbeitungsvorrichtung (S) der zentralen Signalverarbeitungsvorrichtung (ZV) über eine Datenfernübertragungsvorrichtung (DFV) mit einer Vielzahl von externen programmierbaren Datenverarbeitungsvorrichtungen (C₁-C_n) und/oder Datensichtvorrichtungen verbunden ist.

41. Betriebstestvorrichtung nach Anspruch 40, dadurch gekennzeichnet, daß zur Datenfernübertragung ein lokales Netzwerk (LAN) vorgesehen ist.

42. Betriebstestvorrichtung nach Anspruch 40, dadurch gekennzeichnet, daß zur Datenfernübertragung ein Internet vorgesehen ist.

43. Betriebstestvorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die mindestens eine Unterbrechungsvorrichtung (UV) zwischen Kontaktleisten (KL1) mindestens einer Schaltungskarte (SK) und Kontaktleisten (KL2) eines Schaltungskartenträgers (ST) der Übertragungsstation (UEV) angeordnet ist.

44. Betriebstestvorrichtung nach Anspruch 43, dadurch gekennzeichnet, daß mehrere Schaltungskarten in Serie miteinander verbunden sind und jeweils eine eigene Adresse aufweisen, und daß die Schaltungskarten über eine einzige Steuerleitung ansteuerbar sind.

45. Betriebstestvorrichtung nach Anspruch 33-42, dadurch gekennzeichnet, daß die mindestens eine Unterbrechungsvorrichtung (UV) an der jeweiligen Vorderseite der mit einem Schaltungskartenträger (ST) verbundenen Schaltungskarten (SK) der Übertragungsstation (VEV) angeordnet ist.

46. Betriebstestvorrichtung nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Übertragungsstation (UEV) eine Mobilservice- Vermittlungsstation (MSC), eine Basis- Vermittlungsstation (BSC) und eine Basis-Sende- und Empfangsstation (BTS) aufweisende GSM-Über­ tragungsstation ist.

47. Verfahren nach Anspruch 31, dadurch gekennzeichnet, daß der Betriebstest (LT, DT, CT) ausgeführt wird zum Testen eines Testsystems (SUT) umfassend eine Telefon- Kommunikationsvorrichtung (KV) unter betriebsmäßiger Lastbedingung, welche eine Vielzahl von Telefonen (T₁-T_n), insbesondere von Mobiltelefonen, eine Vielzahl von elektrischen Verbindungsleitungen und mindestens eine Übertragungsstation (UEV) zur Übertragung von Signalen in der Telefon-Kommunikationsvorrichtung (KV) enthält, wobei
die Testvorrichtungs-Schnittstelle (INT) und der Testmustergenerator (TCG) eine Testvorrichtung (TV) zum Testen der Telefon-Kommunikationsvorrichtung (KV) unter der Lastbedingung bilden; und
das Verfahren die folgenden Schritte umfaßt:

• - Erzeugen und Ausführen der Testbefehle mit einer programmierbaren Datenverarbeitungsvorrichtung (S) einer zentralen Signalverarbeitungsvorrichtung (ZV) der Testvorrichtung (TV) zum Testen der Telefon- Kommunikationsvorrichtung (KV);
• - Übertragen von gemäß der Testbefehle erzeugten digitalen Testsignalen an eine Wandlervorrichtung (WV) und Umwandeln der digitalen Testsignale in Bediensignale zum gezielten Unterbrechen mindestens einer elektrischen Verbindungsleitung der Vielzahl von elektrischen Verbindungsleitungen;
• - Übertragen der Bediensignale von der Wandlervorrichtung (WV) zu einer Unterbrechungsvorrichtung (UV) und Bediensteuern der Unterbrechungsvorrichtung (UV) gemäß der Bediensignale zum Unterbrechen mindestens einer elektrischen Verbindungsleitung für durch die Bediensignale vorgegebene Zeitabschnitte,
• - Vergleichen der aufgrund der gezielten Unterbrechungen hervorgerufenen Ist- Signaländerungen mit den zugehörigen Soll- Signaländerungen und
• - Signalisieren von Abweichungen der Ist- Signaländerungen von den Soll-Signaländerungen.

48. Verfahren nach Anspruch 47, gekennzeichnet durch folgende Schritte:

• - Bedienensteuern der Tastaturen und der Mikrophone der Telefone durch die Wandlervorrichtung (WV) unter Steuerung von weiteren Testbefehlen; und
• - Empfangen von Antwortsignalen von Lautsprechern und von Rufvorrichtungen der Telefone und Umwandeln der Antwortsignale in digitale Bedien-Antwortsignale, und Übertragen der digitalen Bedien-Antwortsignale zur programmierbaren Datenverarbeitungsvorrichtung (S).

49. Verfahren nach Anspruch 47 oder 48, gekennzeichnet durch folgende Schritte:
Aufbauen eines Sprachkanals zwischen jedem Paar von Telefonen einer Vielzahl von Telefonen (T₁ bis T_n) bei einem Zweiergespräch oder einer Konferenzschaltung mit drei oder mehreren Teilnehmern;
wiederholtes, vom ersten Telefon ausgehendes Übertragen eines das erste Telefon eindeutig identifizierenden Musters von Tonimpulsen mit einer vorbestimmten Frequenz über den Sprachkanal;
Überwachen des Empfangs des über den Sprachkanal übertragenen Musters von Tonimpulsen des ersten Telefons durch ein zweites am Gespräch beteiligtes Telefon;
wobei die Übertragung des Musters von Tonimpulsen zwischen dem ersten und dem zweiten Telefon Sprachkomprimierung und Sprachdekomprimierung beinhaltet; und
wobei das Muster von Tonimpulsen so gewählt ist, daß eine Identifikation des ersten Telefons möglich ist, wenn das Muster von Tonimpulsen am zweiten Telefon bei Verwendung von Sprachkomprimierung und Sprachdekomprimierung empfangen wird.

50. Verfahren nach einem der Ansprüche 47-49, gekennzeichnet durch folgende Schritte:
Übertragen von Bediensignalen von der Wandlervorrichtung (WV) zu gemäß der Testbefehle ausgewählten Telefonen über eine Anschlußvorrichtung; und
Übertragen von Antwortsignalen von angewählten Telefonen zur Wandlervorrichtung über die Anschlußvorrichtung.

51. Verfahren nach Anspruch 47-50, dadurch gekennzeichnet, daß Daten über eine Datenfernübertragungsvorrichtung (DFV) zwischen der programmierbaren Datenverarbeitungsvorrichtung (S) der Testvorrichtung (TV) und einer Vielzahl von externen programmierbaren Datenverarbeitungsvorrichtungen (C₁-C_n) und/oder Datensichtvorrichtungen übertragen werden.