CH683474A5 - Verfahren zur Verarbeitung von über Datenübertragungssysteme zu übertragenden Datensätzen sowie eine Anwendung. - Google Patents

Description

5

10

15

20

25

30

35

40

45

50

55

CH 683 474 A5

Beschreibung

Die vorliegende Erfindung betrifft ein Verfahren nach dem Oberbegriff des Patentanspruchs 1 sowie eine Anwendung des Verfahrens.

Bei der Übertragung von Daten zwischen zwei digitalen Datenübertragungssystemen, wie dies zum Beispiel in Femmeldesystemen nach ISDN-(lntegrated Services Digital Network)-Normen der Fall ist, werden zwischen einem Endgerät eines Teilnehmers und einem Fernmeldeamt oder zwischen zwei Fernmeldeämtern Datensätze unterschiedlicher Komplexität und/oder Länge übertragen. Insbesondere werden bei der Signalisierung die vom CCITT herausgegebenen Empfehlungen herangezogen. In diesen Empfehlungen sind die grundsätzlichen Funktionen und Protokolle für den für die Signalisierung zwischen Endgerät und Fernmeldeamt vorgesehenen D-Kanal - Ebene 3 des OSI-(Open Systems In-terconnection)-Referenzmodells - sowie das zur Signalisierung zwischen Fernmeldeämtern vorgesehenen ISUP-(ISDN User Part) - Ebene 4 des OSl-Referenzmodells -, insbesondere die zur Erstellung, für den Unterhalt und zum Löschen von Verbindungen in der Benützer-Netzwerk-Schnittstelle bzw. Netzwerk-Netzwerk-Schnittstelle notwendigen Prozeduren, beschrieben. Detaillierte Angaben sind in den Empfehlungen Q.931 bzw. 1.451 und Q.932 bzw. I.452 oder, was die Funktionen und Prozeduren für Protokolle und Beziehungen mit anderen Schichten des OSl-Referenzmodells anbelangt, in der Empfehlung Q.930 bzw. I.430 angegeben.

Alle möglichen bei der Signalisierung übertragenen Parameter werden in Gruppen unterteilt, die beim Signalisierungsvorgang ähnliche Aufgaben wahrnehmen und die im folgenden als Meldungen (engl. Messages) bezeichnet werden. Eine solche Meldung besteht grundsätzlich aus einem in Dateneinheiten unterteilten Datensatz, der dem geforderten Leistungsmerkmal entsprechende Daten enthält. Betrachtet man beispielsweise die Meldung SETUP, so werden darunter sämtliche Leistungsmerkmale, die mit dem Auf- und Abbau von Verbindungen zusammenhängen, verstanden. Dazu gehören beim erwähnten Beispiel 23 verschiedene Datensätze wie REPEAT INDICATOR, SENDING COMPLETE, BEARER CAPABILITY, CALLING PARTY SUBADDRESS, etc. (CCITT Empfehlung Q.931). Nicht alle Datensätze sind jedoch durch ihre Bezeichnung eindeutig bestimmt. Aufgrund der in den Datensätzen abgelegten Werte kann neben der Grösse auch die aus den Dateneinheiten gebildete Struktur der Datensätze ändern. Betrachtet man beispielsweise die verschiedenen Ausführungsmöglichkeiten des Datensatzes BEARER CAPABILITY, so stellt man fest, dass einerseits die Länge dieses Datensatzes zwischen vier und dreizehn Byte variieren kann und dass anderseits verschiedene Kombinationen von Dateneinheiten im Datensatz durch in vorangehenden Dateneinheiten abgelegte Werte festgelegt werden. Es ergeben sich demzufolge Änderungen in der Struktur der Datensätze, die während dem Ablauf der durch diese Meldung beschriebenen Prozedur bewirkt werden und die vom Empfänger bzw. vom Sender bei der Rekonstruktion bzw. Konstruktion und Weiterverarbeitung der Daten entsprechend berücksichtigt werden muss.

