Kommunikationssoftware

Lutz Winkler
Hochschule fr Technik und Wirtschaft Mittweida (FH)

Kommunikationssysteme werden durch Software dominiert. Fr Software kann man einen Lebenszyklus angeben.
Der vorliegende Beitrag beschftigt sich mit dem Lebenszyklus von Protokollsoftware und im speziellen mit formalen
Sprachen fr ausgewhlte Phasen. Folgende Sprachen werden besprochen:
Message Sequence Chart (MSC), (ITU-T-Recommendation Z.120),
Specification and Description Language (SDL), (ITU-T-Recommendation Z.100),
Tree and Tabular Combined Notation (TTCN), (ISO International Standard 9646).
Es wird jeweils ein kurzer berblick zu den Sprachen gegeben. Die Nutzung von MSC und SDL wird exemplarisch
anhand eines einfachen HDLC-basierten Schicht-2-Protokolls, SimpleDataLink genannt, gezeigt. TTCN wird an
einem fast realen Beispiel demonstriert. Der Beitrag ist wie folgt gegliedert:
bersicht,
MSC - Message Sequence Chart,
SDL - Specification and Description Language,
TTCN - und der Test von Protokollen,
Ausblick.

bersicht
Kommunikationssysteme bestehen aus konfektionierter Steuer- sowie Funktionalhardware und komplexer Software.
Am Beispiel der Hard-Softwarestruktur eines ISDN-Telefons kann man zeigen, da Kommunikationssoftware aus
drei Teilen besteht:
Funktionalsoftware (z.B. Call Control Agent, Benutzerinterface),
Protokollsoftware (z.B. Protokolle der Schichten 1 bis 3, Stackmanagement)
und Supportsoftware (Echtzeitbetriebssystem zur Prozekoordinierung und Prozekommunikation).

Anzeige,
Anzeige,
Tastatur,
Tastatur,
Wecker
Wecker

PCM-Codec,
PCM-Codec,
Filter,
Filter,
Freisprech
Freisprech

Takte

D-KanalD-KanalController
Controller

B-Kanal

Takte
Upstream
Downstream

SS-oder
oder UUController
Controller

Rechner
Rechner mit
mit RAM,
RAM, ROM,
ROM, Timer
Timer

FUNKTIONALSOFTWARE

Anzeige,
Anzeige,
Tastatur,
Tastatur,
Wecker
Wecker

Call
Call Control
Control Agent
Agent

B-Kanal

Network

PROTOKOLLSOFTWARE
SUPPORTSOFTWARE

Data Link

D-Kanal-Controller
D-Kanal-Controller

Physical

SS-oder
oder U-Controller
U-Controller

Echtzeitbetriebssystem
Echtzeitbetriebssystem
Rechnerhardware
Rechnerhardware

Funktionalhardware
Funktionalhardware

Abb.1: Hard-Software-Struktur eines ISDN-Telefons

Kommunikationssoftware

PCM-Codec,
PCM-Codec,
Filter,
Filter,
Freisprech
Freisprech

Takte

von/zur
Vermittlung

Software fr Kommunikationssysteme ist besondere Software:

Sie mu sehr zuverlssig sein.
Sie mu wartbar sein, denn Kommuniktionssysteme haben teilweise eine Lebensdauer von 10 Jahren und mehr
(z.B. Vermittlungen).
Sie ist oft sehr komplex, mu daher von mehreren (vielen) Bearbeitern implementiert werden. Beispielsweise
werden fr das Vermittlungssystem EWSD 2000 Mannjahre fr die Softwareentwicklung angegeben.
Protokollstandards und Anforderungen an die Funktionalsoftware sind nicht stabil. Damit mu diese Software
ber viele Jahre relativ hufig angepat werden.
Protokollsoftware ist teure Software, sie sollte deshalb wiederverwendbar und portierbar sein.
Die Kosten fr die Softwareentwicklung machen in Produkten der Kommunikationstechnik teilweise bis zu 80%
der Gesamtentwicklungskosten aus. Aufgrund dieser Tatsache versucht man, die Technologie zu verbessern. In
[HALLMANN] wurden u.a. folgende Merkmale des gegenwrtigen Standes der Softwaretechnologie angegeben:
Strukturierte Methoden der Softwareentwicklung haben bisher nur etwa 10% des Marktes erreicht.
Das Management von Softwareprojekten verluft zufllig.
Nur 2-4% aller Entwickler benutzen CASE-Tools (Computer Aided Software Energineering).
80% aller Softwareprojekte bleiben nicht in geplantem Zeit- bzw. Aufwandrahmen.
60% aller festgestellter Fehler eines Softwareprodukts gehen auf die Spezifikation zurck. Die Beseitigung
dieser Spezifikationsfehler macht bis zu 75% der Gesamtentwicklungskosten aus.
70% der entwickelten Software werden nicht ausgeliefert bzw. nie richtig genutzt.
40% des Aufwandes zur Erstellung von Software werden zum Testen bentigt.
Von den Gesamtkosten einer Software ber den Lebenszyklus entfallen 35% auf die Spezifikation, Beschreibung, Implementation und Test, aber 65% auf die Abnahme der Software sowie die Wartung und Pflege.
Die Produktivitt wird in "Line of Code" gemessen. Derzeit (1990) betrgt sie 5 LOC/Std. Bezogen auf 1955
ergibt sich lediglich eine Produktivittssteigerung von 3% bis 4%.
Whrend viele Basistechnologien der Kommunikationstechnik (Mikroelektronik, Signalverarbeitung, bertragungstechnik usw.) ein teilweise atemberaubenes Tempo vorlegen, steht die Softwareproduktivitt fast auf der
Stelle. Ein weiteres Hemmnis ist die Tatsache, da die Werkzeuge fr die einzelnen Lebensphasen nicht
hinreichend gut aufeinander abgestimmt sind, so da an den Schnittstellen oft Anpassungsprobleme entstehen.

Funktionsdefinition
Funktionsdefinition

durch Standards festgelegt

Protokollspezifikation
Protokollspezifikation

C, Pascal, CHILL

ImplementierungsImplementierungsspezifikation
spezifikation
Implementation
Implementation
TTCN

SDL

MSC

Dienstespezifikation
Dienstespezifikation

MSC

verbale Sprachen

Der Lebenszyklus von Protokollsoftware besteht aus mehreren Phasen. In jeder Phase werden spezielle Sprachen
und Werkzeuge benutzt. Der Zusammenhang wird in Abbildung 2 dargestellt.

Test
Test
Betrieb
Betrieb u.
u. Wartung
Wartung

Sprachen fr den
Lebenszyklus
Abb. 2: Der Lebenszyklus von Protokollsoftware und verwendete Sprachen
Kommunikationssoftware

