Leseprobe
Inhaltsverzeichnis
1 Einleitung
2 Open System Interconnection (OSI)
2.1 Begriffsbestimmung
2.2 OSI-Architektur
2.3 OSI-Referenzmodell
2.4 Typische Schichtfunktionalitäten
2.5 Schicht 7-Dienstelemente
2.6 Protokollspezifikationssprache ASN.1
3 OSI Systems Management
3.1 Überblick
3.2 Informationsmodell
3.3 Organisationsmodell
3.4 Kommunikationsmodell
3.5 Funktionsmodell
3.6 Offene Punkte
4 Abstract Syntax Notation One (ASN.1)
4.1 Begriffsbestimmung
4.2 Datentypen
4.3 Syntaxregeln
4.4 Tags
4.5 Untertypen
4.6 Object Identifier
4.7 Protokollbeispiel - Filetransfer
4.8 Basic Encoding Rules
4.9 Implementierung von ASN.1 -Datentypen
5 Guidelines for the Definition of Managed Objects (GDMO)
5.1 Begriffsbestimmung
5.2 Templates
5.3 Syntaxregeln
5.4 GDMO-Beispiel - Dateiverwaltung
5.4.1 MANAGED OBJECT CLASS-Template
5.4.2 NAME BINDING-Template
5.4.3 PACKAGE-Template
5.4.4 ATTRIBUTE-Template
5.4.5 BEHAVIOUR-Template
5.4.6 PARAMETER-Template
5.4.7 ACTION-Template
5.4.8 NOTIFICATION-Template
5.4.9 ASN.1-Modul
5.5 Zusammenhang zwischen CMISE und GDMO
6 Softwaretracer (SWT)
6.1 Begriffsbestimmung
6.2 Manager-Agent-Prinzip
6.3 Funktionsweise / Leistungsmerkmale
6.4 Bedienung
7 Qx-Softwaretracer-Analysator (QSTAN)
7.1 Motivation
7.2 Benutzeroberfläche
7.2.1 Startformular
7.2.2 Menüleisten
7.3 Konvertierungslauf
7.3.1 Datenkonvertierung starten
7.3.2 Konvertierungsreport
7.3.3 Unbekannte Zeichenfolgen bearbeiten
7.4 Datenauswertung
7.4.1 Detailansicht
7.4.2 Tabellarische Datenansicht
7.4.3 Laufzeitmessung durchführen
7.4.4 Datenblattansicht
7.4.5 Daten drucken
7.5 Weitere Programmfunktionen
7.5.1 Abfragen erstellen
7.5.2 Tabellen löschen
7.5.3 Datenbank komprimieren
7.5.4 Speichern von Programmeinstellungen
7.5.5 Online-Hilfe
7.6 Programminformationen
7.6.1 Systemanforderungen
7.6.2 Bezugsquelle
Abkürzungsverzeichnis
Literaturverzeichnis
Danksagung
1 Einleitung
Die Grundlage jeder Kommunikation ist das Verständnis einer gemeinsamen Sprache. Dabei ist es unerheblich, ob sich Menschen, Maschinen oder auch Mensch und Maschine verständigen. Nicht nur die Evolution der Menschheit brachte unterschiedliche Sprachen hervor, die im allgemeinen zu Verständigungsschwierigkeiten führen. Auch im geschichtlichen Verlauf der Entwicklung von elektronischen Rechnersystemen entstanden die verschiedensten Kommunikationsarchitekturen, die untereinander nicht ohne weiteres in der Lage sind, Informationen auszutauschen; ihnen fehlt demnach ein einheitliches „Vokabular“ (fachsprachlich: Protokoll). Durch die zunehmende weltweite Vernetzung - hier sei beispielsweise an die Internettechnologie gedacht - treten aufgrund dieser Verschiedenartigkeit Probleme auf, die zum Teil nur mit viel Aufwand in den Griff zu bekommen sind.
Normungsgremien, wie beispielsweise die International Organization for Standardization (ISO) oder die International Telecommunication Union (ITU), sind seit jeher bestrebt, Kommunikationsvorgänge zwischen Rechnern und auch die stets notwendigen Schnittstellen zum Menschen zu vereinheitlichen. Auf diese Weise ist die gegenwärtig stark gefragte Interkonnektivität und Interoperabilität zwischen den verschiedensten Systemen erst möglich geworden. Das Resultat des Standardisierungsprozesses ist in Fachkreisen unter dem Namen „Open System Interconnection (OSI) “ bekannt. Die Vertrautheit mit den OSI-Prinzipien (siehe Kapitel 2) bildet die Basis für das Verständnis jeder rechnergestützten Kommunikation.
Netzwerke zum Austausch von Daten jeglicher Art (Sprache, Bild, Text etc.) sind in den letzten Jahrzehnten in einem großen Umfang entstanden. Der rasante technische Fortschritt bringt zudem immer mächtigere Rechnersysteme hervor, deren Leistungsfähigkeit allerdings nur durch ein (netz-) umfassendes Management gewährleistet ist. Aufbauend auf den OSI-Prinzipien entstand das sog. „OSI Systems Management“ (siehe Kapitel 3), das ein Konzept zur einheitlichen Verwaltung aller Systemkomponenten bereitstellt.
Der Austausch von (Management-) Informationen zwischen Kommunikationssystemen setzt, wie bereits eingangs erwähnt, ein gemeinsames Protokoll voraus. Es sind also Beschreibungsmittel gefordert, die eine systemübergreifende Darstellung von Informationen bzw. Daten erlauben. Hierbei ist prinzipiell zwischen zwei formalen Notationen zu unterscheiden:
- Die „Abstract Syntax Notation One (ASN.1) “ ermöglicht es, die zwischen den einzelnen Systemen zu transferierenden Daten syntaktisch zu beschreiben (siehe Kapitel 4).
- Die „Guidelines for the Definition of Managed Objects (GDMO) “ gestatten die Charakterisierung sämtlicher Eigenschaften aller Systemkomponenten im Bezug auf das einheitliche Management (siehe Kapitel 5).
Die vier erwähnten Themengebiete bilden mitunter das Grundgerüst für einen Tracer, der bei der Siemens AG im Bereich der Softwareentwicklung von fernmeldetechnischen Vermittlungsanlagen der Produktreihe „ EWSD (Elektronisches Wählsystem Digital) “ im Einsatz ist. Tracer sind Hilfsprogramme, die einem Softwareentwickler das Auffinden von Programmfehlem erleichtern. Der in Kapitel 6 vorgestellte Softwaretracer (SWT) wird nach „außen“ unter Verwendung der ASN.1- und GDMO-Notation beschrieben. Der Austausch von Informationen zwischen Anwender und Tracer erfolgt dabei über die Q3-Mangementschnittstelle, der das OSI-Prinzip zugrunde liegt.
Die Bedienung des Tracers geschieht über Skripten - dies erscheint im Zeitalter der fensterorientierten Benutzeroberflächen nicht besonders modern. Jedoch ist unter Zuhilfenahme eines speziellen Editors die Eingabeseite des Tracers relativ gut abgedeckt. Lediglich die Ausgabeseite war bislang unbefriedigend; sie wurde aber im Rahmen dieser Diplomarbeit durch die Entwicklung einer Datenbankanwendung basierend auf Microsoft Access ’97 entscheidend verbessert. Das Programm QSTAN (Qx-Softwaretracer-Analysator) hat die Aufgabe, die Softwaretracer-Ausgaben nachträglich aufzubereiten und den Anwender bei deren Auswertung durch die Bereitstellung verschiedenster Funktionen hilfreich zu unterstützen. Eine ausführliche Programmbeschreibung ist dem Kapitel 7 zu entnehmen.
Es sei darauf hingewiesen, daß die einzelnen Themen und deren Zusammenhänge (siehe Abbildung 1) aufgrund des beschränkten Umfanges der Diplomarbeit nicht umfassend behandelt werden können. Demzufolge konzentrieren sich die Ausführungen ausschließlich auf die wesentlichsten Punkte, um zumindest ein Grundverständnis zu vermitteln. Im übrigen sind die behandelten Themen nicht nur im Hinblick auf den Softwaretracer erwähnenswert; vielmehr soll die Arbeit den interessierten Leser eine Einführung in das weitreichende Gebiet des Netz- und Systemmanagements bieten.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Zusammenhänge zwischen den behandelten Themen
2 Open System Interconnection (OSI)
2.1 Begriffsbestimmung
Mit zunehmender Notwendigkeit der Vernetzung von Rechnersystemen entstanden seit den 50er Jahren verschiedene Netzarchitekturen, die jeweils für eine bestimmte Aufgabe konzipiert bzw. optimiert wurden. Sie haben eine Gliederung in Kommunikationsschichten gemeinsam, die allerdings unterschiedlicher Struktur sind. Internationale Normungsgremien (ISO, ITU-T[1] ) erkannten die Problematik der Inkompatibilitäten und strebten daher eine Harmonisierung des Datenaustausches zwischen Rechnersystemen an.
Ergebnis des Normungsprozesses war das OSI-Referenzmodell (auch OSI-Schichtenmodell genannt), das ausdrücklich nicht die innere Funktionsweise eines einzelnen realen, offenen Systems, sondern nur dessen Verhalten an seinen Systemgrenzen definiert. OSI beschäftigt sich also nur mit der Zusammenarbeit von offenen Systemen, um eine gemeinsame (auch verteilte) Aufgabe zu erfüllen, wobei die Art der Implementierung nicht explizit vorgeschrieben wird.
Der an sich positive Begriff „offen“ wird oft in Zusammenhang mit firmenspezifischen, sog. proprietären Lösungen gebracht und somit verzerrt, wenn nicht gar mißbraucht. Zudem existieren in der Systemtheorie diverse Definitionen, nach denen alle Systeme mit mindestens einer Beziehung zu ihrer Umgebung als offene Systeme bezeichnet werden. Durch die verschiedenartige Auslegung des Begriffes „offen“ kommt es daher nicht selten zu Mißverständnissen. Deshalb sei an dieser Stelle die dreistufige Definition eines offenen Systems nach ISO-Norm 7498 (entspr. ITU-T Empfehlung X.200) gegeben[2]:
„Ein reales System ist eine Menge von einem oder mehreren Computern, der dazugehörigen Software, Ein-/Ausgabegeräte, Terminals, menschlichen Bedienungskräften, physikalischen Prozessen, Mitteln zum Informationstransfer usw., womit ein autonomes System gebildet wird, das Informationsverarbeitung und/oder Informationstransfer ermöglicht. Ein reales, offenes System ist ein reales System, das sich bezüglich der Kommunikation mit anderen realen Systemen konform zu ISO 7498 verhält. Ein offenes System ist die Darstellung eines realen, offenen Systems im OSI- Referenzmodell in Übereinstimmung mit ISO 7498.“
2.2 OSI-Architektur
Konzepte einer logischen Netzstruktur werden in Kommunikationsarchitekturen beschrieben, die allgemein Kommunikationsvorgänge modellieren, funktionelle Zerlegungen solcher Vorgänge vorschlagen und als Basis für Protokollfestlegungen dienen. Protokolle beschreiben Konventionen eines geregelten Informationsaustausches für einen bestimmten Kommunikationsdienst. Das für das OSI-Referenzmodell angewandte Strukturierungsprinzip ist das der Schnittbildung (Abbildung 2).
- Die Bestimmung diskreter Systeme, zwischen denen kommuniziert wird, geschieht mittels Systemschnitt. Dieser liefert dabei die Unterscheidung zwischen Endsystem, Transitsystem und Übertragungsmedium.
- Die Anwendung des Dienstschnittes führt zur Zerlegung von Kommunikationsvorgängen in funktionale Einheiten und schließlich zur Bildung von Schichten. Einander ähnliche Funktionen werden dabei einer Schicht, unabhängige Teilvorgänge verschiedenen Schichten zugeordnet. Dabei ist auf eine gewisse Flexibilität zu achten, die es erlaubt, eine Schicht ggf. mit verschiedenen Techniken (Hardware, Software) zu implementieren. Dienstschnitte definieren sog.
virtuelle Maschinen, die als Diensterbringer ihre Kommunikationsdienste den Instanzen der übergeordneten Schicht an Dienstzugangspunkten (Service Access Points, SAPs) anbieten. Die Kommunikation an den Zugangspunkten, also zwischen den Schichten innerhalb eines Systems, geschieht über Dienstprimitive (Service Primitives, SPs), deren Bedeutung zwar einheitlich festgelegt werden muß, deren Realisierung aber völlig systemspezifisch geschehen kann. Dienstschnitte ermöglichen somit eine „vertikale“ Kommunikation innerhalb eines Systems.
- Der Protokollschnitt berücksichtigt die Realisierung der Diensterbringung in getrennten Systemen und schafft so die Voraussetzungen für eine „horizontale“ Kommunikation. Die hierfür notwendigen Kommunikationsregeln und Datenformate sind in Schichtprotokollen festgelegt. Instanzen der gleichen Schicht in verschiedenen Systemen können miteinander kommunizieren, wenn sie das gleiche Schichtprotokoll verwenden und auf die gleichen Kommunikationsdienste zugreifen können. Eine Kommunikationsverbindung basiert also auf einem Protokollstapel, der von der Wahl der Dienste abhängig ist. Stimmt dieser Stapel in den kommunizierenden Systemen nicht überein, so sind entsprechende Abbildungsfunktionen erforderlich.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: OSI-Architekturmodell
2.3 OSI-Referenzmodell
Das OSI-Referenzmodell gliedert die offene Kommunikation zweier Systeme in sieben „horizontale“, aufeinander aufbauende Hauptschichten[3] (Abbildung 3), wobei jede Schicht eine bestimmte Aufgabe erfüllt. Die von den einzelnen Schichten bereitgestellten Funktionalitäten heißen Dienste (Services). Nachrichten werden im OSI-Modell nur zwischen benachbarten Schichten desselben offenen Systems bzw. innerhalb derselben Schicht zwischen verschiedenen offenen Systemen ausgetauscht. Erstere Nachrichten werden als Dienstprimitive, letztere als Protokolldateneinheiten (Protocol Data Units, PDUs) bezeichnet.
Die unteren vier Schichten des OSI-Modells stellen das Transportsystem dar; sie sind durch eine systematische bzw. funktionelle Erweiterung der Eigenschaften von Übertragungsmedien entstanden. Die Schnittstelle zwischen der vierten und der fünften Schicht grenzt das Transportsystem vom übergeordneten Anwendungssystem ab. Unterhalb der Bitübertragungsschicht befindet sich das physikalische Netz, während die eigentliche Applikation oberhalb der Anwendungsschicht zu finden ist. Transitnetze, wie z.B. das Datenkommunikationsnetz nach ITU-T X.25, basieren lediglich auf den unteren drei Schichten des Modells.
Bitübertragungsschicht (Physical Layer): Die Protokolle der ersten Schicht definieren die physikalischen, funktionalen und steuertechnischen Verfahren für die transparente Übertragung von Bitsequenzen über verschiedene Medien. Hauptaufgabe der untersten Schicht ist die Unterhaltung der elektrischen und optischen Signalverbindungen.
- Sicherungsschicht (Data Link Layer): Die zweite Kommunikationsschicht des OSI-Modells stellt, aufsetzend auf die fehlerbehaftete Bitübertragungsschicht, einen zuverlässigen Transport von Bitfolgen auf den einzelnen Teilstrecken des gesamten Übertragungsweges bereit. Der Sicherungsdienst beruht auf der Segmentierung und blockweisen Übermittlung von Benutzerdaten, versehen mit Prüfinformationen.
- Vermittlungsschicht (Network Layer): Die dritte Schicht ist zuständig für die Pfadschaltung einer logischen Verbindung in einem Netzwerk. Sie beschreibt alle Funktionen, um Daten von ihrem Entstehungsort zum Zielort (auch über unterschiedliche Netztechnologien) zu transportieren. Hierzu gehören die Wegeauswahl (Routing), die Betriebsmittelzuordnung und das Multiplexen.
- Transportschicht (Transport Layer): Auf den vermittelten Kommunikationspfaden zwischen den Endsystemen verwaltet die vierte Schicht die adressierten Anwenderverbindungen. Neben der Bereitstellung von Güteparametern (z.B. Datendurchsatz, Verzögerung etc.) führt das Transportprotokoll, unabhängig von der Anzahl der beteiligten Netze, eine Ende-zu-Ende- Fehlersicherung aus (z.B. IP-Protokoll).
- Kommunikationssteuerungsschicht (Session Layer): Die fünfte Funktionsschicht des OSI- Referenzmodells stellt als unterste anwendungsbezogene Schicht den höheren Instanzen Sprachmittel zur Eröffnung, Durchführung, Unterhaltung und Beendigung einer Verbindung zwischen Kommunikationspartnern bereit.
- Darstellungsschicht (Presentation Layer): Als sechste Schicht stellt sie Dienste zur Verfügung, die die Anwendungen befähigen, die Bedeutung der ausgetauschten Informationen zu interpretieren. Hierzu ist es notwendig, daß sich die Kommunikationspartner auf eine gemeinsame Darstellung der Daten, d.h. auf eine Transfersyntax, einigen, um systemspezifische Codierungen von Datenstrukturen in heterogenen Umgebungen übermitteln zu können.
- Anwendungsschicht (Application Layer): Die siebte und zugleich höchste hierarchische Funktionsschicht vereint alle kommunikationsrelevanten Funktionen eines Anwendungsprozesses. Sie realisiert letztendlich den Zugang der Anwendungsprozesse zur OSI-Welt.
2.4 Typische Schichtfunktionalitäten
„Protokolle sind präzise Vereinbarungen (in syntaktischer, prozeduraler und semantischer Hinsicht) über Verhaltensweisen und Formate bei der Kommunikation unter zwei entfernten Systemen des gleichen logischen Niveaus[4]
Abbildung in dieser Leseprobe nicht enthalten
Der Austausch von Dateneinheiten zwischen zwei Partnersystemen wird erst durch das Verständnis gemeinsamer Protokolle ermöglicht. Jede PDU gliedert sich generell in zwei Teile (Steuerinformation, Nutzinformation), wobei der Aufbau eines jeden Teiles schicht- bzw. dienstspezifisch ist. Dabei sind unter dem Begriff „Steuerinformation“ alle Nachrichten zu verstehen, die zwischen den gleichen Schichten verschiedener Systeme ausgetauscht und dort ausgewertet werden. Die im zweiten Teil der PDU enthaltene Nutzinformation wird unmittelbar an die nächst höhere Schicht weitergeleitet; sie kann - wie Abbildung 4 zeigt - daher selbst wiederum eine PDU darstellen.
Abbildung 4: Austausch von Protokolldateneinheiten
Abbildung in dieser Leseprobe nicht enthalten
Die Auswertung der Steuerinformationen setzt bestimmte Schichtfunktionalitäten (Dienste) voraus. Im folgenden sollen nun einige typische Funktionen schichtungebunden dargestellt werden, wobei die Auswahl dieser und ihre sprachliche Ausprägung selbstverständlich für jede Schicht verschieden ist.
- Zum Verbindungsmanagement zählen alle Elemente, die einen Verbindungsauf- und -abbau anfordern, ablehnen oder bestätigen. Grundsätzlich ist zwischen verbindungsorientierter und verbindungsloser Kommunikation zu unterscheiden. Während die verbindungsorientierte Kommunikation auf permanenten Festverbindungen oder temporären Wählverbindungen beruht, wird bei der verbindungslosen Kommunikation auf die Einrichtung von festen Ende-zu-Ende- Verbindungen verzichtet, d.h. die Dateneinheiten suchen sich selbststeuernd ihren Weg durch das Netz. Ebenso sind Funktionen für das Multiplexing und Splitting von Verbindungen hier einzuordnen.
- Schichtfunktionen zum Datentransfer haben die Aufgabe, Dateneinheiten durch Aufteilung und Zusammenfassung den Systemressourcen entsprechend anzupassen. Ferner können sie eine Empfangsbestätigung von der Partnerinstanz fordern, um eine gewünschte Dienstqualität zu garantieren.
- Dienste zur Wegewahl und Flußsteuerung beugen einer Datenüberflutung des Empfängers bzw. des Übertragungsmediums vor.
- Dienste zur Fehlererkennung und Fehlerbehandlung umfassen die Durchnummerierung von Nachrichten, die Bildung von Prüfsummen, Quittungen und Fehlerbenachrichtigungen sowie Funktionen zur Zeitüberwachung und Wiederaufsetzmechanismen. Typische Fehlerursachen sind die Verfälschung, der Verlust oder die Vertauschung von Dateneinheiten.
2.5 Schicht 7-Dienstelemente
Entsprechend den vielfältigen Anwendungsprozessen auf verteilten Systemen kann es im Sinne der Modularisierung nicht das Schicht 7-Protokoll geben. Vielmehr müssen sich die kommunizierenden Partnerinstanzen (innerhalb jeder Schicht) auf ein gemeinsames Protokoll, je nach angefordertem Dienst, einigen. Dazu benötigen sie ein bestimmtes Dienstelement (Service Element, SE), das die nötigen Funktionalitäten bereitstellt. Dienstelemente können entweder im bestätigten (confirmed) oder nicht-bestätigten (non-confirmed) Modus betrieben werden (Abbildung 5). Kriterium für die Wahl zwischen diesen zwei Modi kann beispielsweise eine geforderte Dienstgüte (Quality of Service, QoS) sein, etwa eine Empfangsbestätigung bei unsicherer Datenübertragung aufgrund qualitativ schlechter Übertragungswege.
Schicht N Schicht N-1
Dienstelemente lassen sich prinzipiell in zwei Klassen unterteilen:
- allgemeine Dienstelemente CASE (Common Application Service Element)
- spezifische Dienstelemente SASE (Specific Application Service Element)
Die allgemeinen Dienstelemente stehen generell mehreren Applikationen zur Verfügung. Beispiele für die CASE-Gruppe sind:
- ACSE (Association Control Service Element) dient dem Aufbau einer logischen Verbindung zwischen zwei Instanzen der Anwendungsebene.
- RTSE (Reliable Transfer Service Element) ermöglicht den zuverlässigen Transport einer Protokolldateneinheit innerhalb einer vorgegebenen Zeit mit entsprechender Bestätigung.
- ROSE (Remote Operations Service Element) ermöglicht das Anstoßen beliebiger Prozesse an entfernten Systemen, wobei die Art der Auftragserbringung (synchron, asynchron) und der Antwort (keine, nur im Fehlerfall, nur im Erfolgsfall, auf jeden Fall) angegeben werden kann.
Im Gegensatz dazu finden die spezifischen Dienstelemente nur für bestimmte Aufgabenbereiche Verwendung. Beispiele für die SASE-Gruppe sind:
- FTAM (File Transfer Access and Management) stellt umfangreiche Dienste zum Verwalten von Dateien auf entfernten Systemen bereit.
- CMISE (Common Management Information Service Element) stellt Dienste zum Austausch von Managementinformationen zur Verfügung (siehe Kapitel 3.4).
2.6 Protokollspezifikationssprache ASN.1
Wie bereits in Kapitel 2.3 (OSI-Referenzmodell) erwähnt wurde, besitzt die Darstellungsschicht die Aufgabe, die Daten der Anwendungsschicht so zu beschreiben, daß diese für beide Seiten verständlich sind. Die Dateneinheiten der Anwendungsschicht (in diesem Zusammenhang auch als abstrakte Datenwerte bezeichnet) sind daher vor dem Transfer in konkret übertragbare Bitfolgen umzuwandeln, und umgekehrt. Zur Bildung der abstrakten Datenwerte sind genormte Regeln, die unter dem Begriff abstrakte Syntax zusammengefaßt werden, notwendig.
Zu diesem Zweck definiert ITU-T die Protokollspezifikationssprache ASN.1 (Abstract Syntax Notation One), die als einheitliche Darstellungssyntax im OSI-Referenzmodell dient. Die Umwandlung einer beliebigen, mittels ASN.1 festgelegten abstrakten Syntax in übertragbare Bitfolgen erfolgt unter Verwendung der Basic Encoding Rules for ASN.1 (BER). Näheres zum Thema ASN.1 ist in Kapitel 4 zu finden.
3 OSI Systems Management
3.1 Überblick
Die Komplexität, Heterogenität und Verteiltheit der Rechner- und Telekommunikationsnetze nimmt heutzutage in einem immer stärkeren Maße zu. Dies bedeutet, daß die Anzahl, die Gruppierung, die Verschiedenartigkeit (funktions- bzw. herstellerspezifisch) und die Verteiltheit (ortsspezifisch und logisch) der Hardware- und Softwarekomponenten eines Netzes und deren Kombinierung immer schwerer zu handhaben sind. Zudem steigt die Nachfrage seitens der Anwender nach mehr Verarbeitungsleistung, einem vielfältigen Diensteangebot und einer zunehmenden Diensteintegration (O Breitband-ISDN).
Mit dem Management dieser Netze (Stichwort OAM: Operation, Administration and Maintenance) ist ein Mensch allein kaum noch zu betrauen, weil er dabei zu viele Bedingungen und Abhängigkeiten zu beachten hat. Aus diesem Grund beschäftigen sich seit einigen Jahren etliche Institutionen damit, einige dieser Aufgaben zu automatisieren oder ihre Durchführung mit Hilfe von Software zu erleichtern. So entstanden für kleine, begrenzte Problemfelder viele separate, zueinander nicht kompatible Lösungen.
Die Forderung nach einem integrierten Netzmanagement veranlaßte die ISO, aufbauend auf dem OSI- Referenzmodell, ein Konzept zur einheitlichen Verwaltung von Systemressourcen zu entwickeln. Das OSI Systems Management wird durch die Definition von vier Teilmodellen festgelegt (Abbildung 6), die jeweils einen bestimmten Managementaspekt behandeln:
- Das Informationsmoden benutzt konsequent einen objektorientierten Ansatz zur Beschreibung von managementrelevanten Ressourcen. Ferner wird eine Informationsbasis definiert, die als „Aufbewahrungsort“ der Ressourcenbeschreibungen angesehen werden kann (siehe Kapitel 3.2).
- Das Organisationsmodell geht grundsätzlich von einem verteilten kooperativen Management in einem Netz offener Systeme aus. Es werden Rollen (Manager, Agent) unterschieden, wobei ein System verschiedene Rollen im Hinblick auf bestimmte Ressourcen einnehmen kann. Die Festlegung eines Domänenkonzeptes ermöglicht das Gruppieren von Ressourcen aus ablauf- und aufbauorganisatorischen Gründen (siehe Kapitel 3.3).
- Das Kommunikationsmodell basiert auf dem OSI-Referenzmodell und beschreibt die zur Übermittlung von Managementinformationen zwischen verteilten Anwendungsprozessen notwendigen Dienstelemente und Schichtprotokolle (siehe Kapitel 3.4).
- Das Funktionsmodell teilt den Gesamtmanagementkomplex in fünf Funktionsbereiche (Configuration, Fault, Performance, Accounting, Security) auf und beschäftigt sich mit der Ableitung generischer Managementfunktionen (siehe Kapitel 3.5).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: Teilmodelle des OSI Systems Management
3.2 Informationsmodell
Dem OSI Systems Management liegt eine objektorientierte Betrachtungsweise zugrunde. Objekte sind, ganz allgemein, die Abstraktion eines physikalischen oder logischen Gegenstandes. Im Zusammenhang mit dem OSI Systems Management stellt ein Managementobjekt (Managed Object) die abstrakte Sicht einer realen Ressource dar, also ein zu verwaltendes, zu überwachendes oder zu steuerndes Betriebsmittel. Jedes Managementobjekt wird spezifiziert durch
- seine Attribute, die die Eigenschaften und den Status eines Managementobjektes charakterisieren.
- die an ihm durchführbaren Operationen, die entweder das gesamte Managed Object oder nur auf die Attribute des Managed Objects anwendbar sind.
- die von ihm ausgehenden Meldungen (Notifications), die entweder durch Ausführen einer Operation oder auch selbständig (asynchron) ausgelöst werden können.
- sein Verhalten (Behaviour), d.h. eine Beschreibung des Managed Objects in Textform, die allerdings keinen Einfluß auf die realisierten Abläufe hat.
Per Definition ist ein Objekt eine gekapselte Datenstruktur, die an ihrer Schnittstelle Methodenaufrufe zur Datenmanipulation bereit stellt. Die Attribute und das Verhalten werden nur durch die am Objekt ausgeführten Operationen und den von ihm ausgehenden Meldungen erfaßt. Im übertragenen Sinne kann ein Managementobjekt als „Black-Box“ betrachtet werden, die das innere Verhalten einer realen physikalischen Ressource nur an definierten Interaktionsstellen sichtbar werden läßt (Abbildung 7).
Die oben genannte Beschreibung von Managementobjekten ist zwar verschieden von den eigentlichen Kommunikationseigenschaften einer realen Ressource (schließlich sind nur die managementrelevanten Aspekte zu betrachten), steht aber in Beziehung zu ihnen. Abbildung 8 gibt einige Beispiele für die Ausprägungen von Managementobjekten.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 8: Beziehungen zwischen Managementobjekten und physikal. Ressourcen
Objektorientiertheit bedeutet die Bereitstellung von Vererbungsmechanismen, d.h. alle Eigenschaften eines Managementobjektes einer Oberklasse (Superclass) werden automatisch auf ein Managementobjekt einer Unterklasse (Subclass) übertragen[5] [6] - dies wird auch als strikte Vererbung bezeichnet. Die geerbten Eigenschaften können abgeändert oder auch erweitert werden. Mit zunehmender Tiefe der Vererbung erfolgt daher i.a. eine immer feinere und exaktere Beschreibung der Objekteigenschaften. Weiterhin besteht die Möglichkeit der multiplen Vererbung, d.h. eine Unterklasse erbt die Eigenschaften mehrerer Oberklassen. Von Allomorphie wird gesprochen, wenn ein Objekt als Instantiierung mehrerer Klassen behandelt werden kann. Die Abhängigkeiten der Objektklassen untereinander können zumeist graphisch in einem Vererbungsbaum dargestellt werden (Abbildung 9).
Abbildung in dieser Leseprobe nicht enthalten
Ein Objekt der Klasse K2.1 kann sich, falls das Allomorphiekonzept unterstützt wird, nach Aufforderung wie ein Objekt der Klasse K1.1 verhalten. Objekte der Klasse K2.1 können dann von ManagementSystemen unterstützt werden, die die Klasse K2.1 nicht kennen, sondern nur die Klasse K1.1.
Abbildung 9: Vererbungshierarchie
Abbildung in dieser Leseprobe nicht enthalten
Der objektorientierte Ansatz zur Beschreibung der managementrelevanten Ressourcen garantiert die Erweiterbarkeit und Wiederverwendbarkeit von einmal definierten Managementobjekten. Eine solche Möglichkeit erleichtert die Integration unterschiedlicher Technologien, wenn diese aus der Sicht des Managements ähnliche Eigenschaften haben. Aus diesem Grund werden generische - also basisorientierte - Objektklassen mit Hilfe einer einheitlichen Beschreibungssprache, deren Syntax in den „Guidelines for the Definition of Managed Objects (GDMO) “ festgelegt ist, definiert und in einer (standardisierten) Bibliothek zusammengefaßt (siehe Kapitel 5).
Das Herzstück jeder Managementarchitektur bildet die Managementinformationsbasis (MIB). Sie wird als der „konzeptionelle Aufbewahrungsort von Managementinformationen“ [2] bezeichnet. Darunter ist nicht unbedingt eine reale Datenbank zu verstehen. Vielmehr ist die MIB als ein theoretisches Gebilde aufzufassen, das die Managementobjekte in Form einer Beinhaltungshierarchie (Management Information Tree, MIT) darstellt.
Die Beinhaltungshierarchie spiegelt die Tatsache wider, daß reale Ressourcen aus der Sicht des Managements nicht zwangsläufig elementar sein müssen, sondern auch zusammengesetzt sein können. Eine reale Ressource kann also nur dann Einsatz finden, wenn die übergeordnete Ressource vorhanden ist. Oder: Die Existenz eines untergeordneten (subordinate) Managementobjektes ist unmittelbar von der Existenz des übergeordneten (superior) Managementobjektes abhängig. Abbildung 10 verdeutlicht dies anhand eines hypothetischen Netzwerkes.
Beachte: Die Vererbungshierarchie stellt die Beziehungen zwischen den Objektklassen dar, die Beinhaltungshierarchie dagegen zeigt die Abhängigkeiten der Objektinstanzen. Beide Darstellungen sind also voneinander vollkommen unabhängig!
3.3 Organisationsmodell
Bereits bei kleinen Kommunikationsanlagen kann die Anzahl der Managementobjekte je nach Managementtiefe beträchtlich sein. Daher sieht das OSI-Organisationsmodell eine Verteilung der Managementaufgaben auf zwei Systeme vor:
- Das Managing Open System übernimmt die Rolle des Managers.
- Das Managed Open System übernimmt die Rolle des Agenten.
Der Manager veranlaßt Managementoperationen und empfängt Meldungen, die für ihn relevante Informationen enthalten. Dagegen führt der Agent die vom Manager beauftragten Operationen an den Managementobjekten aus (Vermittlerfunktion) und leitet die zurückkommenden Meldungen an ihn weiter (Filterfunktion). Hieraus ist ersichtlich, daß der Manager selbst keinen direkten Zugriff auf die Managementobjekte hat, sondern stets den Agenten bemühen muß. Dies erscheint vielleicht etwas umständlich, hat aber wesentliche Vorteile, denn der Manager wird durch einen oder mehrere Agenten sowie durch weitere Manager mit anderen Aufgaben entlastet. Auf diese Weise können Managementeinheiten (Domänen) mit optimierter Struktur und speziellen Aufgaben gebildet werden. Der Manager stellt das aktive System dar, während der Agent durchaus auch passiv sein kann. Diese Rollenverteilung muß nicht für immer, jedoch für die aktuelle Managementaktivität fix sein. Abbildung 11 faßt dies nochmals zusammen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 11: Manager und Agent
Um Managementoperationen an den Managementobjekten zu veranlassen (Manager zu Agent) und um Meldungen betreffend dieser überhaupt weiterleiten zu können (Agent zu Manager), müssen beide Partner in der Lage sein, ein Managementobjekt eindeutig zu identifizieren. Hierzu ist ein gemeinsames Managementwissen (SharedManagement Knowledge, SMK) erforderlich; ITU-T legt in ihrer Empfehlung M.3010 für das Telecommunication Management Network (TMN) ein gemeinsames Verständnis mindestens der folgenden Informationen fest:
- unterstützte Protokolle
- unterstützte Managementfunktionen
- unterstützte Managementobjektklassen
- verfügbare Managementobjektinstanzen
- autorisierte Fähigkeiten (d.h. erlaubte Managementfunktionen)
- Beziehungen zwischen den Managementobjekten
Das SMK kann entweder bei der Systemkonfiguration oder bei der ersten Kontaktaufnahme zwischen Manager und Agent aufgebaut und während der Verbindungsdauer laufend aktualisiert werden. Abbildung 12 ergibt sich als geeignete Darstellung für den Begriff SMK.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 12: Shared Management Knowledge (SMK)
Unter dem Begriff Domäne wird eine Gruppenbildung von Ressourcen (besser: Managementobjekten) aus funktionalen, geographischen, technologischen oder organisatorischen Gründen verstanden. Eine Überlappung von Domänen ist prinzipiell erlaubt. Insbesondere ist bei den mehrfach verwalteten Managementobjekten auf die Anwendung widerspruchsfreier Managementverfahren (Management Policies)[7] zu achten. Domänen sind selbst Gegenstand von Managemententscheidungen und können so wiederum als Managementobjekte angesehen werden. Im OSI-Organisationsmodell wird zwischen Organisationsdomänen und Verwaltungsdomänen unterschieden (Abbildung 13).
Organisationsdomänen sind Zusammenfassungen von Managementobjekten
- nach funktionalen Gesichtspunkten (z.B. Sicherheitsmanagement, Fehlermanagement etc.);
- innerhalb eines Funktionsbereiches, um ein gemeinsames Managementverfahren besser anwenden zu können.
In Verwaltungsdomänen unterstehen Managementobjekte genau einer Verwaltungsautorität; sie werden daher benötigt, um
- Organisationsdomänen einrichten und manipulieren zu können;
- den Steuerfluß zwischen Organisationsdomänen, die sich u.U. auch überschneiden können, zu kontrollieren.
Abbildung in dieser Leseprobe nicht enthalten
3.4 Kommunikationsmodell
Um betriebszielorientiert reale Ressourcen kontrollieren und steuern zu können, müssen zwischen den kooperierenden Systemen Managementinformationen ausgetauscht werden. Hierzu sieht das OSI- Kommunikationsmodell drei verschiedene Managementkategorien vor:
- Das schichtübergreifende Management (Systems Management) ist für den Informationsaustausch zwischen Managementanwendungsprozessen der OSI-Schicht 7 zuständig und damit auch für den Zugriff auf alle relevanten Kommunikationsressourcen.
- Das Schichtenmanagement (n-Layer Management) stellt eine Menge von Funktionen bereit, die die Integrität der Schichtenprotokolle gewährleisten (z.B. Test der nächst niedrigeren Schicht). Damit dient es der Überwachung und Steuerung der jeweiligen Schicht. Kommunikationspartner sind schichtspezifische Managementinstanzen (Layer Management Entities, LMEs), die über das entsprechende Schichtenprotokoll miteinander in Verbindung stehen.
- Das Protokollmanagement (n-Layer Operation) ist zuständig für die Überwachung eines einzelnen Kommunikationsvorganges. Informationen, die dabei von Bedeutung sind, betreffen entweder den Vorgang selbst (z.B. Parameter für den Verbindungsaufbau) oder die durch ihn verursachten Änderungen (z.B. Veränderung der Menge des zur Verfügung stehenden Speicherplatzes).
Das schichtübergreifende Management soll in den folgenden Absätzen etwas näher betrachtet werden:
Der Austausch von Managementinformationen, der zwischen den Anwendungsprozessen über die Schicht 7 abgewickelt wird, basiert auf einer Reihe von Dienstelementen. Das System Management Application Service Element (SMASE) stellt eine Vielzahl von Managementfunktionen bereit und bildet zugleich die Schnittstelle zu den Anwendungsprozessen. Es stützt sich selbst auf dem Common Management Information Service Element (CMISE) und dem zugehörigen Common Management Information Protocol (CMIP) ab, die den Zugriff auf und die Manipulation von Managementobjekten ermöglichen.
Auch das CMISE benötigt für die eigene Funktionalität zwei weitere Dienstelemente. Erstens, das Association Control Service Element (ACSE) zur Verbindungsverwaltung, und zweitens, das Remote Operations Service Element (ROSE) zur Durchführung von Managementoperationen auf entfernten Systemen. Abbildung 14 zeigt die Einbettung der Dienstelemente in die Anwendungsschicht.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 14: OSI-Kommunikationsmodell
Das CMISE verfügt mit den „Durchreichdiensten“ des ACSEs über insgesamt zehn Dienste, die sich in drei Gruppen einteilen lassen:
- Assoziationsverwaltung (unmittelbare Abbildung auf ACSE-Dienste):
- A-ASSOCIATE: Anforderung zum Verbindungsaufbau
- A-RELEASE: Anforderung zum Verbindungsabbau
- A-ABORT: Anforderung zum sofortigen Abbruch der Verbindung
Management Operationsdienste (Manager zu Agent):
Anforderung von Managementinformationen Modifikation von Managementinformationen Ausführung einer Managementoperation Erstellung eines Managementobjektes Löschung eines Managementobjektes
Rücknahme einer angeforderten, jedoch noch nicht ausgegebenen Managementinformation · Management Benachrichtigungsdienste (Agent zu Manager):
- M-EVENT-REPORT: Übertragung einer MO-Notification
Jede Dienstanforderung erfolgt, wie Tabelle 1 zeigt, mit der Übergabe einer bestimmten Anzahl von Parametern. Es wird zwischen Parametern unterschieden, die zwingend vorgeschrieben sind (M), wahlweise vom Anwender (U) oder nur unter gewissen Umständen (C) zu besetzen sind. Einige der unten aufgelisteten Parameter werden im Verlauf dieser Arbeit noch näher zu erläutern sein, die restlichen sind hier nur der Vollständigkeit halber aufgeführt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1 : CMISE-Dienste und ihre Parameter
Interessant ist das Verfahren zur Auswahl von Managementobjekten aus dem bereits in Kapitel 3.2 angesprochenen Managementinformationsbaum (MIT) der MIB, das als „Scoping and Filtering“ bezeichnet wird:
Managementobjekte werden anhand ihres Namens und ihrer zugehörigen Klasse eindeutig identifiziert. Das CMISE ermöglicht nun für bestimmte Dienste (z.B. M-GET) eine Menge von Managementobjekten als Teilbaum mit bestimmter Tiefe zu spezifizieren (Scoping). Als Ausgangspunkt für die Scoping-Selektion dient das Base Object. Zusätzlich wird mit Hilfe des Scope- Parameters eine Lokalisierung in der Objekthierarchie vorgenommen (Abbildung 15a). Mögliche Parameterbelegungen sind:
- nur Basisobjekt
- n-te Ebene unterhalb Basisobjekt
- Basisobjekt und alle untergeordneten Objekte bis zur n-ten Ebene
- Basisobjekt und vollständig nachgeordneter Teilbaum
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 15: (a) Scoping, (b) Filtering
Über den Filter-Parameter lassen sich schließlich aus dieser Menge einzelne Objekte auswählen (Filtering). Ein Filter besteht aus einer oder mehreren Aussagen über die Anwesenheit oder Wertebelegung von MO-Attributen; er dient demnach der attributbezogenen Objektselektion (Abbildung 15b).
Durch das „Scoping and Filtering“ wird eine Auswahl mehrerer Managementobjekte ermöglicht, d.h. eine Anfrage des Managers hat mehrere Rückantworten (entsprechend der Anzahl der ausgewählten Objekte) durch den Agenten zur Folge. Der Manager muß dabei nicht das Eintreffen aller Antworten abwarten, er kann zwischenzeitlich auch neue Dienstaufrufe starten. Aufgrund der asynchronen Arbeitsweise der CMISE-Dienste ist eine nachträgliche Zuordnung der Rückmeldungen zum auslösenden Prozeß notwendig. Jeder Dienstaufruf benötigt daher einen eindeutigen Identifizierer, den Invoke Identifier, auf den sich die Antworten, über den Linked Identifier, beziehen können. Das Prinzip des sog. Multiple Linked Replies zeigt Abbildung 16.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 16: Multiple Linked Replies
3.5 Funktionsmodell
Managementaufgaben zum Betrieb von Kommunikationsnetzen sind vielseitiger Art und können daher Funktionsbereichen (System Management Functional Areas, SMFAs) zugeordnet werden. ISO schlägt eine Einteilung in fünf Kategorien vor:
- Das Konfigurationsmanagement (Configuration Management) ist verantwortlich für die Anpassung und Verknüpfung von Ressourcen zur Erbringung von Kommunikationsleistungen. Die einzelnen Teilaufgaben gliedern sich in:
- Definieren und Benennen von Betriebsmitteln (Managementobjekten)
- Initialisieren und Löschen von Managementobjekten
- Einstellen und Ändern der Attribute von Managementobjekten
- Sammeln von Zustandsdaten
- Sichern des Normalbetriebs
- Das Fehlermanagement (Fault Management) hat die Verfügbarkeit eines Kommunikationsnetzes möglichst hoch zu halten. Aus dieser Zielvorgabe ergeben sich folgende komplexe Teilaufgaben:
- Überwachen des Netz- und Systemzustands
- Entgegennehmen und Verarbeiten von Alarmen
- Diagnostizieren von Fehlerursachen
- Feststellen von Fehlerfortpflanzungen
- Einleiten und Überprüfen von Fehlerbehebungsmaßnahmen
- Fehlerdokumentation
- Leisten von Hilfestellungen für den Benutzer
- Das Leistungsmanagement (Performance Management) ist verantwortlich für die Einhaltung der gewählten Dienstgüte und der damit verbundenen Effizienz von Kommunikationsaktivitäten. Als Teilaufgaben sind zu nennen:
- Bestimmen von Dienstgüteparametern
- Erkennen von Leistungsengpässen
- Durchführen von Verkehrsmessungen
- Durchführen von Leistungs- und Kapazitätsplanungen
- Aufbereiten von Meßdaten und Verfassen von Berichten
- Das Abrechnungsmanagement (Accounting Management) hat die Aufgabe, die Inanspruchnahme von Kommunikationsdiensten sowie Ressourcen zu überwachen und die anfallenden Kosten dem Verursacher in Rechnung zu stellen. Damit sind folgende Teilaufgaben verbunden:
- Erfassen von Verbrauchsdaten
- Führen von Abrechnungskonten
- Führen von Verbrauchsstatistiken
- Verteilen und Überwachen von Kontingenten
- Das Sicherheitsmanagement (Security Management) gelangt überall dort zum Einsatz, wo sensible Informationen ausgetauscht werden (Bankwesen, Militär etc.). Es beinhaltet nachfolgende Teilaufgaben:
- Erkennen von Sicherheitsangriffen
- Verschlüsseln von Informationen
- Durchführen von Authentifizierungen
Durch die Einteilung der Managementaufgaben in Teilbereiche wird eine modulare Entwicklung von Managementfunktionen (System Management Functions, SMFs) ermöglicht. Allerdings ist die Abgrenzung der Funktionsbereiche nicht ganz unproblematisch, da verschiedene Wechselwirkungen (z.B. Aufrufketten) zwischen ihnen denkbar sind. Dies zeigt sich auch daran, daß nicht jede Managementfunktion eindeutig einem Funktionsbereich zugeordnet werden kann.
Die SMFs bilden zusammen das System Management Application Service Element (SMASE), das in die Schicht 7 des OSI-Referenzmodells eingebettet ist. Zur Erfüllung ihrer Aufgaben nehmen sie die Dienste des CMISE in Anspruch (Abbildung 14 und Abbildung 17).
Abbildung in dieser Leseprobe nicht enthalten
ITU-T beschreibt in ihren Empfehlungen X.730 ff. eine Reihe generischer, zum Teil auch komplexer
Funktionen, von denen hier nachfolgend zwei vorgestellt werden sollen:
- Event Report Management Function: Die von Managementobjekten ausgehenden Meldungen werden von einem lokalen Erkennungs- und Verarbeitungsmechanismus (Event Preprocessing) entgegengenommen, zu einem potentiellen Ereignisbericht zusammengestellt und anschließend an einen Filterprozeß (Event Forwarding Discriminator, EFD) weitergereicht. Dieser übernimmt dann die Entscheidung über die Berichtsweiterleitung, z.B. zu unterschiedlichen Terminals (Abbildung 18).
- Log Control Function: Ihre Arbeitsweise ist ähnlich der vorgenannten Event Report Management Function. Im Unterschied dazu werden neben den Ereignismeldungen auch alle Dateneinheiten (PDUs) ausgewertet, die ein lokales System empfängt oder verschickt. Außerdem erfolgt keine sofortige Weiterleitung der gefilterten Informationen, sondern eine Zwischenspeicherung in sog. Logs. Diese Logs können bei Bedarf ausgelesen und z.B. als Datei auf einem Datenträger gesichert werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 18: Event Report Management Function
3.6 Offene Punkte
Standardschriften bieten oft nur konzeptionelle Ideen an. Wie diese jedoch umgesetzt werden können, wird nicht festgelegt. So sind durch das OSI Systems Management bei weitem nicht alle Probleme, die in diesem Themenbereich existieren, erkannt und gelöst worden. Zu ihnen zählen u.a.:
- Ressourcen, die keinem oder einem anderen Standard entsprechen, können z.B. über ein Gateway an ein OSI-Netz angebunden werden. Dies führt aber in der Regel zu Einbußen sowohl bei der Kommunikations- als auch bei der Managementfunktionalität. Ursache dafür sind unterschiedliche Mengen von Funktionen, die über das Gateway aufeinander abgebildet werden müssen.
- Das OSI-Organisationsmodell - es kann insgesamt als unbefriedigend angesehen werden - legt zwar einerseits Rollen (Manager, Agent) zur Abwicklung der Managementaufgaben fest, läßt aber andererseits die Realisierungsmöglichkeiten und damit auch die notwendigen Schnittstellen zu den realen Ressourcen (Netzkomponenten) bzw. zum Anwender vollkommen offen. Ebenso wird ein „gemeinsames Managementwissen“ eingeführt, ohne dessen Inhalt genau zu spezifizieren.
- Eine exakte Definition des Begriffes „Managementpolicy“ liegt, obwohl in einigen Standards verwendet, nicht vor. Um zukünftig differierende Interpretationen zu vermeiden, ist zunächst eine genaue Begriffserklärung vorzunehmen und anschließend der Zusammenhang zu den managenden Einheiten festzulegen.
4 Abstract Syntax Notation One (ASN.1)
4.1 Begriffsbestimmung
„Eine abstrakte Syntaxnotation ist ein von der Zielumgebung unabhängiges Beschreibungsmittel, mit dem ausgedrückt werden kann, wie aus einzelnen Daten(elementen) in korrekter Art und Weise komplexere Datenstrukturen und Informationsgebilde aufgebaut werden können[8]
ASN.1 wurde im Rahmen des OSI-Referenzmodells zur systemübergreifenden Beschreibung von Daten und Informationen entwickelt. Daher wird sie häufig auch als rein „kommunikationsbezogen“ bewertet. Dies ist jedoch nicht zutreffend, da ihre Anwendung prinzipiell in den unterschiedlichsten Bereichen der Datenverarbeitung denkbar ist. ASN.1 ist aber keine Programmiersprache im herkömmlichen Sinn, denn es fehlen Sprachelemente, die Operationen auf und mit den definierten Datenstrukturen ermöglichen.
Die konkrete Darstellung von Daten in einem elektronischen System wird von einem allgemeinen Beschreibungsmittel wie ASN.1 nicht festgelegt. Hierzu ist eine Übersetzungsvorschrift notwendig, die die Codierung bzw. Decodierung einheitlich und plattformübergreifend festlegt; diese Aufgabe erfüllen die Basic Encoding Rules for ASN.1 (BER).
Hinweis: Den Ausführungen dieses Abschnitts liegen die ITU-T Empfehlungen X.208 (ASN.1) und X.209 (BER) aus dem Jahre 1993 zugrunde. Die Neuerungen im Sprachumfang durch X.680 ff. bzw. in den Codiervorschriften durch X.690 ff. berühren jedoch nicht das Grundverständnis der ASN.1- Notation.
4.2 Datentypen
ASN.1 kennt - wie auch andere Programmiersprachen - eine Reihe von vordefinierten Datentypen, die sog. Built-in Types. Sie lassen sich nach Tabelle 2 in vier Gruppen einteilen:
- Die einfachen Datentypen bilden das Grundgerüst der Protokollspezifikationssprache, mit deren Hilfe sich Untertypen durch Einschränkung des Wertebereiches oder komplexe Datenstrukturen konstruieren lassen.
- Die Strukturtypen ermöglichen das Zusammenfassen mehrerer (unterschiedlicher) Datentypen zu einer Datenstruktur. Wahlweise können die einzelnen Komponenten einfache Datentypen oder selbst strukturierte Datentypen sein. Folgende Strukturierungsprinzipien sind zu nennen:
- Bildung von Strukturen aus einer Folge mehrerer Komponenten verschiedener (SEQUENCE) oder gleicher (SEQUENCE OF) Typen, wobei die Reihenfolge der Komponenten relevant ist. In der Sprache C vergleichbar mit dem Strukturtyp »struct«.
- Bildung von Strukturen aus einer Folge mehrerer Komponenten verschiedener (SET) oder gleicher (SET OF) Typen, wobei die Reihenfolge der Komponenten nicht relevant ist.
- Auswahl zwischen mehreren Komponenten verschiedenen oder gleichen Typs (CHOICE). In der Sprache C vergleichbar mit dem Vereinigungstyp »union«.
- Die acht vordefinierten String-Typen unterscheiden sich in den verwendbaren Zeichensätzen. Lediglich die Typen »NumericString« und »PrintableString« können als Teil der ASN.1-Norm angesehen werden; alle weiteren sind Gegenstand anderer Standardschriften (z.B. ISO 2375).
Abbildung in dieser Leseprobe nicht enthalten
- Die als „nützlich “ bezeichneten Datentypen sind von elementaren Build-in Typen abgeleitet. Sie wurden zur internationalen Harmonisierung bestimmter, in vielen Protokollspezifikationen immer wieder vorkommender Typdefinitionen eingeführt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2: Built-in Types
4.3 Syntaxregeln
ASN. 1-Definitionen können formatfrei geschrieben werden, das heißt, daß sie keine bestimmte Zeilenstruktur haben müssen. Das Leerzeichen, das Zeilenende und ein Benutzerkommentar werden (außerhalb von Zeichenfolgen) als Trennzeichen angesehen, durch die die einzelnen Grundelemente der Sprache getrennt werden. Folgen mehrere Trennzeichen aufeinander, so werden diese wie ein logisches Trennzeichen angesehen.
Folgende Zeichen sind in ASN.1-Definitionen zulässig (ASN.1-Zeichensatz):
Abbildung in dieser Leseprobe nicht enthalten
Leerzeichen und Zeilenendezeichen
Zwischen Groß- und Kleinschreibung wird generell unterschieden. In Kommentaren und Strings können abweichend vom ASN.1-Zeichensatz weitere Zeichen verwendet werden.
Eine ASN.1-Zeichenfolge kann nachstehende Bedeutung haben:
- Typ- und Modulbezeichner sind beliebige Zeichenfolgen aus Buchstaben, Ziffern und Bindestrichen, beginnend mit einem Großbuchstaben. Zwei aufeinanderfolgende Bindestriche sind nicht zulässig, da es zu Konflikten mit dem Beginn eines Kommentars kommen kann.
- Wertbezeichner unterliegen den Syntaxregeln der Typbezeichner, allerdings beginnen diese mit einem Kleinbuchstaben.
- Kommentare beginnen mit der Aufeinanderfolge zweier Trennungszeichen »--« und enden mit der erneuten Angabe dieser Zeichenfolge, spätestens jedoch am Ende einer Zeile.
- Schlüsselwörter sind Bestandteil der Sprachdefinition, sie sind durchgängig in Großbuchstaben geschrieben. Gleichlautende Typ- oder Modulbezeichner sind daher unzulässig.
- Wertzuweisungen und Typdefinitionen werden mit dem Zuweisungsoperator »::=« formuliert, z.B.:
Abbildung in dieser Leseprobe nicht enthalten
- Binäre und hexadezimale Zeichenfolgen werden durch Apostrophe begrenzt. Ein anschließendes »B« (für binär) oder »H« (für hexadezimal) kennzeichnet dabei die Basis der Zeichenfolge, z.B.:
Abbildung in dieser Leseprobe nicht enthalten
- Strings werden mit Anführungszeichen begrenzt; der zugrundeliegende Stringtyp bestimmt dabei den zulässigen Zeichensatz.
- Dezimalzahlen dürfen einen positiven oder negativen Wert besitzen, führende Nullen sind nicht zulässig.
- Typ- und Wertnotationen von Strukturen und Aufzählungen werden durch geschweifte Klammern begrenzt, z.B.:
Abbildung in dieser Leseprobe nicht enthalten
- Typkennzeichen (Tags) werden durch eckige Klammern begrenzt (siehe Kapitel 4.4).
Wertebereichsbeschränkungen bei der Bildung von Untertypen sind zwischen runden Klammern einzuschließen (siehe Kapitel 4.5).
4.4 Tags
Zur eindeutigen Interpretation eines BER-codierten Datenwertes muß der zugehörige Datentyp bekannt sein. Jeder ASN.1-Typ besitzt daher ein Kennzeichen, das sog. Tag, das fixer Bestandteil bei der Codierung eines Datenwertes ist. Dadurch ist der Decoder in der Lage, den zugehörigen Datentyp zu erkennen und den Datenwert richtig zu interpretieren. Das Tag eines (benutzerdefinierten) Typs ist entweder durch den ASN. 1-Standard festgelegt oder wird vom Anwender der Notation selbst vergeben.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3: UNIVERSAL-Tags
Tags bestehen aus einer Tag-Klasse und einer Tag-Nummer innerhalb dieser Klasse. Die Klasse - der
ASN.l-Standard definiert vier davon - gibt Auskunft darüber, wie die Nummer vergeben wurde:
- Die Tag-Klasse UNIVERSAL ist für Build-in Datentypen des ASN. 1-Standards reserviert (siehe Tabelle 3).
- Tags der Klasse APPLICATION werden durch andere Standards festgelegt; sie müssen innerhalb eines ASN.1-Moduls eindeutig sein.
- Die Klasse PRIVATE ermöglicht eine benutzer- bzw. unternehmensspezifische Vergabe von Tags innerhalb eines Standards.
- Kontextspezifische Tags kommen überall dort zum Einsatz, wo ein eindeutiger Zusammenhang zwischen Datenwert und Datentyp - trotz Verwendung eines Tags einer anderen Klasse - durch den Decoder nicht gewährleistet ist. Dies kann bei Datenstrukturen der Fall sein, die optionale Komponenten beinhalten oder deren Komponentenreihenfolge nicht relevant ist (SET-Typ), z.B.:
Abbildung in dieser Leseprobe nicht enthalten
Obige Anweisung definiert den Typ »Complex«, im Gegensatz zum Beispiel aus Kapitel 4.3, als SET-Struktur. Bei der Datenübertragung ist also keine feste Reihenfolge vorgeschrieben, d.h. es bleibt offen, ob zuerst die reale oder imaginäre Komponente übermittelt wird. Der Decoder benötigt daher je Komponente zur eindeutigen Zuordnung ein Tag, die im Wert unterschiedlich sein müssen. Dies ist hier allerdings nicht gegeben, da beide Komponenten den gleichen Datentyp (und so auch das gleiche Tag) besitzen. Demnach müssen als Unterscheidungsmerkmal kontextspezifische Tags mit in die Strukturdefinition aufgenommen werden, z.B.:
Abbildung in dieser Leseprobe nicht enthalten
Tags werden in ASN.1-Modulen als Kombination von Tag-Klasse und Tag-Nummer zwischen eckigen Klammern eingeschlossen. Fehlt die Angabe der Tag-Klasse, so gilt das Tag als kontextspezifisch. Alle anderen Klassen hingegen müssen durch das entsprechende Schlüsselwort gekennzeichnet werden.
Die zur Codierung bzw. Decodierung nötige Typkennzeichnung kann auf zwei unterschiedliche Arten erfolgen:
- IMPLICIT: Das Tag des zugrundeliegenden Datentyps wird bei der Codierung nicht berücksichtigt. Im allgemeinen erfolgt dadurch eine Verkürzung der zu übertragenden Bitfolge. Die implizite Typkennzeichnung sollte immer dann Verwendung finden, wenn dieses Tag bedeutungslos geworden ist und durch ein anderes ersetzt werden muß, z.B.:
Abbildung in dieser Leseprobe nicht enthalten
- EXPLICIT: Das Tag des zugrundeliegenden Datentyps wird bei der Codierung berücksichtigt und in die zu übertragende Bitfolge aufgenommen. Fehlt die Angabe über die Art der Typkennzeichnung, so gilt EXPLICIT als Voreinstellung, falls nicht ausdrücklich über die Moduldefinition etwas anderes vereinbart wurde.
4.5 Untertypen
Für einige Built-in Datentypen aus Tabelle 2 gelten keinerlei Beschränkungen in Form von maximalen Werten oder Längen. So können - im Gegensatz zu den meisten gängigen Programmiersprachen - Integer-Werte beliebig groß sein, String-Zeichenfolgen beliebig lang sein, etc. ASN.1 bietet daher mehrere Möglichkeiten durch Einschränkung des Wertebereiches neue Datentypen, die als Untertypen (Subtypes) bezeichnet werden, festzulegen. Im folgenden nun einige selbsterklärende Beispiele:
Abbildung in dieser Leseprobe nicht enthalten
Die Untertypen haben ihre praktische Bedeutung bei der Implementierung von Schichtprotokollen, denn die in ASN.1 definierten abstrakten Typen müssen in konkrete Datentypen einer Programmiersprache (z.B. C) umgesetzt werden. ASN.1-Compiler generieren hierzu Programmcode in der entsprechenden Zielsprache, der im wesentlichen aus Typ- und Strukturdefinitionen sowie Funktionen zur Codierung bzw. Decodierung gemäß den Basic Encoding Rules besteht (siehe Abbildung 19). Näheres hierzu ist dem Kapitel 4.9 zu entnehmen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 19: Zusammenhang zwischen abstrakter Syntax, konkreter Syntax und Transfersyntax
4.6 Object Identifier
Der Built-in Datentyp OBJECT IDENTIFIER dient der Referenzierung von international gültigen Informationsobjekten. Darunter sind beispielsweise Protokollspezifikationen oder Klassen von Managementobjekten zu verstehen. Die Informationsobjekte sind Bestandteil einer weltweiten Registration und werden zumeist anschaulich in einem Objektbezeichnerbaum dargestellt (siehe Abbildung 20).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 20: Objektbezeichnerbaum
Die Kommunikation zwischen offenen Systemen setzt ein gemeinsames Protokoll voraus. Mit Hilfe des Objektbezeichners können sich die Partner gegenseitig signalisieren, welche Protokolle sie grundsätzlich unterstützen und welchem Protokoll eine konkrete Nachricht angehört. Ebenso müssen sich offene Systeme mitteilen, welche Codierungsregeln sie kennen bzw. für eine bestimmte Nachricht verwendet haben.
Der Wert des OBJECT IDENTIFIER-Typs, d.h. der konkrete Objektbezeichner, wird von jener Organisation vergeben, die das entsprechende Informationsobjekt definiert hat. Er besteht aus einer Folge von nicht-negativen Integerwerten und/oder Synonyme für diese Zahlenwerte, z.B.:
Abbildung in dieser Leseprobe nicht enthalten
4.7 Protokollbeispiel - Filetransfer
Nachdem in den vorangegangenen Kapiteln bereits die wesentlichen Grundelemente von ASN.1 aufgezeigt wurden, soll nun an dieser Stelle ein einfaches Beispiel (Spezifikation eines FiletransferProtokolls) die Anwendung konkretisieren. Für eine ausführliche Beschreibung des Sprachumfanges sei auf die entsprechende Literatur verwiesen (z.B. [Gora]).
Der Entwurf des Filetransfer-Protokolls erfolgt am besten nach dem „Top-Down-Verfahren“. So sind zunächst alle Funktionalitäten festzuhalten, die das Dienstelement bereitstellen soll. Hierzu gehören neben der eigentlichen (blockweisen) Datenübertragung auch der bestätigte Verbindungsauf- und -abbau. Bestätigt deshalb, da etwa bei einer vorübergehenden Überlastung das entfernte System in der Lage sein muß, den Wunsch nach einem Verbindungsaufbau ablehnen zu können. Der Datentransfer selbst kann unbestätigt erfolgen - die Fehlerfreiheit wird in einer OSI-Umgebung bekanntlich durch die Sicherungsschicht bzw. Transportschicht gewährleistet. Allerdings kann der Fall eintreten, daß der Plattenplatz zur Abspeicherung der Daten nicht mehr ausreicht und daher der Vorgang beendet werden muß.
Der nächste Schritt beim Protokollentwurf ist der Übergang von den Diensten zu den entsprechenden Dateneinheiten. Anhand der bereits beschriebenen Aufgaben lassen sich insgesamt sechs PDUs ableiten, von denen beim tatsächlichen Nachrichtenaustausch jeweils nur eine an das entfernte System weiterzugeben ist. Diese Tatsache läßt sich in ASN.1 mit Hilfe des CHOICE-Konstruktes wie folgt formulieren:
Verbindungsaufbau Bestätigung hierzu Datenübertragung (blockweise) Fehler am entfernten System Verbindungsabbau Bestätigung hierzu }
Bevor die eigentlichen Inhalte der Dateneinheiten festgelegt werden sei erwähnt, daß die eindeutige Interpretation dieser auf der Empfängerseite sichergestellt sein muß. Eine Möglichkeit wäre, analog dem Beispiel aus Kapitel 4.4, innerhalb des CHOICE-Ausdruckes kontextspezifische Tags einzuführen. Oder: Jeder einzelne Datentyp bekommt genau ein APPLICATION-Tag zugewiesen (das Filetransfer-Protokoll kann bedenkenlos als eigener „Haus“-Standard betrachtet werden). Zudem soll durch die ausreichende Verwendung der impliziten Codierung der Dateneinheiten ein möglichst kurzer Bitstrom erreicht werden.
Es empfiehlt sich, die für den Verbindungsaufbau relevanten Daten (z.B. Adresse des Empfängers in maschinenlesbarer Form oder die maximale Länge einer PDU) mittels SEQUENCE-Struktur zu einer Einheit zusammenzufassen. Einige Komponenten dieser Struktur können mit konkreten Werten vorbelegt oder aber auch optional sein, d.h. der Aufbau der zu übertragenden Dateneinheit kann variieren.[9] Seitens des Decoders muß aber Klarheit darüber bestehen, ob nun eine Komponente vorhanden ist oder ausgelassen wurde. Die ASN.1-Norm schreibt daher die Verwendung von (kontextspezifischen) Tags wenigstens an den Stellen vor, an denen Mehrdeutigkeiten auftreten können - also:
Abbildung in dieser Leseprobe nicht enthalten
Zur Bestätigung des Verbindungsaufbaus ist prinzipiell die Übermittlung eines Wahrheitswertes (Wahr/Falsch) an den Sender ausreichend. Die Verwendung eines Integerwertes bietet jedoch den Vorteil, daß im Falle eines Fehlers auch die Ursache in verschlüsselter Form übertragen werden kann. Wie die nachfolgende Definition der Dateneinheit zeigt, ist es möglich, einzelne Fehlercodes mit aussagekräftigen Namen zu belegen. Eine Einschränkung des Definitionsbereiches findet allerdings dadurch nicht statt; dies wird erst durch die Bildung eines Untertyps erreicht.
Abbildung in dieser Leseprobe nicht enthalten
Da der Filetransfer in der Regel blockweise erfolgt, muß die hierfür zuständige Dateneinheit neben den eigentlichen Daten auch ein Endekennzeichen beinhalten. Allerdings ist eine gleichzeitige Übertragung beider Informationen nicht unbedingt erforderlich. Die Dateneinheit läßt sich also am sinnvollsten als CHOICE-Struktur mit zwei Komponenten definieren. Dabei kann das Endekennzeichen als NULL-Typ festgelegt werden. Der Datentyp NULL hat lediglich die Aufgabe, das Vorhandensein einer Komponente zu kennzeichnen. Er kennt daher auch nur einen einzigen Wert, den Wert »NULL«.
Abbildung in dieser Leseprobe nicht enthalten
Tritt während des Filetransfers ein Fehler am Empfänger auf, so hat dieser an den Sender eine Nachricht zu übermitteln, die den Fehler beschreibt. Analog zur Bestätigung des Verbindungsaufbaus könnte eine Integerzahl zur Darstellung der Fehlerursache herangezogen werden. Eine weitere Möglichkeit besteht darin, die Dateneinheit als eine aus NULL-Komponenten bestehende CHOICE- Struktur festzulegen. Die hierfür benötigten kontextspezifischen Tags dienen dann der eindeutigen Interpretation des Fehlers auf der Empfängerseite. Im übrigen dürfen CHOICE-Strukturen keinesfalls implizit codiert werden; die zur Unterscheidung der Komponenten notwendigen Tags würden sonst verloren gehen.
Abbildung in dieser Leseprobe nicht enthalten
Die für den Verbindungsabbau zuständigen Protokolldateneinheiten erklären sich dann von selbst:
Abbildung in dieser Leseprobe nicht enthalten
Schließlich werden alle Typdefinitionen des Filetransfer-Protokolls in einem Modul vereinigt und so von weiteren Protokollspezifikationen logisch getrennt. Die Referenzierung eines ASN.1-Moduls erfolgt über den Modulnamen und/oder den Objektbezeichner. Letzterer gilt als verbindlich, falls der Modulname nicht eindeutig sein sollte.
Abbildung in dieser Leseprobe nicht enthalten
4.8 Basic Encoding Rules
Neben der abstrakten Syntax zur Beschreibung von Datenwerten und Datentypen ist für den Nachrichtenaustausch zwischen Anwendungsprozessen eine Transfersyntax notwendig. Die Basic Encoding Rules stellen hierfür eine vollständige Übersetzungsvorschrift bereit. Je nach Art der Codierung gliedert sich ein Datenwert in drei bzw. vier Komponenten.
- Codierung ohne Endekennung (bestimmte Form):
Das Längenfeld gibt bei der bestimmten Form der Codierung explizit die Anzahl der Bytes im Inhaltsfeld an. Hierbei ist für Längenangaben kleiner oder gleich 127 ein Oktett ausreichend, wobei die Bits 7 bis 1 die Länge repräsentieren und das Bit 8 auf 0 zu setzen ist.
Abbildung in dieser Leseprobe nicht enthalten
Besitzt das Inhaltsfeld mehr als 127 Bytes, so sind zur Beschreibung der Länge mehrere Oktette notwendig. Dabei geben die Bits 7 bis 1 des ersten Oktetts die Anzahl der nachfolgenden Oktette an, die die Größe des Inhaltsfeldes binär darstellen.
Abbildung in dieser Leseprobe nicht enthalten
- Codierung mit Endekennung (unbestimmte Form):
Abbildung in dieser Leseprobe nicht enthalten
Dagegen erfolgt bei der Codierung in der unbestimmten Form keine ausdrückliche Angabe der Länge. Statt dessen wird das Inhaltsfeld mit einer Endekennung abgeschlossen.
Das Bezeichnerfeld speichert die Tag-Angaben und erlaubt somit eine eindeutige Typidentifikation des im Inhaltsfeld angegebenen Datenwertes. Je nach Größe der Tag-Nummer sind dafür ein oder mehrere Oktette erforderlich. Für Tag-Nummern aus dem Wertebereich zwischen 0 und einschließlich 30 ist ein Oktett ausreichend. Die Codierung geschieht nach folgendem Schema:
Abbildung in dieser Leseprobe nicht enthalten
Für Tag-Nummern größer oder gleich 31 genügt ein Bezeichnerfeld alleine nicht mehr; sie müssen daher auf mehrere Oktette aufgeteilt werden. Um dies zu kennzeichnen, sind die Bits 5 bis 1 des ersten Oktetts mit dem Wert B’11111 zu belegen. Die Binärdarstellung der Tag-Nummer ergibt sich dann aus der Aneinanderreihung der Bits 7 bis 1 aller folgenden Bezeichnerfelder. Das achte Bit ist dabei jeweils auf den Wert 1 zu setzen, mit Ausnahme des letzten Oktetts. Es ergibt sich also nachstehende Bildungsregel:
Die Codierung der eigentlichen Datenwerte erfolgt im dritten Feld, dem Inhaltsfeld. Dabei ist die Oktettfolge nicht nur vom darzustellenden Datenwert abhängig, sondern auch vom Datentyp, der letztendlich für die Art der Codierung (primitiv oder zusammengesetzt) entscheidend ist. Anhand zwei einfacher Beispiele soll dieser Unterschied aufgezeigt werden:
Abbildung in dieser Leseprobe nicht enthalten
4.9 Implementierung von ASN.l-Datentypen
In Kapitel 4.5 wurde bereits darauf hingewiesen, daß für eine konkrete Protokollimplementierung zunächst die abstrakte Syntax in eine konkrete lokale Syntax übersetzt werden muß. Zu diesem Zweck ist eine generelle Vorschrift für die Abbildung von ASN.1-Datentypen und -werten auf die gewählte Zielsprache aufzustellen. Tabelle 4 zeigt einige dieser Abbildungsvorschriften von ASN.1 nach C und umgekehrt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 4: Zuordnung ASN.1 O C
Anmerkung: Tag- und Längenangaben sind nur für die zu übertragenden Dateneinheiten, nicht aber für die konkreten C-Daten relevant. Sie haben daher keinen Einfluß auf die oben aufgelistete Zuordnung zwischen ASN.1- und C-Typen. Jedoch spielen sie sehr wohl eine Rolle im Programmcode des Decoders.
5 Guidelines for the Definition of Managed Objects (GDMO)
5.1 Begriffsbestimmung
„GDMO ist eine in der ITU-T Empfehlung X.722 festgelegte formale Notation zur Beschreibung der statischen, dynamischen und funktionalen Aspekte von Systemkomponenten in Zusammenhang mit dem Systemmanagement.“[10]
Das Informationsmodell des OSI Systems Managements (vgl. Kapitel 3.2) fordert zur Darstellung aller managementrelevanten Ressourcen eines Systems ein objektorientiertes Beschreibungsmittel. Hiermit soll nicht nur ein konsistentes Konzept bei der Definition von Objektklassen erreicht, sondern auch eine Duplizierung von Informationen durch die konsequente Anwendung der bereitgestellten Vererbungsmechanismen vermieden werden - diese Anforderungen erfüllt GDMO.
Die mittels GDMO festgelegten Objektklassen, deren Merkmale und deren Beziehungen zueinander (Vererbung, Beinhaltung) müssen - analog zu den ASN.I-Definitionen - in eine (objektorientierte) Programmiersprache umgesetzt werden. Dies kann entweder mit Hilfe eines entsprechenden GDMO- Compilers oder aber auch manuell geschehen.
Anmerkung: Die Bezeichnung „Guidelines for the Definition of Managed Objects“ ist streng genommen nicht korrekt, denn hier ist von Managementobjekten die Rede, obwohl eigentlich Objektklassen gemeint sind!
5.2 Templates
Die grundlegenden Bausteine der GDMO-Notation sind die sog. Templates. Templates sind im übertragenen Sinn Schablonen, die der Entwickler von Objektklassen „ausfüllen“ muß. Sie setzen sich laut GDMO-Sprachdefinition zusammen aus
- dem innerhalb eines GDMO-Moduls eindeutigen Template-Bezeichner,
- dem Template-Typ,
- den eigentlichen, vom Template-Typ abhängigen Inhalten und
- der (optionalen) Registrierungsklausel zur internationalen Identifizierung des Templates.
Die allgemeine Struktur eines Templates ist demnach:
template-bezeichner TEMPLATE-TYP
CONSTRUCT-NAME [construct-argument];
[CONSTRUCT-NAME [construct-argument];]*
[REGISTERED AS object-identifier];
Der Sprachumfang von GDMO setzt sich aus neun Templates zusammen, die - wie aus Abbildung 2I ersichtlich - zueinander nach einem gewissen Schema in Beziehung stehen. Demzufolge enthält eine Objektklasse Pakete, die u.a. eine Menge von Attributen, Meldungen und Aktionen zusammenfassen. Ferner ist erkennbar, daß einige Templates einen Zugriff auf ASN.I-Module gestatten. Dies ist insofern von Bedeutung, da GDMO selbst keine Möglichkeiten zur Festlegung von Datenwerten bzw. -strukturen bereitstellt. Der Aufbau einer Managementobjektklasse gliedert sich in
- Attribute, die die Eigenschaften und den Status von Managementobjekten charakterisieren. Jedem Attribut können Zugriffsrechte und CMISE-Filterkriterien zugeordnet werden.
- Aktionen, die als komplexe Operationen aufzufassen sind und nicht nur ein Attribut allein, sondern das gesamte Managementobjekt betreffen.
- Meldungen (Notifications), die die Managementobjekte, ausgelöst durch entsprechende externe bzw. interne Ereignisse, aussenden können (i.a. können Managementobjekte auch autonome Ressourcen darstellen).
- Verhaltensweisen (Behaviour), die rein informell die Art und Weise beschreiben, wie ein Managementobjekt auf eine Operation reagiert.
- verbindliche Pakete (Mandatory Packages), die die oben angeführten Komponenten bündeln und als fixen Bestandteil in eine Klassendefinition einfügen.
- optionale Pakete (Conditional Packages), deren Eingliederung in ein Managementobjekt erst während der Instantiierung entschieden wird.
- Name-Bindings, die die Stellung einer Klasse innerhalb der Beinhaltungshierarchie festlegen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 21: Beziehungen zwischen GDMO-Templates
5.3 Syntaxregeln
Die GDMO-Syntax ähnelt in einigen Punkten der Syntax von ASN.1. GDMO-Definitionen sind ebenfalls formatfrei, auch zwischen Groß- und Kleinschreibung wird unterschieden. Folgende Zeichen sind in GDMO-Definitionen zulässig (GDMO-Zeichensatz):
Abbildung in dieser Leseprobe nicht enthalten
Leerzeichen, Zeilenendezeichen und Textbegrenzer
Eine GDMO-Zeichenfolge kann nachstehende Bedeutung haben:
- Template-Bezeichner sind beliebige Zeichenfolgen aus Buchstaben, Ziffern und Bindestrichen, beginnend mit einem Kleinbuchstaben (analog der ASN.l-Wertbezeichner).
- Kommentare beginnen mit der Aufeinanderfolge zweier Trennungszeichen »--« und enden mit der erneuten Angabe dieser Zeichenfolge, spätestens jedoch am Ende einer Zeile.
- Schlüsselwörter sind Bestandteil der Sprachdefinition, sie sind durchgängig in Großbuchstaben geschrieben. Gleichlautende ASN.1-Typ- oder Modulbezeichner sind daher unzulässig.
- Textstrings können - müssen aber nicht! - mit einem der folgenden Zeichen begrenzt werden:
Abbildung in dieser Leseprobe nicht enthalten
- Objektbezeichner werden durch geschweifte Klammern begrenzt.
- Der Punktoperator ». « dient der Referenzierung von externen ASN.l-Typ- und Wertdefinitionen.
5.4 GDMO-Beispiel - Dateiverwaltung
Eine ausführliche Erklärung aller einzelnen Template-Komponenten der GDMO-Notation ist hier leider nicht möglich - dies würde sonst den Rahmen dieser Arbeit sprengen. Hierzu sei also wieder auf die entsprechende Literatur verwiesen (z.B. [Hebrawi]).
Vielmehr soll ein leicht verständliches Beispiel die Anwendbarkeit von GDMO verdeutlichen. Aufgabe dieses Beispieles ist es, das Informationsmodell einer Dateiverwaltung zu beschreiben. Die Dateiablage erfolgt dabei nach einem hierarchischen Prinzip (siehe Abbildung 22): Jede Datei ist genau einem Verzeichnis zugeordnet; Verzeichnisse können selbst wiederum (Unter-) Verzeichnisse beinhalten. Dieses Prinzip dürfte jedem Nutzer eines Betriebssystems wie DOS, OS/2 etc. bekannt sein.
Abbildung in dieser Leseprobe nicht enthalten
Die Dateiverwaltung muß/soll folgende Funktionalitäten bereitstellen:
- Erzeugen bzw. Löschen von Verzeichnissen und Dateien,
- Komprimieren von Dateien und
- Auslagern von Verzeichnissen.
5.4.1 MANAGED OBJECT CLASS-Template
Eine Objektklasse ist ein Schema zur Konstruktion von gleichartig aufgebauten Objekten. Mit der Definition einer Objektklasse sind alle Komponenten festgelegt, die ein Objekt dieser Klasse enthält bzw. enthalten kann. Ein Objekt ist gewissermaßen die konkrete Ausprägung (Instanz) einer Klasse. Unter „Komponenten“ ist dabei eine Menge von Attributen, Operationen, Meldungen und Verhaltensweisen zu verstehen.
Objektklassen sind Bestandteil einer Vererbungshierarchie, an deren Spitze die Klasse »top« steht. Jede Klasse dieser Hierarchie stammt also direkt bzw. indirekt von »top« ab. Eine Unterklasse besitzt mindestens eine Oberklasse, deren Eigenschaften sie erbt. GDMO unterstützt somit die multiple Vererbung.
Durch die Definition neuer Managementobjektklassen werden zu den geerbten Komponenten weitere hinzugefügt. Die Beschreibung dieser Komponenten erfolgt durch das
- ATTRIBUTE-Template,
- PARAMETER-Template,
- ACTION-Template,
- NOTIFICATION-Template und
- BEHAVIOUR-Template,
wobei diese allerdings nicht unmittelbar, sondern indirekt über das PACKAGE-Template in einer Klassendefinition auftreten.
Objektklassen werden in GDMO mit Hilfe des MANAGED OBJECT CLASS-Templates definiert. Das Beispiel der hierarchischen Dateiablage benötigt zur Beschreibung der Verzeichnisse und Dateien zwei Klassendefinitionen:
Abbildung in dieser Leseprobe nicht enthalten
Die DERIVED FROM-Klausel bestimmt alle Oberklassen der neu definierten Klasse. In diesem Fall sind - wie auch Abbildung 23a zeigt - die Klassen »dir« und »file« lediglich von »top« abgeleitet. Die Klasse »top«, die als Wurzel der Vererbungshierarchie dient, ist in der ITU-T Empfehlung X.721 festgelegt. Das Schlüsselwort CHARACTERIZED BY benennt alle verbindlichen Pakete, die somit fester Bestandteil eines Managementobjektes dieser neuen Klasse sind.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 23: (a) Vererbungshierarchie, (b) Name-Binding-Graph (s. Kap. 5.4.2)
Interessant ist die Möglichkeit, in eine Klassendefinition sog. Conditional Packages aufzunehmen, die nicht automatisch Bestandteil jeder Objektinstanz dieser Klasse sind. Die Einbindung dieser optionalen Pakete erlaubt eine Variantenvielfalt von Managementobjekten, ohne dabei unzählig viele Klassen definieren zu müssen. Oder anders formuliert: N Conditional Packages würden ohne dieses Verfahren zur Festlegung von 2N Objektklassen führen! Für die Praxis bedeutet dies, daß bei der Erzeugung einer Instanz der Manager die Objektbezeichner sämtlicher zu instantiierenden Conditional Packages als Parameter an den Agenten übergeben muß.
Beachte: Bei der Vererbung von Objektklassen können durch das mehrmalige Auftreten einzelner Komponenten Probleme entstehen. Welche Regeln für die jeweiligen Konfliktsituationen gelten bzw. welche Gegenmaßnahmen zu ergreifen sind, kann der GDMO-Spezifikation entnommen werden.
5.4.2 NAME BINDING-Template
Um eine klare Trennung zwischen den internen Charakteristika eines Objektes und seinen externen Beziehungen zu erhalten, sind in GDMO zwei verschiedene Template-Arten notwendig. Während das MANAGED OBJECT CLASS-Template die „Interna“ und somit auch die Abstammungsverhältnisse beschreibt, legt das NAME BINDING-Template die „Externa“ fest, d.h. welche Objekte in welchen enthalten sein und wie diese identifiziert werden können.
Logischerweise ist die Existenz eines untergeordneten (subordinate) Objektes direkt von der Existenz des übergeordneten (superior) Objektes abhängig. Die hieraus resultierende Beinhaltungshierarchie entsteht aber erst „zur Laufzeit“. Zur Identifizierung eines Managementobjektes wird die enge Verwandtschaft zwischen Namensgebung und Beinhaltung ausgenutzt: Jedes Objekt besitzt im Bezug zur übergeordneten Instanz einen eindeutigen lokalen Namen (relativ distinguished name). Der globale Name (distinguished name) eines Objektes ergibt sich dann aus der Kombination aller lokalen Namen zurückgehend bis zur Wurzel der Beinhaltungshierarchie. Zum Beispiel besitzt die Datei »file_2« nach Abbildung 22 den globalen Namen »system\dir_1\dir_2\file_2«.
Tabelle 5 faßt nochmals die Merkmale von Klassen, Objekten und dem Name-Binding zusammen.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 5: Klassen, Name-Binding, Objekte
Die Wurzel der Beinhaltungshierarchie ist die in der ITU-T Empfehlung X.721 definierte Objektklasse »system«. Für das Beispiel des Dateisystems ergeben sich schließlich nach dem Name-Binding-Graph aus Abbildung 23b die GDMO-Definitionen wie folgt:
Abbildung in dieser Leseprobe nicht enthalten
Erklärung der einzelnen Bestandteile des NAME BINDING-Templates:
- SUBORDINATE OBJECT CLASS legt die Klasse des untergeordneten Objektes fest.
- NAMED BY SUPERIOR OBJECT CLASS bezeichnet die Klasse des übergeordneten Objektes, das das untergeordnete Objekt enthält.
- WITH ATTRIBUTE verweist auf ein Attribut des untergeordneten Objektes, das zur Aufnahme eines eindeutigen lokalen Namens und somit zur Identifizierung dieses Objektes dient.
- CREATE gibt an, daß das Erzeugen von Objekten der untergeordneten Klasse durch den CMISE- Dienst M-CREATE möglich ist. Der Bezeichner »createError« verweist dabei auf ein PARAMETER-Template, das im Falle eines Prozeßfehlers diesen näher spezifiziert.
- DELETE erlaubt das Löschen von Objekten der untergeordneten Klasse durch den CMISE-Dienst M-DELETE. Die zusätzliche Angabe der Klausel ONLY-IF-NO-CONTAINED-OBJECTS verhindert das Entfernen von Objekten, die selbst untergeordnete Objekte beinhalten. Analog dient auch hier der Bezeichner »deleteError« der näheren Beschreibung eines etwaigen Prozeßfehlers.
5.4.3 PACKAGE-Template
Das PACKAGE-Template dient der Gruppierung von Attributen, Operationen und Meldungen, die zur Beschreibung von Objektklassen notwendig sind. Die in einem Paket definierten Operationen können auf alle Managementobjekte angewendet werden, bei denen dieses Paket instantiiert ist. Sie lassen sich prinzipiell einteilen in
- Zugriffsrechte, die direkt auf die Attribute wirken und diese ggf. modifizieren (= attributbezogene Operationen) sowie
- Aktionen, die ein Managementobjekt als Ganzes betreffen (= objektbezogene Operationen).
Die vollständige Charakterisierung der Attribute erfolgt erst in einem Package. Es können
- Zugriffsrechte wie GET, REPLACE oder GET-REPLACE vergeben werden,
- Initial- und Defaultwerte durch Verweise auf ASN.1-Wertdefinitionen festgelegt werden sowie
- Wertebereiche eingeschränkt werden.
Die Klassendefinitionen des Beispieles beziehen sich auf insgesamt zwei Packages. Dabei umfaßt das »dirPackage« den Verzeichnisnamen und die Meldung, die bei einer Auslagerung des Verzeichnisses ausgesendet werden soll. Das »filePackage« dagegen beinhaltet den Dateinamen, die Dateiattribute, den Dateiinhalt sowie die Aktion zur Datenkomprimierung. Es ergeben sich folgende Definitionen:
Abbildung in dieser Leseprobe nicht enthalten
5.4.4 ATTRIBUTE-Template
Attribute bezeichnen die Eigenschaften von Objekten. Sie beschreiben Informationen, die in einem Objekt verborgen sind und durch objektspezifische Operationen (Methoden) manipuliert werden können. Die Festlegung der Attributkomponenten erfolgt unter Verwendung von ASN.1- Typdefinitionen, da GDMO selbst keine Mittel zur Beschreibung von Datenstrukturen bereitstellt.
Attribute können Teil eines CMISE-Filterausdruckes sein (vgl. Kapitel 3.4, „Scoping and Filtering“). Welche Abprüfungen mit einem Attribut möglich sind - z.B. auf Gleichheit (EQUALITY), Größe (ORDERING), Beinhaltung (SUBSTRING) - legt die MATCHES FOR-Klausel fest. Die Menge aller Vergleichsregeln wird durch ein logisches „Oder“ gebildet.
Die Attributdefinitionen für das Dateisystem-Beispiel könnten wie folgt aussehen:
Abbildung in dieser Leseprobe nicht enthalten
Attribute, die logisch zusammengehören und auf die gemeinsame Operationen angewendet werden sollen, lassen sich mit dem ATTRIBUTE GROUP-Template vereinigen.
5.4.5 BEHAVIOUR-Template
Das BEHAVIOUR-Template kann zur informellen Beschreibung des Verhaltens von einigen GDMO- Sprachkomponenten, wie beispielsweise von ACTION-Templates, NOTIFICATION-Templates, etc. herangezogen werden. Diese Beschreibung - sie erfolgt in Textform! - hat allerdings keinen Einfluß auf die realisierten Abläufe, z.B.:
Abbildung in dieser Leseprobe nicht enthalten
5.4.6 PARAMETER-Template
Managementoperationen sind immer mit dem Austausch von Dateneinheiten zwischen Manager und Agent verbunden. Diese Dateneinheiten beinhalten definitionsgemäß „offene“ Felder, deren genaue Festlegung über das PARAMETER-Template erfolgen kann. Parameter dienen also der zusätzlichen Beschreibung von Informationen. Im Gegensatz zu den Attributen sind sie jedoch „protokollbezogen“, d.h. mit Hilfe von Parametern lassen sich gezielt Protokolldaten festlegen.
Jeder Parameter besitzt eine Syntax, die durch einen ASN.l-Datentyp definiert ist. An welcher Stelle innerhalb einer Dateneinheit die Parameter-Inhalte zu übertragen sind, läßt sich mittels dem CONTEXT-Schlüsselwort bestimmen - also:
Abbildung in dieser Leseprobe nicht enthalten
Obige Definitionen bedeuten im Klartext: Kann aus bestimmten Gründen eine Objektinstanz der Klassen »dir« oder »file« über den CMISE-Dienst M-CREATE nicht erzeugt werden, so soll die Ursache in Form eines Integerwertes im Error-Feld der bestätigenden Dateneinheit (Confirmation- PDU) an den Manager übermittelt werden. Im Falle einer fehlerfreien Instantiierung eines Objektes ist das Error-Feld der Rückantwort nicht besetzt. Analog gelten diese Punkte für die Löschung einer Objektinstanz durch den CMISE-Dienst M-DELETE.
5.4.7 ACTION-Template
Aktionen sind benutzerdefinierte objektbezogene Operationen; sie sind generell auf das gesamte Objekt anwendbar. Die Definition von Aktionen geschieht auf rein formelle Weise. Dies bedeutet, daß die eigentlichen Operationen ein Bestandteil des Programmcodes des Agenten sind, während es mit Hilfe von GDMO lediglich möglich ist, die Übergabeparameter von Operationen und das Verhalten als „Prosatext“ festzulegen. Bei den Übergabeparametern ist zu unterscheiden zwischen
- dem Action Information Parameter, der die Eingangsdaten einer Operation bestimmt und somit ein Teil der M-ACTION-Request-Dateneinheit ist und
- dem Action Reply Parameter, der die Ausgangsdaten einer Operation beschreibt und demnach konsequenterweise Bestandteil der M-ACTION-Confirmation-Dateneinheit ist (vgl. hierzu auch Tabelle 1, Seite 19).
Das Dateiverwaltungsbeispiel sieht das Komprimieren einzelner Dateien vor. Auslöser für diese Aktion ist der Manager, der dem Agenten den Dateinamen und die Komprimierungsmethode mitteilt. Als Rückmeldung erhält der Manager vom Agenten den Komprimierungsgrad. Demzufolge lautet die ACTION-Definition:
Abbildung in dieser Leseprobe nicht enthalten
5.4.8 NOTIFICATION-Template
Managementobjekte können Meldungen aussenden, die entweder durch das Ausführen einer Operation (externes Ereignis) oder auch autonom (internes Ereignis) ausgelöst werden. Jede Meldung ist charakteristisch für das Managementobjekt, das diese aussendet. Die Übertragung erfolgt dabei unter Verwendung des CMISE-Dienstes M-EVENT-REPORT vom Agenten, der das Managementobjekt verwaltet, zu einem ausgewählten Manager. „Ausgewählt“ heißt, daß der Empfänger der Meldung nicht zwangsläufig der Manager sein muß, der die Instantiierung des entsprechenden Objektes veranlaßt hat (vgl. auch Kapitel 3.5, Event Report Management Function).
Die Syntax der zu übertragenden Information beschreibt eine ASN.1-Typdefinition. Ferner ist es möglich, über die Klausel AND ATTRIBUTE IDS Beziehungen zwischen den Feldkomponenten der Informationssyntax und den Attributen des Objektes, das die Meldung aussenden soll, herzustellen. Der Typ einer Komponente muß hierbei der Syntax des zugeordneten Attributes entsprechen.
Bislang blieb eine geforderte Funktionalität des Dateiverwaltungsbeispieles offen - die Migration (Auslagerung) von Verzeichnissen. Wird durch den Agenten, der die Dateiablage verwaltet, ein Verzeichnis selbständig - also ohne Aufforderung durch den Manager - ausgelagert (beispielsweise auf Magnetband), so muß dieser dem entsprechenden Manager den Namen des ausgelagerten Verzeichnisses mitteilen. Hierzu ist eine Notification notwendig, deren Definition nachfolgend zu sehen ist:
Abbildung in dieser Leseprobe nicht enthalten
5.4.9 ASN.l-Modul
Den Abschluß des GDMO-Beispieles bilden die zugehörigen ASN.l-Typdefinitionen. Sie sollen hier nicht näher erläutert werden, denn sie sprechen eigentlich für sich selbst. Andernfalls sei auf das Kapitel 4 verwiesen, das die Grundlagen zum Thema ASN.l vermittelt.
Abbildung in dieser Leseprobe nicht enthalten
5.5 Zusammenhang zwischen CMISE und GDMO
Das Dateiverwaltungsbeispiel aus dem vorangegangenen Kapitel 5.4 zeigte bereits an einigen Stellen die Zusammenhänge zwischen den GDMO-Definitionen und den CMISE-Diensten auf. Hierbei ist ersichtlich, daß die Spezifikation eines Informationsmodells direkten Einfluß auf die möglichen Managementoperationen nimmt. So können beispielsweise Attribute nur dann gelesen, gesetzt oder innerhalb eines Filterausdruckes verwendet werden, wenn dies ausdrücklich durch die GDMO- Definition festgelegt wurde. Die Zusammenhänge im einzelnen soll nochmals Abbildung 24 verdeutlichen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 24: Zusammenhang CMISE O GDMO
6 Softwaretracer (SWT)
6.1 Begriffsbestimmung
Bei der Entwicklung von Software schleichen sich i.a. immer wieder Fehler ein, die sich erst zur Laufzeit des Programms bemerkbar machen. Selbst erfahrene Programmierer sind vor solchen Irrtümern kaum gefeit. Je umfangreicher die Softwareprodukte werden, um so schwieriger gestaltet sich zumeist die Fehlersuche. Um den Programmierer bei seiner Arbeit tatkräftig zu unterstützen, sind leistungsfähige Hilfsprogramme zum Aufspüren sog. „Bugs“ (Programmfehler) notwendig. Allgemein ist bei diesen Hilfsprogrammen zwischen zwei Verfahren zu unterscheiden:
- Tracer unterbrechen den eigentlichen Programmablauf nur kurzfristig an denjenigen Stellen, an denen der Anwender Tracepunkte in den Programmcode eingebracht hat. Mit Hilfe dieser Tracepunkte ist es möglich, die Zustände von globalen bzw. lokalen Programmvariablen, CPU- Registern etc. abzufragen, diese in einem Tracepuffer zwischenzuspeichern oder unmittelbar an den Anwender weiterzuleiten. Tracer eignen sich u.U. auch für laufzeitkritische Untersuchungen - eine optimale Programmierung des Tracers sei natürlich vorausgesetzt!
- Debugger stoppen im Gegensatz zum Tracer ein laufendes Programm. In diesem Zusammenhang wird dann auch von Haltepunkten (Breakpoints) gesprochen. Debugger erlauben nicht nur das Betrachten von Variablen- oder Registerinhalten, sie gestatten auch deren Manipulation. Der Anwender hat demnach die Möglichkeit, direkten Einfluß auf die weitere Programmsteuerung zu nehmen. Ein weiterer Vorteil besteht darin, daß sich Codezeilen schrittweise ausführen und so die Änderungen an den Variablen bzw. Registern besser nachvollziehen lassen. Debugger sind jedoch für den Einsatz unter Realzeitbedingungen nicht geeignet.
In diesem Abschnitt soll nun der Softwaretracer (SWT) etwas näher beschrieben werden, der bei der Softwareentwicklung für fernmeldetechnische Vermittlungsanlagen bei der Siemens AG im Einsatz ist. Die Ursprünge dieser Vermittlungssysteme mit der Produktbezeichnung „EWSD (Elektronisches Wählsystem Digital) “ reichen bis in den Anfang der 80er Jahre zurück - heute sind sie weltweit verbreitet. Auch vor ihnen machte der rasante Fortschritt der Technik nicht halt. Dementsprechend komplex sind mittlerweile die EWSD-Anlagen, dies gilt natürlich auch für die jeweiligen Softwarekomponenten.
Der Softwaretracer ist ein modernes Hilfsprogramm, das den hohen Anforderungen selbst bei laufzeitkritischen Tests standhält. Er wird beschrieben durch ein mittels GDMO spezifiziertes Informationsmodell. Die Bedienung des SWTs erfolgt über einen Manager-Agent-Mechanismus.
6.2 Manager-Agent-Prinzip
Das Prinzip der Aufgabenverteilung zwischen Agent und Manager dürfte aus dem Kapitel 3.3 bekannt sein. Wie aber sieht dies konkret bei einem EWSD-Vermittlungssystem aus?
Der Network Manager (NM) steht mit einem oder mehreren Network Elements (NEs) in Verbindung; das Bindeglied zwischen ihnen heißt Q3-Schnittstelle. Eine CMISE-Dienstanforderung des Network Managers wird also über die Q3-Schnittstelle an das entsprechende Network Element (= Agent) weitergeleitet. Dort empfängt zunächst der Association Server die übertragene Dateneinheit und legt diese in einem Zwischenspeicher ab.
Der Association Server vergleicht bestimmte Komponenten der übermittelten Dateneinheit mit einer Zuordnungstabelle, um so den tatsächlich auszuführenden Managementprozeß ermitteln zu können. Vom Association Server erhält dann der Prozeß eine Benachrichtigung über die eingetroffene und für ihn bestimmte Dateneinheit. Diese kann sich der Prozeß aus dem Zwischenspeicher abholen und je nach deren Inhalt erfolgt schließlich die Durchführung der geforderten Operationen.
Der Zugriff auf den Zwischenspeicher durch einen Managementprozeß geschieht dabei über API- Funktionen (API = Application Programmers Interface), die das Network Element bereitstellt. Umgekehrt kann ein Prozeß - ebenfalls über einen API-Funktionsaufruf - Informationen an den Network Manager zurücksenden. Abbildung 25 faßt dies nochmals zusammen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 25: Manager-Agent-Prinzip
Die Q3-Schnittstelle dient der Kommunikation zwischen Manager und Agent oder auch zwischen zwei Managern eines verteilten Systems im Rahmen des Telecommunication Management Network (TMN). Das TMN (beschrieben durch die ITU-T Empfehlungen M.3000 ff.) basiert auf den Prinzipien des OSI Systems Managements. Es verwendet zur ganzheitlichen Verwaltung aller Netzkomponenten ein vom eigentlichen Nutznetz physikalisch getrenntes Managementnetz.[11] Darüber hinaus garantiert der Gebrauch eines generischen Informationsmodells und standardisierter Schnittstellen ein herstellerübergreifendes Netzmanagement.
Hinweis: Die sog. Qx-Schnittstelle lehnt sich zwar an den Festlegungen der Q3-Schnittstelle an, stellt aber in der Regel auch herstellerspezifische Funktionalitäten bereit!
6.3 Funktionsweise / Leistungsmerkmale
Herkömmliche Tracer verwenden zum Auslesen von Variablen- und Registerinhalten ausschließlich eine Traceroutine. Für jeden angesprochenen Tracepunkt muß diese Routine anhand einer Tabelle alle zu sammelnden Daten ausfindig machen. Dieses Verfahren verfälscht u.U. die Laufzeit nachhaltig, so daß von Realzeitbedingungen nicht mehr ausgegangen werden kann.
Der SWT hingegen kann mehrere Traceroutinen verwenden, wobei jede auf ein ganz bestimmtes Bedürfnis zugeschnitten ist. Jede Routine wird dabei nach einer Art „Baukastensystem“ individuell zusammengesetzt. Der auf diese Weise vorab generierte Code adressiert alle vom Anwender gewünschten Variablen bzw. Register direkt, also ohne den Umweg über eine Tabelle. So entfällt der zeitraubende Faktor - der SWT ist daher auch für laufzeitkritische Systemtests geeignet. Abhängig vom angesprochenen Tracepunkt wird schließlich die ihm zugeordnete Routine ausgeführt, die die geforderten Daten in einem Tracepuffer ablegt.
Zudem ermöglicht der SWT eine symbolische Ein- und Ausgabe aller Adressen von Tracepunkten und Programmvariablen. Dies erleichtert die Anwendung des Tracers für den Programmierer insofern, da er im Normalfall lediglich Prozedur- und Variablennamen kennt, jedoch nicht die zugehörigen Adressen. Hierzu verwendet der Tracer einen Interpreter, der über Symboltabellen, die während der Übersetzung des Programmquelltextes durch den Compiler erzeugt werden, die Beziehung zwischen symbolischer und realer Adresse herstellt.
Die Einrichtung von Tracepunkten kann hardware- und/oder softwareseitig erfolgen:
- Software-Tracepunkte können beliebig im Programmcode gesetzt werden. Die Auslösung der Traceroutine erfolgt dabei über einen Interrupt-Befehl (INT 3).
- Hardware-Tracepunkte werden über die Debug-Register des INTEL 80486-Prozessors gesetzt; er verfügt über insgesamt vier solcher Register. HW-Tracepunkte müssen sich nicht ausschließlich auf eine Stelle im Programmcode beziehen, sie können zusätzlich auch eine Variable adressieren und diese auf einen Lese- und/oder Schreibzugriff überwachen.
Jeder Tracepunkt wird einem eindeutigen benutzerdefinierten Identifier (ID) zugeordnet. Mehrere HW- und/oder SW-Tracepunkte können dabei zu einer ID gruppiert werden. Der Identifier hat die Aufgabe, eine Beziehung zwischen den Tracepunkten und den individuell zusammengesetzten Traceroutinen herzustellen. So ist gewährleistet, daß ein angesprochener Tracepunkt die Ausführung der gewünschten Traceereignisse bewirkt.
Zwei weitere interessante Merkmale des SWTs sollen nicht unerwähnt bleiben: Erstens, die trigger- und uhrzeitgesteuerten Tracepunkte. Sie gestatten dem Anwender das Aktivieren bzw. Deaktivieren eines Tracepunktes von der Uhrzeit oder auch vom Durchlaufen eines anderen Tracepunktes abhängig zu machen. Zweitens, die selbständige Deaktivierung aller einer Routine zugeordneten Tracepunkte, falls beim Durchlaufen dieser ein unzulässiger Datenzugriff oder auch eine Überlast („Dynamic Self Control“ O Wahrung der Realzeitbedingung) auftreten sollte.
Abbildung 26 veranschaulicht noch einmal die bereits erwähnten SWT-Funktionalitäten.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 26: SWT-Funktionalitäten (a) „Baukastensystem“, (b) Zuordnung Tracepunkt O Traceroutine,
(c) Überlast- und Zugriffskontrolle, (d) trigger- und zeitgesteuerte Tracepunkte
6.4 Bedienung
Der Test von Programmcode an den Vermittlungsanlagen unter Verwendung des Softwaretracers vollzieht sich nach folgenden Schritten:
- SW- und/oder HW-Tracepunkte festlegen,
- Traceereignisse festlegen (Überwachung von Variablen, triggergesteuerte Tracepunkte etc.),
- Code der Traceroutine(n) generieren,
- gewünschte Tracepunkte aktivieren,
- Test an der EWSD-Anlage durchführen,
- Tracepuffer auslesen,
- Tracepunkte deaktivieren und ggf. Traceroutine(n) löschen.
Eine umfassende Beschreibung obiger Punkte ist der Bedienungsanleitung des Softwaretracers zu entnehmen ([Schwarzmann-1]).
Alle Funktionen des Softwaretracers lassen sich über die Q3-Schnittstelle nach dem Manager-AgentPrinzip unter dem Austausch von Dateneinheiten ansprechen. Leider ist dabei die Bedienung (derzeitig) nicht besonders benutzerfreundlich. Sie erfolgt nämlich über Skripten in Form der CMIS- Notation (CMIS-N), die gewissermaßen als das „menschenlesbare“ Abbild der ausgetauschten PDUs zu verstehen sind. Um die CMIS-Notation überhaupt nutzen zu können, sind Grundkenntnisse über deren Syntax sowie zu den CMISE-Diensten und den zugehörigen Übergabeparametern allein nicht ausreichend. Der Anwender benötigt zudem das Wissen über das Informationsmodell, auf das er sich bezieht - in diesem Falle also das SWT-Informationsmodell.
Ein kleines Beispiel soll dies veranschaulichen: Nach oben stehender Vorgehensweise sind bei der Verwendung des Softwaretracers als erstes die Tracepunkte festzulegen. Hierzu ist dem Agenten (Network Element) eine M-ACTION-Dienstanforderung unter der Angabe mehrerer Parameter zu übersenden. Die Dateneinheit könnte folgendermaßen aussehen:
Abbildung in dieser Leseprobe nicht enthalten
Nun einige Erklärungen zu den M-ACTION-Parametern (vgl. auch Tabelle 1, Seite 19):
- MODE legt fest, ob der Dienst im bestätigten (confirmed) oder nicht-bestätigten (non-confirmed) Modus ausgeführt wird.
- BASE OBJECT INSTANCE bezeichnet die Objektinstanz, auf die die Operation wirken soll. Das die Instanz benennende Attribut »swtMain« ist dabei vom ASN.l-Typ NULL. Die Existenz der Instanz wird durch den Wert »NULL« gekennzeichnet.
-BASE OBJECT CLASS benennt die Klasse der Objektinstanz.
- ACTION TYPE legt die auszuführende objektbezogene Operation fest.
- ACTION INFORMATION beschreibt die an die Operation zu übergebenden Daten. Dabei ist die Syntax dieses Parameters durch eine ASN.1-Typdefinition festgelegt (vgl. auch Kapitel 5.4.7). Sie ist in der Regel für jeden Aktionstyp verschieden. Dies zeigt sehr deutlich, daß der Anwender - will er die CMIS-Notation verwenden - mit dem entsprechenden Informationsmodell vertraut sein muß. Beispielsweise klärt sich die doppelte Angabe von geschweiften Klammern vor und nach der Tracepunktadresse »swAddr« erst durch einen Blick in das ASN.l-Modul auf: Die Schachtelung zweier Strukturen (»SwTpAddr« und »AddrDescription«) zwingt den Anwender der CMIS- Notation zu dieser Schreibweise.
Im folgenden ein Auszug aus den GDMO- und ASN.1-Definitionen des SWT-Informationsmodells nach [Schwarzmann-2], passend zum obigen M-ACTION-Beispiel:[12]
Abbildung in dieser Leseprobe nicht enthalten
Die Erstellung von Management-Dateneinheiten mittels der CMIS-Notation ist nicht nur umständlich, sondern auch noch äußerst zeitintensiv. Obendrein benötigt der Anwender für lediglich einen einzigen Tracepunkt mindestens sechs PDUs. So ist die Benutzung eines CMIS-Editors ratsam, der durch seine graphische Oberfläche und den zahlreichen Auswahlmenüs den Aufbau von Dateneinheiten erheblich erleichtert. Der Anwender kann die entsprechenden Felder des in Abbildung 27 gezeigten Formulars ausfüllen, ohne sich dabei Gedanken über die korrekte Syntax bzw. das jeweilige Informationsmodell machen zu müssen. Unter Verwendung des CMIS-Editors ist demzufolge die Eingabeseite des SWTs recht gut abgedeckt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 27: CMIS-Editor
Lediglich die Ausgabeseite des Softwaretracers stellte bislang ein Problem dar: Die Speicherung der gesamten Korrespondenz zwischen Anwender und SWT (respektive zwischen Manager und Agent) - und damit verbunden die Ausgabe von Tracedaten - erfolgt in sog. Logdateien (vgl. Kapitel 3.5, Log Control Function). Es ist für den Anwender allerdings sehr mühselig, die Tracedaten aus den bis zu einigen Megabyte großen Logdateien herauszufiltern. Infolgedessen war die Entwicklung eines Programms zur Nachbereitung der SWT-Ausgaben gefordert.
Im Rahmen dieser Diplomarbeit wurde die Datenbankanwendung QSTAN (Qx-Softwaretracer- Analysator) basierend auf Microsoft Access ’97 entworfen, die die SWT-Logdateien auf Tracedaten untersucht, diese ausliest und in Tabellen ablegt. Zur Auswertung dieser Daten stehen dem Anwender mehrere Formulare mit unterschiedlichen Funktionen zur Verfügung (z.B. Zeitmessung zwischen Traceereignissen). Näheres hierzu ist der Programmbeschreibung im Anschluß an dieses Kapitel zu entnehmen.
Das Programm QSTAN beruht auf den Vorgaben des SWT-Teams sowie den Ideen des Entwicklers. Welche Funktionen zu erweitern bzw. neu zu implementieren sind, wird allerdings erst der ständige praktische Einsatz zeigen. Für die (nahe) Zukunft ist mit Sicherheit eine benutzerfreundliche Oberfläche zur Bedienung des Softwaretracers wünschenswert. Diese Forderung ergibt sich schon alleine aus der zunehmenden Verbreitung der Q3-Schnittstelle und der damit einhergehenden Verdrängung herstellerspezifischer Lösungen. Sinnvoll erscheint, die Ein- und Ausgabeseite des SWTs - und damit auch die Funktionalitäten des Programms QSTAN - in einem Produkt zu vereinen.
7 Qx-Softwaretracer-Analysator (QSTAN)
7.1 Motivation
Alle durch den SWT im Tracepuffer gesammelten Daten können vom Anwender durch eine M-GET- Dienstanforderung ausgelesen werden. Die Ausgabe erfolgt dabei in Form der CMIS-Notation. Ein Traceeintrag könnte also folgendes Erscheinungsbild besitzen:
Abbildung in dieser Leseprobe nicht enthalten
In obigem Traceeintrag sind nur mit einiger Mühe die wichtigsten Informationen (beispielsweise die „collectedData“-Komponente der Attributliste) zu erkennen. Der Überblick geht allerdings um so leichter verloren, je größer die Ausgabedatei im CMIS-N Format wird.
Die hieraus resultierende zeitaufwendige Analyse aller Traceereignisse gab Anlaß zur Entwicklung des Programms QSTAN.
7.2 Benutzeroberfläche
Die Datenbankanwendung QSTAN unterstützt den Anwender bei der Auswertung von SWT- Logdateien durch eine fensterorientierte Benutzeroberfläche. Dabei kann die Navigation durch das Programm auf zwei unterschiedliche Weisen erfolgen: Entweder mit der programmspezifischen Menü- bzw. Symbolleiste oder mit Hilfe des Startformulars.
7.2.1 Startformular
Unmittelbar nach dem Programmaufruf öffnet sich automatisch das Startformular (Abbildung 28) und ermöglicht somit dem Anwender die Ansteuerung aller wesentlichen Programmfunktionen. Prinzipiell wird es aber nur dann benötigt, wenn die programmspezifischen Menüleisten nicht installiert werden konnten. Andernfalls erscheint das Startformular in minimierter Darstellung.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 28: QSTAN-Startformular
7.2.2 Menüleisten
QSTAN versucht nach dem Start einen Verweis auf die „Microsoft Office 8.0 Object Library MSO97.DLL“ herzustellen, um die programmspezifische Menü- bzw. Symbolleiste installieren zu können (Abbildung 29). Schlägt dieser Vorgang fehl, so müssen zur Ansteuerung sämtlicher Programmfunktionen das Startformular (es ist in diesem Fall automatisch maximiert dargestellt) und die Access-interne Menüleiste verwendet werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 29: QSTAN-Menü- und Symbolleiste
7.3 Konvertierungslauf
7.3.1 Datenkonvertierung starten
Abbildung in dieser Leseprobe nicht enthalten
Um eine einfache Auswertung von SWT-Logfiles zu ermöglichen, extrahiert das Programm zunächst die Tracedaten aus der Datei und legt diese anschließend in der Datenbank ab. QSTAN sucht dabei innerhalb einer Tracerdatei nach „M-GET-Confirmation“-Einträgen und filtert dann die jeweiligen Inhalte anhand von Schlüsselwörtern, die zugleich die Spalten der Tabellen benennen. Diese Aufgabe übernimmt die Programmfunktion »Daten konvertieren«; Abbildung 30 zeigt das entsprechende Formular.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 30: Formular »Daten konvertieren«
Das Formular stellt eine Textzeile bereit, die der vollständigen Angabe des Dateinamens - also mit Laufwerksangabe und Pfad - der zu konvertierenden Logfile dient. Zur Unterstützung bei der Suche einer Tracerdatei im Filesystem genügt ein Mausklick auf die Schaltfläche »Durchsuchen...«. Der erscheinende Standarddateidialog »Öffnen« ermöglicht so die bequeme Navigation im Filesystem (Abbildung 31).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 31 : Standarddateidialog »Öffnen«
Der Tabellenname wird automatisch aus dem Dateinamen - ohne Pfad und Erweiterung - generiert und kann bei Bedarf im dafür vorgesehenen Textfeld geändert werden.
Die Datenkonvertierung wird mit einem Klick auf die entsprechende Schaltfläche gestartet. Die Fortschrittsanzeige am unteren Rand des Formulars gibt Auskunft über den aktuellen Stand des Konvertierungsvorganges. Dieser kann jederzeit mit Hilfe der Schaltfläche »Abbrechen« oder durch Betätigen der Taste »ESC« beendet werden. Nach Abschluß der Konvertierung informiert der »Konvertierungsreport« über die Anzahl der gefundenen Einträge und über etwaige Unstimmigkeiten.
Überdies besteht die Möglichkeit, durch Aktivierung bzw. Deaktivierung eines Kontrollkästchens das Programm zu veranlassen, im Kontext der Konvertierung unbekannte Zeichenfolgen entweder zu überlesen (Voreinstellung) oder diese zur nachträglichen manuellen Bearbeitung an den Anwender freizugeben. Bei sachgemäßer Verwendung der Logdateien, d.h. keine eigenmächtige Editierung nach dem Speicherabzug, ist lediglich ein Fall bekannt, der unbekannte Zeichenfolgen hervorrufen kann: Beinhaltet die „collectedData“-Komponente der Attributliste Hex-Dumps, so kann das Ende einer Dump-Zeile u.U. nicht eindeutig erkannt werden, wenn diese selbst Hochkommas enthält!
7.3.2 Konvertierungsreport
Der »Konvertierungsreport« (Abbildung 32) informiert den Anwender über die Konvertierungszeit, die Anzahl der ausgewerteten Zeilen, die Anzahl der ausgewerteten „M-GET-Confirmation“-Einträge, die Anzahl der gespeicherten Datensätze und über im Verlauf der Konvertierung aufgetretene Fehler.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 32: Formular »Konvertierungsreport«
Nachfolgende (Fehler-) Meldungen sind möglich:
- Fehler bei Dateizugriff: Ein derartiger Fehler kann z.B. durch einen defekten Datenträger oder durch ein nicht bereites Laufwerk ausgelöst werden. Der Konvertierungslauf wird mit sofortiger Wirkung unterbrochen.
- Fehler in Ausdruck (Ursache): In diesem Zusammenhang ist zuerst zu prüfen, ob die SWT- Logdatei richtig von UNIX auf den Arbeitsplatz-PC übertragen wurde. Möglicherweise sind die Zeilen nicht korrekt mit CR/LF abgeschlossen.
- Konvertierung abgebrochen: Die Konvertierung wurde über die Schaltfläche »Abbrechen« oder über die Taste »ESC« manuell beendet.
- Fehler beim Einfügen der Daten: Die Daten eines Blockes werden zunächst gesammelt und anschließend als neuer Datensatz in die Tabelle eingefügt. Sollte hier ein Fehler bei der Ausführung der SQL-Anweisung auftreten, so erscheint in jedem Fall eine zu bestätigende Dialogbox, die Detailinformationen über den fehlerhaften SQL-String bereitstellt.
- Fehler beim Einfügen des Feldes [Name]: Der Anwender hat versucht, für den aktuellen Konvertierungslauf ein neues Schlüsselwort zu definieren, das jedoch nicht als neue Spalte in die Tabelle aufgenommen werden konnte. Eine in jedem Fall zu bestätigende Dialogbox gibt Auskunft über die Fehlerursache.
- Unbek. alphanumerische Zeichenfolge, unbek. Stringfolge, unbek. Zeichen: Die Auswerteroutine des Programms ermittelte ein unbekanntes Wort (evtl. nicht definiertes Schlüsselwort), ein unbekanntes Zeichen (evtl. Schmierzeichen) oder eine nicht zuzuordnende Stringfolge.
7.3.3 Unbekannte Zeichenfolgen bearbeiten
Eine im Kontext der Auswertung unbekannte Zeichenfolge führt, sollte das zugehörige Kontrollfeld aktiviert sein, grundsätzlich zu einer Fehlermeldung im »Konvertierungsreport«. Bei Deaktivierung des Feldes kann diese Zeichenfolge über das in Abbildung 33 dargestellt Formular händisch nachbearbeitet oder als neues Schlüsselwort, das eine neue Spalte in der Tabelle bezeichnen soll, definiert werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 33: Formular »Unbekannte Zeichenfolgen bearbeiten«
Über die Textzeile »Unbekannte Zeichenfolge in Ausdruck« kann eine vom Programm als nicht interpretierbare Zeile durch den Anwender editiert und durch Betätigen der Schaltfläche »Übernehmen« zur weiteren Analyse freigegeben werden.
Ein neues Schlüsselwort kann für den aktuellen Konvertierungslauf über die Textzeile »Neues Schlüsselwort« definiert werden. Weiterhin ist der Datentyp des zugehörigen Wertes festzulegen. Anschließend sind die Einstellungen durch einen Klick auf die Schaltfläche »Übernehmen« an die Konvertierungsroutine zu übergeben.
Folgende Datentypen stehen zur Verfügung: Wert (alphanumerisch), String, Stringfeld und Struktur. Eine etwaige Angabe des Wertbezeichners steht dabei immer vor dem Wert getrennt durch einen Doppelpunkt. Einige Beispiele hierzu:
- Alphanumerischer Wert ohne Wertbezeichner:
SwtMain = NULL counter 644494264
- Alphanumerischer Wert mit Wertbezeichner:
SCOPE standardLevels : wholeSubtree
- String ohne Wertbezeichner:
cps "C00OBDUC"
- Stringfeld mit Wertbezeichner:
collectedData symbolicRepresent : { "(1)", "(2)", ... }
- Struktur ohne Wertbezeichner:
time { hours 10, minutes 20, seconds 30 }
7.4 Datenauswertung
Zur Ansicht und Auswertung von SWT-Logfile-Einträgen stehen insgesamt vier verschiedene
Formulare mit unterschiedlichen Funktionen zur Verfügung:
- Die »Detailansicht« stellt alle Felder eines Datensatzes dar (s. Kap. 7.4.1).
- Die »Tabellarische Datenansicht« gibt einen Überblick über alle Datensätze (s. Kap
- Die »Laufzeitmessung« ermittelt Zeitdifferenzen zwischen einzelnen Ereignissen (s
- Die »Datenblattansicht« öffnet eine generierte Tabelle (s. Kap. 7.4.4).
Auf den Formularen zur Datenansicht befinden sich - je nach Aufgabe - eine unterschiedliche Anzahl von Steuerelementen. Einige davon sind nahezu auf jedem Formular vorhanden; ihre Funktionen seien vorweg schon einmal erläutert:
- Das Kombinationsfeld »Tabellenname« dient der Auswahl derjenigen Tabelle, deren Inhalte (Tracedaten) der Anwender betrachten möchte.
- Über das Kombinationsfeld »Abfrage« lassen sich Sortier- und/oder Filterkriterien einstellen, die unmittelbar auf die Datensätze der ausgewählten Tabelle wirken. Hinweise zur Erstellung von benutzerdefinierten Abfragen sind im Kapitel 7.5.1 zu finden.
- Die Befehlsschaltfläche »Drucken« ermöglicht die Ausgabe ausgewählter Datensätze auf den Drucker oder in eine Textdatei (siehe Kapitel 7.4.5).
7.4.1 Detailansicht
Menüleiste: QSTAN | Detailansicht
Abbildung in dieser Leseprobe nicht enthalten
Das Formular »Detailansicht« (Abbildung 34) ermöglicht dem Anwender die Betrachtung aller Daten eines Traceeintrages.
Die Steuerung durch das Abfrageergebnis erfolgt anhand der sich am unteren linken Rand des Formulars befindlichen Navigationsschaltflächen. Sie bieten die Möglichkeit, auf einfache Weise zum ersten, vorigen, nächsten, letzten oder zu einem leeren (neuen) Datensatz zu gelangen. Das Datensatznummernfeld zwischen den Schaltflächen zeigt die Nummer des aktuellen Datensatzes an. Die Gesamtzahl der (gefilterten) Datensätze wird neben den Schaltflächen angezeigt. Durch das Eingeben einer Zahl in das Datensatznummernfeld kann der Anwender direkt zu einem bestimmten Datensatz gelangen.
Die Schaltfläche »Suchen« ermöglicht die Ermittlung eines bestimmten Datensatzes innerhalb des aktuellen Abfrageergebnisses. Das Programm greift hierbei auf die Access-interne Suchfunktion zurück, die die Einstellung verschiedener Suchkriterien erlaubt. U. a. kann die Suche in nur einem Feld (das zuletzt aktive Feld vor dem Klick auf die Schaltfläche »Suchen«) oder in allen Feldern erfolgen.
Hinweis: Die Editierung von Einträgen (auch das Löschen und Hinzufügen ganzer Datensätze) ist nur dann möglich, wenn das Kontrollfeld »Datensatz bearbeiten zulassen« markiert ist.
7.4.2 Tabellarische Datenansicht
Menüleiste: QSTAN | Tabellarische Datenansicht
Abbildung in dieser Leseprobe nicht enthalten
Das Formular »Tabellarische Datenansicht« (Abbildung 35) verschafft dem Anwender einen Überblick über alle vorhandenen Datensätze (Traceeinträge). Die im Listenfeld angezeigten Felder können dabei benutzerdefiniert zusammengestellt werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 35: Formular »Tabellarische Datenansicht« (Seite 1)
Das Formular verfügt über zwei Seiten; zwischen ihnen kann mit Hilfe der Schaltflächen »Datenübersicht« bzw. »Einstellungen« gewechselt werden. Die zweite Seite (Abbildung 36) erlaubt die Festlegung aller im Listenfeld ein- bzw. ausgeblendeten Felder. Je nach Anforderung kann der Nutzer mittels der Pfeiltasten die in den beiden Auswahlfenstern aufgelisteten Feldnamen verschieben und somit die Datenübersicht individuell gestalten. Diese Einstellungen werden nach dem Schließen des Formulars automatisch gespeichert und stehen daher beim nächsten Aufruf wieder zur Verfügung.
Die Schaltfläche »Wiederherstellen« setzt die Liste der ein- bzw. ausgeblendeten Felder auf den zuletzt gesicherten Stand zurück; »Rücksetzen« verwendet dagegen die programminterne Vorauswahl. Zur Ansicht aller Daten eines Traceintrages (»Detailansicht«) genügt ein Doppelklick auf einen im Listenfeld markierten Datensatz.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 36: Formular »Tabellarische Datenansicht« (Seite 2)
7.4.3 Laufzeitmessung durchführen
Menüleiste: QSTAN | Laufzeitmessung
Abbildung in dieser Leseprobe nicht enthalten
Das Formular »Laufzeitmessung« (Abbildung 37) unterstützt den Anwender bei der Ermittlung von Zeitdifferenzen zwischen einzelnen Traceereignissen.
Abbildung in dieser Leseprobe nicht enthalten
Die Bildung der Zeitdifferenzen kann unter Verwendung des Optionsfeldes »Bezugspunkt« gesteuert werden:
- »Relativ zum nächsten Datensatz«, d.h. die Differenzbildung erfolgt immer zwischen aufeinanderfolgenden Datensätzen des Abfrageergebnisses.
- »Absolut zu gewähltem Datensatz«, d.h. die Differenzbildung erfolgt mit einem im Listenfeld markierten Datensatz.
Um eine aussagekräftige Laufzeit zu erhalten, wird die jeweilige Counter-Differenz mit der „Granularität“ von 193 Nanosekunden multipliziert. Die Spalte »Delta« enthält dann die bereits in Millisekunden umgerechnete Zeitdifferenz.
Zur Ansicht aller Daten eines Traceintrages (»Detailansicht«) genügt ein Doppelklick auf einen im Listenfeld markierten Datensatz.
7.4.4 Datenblattansicht
Menüleiste: QSTAN | Datenblattansicht
Abbildung in dieser Leseprobe nicht enthalten
Das Formular »Datenblattansicht« (Abbildung 38) dient dem (schreibgeschützten) Öffnen einer generierten Tabelle. Diese Option ist insbesondere dann zu wählen, wenn Tracedaten manuell nachbearbeitet oder die Inhalte von neu definierten Tabellenspalten ausgewertet werden sollen. Für einen Überblick auf alle Traceeinträge ist besser das Formular »Tabellarische Datenansicht« zu verwenden (siehe Kapitel 7.4.2).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 38: Formular »Datenblattansicht«
7.4.5 Daten drucken
Das Formular »Daten drucken« (Abbildung 39) ermöglicht dem Anwender die Ausgabe von Tracedaten ausgewählter Datensätze auf dem Standarddrucker oder die Speicherung dieser in einer Textdatei. Es enthält ein Listenfeld, das die einfache Selektion aller zu druckenden Datensätze erlaubt. Dabei bewirkt das gleichzeitige Betätigen der Taste »Shift« die Markierung eines Blockes innerhalb des Listenfeldes, bzw. die Taste »Ctrl«, eine Auswahl einzelner Datensätze. Ein Mausklick auf die Schaltfläche »Datensätze drucken« startet den Druckvorgang.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 39: Formular »Daten drucken« (Register »Auswahl«)
Dem Anwender stehen in der Registerkarte »Optionen« folgende zusätzliche Funktionen bereit (siehe Abbildung 40):
- Das Feld »Kopfzeilentext« stellt Platz für Anmerkungen auf der ersten Seite des Ausdruckes bereit. Dabei ist zu beachten, daß bei der Eingabe für einen Zeilenumbruch die Tastenkombination »Ctrl« + »Return« zu verwenden ist.
- Um ggf. die Lesbarkeit des Ausdruckes zu verbessern, kann das Kontrollkästchen »Schmalschrift verwenden« deaktiviert werden.
- Soll der Ausdruck in eine Textdatei umgeleitet werden, so ist das Kontrollkästchen »Druck in Datei« zu markieren. Der Anwender wird dann nach der Erteilung des Druckauftrages automatisch aufgefordert, über den Standarddateidialog »Datei speichern unter« die Zieldatei festzulegen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 40: Formular »Daten drucken« (Register »Optionen«)
7.5 Weitere Programmfunktionen
7.5.1 Abfragen erstellen
Abbildung in dieser Leseprobe nicht enthalten
Während der Auswertung der Tracedaten ist es häufig erforderlich, diese nach bestimmten Kriterien zu sortieren und/oder zu filtern. Aus diesem Grund ermöglicht das Programm QSTAN die Definition von benutzerspezifischen Abfragen. Jede Abfrage besitzt einen eindeutigen Namen, um diese in den Formularen zur Datenauswertung auch anwählen zu können. Drei immer wieder benötigte Abfragen sind bereits durch die Datenbankanwendung fest vorgegeben:
Abbildung in dieser Leseprobe nicht enthalten
Benutzerdefinierte Abfragen können über das in Abbildung 41 dargestellte Formular erstellt, bearbeitet und wieder gelöscht werden. Zur Erstellung einer benutzerdefinierten Abfrage ist zunächst für diese ein neuer Name in das Feld »Abfrage« einzugeben. Nach der Bestätigung mit »Return« können anschließend die Filterkriterien im WHERE-Abschnitt und/oder die Sortierkriterien im ORDER BY-Abschnitt nach der SQL-Syntax festgelegt werden. Mit einem Mausklick auf die Befehlsschaltfläche »Speichern« wird die neu erstellte Abfrage auf den Formularen zur Datenauswertung anwählbar.
Die Bearbeitung von bereits bestehenden Abfragen erfolgt sinngemäß nach obigem Schema; zum Entfernen von Abfragen findet die Befehlsschaltfläche »Löschen« Verwendung.
Abbildung in dieser Leseprobe nicht enthalten
Im folgenden nun eine kleine Zusammenfassung der wichtigsten Syntaxregeln von SQL:
Der WHERE-Abschnitt legt die Filterkriterien fest; er ist prinzipiell optional. Ist die WHERE-Klausel in einer SQL-Abfrage vorhanden, so werden bei der Datenauswertung nur die Datensätze angezeigt, die den Bedingungen im WHERE-Abschnitt entsprechen.
Abbildung in dieser Leseprobe nicht enthalten
Ein WHERE-Abschnitt kann bis zu 40 Ausdrücke enthalten, die durch logische Operatoren verknüpft sind. Die logischen Operatoren werden dabei in der Reihenfolge NOT, AND, OR und XOR ausgeführt. Um die Reihenfolge der Bearbeitung zu steuern, können die einzelnen Ausdrücke mit runden Klammern gruppiert werden. Die Feldbezeichner sind dabei der Eindeutigkeit halber in eckige Klammern zu setzen, z.B.:
- Anzeige aller Datensätze, deren Invoke Identifier zwischen zwei Werten liegt:
WHERE [INVOKE IDENTIFIER] Between 300 And 305
- Anzeige aller Datensätze, deren Identifier gleich einem bestimmten Wert entspricht:
WHERE [id] = "SI09ID01"
Der ORDER BY-Abschnitt bestimmt die Sortierkriterien; er ist prinzipiell optional. Sollen bei der Auswertung der Daten diese in einer bestimmten Reihenfolge erscheinen, so ist die ORDER BY- Klausel zu verwenden.
Abbildung in dieser Leseprobe nicht enthalten
Es können mehrere Felder getrennt durch Kommata angegeben werden, wobei jeder Feldbezeichner in eckige Klammern zu setzen ist. Das erste in der Parameterliste genannte Feld stellt das primäre Sortierkriterium dar. Datensätze, deren Werte sich in diesem Feld nicht unterscheiden, werden dann nach dem zweiten in der Parameterliste genannten Feld sortiert usw. Die Sortierreihenfolge ist dabei standardmäßig aufsteigend; diese kann aber durch das Anfügen des Schlüsselwortes »DESC« an einen Feldnamen umgekehrt werden, z.B.:
- Sortierung aufsteigend nach dem Identifier und aufsteigend nach der Zeilennummer:
ORDER BY [id], [Line#]
- Sortierung aufsteigend nach dem Identifier und absteigend nach der Zeilennummer:
ORDER BY [id], [Line#] DESC
7.5.2 Tabellen löschen
Abbildung in dieser Leseprobe nicht enthalten
Zum Entfernen nicht mehr benötigter Tabellen aus der Datenbank ist das Formular »Löschen von Tabellen« zu verwenden (Abbildung 42). Es enthält ein Listenfeld, das alle in der Datenbank vorhandenen Tabellen anzeigt und so eine einfache Selektion aller zu löschenden Tabellen mit Hilfe der Maus ermöglicht. Dabei bewirkt das gleichzeitige Betätigen der Taste »Shift« die Markierung eines Blockes innerhalb des Listenfeldes, bzw. die Taste »Ctrl«, eine Auswahl einzelner Tabellen. Mit einem Klick auf die Schaltfläche »Löschen« wird der Löschvorgang gestartet.
Die Fortschrittsanzeige am unteren Rand des Formulars gibt dabei Auskunft über den aktuellen Löschstatus. Der Vorgang kann jederzeit mit einem Klick auf die Schaltfläche »Abbrechen« bzw. durch Drücken der Taste »ESC« abgebrochen werden. Die bereits entfernten Tabellen werden dann - wie im Fall eines Fehlers - wieder selbständig hergestellt.
Abbildung in dieser Leseprobe nicht enthalten
7.5.3 Datenbank komprimieren
Abbildung in dieser Leseprobe nicht enthalten
Das Löschen von Tabellen kann zu einer Fragmentierung der Datenbank und zu einer ineffizienten Nutzung des Speicherplatzes auf der Festplatte führen. Aus diesem Grund ist es ratsam, hin und wieder die Datenbank zu komprimieren.
7.5.4 Speichern von Programmeinstellungen
QSTAN speichert alle Programmeinstellungen automatisch in der Windows-Registrierung unter dem folgenden Schlüssel ab:
HKEY_CURRENT_USER\SOFTWARE\VB and VBA Settings\
QSTAN - Qx-Softwaretracer-Analysator\<Hauptversionsnummer>
Sollte es durch fehlerhafte Einstellungen zu Schwierigkeiten kommen, so können durch Drücken der Tastenkombination »Ctrl« + »Alt« + »C« auf dem Startformular die Registrierungseinträge gelöscht werden.
7.5.5 Online-Hilfe
Abbildung in dieser Leseprobe nicht enthalten
Wie jedes (gute) Windows-Programm verfügt auch QSTAN über eine Online-Hilfe, die alle notwendigen Informationen zu den einzelnen Programmpunkten bereitstellt. Durch Betätigen der Taste »F1« können wie gewohnt gezielt Hinweise zu einem gerade aktiven Formular abgerufen werden.
7.6 Programminformationen
7.6.1 Systemanforderungen
Die Datenbankanwendung QSTAN ist vollständig mit Hilfe von „Visual Basic for Applications 5“ programmiert worden. Es ergeben sich somit folgende Systemanforderungen:
- Microsoft Access ’97 (Office-Version 8.0)
- Microsoft Windows NT 4.0 (oder höher) bzw. Windows 95 (oder höher)
7.6.2 Bezugsquelle
Die jeweils neueste Version von QSTAN kann als Zip-File über folgende Intranet-Adresse bezogen werden:
http://intranet.icn.siemens.de:80/wn/cs/cseb/ebc/ebc16/download.htm
Zip-File einfach in das gewünschte Verzeichnis entpacken, die Datei QSTAN.MDE über den Windows-Explorer starten - das war’s.
Hinweis: Die der Diplomarbeit beiliegende CD-ROM enthält die vollständige Datenbankanwendung QSTAN in der Programmversion 1.05 inkl. Quelltext sowie einige SWT-Beispieldateien (weitere Info’s sind der Datei „Readme.txt“ zu entnehmen).
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Literaturverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Danksagung
Mein besonderer Dank gilt Hans-Martin Wiest, der mir die Durchführung der Diplomarbeit ermöglicht hat und Bernd Schwarzmann für die hervorragende Betreuung.
Weiterhin danke ich Gerhard Goller und Michael Ullrich, die meine Arbeit durch ständige Unterstützung mit ihrem Fachwissen gefördert haben, sowie allen weiteren Kollegen, die mir in jeder Hinsicht mit Rat und Tat zur Seite standen.
Hr. Pichler und Hr. Strassser der Siemens AG Österreich danke ich für die freundliche Überlassung ihrer Studienarbeit zum Thema „ASN.1“
Ich danke außerdem recht herzlich Andrea Wuske für das Korrekturlesen, Christine Baumgärtel für die Beantwortung meiner Fragen bezüglich der in einigen Fällen doch recht kniffligen deutschen Rechtschreibung sowie Michael Dankl für die Überprüfung auf Verständlichkeit und das Brennen der CD’s.
Name, Vorname: Baumgärtel, Oliver
Geburtsdatum, -ort: 04.01.1971, München
Studiengruppe: 06 PH 8T im WS 1998/99
Erklärung
gemäß § 31 Abs. 5 RaPO
Hiermit erkläre ich, daß ich die Diplomarbeit selbständig verfaßt, noch nicht anderweitig für Prüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfsmittel benützt sowie wörtliche und sinngemäße Zitate als solche gekennzeichnet habe.
München, den 01.03.1999
[...]
[1] ehemals CCITT (Comité Consultatif International de Télégraphique et Téléphonique)
[2] TCP/IP als weit verbreiteter Industriestandard im Datentransferbereich wird oft auch als „quasi-offener“ Standard bezeichnet.
[3] Für einige Hauptschichten sind zudem Unterschichten definiert, auf die hier aber nicht näher eingegangen werden soll.
[4] Definition nach [Schulte]
[5] Eine Klasse ist als Typ eines Objektes bzw. ein Objekt ist als Instanz einer Klasse aufzufassen.
[6] Definition nach ITU-T Empfehlung X.700
[7] Unter dem Begriff Policies werden Vorgaben verstanden, nach denen das Management durchzuführen ist.
[8] Definition nach [Gora]
[9] Das Auslassen einer DEFAULT-Komponente ist identisch mit der Zuweisung des DEFAULT-Wertes.
[10] Sinngemäß nach [Flug]
[11] Wesentlicher Vorteil: Das Management wird unabhängig von der Last im Nutznetz (und umgekehrt)!
[12] Sämtliche SWT-Funktionen werden durch M-ACTIONs angesprochen, mit Ausnahme des Auslesens des Tracepuffers, das über den CMISE-Dienst M-GET geschieht. Obwohl der SWT nach „außen“ auf einem mittels GDMO spezifizierten Informationsmodell basiert, erfolgt jedoch nie eine Instantiierung von Objekten (hierzu wäre die Verwendung des Dienstes M-CREATE erforderlich). Dies bedeutet, daß der SWT intern keinen objektorientierten Ansatz verwendet!
- Arbeit zitieren
- Oliver Baumgaertel (Autor:in), 1999, Bereitstellung einer Datenbankanwendung zur Auswertung von Q3-Protokolldateien eines Tracers im Rahmen der Softwareentwicklung für EWSD-Vermittlungssysteme, München, GRIN Verlag, https://www.grin.com/document/99995
Ähnliche Arbeiten
Kostenlos Autor werden
Kommentare