Naheliegend, insbesondere für die Datenrekonstruktion, wäre eine mit Hilfe eines Computerprogramms ausgeführte prozedurale Verarbeitung der Datensätze, in der ein Datensatz mit Hilfe der in den CCITT-Empfehlungen angegebenen Regeln derart verarbeitet wird, dass die in den Dateneinheiten der Datensätze enthaltenen Werte vordefinierten Variablen zugewiesen werden. Mit diesen Variablen kann dann eine Weiterverarbeitung auf herkömmliche Art und Weise erfolgen. Voraussetzung bei der proze-duralen Verarbeitung ist die Einhaltung aller der die Strukturen der möglichen Datensätze beschreibenden Regeln, was eine aufwendige Bearbeitung notwendig macht. Zudem sind bei diesem Verfahren die Fehlermöglichkeiten bei der Implementation der CCITT-Empfehlung sehr gross, womit ein grosser Teil der Fehlverhaltenswahrscheinlichkeit des Gesamtsystems den implementierten Regeln zugesprochen werden muss.

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zur Verarbeitung von zwischen Datenübertragungssystemen übermittelten Datensätzen anzugeben, deren Struktur und Länge durch die in den Datensätzen abgelegten Werte hervorgeht.

Diese Aufgabe wird durch die im kennzeichnenden Teil des Patentanspruchs 1 angegebenen Massnahmen gelöst. Vorteilhafte Ausgestaltungen der Erfindung sowie eine Anwendung sind in weiteren Ansprüchen angegeben.

Die Erfindung geht von einer an sich bekannten höheren Programmiersprache wie beispielsweise Pascal, Fortran, C, C+ +, Modula, SDL (Spécification and Description Language), etc. aus, wobei eine Untermenge der normalerweise als Spezifikationssprache eingesetzte Sprache SDL als Programmiersprache verwendet werden kann. In jeder dieser Sprachen können Daten in mit Namen versehenen Variablen abgelegt werden. Diese Variablen vereinfachen die Handhabung der Daten erheblich, da mit Hilfe der Namen direkt auf die Variablen bzw. deren Werte zugegriffen werden kann, ohne dass der physikalische Ort der Variablen im Speicher eines Rechnersystems angegeben werden muss. Voraussetzung ist lediglich, dass vor der ersten Venwendung der Variablen bzw. deren Namen diesen Variablen in einem Programm ein Datentyp in einer sogenannten Variablendeklaration zugewiesen wird. Der Datentyp legt die zulässigen Werte bzw. den Wertebereich der Variablen fest, was einerseits die Lesbarkeit der Programme verbessert, anderseits den Variablen falsch zugewiesene Werte erkennen lassen, falls diese ausserhalb des für diese Variable bzw. diesen Datentyp zugelassenen Bereiches liegen. Insbesondere kann ein Übersetzungsprogramm (Interpreter oder Compiler), das zur Übersetzung von in höheren

2

5

10

15

20

25

30

35

40

45

50

55

60

65

CH 683 474 A5

Programmiersprachen geschriebenen Programmen in maschinenverständliche Anweisungen benötigt wird, etwelche Zuweisungen von nicht mit dem gleichen Datentyp deklarierten Variablen als Fehler erkennen oder anzeigen.

Es empfiehlt sich hauptsächlich aus diesen Gründen, möglichst auch die verwendeten Datentypen, falls es sich nicht um sogenannte durch die verwendete Programmiersprache selbst gegebene Standarddatentypen handelt, in Typendefinitionen zusammenzufassen. Für die Variablendeklarationen können dann diese zusammengesetzten Datentypen immer wieder verwendet werden.

Im folgenden werden die eben eingeführten Begriffe ausschliesslich in der bezeichneten Art und Weise verwendet: Datentypen werden demnach grundsätzlich «definiert», währenddem Variablen durch die Angabe eines Datentyps «deklariert» werden.

Bei all diesen Programmiersprachen können die Datentypen nur statisch angegeben werden, d.h., dass die Datentypen nach der Ubersetzung mit dem Übersetzungsprogramm nicht mehr verändert werden können. Aus diesem Grund wird eine Programmiersprache erfindungsgemäss mit verschiedenen Datentypen erweitert, die weder die Struktur noch die Länge der mit diesen Datentypen deklarierten Variablen zum Zeitpunkt der Übersetzung mit dem Übersetzungsprogramm fixieren. Die Festlegung auf einen der in der Variablendeklaration als Auswahl angegebenen Datentypen wird erst zum Zeitpunkt der Programmausführung vorgenommen.

