[18] Nu P 13 1

© UNI Hannover, Institut für Allgemeine Nachrichtentechnik

Institut für Kommunikationstechnikwww.ikt.uni-hannover.de

Specification and Description LanguageKapitel 13.1

Netze und ProtokolleLeibniz Universität Hannover

Institut für KommunikationstechnikKommunikationsnetze

Dr.-Ing. Jan Steuer


(2)

Begriffe

Spezifikation von Prozessen in FernmeldesystemenSDL: Specification and Description Language

ITU-T Rec. Z100Spezifikationen von Nachrichten zwischen Prozessen

ASN1: Abstract Syntax Notation oneITU-T Rec. X.208 and X.680-683ITU-T Rec. Z105: Use of SDL with ASN.1

BER: Basic Encoding Rules

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.


(3)

Prozess - Instanz ASDL

Prozess - Instanz BSDL

Prozess - CodeSDL

System 1

Prozess - Instanz ASDL

Prozess - Instanz BSDL

Prozess - CodeSDL

System 2

Message

Message

ASN1, BER

Prozesse

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 lokaleingrenzbar. 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 eineSpezifikationssprache 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 vorspezifiziertsind.


(4)

FormalKonzeptuell

Mapping

z.B. verbale Spracheoder formatfreie Bilder

z.B. SDL, ASN1,BER

Verifikation

Beziehungen zwischen Spezifikationsmethoden

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.


(5)

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

Statische Elemente von SDL


(6)

SDL-Begriffe

Spezifikation: Festlegung der geplanten Eigenschaften eines Systems(Was soll das System können?)

Beschreibung: Festlegung der vorhandenenEigenschaften eines Systems(Was kann das System und wie macht es das?)

Darstellung der EigenschaftenDatenblätter - SystemparameterSDL - Systemverhalten

SDL GrafikSDL Programm

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 odermittels 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


(7)

System

Block

Block

Pro

zess

Pro

zess

BlockP

roze

ss

Pro

zess

Block

Block

Pro

zess

Pro

zess

Block

Pro

zess

Pro

zess

SDL Strukturierung

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


(8)

System <system name>

<system declarationarea>

<block interactionarea>

grafisch

system <system name>;<system declarations><block interaction>

endsystem [<system name>]

textuell

Grafische und textuelle Repräsentation

SDL erlaubt sowohl die grafische, als auch die textuelle Beschreibung der Systeme. Der Programmierer wird häufig dietextuelle 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.


Erläuterungen

Die Systemstruktur ist statischDer Rahmen um das “System xyz” stellt die Grenze zu seiner Umgebung darDie Systeme können mit ihrer Umgebung kommunizierenDie 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 angegebenKanä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.

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

(9)

[S1,S2,S3][Sx, Sy] B_1

B_2

B_3

k-1 k-2

k-3

k-4k-5

[Sx, Sy][S1,S2,S3]

[S9]

[Si,Sk][S6][S5]

Texterweiterungzu Block B_1

Kommentarzu Block B_3

System xyzSIGNAL

S1,S2,S3Sx,Sy S9Si,Sk,S5,S6

Systemstruktur und Signalbehandlung

Verarbeitung der Signale S1,S2,S3

[S9]

Verarbeitung desSignales S9

[Sx, Sy]

Verarbeitung der Signale Sx, Sy

[S9]

Verarbeitung desSignales S9

(1. Durchlauf gespeichert)

[Si,Sk]Verarbeitung Si und Sk[S6]

Verarbeitung S6

[S5]

SIGNALS1,S2,S3Sx,Sy S9Si,Sk,S5,S6


(10)

CONNECT K_A AND k-1CONNECT K_D AND k-1CONNECT K_B AND k-2CONNECT K_C AND k-3

SIGNALS1, S2, S3,Sx,Sy,Si,S9

B_1_1

B_1_2

K_A

S1,S2

K_DS3

K_E

Si

K_C

S9

K_B

Sx,Sy

Block B_1

Block mit Unterblöcken

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ß.


(11)

CONNECT R_1 AND K_3;CONNECT R_3 AND K_2;CONNECT R_4 AND K_4;

SIGNALS9, Sx, Sy, Si, SkRequest

