[18] Nu P 13 1
Upcoming SlideShare
Loading in...5
×
 

[18] Nu P 13 1

on

  • 742 views

 

Statistics

Views

Total Views
742
Views on SlideShare
742
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

[18] Nu P 13 1 [18] Nu P 13 1 Document Transcript

  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • Statische Elemente von SDL Statisch sind die Programmstrukturen, die Nachrichtenpfade und die Erläuterungen (5) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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ß. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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“ © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • Folgeregel 1 FALSCH RICHTIG (24) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • Folgeregel 2 Falsch Richtig (25) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • Folgeregel 3 Falsch Richtig (26) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • Folgeregel 4 Falsch Richtig (27) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • Eingabewarteschlangen der Prozeßinstanzen Signal Signalwege Prozeß und Kanäle Signalwege Prozeß und Kanäle Signal Prozeß (29) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 Zustand 2.1 Zustand 2.2 A D A wird verbraucht Zustand 3.1 Zustand 3.2 (37) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 Zustand 2.1 Zustand 2.2 B wird verbraucht A D Das aufbewahrte Signal D wird verbraucht Zustand 3.1 Zustand 3.2 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • ... 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 Zustand 3.1 Zustand 3.2 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! © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • Timer-Mechanismus e d T zum Zeitpunkt x c b a TIMER-Mechanismus Prozeß (40) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • Ü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; © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • SDL'92 Typ Definitionen (2) (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; © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • SDL'92 Typ Definitionen (3) • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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 © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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. © UNI Hannover, Institut für Allgemeine Nachrichtentechnik
  • 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...) © UNI Hannover, Institut für Allgemeine Nachrichtentechnik