Mit diesen zusätzlichen Datentypen können die Datensätze, die als Meldungen zwischen Fernmeldesystemen übertragen werden, formal beschrieben werden, wobei die Datentypen entsprechend den in den Dateneinheiten enthaltenen Werten ausgewählt werden. Anstelle der umständlichen und zeitaufwendigen prozeduralen Verarbeitung der einzelnen Datensätze können auf die Werte der mit Hilfe der flexiblen Datentypen deklarierten Variablen direkt zugegriffen werden. Eine anschauliche Darstellung dieses Verfahrens würde etwa darin liegen, dass ein allgemeines mit verschiedenen Auswahlmöglichkeiten versehenes Muster über einen Datensatz gelegt wird, das sich aufgrund der Werte der Dateneinheiten in ein spezielles durch die ausgewählte Struktur beschränktes Muster umwandelt, in dem die Werte über die mit diesem speziellen Muster deklarierten Variablennamen direkt verfügbar werden, ohne dass eine Wertezuweisung wie bei der prozeduralen Verarbeitung notwendig ist. Durch die mit den flexiblen Datentypen deklarierten Variablen entfällt die fehleranfällige Regelimplementation der prozeduralen Verarbeitung. Zusätzlich kann eine Typenkontrolle bei jedem Zugriff auf den Wert einer in dieser Art und Weise deklarierten Variablen ausgeführt werden, was somit auch das Fehlverhalten des Gesamtsystems verkleinert.

Die Erfindung wird nachfolgend anhand von Zeichnungen beispielsweise näher erläutert. Dabei zeigt:

Fig. 1: einen Datensatz, dessen Struktur vor der Verarbeitung der im Datensatz abgelegten Werte nicht bekannt ist

Fig. 2: einen Datensatz, dessen Länge vor der Verarbeitung der im Datensatz abgelegten Werte nicht bekannt ist

Fig. 3: ein Syntaxdiagramm zur Darstellung aller möglichen Formen eines Datentyps CHOICE

Fig. 4: ein Syntaxdiagramm zur Darstellung aller möglichen Formen eines Datentyps SEQUENCE

Fig. 5: ein Syntaxdiagramm zur Darstellung einer in den Datentypen SEQUENCE und CHOICE verwendeten syntaktischen Einheit «field list»

Fig. 6: ein Testsystem zum Testen von Systemeinheiten

Fig. 1 zeigt einen Ausschnitt aus einem aus mehreren Wörtern BY1 bis BY4b bestehenden Datensatz BC. Zu jedem Wort BY1 bis BY4b - häufig auch als Oktett bezeichnet - gehören acht Bit B1 bis B8, die in beliebigen Dateneinheiten zusammengefasst werden können. Der Einfachheit halber sind in diesem Ausführungsbeispiel nur benachbarte und/oder einzelne oder mehrere zum gleichen Wort BY1 bis BY4b gehörende Bit B1 bis B8 in Dateneinheiten DE1 bis DE15 zusammengefasst. So kann eine Dateneinheit DE2 beispielsweise aus allen das ganze Wort BY2 umfassende acht Bit B1 bis B8 bestehen oder, wie die Dateneinheiten DE3, nur aus zwei Bit B6 und B7. Die durch die Dateneinheiten DEO bis DE15 vorgegebene Datenstruktur ist jedoch nicht auf die in Fig. 1 vorgegebene Struktur beschränkt. Vielmehr kann sich aus dem Zusammenhang der Anwendung ergeben, dass beispielsweise einzelne Wörter BY1 bis BY4b oder einzelne Dateneinheiten DEO bis DE15 keine Bedeutung haben und demzufolge weggelassen werden. Aus praktischen Gründen, die sich aus der Organisation von Speichern in Rechnersystemen ergeben, sind vom Weglassen oder Hinzufügen von Datensatzteilen im vorliegenden Beispiel immer ganze Wörter BY1 bis BY4b betroffen. So beinhalten beispielsweise die beiden Wörter BY4a und BY4b die Dateneinheiten DE7 bis DE11, DE14 und DE15, welche bei diesem Datensatz BC im gegebenen Fall nicht vorhanden sein müssen. Die Entscheidung, wann beispielsweise das Wort BY4a mit den Dateneinheiten DE7 bis DE9 und DE14 vorhanden ist, erfolgt aufgrund der in der Dateneinheit DE13 abgelegten Werte des vorangehenden Wortes BY4. Ebenso wird das Vorhandensein des Wortes BY4b durch die in der Dateneinheit DE14 angegebenen Werte des vorangehenden Wortes BY4a angezeigt. Dies bedeutet, dass sich die Struktur des Datensatzes BC aufgrund von Werten in strukturell bereits festgelegten Teilen des Datensatzes BC selbst definiert. Die möglichen Datensatzstrukturen sind im vorliegenden Beispiel in ihrer Anzahl insofern eingeschränkt, weil die die Datensatzstruktur bestimmenden Werte jeweils im vorangehenden Wort BY4a bzw. BY4b abgelegt sind. Damit ist