Am Ende jeder Phase des Lebenszyklus sollte ein abgeschlossenes Dokument als Input fr die nchste Phase bereitgestellt werden. Eine kurze Definition der einzelnen Phasen soll nachfolgend gegeben werden:
Function definition, ist die verbale Beschreibung der beabsichtigten Funktionalitt. Diese Beschreibung wird
bisher nur durch einige Standardisierungsgremien bereitgestellt. Beispielsweise heien bei ECMA diese
Dokumente Technical Report (Beispiel: TR/52). Diese TRs sind Lesebcher aus denen die Absichten, Ziele
und das betrachtete Umfeld von Standards hervorgehen. Sie versetzen den spteren Leser von Standards in
die Lage, so einigermaen das nachvollziehen zu knnen, was in den Kpfen der Standardisierer vor sich ging.
Service specification, ist die verbale/formale Beschreibung der Dienste einer Schicht (Umfang, Qualitt), die
einem Nutzer bereitgestellt werden sollen (z.B. X.211, X.212 bis X.217, Q.920, Q.930).
Protocol specification, ist eine implementierungsunabhngige Beschreibung der Funktionalitt eines Schichtenprotokolls. Derzeit werden von ISO und CCITT verbale und formale Spezifikationen vorgenommen.
Beachte, die verbale Spezifikation dominiert, die formale Spezifikation dient der besseren Lesbarkeit
und als Basis fr einen computergesttzten Entwurf. Die formalen Sprachen sind aber mit Absicht
nicht mchtig genug, um Feinheiten zu beschreiben. Dann wrde eine Spezifikation eine Fast-Implementation werden.
Formale Spezifikationen sind mglich mit endlichen Zustandsmaschinen (Finite state machine - FSM),
Petri-Netzen, erweiterten endlichen Zustandsmaschinen (Extended FSM - EFSM) in Gestalt von beispielsweise SDL und ESTELLE.
Implementation specification, ist eine implementierungsabhngige Beschreibung der Funktionalitt eines
Protokolls. Bercksichtigung finden hier die Laufzeitumgebung (Art der Prozekommunikation, Prozekoordination, Prozesynchronisation) und die Zielsprache. Als Werkzeug fr die Implementierungsspezifikation wird
eine Spezifikationssprache oder ein Subset der Zielsprache verwendet.
Implementation, wird zunehmend durch spezielle Werkzeuge untersttzt. Ansonsten werden die Standardwerkzeuge fr die Programmierung benutzt.
Der Test ist Teil der Validierung und dient der abschlieenden Bewertung der erreichten Funktionalitt.
Viele Begriffe im Kontext Validierung werden verschieden verwendet. Unter Validierung soll hier die Gesamtheit
aller Manahmen zur Sicherung der beabsichtigten Funktionalitt eines Protokolls oder einer Software verstanden
werden. Die Validierung umfat alle Phasen des Lebenszyklus. Fr bestimmte Phasen bzw. Methoden haben sich
folgende Validierungsschritte herausgebildet:
Verifizierung, ist die berprfung der Korrektheit einer Spezifikation vor der Umsetzung in ein Protokoll. Wird z.B. ein Protokoll fehlerhaft spezifiziert und dann implementiert, schleppt man unntige
und schwer lokalisierbare Fehler mit.
Rapid Prototyping, ist eine Methode, bei der auf unterschiedlichem Niveau und mit unterschiedlichen
Mitteln, ein Gerst oder Teile einer Software zu dem Zwecke beschrieben werden (z.B. mit SDL oder
C), um dieses Gerst oder Teile zu Simulieren oder Ablaufen zu lassen. Durch Steuern der Inputs und
Beobachten des Outputverhaltens kann man die Funktionalitt berprfen. Im allgemeinen wird der
letzte Prototyp das Produkt.
Test, wird unterschieden in Konformittstest, Zusammenarbeitstest, Test der Leistungsgfhigkeit und
der Robustheit gegenber Fehlverhalten der Umgebung. Dazu werden geeignete Testfolgen entworfen,
Testlufe durchgefhrt und das Verhalten analysiert. Diese Testfolgen werden ebenfalls standardisiert
und bilden die Testbasis. Im ISO-Standard IS9646 werden sowohl Testmethoden, als auch die Mittel
standardisiert, unter anderem auch eine Sprache zur Verhaltensbeschreibung TTCN (Tree and Tabular
Combined Notation). Diese wird im Abschnitt 4 etwas nher betrachtet.
Insgesamt wird deutlich, da der Entwurf, die Implementation und der Test ein iterativer Vorgang ist. Dazu sind
entsprechende Methoden und Sprachen erforderlich, die nachfolgend betrachtet werden sollen.
Kommunikationssoftware

MSC - Message Sequence Chart

Eine kurze Sprachbeschreibung
Message Sequence Chart (MSC) wird in der ITU-T-Recommendation Z.120 spezifiziert. Diese Sprache soll in Verbindung mit SDL und TTCN den Entwurf, die Simulation, den Test und die Dokumentation von
Kommunikationssoftware untersttzen:
Mit Hilfe von MSC kann das beabsichtigte (Teil-) Verhalten eines Systems in Form des
Nachrichtenaustausches zwischen Systemkomponenten und ihrer Umgebung dargestellt werden.
Mit Hilfe von MSC kann bei der Simulation oder dem Test das tatschliche Verhalten dargestellt
werden.
Fr MSC gibt es zwei Darstellungsformen: eine textuelle (MSC.PR, phrase representation) und eine grafische
(MSC.GR, graphical representation). Die Syntax wird, da diese Sprache noch relativ wenig bekannt ist, verkrzt
dargestellt. Die folgende Sprachbeschreibung basiert auf [Z.12094]. Die Sprache wurde weiterentwickelt
[Z.12096], die Basiskonzepte sind aber identisch.

Beschreibung

textuelle Darstellung

Kommentare

<comment>::=
comment <character string>

Hier steht ein

Kommentar

<text definition>::=
text <character string>;

Das ist ein

Textfeld

Text

grafische Darstellung

Paging
MSC Dokument

Message Sequence Chart

<msc document>::=
<msc document head> <msc document body>
<mscdocument head>::=
mscdocument<msc document name>;
<msc document body>::=
{<message sequence chart>| <msc diagramm}*
<message sequence chart>::=
msc <msc head><msc body> endmsc;
<msc head>::=<msc name>[<msc interface>]
<msc interface>::=inst<instance list>;
<instance list>::=<instance name>[:<instance
kind>][,<instance list>]
<instance kind>::=[<kind denominator>]<identifier>
<kind denominator>::=system|block|process|service

Ein Rahmen grenzt ein MSC ab. Auerhalb des Rahmens ist Environment env.
msc name

<msc body>::={<instance definition>|<text definition>}*

Abb. 3a: MSC-Sprachbeschreibung

Generelle Regeln beschreiben die Darstellung von Kommentaren und dem sogenannten Paging. Paging wird
unterschieden in vertikales Paging und horizontales Paging.
Vertikales Paging wird verwendet, wenn die Beschreibung mehrere Seiten erfordert. Auf allen Seiten befindet
sich der <msc head> und der <instance head area>. Auf der ersten Seite werden die Instanzen voll und auf allen
folgenden Seiten gestrichelt dargestellt. Das Instanz-Endesymbol befindet sich auf der letzten Seite. Messages
und Timer, die ber mehrere Seiten gehen, mssen auf jeder benannt werden.
Horizontales Paging wird durch Sub-MSCs realisiert. Eine Sub-MSC enthlt Detaillierungen bei der
Beschreibung einer Instanz.
Ein MSC-Dokument ist eine Sammlung von MSCs und Sub-MSCs. Ein MSC beschreibt ein System oder Teile
davon. Diese werden durch Instanzen modelliert.
Kommunikationssoftware

Beschreibung

textuelle Darstellung

Instance

<instance definition>::=
instance <instance head> <instance body> endinstance;

Message

Condition

