[18] Nu P 13 1

Specification and Description Language
Kapitel 13.1

Netze und Protokolle
Leibniz Universität Hannover
Institut für Kommunikationstechnik
Kommunikationsnetze
Dr.-Ing. Jan Steuer

Institut für Kommunikationstechnik
www.ikt.uni-hannover.de

© UNI Hannover, Institut für Allgemeine Nachrichtentechnik

Begriffe

Spezifikation von Prozessen in Fernmeldesystemen
SDL: Specification and Description Language
ITU-T Rec. Z100
Spezifikationen von Nachrichten zwischen Prozessen
ASN1: Abstract Syntax Notation one
ITU-T Rec. X.208 and X.680-683
ITU-T Rec. Z105: Use of SDL with ASN.1
BER: Basic Encoding Rules

(2)

Nachrichtentechnische Systeme sind regional, national, kontinental und weltweit miteinander verbunden. Daraus resultiert ein
erhöhter Grad der Komplexität, verglichen mit einzelnen Systemen.
Darüber hinaus werden mehr und mehr Funktionen der nachrichtentechnischen Systeme mittels Software realisiert.
Realisierte Systeme weisen teilweise mehrere hundert MByte Programmcode auf.
Die Folge dieser wachsenden Softwarekomplexität ist der Zwang zur Standardisierung bei der Softwareerstellung. Diese
Vorlesung soll sich mit den bereits vorhandenen Standards für Software in Fernmeldesystemen auseinandersetzen.
Es ist nicht das Ziel dieser Vorlesung, Standards für Softwareerstellung allgemein zu behandeln. Dazu verweise ich auf die
Vorlesungen meiner Kollegen in der Technischen Informatik und der Informatik.
Detailliert werden wir die Regeln von SDL in dieser Vorlesung und ASN1 und den BER in folgenden Vorlesungen bearbeiten,
da die meisten Nachrichtentechnischen Systeme hierauf basieren.


Prozesse

System 2
System 1

Prozess - Instanz A
Prozess - Instanz A
Message
SDL
SDL
Message

ASN1, BER

Prozess - Instanz B
Prozess - Instanz B
SDL
SDL

Prozess - Code
Prozess - Code
SDL
SDL

(3)

In diesem Beispiel sind zwei physikalisch getrennte Nachrichtensysteme, also z.B. zwei Vermittlungssysteme dargestellt.
Beide Vermittlungssysteme verfügen über die unterschiedlichsten Prozesse zur Lösung einzelner Teilaufgaben aus der
Vermittlungstechnik. Ein solcher Prozeß kann der Teilnehmerprozeß sein, der die Funktionen des Teilnehmers überwacht
und steuert, also z.B. die BORSCHT-Funktionen realisiert.
Jeder Prozeß besteht aus dem Code, der die Funktionalität beschreibt und einem Datenblock für jede Prozeßinstanz, der die
Zustandsdaten des Prozesses speichert. Der Code ist üblicherweise nur einmal im System vorhanden, während die
Datenblöcke individuell pro Teilnehmer aktiviert werden. Der Prozeßcode und die Prozeßinstanzen werden in der
Nachrichtentechnik in SDL spezifiziert. Dies schließt nicht aus, daß einzelne Teilaufgaben, wie z.B. die DTMF-Erkennung in
Signalprozessoren im zugehörigen Assembler (oder C) programmiert werden. Solche Assemblerroutinen sind aber lokal
eingrenzbar. Sie können zur Optimierung der lokalen Prozesse erforderlich sein.
SDL spezifiziert das Verhalten als Reaktion auf Meldungen und die Struktur von Systemen. SDL ist somit eine
Spezifikationssprache für Realtime-Systeme, die verteilt und interaktiv sein können. Der Grad der Abstraktion kann vom
Überblick bis zur detaillierten Behandlung von Variablen reichen.
Die Möglichkeit auf einem hohen Abstraktionsniveau zu arbeiten ermöglicht den sehr frühen Einsatz von SDL in der kreativen
Phase eines Systemlayouts. Damit wird die Diskussion zwischen Beteiligten auf eine formale und damit nachprüfbare,
eindeutige Grundlage gestellt. Folglich ist SDL auch geeignet ein System für eine Ausschreibung zu beschreiben und die
Angebote auf Übereinstimmung zu prüfen.
Die zwischen den Prozeßinstanzen ausgetauschten Meldungen sind in SDL nicht hinreichend spezifiziert. Hier setzt die
Funktion von ASN1 ein. Die BER sind in ASN1 vorhandene Grundfunktionen, die wegen ihrer Universalität vorspezifiziert
sind.


Beziehungen zwischen
Spezifikationsmethoden

Mapping
Formal
Konzeptuell Verifikation

z.B. verbale Sprache z.B. SDL, ASN1,
oder formatfreie Bilder BER

(4)