P1 P2R_1S9

R_4 Si, Sk

R_2Request

R3Sx, Sy

Block B_2

Block mit Prozessen

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.


(12)

P1 P2 P3P4 Pn

B_1_1 B_1_2

B_1 B_2 B_3

XYZ

Prozeß-Ebene

Unterblock-Ebene

Block-Ebene

System-Ebene

Baumdiagramm eines Systems

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


(13)

SDL erlaubt die Programmierung von dynamischen Systemzuständen:

ProzeßinstanzenWartezuständeReaktion auf Signale

dynamische Eigenschaften von SDL

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.


(14)

Monitor Geb_erzeug

P1

Start_Zähl,Stop_Zähl

P2

Terminiere

(1,1) (0,25)

Block Gebührenerfassungimmer einmal vorhanden

genau einmal instanziert

kann auch gar nicht vorhanden sein

maximal 25 mal instanziert

Welches Problem hat das hier spezifizierte Vorgehen?

dynamische Erzeugung

Kreieren von Prozeßinstanzen

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.


(15)

Prozeßkonzept in SDL

Ein Prozeß besteht aus Programm-Code und DatenfeldernProzeßinstanzen sind nur Datenfelder, die vom Programm-Code bedient werdenDer Prozeß kann

zeitlich versetzte oder gleichzeitige Signale aufnehmenSignale an andere Prozesse abgebenZustände behaltensich in einem von mehreren Wartezuständen auf Signale befinden(der eingenommene Wartezustand hängt von vorangegangenen Aktionen ab)sich im Verarbeitungszustand von Signalen befinden


(16)

Graphische Prozeß-darstellung SDL/GR

Darstellung von miteinander kommunizierenden Prozessenjeder Prozeß ist eine erweiterte FSM

Erweiterung um Variable und Entscheidungenbesondere Symbole für den Signalaustausch

FSM: Finite State Machine


(17)

Z2

Z4Z3

Z1

A1

E2

E3

A3

E4

A4

E7A7

A5

E5

A2

E1

E6

A6

Endlicher ZustandsautomatFSM

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 unddie 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.


(18)

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

Grundsymbole (1)


(19)

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

Grundsymbole (2)


(20)

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.

Konnektor

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

A

Symbole (3)


(21)

Alle Zustände

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

Alle INPUT-Signale

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

CREATE REQUEST

Anforderung zum kreieren eines Prozesses (hier: P_1).

PROCEDURE CALL

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

PROCEDURE REFERENCE

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

*

*

P_1

Proc_X

Proc_X

Symbole (4)

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


(22)

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.

Symbole (5)


(23)

a a

aa a

Flußlinien

Durch Konnektorenverbundene Flußlinien

Divergierende Flußlinien

Konvergierende Flußlinien

Flußlinien und Konnektoren in SDL/GR

jedes Symbol ist mit seinem(n) Nachfolger(n) über eine Flußlinie verbundeneine Flußlinie kann unterbrochen werden, sie endet dann in einem Ausgangs-

connector und beginnt wieder in einem EingangsconnectorFluß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 oderdurch 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 tragenFlußlinien verlaufen horizontal oder vertikal mit scharfen EckenKreuzungen von Flußlinien bedeuten keine logische Beziehung zwischen den Linien


(24)

FALSCH

RICHTIG

Folgeregel 1


(25)

Falsch

Richtig

Folgeregel 2


(26)

Falsch

Richtig

Folgeregel 3


(27)

Falsch

Richtig

Folgeregel 4


(28)

Block1 Block2

Ausgangswarte-schlange

Prozeß1 Prozeß2

Eingangswarte-schlange

Kanal

Signalpfad

Warteschlangen in SDL

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


(29)

Prozeß

Prozeß

Prozeß

Signal

Signal

Signalwege und Kanäle

Signalwege und Kanäle

Eingabewarteschlangen der Prozeßinstanzen


(30)

Process: Tasten-Überwachung(Totmann-Taste beimLokführer)

TIMER T_Out

SET(NOW +30,T_OUT)

Relative Zeit; mit NOW wirddie Systemzeit ausgelesen

Z0

Taste T_OUT Ende