grafische Darstellung
Instanzkopfsymbol

<instance head>::= <instance name>[[:]<instance

kind>][decomposed];

Ende der
Beschreibung

<instance body>::=<instance event list>[<stop>]

Instanzkopfsymbol

<instance event list>::=

{<message input>|<message output>|<create>|<timer
statement>|<coregion>|<action>|<condition>}*

Ende der
Beschreibung

Instanzachse

<message input>::= in<msg identification> from <address>;

<message output>::= out<msg identification> to <address>;

Messagesymbol

<msg identification>::=<message name>

<adress>::=<instance name>|env
<condition>::=
condition <condition name>[shared{<shared instance
list>|all}];
<shared instance list>|::=<instance name>[,<shared instance
list>]

Instanzachse

Conditionsymbol

A
Condition X gilt
fr A und C, aber
nicht fr B

Abb. 3b: MSC-Sprachbeschreibung

Eine Instanz kann, wie bei SDL, ein Proze, ein Block oder ein Service sein. Zustzlich zum Instanznamen, der
ber dem Instanzkopfsymbol steht, kann innerhalb des Instanzkopfsymbols ein Prozess-Name, ein Service-Name
oder das Schlsselwort decomposed stehen.
BEISPIEL: User: process DataLink. In diesem Falle heit die Instanz User, und es wird der Proze DataLink
beschrieben.
Steht im Instanzkopfsymbol das Schlsselwort decomposed, dann heit das, da die Instanzbeschreibung irgendwo
detallierter erfolgt, nmlich in einer Sub-MSC. Diese Sub-MSC hat den gleichen Namen wie die Instanz. Der
Instanzname wird damit zur Referenz zwischen einer MSC und Sub-MSC.
Das Instanzkopf- und Instanzende-Symbol einer Instanz bezieht sich nur auf den Beginn und das Ende der
Beschreibung, nicht auf die Existenz einer Instanz!
Messages werden in kommende (in) und gehende (out) unterschieden. Messages werden zwischen Instanzen
untereinander oder zwischen einer Instanz und der Umgebung (env) ausgetauscht. Messages knnen instaziiert
werden und parametrisiert sein.
BEISPIEL: in dlDataRq(daten) from env. Eine Instanz bekommt eine Nachricht dlDataRq mit dem Parameter
daten von der Instanz Environment.
Eine Condition beschreibt entweder einen globalen Sytemzustand oder nur den Zustand einer oder mehrerer (aber
nicht aller) Instanzen.
BEISPIEL: condition state4 shared all. Alle Instanzen einer MSC sind im Zustand state4.
BEISPIEL: condition state7 shared DLUser, DLNetw. Die Instanzen DLUser und DLNetw befinden sich im
Zustand state7.
Kommunikationssoftware

Beschreibung

textuelle Darstellung

Timer

<timer statement>::=<set>|<reset>|<timeout>

grafische Darstellung
Set Timer Symbol

<set>::= set<timer name>[,<timer instance name>][<duration

name];
Reset Timer Symbols

<reset>::= reset<timer name>[,<timer instance name>];

Action

<timeoutt>::= timeout<timer name>[,<timer instance

name>];
<action>::= action<action text> ;

Timeout Symbols

Action Symbol

Process creation

Process stop
Coregion

<create>::=
create <instance name>[(<parameter list>)];
<shared instance list>|::=<instance name>[,<shared instance
list>]
<stop>::= stop;
<coregion>::= concurrent {<coevent>}* endconcurrent;
<coevent>:=<message input>|<message output>

<action text>

Create Symbol

Stop Symbol

Coregion Start
Coevent area
Coregion Stop

Abb. 3b: MSC-Sprachbeschreibung

Die Timerkonzepte fr MSC wurden von SDL bernommen. Das Timeout-Ereignis kann nur durch die Instanz
konsumiert werden, die den Timer kreierte.
Die Action beschreibt eine Aktivitt innerhalb einer Instanz. Sie ist mit dem SDL-Konzept Task vergleichbar.
Ebenfalls in Analogie zu SDL, kann man dynamisch Prozesse erzeugen (Process creation) und Prozesse sich selbst
beenden (Process stop) lassen. Die Prozeerzeugung kann mit der bergabe von Parametern verbunden sein.
Zwischen dem Start und Ende einer Instanz herrscht in der Regel eine strenge zeitliche Ordnung. Durch das
Konzept der Coregion kann diese zeitliche Ordnung aufgehoben werden. Die in einer solchen Region dargestellten
Ereignisse mssen stattfinden, die zeitliche Reihenfolge ist aber unbestimmt.

Anwendung von MSC bei einer Dienste- und Protokollspezifikation

Nachfolgend soll MSC angewendet werden. Dazu wird erst ein einfacher Schicht-2-Dienst definiert. Bei der
Definition dieser einfachen Sicherungsschicht (SimpleDataLink) sollen die Grundprinzipien einer ISDN-Schicht-2
benutzt werden. Dies gilt fr die Bezeichnung der Dienste, der abstrakten Primitive und der benutzten ProtokollDaten-Einheiten, nicht aber fr die Funktionalitt.
SimpleDataLink soll den Dienstnutzern folgende Funktionen bereit- bzw. nicht bereitstellen:
einen besttigten Auf- und Abbau einer Verbindung,
quittierte Datenbertragung,
unquittierte Datenbertragung,
Adressierungs- und Fehlererkennungsmechanismen werden nicht untersttzt.

Kommunikationssoftware

Die verwendeten Abkrzungen in den abstrakten Dienstprimitiven sind:

Rq Request (Anforderung eines Dienstes),
Indication (Anzeige eines Dienstes),
In
Cf Confirmation (Besttigung der erfolgreichen Ausfhrung eines Dienstes).

Service User

Service User

Abstract Service
Primitives (ASP)

Services

Services

SimpleDataLink (Service Provider)

Service (Dienst)

ASPs

Parameter

Anforderung zum Aufbau einer Verbindung

Anzeige, Verbindung, initiiert vom Partner, aufgebaut
Besttigung, Verbindung wurde aufgebaut
Anforderung zur quittierten Datenbertragung
Anzeige von quittiert empfangenen Daten
Anforderung zur unquittierten Datenbertragung
Anzeige von unquittiert empfangenen Daten
Anforderung zum Abbau einer Verbindung
Anzeige, Verbindung, initiiert vom Partner, abgebaut
Besttigung, Verbindung wurde abgebaut

dlEstablishRq
dlEstablishIn
dlEstablishCf
dlDataRq
dlDataIn
dlUnitDataRq
dlUnitDataIn
dlReleaseRq
dlReleaseIn
dlReleaseCf

keine
keine
keine
Daten
Daten
Daten
Daten
keine
keine
keine

Abb. 4: Szenario und Definition der Dienste sowie der abstrakten Dienstprimitive

Nach der verbalen Beschreibung erfolgt eine formale Beschreibung mittels MSC. In Abbildung 5 werden die
geforderten Dienste sowohl in MSC.GR als auch MSC.MR beschrieben.

msc ServicesSimpleDataLink; inst

SimpleDataLink;

msc ServicesSimpleDataLink
SimpleDataLink
dlEstablishRq

dlEstablishIn

dlEstablishCf

dlDataRq(data)
dlUnitDataRq(data)

dlReleaseRq

dlDataIn(data)
dlUnitDataIn(data)