SDL ist eine formale Sprache, die im Gegensatz zur natürlichen (verbalen) Sprache einen hohen Grad an Präzision,
Nachprüfbarkeit und Zweifelsfreiheit aufweist. Die natürliche Sprache hat im technischen Bereich ihre Bedeutung, wenn Ziele,
Intentionen und Anforderungen formuliert werden sollen.
Eine verständliche Spezifikation wird also beide Sprachelemente enthalten. Anders ausgedrückt liefert die natürliche
Beschreibung Konzepte, während formale Beschreibungen Modelle der zu beschreibenden Objekte generieren. Eine gute
Spezifikation erlaubt immer wieder die Prüfung der Modelle gegen die Konzepte. Die Umkehrung ist nicht möglich.


Statische Elemente von SDL

Statisch sind die Programmstrukturen,
die Nachrichtenpfade und die Erläuterungen

(5)


SDL-Begriffe

Spezifikation: Festlegung der geplanten
Eigenschaften eines Systems
(Was soll das System können?)
Beschreibung: Festlegung der vorhandenen
Eigenschaften eines Systems
(Was kann das System und wie
macht es das?)
Darstellung der Eigenschaften
Datenblätter - Systemparameter
SDL - Systemverhalten
SDL Grafik
SDL Programm

(6)

Systemparameter sind z.B. die Zahl der Teilnehmer eines Vermittlungssystems oder die Übertragungsrate eines
Übertragungssystems

Das Systemverhalten gibt an, was das System zu bestimmten Zeitpunkten oder unter bestimmten Umständen, z.B. nach dem
Eintreffen von Signalen macht.

Die grafische Version von SDL ist durch Verwendung von Symbolen und zugehörigen Regeln leicht erlernbar und lesbar.

Die SDL-Version in Programmcodedarstellung wird automatisch aus der grafischen Version erzeugt und entweder
zur Interpretation dem Echtzeitsystem zugeführt oder
mittels eines Übersetzers in eine Zielsprache, z.B. C++ überführt.
Anwendung von SDL zur Spezifikation von:
. Vermittlungsvorgängen (Signalisierung und Reaktion auf Signalisierung)
. Wartungsvorgängen
. Fehlerbehandlung
. Systemsteuerung
. Kommunikationsprotokolle
Anmerkungen zum dargestellten Sprachumfang:
Untermenge von SDL-88 (Rec.ITU-T Z.100 von 1988)
keine Darstellung der objektorientierten Erweiterungen in SDL-92 (Rec.ITU-T Z.100 von 1993)
SDL/PE (Pictorial Elements) wurde gestrichen


SDL Strukturierung

System

Block Block

Block Block Block Block

Prozess
Prozess

Prozess

Prozess

Prozess

Prozess
Prozess

Prozess
(7)

Ein mit SDL spezifiziertes System kann
zur Gliederung in Teilaufgaben,
zum Test von Schnittstellen,
zur besseren Wiederverwendbarkeit

hierarchisch gegliedert werden

Das System zerfällt in Blöcke, Unterblöcke und Prozesse. Das System ist nur einmal vorhanden. Alle Untereinheiten können
mehrfach auftreten.

Unterteilungen sind so zu wählen, daß
die Kommunikation über Schnittstellen minimal wird,
die funktionale Struktur der Realisierung entspricht (z.B. sollte im Prozeß der Wegesuche keine Beschreibung der
Tonerkennung vorhanden sein)
die Verständlichkeit eines Blockes gefördert wird


Grafische und textuelle Repräsentation

System <system name>
system <system name>;
<system declaration
<system declarations>
area>
<block interaction>
<block interaction endsystem [<system name>]
area>

textuell
grafisch

(8)

SDL erlaubt sowohl die grafische, als auch die textuelle Beschreibung der Systeme. Der Programmierer wird häufig die
textuelle Eingabe seiner Spezifikationen tätigen und die Prüfungen und Dokumentationen mit der grafischen Darstellung
durchführen. Die grafische Darstellung läßt sich aus der textuellen maschinell erzeugen.
Die <system declarations> definieren die in der <block interaction area> verwendeten Variablen und Verbindungen. Sie
erlauben eine automatisierte Prüfung der Spezifikationen.


Systemstruktur und Signalbehandlung

System xyz
SIGNAL
S1,S2,S3
Sx,Sy S9
Si,Sk,S5,S6
Verarbeitung der
k-1 k-2
[Sx, Sy]
B_1
Signale S1,S2,S3
Signale Sx, Sy [Sx, Sy]
[S1,S2,S3] [Sx, Sy]
[S1,S2,S3]

Texterweiterung
zu Block B_1

Verarbeitung des
k-3
B_2
Signales S9
Signales S9
[S9]
[S9]
(1. Durchlauf
gespeichert)
Kommentar
zu Block B_3

k-4
k-5 Verarbeit
B_3
ung Si
S6
[Si,Sk]
[Si,Sk]
[S5] [S6] und Sk
[S5] [S6]

(9)

Erläuterungen