3

5

10

15

20

25

30

35

40

45

50

55

60

CH 683 474 A5

es beim Vorhandensein des Wortes BY4b Voraussetzung, dass das Wort BY4a ebenfalls vorhanden ist. Will man den allgemeinen Fall, wo die Worte BY4a und BY4b jeweils einzeln vorkommen können, auch berücksichtigen, so bedingt dies, dass die zur Entscheidung über das Vorhandensein benötigten Werte vor den optionalen Wörtern BY4a bzw. BY4b abgelegt sind.

Im folgenden sollen zur Beschreibung des Datensatzes BC benötigte erfindungsgemässe Datentypen in der höheren mit den Datentypen erweiterten Programmiersprache SDL anhand von zwei Beispielen erläutert werden. Gleichzeitig soll erwähnt werden, dass die üblicherweise als Spezifikationssprache verwendete Sprache SDL durch die Möglichkeit der Angabe von Bitdarstellungen bei Typendefinitionen erweitert worden ist. Eine solche Typendefinition durch Bitdarstellung ist im ersten Programmausschnitt ersichtlich.

Als erstes Beispiel soll der in Fig. 1 dargestellte Datensatz BC verwendet werden, der den Datensatz BEARER CAPABILITY der Meldung SETUP gemäss den CCITT Empfehlungen Q.931 darstellt. Zur Verdeutlichung wurden die Dateneinheiten DEO bis DE15 mit den sie repräsentierenden Datentypen bc_ identifier, bc_ length, etc. versehen, die mit den in den Empfehlungen Q.931 verwendeten Bezeichnungen übereinstimmen und die auch in den folgenden SDL- Programmausschnitten zur Datentypendefinition verwendet werden.

Als Grundlage zum Verständnis der angegebenen SDL-Programme sei auf das vom CCITT herausgegebene Volume X des «Blue Book» verwiesen. Zur einfacheren Unterscheidung der zur Programmiersprache SDL gehörenden Schlüsselwörter STRUCT, NEWTYPE, etc. von den Datentypen bc_ identifier, bc_ length, etc. des Datensatzes BC sind die Schlüsselwörter durchwegs gross und die Datentypen durchwegs klein geschrieben.

Alle die Dateneinheiten DEO bis DE15 beschreibenden Datentypen werden zunächst in einer ersten Definitionsstufe durch Auflistung aller möglichen Werte, die die betreffenden Dateneinheit DEO bis DE15 annehmen können, definiert. Als Beispiel sei im folgenden die Dateneinheit DE4 angegeben, für deren weitere Datentypdefinition zunächst ein Datentyp info_ transfer_ capability definiert wird:

NEWTYPE info_transfer_capability /* Beispiel einer Typendefinition DE4 */

UTERALS

speech

[00000B ],

unrestricted

[ 01000B ],

restricted

[01001B],

audio3.1

[ 10000B ],

audio7

[ 10001B ],