dlReleaseIn

dlReleaseCf

instance SimpleDataLink;
in dlEstablishRq from env;
out dlEstablishIn to env;
out dlEstablishCf to env;
in dlDataRq(data) from env;
out dlDataIn(data) to env;
in dlUnitDataRq(data) from env;
out dlUnitDataIn(data) to env;
in dlReleaseRq from env;
out dlReleaseIn to env;
out dlReleaseCf to env;
endmsc;

Abb. 5: Formale Dienstebeschreibung der SimpleDataLink in MSC.GR und MSC.MR

Kommunikationssoftware

Nach der Dienstespezifikation erfolgt die Protokollspezifikation. In Abbildung 5 werden das Szenario der
Diensterbringung, die festgelegten Protocol data units (PDUs) und ihre Bedeutung dargestellt.
Service User

Service User
(User side)

(Netw side)
Abstract Service
Primitives (ASP)

Services

DLUser

Abstract Service
Primitives (ASP)

Services

DLNetw

Peer-to-peer-protocol

Zwischen den paaren Instanzen findet ein virtueller Austausch von Protocol data
units (PDUs) nach feststehenden Regeln statt. Die Definition von PDUs und
der Regeln des Austausches selbiger, bezeichnet man als Protokoll
PDU
SABME
DISC
UA
I
UI
RR

Bedeutung

Parameter

Gehe in den Zustand 7, damit quittierte Datenbertragung mglich ist

keine

Gehe in den Zustand 4 (nur noch unquittierte Datenbertragung mglich)

keine

Positive Quittung als Antwort auf SABME oder DISC

keine

Informationsrahmen zur quittierte Datenbertragung

Daten

Unnumerierter Informationsrahmen zur unquittierten Datenbertragung

Daten

Quittierung eines empfangenen Informationsrahmens

keine

Abb. 5: Szenario der OSI-Diensterbringung und Definition der PDUs

Jetzt knnen ausgewhlte Sequenzen des Protokollablaufes mit den Mitteln von MSC beschrieben werden.
msc ProtocolSimpleDataLinkEstablish
DlUser

DlNetw

State4
dlEstablishRq

SABME

dlEstablishIn

T200
State5
UA
dlEstablishCf
State7

reset T200;
msc ProtocolSimpleDataLinkEstablish;
condition state7 shared all;
inst DLUser, DLNetw;
endinstance;
instance DLUser;
instance DLNetw;
condition state4 shared all;
condition state4 shared all;
in dlEstablishRq from env;
in SABME from DLUser;
out SABME to DLNetw;
out dlEstablishIn to env;
start T200;
out UA to DLUser;
condition state5;
endinstance;
in UA from DLNetw;
endmsc;
out dlEstablishCf to env;
Abb. 6: MSC-Beschreibung eines erfolgreichen Verbindungsaufbaus

Kommunikationssoftware

SDL - Specification and Description Language

Die SDL-Sprachbeschreibung wurde erstmals 1972 in der ITU-T-Recommendation Z.100 als Standard
herausgegeben. Seit dieser Zeit wurde SDL, fr die es ebenfalls eine grafische (SDL.GR, graphical representation)
und textuelle (SDL.PR, phrase representation) Darstellungsform gibt, weiterentwickelt. Die Sprache ist in der
Zwischenzeit sehr mchtig geworden und relativ bekannt. Deshalb wird hier nur ein kurzer berblick gegeben.
SDL basiert auf einer erweiterten endlichen Zustandsmaschine (Extended finite state machine), d.h. neben den
Zustandsdaten bei einer nichterweiterten Maschine existieren zustzlich Operationsdaten. Diese Operationsdaten
knnen whrend eines Zustandsberganges manipuliert werden, und der Wert von Operationsdaten kann den
Folgezustand bestimmen. Alle Maschinen sind unabhngig voneinander, knnen parallel laufen und
kommunizieren ber Signale. Jeder aktive Proze kann Signale senden und empfangen. Fr den Empfang von
Signalen hat jeder Proze einen FIFO-Speicher (First in first out), damit erfolgt die Kommunikation asynchron.
Ein SDL-System besteht aus vier Teilen:
Seiner Architektur oder auch statische Beschreibung genannt. Die Architektur besteht aus den Elementen
System, Block, Process und Procedur (Abbildung 7).
Der Beschreibung der Kommunikation, realisiert durch Signals, die ber Channels bzw. Signal routes
transportiert werden.
Der Beschreibung des dynamischen Verhaltens durch Prozesse und Prozeduren.
Der Definition von Operationsdaten in abstrakter Form und der zulssigen Operationen auf ihnen.
Environment
System A 1

Block Blck_A
P1

C1
Blck_A

Prc_A1

C2
P2

C3

Prc_A2
Blck_B

Procedure Pro_2

Process Prc_A2
Pro_2

State1

a3
Pro_2

Abb. 7: Statische Struktur oder Architektur eines SDL-Systems

Kommunikationssoftware

xy34

In den folgenden Abbildungen wird die Spezifikation des Protokolls fr die SimpleDataLink gezeigt. Verwendet
wurde das Tool SDT3.0 der Firma Telelogic.

Abb. 8: Organizer-Oberflche und Diagrammstruktur des Systems SimpleDataLink

Abb. 9 a: Systemstruktur SimpleDataLink

Kommunikationssoftware

10

Abb.9 b,c,d: SDL.GR-Darstellung der Blcke DLUser und DLNetw und des Prozesses DLNetw
Kommunikationssoftware

11

Abb.9 e: SDL.GR-Darstellung des Prozesses DLUser

System SimpleDataLink;

channel C1FrEnv from env to DLUser

with (ASPsToUser);
endchannel C1FrEnv;
channel C3ToNetw from DLUser to DLNetw
with (PDUsToNetw);
endchannel C3ToNetw;
channel C2ToEnv from DLNetw to env
with (ASPsFrNetw);
endchannel C2ToEnv;
channel C3ToUser from DLNetw to DLUser
with (PDUsToUser);
endchannel C3ToUser;
channel C1ToEnv from DLUser to env
with (ASPsFrUser);
endchannel C1ToEnv;
channel C2FrEnv from env to DLNetw
with (ASPsToNetw);
endchannel C2FrEnv;

/*Das ist die Protokollspezifikation einer einfachen Sicherungsschicht

"SimpleDataLink".
SimpleDataLink nutzt keinen Serviceprovider, sondern die paaren
Instanzen senden die PDU's direkt */
SYNTYPE daten=integer ENDSYNTYPE;
SIGNAL dlEstablishRq, dlEstablishIn, dlEstablishCf,
dlDataRq(daten), dlDataIn(daten);
SIGNAL dlUnitDataRq(daten), dlUnitDataIn(daten), dlReleaseRq,
dlReleaseIn, dlReleaseCf;
SIGNAL SABME, DISC, UA, I(daten), UI(daten), RR;
SIGNALLIST ASPsToUser=dlEstablishRq, dlDataRq,
dlUnitDataRq, dlReleaseRq;
SIGNALLIST ASPsFrUser=dlEstablishIn, dlEstablishCf, dlDataIn,
dlUnitDataIn, dlReleaseIn, dlReleaseCf;
SIGNALLIST ASPsToNetw=dlUnitDataRq;
SIGNALLIST ASPsFrNetw=dlEstablishIn, dlDataIn, dlUnitDataIn,
dlReleaseIn;
SIGNALLIST PDUsToNetw= SABME, DISC, I, UI;
SIGNALLIST PDUsToUser= UA,UI,RR;