Die Systemstruktur ist statisch
Der Rahmen um das “System xyz” stellt die Grenze zu seiner Umgebung dar
Die Systeme können mit ihrer Umgebung kommunizieren
Die Rechtecke im System sind Blöcke (B_1, B_2, B_3)
Die Kommunikation der Blöcke untereinander und der Blöcke mit der Umgebung
erfolgt über Kanäle (K-1, K-2, K-3, K-4, K-5)
Kanäle können unidirektional oder bidirektional sein. Die Richtung wird mit Pfeilen angegeben
Kanäle übertragen Signale (S1, S2, S3, ..)

Im einem Textsymbol werden die benötigten Signale deklariert. Die Deklaration kann auf System- und Blockebene erfolgen,
nicht aber auf Prozessebene.

SIGNAL
S1,S2,S3
Sx,Sy S9
Si,Sk,S5,S6

Mit einem Signal können bei Bedarf auch Variablen übergeben werden.


Block mit Unterblöcken

Block B_1
CONNECT K_A AND k-1 SIGNAL
CONNECT K_D AND k-1 S1, S2, S3,
CONNECT K_B AND k-2 Sx,Sy,Si,
CONNECT K_C AND k-3 S9

K_A K_B
B_1_1
S1,S2 Sx,Sy

S3 Si
K_D K_E

K_C
B_1_2
S9

(10)

Der Block B_1 wird hier in die Unterblöcke B_1_1 und B_1_2 unterteilt. Die Verbindung zum Block B_1 wird über die
Blockbeschriftung (hier in der oberen linken Ecke ) und durch die CONNECT -Anweisungen hergestellt. Die CONNECT -
Anweisungen geben an, welche Kanäle von den Unterblöcken mit denen des Oberblockes verbunden ist. Die CONNECT-
Anweisungen können auch in der Form von Markern am Bildrand deklariert werden.
Die Blockbeschreibung ist nicht Bestandteil der SDL-Spezifikation, sie wird aber von dem hier verwendeten SDT-Tool
erzeugt. Fehlt die Blockbezeichnung, so kann die Referenz zum übergeordneten Block nicht in jedem Fall hergestellt werden,
da die Bezeichnung der Blöcke in der Wahlfreiheit der Programmierer steht und nicht wie in diesem Beispiel auseinander
ableitbar sein muß.


Block mit Prozessen

Block B_2
CONNECT R_1 AND K_3; SIGNAL
CONNECT R_3 AND K_2; S9, Sx, Sy, Si, Sk
CONNECT R_4 AND K_4; Request

R_1 R_2 R3
P1 P2
S9 Request Sx, Sy

Si, Sk
R_4

(11)

Die Prozesse sind in der statischen Strukturbeschreibung die kleinsten Einheiten. Prozesse können keine Unterprozesse
haben. In den Prozessen werden die dynamischen Abläufe spezifiziert. Innerhalb von Prozessen können andere Prozesse
instanziert werden. Die Beschreibung dieser instanzierten Prozesse ist aber außerhalb der aufrufenden Prozesse.


Baumdiagramm eines Systems

System-Ebene XYZ

B_3
B_2
Block-Ebene B_1

Unterblock-
B_1_1 B_1_2
Ebene

Prozeß- P4 Pn P1 P2 P3
Ebene

(12)

Es gibt genau eine Systemebene.
Die Block-/Unterblock-Ebene kann beliebige Verschachtelungen aufweisen.


dynamische Eigenschaften von SDL

SDL erlaubt die Programmierung von
dynamischen Systemzuständen:

Prozeßinstanzen
Wartezustände
Reaktion auf Signale

(13)

Die Dynamik ist nicht direkt aus der Spezifikation zu ersehen. Als Hilfsmittel zur Verdeutlichung sind die Message Sequence
Charts (MSC) spezifiziert.
Tools, wie der SDT SDL-Generator, stellen zusammen mit der Simulation eine weitere Möglichkeit der Darstellung der
Dynamik dar

Die Spezifikation eines Echtzeitsystems zwingt zur Spezifikation der dynamischen Vorgänge. Dynamische Vorgänge lassen
sich nur schwer verständlich auf Papier darstellen. Daher ist die Verwendung von Rechnern mit den Möglichkeiten der
visuellen Darstellung von Sequenzen ein hervorragendes Hilfsmittel. Hiervon macht der Simulator in dem SDT-SDL
Gebrauch.


Kreieren von Prozeßinstanzen

Block Gebührenerfassung
immer einmal vorhanden kann auch gar nicht vorhanden sein

genau einmal instanziert maximal 25 mal instanziert

dynamische Erzeugung

(1,1) (0,25)
Start_Zähl,
Terminiere
Monitor Geb_erzeug
Stop_Zähl

P1 P2

Welches Problem hat das hier spezifizierte Vorgehen?

(14)

Der Prozeß Monitor ist beim Einschalten des Systems einmal instanziert. Eine weitere Instanzierung erfolgt nicht. Über das
Signal Start_Zähl wird der Prozess Monitor veranlaßt den Prozeß Geb_erzeug zu instanzieren. Dort werden dann z.B.
Zeitereignisse gezählt.
Gestoppt wird der Gebührenzähler durch das Signal Stop_Zähl an den Prozeß Monitor, der wiederum mit dem Signal
Terminiere die Reinstanzierung des Prozesses Geb_Erzeug bewirkt.