video

[ 11000B ];

/* aile andern Werte sind reserviert */

ENDNEWTYPE;

NEWTYPE ext_bit ext [ OB ],

end [ 1B ];

ENDNEWTYPE;

Für alle andern Dateneinheiten DEO bis DE3 und DE5 bis DE15 werden in gleicher Weise entsprechende Datentypen identifier, length, configuration, etc. definiert, die später zur Definition der Datentypen bc_ identifier, bc_ length, bc_ configuration, etc. herangezogen werden. Nach dieser ersten Stufe der Datentypendefinition erfolgt in einer zweiten die eigentliche Definition des Datensatzes BC. Dazu werden die in der Programmiersprache SDL erfindungsgemäss ausgeführten Datentyperweiterungen

4

5

10

15

20

25

30

35

40

45

50

55

60

65

CH 683 474 A5

CHOICE und SEQUENCE für die Beschreibung von Datensätzen mit variabler Länge und/oder veränderbarer Struktur eingesetzt. Der als CHOICE bezeichnete Datentyp wird zur Auswahl aus einer Anzahl von verschiedenen Datentypen aufgrund der Angabe in einer vorangehenden Dateneinheit verwendet. Diese Auswahl wurde bereits in der allgemeinen Beschreibung zu Fig. 1 bezüglich der Wörter BY4a und BY4b erklärt. Im folgenden Programmlisting wird der Datensatz BC mit Hilfe der in der ersten Stufe definierten Datentypen identifier, length, configuration, etc. und mit Hilfe des zusätzlichen Datentyps CHOICE definiert. Zum besseren Verständnis des Programmlistings wurden die entsprechenden Dateneinheiten DEO bis DE15 in einer Kommentarspalte am rechten Seitenrand eingefügt:

NEWTYPE BearerCapability_Q.931 STRUCT [ CODESET 0 00000100B ] /* BY3 */

SPARE (1B) ; bc_coding_standard bcJnfo_transfer_capability /* BY4 */

ext_4

bc_transfer_mode bc_info_transfer_rate

/* BY4a */

CHOICE ext_4 (ext):

ext_4a bc_structure bc_configuration bc_establishment

/* BY4b */ CHOICE ext_4a (ext):

SPARE (1B);

bc_symmetry bc_info_transfer_rate ENDCHOICE;

ENDCHOICE;

coding_standard; info_transfer_capability ext_bit;

transfer_mode;

info transfer rate;

ext_bit; structure; configuration; establishment;

symmetry;

info transfer rate;

/* DEO, DE1.DE2 */

/* DE12 V /* DE3 */

/* DE4 */

/*DE13*/

f* DE5 */

/* DE6 */

/* DE14 */ /* DE7 */ I* DE8 */ /* DE9 */

/* DE15 */ /* DE10 */ /* DE11 */

ENDNEWTYPE; /* BearerCapabillty_Q.931 */

Grundsätzlich sind alle zum Datensatz BC gehörenden Datentypen in einem Standarddatentyp STRUCT zusammengefasst. In diesem sind die einzelnen vorkommenden Datentypen in der Reihenfol-

5

5

10

15

20

25

30

35

40

45

50

55

CH 683 474 A5