Kommunikationssoftware

block DLUser referenced;

block DLNetw referenced;
endsystem ;

12

Block DLNetw;

with (ASPsFrUser);
signalroute P32 from env to DLUser
with (PDUsToUser);
process DLUser referenced;
endblock ;

CONNECT C3ToNetw AND P34;

CONNECT C3ToUser AND P33;
CONNECT C2ToEnv AND P22;
CONNECT C2FrEnv AND P21;

Process DLUser;
DCL daten daten;
TIMER T200;
start ;
nextstate state4 ;
state state5 ;
input T200 ;
output dlReleaseIn ;
nextstate state4 ;
input UA ;
reset (T200) ;
output dlEstablishCf ;
nextstate state7 ;
state state4 ;
input dlEstablishRq ;
output SABME ;
Set(now+1,T200) ;
nextstate state5 ;
input dlUnitDataRq(daten) ;
output UI(daten)
via C3ToNetw ;
nextstate - ;
state state7 ;
input dlUnitDataRq(daten) ;
output UI(daten)
via C3ToNetw ;
nextstate - ;
input dlDataRq(daten) ;
output I(daten)
via C3ToNetw ;
set(now+1,T200) ;
nextstate state7 ;
input dlReleaseRq ;
output DISC ;
set(now+1,T200) ;
nextstate state6 ;
state state7 ;
input RR ;
reset (T200) ;
nextstate - ;
input T200 ;
grs0:output dlReleaseCf ;
nextstate state4 ;
state state6 ;
input UA ;
reset (T200) ;
join grs0;
input T200 ;
join grs0;
endprocess ;

signalroute P21 from env to DLNetw

with (ASPsToNetw);
signalroute P33 from DLNetw to env
with (PDUsToUser);
signalroute P22 from DLNetw to env
with (ASPsFrNetw);
signalroute P34 from env to DLNetw
with (PDUsToNetw);
process DLNetw referenced;
endblock ;
Process DLNetw;
DCL daten daten;
start ;
nextstate state4 ;
state state4 ;
input dlUnitDataRq(daten) ;
output UI(daten)
via C3ToUser ;
nextstate - ;
input SABME ;
output UA ;
output dlEstablishIn ;
nextstate state7 ;
state state7 ;
input UI(daten) ;
output dlUnitDataIn(daten) ;
nextstate - ;
input I(daten) ;
output dlDataIn(daten) ;
output RR ;
nextstate - ;
input DISC ;
output dlReleaseIn ;
output UA ;
nextstate state4 ;
endprocess ;
Block DLUser;
CONNECT C1FrEnv AND P11;
CONNECT C1ToEnv AND P12;
CONNECT C3ToNetw AND P31;
CONNECT C3ToUser AND P32;
signalroute P11 from env to DLUser
with (ASPsToUser);
signalroute P31 from DLUser to env
with (PDUsToNetw);
signalroute P12 from DLUser to env

Abb.9 f: SDL.GR-Darstellung des Systems SimpleDataLink

Kommunikationssoftware

13

TTCN - und der Test von Protokollen

Standardisierung und grundlegende Begriffe
Seit Anfang der achtziger Jahre beschftigt man sich bei ISO sehr intensiv mit den Problemen des Testes von
Protokollsoftware. Es entstand ein umfangreicher Standard mit der Bezeichnung ISO9646: Information
technology - Open Systems Interconnection - Conformance testing methodology and framework. Dieser Standard
besteht aus sieben Teilen:
ISO9646-1: General concepts; Definition und Beschreibung verwendeter Begriffe und Konzepte.
ISO9646-2: Abstract test suite specification; dieser Teil spezifiziert Anforderungen an abstrakte
Testsuites (Abstract test suite, ATS) und definiert Grundstrukturen fr Testsuites.
ISO9646-3: The Tree and Tabular Combined Notation; hier wird die Syntax der Testnotation
beschrieben.
ISO9646-4: Test realisation; spezifiziert Anforderungen und gibt Anleitung fr die Realisierung der
Testmittel (Means of testing, MOT).
ISO9646-5: Requirements on test laboratories and clients for the Conformance Assessment Process;
beschreibt die Schnittstelle zwischen Testlabor und dem Kunden.
ISO9646-6: Protocol profile test specification; spezifiziert Anforderungen und gibt Anleitung fr die
Erzeugung von Profilen fr den Test eines Protokolls.
ISO9646-7: Implementation Conformance Statement; dieser Teil spezifiziert Anforderungen an
Konformittserklrungen fr eine Protokollimplementation.
Dieser Standard ist, wie andere auch, eine anstrengende Lektre. Anstrengungen vermeidet man, indem man die
Ursache als fr nicht relevant deklariert. Viele mit Kommunikationstechnik befate Ingenieure werden sich dieser
Ausrede nicht bedienen knnen, denn zahllose Firmen (kleine, mittlere, groe) entwickeln und produzieren
heutzutage Kommunikationstechnik. Damit steht am Ende immer die Zertifizierung und damit ISO9646. Der Test
ist damit keine Spezialdisziplin, sondern wird enger Bestandteil jeder Entwicklung.
Bevor auf TTCN eingegangen werden kann, mssen einige Grundbegriffe eingefhrt werden. In ISO9646-1 wird
die in Abbildung 10 grundlegende Testarchitektur definiert. Die Implementation Under Test (IUT) wird dabei als
Black-Box betrachtet. Der Test erfolgt durch Manipulation von Inputs und Beobachtung der resultierenden
Outputs. Inputs knnen dabei sowohl vom oberen als auch vom unteren Tester gesteuert werden. Outputs sind
ebenfalls ober- und unterhalb der IUT beobachtbar. Die virtuellen Punkte, wo Inputs gesteuert und Outputs
beobachtbar sind, nennt man Point of Control and Observation, PCO.

Upper Tester, UT

T
E
S
T
E
R

PCO

Abstract Service
Primitives, A S P ' s

Implementation
Under Test, I U T

PCO

Abstract Service
Primitives, A S P ' s,
Protocol Data
Unit's, P D U ' s

Lower Tester, LT

Abb. 10: Grundlegende Testarchitektur

Aus der Abbildung geht hervor, da an PCOs oberhalb der

IUT nur ASPs aber an PCOs unterhalb der IUT sowohl
ASPs und PDUs sichtbar sind. Wre die IUT beispielsweise
SimpleDataLink, dann wrden oberhalb die Primitives
dlEstablishRq, dlDataRq, dlUnitDataRq, und dlReleaseRq
steuerbar sein. Alle anderen Primitives (siehe Abbildung 4)
wren beobachtbar. Unterhalb der IUT wrde Physical seine
Dienste anbieten. Wenn SimpleDataLink unter Benutzung
von Physical seinem Partner eine PDU schickt, realisiert er
die durch den Dienst Datenbertragung, der durch das ASP
phDataRq angefordert wird. ASPs mit denen
Datenbertragungsdienste angefordert bzw. angezeigt werden,
sind parametrisiert. Ein Parameter sind die PDUs des
Dienstnutzers. Damit lassen sich an PCOs die unterhalb der
Schicht liegen, die gestestet werden soll, auch die PDUs der
IUT beobachten und steuern.