Prozeßkonzept in SDL

Ein Prozeß besteht aus Programm-Code und Datenfeldern
Prozeßinstanzen sind nur Datenfelder, die vom Programm-Code
bedient werden
Der Prozeß kann
zeitlich versetzte oder gleichzeitige Signale aufnehmen
Signale an andere Prozesse abgeben
Zustände behalten
sich in einem von mehreren Wartezuständen auf Signale befinden(der
eingenommene Wartezustand hängt von vorangegangenen Aktionen ab)
sich im Verarbeitungszustand von Signalen befinden

(15)


Graphische Prozeß-darstellung SDL/GR

Darstellung von miteinander kommunizierenden
Prozessen
jeder Prozeß ist eine erweiterte FSM
Erweiterung um Variable und Entscheidungen
besondere Symbole für den Signalaustausch

(16)

FSM: Finite State Machine


Endlicher Zustandsautomat
FSM

E3
A1
Z2
A6
A3
E1 E2
E4

Z1
E6 A2

E5

A4

Z4
Z3
A7
E7
A5

(17)

Kommunikationssysteme können aus parallelen oder quasiparallelen Prozessenbestehen. Echte Parallelität besteht, wenn
die Prozesse auf getrennten Rechnern ablaufen. Quasiparallel sind die Prozesse, wenn sie auf einem Prozessor installiert
sind. DieProzesse sind über Warteschlangen gekoppelt.

Neben der SDL-Darstellung können Prozesse auch als Finite State Machines (FSM) [endlicher Zustandsautomat]
anschaulich gemacht werden.
die Zustände der FSM werden mit Z1 bis Z4,
die Ereignisse mit E1 bis E7 und
die Aktionen auf die Ereignisse mit A1 bis A7
Problematisch bei den FSM ist,
daß die Zahl der Zustände unübersichtlich groß werden kann. Stellen Sie sich als Beispiel einen Zähler vor. In FSM-
Darstellung ist jeder Zählerzustand ein eigener Zustand!
daß die Kommunikation zwischen mehreren FSM nicht definiert ist und damit nicht mehrere Prozesse dargestellt
werden können
Abhilfe bietet SDL. SDL ist als Sprache für eine Multiprozeßumgebung spezifiziert, und SDL kennt Variable, mit deren Hilfe
Zähler gebildet werden können.


Grundsymbole (1)

Spezifikation/ Beschreibung eines Prozesses in SDL/ GR durch folgende
Elemente:

Eingabe (Input)

Entgegennahme von Signalen eines anderen Prozesses

Ausgabe (Output)

Aussendung von Signalen an einen anderen Prozesses

Wartezustand (State)

Zustand eines Prozesses, während dessen er ohne Ausführung irgendwelcher
Aktionen auf das Eintreffen von Signalen wartet

(18)


Grundsymbole (2)

Aufbewahrung (Save)

Speicherung eines eintreffenden Signales zur späteren Entgegennahme in
einem anderen Zustand des Prozesses

Übergang (Transition)

Folge von Aktionen beim Übergang von einem Wartezustand in einen anderen
Wartezustand

Entscheidung (Decision)

Auswahl einer von mehreren Folgen von Aktionen im Verlaufe eines Überganges

Aufgabe (task)

Aktionen, die weder Ausgaben noch Entscheidungen sind

(19)


Symbole (3)
Text-Extension

Texterweiterung für ein Symbol (falls im Symbol nicht mehr genug Platz für Text ist).

Kommentar

Angabe eines Kommentars für ein Symbol.

Textsymbol

Unterschiedliche Anwendung des Textsymbols, z.B. Angabe von Signallisten,
Variablendeklaration, Timer-Deklaration.

START

Definierte Startangabe für einen Prozess.

STOP

Durch das STOP-Symbol wird ein Prozess beendet. Er ist dann nicht mehr existent.

A
Konnektor

Verbindung von Flußlinien, z.B. auf unterschiedlichen Diagrammseiten.

(20)


Symbole (4)
*
Alle Zustände

Abkürzende Darstellung für quot;alle möglichen Zustände in diesem Prozeßquot;.

*
Alle INPUT-Signale

Abkürzende Darstellung für quot;alle möglichen Input-Signale in diesem Prozeßquot;.
Eine Kombination mit quot;alle Zuständequot; ist nicht möglich.

P_1
CREATE REQUEST

Anforderung zum kreieren eines Prozesses (hier: P_1).

Proc_X
PROCEDURE CALL

Aufruf einer Prozedur (entspricht dem Prozeduraufruf einer normalen
Programmiersprache).

Proc_X
PROCEDURE REFERENCE

Referenzsymbol für eine Prozedur. Die entsprechende Definition der Prozedur
(hier Proc_X)
erfolgt in einem separaten (Prozedur-) Diagramm.
(21)

Hinweis: * (A,B) bedeutet „Alle möglichen außer A und B“


Symbole (5)

PROCEDURE START nur in Prozessdiagrammen!