ESET (T_OUT) Error RESET (T_OUT

SET(NOW +30, T_OUT)

Z0

Beispiele für Timer-Anwendung


(31)

S_1 S_2 S_3

[T, Ende] [T_2, Ende] [T_4]Teiler_1 Teiler_2

Block Takt_Teiler

Bsp.: Block Takt_Teiler


(32)

Z1

T

Z2

T

T_2

Z1

Ende

Ende

Ende

Prozess Teiler_1

Teiler 1

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.


(33)

Z1

T_2

Z2

T_2

T_4

Z1

Prozess Teiler_2

*

Ende

Teiler 2

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


(34)

DCL I INTEGER;/* Deklaration (DCL) derInteger-Variablen I */

I := 0;

Ruhe

Reset

I := 0;

Ruhe

Start

Aktiv

Stop

Ruhe

Sec

I := I + 1;

I

Aktiv Min

I: = 0;

Aktiv

< 60 =60

Process Sekunden_Zähler

Beispiel für Deklaration und Verwendung von Variablen


(35)

A trifft einA

A bewirkt einenZustandswechselund wird verbraucht

Reihenfolge desEintreffens

Zeit

Zustand 1

Zustand 2

A

Zustandswechsel in SDL/GR


(36)

Reihenfolge des Eintreffens

B trifft zuerst ein

A

B

B wird verbraucht

A trifft ein, wird aberzwischengespeichert

A wird verbraucht

Zeit

...

Zustand 1

A

Zustand 2.1

B

Zustand 2.2

A

Zustand 3

Reihenfolge der Verarbeitung nacheinander eintreffender Signale


(37)

Reihenfolge desEintreffens

A wird verbraucht

A

B D

C

C wird D wird B wirdimplizit implizit verbraucht

verbraucht verbraucht

...

Zustand 1

A

Zustand 2.1

B

Zustand 2.2

A

Zustand 3.1

D

Zustand 3.2

* (A, B) Übrige

Implizierter Verbrauch von nicht ausgewerteten Signalen


(38)

ZeitA

B

C D

A wird verbraucht

Das aufbewahrteSignal D wirdverbraucht

B wird verbraucht

D wird aufbewahrt

C wird implizitverbraucht

Reihenfolge des Eintreffens...

Zustand 1

A

Zustand 2.1

B

Zustand 2.2

A

Zustand 3.1

D

Zustand 3.2

A

Zustand 4

D * (A, B, D) Übrige

SAVE-Funktion in SDL/GR

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.


(39)

1. C wird implizit verbraucht2. D wird aufbewahrt3. B wird verbraucht

D wird verbraucht

1. A wird aufbewahrt2. E wird implizit verbraucht3. F wird aufbewahrt4. G wird verbraucht

A wird verbraucht

F wird verbraucht

CD B A

E F

G

Reihenfolge des Eintreffens

Zeit

...

Zustand 1

A

Zustand 2.1

B

Zustand 2.2

A

Zustand 3.1

D

Zustand 3.2

F G

Zustand 4

F A

Zustand 5

F

Zustand 6

A

F G

D E F

Beispiel eines komplexen Signaleinganges

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


(40)

e dT

a

b

c

TIMER-Mechanismus Prozeß

zumZeitpunkt x

Timer-Mechanismus


(41)

Ü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

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 T2NEXTSTATE 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;


(42)

Zweck von ASN1 & BER

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

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 zwischenDeklararation und Realität auftreten.


(43)

• Boolean- "NOT", "AND", "OR", "XOR", "=>"

• Character- "<", "<=", ">", ">=", Num, Chr

• String (TYPE Itemsort, LITERAL Emptystring), Charstring- MkString, Length, First, Last, "//", Extract!,

Modify!, Substring• Integer

- "-", "+", "*", "/", "mod", "rem", "<", "<=", ">", ">=", Float, Fix

• Real- "-", "+", "*", "/", "<", "<=", ">", ">="

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

Boolean : Variablen können die Werte TRUE oder FALSE annehmenBsp.: boolvar1 := boolvar2 AND boolvar1

Character : Variable kann einen Charakter annehmenBsp.: 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.


(44)

• Array (TYPE Index, TYPE Itemsort)- Make!, Modify!, Extract!

• PID• Duration

- "-", "+", "*", "/", "<", "<=", ">", ">="• Time

- "-", "+", "<", "<=", ">", ">="• Struct

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

Integer : Variablen können ganzzahlige Werte annehmenBsp.: intvar1 := intvar2 * intvar1

Array : erzeugt einen Array beliebigen Typs mit dem Index INTEGERPID : Typ für die Verwaltung von Process IDentification NumbersDuration : spezieller Typ zum Arbeiten mit Timern und ZeitabläufenTime : zur Definition von ZeitabläufenStruct : Erzeugt einen Datentyp, der sich aus beliebigen Datentypen zusammensetzen kann.

Bsp.: NEWTYPE SortName STRUCT

ComponentName, ComponentName SortName;ComponentName SortName1;

ENDNEWTYPE;


(45)

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

NEWTYPE Setup_Type STRUCTParameter 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 = charstringCONSTANTS 'request', 'indicate', 'response'

ENDSYNTYPE Parameter_type;

SDL'92 Typ Definitionen (3)

Typen können in ihren Eigenschaften frei definiert werden. Hier am Bsp. des Typs Boolean :NEWTYPE Boolean

LITERALS True, False; OPERATORS

"NOT" : Boolean -> Boolean; "AND" : Boolean, Boolean -> Boolean; "OR" : Boolean, Boolean -> Boolean; "XOR" : Boolean, Boolean -> Boolean; "=>" : Boolean, Boolean -> Boolean;

ENDNEWTYPE Boolean;Die Operatoren müssen im SDT Tool als Funktionen in der Programmiersprache C implementiert werden.


(46)

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

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

• Variablen werden auf Prozeß oder Prozedurebene definiert.

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

Variablen und Signal Definitionen


(47)

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

TIMERtimer_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 Timernamenan den Prozeß geschickt, in dem der Timer definiert worden ist.

Variablen und Timer Definitionen


(48)

• 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 übergebenIN/OUT : ändert den Parameter auch in dem aufrufenden

ProzeßRETURNS : übergibt einen Wert an die aufrufende Instanz

Parameter für Prozeduren


(49)

warten_6

warten_3

sig_setup (setup)via Leitung_1

sig_setup (putes)

[sig_setup]

Leitung_1

Prozess_1

Prozess_2

Signale mit Parameterübergabe

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 PIdExprdas Signal wird zu dem Prozeß mit der ProzeßID 'PIdExpr' geschickt

SignalName TO PROZ_DEFSendet Signal z.B. an sich selbst (siehe unten)

SignalName VIA PathNamedas Signal wird über 'PathName' geschickt.

SignalName VIA ALL PathName, PathNamedas Signal wird über alle angegebenen Signalwege geschickt

SignalName TO PId_Expr VIA PathNamesendet 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 "PROZ_DEF" können folgende Systemausdrücke benutzt werden :SELF : Eigene Prozeß_IDPARENT : Prozeß_ID vom ErzeugerprozeßOFFSPRING : Prozeß_ID vom zuletzt erzeugten ProzeßSENDER : Prozeß_ID vom Absender des zuletzt empfangenen

Signales


(50)

SDL-Beschreibung

C-Unterprogramme

C-Routinen alsSchnittstelle zur

Hardware (Treiber)

SDL-Compiler

Programmin C-Code

C-Compiler

SUN / Sparc / Solaris

Intel / 486 / NT & Unix

µ-Kontroller, z.B. 8031

Realisierung von Anwendungen

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), oderEntwicklung eines eigenen, bereits auf das Zielsystem optimierten SDL->C Compiler.


(51)

Prozeß 1

Prozeß 2

Prozeß 3

Plattform 1 (Sun)

Plattform 2 (PC)

ORB

TCP/IP

IDL-Beschreibung

Sun IDL-Compiler

ORB

TCP/IPProzeß 3*

C++ InterfaceRoutine

C++ InterfaceRoutine

NT IDL-Compiler

Realisierungen mit CORBA

Abkürzungen:CORBA - Common Object Request Broker ArchitectureIDL - 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/95Orbix (Corba Tool von der Fa. IONA) hat eine spezielle Schnittstelle für SDTDie 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...)

Documents

[18] Nu P 13 1