Am Beispiel des Protokollstacks eines ISDN-Telefons, soll die Lage mglicher PCOs gezeigt werden (Abb. 11):
Kommunikationssoftware

14

S0-Interface

TESTER

System Under Test, SUT

Call Control Agent

Call Control
ASP's

mgliche PCO's
fr Upper Tester

PCO

Network

ASP's

ASP's,
PDU's

ASP's

PCO

ASP's

Network

PCO

mgliche PCO's
fr Lower Tester

Data Link

PCO

Data Link

PCO

IUT
PCO

Physical

ASP's,
PDU's

Physical

Service Provider for Data Link

ASP's,
PDU's

PCO

PCO

ASP's,
PDU's

Abb. 11: Mgliche Lage von PCOs

Die genauesten Aussagen ber eine IUT erhlt man dann, wenn der obere Tester Dienstnutzer (Service user) der
IUT ist und der untere Tester der Dienstbereitsteller (Service provider) fr die IUT. Dieser Fall ist eigentlich nur in
der Implementierungsphase und durch zustzlichen Aufwand gegeben. In realen Protokollstacks sind die vertikalen
Interfaces, also dort wo PCOs sitzen sollten, nicht zugnglich. Die Protokolle der einzelnen Schichten werden
deshalb oft eingebettet getestet.
In ISO9646-2 werden
grundlegende Testmethoden
definiert. Es werden Szenarien
fr den Test von Endsystemen
und den Test von Relaissystemen
beschrieben. Fr Endsysteme
werden vier Testmethoden festgelegt, die sich durch die Lage
des oberen und unteren Testers
unterscheiden und dadurch, wie
die Koordinierung der beiden
Tester erfolgt.
Diese Methoden, die in
Abbildung 12 dargestellt
werden, nennt man:
lokal (local, L),
verteilt (distributed, D),
koordiniert (coordinated, C).
entfernt (remote, R).
Ein Tester kann ein Gert, ein
Proze innerhalb einer IUT oder
eine Kombination aus beidem
sein.

UT

(N t)-A S P ' s
Test Coordination
Procedures, TCP

LT

(Nb) bis (Nt)PDU's

(Nb-1)-ASP's

TCP

LT

PCO

IUT
PCO

SUT

Test Management
Protocol

IUT
PCO

SUT

UT
(Nb) bis (Nt)PDU's

PCO

(Nb-1)-ASP's

Service Provider

(Nb-1)-ASP's

Service Provider

TM-PDU's

LT

Test Coordination
Procedures

15

SUT

TCP

UT

LT
(Nb) bis (Nt)PDU's

IUT
PCO

(Nb-1)-ASP's

Service Provider

Abbildung 12: Die vier grundlegenden abstrakten Testmethoden

Kommunikationssoftware

PCO

(Nb) bis (Nt)PDU's

S
U
T

Service Provider

(N t)-A S P ' s

UT

IUT

Jede der grundlegenden Methoden wird wieder danach unterschieden, ob das zu testende Protokoll einzeln
vorliegt (single layer) oder ob das zu testende Protokoll in einen Stack eingebettet ist (single-layer embedded). In
der Testsuite wird die Methode angegeben, z.B. RS fr Remote Single layer oder RSE fr Remote Single layer
Embedded.
Wenn man die Methoden bezglich Steuerbarkeit und Beobachtbarkeit der IUT bewertet, ist die entfernte
Testmethode die schlechteste und dennoch die derzeit dominierende. Dies hat, wie bereits erwhnt, praktische
Grnde. Wenn beispielsweise ein ISDN-Telefon entwickelt wurde, ist der D-Kanal-Stack bezglich der
Schichten 1 bis 3 zu testen. Der Test erfolgt schichtenweise, beginnend bei Physical. Ist dieses
Schichtenprotokoll normenkonform, wird die Schicht 2 und danach die Schicht 3 getestet. In Abbildung 13 wird
ein Testszenario, die Bildschirmanzeige eines Testfalles sowie auf die Realisierung der Koordinierungsfunktion
zwischen unteren und oberen Tester eingegangen.

Basic Access Modul

Test
Coordination
Procedures

Tester mit LT

TCP

SUT
UT

LT

Network

(DataLink)-PDU's
PCO

Physical-ASP's mit DataLink-PDU's

D a ta L in k

IUT
Physical

Service Provider
TIME

SAPI

TEI C/R Frame

P/F

NR NS

45'247439
45'269639
45'295707
45'311413
45'333451
45'545666
45'700001
48'952160
48'963453
48'996933
49'025666
49'041785
49'075354
49'100889
49'126400
49'138465
49'168333
49'178656
49'187678
49'202009
50'034776
50'054106
50'088002
50'114666

Trace
Trace
Trace
Trace
Trace
Trace
Net
Trace
Net
Usr
Net
Usr
Net
Usr
Net
Usr
Trace
Trace
Trace
Trace
Usr
Ntw
Usr
Net

TEST GROUP
:A.2.2.1.0 Initialisation
96/7/4 15:27:45

50'134212

Trace

TEST CASE

TEST CASE

:A.2.2.1.1 Test link establish request

63 127 1 UI
P=0
TNOAC expired
0
127 1 UI
P=0
63 127 0 UI
P=0
63 127 1 UI
P=0
0
69 0 SABME P=1
0
69 0 UA
F=1
0
69 0 INFO P=0
0
69 1 DISC P=1
0
69 1 UA
F=1
=====================
*
body
*
=====================
Please initiate a call
0
69 0 SABME P=1
0
69 0 UA
F=1
0
69 0 INFO P=0
0
69 0 RR
F=0

identity remove
Orig Q.931 1 SETUP
identity request
identity assigned
0

:A.2.2.1.1

Orig Q.931 1 SETUP

VERDICT: PASS

Abb. 13: Reales Testszenario (remote) mit kommentiertem Monitortext eines Testers

Kommunikationssoftware

16

Preamble:
die IUT wird in
einen definierten
Anfangszustand
gebracht

Dest Q.931 1 REL_COM

!!!
0
1

allgemeine
Angaben zum
Testfall

Das ist der

Testkrper. In
diesem Fall wird
er durch das
Abnehmen des
Hrers gestartet.
Auswertung und
Ergebnis

An diesem Beispiel wird sichtbar, da der obere Tester (UT) eigentlich nicht existiert, sondern durch die
Benutzeroberflche des Telefons gegeben ist. Die Testkoordinierungsprozeduren werden durch Anweisungen auf
dem Monitor des Testers angestoen, die dann durch einen Operator realisiert werden.
Jeder Testfall besteht aus drei wesentlichen Teilen:
Testvorbereitung (Preamble); die IUT wird durch geeignete Manahmen in einen definierten Anfangszustand
gebracht.
Testdurchfhrung; der Test wird entweder durch den LT oder UT angestoen und luft zeitberwacht ab.
Testauswertung; hier werden die beobachteten Ereignisse mit den erwarteten Ereignissen, die in der Testsuite
beschrieben wurden, verglichen. Die Auswertung kennt drei Prdikate (verdicts):
pass, der Test wurde vollstndig bestanden,
fail, der Test wurde nicht bestanden, weil mindestens ein Ereignis nicht der Erwartung entsprach,
inconclusive, der Test lieferte kein schlssiges Ergebnis.

Tree and Tabular Combined Notation