ge ihres Auftretens aufgeführt. Dabei sind die beiden Wörter BY1 und BY2 automatisch durch die zwischen den eckigen Klammern nach dem Schlüsselwort CODESET angegebenen Information definiert. Diesen beiden die Dateneinheiten DEO bis DE2 enthaltenden Wörter BY1 und BY2 folgt eine durch das Schlüsselwort SPARE reservierte nicht veränderbare Bitkombination in der Dateneinheit DE12 des Wortes BY3. Für die Wörter BY3 und BY4 ergeben sich ansonsten keine von der normalen Typendefinition abweichenden Eigenschaften. Erst beim Wort BY4a und BY4b erfolgt eine Auswahl der folgenden Datentypen mit Hilfe des Datentyps CHOICE aufgrund der Werte in den als Datentypen ext_4 und ext_4a deklarierten Dateneinheiten DE13 und DE14. Im vorliegenden einfachen Fall beschränkt sich die Auswahl sowohl beim Wort BY4a als auch beim Wort BY4b auf dessen Vorhandensein oder auf dessen Nichtvorhandensein. Vorhanden ist das Wort BY4a bzw. BY4b nur dann, wenn der Wert der mit dem Datentyp ext_4 bzw. ext_4a deklarierten Variablen mit dem Wert ext des Datentyps ext_bit übereinstimmt. Die bereits festgestellte Tatsache, dass das Wort BY4b nur vorhanden sein kann, falls das Wort BY4a vorhanden ist, äussert sich im verschachtelten CHOICE- Datentypen bei der Definition des Wortes BY4b. Gerade diese Verschachtelung von mehreren gleichen oder unterschiedlichen Datentypen verbunden mit den beliebigen Auswahlmöglichkeiten aus weiteren Datentypen mit Hilfe des Datentyps CHOICE öffnen grosse Möglichkeiten und Flexibilität bei der Definition von Datentypen.

Wie bereits erwähnt, kann auf die Werte in den Variablen direkt über die bei der Datentypendeklaration verwendeten Variablennamen zugegriffen werden.

Fig. 2 zeigt einen als zweites Beispiel verwendeten Datensatz CPSA, der ebenfalls zur Meldung SETUP gehört und in den Empfehlungen Q.931 mit CALLING PARTY SUBADDRESS bezeichnet wird. Wie der in Fig. 1 dargestellte Datensatz BC besteht auch der Datensatz CPSA aus mehreren acht Bit BI1 bis Bl8 langen Wörtern BT1 bis BTn, die wiederum in verschiedene Dateneinheiten DE20 bis DEm unterteilt sind. Identisch zu den in Fig. 1 dargestellten Wörtern BY1 und BY2 sind auch die beiden ersten Wörter BT1 und BT2 aufgebaut. Während im ersten Wort BT1 die eigentliche Datensatzidentifikation enthalten ist, beinhaltet das Wort BT2 die Länge des gesamten Datensatzes CPSA. Beide Wörter BT1 und BT2 sind automatisch durch die in eckigen Klammern nach dem Schlüsselwort CODESET angegebene Information definiert. Dem Wort BT2 folgt das wiederum in verschiedene Dateneinheiten DE23 bis DE25 eingeteilte Wort BT3, dem eine sich aus der Gesamtlänge im Wort BT2 ergebende Anzahl von gleichen Wörtern vom Typ BT4 folgt. Während die Worte BT1 bis BT3 bei diesem Datensatz CPSA immer vorhanden sind und mit herkömmlichen Datentypen versehen werden können, ist für die Beschreibung des restlichen Teils dieses Datensatzes CPSA der Datentyp SEQUENCE geeignet. Bei diesem wird eine sich wiederholende Datenstruktur einmal angegeben und mit der maximalen Anzahl an Wiederholungen versehen. So ist im vorliegenden Beispiel die maximale Anzahl des sich wiederholenden Datentyps cgps_subaddress_info auf zwanzig beschränkt, d.h., dass der Datensatz CPSA bis zu 23 Worten lang sein kann. Eine mögliche Definition des Datensatzes CPSA ist im folgenden Programmausschnitt wiederum in der Programmiersprache SDL angegeben:

NEWTYPE CallingPartySubaddress_Q.931 STRUCT [CODESET 0 01101101B]

/* BT3 */

SPARE (1B);

cgps_type type_of_subaddress;

cgps_oe odd_even_id;

SPARE (000B);

/* BT4 */

SEQUENCE (cgpsjength < = 20)

subaddressjnfo NATURAL [ 8 BITS ];

ENDSEQUENCE;

ENDNEWTYPE; /* CallingPartySubaddress_Q.931 */

Wie beim Datentyp CHOICE können auch innerhalb des Datentyps SEQUENCE wiederum beliebige Datentypen definiert werden.

/* DE26 */ /* DE23 */ /* DE24 */ /* DE25 */

/* maximale Länge */

6

5

10

15

20

25

30

35

40

45

50

55

60

65

CH 683 474 A5