Angabe des Startpunktes einer Prozedur.

PROCEDURE RETURN nur in Prozessdiagrammen!

Angabe des Return-Punktes einer Prozedur. (Procedur-Ende : Mit der
einem Erweiterungssymbol kann ein Rückgabewert an den aufrufenden
Prozess übergeben werden.
Anmerkung: In einem Prozedurdiagramm sind alle Prozeßsymbole
erlaubt.

(22)


Flußlinien und Konnektoren in SDL/GR

Flußlinien

Durch Konnektoren
a a verbundene Flußlinien

Divergierende Flußlinien

a
a a Konvergierende Flußlinien

(23)

jedes Symbol ist mit seinem(n) Nachfolger(n) über eine Flußlinie verbunden
eine Flußlinie kann unterbrochen werden, sie endet dann in einem Ausgangs-
connector und beginnt wieder in einem Eingangsconnector
Flußlinien können sich vereinigen. Die Vereinigung kann
durch Zusammenfügung von Flußlinien,
indirekt durch Darstellung von mehreren Ausgangsconnectoren und einem zugehörigen Eingangsconnector oder
durch Eintreten mehrerer Flußlinien in einen Zustand erfolgen.
Eine Flußlinie kann sich - z.B. nach einem Entscheidungssymbol - in zwei oder mehr Linien auf-
spalten (eindeutig kennzeichnen, unter welcher Bedingung welcher Weg genommen wir
Flußlinien müssen bei einer Vereinigung, beim Eintritt in Ausgangsconnectoren und
beim Eintritt in Zustände mit Pfeilen versehen werden
Flußlinien, die in Eingangssymbole münden, dürfen keine Pfeile tragen
Flußlinien verlaufen horizontal oder vertikal mit scharfen Ecken
Kreuzungen von Flußlinien bedeuten keine logische Beziehung zwischen den Linien


Folgeregel 1

FALSCH

RICHTIG

(24)


Folgeregel 2

Falsch

Richtig

(25)


Folgeregel 3

Falsch

Richtig

(26)


Folgeregel 4

Falsch

Richtig

(27)


Warteschlangen in SDL

Kanal
Block1 Block2
Ausgangswarte-
schlange

Signalpfad
Prozeß1 Prozeß2
Eingangswarte-
schlange

(28)

Für einen Kanal kann eine zufällige Verzögerung oder eine bestimmte Verzögerung programmiert werden. Ein Signalpfad
besitzt keine Verzögerung.


Eingabewarteschlangen der
Prozeßinstanzen

Signal
Signalwege
Prozeß und Kanäle

Signalwege
Prozeß
und Kanäle
Signal

Prozeß

(29)


Beispiele für Timer-Anwendung

TIMER T_Out

Process: Tasten-Überwachung SET(NOW +30, Relative Zeit; mit NOW wird
T_OUT) die Systemzeit ausgelesen
(Totmann-Taste beim
Lokführer)
Z0

Taste T_OUT Ende

ESET (T_OUT) Error RESET (T_OUT

SET(NOW +30,
T_OUT)

Z0

(30)


Bsp.: Block Takt_Teiler

Block Takt_Teiler

S_1 S_2 S_3
Teiler_1 Teiler_2
[T, Ende] [T_2, Ende] [T_4]

(31)


Teiler 1

Prozess Teiler_1

Z1

T Ende

Z2

T Ende

T_2 Ende

Z1

(32)

Dies ist ein Teiler durch zwei.
Achtung: Erreicht den Prozess das Ende-Signal in Z1, so wird der Prozeß erst durch ein nachfolgendes T-Signal wirklich
reinstanziert.


Teiler 2

Prozess Teiler_2

*
Z1

T_2
Ende

Z2

T_2

T_4

Z1

(33)

Dieser Teiler-Prozeß kann in jedem Zustand durch ein Ende-Signal reinstanziert werden.


Beispiel für Deklaration und Verwendung
von Variablen

Process Sekunden_Zähler

DCL I INTEGER; I := 0; Stop Sec
/* Deklaration (DCL) der
Integer-Variablen I */
Ruhe Ruhe I := I + 1;

Reset Start I
< 60 =60
I := 0; Aktiv Min

Ruhe Aktiv I: = 0;

Aktiv

(34)


Zustandswechsel in SDL/GR

Reihenfolge des
Eintreffens

Zustand 1

A
A trifft ein
Zeit

A
A bewirkt einen
Zustandswechsel
und wird verbraucht

Zustand 2

(35)


Reihenfolge der Verarbeitung
nacheinander eintreffender Signale

Reihenfolge des
Eintreffens
B
B trifft
... zuerst ein

A trifft ein, A
wird aber
Zustand 1
zwischengespeichert
Zeit

A B
B wird verbraucht

Zustand 2.1 Zustand 2.2

A
A wird verbraucht

Zustand 3

(36)


Implizierter Verbrauch von nicht
ausgewerteten Signalen

Reihenfolge des
Eintreffens

C
... D
B
A
Zustand 1

A B * (A, B) Übrige
C wird D wird B wird
implizit implizit verbraucht
verbraucht verbraucht

A D
A wird verbraucht


(37)


SAVE-Funktion in SDL/GR

Reihenfolge des
... Eintreffens
C D
Zustand 1 B
A
Zeit
C wird implizit
A B D * (A, B, D) Übrige verbraucht

D wird aufbewahrt
B wird verbraucht

A D Das aufbewahrte
Signal D wird
verbraucht

A

A wird verbraucht
Zustand 4

(38)

Beim Zustandswechsel werden alle nicht gespeicherten Signale gelöscht! Oft werden in der Praxis mit der „Save *“
Anweisung alle Signale gespeichert, damit in den Folgezuständen eine Auswertung der Signale erfolgen kann.


... Reihenfolge des Eintreffens
Beispiel eines komplexen
Signaleinganges C
D
Zustand 1 B
A
E F

A B D E F
1. C wird implizit verbraucht
2. D wird aufbewahrt
Zustand 2.1 Zustand 2.2 3. B wird verbraucht Zeit
G

A D F G
D wird verbraucht


F G A
1. A wird aufbewahrt
2. E wird implizit verbraucht
3. F wird aufbewahrt
Zustand 4 4. G wird verbraucht

F A
A wird verbraucht

Zustand 5

F F wird verbraucht

Zustand 6 (39)

Hinweis: Das Bild ist unvollständig. Der Input des Signals „F“ in Zustand 4 muß weiterführen!


Timer-Mechanismus

e d
T

zum
Zeitpunkt x
c

b

a
TIMER-Mechanismus Prozeß

(40)


Übung

Welche Darstellungsmethoden sind in SDL möglich?
Welche Vorteile hat eine Systembeschreibung mit Hilfe
von SDL, verglichen mit z.B. Pascal?
Welche Aufgabe hat das Save-Symbol?
Setzen Sie die als Text angegebene Spezifikation des
„SYSTEMS Binärzähler“ in eine SDL/GR-Spezifikation um

(41)

Beispiel für SDL/PR Quelltext (zweistelliger Binärzähler)
SYSTEM Binärzähler;
SIGNAL T1;
CHANNEL C1 FROM ENV TO Block_eins WITH T1;
CHANNEL C2 FROM Block_eins TO Block_zwei WITH T2;
BLOCK Block_eins;
CONNECT C1 AND R1;
CONNECT C2 AND R2;
SIGNALROUTE R1 FROM ENV TO Prozess_eins WITH T1;
SIGNALROUTE R2 FROM Prozess_eins TO Prozess_zwei WITH T2;
PROCESS Prozess_eins;
STATE Warten_0;
INPUT T1;
NEXTSTATE Warten_1;
STATE Warten_1;
INPUT T1;
OUTPUT T2
NEXTSTATE Warten_0;
ENDPROCESS Prozess_eins;
ENDBLOCK Block_eins;
BLOCK Block_zwei;
CONNECT C2 AND R3;
SIGNALROUTE R3 FROM Prozess_eins TO Prozess_zwei WITH T2;
PROCESS Prozess_zwei;
STATE Warten_0x;
INPUT T2;
NEXTSTATE Warten_1x;
STATE Warten_1x;
INPUT T2;
NEXTSTATE Warten_0x;
ENDPROCESS Prozess_zwei;
ENDBLOCK Block_zwei;
ENDSYSTEM Binärzähler;


Zweck von ASN1 & BER

Exakte Definition von Datenströmen und deren (binärer)
Codierung über Kommunikationsverbindungen mittels
einer Hochsprache, die einfach erlernbar sein soll
Erzeugung von Runtime-Modulen zur syntaktischen
Prüfung der Datenströme

(42)

Aus Hochsprachen wie Pascal, ADA oder ähnlichen, ist bereits bekannt, daß vor der Erzeugung der Programmbefehle die
Typ-Deklarationen erfolgen. Typen können sein:
Integer, Real, Array, String, Set of...
Mit Hilfe dieser Typdeklarationen wird an den Schnittstellen geprüft, ob die übergebenen Daten den Vereinbarungen
entsprechen.
Einerseits kann bereits zur Kompilationszeit geprüft werden, ob die übergebenen Variablen den Typen entsprechen,
andererseits kann auch zur Exekutionszeit geprüft werden, ob die Daten, die übergeben werden vom richtigen Typ sind.
Wenn ein Datentyp zur Kompilationszeit richtig ist, sollte er eigentlich auch zur Laufzeit richtig sein. Im Prinzip ja, aber wenn
bei einer Datenübertragung ein unerkannter Fehler auftritt, dann kann zur Laufzeit die Unverträglichkeit zwischen
Deklararation und Realität auftreten.


SDL'92 Typ Definitionen (1)
(vordefinierte Typen + Operatoren)

• Boolean
- quot;NOTquot;, quot;ANDquot;, quot;ORquot;, quot;XORquot;, quot;=>quot;
• Character
- quot;<quot;, quot;<=quot;, quot;>quot;, quot;>=quot;, Num, Chr
• String (TYPE Itemsort, LITERAL Emptystring), Charstring
- MkString, Length, First, Last, quot;//quot;, Extract!,
Modify!, Substring
• Integer
- quot;-quot;, quot;+quot;, quot;*quot;, quot;/quot;, quot;modquot;, quot;remquot;, quot;<quot;, quot;<=quot;,
quot;>quot;, quot;>=quot;, Float, Fix
• Real
- quot;-quot;, quot;+quot;, quot;*quot;, quot;/quot;, quot;<quot;, quot;<=quot;, quot;>quot;, quot;>=quot;

(43)

Boolean : Variablen können die Werte TRUE oder FALSE annehmen
Bsp.: boolvar1 := boolvar2 AND boolvar1
Character : Variable kann einen Charakter annehmen
Bsp.: charvar := 'd',
charvar1 := Num (93)
String / Charstring : definiert einen String vom Typ 'Itmensort' beliebiger Länge
StringType := MKSTRING (Itemsort);
StringType := MKSTRING (Itemsort) // MKSTRING (Itemsort);
Füllen einer Nachricht mit einem beziehungsweise mehreren Inhalten.

StringType1 := StringType ;
StringType := StringType1 // StringType ;
Zuweisen von Strings, Aneinanderketten von Strings.

ByteType := StringType (IntegerType);
StringType (IntegerType) := ByteType;
Herauslesen beziehungsweise Überschreiben von beliebigen Inhalten (Vereinfachung von Modify!).

StringType:=Substring(StringType,AnfangIntegerType,LängeIntegerType);
Herauslesen eines beliebigen Teilstrings.

IntegerType := Length (StringType);
StringType := 0;
Länge eines Strings ermitteln, String löschen.


(vordefinierte Typen + Operatoren)

• Array (TYPE Index, TYPE Itemsort)
- Make!, Modify!, Extract!
• PID
• Duration
- quot;-quot;, quot;+quot;, quot;*quot;, quot;/quot;, quot;<quot;, quot;<=quot;, quot;>quot;, quot;>=quot;
• Time
- quot;-quot;, quot;+quot;, quot;<quot;, quot;<=quot;, quot;>quot;, quot;>=quot;
• Struct

(44)

Integer : Variablen können ganzzahlige Werte annehmen
Bsp.: intvar1 := intvar2 * intvar1
Array : erzeugt einen Array beliebigen Typs mit dem Index INTEGER
PID : Typ für die Verwaltung von Process IDentification Numbers
Duration : spezieller Typ zum Arbeiten mit Timern und Zeitabläufen
Time : zur Definition von Zeitabläufen
Struct : Erzeugt einen Datentyp, der sich aus beliebigen Datentypen zusammensetzen kann.
Bsp.:
NEWTYPE SortName STRUCT
ComponentName, ComponentName SortName;
ComponentName SortName1;
ENDNEWTYPE;



• SDL bietet die Möglichkeit eigene Typen auf Systemebene
zu definieren:

NEWTYPE Setup_Type STRUCT
Parameter Parameter_type;
CCEI Integer;
Portable_identity Var_info;
Fixed_identity Var_info;
Basic_service Var_info;
IWU_attributes Var_info;
ENDNEWTYPE Setup_Type;

• oder schon vorhandene Typen an den eigenen Bedarf
anzupassen :

SYNTYPE Parameter_type = charstring
CONSTANTS 'request', 'indicate', 'response'
ENDSYNTYPE Parameter_type;

(45)

Typen können in ihren Eigenschaften frei definiert werden. Hier am Bsp. des Typs Boolean :
NEWTYPE Boolean
LITERALS True, False;
OPERATORS
quot;NOTquot; : Boolean -> Boolean;
quot;ANDquot; : Boolean, Boolean -> Boolean;
quot;ORquot; : Boolean, Boolean -> Boolean;
quot;XORquot; : Boolean, Boolean -> Boolean;
quot;=>quot; : Boolean, Boolean -> Boolean;
ENDNEWTYPE Boolean;
Die Operatoren müssen im SDT Tool als Funktionen in der Programmiersprache C implementiert werden.


Variablen und Signal Definitionen

• Signale werden auf Systemebene definiert. Sie können aus beliebig
zusammengesetzten Datentypen / Informationen oder nur als
Signal ohne Inhalt benutzt werden

SIGNAL
Sig_Setup (Setup_Type),
SigName1 (ExprType, PId),
Alles_OK (Boolean, Integer),
Nur_Signal;

• Variablen werden auf Prozeß oder Prozedurebene definiert.

DCL
setup Setup_Type,
zustand BOOLEAN,
par1, par2 Parameter_Type,
timeout_setup DURATION := 10;

(46)


Variablen und Timer Definitionen

• Timer müssen, genau wie Variablen vor Gebrauch definiert werden

TIMER
timer_setup;

• in einem Prozeß oder einer Prozedur können Timer dann gestartet
oder gestoppt werden

SET (NOW + timeout_setup, timer_setup)
RESET (timer_setup)

• läuft ein Timer ab, wird ein Signal mit dem definierten Timernamen
an den Prozeß geschickt, in dem der Timer definiert worden ist.

(47)


Parameter für Prozeduren

• Für die Parameterübergabe an Prozeduren gibt es die Befehle
'FPAR', 'IN', 'IN/OUT' und 'RETURNS'

FPAR : definiert die zu übergebenden Parameter
IN : Parameter werden in die Prozedur übergeben
IN/OUT : ändert den Parameter auch in dem aufrufenden
Prozeß
RETURNS : übergibt einen Wert an die aufrufende Instanz

(48)


Signale mit Parameterübergabe
Prozess_2

warten_6

sig_setup (putes)

Prozess_1

warten_3

Leitung_1
sig_setup (setup)
via Leitung_1
[sig_setup]

(49)

Signale übertragen nur einem bestimmten Dateninhalt, keine Variable. Das hat zur Folge, daß in
verschiedenen Prozessen die zum Senden und Empfangen benutzten Variablen zwar den gleichen Type haben müssen,
nicht aber den gleichen Namen.
es gibt verschiedene Möglichkeiten Ziele für Signale anzugeben:
SignalName (Expr, Expr)
Gibt es einen eindeutigen Signalweg, braucht kein Ziel angegeben zu werden. Vorsicht : führt zusätzlich
auch ein Signalweg mit dem angegebenen Signal zu dem Prozeß selbst, wird dieser vom Signal gewählt.
Folge : der Prozeß schickt das Signal an sich selbst.
SignalName TO PIdExpr
das Signal wird zu dem Prozeß mit der ProzeßID 'PIdExpr' geschickt
SignalName TO PROZ_DEF
Sendet Signal z.B. an sich selbst (siehe unten)
SignalName VIA PathName
das Signal wird über 'PathName' geschickt.
SignalName VIA ALL PathName, PathName
das Signal wird über alle angegebenen Signalwege geschickt
SignalName TO PId_Expr VIA PathName
sendet ein Signal zum Prozeß 'PIdExpr' über den Signalweg 'PathName'
SigName1 (Expr, PROZ_DEF)
sendet z.B. die eigene Prozeß ID (SELF) zum Empfänger.

Für quot;PROZ_DEFquot; können folgende Systemausdrücke benutzt werden :
SELF : Eigene Prozeß_ID
PARENT : Prozeß_ID vom Erzeugerprozeß
OFFSPRING : Prozeß_ID vom zuletzt erzeugten Prozeß
SENDER : Prozeß_ID vom Absender des zuletzt empfangenen
Signales


Realisierung von Anwendungen

SDL-
SDL-Compiler
Beschreibung

C- Programm
Unterprogramme in C-Code
C-Routinen als
Schnittstelle zur
Hardware (Treiber)

C-Compiler

SUN / Sparc / Solaris µ-Kontroller, z.B. 8031

Intel / 486 / NT & Unix

(50)

Problem:

„langsame“ Low-Cost µ-Controller in TEs !

Lösung:

nur die Definition & Simulation in SDL, das schnelle Assembler-Programm wird aber manuell programmiert. (von SDL
abgeleitet), oder
Entwicklung eines eigenen, bereits auf das Zielsystem optimierten SDL->C Compiler.


Realisierungen mit CORBA

IDL-
Beschreibung

Sun IDL-
NT IDL-
Compiler
Compiler
Plattform 1 (Sun)
Plattform 2 (PC)
Prozeß 1
C++ Interface
C++ Interface
Routine
Routine
Prozeß 3

Prozeß 2 ORB ORB
Prozeß 3*
TCP/IP TCP/IP

(51)

Abkürzungen:
CORBA - Common Object Request Broker Architecture
IDL - Interace Description Language

ORB-Demon mit IP-Nameserver / Server Locator (Tabelle)
Die Korrekte Funktion des IP-Netzes ist eine Voraussetzung!
Nur die IDL-Beschreibung muß den Kommunikationspartnern bekannt sein.
Die Implementierung auf der Plattform und die Lokalisation des Rechners sind nicht mehr relevant.
Über den ORB können (Dienst-) Objekte in beiden Richtungen aufgerufen werden. (Client/Server)
Die Objekte auf entfernten Systemen können wie lokale Unterprogramme aufgerufen werden. Der Demon kann mehrere
Instanzen der gewünschten Objekte dynamisch erzeugen. (z.B. Multi-System-Zugriff)
CORBA Compiler z.Z. für C++ & Java auf Unix & NT/95
Orbix (Corba Tool von der Fa. IONA) hat eine spezielle Schnittstelle für SDT
Die Kommunikation der verteilten Objekte via CORBA ist als Standard spezifiziert, grundsätzlich ist eine derartige
Kommunikation auch in SDL zu implementieren. Beispiele: E-DSS1 (aber mit manuellem Auf- und Abbau aller Schichten...)


[18] Nu P 13 1

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (17)

Similar to [18] Nu P 13 1

Similar to [18] Nu P 13 1 (20)

More from Rafael Scudelari

More from Rafael Scudelari (20)

[18] Nu P 13 1