TTCN, standardisiert in ISO9646-3, besteht aus einer grafischen Darstellung (TTCN.GR, graphical) und einer
maschinenverarbeitbaren Form (TTCN.MP, machine processable). Mittels TTCN wird in der Regel der Test
eines Schichtenprotokolls beschrieben. Die Gesamtheit dieser Beschreibung heit Testsuite. Eine Testsuite
besteht aus einer Menge von Tabellen, die der Entwickler, untersttzt von speziellen Tools, ausfllen mu. In
der Syntax wurden zwei Tabellentypen spezifiziert, die sogenannte Einzeltabelle zur Definition eines Objektes
und die Mehrfachtabelle zur Definition gleichartig strukturierter Typen (Abbildung 14).
Titel der Tabelle
Kopf der Tabelle

EINZELTABELLE
Objektname:
Zweck:
Kommentar: dieser Teil kann entfallen
Spalte1
...
Komponente 1
Komponente 2

Spalte n

...

Kommentare

Komponente m
Erweiterte Kommentare: dieser Teil kann entfallen

Objektname
Objektbezeichner 1
Objektbezeichner 2

...

Tabellenkrper

Tabellenfu

MEHRFACHTABELLE
Spalte n

...

Kommentare

Objektbezeichner n
Erweiterte Kommentare: dieser Teil kann entfallen

Titel der Tabelle

Tabellenkrper

Tabellenfu

Abb. 14: Die zwei Tabellengrundtypen fr die Beschreibung einer Testsuite in TTCN.GR

Eine Testsuite hat dem Inhalt nach vier Teile, die auch in der genannten Reihenfolge anzuordnen sind:
berblicksteil (Overview part): hier werden der Name der Testsuite, der Protokollstandard gegen den zu
testen ist, das Profil des Protokolls und die Testmethode angegeben. Danach erfolgt ein berblick ber alle
Testflle und Testschritte. Dieser Teil wird automatisch generiert. Der Entwurf einer Suite beginnt beim
Deklarationsteil.
Deklarationsteil (Declaration part): dieser enthlt Typdefinitionen von Datenobjekten
Konstantendefinitionen. Beispielsweise werden hier alle Timer definiert und mit Werten bzw.
Wertebereichen versehen. Es werden alle ASPs (dlEstRq, phActIn usw.) deklariert und alle zu
verwendenden PDUs (SETUP, ALERT, I-Frame, RR-Frame usw.) und ihre Struktur einschlielich
Informationselemente (bearer capability, called party number, sending complete usw.) formal beschrieben.

Kommunikationssoftware

17

Constraintsteil (Constraint part): hier werden, basierend auf den Konstanten- und Typdefinitionen des
vorhergehenden Teils, die zu verwendenden Objekte beschrieben. Zum Beispiel werden verschiedene
SETUP-PDUs oder ALERT-PDUs usw. definiert. Diese werden dann als Input fr die IUT verwendet oder
als Vergleichsobjekt fr einen Output. Die Beschreibung der Objekte erfolgt anhand vordefinierter Typen
(Integer, Boolean, Bitstring, Hexstring, Octettstring usw.) und/oder der ASN.1 (Abstract Syntax Notation No.
1, ITU-T-Recommendation X.218, ISO 8824).
Verhaltensteil (Dynamic part): hier erfolgt die Beschreibung der Inputfolgen und der dazu zulssigen
Outputs. Dieser Teil ist auch ein wertvoller Zusatz fr die Protokollbeschreibung. Erst hier erfhrt man oft,
welche Merkmale das Protokoll in speziellen Situationen aufweisen mu und WARUM bestimmte
Eigenschaften im Protokoll vorgesehen wurden. In der Protokollbeschreibung steht ja letztlich nur, WAS das
Protokoll zu machen hat, nicht WARUM!

Im Verhaltensteil werden alle Testflle (Test cases), abgeleitet aus dem Verhaltensbaum (Behavior tree),
beschrieben. Fr jeden Testfall wird eine Einzeltabelle angelegt (vgl. Abbildung 15). In dieser Tabelle wird das
Verhalten, die Bewertung des Verhaltens und die Kommentierung zeilenweise notiert.
Die horizontale bzw. vertikale Position eines Ereignisses wird als zeitliche Ordnung bzw. zur Angabe von
Alternativen benutzt. In Abbildung 15 sind zustzlich zwei Achsen eingezeichnet, die diese Ordnung
reprsentieren sollen.
Aus der TTCN-Sprachbeschreibung (ISO9646-3) werden nachfolgend die wesentlichsten TTCN-Anweisungen,
Timeroperationen und Ausdrcke dargestellt (Abbildung 15).
Ereignis
Senden eines ASPs oder einer PDU von einem bestimmten PCO aus

Syntax
[PCO_Id] ! (ASP_Id | PDU_Id)

Implizites Senden eines ASPs oder einer PDU vom UT als Teil der IUT

<IUT ! (ASP_Id | PDU_Id) >

Empfangen (erwarten) eines ASPs bzw. einer PDU an einem bestimmten

[PCO_Id] ? (ASP_Id | PDU_Id)

PCO
unerwartetes Ereignis, ist alles was nicht ausdrcklich im Testfall

[PCO_Id] ? OTHERWISE

beschrieben ist
Gehe zu Zeile mit dem Label (Marke) xyz

GOTO Label

Benutze folgenden Testfall oder Testschritt (wie ein Unterprogrammaufruf)

+ TreeReference

Starten eines Timers

START Timer_Id [TimerValue]

Stoppen eines Timers

CANCEL Timer_Id

Abfragen eines Timers

READ Timer_Id

Empfang der Mitteilung: Timer abgelaufen

? TIMEOUT Timer_Id

Einer Variablen wird ein Wert zugewiesen

(Var_Id ::= Wert)

Vergleichsoperation mit Entscheidung ber weiteren Verlauf

[Var_Id Operator Var_Id|Const_Id]

Abb. 15: Die wichtigsten TTCN-Anweisungen, Timereroperationen und Ausdrcke

Die Anwendung von TTCN soll an dem Beispiel erfolgen , welches in Abbildung 13 dargestellt wurde. Dabei ist
zu beachten, da die nachfolgende Verhaltensbeschreibung nicht ganz vollstndig ist, da dies den Rahmen des
Beitrages sprengen wrde.

Kommunikationssoftware

18

Test Case Dynamic Behavior

Reference:
Identifier: A.2.2.1.1
Objective: Test link establish request
Behavior Description

V Constraint
Reference

Comments