Die Fig. 3,4 und 5 zeigen die zur Darstellung von Syntaxregeln einer Programmiersprache häufig verwendeten Syntaxdiagramme für die beiden in der Programmiersprache SDL neu eingeführten Datentypen CHOICE und SEQUENCE sowie für die in diesen Datentypen verwendete syntaktische Einheit «field list». Mit Hilfe von Syntaxdiagrammen können die Syntaxregeln einer Programmiersprache abschliessend und in kompakter Art und Weise beschrieben werden. Insbesondere können sämtliche zusammengesetzten Typenkonstruktionen einfach dargestellt werden. So wurde auch die Programmiersprache SDL in dem vom CCITT verfassten «Blue Book» Volume X mit Hilfe von Syntaxdiagrammen beschrieben. Auf dieser Beschreibung basieren auch die in den Fig. 3 bis 5 angegebenen Syntaxdiagramme für die Datentypen CHOICE und SEQUENCE. Dabei fassen die durch einen rechteckigen Kasten dargestellten syntaktischen Einheiten weitere oft wiederkehrende syntaktischen Einheiten in einer zusammen. Nur diejenigen können nicht weiter unterteilt werden, die durch einen mit runden Elementen ausgestatteten Kasten oder durch einen Kreis dargestellt sind.

Weiterführende Angaben zur Interpretation von mit Syntaxdiagrammen dargestellte Syntaxregeln von Programmiersprachen sind ebenfalls im «Blue Book» Volume X vom CCITT enthalten.

Fig. 3 zeigt das Syntaxdiagramm des Datentyps CHOICE. Als zusätzliche im Beispiel von Fig. 1 nicht verwendete Möglichkeit dieses Datentyps CHOICE kann ein mit dem Schlüsselwort ELSE eingeleitete Variante zur Zusammenfassung aller der in der syntaktischen Einheit «field identifier» enthaltenen Fälle verwendet werden, die nicht zu einem der in der syntaktischen Einheit «answer» aufgeführten Fälle gehören, indem diese durch die dem Schlüsselwort ELSE folgende syntaktische Einheit «field list» definiert wird. Speziell zu erwähnen bleibt auch, dass innerhalb des Datentyps CHOICE beliebig andere Datentypen, inklusive ein weiterer Datentyp CHOICE, verwendet werden kann. Diese Möglichkeit wird deutlich, wenn man die syntaktische Einheit «field list» durch das in Fig. 5b dargestellte Syntaxdiagramm ersetzt.

Fig. 4 zeigt das Syntaxdiagramm des Datentyps SEQUENCE. Auch in diesem ist die Möglichkeit verschachtelte Datentypendefinitionen zu verwenden ersichtlich, indem wiederum anstelle der syntaktischen Einheit «field list» das Syntaxdiagramm von Fig. 5b eingesetzt wird.

Fig. 6 zeigt ein Testsystem zum Testen von Funktionsabläufen einer in Fernmeldeanlagen verwendeten Systemeinheit SE. Das Testsystem besteht im wesentlichen aus einer Arbeitsstation AS und einer Erweiterungseinheit EAS. Die Arbeitsstation AS verfügt über eine Eingabeeinheit ED, eine Speichereinheit DB und ein Übersetzungsprogramm IP, das die über die Eingabeeinheit ED eingegebenen und in der Speichereinheit DB gespeicherten Programme übersetzt. Die Erweiterungseinheit EAS, welche beispielsweise aus zwei Schnittstelleneinheiten SS1 und SS2 besteht, übernimmt die übersetzten Programme von der Arbeitsstation AS und steuert eine zwischen der Systemeinheit SE und der Schnittstelleneinheit SS1 bzw. SS2 vorhandene Verbindung gemäss den Ausführungsbefehlen des Programms. Werden verschiedene Systemeinheiten SE getestet, so müssen, dank der modularen Aufbauweise des Testsystems, lediglich die Erweiterungseinheit EAS an die neue Systemeinheit SE angepasst werden. Die Erstellung von Prüfprogrammen kann unter Anwendung der in den Fig. 3 bis 5 beschriebenen Datentypendefinitionen erheblich vereinfacht erfolgen. Gerade bei den in der Fernmeldetechnik komplexen Datensatzstrukturen (Fig. 1 und 2) von Meldungen, die in ebenso komplexen Systemeinheiten ablaufen, ist eine einfache und klare Repräsentation von Daten von enormer Bedeutung. Denn bei einfacher Darstellung lassen sich Fehler eher vermeiden oder zumindest schneller finden und korrigieren.

Als Arbeitsstation AS kann ein herkömmliches Rechnersystem, wie beispielsweise ein PC (Personal Computer), eingesetzt werden.

Die in der Erweiterungseinheit EAS vorhandenen Schnittstelleneinheiten SS1 und SS2 simulieren im Testsystem beispielsweise Datenübertragungssysteme einer Fernmeldeanlage. Die direkt beteiligten Systeme, d.h. die Schnittstelleneinheiten SS1, SS2 und die Systemeinheit SE, können dabei sowohl Sender- als auch Empfängerfunktionen ausüben. Es ist jedoch nicht zwingend, dass alle beteiligten Systeme die Datensätze nach dem erfindungsgemässen Verfahren verarbeiten. Vielmehr ist auch möglich, dass ein Systemteil, beispielsweise nur der Send- oder nur der Empfangsteil, die Datensätze mit einem anderen Verfahren als dem erfindungsgemässen verarbeitet.

Grundsätzlich ist also die Datenverarbeitung des Empfängers vom Sender und umgekehrt unabhängig, was eine Kombination von nach einem beliebigen Verfahren arbeitenden Übertragungssystem mit dem nach dem erfindungsgemässen Verfahren arbeitenden Übertragungssystem ermöglicht.

Das erfindungsgemässe Verfahren ist nicht auf den Einsatz in dem beschriebenen Testsystem begrenzt. Vielmehr kann das beschriebene Verfahren in andern Datenübertragungssystemen mit gleicher Aufgabenstellung angewendet werden.

Claims (6)

Patentansprüche

1. Verfahren zur Verarbeitung von zwischen mindestens zwei Datenübertragungssystemen zu übertragenden Datensätzen, die in beliebige Dateneinheiten unterteilt sind, dadurch gekennzeichnet, dass in mindestens einem der beteiligten Datenübertragungssysteme die durch die Unterteilung der Datensätze

(BC, CPSA) in die Dateneinheiten (DEO, ..., DE15; DE20 DEm) vorgegebene Datenstruktur mit Hilfe von Datentypen in einem Programm deklariert wird und dass die definitive Datenstruktur der Datensätze (BC, CPSA) spätestens zum Zeitpunkt der Übertragung zwischen den Datenübertragungssystemen festgelegt wird.

7

5

10

15

20

25

30

35

40

45

50

55

60

CH 683 474 A5

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Datentyp die Wiederholung eines beliebigen anderen Datentyps aufgrund eines vor oder nach der Übersetzung des Programms angegebenen Wertes beliebig oft ermöglicht.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein Datentyp eine Auswahl aus mehreren für den gleichen Bereich des Datensatzes (BC, CPSA) bestimmten Datentypen trifft und dass die Auswahl der Datentypen aufgrund eines vor oder nach der Übersetzung des Programms angegebenen Wertes erfolgt.

4. Verfahren nach einem der Ansprüche 1, 2 oder 3, dadurch gekennzeichnet, dass die Datentypen beliebig ineinander verschachtelt werden.

5. Anwendung des Verfahrens nach Anspruch 1 in einem Testsystem zum Testen von Systemeinheiten (SE), insbesondere Einheiten einer Fernmeldeanlage.

6. Anwendung nach Anspruch 5, dadurch gekennzeichnet, dass das Testsystem aus einer Arbeitsstation (AS) und einer Erweiterungseinheit (ED) besteht, dass die Arbeitsstation (AS) eine Eingabeeinheit (ED), einen Speicher (DB) und ein Übersetzungsprogramm (IP) enthält und dass die Erweiterungseinheit (EAS) mindestens eine mit der Systemeinheit (SE) verbundene Schnittstelleneinheit (SS1, SS2) aufweist.

8