Zeit
1
L!UI_M (RC::=0) START TNOAC
2
L?UI_Mr (RC::=RC+1) CANCEL TNOAC
3
[RC<=RCMax] START TNOAC
4
GOTO L2
5
[RC>RCMax]
6
+POSTAMBLE
7
?TIMEOUT TNOAC
8
L!UI START TWAIT
9
L?UI_Mr
10
(CURRENT_TEI::=RANDOM(64,126)
11
L!UI_M START TAC
12
L?SABMEr CANCEL TAC
13
(NS::=0,NR::=0)
14
L!Uar START TAC
15
L?Ir CANCEL TAC
16
(NR::=(NR+1)MOD 128)
17
L!DISC START TAC
18
(NS::=0,NR::=0)
19
L?UAr CANCEL TAC
20
<IUT!SABME>
21
START TWAIT
22
L?SABME CANCEL TWAIT
23
(NS::=0,NR::=0)
24 AlterL!UA START TWL3
25 nativen
L?Icr
26
(NR::=(NR+1)MOD 128)
27
L!RR
28
+POSTAMBLE
29
?TIMEOUT TWL3
30
+POSTAMBLE
31
?TIMEOUt TWAIT
32
+POSTAMBLE
33
?TIMEOUT TAC
34
+POSTAMBLE
35
?TIMEOUT TAC
36
+POSTAMBLE
37
?TIMEOUT TAC
38
+POSTAMBLE
39
?TIMEOUT TWAIT
40
+POSTAMBLE

UM_T6
UM_T1

L2

Lower Tester an IUT: TEI-Werte sind ungltig

IUT fordert neuen TEI-Wert (identity request)
der Tester antwortet nicht

die IUT fordert fter als RCMax neuen TEI-Wert

der Timer TNOAC ist abgelaufen, jetzt geht es weiter

UI3
UM(T1)

es wird eine unvollstndige SETUP-Message gesendet

es wird ein identity request von der IUT erwartet
hier wird der TEI-Wert erzeugt
der TEI-Wert wird zugewiesen (identity assigned)

SA(P1)

jetzt wird ein SABME erwartet

die Variablen NS, NR werden auf Null gesetzt

UA(F1)
IN8
P

Verbindungsaufbau wird besttigt

jetzt wird ein I-Frame erwartet
der I-Frame ist gekommen, NR wird ermittelt

DI(P1)

DISC wird an IUT geschickt und Timer TAC gestartet

NS und NR werden auf Null gesetzt

UA(F1)

wenn das DISC mit UA quittiert wird , wird TAC gelscht

die IUT soll ein SABME schicken (Please initiate a call !!!)

SA(P1)

wenn SABME kommt, wird TWAIT gelscht

NS, NR werden auf Null gesetzt

SA(F1)
IN5

UA wird als Besttigung fr SABME gesendet

es wird ein I-Frame mit SETUP etrwartet,
NR wird ermittelt

RRR

und der I-Frame mittels RR-Frame quittiert

IUT wird zurckgesetzt und der Testfall bewertet

Timer TWL3 abgelaufen, damit fehlerhaftes Verhalten

IUT wird zurckgesetzt und der Testfall bewertet

Timer TWAIT abgelaufen, damit fehlerhaftes Verhalten

IUT wird zurckgesetzt und der Testfall bewertet

Timer TAC abgelaufen, damit fehlerhaftes Verhalten

IUT wird zurckgesetzt und der Testfall bewertet

Timer TAC abgelaufen, damit fehlerhaftes Verhalten

IUT wird zurckgesetzt und der Testfall bewertet

Timer TAC abgelaufen, damit fehlerhaftes Verhalten

IUT wird zurckgesetzt und der Testfall bewertet

Timer TWAIT abgelaufen, damit fehlerhaftes Verhalten

IUT wird zurckgesetzt und der Testfall bewertet

Abb. 16:Prinzip einer Verhaltensbeschreibung mittels TTCN fr das Beispiel in Abbildung 13

In dem gezeigten Testfall soll der Verbindungsaufbau von der IUT aus getestet werden. In der Pramble wird
zuerst der TEI-Wert zurckgezogen. Wenn die IUT eine automatische TEI-Zuweisung untersttzt, wird diese
versuchen, einen neuen TEI-Wert zu bekommen (Zeilen 2 bis 5). Der Lower Tester reagiert nicht darauf, zhlt
aber die Anzahl der Versuche (RCMax). Wird RCMax berschritten, ist der Testfall gescheitert.
Luft der Timer TNOAC ab, geht der Test weiter. Der LT schickt unnumeriert eine unvollstndige SETUPNachricht (Zeile 8). Die IUT mu daraufhin, wenn sie standardkonform ist, einen TEI-Wert anfordern (Zeile 9),
Kommunikationssoftware

19

eine Schicht-2-Verbindung aufbauen (Zeile 12) und numeriert die Schicht-3-Nachricht REL_COM (Zeile 15)
schicken. Dieser I-Rahmen wird nicht quittiert, sondern die Schicht-2-Verbindung wird vom Lower Tester aus
abgebaut (Zeilen 17 bis 19). Die Schicht 2 der IUT befindet sich jetzt im Zustand 4 (TEI assigned).
Auf dem Tester erscheint die Ausschrift Please initiate a call. Der Testoperator nimmt den Telefonhrer ab.
Der Call Control Agent (siehe Abbildung 1) beauftragt die Schicht 3 mit einem Verbindungsaufbau. Schicht 3
wird mit dem ASP dlEstablishRq den Aufbau der Schicht 2 veranlassen. Das erwartete Ergebnis ist in den Zeilen
22 bis 27 dargestellt. Treten alle erwarteten Ereignisse ein, wird in Zeile 28 die Postamble abgearbeitet. In der
Postamble werden Zustnde der IUT getestet, die IUT in einen definierten Zustand gebracht, alle Testaussagen
bewertet und das Ergebnis pass, fail oder inconclusive ausgegeben.

Ausblick
Der Entwurf, die Entwicklung und der Test von Kommunikationssoftware wird durch formale Sprachen und
darauf basierenden Tools untersttzt. Die drei besprochenen Sprachen: MSC, SDL und TTCN sind semantisch
relativ gut aufeinander abgestimmt, die Syntax ist aber sehr verschieden.
Bei der Weiterentwicklung der Sprachen ist eine Eigendynamik zu beobachten, d.h. die Sprachen werden immer
mchtiger und wachsen in die Rolle von Sprachen fr die nchste Phase des Lebenszyklus hinein. Beispielsweise
kann man mit SDL auch programmieren.
Um der sogenannten Softwarekrise besser begegnen zu knnen, mu in der Ingenieurausbildung die Software
einen greren Raum einnehmen. Basierend auf den Grundlagen der Informatik und der Automatentheorie sind
Fachsprachen fr den Softwarelebenszyklus und ausgewhlte Werkzeuge dafr, Echtzeitbetriebssysteme sowie
das Management groer Softwareprojekte umfnglicher zu lehren.

Literatur
[BAUMGIES]

Bernd Baumgartner, Alfred Giessler: OSI-Testmethodik und TTCN

Berichte der GMD Nr.202, ISBN 3-468-22419-0
[HALLMANN] Matthias Hallmann,: Prototyping komplexer Softwaresysteme
Teubner 1990; ISBN 3-519-02497-5
[I-ETS 300 313] Interim ETSI-Standard: ISDN-DSS1;
Abstract Test Suite (ATS) for data link layer protocol for general application (user), ETSI 1995
[ISO9646]
ISO: Information technology - Open Systems Interconnection Conformance testing methodology and framework.
[Z.12094]
ITU-T: Message Sequence Chart (MSC); ITU 1994
[Z.12096]
ITU-T: Message Sequence Chart (MSC); ITU 1996
[Z.10093]
ITU-T: Specification and Description Language (SDL); ITU 1993

Autor:
Prof. Dr.-Ing. habil. Lutz Winkler
Hochschule fr Technik und Wirtschaft Mittweida (FH), Fachbereich Elektrotechnik/Elektronik
Technikumplatz 17, 09482 Mittweida
03727 581290
FAX 03727 581420
win@htwm.de

Kommunikationssoftware

20