Diplomarbeit

DIPLOMARBEIT
Feldbus-Netzwerkmanagement mit SNMP
ausgeführt am Institut für Computertechnik
der Technischen Universität Wien
unter der Anleitung von
o.Univ. Prof. Dr. Dietmar Dietrich
und
Univ. Ass. Dipl. Ing. Richard Schmalek
Univ. Ass. Dipl. Ing. Roman Weisgärber
Univ. Ass. Dipl. Ing. Thilo Sauter
Dr. Manfred Siegl
als verantwortlich mitwirkende Universitätsassistenten
durch
Martin Knizak
Türkenbundgasse 10; 2102 Bisamberg
Matr.Nr. 8525426
Wien, 25. Februar 1999
........................................
(Unterschrift)
Feldbus-Netzwerkmanagement mit SNMP
Abstract
Feldbusse erlauben den Einsatz von einfachen Sensoren und Aktoren ohne großen Overhead an
Protokoll. Um aber auf diese Werte ohne detailiertes Fachwissen zugreifen zu können, erscheint
es wünschenswert, dies an Hand eines weit verbreiteten und leicht verständlichen Protokolls zu
machen. Ein Protokoll das diese Vorzüge besitzt, ist SNMP (Simple Network Management).
In der vorliegenden Ausarbeitung werden die theoretischen Grundlagen dargelegt und aufbauend
auf diese Lösungsmöglichkeiten vorgestellt. Die, für diese Aufgabe am besten geeignete, wurde
aufbauend auf der von Funkamateuren verwendeten Programmsammlung KA9Q auf einem PC
unter MS/DOS implementiert. Da auf einen modularen Aufbau geachtet wurde, können die für
das Feldbussystem PROFIBUS gewonnenen Erkenntnisse leicht auf andere Systeme übertragen
werden.
Die erstellte Anwendung ist kostengünstig und ohne Vorkenntnisse verwendbar. Es handelt sich
aber nicht um ein in zeitkritischen Umgebungen einsetzbares System, da die verwendeten
Protokolle, wie etwa das Internetprotokoll, dies nicht zulassen.
Inhaltsverzeichnis
1. Situationsanalyse
1
2. Aufgabenstellung und Lösungsansatz
5
2.1. Feldbusse .................................................................................... 5
2.2. Netzwerkmanagementprotokolle .................................................. 6
3. Das ISO/OSI Modell
7
4. SNMP und unterlagerte Protokolle
9
4.1. IP ................................................................................................ 9
4.2. UDP.......................................................................................... 12
4.3. SNMP........................................................................................ 13
4.4. Die MIB-Struktur ...................................................................... 15
4.5. Zugriff auf Elemente der MIB.................................................... 17
4.6. ASN.1 (Abstract Syntax Notation One) ...................................... 19
5. Der PROFIBUS
22
5.1. Profibus-FMS (Fieldbus Message Spezifikation) ....................... 22
5.2. Profibus-DP (Dezentrale Peripherie) ........................................ 23
5.3. Profibus-PA (Prozeßautonatisierung)........................................ 23
5.4. Schichten 1 und 2 ...................................................................... 23
5.5. Schicht 7 ................................................................................... 24
6. Analyse der Kopplungsmöglichkeiten
28
6.1. Router mit PROFIBUS-Protokoll .............................................. 29
6.2. Router mit SNMP-Protokoll....................................................... 30
6.3. Gateway .................................................................................... 31
7. Interne Informationsstrukturen
33
7.1. Definition der neuen MIB.......................................................... 34
7.2. Beschreibung in ASN.1.............................................................. 35
8. Grundsätzliche Konzeption der Tasks
43
9. Realisierung der SNMP-Seite
45
9.1. KA9Q ........................................................................................ 45
9.2. Starten des vorhandenen Systems .............................................. 46
I
Inhaltsverzeichnis
9.3. Einfügen eines Tasks in den Kernel ........................................... 47
9.4. Datenstruktur von UDP und Zugriffsverfahren.......................... 49
9.5. Darstellung von ASN.1 Paketen in C-Strukturen........................ 50
9.6. Zugriff auf im System vorhandene Werte ................................... 50
10. Realisierung der PROFIBUS-Seite
54
10.1. Installation der PROFIBUS-Karte........................................... 54
10.2. Test der PROFIBUS-Karte ...................................................... 54
10.3. Projektierung der PROFIBUS-Seite......................................... 55
10.4. Der zweite Teil der Struktur Feld_Knoten................................ 56
10.5. Der PROFIBUS-Task .............................................................. 58
10.6. Zusätze beim SNMP-Task ........................................................ 60
11. Zusammenfassung der gemachten Änderungen
65
12. Der Weg eines Paketes durch das Gateway
67
13. Erstellung einer beispielhaften Anwendung
70
14. Resümee und Aussichten
74
II
Situationsanalyse
1. Situationsanalyse
Noch vor einigen Jahren war ein Stand-alone-Rechner gang und gäbe. Heute jedoch bilden für
sich alleine arbeitende Computer eine Seltenheit. Nicht nur in Firmen und wissenschaftlichen
Einrichtungen ist die Vernetzung üblich geworden, sondern auch in privaten Haushalten wird der
Computer immer öfter via Modem mit anderen Rechnern verbunden. Diese Verbindungen basieren auf den unterschiedlichsten Hardware-Komponenten. Einen gemeinsamen Punkt dieser Vernetzung bildet das Internetprotokoll. Dieses Transportprotokoll ist für nahezu alle Typen von
Rechnern und physikalischen Netzwerken erhältlich. So stellt es kein Problem dar, einen UNIXRechner mit einer Ethernet-Karte und einen MS-DOS-Rechner, der an einen Tokenring angeschlossen ist, über einen Router miteinander zu verbinden. Dies hier in kurzen Worten dargestellte
Gebilde ist allgemein unter dem Begriff Internet bekannt. Falls ein Netzwerk aus Sicherheits- oder
anderen Gründen nicht mit anderen Netzwerken verbunden ist, nennt man es Intranet.
Aber nicht nur in den Bereichen, wo große Datenmengen transportiert werden sollen und die
Übermittlungszeit als unangenehm, aber nicht als kritischer Parameter angesehen wird, hat die
Vernetzung Einzug gehalten. Auch in der Zell- und Feldebene geht man daran, immer mehr zu
vernetzen. In diesen Bereichen handelt es sich um eher kleine Datenmengen, die aber meist in
Echtzeit übermittelt werden müssen. Speziell für diese Bedürfnisse zugeschnitten, wurden eigene
Bussysteme entwickelt - die Feldbusse. Im Gegensatz zum Internet existieren etliche Feldbussysteme, die von Firmen oder Firmengruppen entwickelt worden sind und von diesen unterstützt
und beworben werden. Von einem einheitlichen Standard ist man bei den Feldbussen weit entfernt. Selbst die erste europäische Norm über Feldbusse (EN50170) enthält drei unterschiedliche
Systeme (nämlich PROFIBUS, P-Net und WorldFIP). Ob sich so wie beim Internetprotokoll ein
einheitlicher Standard herausbilden wird, kann aus heutiger Sicht noch nicht gesagt werden. Falls
sich jedoch ein System durchsetzt, muß es mit schon bestehenden wie dem Internet interagieren
können, da es notwendig ist, Feldbusse nicht nur als Insellösungen anzusehen, damit die Vorteile
voll ausschöpft werden.
Um die Abläufe auf einem Feldbus zu protokollieren und unter Umständen auch zu visualisieren,
genügt ein einfacher PC (Personal Computer) mit einer dem Feldbus entsprechenden
Einsteckkarte und einem gängigen Programm, wie zum Beispiel MS-Excel oder Access. Mit
dieser Ausrüstung lassen sich einfache Statistiken leicht und kostengünstig erstellen und auch
graphisch aufbereiten. Ein Nachteil ist hingegen die Konzentration auf einen einzelnen Rechner.
Es lassen sich zwar die Protokolldateien leicht mit Diskette oder auf elektronischem Weg auch
mit anderen Geräten weiterverarbeiten, es bestehen aber viele Vorteile, die eine allgemein
genormte Übermittlung der Rohdaten wünschenswert machen. Eine Einbindung von Feldbussen
in das Internet mittels SNMP ist dabei ein zweckmäßiger Ansatz, da SNMP eine standardisierte,
globale Struktur bietet, die für das Internet maßgeschneidert ist.[SIE95]
1
Situationsanalyse
Diese und ähnliche Überlegungen führen zu dem Schluß, daß es gut wäre, die zwei schon heute
existierenden, aber getrennten Welten des Internets und der Feldbusse zu verbinden. Damit wäre
der Einsatz des jeweils der Situation angepaßten Systems möglich, da man mit dem anderen
ebenfalls darauf zugreifen könnte.
Ein gerne in diesem Zusammenhang erwähntes Beispiel sind Temperatursensoren. Bei mehren
Sensoren, deren Werte man über Internet zugänglich haben möchte gibt es derzeit zwei Wege:
1. Man verbindet jeden Sensor mit einem zentralen Computer. Dies hätte einen enormen Verkabelungsaufwand zur Folge. Weiters müßte dafür gesorgt werden, daß genügend ansprechbare Eingabeports vorhanden wären.
Temperatursensoren
PC
Internet
Abb. 1.1
Temperatursensoren Variante 1
2. Man plaziert neben jeden Sensor einen Computer oder ein anderes Internet-taugliches Gerät.
Dies würde eine große Zahl an Internet Geräten erfordern. Ein weiterer nicht zu unterschätzender Faktor wäre die notwendige Anzahl an Internetadressen, da bei dieser Variante
jeder Sensor eine eigene besitzen müßte.
2
Situationsanalyse
Pc mit angeschlossenem Temperatursensor
Internet
Abb. 1.2
Temperatursensoren Variante 2
Jede dieser beiden extremen Varianten, so wie auch eine Mischung beider, hat bedeutende Nachteile. Eine Lösung dieses Problems bietet die Verbindung der Internets mit einem Feldbus. Alle
Sensoren können dann ohne großen Verkabelungsaufwand an den Feldbus angeschlossen werden.
Der Feldbus selbst ist mit einer Internetadresse ansprechbar und liefert über eine wie auch immer
geartete Verbindung die gewünschten Daten.
3
Situationsanalyse
Temperatursensor mit Feldbusknoten
Feldbus
Internet
PC
Abb. 1.3
Temperatursensoren Variante 3
Die Begriffe PC und Internet stehen hier nur als Synonyme für einerseits ein mit Feldbusanschluß
und LAN Anschluß ausgestattetes Gerät sowie für ein bestehendes Netzwerk zur
Kommunikation.
4
Aufgabenstellung und Lösungsansatz
2. Aufgabenstellung und Lösungsansatz
Auf Grund dieser anfänglich gestellten Überlegungen ergibt sich folgende Ausgangssituation: Eine
Kopplung von Feldbussen und Internet-Geräten wird angestrebt. Die folgenden Seiten werden
ausgehend von diesem Erfordernis zeigen welche Möglichkeiten sich bieten, welche Vorteile sie
verheißen und welche Schlüsse daraus zu ziehen sind.
Primäre Aufgaben, die sich stellen, sind:
• Art der Einbindung ins Inter- oder Intranetz
• Auswahl des Feldbussystems
• Ausgehend von diesen Erkenntnissen ergibt sich eine ausgearbeitete Implementation
Da es nicht zielführend ist, grundlegende Überlegungen auf eine spezielle Implementierung auszurichten, wurde ein PC als Kopplgerät gewählt. Für dieses Gerät existieren eine Menge von
Programmen, die leicht und kostengünstig zu erwerben sind. Weiters sind für fast alle Feldbusse
PC-Einsteckkarten am Markt. Dies schränkt die Auswahl des Systems nicht ein. Die Programmiersprache C, die gewählt wurde, ist weit verbreitet, und für die unterschiedlichste Hardware
gibt es C-Compiler. Obwohl es verschiedene Varianten davon gibt, kann man davon ausgehen,
daß eine Portierung auf andere Systeme möglich ist, wenn man versucht, alle compilerspezifischen
Befehle zu vermeiden und nur Ansi C-Befehle verwendet. Diese Voraussetzungen ermöglichen
auch, die gesamte Implementierung mit Ausnahme der Hardwaretreiber auf anderen Systemen als
PCs unter MSDOS zu verwenden. Das als Grundlage verwendete Programmpaket hat als
weiteren Vorteil, daß es auch auf UNIX, CPM und Amiga-Geräten funktionsfähig ist.
2.1. Feldbusse
Um den unterschiedlichen Anforderungen der Anwender gerecht zu werden, entstanden speziell
auf einfache Sensoren und Aktuatoren sowie auf kurze Reaktionszeiten zugeschnittene Vernetzungssysteme für die Feldebene, die Feldbusse. Derzeit sind mehrere unterschiedliche Systeme
dabei, international genormt zu werden. Drei dieser Systeme sind bereits in einer europäischen
Norm zusammengefaßt. Dies sind P-Net, PROFIBUS und World-FIP. Zusätzlich zu diesen in der
EN50170 [EN50170] genormten Bussen gibt es noch Interbus-S, CAN und LON, um nur einige
zu nennen. Viele Firmen verwenden auch proprietäre Systeme.
Die Struktur dieser Systeme ist sehr unterschiedlich. Eine grobe Einteilung kann beispielsweise
durch die Anzahl der Master-Stationen getroffen werden. Die Monomastersysteme wie etwa
PROFIBUS-DP und -PA oder Interbus-S bieten größere Geschwindigkeiten und einfachere
5
Aufgabenstellung und Lösungsansatz
Programmierung. Sie sind jedoch zentral ausgerichtet und damit sehr von der Funktionfähigkeit
der Masterstation abhängig. Eine Verteilung der Aufgaben auf mehrere intelligente Geräte ist
nicht möglich. Multimastersysteme wie PROFIBUS-FMS, P-Net oder LON haben zwar nicht die
große Geschwindigkeit, aber bei Ausfall eines Masters bleibt der Rest des Systems funktionsfähig.
Eine Modularisierung und Verteilung der Aufgaben auf verschiedene Geräte ist nicht nur
möglich, sondern Grundidee dieser Systeme.
Bei der Auswahl des Feldbusses wurde ein zum Zeitpunkt der Erstellung schon genormtes System
verwendet, da die zukünftige Entwicklung der anderen Systeme nicht vorhergesagt werden kann.
Von diesen Systemen ist PROFIBUS das im deutschsprachigen Raum verbreitetste und wurde
deshalb für die Implementierung verwendet. Eine Erweiterung des Konzeptes auf andere
Bussystemen ist nach derselben Strategie leicht möglich.
Da PROFIBUS in mehreren Varianten erhältlich ist, bleibt noch die Frage offen welche letztendlich für die Implementierung ausgewählt werden sollte. Da PROFIBUS-FMS im Normalfall
aus mehreren Mastern und auch mehreren Slaves besteht, die anderen Varianten aber nur aus
einem Master bestehen, kann man aus dem FMS-Spezialfall mit nur einem Master die Grundstruktur für alle anderen ableiten. Die sich ergebenden programmtechnischen Änderungen werden
im entsprechenden Abschnitt noch genauer erörtert.
2.2. Netzwerkmanagementprotokolle
Nachdem das Feldbussystem ausgewählt ist, bleibt noch die Frage, wie die Information auf der
Internetseite verfügbar sein und dargestellt werden soll. Da es sich um Werte eines Netzwerkes
handelt, liegt es nahe, die verschiedensten Tools und Protokolle des Internets auf ihre Tauglichkeit für diesen Zweck zu untersuchen.
Die einfachsten Netzwerktools wie etwa ping und traceroute helfen nur, den Weg durch das Netz
bzw. die Existenz einer anderen Station zu erkunden. Um die Netzwerkskonfiguration oder Werte
zu erfragen, sind effizientere Werkzeuge und Protokolle nötig. Diese stellen dann auch eine gute
Strukturierung ihrer Werte zur Verfügung. Die zwei bekanntesten Protokolle sind CMIP
(Common Management Information Protokol) und SNMP (Simple Network Management
Protokol). SNMP ist das ältere und stellt die Werte in einem hierarchisch geordneten Namensraum dar. Der Nachteil dieses Protokolls ist, daß es nicht genau in das OSI- Modell paßt. Der
Vorteil ist, daß es weit verbreitet und einfach aufgebaut ist. CMIP ist ein von ISO genormtes
Protokoll. In CMOT wird beschrieben, wie CMIP für das Management von TCP/IP Netzen
verwendet werden kann. Wie SNMP verwendet es ebenfalls einen Namensraum zur Darstellung
des Netzes. Die Vorteile sind die Normung und die Konformität zu ISO. Nachteilig ist die geringe
Verbreitung. Der Verbreitung wegen, die die Nachteile bei weitem aufwiegt, wurde für die
Implementierung SNMP ausgewählt.
6
Das ISO/OSI Modell
3. Das ISO/OSI Modell
Um den Austausch von Daten zwischen Rechnern zu ermöglichen, erstellte man um 1980 von der
International Organisation of Standartisation (ISO) ein Referenzmodell, das rechnerunabhängig
war. Das so entstandene, noch keine spezielle Implementierung fordernde OSI (Open Systems
Interconnection)-Modell ist in 7 Schichten unterteilt. Jede Schicht stellt der darüberliegenden ihre
Dienste zur Verfügung und nimmt die der darunterliegenden in Anspruch. Da eine
Kommunikation immer zwischen den beiden Partnerschichten stattfindet und die Daten ohne
inhaltliche Interpretation von der darunterliegenden Schicht als „black box“ übertragen werden,
steigt beim Hinunterwandern der Date die Länge des Paketes immer mehr an (ausgenommen es
muß ein Paket auf Grund der maximalen Länge geteilt werden, dann steigt nur die Gesamtsumme
der Längen an). Bei der Partnerstation wird das Datenpaket wie eine Zwiebel geschält, bis in der
Partnerschicht nur mehr die Nutzdaten, oder die der darüberliegenden Schicht zu übergebenden
Daten plus eigene Informationen vorhanden sind.
Schicht 7
Anwendungsschicht
(application layer)
Schicht 6
Darstellungsschicht
(presentation layer)
Schicht 5
Sitzungsschicht
(session layer)
Schicht 4
Tranportschicht
(transport layer)
Schicht 3
Vermittlungsschicht
(network layer)
Schicht 2
Sicherungsschicht
(data link layer)
Schicht 1
Bitübertragungsschicht
(physical layer)
Abb. 3.1
OSI 7-Schichten-Modell
Das OSI-Modell unterteilt die Datenübertragung in folgende Schichten:
Schicht 7: Anwendungsschicht (application layer)
7
Das ISO/OSI Modell
Hier werden dem Anwendungsprozeß die von ihm verstandenen logischen Einheiten
wie Files Variablen usw. angeboten. Kopplungen auf dieser Ebene werden Gateways
genannt.
Schicht 6: Darstellungschicht (presentation layer)
Eine eventuell notwendige Anpassung der Datenformate (andere Reihenfolge der
Felder oder Bytes), aber auch eine gewünschte Verschlüsselung der Daten fallen in den
Aufgabenbereich dieser Schicht.
Schicht 5: Sitzungsschicht (session layer)
Aufgabe dieser Schicht ist es, einen geregelten Kommunikationsablauf zwischen den
beiden Kommunikationspartnern sicherzustellen. Ebenfalls in den Aufgabenbereich
fallen Synchronisation und Wiederholung bei Unterbrechung.
Schicht 4: Transportschicht (transport layer)
In diesem Layer wird die entweder verbindungsorientierte oder verbindungslose
Kommunikation für die darüberliegenden Schichten zur Verfügung gestellt. Zur
darunterliegenden Schicht werden Pakete in der für das Netz verträglichen Größe
weitergereicht.
Schicht 3: Vermittlungsschicht (network layer)
Hier wird der Weg der Datenpakete durch das Netz geregelt. Routingalgorithmen, die
den Weg nach etwa der Zeit oder den Kosten optimieren, leiten in dieser Schicht die
Datenpakete weiter. Geräte, die nur bis zu dieser Schichte implementiert sind, werden
Router genannt.
Schicht 2: Sicherungsschicht (data link layer )
Im Gegensatz zu der darüberliegenden Schicht findet hier eine Sicherung der Übertragung auf genau einer Teilstrecke statt. Auftretende Fehler sollten erkannt und
behoben werden. Bridges sind Koppl-Geräte, die nur bis zu dieser Schicht
implementiert sind.
Schicht 1: Übertragungsschicht (physical layer)
In dieser Schicht erfolgt nur die Definition der physikalischen Übertragung, jegliche
Korrektur ist höheren Schichten vorbehalten. Wenn aus übertragungstechnischen
Gründen ein Netz auf dieser niedrigen Ebene geKopplt werden muß, so macht man dies
mit einen Repeater.
8
SNMP und unterlagerte Protokolle
4. SNMP und unterlagerte Protokolle
SNMP setzt in der Schicht 4 auf das UDP auf. Es gibt Varianten, bei denen TCP verwendet wird.
Dies hat jedoch den Nachteil, daß einerseits eine Verdopplung der in dieser Schicht übertragenen
Header-Daten stattfindet, andererseits zwischen diesen Schichtendpunkten eine verbindungsorintierte Verbindung aufgebaut werden muß. Dies ist insbesondere deshalb von Nachteil, weil
SNMP auch zur Fehleranalyse und Beseitigung verwendet wird.
4.1. IP
Eines der gebräuchlichsten Netzwerke ist das Ethernet; deshalb wurde bei der hier beschriebenen
Implementierung auf dieser Basis aufgebaut. Dies ist jedoch keine Einschränkung, da über die
genormten Schnittstellen das darauf aufsetzende IP (Internet Protokol) [RFC791] mit jeder
anderen Hardware verwendet werden kann. Das IP hat, wie auch schon der Name vermuten läßt,
etwas mit dem Internet zu tun. Es repräsentiert den Netzwerklayer im OSI Modell. Das in dieser
Schicht stattfindende Routing wird an Hand der bekannten Internetadressen bewerkstelligt
[HUI96].
IP-Paket-Format
Version
Header
Länge
Art des Services
Gesamtlänge
Identifikation
time to live
Flags
Protokoll
Fragment Offset
Kopf-Prüfsumme
Internet Quell Adresse
Internet Ziel Adresse
Optionen
Daten
Abb. 4.1
9
IP-Paket
SNMP und unterlagerte Protokolle
IP, das Internetprotokoll, ist ein der Netzwerkschicht (OSI-Schicht 3) zuzuordnendes Protokoll,
das folgende Felder enthält (Abb. 4.1):
1. Version: Dieses Feld enthält die Versionsnummer des IP, das dieses Paket generiert hat. Pakete
mit einer anderen Nummer als der eigenen Versionsnummer werden verworfen. Derzeit ist die
IP-Version 4 aktuell.
2. Header-Länge: Angabe, aus wie vielen Byte der Header (IP-Paket ohne Daten) besteht. Das
Minimum ist 20 Bytes.
3. Art des Services: Hiermit wird die für dieses Paket Qualität des Services angegeben, die die
Priorität und die Verwendung - wie etwa, daß dieses Paket zur Netzwerkkontrolle bestimmt ist
- angibt. Folgende Arten sind definiert: Network Control, Internetwork Control, CRITIC/ECP,
Flash Override, Flash, Immediate, Priority und Routine. Die verbleibenden 2 Bits geben Delay
(normal oder low) und Throughput (normal oder high) an.
4. Gesamtlänge: Das ist die Länge des Headers plus der Daten, angegeben in Bytes. Das 16-BitFeld läßt 65 535 Bytes als Länge zu, verpflichtend muß ein Gerät aber nur Pakete mit einer
Gesamtlänge von 576 Byte verarbeiten können.
5. Identifikation, Flags und Fragment Offset dienen dazu, wegen ihrer Größe vom Sender
zerlegte Datagramme wieder zusammenzusetzen.
6. Time to live: Dieses Feld hilft, „verirrte“ Pakete aus dem Netz zu entfernen, da das Paket
vernichtet wird, wenn dieses Feld den Wert 0 erreicht hat.
7. Protokoll: Hier wird angegeben, wie die Daten zu interpretieren sind, das heißt für welches auf
IP aufsetzende Protokoll sie gedacht sind. Die wichtigsten sind 1, (Internet Control MessageProtocol), 6, (Transmission Control Protocol) und 17 (User-Datagramm-Protocol).
8. Kopf-Prüfsumme: Um die Fehlerfreiheit zu überprüfen wird auch alleine über den IP-Haeder
eine Prüfsumme gebildet.
9. Quell- und Zieladresse: Hier befinden sich die Internetadressen, die Umsetzung in die
hardwareeigenen Adressen erfolgt erst in den darunterliegenden Schichten.
10. Optionen: In diesem Feld können bis zu 40 Byte an Informationen untergebracht werden.
Hierbei handelt es sich meist um Routing- und Sicherheitsfunktionen.
IP ist hardwareunabhängig und kann damit auf verschiedene Schichten 1 und 2 (z. B. Ethernet,
Token Ring, FDDI) aufgesetzt werden. In seinem Header sind unter anderem die allgemein
bekannten Internetadressen angegeben, die eine weltweit eindeutige Identifizierung eines
Netzwerkteilnehmers erlauben. Meist wird IP in der Kombination TCP/IP [MAR94] verwendet.
Dies ist der Unterbau für Programme wie Ping, Telnet, FTP und Rlogin, die verbindungsorientierte Dienste benötigen. TCP [RFC793], das Transmission Control Protocol, ein Protokoll
der Schicht 4 (Transportschicht), stellt den Verbindungsaufbau her. TCP stellt dem Benützer
10
SNMP und unterlagerte Protokolle
dieser Schicht eine verbindungsorientierte Punkt-zu-Punkt Verbindung zur Verfügung. Dazu sind
die Zerlegung eines Datenstroms bei der Quelle und eine Rückwandlung am Ziel notwendig.
Quell Port Adresse
Ziel Port Adresse
Laufende Nummer
Bestätigungs Nummer
Daten Offset
Flags
Fenstergröße
Prüfsumme
Urgent Pointer
Optionen
Daten
Abb. 4.2
TCP-Paket
Die Felder des TCP-Kopfes (Abb. 4.2) sind:
1. Die Adresse des Quell- und des Ziel-Ports. Damit läßt sich bestimmen, für welches Service
diese TCP-Verbindung verwendet wird. Die wichtigsten Ports sind 20 für FTP file-tranfer, 21
für FTP-Kontrolldaten, 23 für Telnet-Sitzungen und 25 für SMTP.
2. Die laufende Nummer gibt die Nummer der ersten im Datenfeld enthaltenen Bytes an. Damit
ist es möglich, die einzelnen Pakete wieder zusammenzusetzen.
3. Die Bestätigungsnummer gibt die nächste vom Partner erwartete laufende Nummer an. Damit
wird die Flußkontrolle durchgeführt.
4. Der Daten-Offset ist die Länge des TCP-Headers gemessen in 32-Bit-Wörtern.
5. Die Flags steuern die Operationen des Protokolls.
6. Die Fenstergröße, die auch jedes Mal mit übertragen wird, hilft bei der Flußsteuerung. Damit
wird angegeben, wie viele Pakete gesendet werden dürfen, ohne eine Bestätigung erhalten zu
haben. Damit kann die Geschwindigkeit der beiden Partner aufeinander abgestimmt werden.
7. Die Prüfsumme dient zum Auffinden von Übertragungsfehlern.
8. Der Urgent Pointer
11
SNMP und unterlagerte Protokolle
9. Im Optionen-Feld können weitere Zusatzbedingungen für das Protokoll, wie etwa die
maximale Segmentgröße, definiert werden.
Dem Kopf folgen die zu übermittelnden Daten. Obwohl TCP verbindungsorientierte Dienste
anbietet, ist das darunter liegende IP selbst ein verbindungsloses Protokoll.
Um den Aufwand zur Wartung eines Netzwerks gering zu halten, verwendet man statt TCP das
User Datagram Protocol (UDP), das verbindungslos arbeitet. Im Gegensatz zu TCP, das einen
Header von mindestens 20 Byte benötigt (die Optionen können es noch verlängern), kommt UDP
mit einem Minimum von 8 Byte aus. Dieser Header enthält nur die wichtigsten Daten von Quelle
und Ziel.
4.2. UDP
Das User Datagram Protocol ist ein einfaches auf IP aufsetzendes Protokoll, das außer einem
Quell- und Ziel-SAP nur noch eine Prüfsumme und eine Kontrollnummer für jedes Paket enthält.
Wie eingangs erwähnt, ist UDP [RFC768] ein verbindungsloses Protokoll. Ob eine Zustellung
erfolgte oder nicht muß also vom Anwender in geeigneter Form sichergestellt werden. In dem hier
betrachteten Fall stellt UDP eine (die) einfache Verbindung zum Internetlayer dar.
Quell Port Adresse
Ziel Port Adresse
Länge
Prüfsumme
Daten
Abb. 4.3
UDP-Paket
Die einzelnen Felder des UDP-Protokolls haben folgende Bedeutung:
1. Nummer des Quell- und Ziel-Ports. Damit kann festgelegt werden, für welche Anwendung die
Daten bestimmt sind. Die wichtigsten sind:
7 echo ... Sendet ein empfangenes Datenpaket zurück zum Sender,
53 Nameserver ... über diesen Prozeß werden die Namen der Netzwerkstationen administriert,
67 Bootps ... über dieses Port kann eine Konfiguration hinuntergeladen werden,
68 Bootpc ... hier werden die eingehenden Konfigurationen empfangen,
69 TFTP ..ist ein einfaches (nicht das verbindungsorientierte) File Transportprotokoll,
12
SNMP und unterlagerte Protokolle
123 NTP ... ist das für die Systemzeit zuständig Protokoll,
161 SNMP ... ist das Eingangsport für Netzwerkmanagement-Anfragen,
162 SNMP ... dieses Port ist als Eingang für Traps reserviert.
Die beiden letzten sind die für SNMP wichtigen Eingangs-Ports. Als Ausgang-Port kann jedes
beliebige, noch nicht vergebene Port verwendet werden. Wichtig ist nur, daß die Antwort an
das gewählte zurückgeschickt wird.
2. Die Länge des gesamten UDP-Paketes (Daten plus Header) wird in Bytes angegeben. Das ist
die Länge der Daten plus acht.
3. Die Prüfsumme hilft, Übertragungsfehler zu erkennen.
4. Das Datenfeld enthält die von der darüberliegenden Schicht übergebenen Daten.
Wie man auch an den über UDP laufenden Diensten sieht, eignet es sich für kurze Nachrichten,
bei denen auf einen Verbindungsauf- und abbau zur Herstellung einer verbindungsorientierten
Kommunikation verzichtet wird.
4.3. SNMP
Das Simple Network Management Protocol ist ein einfaches, zur Netzwerk Administrierung
geeignetes Protokoll. Obwohl SNMP [RFC1157] in den späten 80er Jahren durch CMIP ersetzt
werden sollte, erfreut es sich bis heute einer großen Beliebtheit. Die große Verbreitung und die
geplante Erweiterung zu SNMPv2 gibt diesem Protokoll einen Vorsprung, der von den anderen
zwar auf dem Papier existierenden aber kaum verbreiteten, vielleicht auch besseren in nächster
Zeit nicht aufgeholt werden wird.
Bei der Implementierung von SNMP unterscheidet man zwischen Managementstationen und den
ihnen zugeordneten Agenten. Zwischen diesen beiden Arten von Stationen findet die Kommunikation statt.
Die Kommunikation zwischen diesen wird über 5 verschiedene PDUs (Protocol Data Unit)
realisiert. Dies sind GetRequest und GetNextRequest, durch die eine Management-Station einen
oder mehrere Werte aus einem Agenten holt; SetRequest setzt einen Wert in einem Agenten. Die
restlichen 2 PDUs werden vom Agenten zum Manager gesendet. GetResponse kommt als
Antwort auf eine Get- oder Set-Aktion des Managers (Abb. 4.4).
13
SNMP und unterlagerte Protokolle
Version
PDU-Type
Abb. 4.4
Community
Daten
AnfrageNummer
Error
Status
Error
Index
Nutzdaten
Objekt 1
Wert 1
Objekt 2
Wert 2
Objekt 3
Wert 3
Objekt n
Wert n
SNMP Paket Struktur für Get-, GetNext-, SetRequest und GetResponse PDU
Die Trap-PDU (Abb. 4.5) gibt dem Agenten die Möglichkeit, selbst die Initiative zu ergreifen und
spezielle Ereignisse seinem Manager anzuzeigen.
Version
PDU
Type
Enterprise
Community
AgentenAdresse
Abb. 4.5
Daten
Trap-Art
generell
Trap-Art
speziell
Objekt 1
Wert 1
Objekt 2
Wert 2
Objekt 3
Wert 3
Objekt n
Wert n
SNMP Paket Trap PDU
14
Timestamp
Nutzdaten
SNMP und unterlagerte Protokolle
4.4. Die MIB-Struktur
In der MIB (Managemen Information Base) [RFC1156] sind die für ein Netzwerk oder für eine
Komponente eines Netzwerks wichtigen Parameter hierarchisch in einer Baumstruktur angeordnet. (Abb. 4.6) Die Zahlen geben eine laufende Nummer innerhalb der Hierarchiestufe an und
können austauschbar mit der alphanumerischen Bezeichnung verwendet werden.
\
ccitt(0)
iso(1)
joint-iso-ccitt(2)
org(3)
dod(6)
internet(1)
mgmt(2)
experimental(3)
private(4)
snmpV2(6)
snmpModules(3)
mib-2(1)
system(1)
sysDescr(1)
sysObjectID(2)
sysUpTime(3)
sysContact(4)
sysName(5)
sysLocation(6)
sysServices(7)
enterprises(1)
interfaces(2)
ifNumber(1)
universitiesOfAustria(1093)
ifTable(2)
tuwien(51)
ifEntry(1)
fieldBus(6)
ifIndex(1)
ifDescr(2)
iso.org.dod.internet.mgmt.mib-2.system.SysUpTime
1.3.6.1.2.1.1.3
iso.org.dod.internet.private.enterprises.universitiesOfAustria.tuwien.fieldBus
1.3.6.1.4.1.1093.51. fieldBus number e.g. 6
Abb. 4.6
MIB-Struktur
Gewisse Objekte wie beispielsweise SysUpTime müssen in jeder Implementierung vorhanden sein.
Um ein Gerät als SNMP-tauglich bezeichnen zu können, müssen je nach Art des Gerätes folgende
Gruppen entweder ganz oder gar nicht implementiert sein (Knoten, die Bestandteil der MIB-II
[RFC1213] - einer Erweiterung der ursprünglichen MIB - sind werden kursiv geschrieben):
system
In dieser Gruppe befinden sich eine Systembeschreibung (sysDescr), ein Verweis auf den
Hersteller (sysObjectID), die Zeit, wie lange diese Station schon in Betieb ist
15
SNMP und unterlagerte Protokolle
(sysUpTime), der Name einer Kontaktperson (sysContact), der Name des Gerätes
(sysName), eine Beschreibung des physikalischen Standorts (sysLocation) und ein
Codes, welche Service dieses Gerät zur Verfügung stellt (sysService).
Interfaces
In dem Bereich befinden sich eine Variable, die angibt, wie viele Interfaces das Gerät
besitzt (ifNumber), und eine Tabelle, in der genauere Informationen über diese enthalten
sind (ifTable).
At
Die Gruppe, die Adress-Übersetzungs-Gruppe, wurde in der MIB-II den einzelnen
Protokollen beigefügt. Sie besteht aus einer Tabelle, die eine Zuordnung zwischen IPund physikalischer Adresse angibt.
IP
In der Internetprotokollgruppe wird angegeben, ob es sich um einen Host oder um ein
Gateway handelt (ipForwarding), wie die default TTL lautet (ipDefaultTTL), wie viele
Datagramme empfangen worden sind (ipInReceives), wie viele davon einen Fehler im
Format (ipInHdrErrors) oder bei der Adresse (ipInAddrErrors) hatten, wie viele Pakete
weitergeleitet wurden (ipForwDatagrams), wieviele an ein unbekanntes Protokoll
gesendet wurden (ipInUnknownProtos), wieviele aus Resourcenmangel verworfen
werden mußten, wie viele tatsächlich zugestellt werden konnten (ipInDelivers) und
ähnliche statistische Werte für die hinausgehenden Pakete. Weiters befinden sich hier
eine Tabelle, die die Internetadressen des Knotens verwaltet (ipAddrTable), einer
Tabelle für Routingfunktionen (ipRoutingTable) und einer Tabelle für die Zuordnung
von physikalischer zu Internet-Adresse.(ipNetToMediaTabele)
ICMP
Die Internet ControlMessageProtocol-Gruppe enthält nur Zähler äquivalent zu denen der
IP-Gruppe.
TCP
Die TransmissionControlProtocol-Gruppe enthält außer den statistischen und den für das
Protokoll wichtigen Werten eine Tabelle, die über die TCP verwendenden Aplikationen
Auskunft gibt (tcpConnTable).
UDP
Die Gruppe gibt Auskunft über die hereingekommenen Pakete (udpInDatagrams), wie
viele davon eine unbekannte Portadresse (udpNoPort) oder einen Formatfehler
(udpInErrors) hatten und wie viele Pakete diese Schicht Richtung Netzwerk verlassen
haben. Weiters ist eine Tabelle mit der Zuordnung von lokalem Port zu lokaler Internetadresse enthalten (udpTable).
EGP
Diese Gruppe Muß nur für Geräte, die das Exterior Gateway Protocol implementiert
haben, eingerichtet werden.
Transmission
Die Gruppe stellt einen Platzhalter für medienspezifische MIBs in der MIB-II dar.
SNMP
Die Gruppe gibt statistische Auskunft über SNMP-Pakete. Es werden die hereinkommenden und hinausgehenden fehlerhaften Pakete nach Fehlerkategorien gezählt:
zu lange PDU
(snmpInTooBigs)
kein solcher Name vorhanden
(snmpInNoSuchName) (snmpOutNoSuchName)
Wertformat falsch
(snmpInBadValues)
(snmpOutBadValues)
Schreibzugriff nicht erlaubt
(snmpInReadOnly)
(snmpOutReadOnly)
Fehler beim Generieren des Paketes (snmpInGenErrs)
16
(snmpOutTooBigs)
(snmpOutGenErrs)
SNMP und unterlagerte Protokolle
Ebenfalls wird Auskunft über die Anzahl der eingelangten Get (snmpInTotalReqVars)
und Set-Anfragen (snmpInTotalSetVars) gegeben. Letztendlich kann man auch
Autentication Traps erlauben und verbieten (snmpEnableAuthTraps).
Für das hier entworfene Gateway sind, um es SNMP-tauglich zu machen, die Gruppen System,
Interfaces, Address Translation, IP, ICMP, UDP und SNMP zu implementieren. Die restlichen
Gruppen müssen nach der jeweiligen Konfiguration von KA9Q bei Bedarf noch dazugefügt
werden, wenn die den fehlenden Gruppen zugeordneten Protokolle konfiguriert werden.
Im private-Zweig können eigene Objekte definiert werden. Diese können also für die Darstellung
von Feldbusknoten verwendet werden. Damit ist der Feldbus fest im Namensraum verankert.
Solange er im private-Unterzweig der TU-Wien angesiedelt ist, sind noch alle Freiheiten der
Definition offen. Eine Verschiebung in den Management-Unterzweig würde die Definition
weltweit gültig machen, bedarf jedoch einer internationalen Zustimmung.
4.5. Zugriff auf Elemente der MIB
Um auf Elemente der MIB zugreifen zu können, muß man entweder den GetRequest- oder den
GetNextRequest-Befehl verwenden.
Sys-MIB ....... 1.3.6.1.2.1.1
Sys-MIB.sysContact
Sys-MIB.sysName
Sys-MIB.sysLocation
..........
..........
..........
get(Sys-MIB.sysContact.0)
liefert
getnext(Sys-MIB.sysContact.0) liefert
getnext(Sys-MIB.sysLocation.0) liefert
Knizak
PC74
Kompetenzzentrum
Knizak
PC74
Kompetenzzentrum
getnext(Sys-MIB.sysContact)
Beispiel 4.1
liefert
Knizak
MIB-Adressierung von einfachen Variablen
Um den ersten verwenden zu können, muß man auf das MIB Element genau zugreifen. Das
bedeutet bei einfachen Variablen wie etwa der SysUpTime, daß man dem Pad (Namen) eine ".0"
als Identifier anhängen muß (Beispiel 4.1). Mit dem GetNextRequest-Befehl wird jeweils auf das
nächstfolgende Element im Namensraum zugegriffen. Dieser Befehl erlaubt es, die gesamte MIB
zu durchsuchen, ohne die einzelnen Elemente genau zu kennen. Es wird dabei nicht nur innerhalb
eines Unterbaums gesucht, sondern auch zum nächsten gewechselt.
Bei Tabelleneinträgen steht hinter dem Namen ein das gewünschte Tabellenelement eindeutig
identifizierender Ausdruck. Dies kann eine einzelne Zahl sein oder auch eine, in der üblichen
17
SNMP und unterlagerte Protokolle
punktierten Schreibweise dargestellte, Internetadresse oder Kombinationen von beiden und noch
mehr (Beispiel 4.2).
Interfaces-MIB ....... 1.3.6.1.2.1.2
get(Interfaces-MIB.1.ifDescr.1)
liefert die verbale Beschreibung des ersten
Interfaces
getnext(Interfaces-MIB.1.ifDescr.1)
liefert die verbale
Beschreibung des zweiten
Interfaces
oder
get(Interfaces-MIB.1.ifDescr.2)
Beispiel 4.2
MIB-Adressierung einer einfachen Tabelle
Ein weiterer Vorteil des GetNext-Befehls ist, daß die Adresse des ausgelesenen Wertes mitgeliefert wird. Damit weiß man, ob man sich noch in der Tabelle befindet, oder schon, da man das
Ende erreicht hat, im nächsten Element. Wenn die eindeutige Identifizierung einer Internetadresse
bedarf, erhält man bei der Abfrage des Status mit getNext auch gleich mitgeliefert, um welche
TCP-MIB
.................
TCP-MIB.13.1.1
1.3.6.1.2.1.6
steht für den Status in der TCP Verbindungstabelle
GetNext(TCP-MIB.13.1.1)
liefert den Status des ersten Eintrags in dieser
Tabelle, gleichzeitig werden auch die zur
Identifikation notwendigen Parameter geliefert, mit
denen der Status des nächsten Tabelleneintrages
gelesen werden kann
Beispiel an zurückgelieferten Daten:
lokale
lokale
remote
remote
Internetadresse
Portadresse
Internetadresse
Portadresse
128.130.80.61
1090
128.130.80.57
1040
zu dieser Verbindung wird der Status angegeben.
Der Aufruf des Status der nächsten Verbindung lautet:
GetNext(TCP-MIB.13.1.1.128.130.80.61.1090.128.130.80.57.1040)
Beispiel 4.3
MIB-Adressierung in einer komplexeren Tabelle
Verbindung es sich handelt [ROS91].
18
SNMP und unterlagerte Protokolle
Durch diese Art der Verwendung des GetNext-Befehles werden viele notwendige Informationen
automatisch ohne eigens dafür notwendige Anforderung mitgeliefert (Beispiel 4.2).
4.6. ASN.1 (Abstract Syntax Notation One)
Um SNMP Pakete übertragen zu können, braucht man zusätzlich zu der Struktur der MIB und
den generellen Regeln von SNMP eine genaue Anleitung, wie diese Nachrichten zu codieren sind.
Bei SNMP wurde dazu nichts Neues geschaffen, sondern man verwendet einen Teil von ASN.1.
Ohne hier genauer auf ASN.1 einzugehen, kann man sich die codierten Ausdrücke dreigeteilt
vorstellen. Das erste Feld enthält, um welche Art von Daten es sich handelt, das mittlere Feld gibt
die Länge an, und zuletzt folgt der Wert selbst. Diese Struktur wird auch bei größeren Einheiten
beibehalten. Dann heißt das ganze Typ „Sequence of“, gefolgt von der Länge und dann den
Daten, die wie beschrieben auch in Typ, Länge und Wert codiert sind.
seqence
of
Abb. 4.7
Länge:14
Daten
OID
Länge: 7
43.6.1.2.1.1.1
INTEGER
Länge: 1
16
NULL
Länge: 0
ASN.1 schematisch (sysuptime, 16, Nullwert)
In Abb. 4.7 sind zwei Besonderheiten enthalten. Normalerweise beginnt die OID mit 1.3. Da aber
in diesen Hierachieebenen nur wenige Unterzweige vorhanden sind, werden diese beiden nach der
Formel: erste Ebene mal 40 plus zweite Ebene zusammengefaßt. Der Nullwert wird dazu
verwendet, wenn man für irgend etwas einen Wert zur Codierung laut ASN.1 braucht, ihn aber
nicht kennt.
Ein Teilaspekt, nämlich nicht die formale Beschreibung, sondern die genaue Codierung der
einzelnen Datentypen soll hier näher beschrieben werden, da sie für das Verständnis der CProgramme nötig ist. Wie anfangs erwähnt, kommt zuerst der Typ, dann die Länge und dann der
Wert. Der Typ ist ein Byte lang. Die ersten beiden Bits geben die Art des Typs an: universial,
applikationsweit, contextspexifisch oder privat. Darauf folgt, ob es sich um einen zusammengesetzten Typ handelt oder nicht. Die letzten fünf Bit geben die Nummer des Typs innerhalb der
festgelegten Gruppe an (Beispiel 4.4).
19
SNMP und unterlagerte Protokolle
Beispiele aus der Klasse Universal:
INTEGER
STRING
NULL_TYP
OID
SEQUENCE
0x02
0x04
0x05
0x06
0x30
Beispiele aus der Klasse Contextspezifisch:
GETREQUEST
GETNEXTREQUEST
GETRESPONSE
SETREQUEST
TRAP
codiert
0xA0
0xA1
0xA2
0xA3
0xA4
Nummer innerhalb der Klasse
0
1
2
3
4
Beispiel 4.4
ASN.1-Klassen
Nach dem Typenfeld folgt die Länge. In ASN.1 existieren zwei Formen, die bestimmte und die
unbestimmte. Bei der unbestimmten wird das Ende durch zwei Nullen angezeigt (Beispiel 4.3).
SNMP verlangt aber, daß immer die bestimmte Form verwendet wird. Diese Form kann immer in
einer langen Form dargestellt werden. Im ersten Byte ist das höchste Bit auf Eins gesetzt. Die
weiteren geben in vorzeichenloser Integerdarstellung die Anzahl der folgenden Bytes an. Die
durch diese Bytes definierte Zahl gibt nun den endgültigen Wert der Länge an. Bei Zahlen kleiner
als 128 kann statt dieser Darstellung auch eine kurze Form verwendet werden. Da bei diesen
Zahlen das höchste Bit Null ist, kann gleich im ersten Byte die Länge angegeben werden
[GOR92].
20
SNMP und unterlagerte Protokolle
Beispiel Längenangabe:
Länge Integer
Bitdarstellung
Hex-Darstellung
Kommentar
1
1
6
6
127
127
00000001
10000001 00000001
00000110
10000001 00000110
01111111
10000001 01111111
01
81 01
06
81 06
7F
81 7F
kurze
lange
kurze
lange
kurze
lange
128
10000001 10000000
81 80
Beispiel 4.5
Form
Form
Form
Form
Form
Form
lange Form
(nicht in kurzer
darstellbar)
ASN.1-Längenangabe
Die danach folgende Darstellung des Wertes nimmt so viele Bytes wie im Längenfeld angegeben
in Anspruch. Die genaue Interpretation ist vom Typ abhängig.
21
Der PROFIBUS
5. Der PROFIBUS
Profibus existiert derzeit in 3 Ausführungsformen (Abb. 5.1).
Automation für
allgemeine Verwendung
PROFIBUS-FMS
EN50170 T1 + T2
Verwendungsspezifische
Profile:
Textilmaschinen
Gebäudeautomation
Sensoren und Aktuatoren
SPS
Prozeßautomation
PROFIBUS-PA
DIN 19 245 T4
für eigensichere
Übertragung lt.
IEC 1158-2
Fabrikautomation
PROFIBUS-DP
EN50170 T1 + T3
große Übertragungsraten
für dezentrale Peripherie
Abb. 5.1
PROFIBUS-Varianten
5.1. Profibus-FMS (Fieldbus Message Spezifikation)
Diese Variante ist multimasterfähig und unterstützt Baudraten bis zu 1500 Kbaud [BEN92].
Umgesetzt auf das OSI-Modell entfallen, wie bei vielen Feldbussen üblich, die Schichten 3 bis 6
zugunsten einer besseren Reaktionszeit. Die Anzahl der Geräte ist auf 127 begrenzt, wobei nicht
mehr als 32 ohne Repeater verbunden sein dürfen; ebenfalls dürfen nicht mehr als drei Repeater
sich auf der Übertragungsstrecke zwischen zwei Geräten befinden. Um trotzdem 127 Master bzw.
Slaves verbinden zu können ist eine Baumstruktur notwendig. Die Programmierung erfolgt durch
Erstellen von KBL (KommunikationsBeziehungsListe) und OV (ObjektVerzeichnis) für die
Eigenschaften der Profibus-Verbindung und meistens durch SPS Programmierung der restlichen
Teile, es existieren aber auch schon vereinzelt PC-Einsteckkarten, die über ein
Visualisierungsprogramm oder über eine DDE-Schnittstelle den Bus ansprechen.
22
Der PROFIBUS
5.2. Profibus-DP (Dezentrale Peripherie)
Diese Variante zeichnet sich durch eine höhere Geschwindigkeit von bis zu 12 Mbaud aus
[POP96]. Die Programmierung ist einfacher, es ist aber nur ein Monomastersystem. Meist müssen
die Slaves nur ihre Stationsadresse mitgeteilt bekommen - entweder durch DIL-Schalter oder
direkt über den Bus. Die Programmierung erfolgt im Masters, wobei in einer Konfigurationsdatei
jedem Slave ein Ein- bzw. Ausgangsbereich des Master zugewiesen wird. Diese können dann
angesprochen werden, als befänden sie sich direkt im Master. Da die Kommunikation in
Hintergrund und nicht ausprogrammierbar abläuft, entfallen bei dieser Variante die Schichten 3-7.
5.3. Profibus-PA (Prozeßautonatisierung)
Diese Ausführung von Profibus ist ähnlich der DP-Variante. Sie stellt lediglich eine Erweiterung
um Profile für spezielle Geräte und die Möglichkeit einer anderen Schicht-1-Implementierung
nach IEC 1158-2, um Profibus auch im eigensicheren Bereich verwenden zu können.
5.4. Schichten 1 und 2
Die Schichten 1 und 2 sind bei PROFIBUS-FMS und -DP gleich aufgebaut und entsprechen der
Norm EN50170 Teil 2. PROFIBUS-PA kann wahlweise ebenfalls so aufgebaut sein oder für den
eigensicheren Betrieb die Norm IEC 1158-2 als Schicht 1 verwenden.
Die Schicht 1 ist meist nach der US Norm RS485, die je nach Kabellänge bis zu 12Mbit/s erlaubt.
Die möglichen Übertragungsgeschwindigkeiten sind 9.6, 19.2, 187.5, 500, 1500 kbit/s und 12
Mbit/s. Angeschlossen werden die Geräte mit einen 9-Pin Sub-D Stecker. Um die maximale
Länge zu vergrößern, sind zwischen zwei Geräten bis zu drei Repeater erlaubt. Im gesamten
Netzwerk dürfen aber mehr Repeater sein. Diesen scheinbaren Widerspruch löst man durch eine
baumartige Struktur der Repeater. Ferner werden Repeater benötigt, da pro Segment maximal nur
32 Geräte angeschlossen sein dürfen. Weiters ist auch die Übertragung mittels Glasfaser erlaubt.
Der Data Link Layer ist für DP und PA die letzte implementierte Schicht des OSI Modells.
Insgesamt sind bis zu 127 Stationen ansprechbar. Diese unterteilen sich in Master, Stationen, die
die Kontrolle über den Bus haben können, und Slaves, die nur nach Aufforderung durch einen
Master Daten senden können. Die Masterstationen sind als logischer Tokenring aufgebaut (Abb.
5.2). In der Zeit, in der ein Master dieses Token besitzt, kann er mit Slaves oder anderen Mastern
kommunizieren. Danach muß er es an den nächsten ihm bekannten Master weitergeben. Die
Weitergabe wird dadurch geregelt, daß eine Umlaufzeit vorgegeben wird. Wenn ein Master
bemerkt, daß diese überschritten wird, muß das Token weitergegeben werden. Um zu wissen, an
welcher Adresse sich der nächst Master befindet, wird das sogenannte Gap-update durchgeführt.
23
Der PROFIBUS
logischer Token-Ring
Master
Slaves
Abb. 5.2
physikalischer
Bus
Busstruktur PROFIBUS
Dabei werden in regelmäßigen Abständen Telegramme an die Adressen zwischen der eigenen und
der des nächsten bekannten Masters geschickt. Wenn sich von solch einer Adresse ein Master
zurückmeldet, hat man einen neuen gefunden, und es muß nur mehr der restliche Adreßbereich
regelmäßig durchsucht werden. Dieser Vorgang erlaubt es, während des Betriebes neue Geräte
einzufügen. Um eine gesicherte Übertragung der Daten zu gewährleisten, sind die Datenpakete
mit einer Hammingdistanz von 4 abgesichert. Eine Fehlerkorrektur wird jedoch nicht vorgenommen.
Folgende Dienste werden von der Schicht 2 zur Verfügung gestellt:
1. Send Data with Acknowledgement,
2. Send And Request Data With Replay,
3. Send Data with NoAcknowledgement,
4. Cyclic Send And Request Data With Replay.
PROFIBUS-FMS verwendet alle 4 Dienste. PROFIBUS-DP und -PA verwenden nur die Dienste
2 und 3.
5.5. Schicht 7
PROFIBUS-FMS ist die einzige der drei Varianten, bei der eine Schicht 7 implementiert ist. Hier
werden die Kommunikationsobjekte und die Applikationsservices beschrieben. Die für den
24
Der PROFIBUS
Anwender wichtigsten zwei Listen sind das Objektverzeichnis (OV) und die Kommunikationsbeziehungsliste (KBL). Beide werden bei der Projektierung erstellt und bilden die Grundlage für
jede Verbindung.
In der KBL steht für jede projektierte Verbindung eine Zeile. Die Zeilennummer entspricht meist
der Kommunikationsreferenz, die alleine für die eigentliche Verbindung im Betrieb genügt.
Weiters sind die physikalischen Adressen von Ziel und Quelle, die SAP-Nummern von beiden und
die die Kommunikation betreffenden Parameter (Abb. 5.3) angegeben.
KR
L
Rem
D
Type
SAP
ADR
SAP
1
3
11
4
MMAZ
2
4
10
4
3
62
27
5
Verb
S
R
CC
CC
D
1
1
MMAZ
D
1
1
MSAZ
D
1
0
CI
PDU
PDU
Serv.
Serv.
C
S
R
S
100
241
241
30
30
100
241
204
30
30
241
241
30
0
......
Abb. 5.3
Kommunikationsbeziehungsliste (schematisch)
KR
Die Kommunikationsreferenz ist eine der Kommunikationsbeziehung eindeutig
zugeordnente Zahl. Sie alleine genügt, um den Emfänger eines Dienstes zu beschreiben.
LSAP
Für jede Kommunikationsbeziehung muß ein Dienstzugangspunkt auf lokaler Ebene
definiert werden. Dieser darf bei Master-Master-Beziehungen nur für eine verwendet
werden. Bei Master-Slave-Verbindungen wird ein Default-SAP verwendet.
RemADR
Die remote-Address ist die physikalische Busadresse des Kommunikationspartners.
DSAP
Ist der lokale Dienstzugangspunkt der Partnerstation. Dieser darf nur für eine
Kommunikationsbeziehung verwendet werden.
Type
Dieses Feld gibt an, um welche Art von Beziehung es sich handelt. Es wird zwischen
Master-Master, Master-Slave, zyklisch oder azyklisch und mit oder ohne Slaveinitiative unterschieden.
SCC
(souce receive confirmed counter) Hiermit wird angegeben, wie viele PDUs gesendet
werden dürfen, ohne eine Bestätigung erhalten zu haben.
RCC
Diese Zahl gibt an, wie viele PDUs die Partnerstation ohne Empfangsbestätigung
senden darf.
25
Der PROFIBUS
CI
Das zyklische Kontrollintervall gibt die Zeit in msec an, nach der spätestens eine
PDU zwischen beiden Stationen ausgetauscht werden muß. Bei azyklischer MasterSlave-Verbindung muß dieser Wert 0 sein.
PDU S
Gibt die maximal mögliche PDU-Länge des Senders an.
PDU D
Gibt die maximal mögliche PDU-Länge des Empfängers an.
Die beiden letzten Werte können für hochpriore und niederpriore PDUs auch unterschiedlich angegeben
werden.
Serv.S
Gibt die vom Gerät als Server unterstützten Dienste an. Dieser Wert ist bitweise
codiert. Jedes Bit in diesem Byte steht für einen unterstützten Dienst.
Serv.S
Gibt die vom Gerät als Client unterstützten Dienste an. In diesem Beispil unterstützt
das Gerät sowohl als Server als auch als Client die Dienste Lesen und schreiben.
Das Objektverzeichnis besteht aus einem Teil, in dem die Variablentypen beschrieben sind, und
einem Teil in dem die Zuordnung von physikalischem Speicher zu den am Netz bekannten
Objektnamen steht (Abb. 5.4).
Objekt Code
Index
Typ
Länge
Passwort
Adresse
Symbolischer Name
5
2
Integer16
5
4
Integer 32
7
41
2
1
00
43FF1234
Temperatur
7
518
4
1
00
44FF1235
Entfernung
Abb. 5.4 Objektverzeichnis (schematisch)
Die Felder im OV haben folgende Bedeutung:
Objektcode
Dies gibt an um welche Art von Objekt es sich handelt. 5 entspricht eine Datentyp, 7
steht für Variable.
Index
Diese Zahl gibt eine fortlaufende Nummer innerhalb des OV an. Es wird
durchlaufend und nicht zwischen Objekttypen unterscheidend gezählt.
26
Der PROFIBUS
Typ
Mit diesem Verweis auf einem Objekttyp wird festgelegt, um welche Art von
Variable es sich handelt. In diesem Fall sind es 2 für Integer16 und 4 für Integer 32.
Passwort
Damit kann man den Zugriff auf Variablen mit einem Paßwort „schützen“. Es
handelt sich aber eher um einen Schutz vor unbeabsichtigter Veränderung, da es
weder codiert ist, noch irgenwelche anderen Schutzmaßnahmen implementiert sind.
Adresse
Dies ist eine vom Hersteller und Gerät abhängige physikalische Adresse, unter der
die diesem Objekt zugeordneten Daten lokalisiert sind.
Symbolischer Name Zur leichteren Verständlichkeit kann man auch alphanumerische Namen vergeben.
Die Abfrage über diese symbolischen Namen ist optional möglich, aber leider bei
kaum einem PROFIBUS-Gerät implementiert.
Zu den zwei wichtigen Tabellen benötigt man grundsätzlich nur noch das Wissen, welche Dienste
zur Verfügung stehen. Jedes PROFIBUS-Mastergerät muß die Dienste Initiate, Abort und Reject
zum Auf- und Abbau von Verbindungen, Get-OV für das Objektmanagement und Status und
Identify als Zustandsmeldungen zur Verfügung stellen. Weitere bei dieser Arbeit verwendete
Dienste sind Read und Write zum Lesen und Schreiben von Variablen.
27
Analyse der Kopplungsmöglichkeiten
6. Analyse der Kopplungsmöglichkeiten
Bei der Kopplung zweier Netzwerke oder Teilen von Netzwerken unterscheidet man vier Arten
von Kopplungsgeräten: den Repeater, die Bridge, den Router und das Gateway.
7
7
6
6
5
5
4
4
3
3
2
2
1
1
1
Repeater
1
7
7
6
6
5
5
Remote Repeater
4
4
3
3
2
2
1
1
1
1
Abb. 6.1
1
1
Repeater
Repeater verbinden lediglich zwei Segmente ein und desselben LANs (Abb. 6.1). Sie bestehen nur
aus der Schicht 1 des ISO-Modells. Einen Sonderfall stellen Remote Repeater dar, sie sind
zweigeteilt und verbinden räumlich voneinander getrennte Teile eines LANs.
Bridges (Abb. 6.2 oben links) besitzen schon etwas an Intelligenz; sie bestehen aus Schicht eins
und zwei und werden zur Kopplung zwischen zwei Netzen verwendet.
Router (Abb. 6.2 oben rechts) verbinden Netzwerke auf Ebene der Schicht 3. Mit eigenen
Algorithmen steuern sie den Weg eines Datenpaketes zu seinem Bestimmungsort.
28
Analyse der Kopplungsmöglichkeiten
7
7
6
6
5
5
4
4
4
3
3
3
3
3
3
2
2
2
1
1
1
7
6
Bridge
5
2
2
2
2
2
1
1
1
1
1
7
7
7
7
6
6
6
6
5
5
5
5
4
4
4
4
3
3
3
3
2
2
2
2
1
1
1
1
Abb. 6.2
7
6
Router
5
4
Gateway
Bridge, Router und Gateway
Das Gateway (Abb. 6.2 unten) ist die komplizierteste dieser Kopplungsvorrichtungen. Es enthält
alle sieben Schichten des ISO-Modells. Durch diesen Aufbau bedingt ist es möglich, auch die
unterschiedlichsten Netzwerke miteinander zu verbinden [COM94].
6.1. Router mit PROFIBUS-Protokoll
LAN
FAN
FMS
FMS
leer
leer
router
leer
leer
leer
leer
IP
IP
leer
leer
DLL
DLL
FDL
FDL
PYL
PYL
PYL
PYL
Abb. 6.3
Router mit PROFIBUS-Protokoll
Abkürzungen in der Abb.: PYL Physikal Layer; DLL Data Link Layer; FDL Fieldbus Data Link Layer
29
Analyse der Kopplungsmöglichkeiten
Die Überlegung liegt nahe, gleich eines der beiden Protokolle zu verwenden. Angenommen, man
verwendet das PROFIBUS-Protokoll - welche Vorteile, welche Nachteile hätte man? Das
Bindeglied zwischen beiden Netzwerken wäre einfach, da es nur aus den Schichten eins bis
einschließlich drei bestehen müßte (Abb. 6.3). Die Seite mit dem PROFIBUS-Protokoll könnte
vollkommen gleich gelassen werden, der Router würde lediglich als Masterstation in das Netz
aufgenommen. Im Router fügte man dem PROFIBUS Datenpaket lediglich den Ethernet„Vorspann“ und die Prüfsumme hinzu, beziehungsweise in die Gegenrichtung entfernte man
beides. Die gesamte Intelligenz des Systems wäre im Ethernet-Gerät.
Vorteil dieses Lösungsansatzes ist die Einfachheit des Kopplgliedes und der geringe Aufwand im
PROFIBUS-Netz.
Nachteile sind: Alle Ethernetgeräte müssen die Software für das PROFIBUS-Protokoll besitzen.
Die Benutzeroberfläche ist entweder sehr unkomfortabel, da die PROFIBUS-Befehle auf sehr
niedriger Ebene eingegeben werden müssen, oder muß bei Änderung im PROFIBUS-Teil bei allen
Ethernetgeräten neu konfiguriert werden.
Zusammenfassend gesagt: Es ist eine billige, schnelle Lösung, wenn man nur ein oder sehr wenige
Ethernetgeräte hat, die die Daten das anderen Netzes benötigen. Ebenfalls sollten die Anwender
zumindest grundsätzliches Wissen über die PROFIBUS-Norm haben - insbesondere über
Kommunikationsreferenzen und Objektverzeichnisse.
6.2. Router mit SNMP-Protokoll
LAN
FAN
SNMP
SNMP
SNMP
SNMP
router
SNMP
SNMP
UDP
UDP
IP
IP
IP
IP
DLL
DLL
FDL
FDL
PYL
PYL
PYL
PYL
Abb. 6.4
Router mit SNMP-Protokoll
Abkürzungen in der Abb.: PYL Physikal Layer; DLL Data Link Layer; FDL Fieldbus Data Link Layer
30
Analyse der Kopplungsmöglichkeiten
Dieser vielleicht verlockend erscheinende Lösungsansatz (Abb. 6.4) scheidet nach näherer
Betrachtung sofort aus. SNMP ist ein leicht zu bedienendes Protokoll, der Benutzer benötigt also
kein Wissen über die PROFIBUS-Norm. Das Kopplglied entspricht in seiner Komplexität etwa
dem des vorigen Abschnittes. Aber Sinn und Zweck ist es ja, einfache („unintelligente“)
PROFIBUS-Slaves auslesen zu können. Bei diesem Lösungsansatz müßte aber gerade dort die
Protokollumsetzung stattfinden - das heißt die gesamte Intelligenz sein - also ein Widerspruch in
sich.
6.3. Gateway
Gateway
SNMP-Manager
SNMP-Agent-FMS-Master
Field-Device
SNMP
SNMP
FMS
FMS
SNMP
SNMP
leer
leer
SNMP
SNMP
leer
leer
UDP
UDP
leer
leer
IP
IP
leer
leer
DLL
DLL
FDL
FDL
PYL
PYL
PYL
PYL
Abb. 6.5
Gateway
Abkürzungen in der Abb.: PYL Physikal Layer; DLL Data Link Layer; FDL Fieldbus Data Link Layer
Der Lösungsansatz mit Hilfe eines Gateways (Abb. 6.5) ist der aufwendigste. Innerhalb des
Gateways müssen alle Schichten des OSI-Modells zweimal implementiert werden. Zusätzlich wird
eine Applikation benötigt, die die Umsetzung der beiden Protokolle bewerkstelligt. Von der
Bedienung bleibt das einfache SNMP-Protokoll für den Endanwender erhalten. Die den Feldbus
betreffenden Änderungen müssen nur im Gateway vorgenommen werden, beziehungsweise
können dort automatisiert werden. Ein weiterer Vorteil liegt darin, daß bei modularer Programmierung das Profibus-Interface durch das eines anderen Feldbusses ersetzt werden kann.
31
Analyse der Kopplungsmöglichkeiten
Obwohl dies die aufwendigste Form ist, verspricht sie im Endergebnis eine leichte Bedienung
[KNI97]. Auf die Feldbus-Seite kann ohne speziell auf das Bussystem zugeschnittene Software
von jedem berechtigten, am Netz befindlichen User mittels verbreiteter SNMP-Software
zugegriffen werden. Änderungen sind nur vor Ort am Gateway durchzuführen. Alle diese Gründe
führten dazu, daß dieser Weg beschritten wurde.
32
Interne Informationsstrukturen
7. Interne Informationsstrukturen
Die MIB und Zeigerstrukturen in C weisen große Ähnlichkeiten auf. Das ist auch der Grund,
weshalb für die Implementierung als interne Speicherung der Daten eine baumartig aufgebaute
Zeigervariable gewählt wurde. Um den Protokoll-Aufwand möglichst gering zu halten, wurde
eine Abkopplung der SNMP-Seite und der PROFIBUS-Seite bevorzugt.
Prinzipiell stehen zwei unterschiedliche Konzepte der Verbindung zur Verfügung:
Gateway
Managementstation
Abb. 7.1
Feldbusknoten
Put through Gateway
1. Jede ankommende Anfrage wird in PROFIBUS-Kommandos umgeformt und abgesetzt. Durch
eine softwaremäßige Vorkehrung muß hier sichergestellt werden, daß es keine Verwechslung
zu knapp aufeinander erfolgender Anfragen gibt oder die Anzahl ausstehender Aufträge zu
groß wird. Weiters ist Vorkehrung zu treffen, wie auf eine Unterbrechung der Feldbusseite zu
reagieren ist (Abb. 7.1).
33
Interne Informationsstrukturen
Gateway
Managementstation
Feldbusknoten
Abb. 7.2 Gateway mit Feldbusabbild
2. Man schafft ein vereinfachtes Abbild der relevanten Daten des Feldbusses im Gateway (Abb.
7.2). Dies hat eine schnellere Reaktionszeit zur Folge, die Daten sind aber nicht so aktuell.
Weiters ist zu bedenken, daß der Datenverkehr auf Feldbusseite stark erhöht wird. Um die
Vorteile dieser Art zu nützen, muß den Daten ein Zeitstempel aufgeprägt werden. Durch diese
und weitere Informationen über den Zustand des Knotens gewinnt diese Art der Abb. an
Attraktivität.
Der Gewinn an Schnelligkeit und die genauere Information über den Zustand der Feldbussseite
sprachen für eine Implementierung nach der zweiten Methode.
7.1. Definition der neuen MIB
Die Abb. der PROFIBUS-Knoten im Gateway ist der MIB angepaßt. Die dort vorhandenen
Felder sind, wenn auch in etwas anderer Form, im Abbild des Feldbusses zu finden. Folgende
Daten werden zu jedem Knoten gespeichert:
1. Art des Knotens,
2. Beschreibung wo sich der Knoten befindet,
3. Wert des Knotens,
4. Der zu Punkt 3 dazugehörende Zeitpunkt,
5. letzter Wert des Knotens,
6. Der zu Punkt 5 dazugehörende Zeitpunkt,
7. Zustand des Knotens ( Zuverlässigkeitsangabe der Daten),
8. Trap Bedingung (ob und unter welchen Bedingungen eine Ausnahme-Verarbeitung
erfolgt),
34
Interne Informationsstrukturen
9. Zur Trapbedingung gehörender Wert 1,
10. Zur Trapbedingung gehörender Wert 2.
Bei der Auswahl wurde darauf geachtet, daß nur die wichtigsten Werte des Knotens in die MIB
aufgenommen werden. Dies soll die Übersichtlichkeit steigern und die schon vorhandene MIB
nicht unnötig überladen.
fieldBus
fBTypeDescr(1)
fBTemperatureSensor(1)
fBStatus(2)
fBLightSensor(3)
fBAccess(2)
fBTable(1) fBInDatagrams(1)
fBEntry(1)
fBAIndex(1)
fBAKind(2)
fBADescr(3)
fBAType(4)
fBAValue(5)
fBATime(6)
fBAValueOld(7)
fBATime(7)
fBATrap(9)
fBAValue1(10)
fBAValue2(11)
fBAStatus(12)
Abb. 7.3
fBDevDescr(3)
fBOutDatagrams(2)
fBInErrors(3)
fBEntries(4)
fBMaxEntries(5)
LAN-FAN-MIB
Die drei in dieser MIB enthaltenen Unterbäume haben unterschiedliche Funktionen. Der erste
stellt alle Arten von ansprechbaren Knoten zur Verfügung. Nur die hier aufgeführten Arten sind
als OID-Typ verwendbar. Der mittlere enthält alle Knoten und deren Werte. Ebenfalls werden hier
die Trap-Bedingungen verwaltet. Die Werte sind lese und schreibbar. Der dritte und letzte
Unterbaum stellt statistische Werte über das Gateway zur Verfügung und kann daher nur gelesen
werden.
7.2. Beschreibung in ASN.1
Die zuvor gegebene graphische Beschreibung der unter SNMP verfügbaren Werte erfüllt nicht die
von ASN.1 vorgeschriebene Form. Sie wurde jedoch zur besseren Verständlichkeit der echten
Definition vorangestellt.
35
Interne Informationsstrukturen
Definition der LAN-FAN-MIB:
LAN-FAN-MIB DEFINITIONS ::= BEGIN
IMPORTS
-- Importieren von vordefinierten Typen und Objekten
MODULE-IDENTITY, OBJECT-TYPE, snmpModules, IpAddress
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, DateAndTime
FROM SNMPv2-TC
mib-2
FROM RFC1213-MIB;
--LAN-FAN-MIB MODULE-IDENTITY
--
LAST-UPDATED " 25.02.99 13:30"
--
ORGANIZATION "Institut für Computertechnik"
--
CONTACT-INFO
--
"
Martin Knizak
----
e-mail: [email protected]"
--
DESCRIPTION
--
"Die MIB beschreibt Feldbusobjekte und macht so Feldbusse
--
vom Internet her zugänglich"
universtiesOfAustria
OBJECT IDENTIFIER ::= { enterprises 1093}
tuwien OBJECT IDENTIFIER ::= { universtiesOfAustria 51 }
fieldBus
OBJECT IDENTIFIER ::= { tuwien 6 }
fBTypeDescr
OBJECT IDENTIFIER ::= { fieldBus 1 }
--
Der Unterbaum fBTypeDescr beschreibt, um welche Art des
--
zugänglich gemachten Objektes es sich handelt
fBAccess
OBJECT IDENTIFIER ::= { fieldBus2 }
--
Über die sich hier befindlichen OIDs erhält man die im
--
Feldbus vorhandenen Werte
36
Interne Informationsstrukturen
fBDevDescr
OBJECT IDENTIFIER ::= { fieldBus 3 }
--
In diesem Unterbaum befinden sich generelle Beschreibungen
--
des Feldbusse s und des Gateways.
--
=========
-- OIDs im Unterbaum fBTypeDescr
--
=========
fBTemperatureSensor OBJECT IDENTIFIER ::= { fBTypeDescr 1 }
--
Bei diesem Typ handelt es sich um einen
--
Temperatursensor
fBStatus
OBJECT IDENTIFIER ::= { fBTypeDescr 2 }
--
Bei diesem Typ handelt es sich um den Gerätestatus
--
eines Feldbusgrätes
fBLightSensor
OBJECT IDENTIFIER ::= { fBTypeDescr 3 }
--
Bei diesem Typ handelt es sich um einen
--
Helligkeitssensor
--
==========
-- OIDs im Unterbaum fBAccess
--
==========
fBATable OBJECT-TYPE
SYNTAX SEQUENCE OF fBAEntry
ACCESS not-accessible
STATUS mandatory
::= { fBAccess 1 }
fBAEntry OBJECT-TYPE
SYNTAX
FBAEntry
ACCESS not-accessible
STATUS mandatory
INDEX { fBAIndex }
--
DESCRIPTION
37
Interne Informationsstrukturen
--
In diesen Tabelleneinträgen werden die erreichbaren
--
Feldbusknoten beschrieben.
::= { fBATable 1 }
FBAEntry ::=
SEQUENCE {
fBAIndex
INTEGER,
fBAKind
OBJECT,
fBADescr
DisplayString,
fBAType
INTEGER,
fBAValue
INTEGER,
fBATime
TimeTicks,
fBAValueOld
INTEGER,
fBATimeOld
TimeTicks,
fBATrap
INTEGER,
fBAValue1
INTEGER,
fBAValue2
INTEGER,
fBAStatus
INTEGER,
}
---
fBAIndex OBJECT-TYPE
SYNTAX
INTEGER (1..1024)
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"Index der Tabelle"
::= { fBAEntry 1 }
fBAKind OBJECT-TYPE
SYNTAX
OBJECT IDENTIFIER
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"Die OID beschreibt Art und Funktionalität des
Feldbusobjekts."
::= { fBAE ntry 2 }
38
Interne Informationsstrukturen
fBADescr OBJECT-TYPE
SYNTAX
DisplayString (SIZE (0..255))
MAX-ACCESS
read-write
STATUS
current
DESCRIPTION
"Eine verbale Beschreibung des Wertes wie z.B., in welchem Raum sichder
Temperatursensor befindet"
::= { fBAEntry 3 }
fBAType INTEGER OBJECT-TYPE
SYNTAX
INTEGER { INTEGER(0), STRING(1)}
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"Gibt an, um welche Art von Wert es sich handelt. Also ob der Wert eine
Integer Zahl(0) oder ein String(1) ist."
::= { fBAEntry 4 }
fBAValue OBJECT-TYPE
SYNTAX
INTEGER (0..65535) or DisplayString (SIZE (0..255))
--
abhängig von fBAType
MAX-ACCESS
read-write
STATUS
current
DESCRIPTION
"Dieses Feld enthält den aktuellen Wert des mit der OID beschriebenen
Feldbus Objekts."
::= { fBAEntry 5 }
fBATime OBJECT-TYPE
SYNTAX
TimeTicks
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"Gibt den Zeitpunkt an, zu dem der Wert fBAValue ausgelesen wurde. "
::= { fBAEntry 6 }
fBAValueOld OBJECT-TYPE
SYNTAX
INTEGER (0..65535) or DisplayString
(SIZE
(0..255))
--
abhängig von fBAType
39
Interne Informationsstrukturen
MAX-ACCESS
read-write
STATUS
current
DESCRIPTION
"Dieses Feld enthält den letzten Wert des mit der OID beschriebenen
Feldbus Objekts."
::= { fBAEntry 7 }
fBATimeOld OBJECT-TYPE
SYNTAX
TimeTicks
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"Gibt den Zeitpunkt an, zu dem der Wert fBAValueOld ausgelesen wurde."
::= { fBAEntry 8 }
fBATrap OBJECT-TYPE
SYNTAX
INTEGER { sendNoTrap(0),
sendTrapOnGoingOverLimit (1),
sendTrapOnRapidChange(2),
sendTrapOnRapidChange(3)}
MAX-ACCESS
read-write
STATUS
current
DESCRIPTION
"Hier wird angegeben, ob ein Trap gesendet werden soll oder nicht. Die
Option senden ist dreigeteilt:
(1)
Ein Trap wird gesendet, wenn der aktuelle Wert unter den von
fBAValue1 fällt oder über den von fBAValue2 ansteigt (nur möglich,
wenn der Typ des Wertes INTEGER ist).
(2)
Ein Trap wird gesendet, wenn der Unterschied zwischen fBAValue und
fBAValueOld größer als fBAValue1 ist (nur möglich, wenn der Typ
des Wertes INTEGER ist).
(3)
Ein Trap wird gesendet, wenn die Werte fBAValue und fBAValueOld
ungleich sind, das heißt, daß sich der Wert geändert hat. "
::= { fanoAEntry 9 }
fBAValue1 OBJECT-TYPE
SYNTAX
INTEGER (0..65535)
MAX-ACCESS
read-write
STATUS
current
DESCRIPTION
"Dieses Feld enthält den für die Trapbedingung notwendigen 1. Wert."
::= { fBAEntry 10 }
40
Interne Informationsstrukturen
fBAValue2 OBJECT-TYPE
SYNTAX
INTEGER (0..65535)
MAX-ACCESS
read-write
STATUS
current
DESCRIPTION
"Dieses Feld enthält den für die Trapbedingung notwendigen 2. Wert."
::= { fBA Entry 11 }
fBAStatus OBJECT-TYPE
SYNTAX
INTEGER{stausValid(0), statusNoConnection(1),
statusValuesNotGuaranted(2)}
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"Hier wird angegeben, wie sicher der gelesene Wert ist:
(1)
Die Werte sind mit großer Wahrscheinlichkeit gut.
(2)
Über den jetzigen Wert kann keine Aussage getroffen werden, da die
Verbindung zum Feldbus unterbrochen ist.
(3)
Gewisse Umstände
korrekt sind. "
lassen
darauf
schließen,
::= { fanoAEntry 12 }
--
==============
-- OIDs im Unterbaum fBDevDescr
--
==============
fBInDatagrams OBJECT-TYPE
SYNTAX
INTEGER (0..1024)
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"."
::= { fBDevDescr 1 }
fBOutDatagrams OBJECT-TYPE
SYNTAX
INTEGER (0..1024)
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
" Anzahl der vom Gateway weggegangenen Pakete."
::= { fBDevDescr 2 }
41
daß
die
Werte
nicht
Interne Informationsstrukturen
fBInErrors OBJECT-TYPE
SYNTAX
INTEGER (0..1024)
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
" Anzahl der vom Gateway empfangenen fehlerhaften Pakete."
::= { fBDevDescr 3 }
fBEntries OBJECT-TYPE
SYNTAX
INTEGER (0..1024)
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
" Anzahl der in der Tabelle enthaltenen Einträge."
::= { fBDevDescr 4 }
fBMaxEntries OBJECT-TYPE
SYNTAX
INTEGER (0..1024)
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
" Maximal mögliche Anzahl der in der Tabelle enthaltenen Einträge."
::= { fBDevDescr 5 }
END
42
Grundsätzliche Konzeption der Tasks
8. Grundsätzliche Konzeption der Tasks
Ohne den folgende Kapiteln vorgreifen zu wollen, ist es zu diesem Zeitpunkt notwendig,
grundsätzliche Überlegungen über das Gesamtkonzept anzustellen. Alle Programmteile müssen
auf ein erweitertes MS-DOS-Betriebssystem aufgesetzt sein. Dieses hat folgende Funktionen zu
erfüllen:
1. Starten eines Tasks,
2. Beenden eines Tasks,
3. Übergabe der Prozessor-Kontrolle von einem zu einem anderen Task,
4. Austausch von Informationen zwischen den Tasks über geeignete Datenstrukturen.
Auf diese Umgebung wird eine Datenstruktur aufgesetzt, die von allen Tasks verwendet werden
kann. In dieser Struktur befinden sich alle Werte, die sowohl für die LAN- als auch für die
Feldbusseite von Bedeutung sind.
Feldbus
Security
Task
Get/Set
Task
gemeinsame
Datenstruktur
Trap
Task
Feldbus
Task
Datenmanagement
KA9Q
Taskmanagement
Datenzugriff
Hardwaretreiber
MS-DOS
kommuniziert mit
Abb. 8.1 Task-Konzept
Durch diese Konzeption ist es nun möglich, folgende Tasks unabhängig voneinander zu entwerfen
(Abb. 8.1):
43
Grundsätzliche Konzeption der Tasks
1. SNMP Get, Getnext und Set Task:
Dieser hat die Aufgabe, hereinkommende Pakete auf ihre Richtigkeit zu untersuchen und je
nach Anfrage an das für diesen MIB-Unterbaum zuständige Unterprogramm weiterzuleiten.
Um diese Programmgruppe leicht erweitern zu können, haben alle diese Unterprogramme die
gleiche einfache Struktur: Sie müssen nur bei einfachen Variablen mit einer Auswahlanweisung
den richtigen Wert zurückliefern oder angeben, daß ein solcher nicht existiert. Bei Tabellen ist
es etwas komplizierter, folgt aber dem gleichen Konzept.
2. Feldbus-Task:
Dieser hat die Aufgabe, die in der gemeinsamen Datenstruktur aufgezählten Werte zyklisch aus
den jeweiligen Feldbusknoten zu holen. Bei PROFIBUS ist dies bei FMS eine Umsetzung in
KBL-Nummer und OV-Nummer und die darauf folgende Kommunikation mit dem
PROFIBUS-Partner; bei DP und PA ist es nur eine Verschiebung der Daten innerhalb des
Speichers, da die Daten schon im Speicher vorhanden sind. Dies mag unsinnig klingen, ist aber
als Konzept gedacht, um bei Portierung auf andere Feldbussysteme nur den Feldbus-Task
ändern zu müssen.
Die folgenden, nicht implementierten Tasks sind für die prinzipielle Funktion des Gateways nicht
notwendig.
3. Trap-Task:
Dieser durchläuft die gemeinsame Datenstrukur periodisch und löst bei freigegebenem Trap
beim Auftreten der gewählten Bedingung einen Trap aus.
4. Feldbus-Security-Task:
Dieser Task durchläuft ebenfalls die gemeinsame Datenstrukur periodisch, überprüft nach noch
festzulegenden Algorithmen die Zuverlässigkeit der Feldbuswerte und setzt dementsprechend
den Feldbusknotenstatus (FeldBusMIB.fBAccess.fBAStatus).
44
Realisierung der SNMP-Seite
9. Realisierung der SNMP-Seite
Generell erfolgt die Programmierung in C++. Ein modularer Aufbau des Programms soll spätere
Änderungen und Erweiterungen vereinfachen. Die Grundlage für das ganze Projekt wird durch
den Multitasking-Kernel des Programms KA9Q gebildet. Diese Programmsammlung wurde für
den Gebrauch bei Radioamateuren entwickelt und enthält alle gebräuchlichen Dienste des
TCP/IP-Protokolls wie FTP, finger, ping usw. Es ist auch in Quellcode frei erhältlich und verfügt
über einen UDP Teil. Auf diesen wird das SNMP-Protokoll aufgesetzt. Da nur ein SNMP Agent
ohne Trap-Befehl implementiert wird, beschränkt sich das Protokoll auf das Herausfinden, ob das
angeforderte Objekt vorhanden ist oder nicht. Bei erfolgreicher Suche ist das Ergebnis, ansonsten
eine Fehlermeldung zurückzuliefern.
9.1. KA9Q
KA9Q ist das Rufzeichen von Phil Karn, einem Amateurfunker, auf den dieses Programmpaket
zurückgeht [WAD92]. Bei dem Programm handelt es sich um eine Komplettlösung an
Netzwerkdiensten. Es ist frei erhältlich, und zwar im Sourcecode. Dieser wurde von etlichen
anderen Leuten erweitert und verbessert. In dieser letzten Aussage ist auch schon der große
Nachteil zu erahnen:. Es existieren die verschiedensten unterschiedlichen Varianten. Beschreibungen, falls überhaupt vorhanden, sind äußerst lückenhaft und beziehen sich meist auf
nicht vorhandene Versionen.
Die erste Aufgabe war es, eine möglichst vollständige Version mit möglichst guter Dokumentation zu finden. Die so gefundene Sammlung ließ sich gut mit Borland C++ 3.1 compilieren, die
Compilierung mit der Version 4.0 konnte trotz größerer Anstrengungen nicht erfolgreich durchgeführt werden. Dies lag daran, daß eine nicht dokumentierte Änderung der Parameter der
„longjump“-Funktion von Borland gemacht wurde und deren Auswirkung auf die einzelnen
Programmteile nicht kompensiert werden konnte. Ein weiterer Vorteil dieser Programmsammlung, der aber nicht ausgetestet wurde, ist, daß der Code auch für Amiga- und UNIXSysteme geschrieben ist. Man kann beim Compilieren durch Optionen diese speziellen Teile
aktivieren, wie dies im vorliegenden Fall mit dem MS-DOS-Teil gemacht wurde.
Zwar werden mit den meisten Versionen Treiber für die verschiedenen Arten von Hardware
mitgeliefert, doch wird bei Ethernetkarten empfohlen, einen auf die jeweilige Karte genau abgestimmten Treiber zu verwenden. Folgende Hardware wird von den meisten Versionen unterstützt:
die seriellen Ports COM1-4 für Modem oder Terminal Node Controler, Modems, Ethernet
Karten, Clarkson Treiber, Baycom AX.25 Treiber, DRSI PCPA 8530 Karte, HAPN 8273
Adapter; High speed DRSI/HAPN Treiber, Eagle 8530 Karten, NET/ROMControler, Single- und
multi-port KISS Terminal Node Controler und PACcom PC100. Zu diesen Hardware45
Realisierung der SNMP-Seite
komponenten entsprechend werden die Low-Level-Protokolle KISS, SLIP, PPP, NHRS, ARCnet
und Ethernet unterstützt.
Agent
MIB
ftp
finger
telnet
ping
SMTP
TCP
hope
RIP
SNMP
UDP
IP (ICMP)
SLIP / PPP
ax25 / KISS
Modem
TNC
Paket Treiber
Ethernet
Abb. 9.1KA9Q Dienste (auszugsweise)
Aufbauend auf diese vorhandene Grundstruktur (Abb. 9.1KA9Q Dienste (auszugsweise)) wurde
eine der Aufgabenstellung entsprechende Konfiguration vorgenommen. Von den Hardwaremöglichkeiten wurden eine Ethernetkarte und ein zusätzlicher Pakettreiber mit dem Namen
3c509.com installiert. Weitere Netzanbindungen wurden nicht eingerichtet.
9.2. Starten des vorhandenen Systems
Nachdem das Programm mit den richtigen Optionen compiliert und gelinkt worden war, dies
erfolgte mit dem dem Sourcecode beigefügten Makefile, konnte daran gegangen werden, es in
Betrieb zu nehmen. Ein Makefile ist meist eine angenehme Arbeitsersparnis, in diesem Fall ist es
aber eine unbedingte Notwendigkeit, da ein Erkennen der gegenseitigen Abhängigkeit bei einigen
Dutzend C-Files samt dazugehörigen Headerfiles und einem halben Dutzend Libraries ohne
genaue Beschreibung, die in diesem Falle (wie erwähnt) nicht vorhanden ist, äußerst schwierig
und zeitaufwendig wäre (vielleicht auch unmöglich, da für einzelne Programme spezielle
Segmentzuweisungen notwendig sind). Zuerst muß der Pakettreiber mit dem Parameter der ihm
zugewiesenen Interruptadresse gestartet werden. Hier wurde die auch den Einschränkungen
entsprechende Nummer 61hex gewählt. Jetzt kann KA9Q durch Starten des Files net.exe in Betrieb
genommen werden. Um die notwendigen Einstellungen nicht jedesmal neu eingeben zu müssen,
46
Realisierung der SNMP-Seite
erweist es sich als sinnvoll, diese in der Datei autoexec.nos (Listing 9.1
abzuspeichern. In ihr wird jedesmal beim Starten von net.exe ausgeführt.
autoexec.nos)
attach packet 0x61 e 8 1500
ifconfig e ipaddress 128.130.80.74
ifconfig e netmask 0xffffffff
ifconfig e broadcast 255.255.255.255
route add default e
ftype binary
eol standart
Listing 9.1
autoexec.nos
Die in dem Listing angegebenen Grundeinstellungen bewirken, zeilenweise erklärt, folgendes:
(1) Dem Kanal e (der Name ist frei wählbar) wird der Pakettreiber, der dem Interrupt 61hex
zugeordnet ist, zugewiesen.
(2) Dem Kanal e wird seine Internetadresse zugewiesen. In diesem Fall ist das die Adresse des PC
74 am Institut für Computertechnik (128.130.80.74).
(3) Dem Kanal e wird seine Netzwerkmaske zugewiesen.
(4) Dem Kanal e wird die am Netzwerk vorhandene Broadcast-Adresse mitgeteilt.
(5) Da noch andere Treiber vorhanden sein könnten, muß dem Programm mitgeteilt werden, daß
alle ausgehenden Pakete über diesen Kanal erfolgen sollen.
(6) Diese Zeile besagt, daß Files binär übertragen werden.
(7) Für eol ist das Standardformat zu verwenden.
Außer diesen Einstellungen wurden bei der vorliegenden Arbeit keine weiteren verwendet.
9.3. Einfügen eines Tasks in den Kernel
Bevor an das Einfügen eines neuen Tasks gegangen werden kann, muß kurz der allgemeine
Aufbau von KA9Q beschrieben werden. Der erste Teil dient zur Speicherverwaltung. In diesem
werden die in C üblichen Funktionen wie etwa malloc redefiniert und teilweise auch in verschiedenen Formen angeboten. Diese Formen ermöglichen, daß beim Fehlen von Systemressourcen keine Fehlermeldung zurückgegeben wird, sondern auf deren Freiwerden gewartet
wird. Ein weiterer großer Teil ist der des Taskmanagements. Hier werden Funktionen zur Bearbeitung der Tasks, zum Starten, Beenden, Suspendieren und zum Warten auf ein Ereignis zur
Verfügung gestellt. Untereinander kommunizieren die einzelnen Programmteile über Message
Buffer. Weiters steht eine beachtliche Anzahl von Protokollen zur Verfügung, die ihre Dienste
über Funktionsaufrufe zugänglich machen.
47
Realisierung der SNMP-Seite
Um einen Task eizufügen, der bei Programmbeginn gestartet wird, muß man in config.c die
Struktur daemon um den gewünschten Task erweitern. Dazu ist ein Name, unter dem er im
System aufscheint, die Größe des erforderlichen Stacks und der Name des C-Programms in diese
Struktur einzutragen (Listing 9.2 Änderungen in config.c).
/* daemons to be run at startup time */
struct daemon Daemons[] =
{
{ "killer", 512,
killer },
{ "gcollect", 256,
gcollect },
{ "timer",
1024, timerproc },
{ "network", 1536, network },
{ "keyboard", 250,
keyboard },
{ "Das ist der neue Task", 250,
neu },
{ NULLCHAR, 0,
NULLVFP }
};
Listing 9.2
Änderungen in config.c
In dem oben gezeigten Beispiel wurde ein Task mit dem C-Programmnamen neu.c eingefügt, der
in der Taskliste unter „Das ist der neue Task“ aufscheint. Da ein Task auch für die mit ihm
arbeitenden Mechanismen definiert sein muß, ist auch eine Änderung in demon.h vorzunehmen
(Listing 9.3 daemon.h eingefügte Zeile).
/* In snmp_sok.c: */
void neu __ARGS((int,void*,void*));
Listing 9.3
daemon.h eingefügte Zeile
Der so eingefügte Task (Listing 9.4 Neuer Task mit Endlosschleife) besteht prinzipiell aus zwei
Teilen: einem, der einmal durchlaufen wird, und zweitens entweder aus einem Funktionsaufruf,
der den Task wieder aus dem System entfernt, oder einer Endlosschleife, in der ein Aufruf für eine
Taskwechselfunktion enthalten sein muß - wie etwa pwait (definiert in ksubr.h) oder pause
(definiert in timer.h). Das Listing, der nach der obigen Änderungen in config.c in einer Endlosschleife läuft und seinen Namen abwechselnd von Ablauf 1 in Ablauf 2 und umgekehrt ändert. Der
pause-Befehl gibt den Prozessor für andere Tasks frei.
48
Realisierung der SNMP-Seite
#include “timer.h“
Void neu(i,v1,v2)
int i;
void v1;
void v2;
{
for(;;)
{
chname(Curproc,"Ablauf 1");
pause(100);
chname(Curproc,"Ablauf 2");
pause(100);
}
}
Listing 9.4 Neuer Task mit Endlosschleife
9.4. Datenstruktur von UDP und Zugriffsverfahren
KA9Q stellt sowohl den Zugriff auf IP als auch auf UDP-Pakete zur Verfügung. Um diese
Funktionen verwenden zu können, muß man quasi den Kanal öffnen und angeben, welche Portadresse einem bestimmten C-Programm zugeordnet ist. Nachdem diese Zuordnung stattgefunden
hat, wird dieses C-Programm beim Eintreffen eines Paketes auf dieser Portadresse aufgerufen.
Innerhalb dieses Tasks, muß man nun die Daten mit der receive-Funktion anfordern und weiterverarbeiten. Der Erhalt dieser Daten erfolgt über mbuf (Listing 9.5),
/* Basic message buffer structure */
struct mbuf {
struct mbuf *next; /* Links mbufs belonging to
single packets */
struct mbuf *anext; /* Links packets on queues */
int16 size;
/* Size of associated data
buffer */
int refcnt;
/* Reference count */
struct mbuf *dup;
/* Pointer to duplicated
mbuf*/
char *data;
/* Active working pointers */
int16 cnt;
};
Listing 9.5
Struktur mbuf
einer Datenstruktur, die ein Array mit den Nutzdaten enthält und zum Austausch von Daten
zwischen verschiedenen Tasks dient. Um einen Dienst anzustoßen, übergibt man einen mbuf
mittels der Sendfunktion an den gewünschten Protokoll-Task.
9.5. Darstellung von ASN.1 Paketen in C-Strukturen
Die vom UDP-Task zur Verfügung gestellte Funktion zum Empfang von Paketen recv_udp(struct
*udp_cb, struct *socket, struct **mbuf) bietet die Rohdaten in der Struktur mbuf an. Diese
49
Realisierung der SNMP-Seite
Struktur enthält unter anderem ein Array of char, in dem die Daten dann auch wirklich enthalten
sind. Da es unhandlich und unübersichtlich ist, mit so einer unstrukturierten Ansammlung von
Daten zu arbeiten, führt die Funktion asn_to_c eine Umsetzung in eine C-Zeiger-Struktur nach
Abb. 9.2 aus.
Pointer
asn_pack
nr (int)
oid_seq
laenge (int)
flags (int)
version (int)
oid (char[128])
name (char[64])
typ (int)
art (int)
wert (*)
error (int)
next (*)
error_ind (int)
oids (*)
oid_seq
oid_seq
flags (int)
flags (int)
oid (char[128])
oid (char[128])
typ (int)
typ (int)
wert (*)
wert (*)
next (*)
next (*)
Abb. 9.2
NIL
C Struktur
Bei dieser Struktur entspricht asn_pack genau einem hereinkommenden SNMP-Paket.Für jede in
ihm enthaltene Anfrage muß eine oid_seq angereiht werden. Die dazu inverse Funktion hat den
Namen c_to_asn. Die beiden Funktionen asn_to_c und c_to_asn sind in dem neuen C-Modul
asn_subr.c enthalten. Definiert sind sie, um einen leichteren Zugriff auf sie zu ermöglichen, in
snmp_sok.h.
9.6. Zugriff auf im System vorhandene Werte
Da auf große Modularität geachtet wurde, ist die Abarbeitung der SNMP Anfragen für alle zu
implementierenden Gruppen gleich aufgebaut (Listing 9.6
Tabelle Unterbaum). Eine Schleife
durchsucht eine Tabelle, ob ein gesuchter Unterbaum vorhanden ist. Falls dieser (bei einem GetBefehl) oder der nächst größere (bei einem GetNext-Befehl) existiert, wird die in der Tabelle
stehende Prozedur aufgerufen.
50
Realisierung der SNMP-Seite
struct u_mib {
// Stukur zur Zuordnung zwischen OID des
//Unterbaumes und
der dazugehörigen Funktion
void
(*u_fkt_mib) __ARGS((struct oid_seq *, int));
//Pointer auf die den Unterzweig bearbeitende
//Funktion
int
n1[128];
//OID des Unterbaumes
};
void
void
void
void
void
void
void
m_system
m_if
m_at
m_ip
m_icmp
m_udp
m_snmp
__ARGS(());
// Definition der Namen, um die
__ARGS(()); // Funktionen auch in anderen
__ARGS(());
// C-Programmen unterbringen zu
__ARGS(());
// können
__ARGS(());
__ARGS(());
__ARGS(());
struct u_mib mibs[] =
{
{m_system,
{m_if,
{m_at,
{m_ip,
{m_icmp,
{m_udp,
{m_snmp
{0,
// Tabelle, in der die Zuordnungen
// eingetragen sind
43,6,1,2,1,1,-1},
//Zuordnung OID //1.3.6.1.2.1.1 zur
Funktion m_system
43,6,1,2,1,2,-1},
//Zuordnung OID //1.3.6.1.2.1.2 zur
Funktion m_if
43,6,1,2,1,3,-1},
//Zuordnung OID //1.3.6.1.2.1.3 zur
Funktion m_at
43,6,1,2,1,4,-1},
//Zuordnung OID //1.3.6.1.2.1.4 zur
Funktion m_ip
43,6,1,2,1,5,-1},
//Zuordnung OID //1.3.6.1.2.1.5 zur
Funktion m_ icmp
43,6,1,2,1,7,-1},
//Zuordnung OID //1.3.6.1.2.1.7 zur
Funktion m_udp
43,6,1,2,1,11,-1},
//Zuordnung OID //1.3.6.1.2.1.11 zur
Funktion m_snmp
0,0,0,0,0,0,0,0}
//Abschluß der Tabelle, um //schleifenmäßige
Verarbeitung
//durchführen zu können
};
Listing 9.6
Tabelle Unterbaum
In dieser Funktion muß dann nur mehr der fehlende Rest der OID verglichen werden und je nach
Anfrage das Ergebnis zurückgeliefert werden. In der System-Gruppe, einer nur aus einfachen,
nicht zusammengesetzten Elementen bestehenden Gruppe, läßt sich dies mit einer case-Anweisung, die die letzte Ziffer als Auswahlkriterium hat, bewerkstelligen (Listing 9.7).
51
Realisierung der SNMP-Seite
void m_system(oid_s_p,l)
//übergebene Parameter:
//Pointer auf die zu
//
bearbeitende OID Struktur
//Integerzahl die die Tiefe des //
Unterbaumes angibt
struct oid_seq *oid_s_p;
int
l;
{
switch(oid_s_p->oid[l]){
case 1:
free(oid_s_p->wert);
// Lösc hen des alten Wertes
oid_s_p->wert = calloc(20,sizeof(char));
//Bereitstellen eines Speicherbereiches
//für den neuen Wert
strcpy(oid_s_p->wert,"Gerätebezeichnug");
//einfügen des neuen Wertes
oid_s_p->typ = STRING;
break;
case 2:
...........//für End-OID 2-7 sind hier analoge
//Einträge
...........................
break;
}
}
Listing 9.7
Prozedur m_system
Zuvor muß noch eine Unterscheidung zwischen Get und GetNext getroffen werden. Bei Get ist
sicherzustellen, daß der Auswahlzahl eine Null folgt. Bei GetNext ist eventuell eine Korrektur der
Adresse nötig, wenn es sich um eine Weitergabe aus einer Vorgruppe handelt. Bei der Auslesung
von im Programm vorhandenen Werten ist dieser an der betreffenden Stelle als extern zu
kennzeichnen. Wie schon an Hand der MIB erklärt, ist das Auslesen einer Tabelle durch einen
Endindex gekennzeichnet, der das Element angibt. Als Beispel für eine Tabelle sei hier der Zugriff
auf die ifTabelle gezeigt (siehe folgenden Ausschnitt aus der Interfaces MIB; die ganze Funktion
hat nicht nur einen, sondern 23 Einträge in der Tabelle).
52
Realisierung der SNMP-Seite
void m_if(oid_s_p,l,art)
//Funktion zur Abarbeitung
//der MIB Interfaces
struct oid_seq *oid_s_p;
int
l,art;
{
int
*i_p,i;
switch(oid_s_p->oid[l]){
//Auswahl, welches Element
//der MIB gewält wurde
//1. Element Anzahl der
//Interfa ces
case 1:
free(oid_s_p->wert);
oid_s_p->wert = calloc(1,sizeof(int));
oid_s_p->wert=2;
oid_s_p->typ = INTEGER;
break;
case 2:
//2. Element Interfaces//Tabelle
//wenn nur Tabelle angewählt
//wurde mit GetNext muß MIB-Nummer
//des ersten Elements der Tabelle
//eingesetzt werden
if((oid_s_p->oid[l+1]==1)&&(oid_s_p->oid[l+2]==-1)&&
(art==GETNEXTREQUEST))
{oid_s_p->oid[l+2]=1;
oid_s_p->oid[l+3]=1;
oid_s_p->oid[l+4]=-1;
}
else
//Bei GetNext muß das nächste
//Element zurückgeliefert werden
if((oid_s_p->oid[l+1]==1)&&(oid_s_p->oid[l+4]==-1)&&
(art==GETNEXTREQUEST))
if(liste[oid_s_p->oid[l+3]].index==-1)
//Falls letztes Element in Spalte
//Übergang zur nächsten
{oid_s_p->oid[l+3]=1;
oid_s_p->oid[l+2]++;}
else
oid_s_p->oid[l+3]++;
i=oid_s_p->oid[l+3];
switch(oid_s_p->oid[l+2]){
case 1:
//der erste Eintrag ist die
//Interface-Nummer
free(oid_s_p->wert);
oid_s_p->wert = calloc(1,sizeof(int));
oid_s_p->wert= i;
oid_s_p->typ = INTEGER;
break;
case 2: // der zweite Eintrag ist die
//Interface-Besdchreibung
//Für die weiteren Felder der Tabelle erfolgen
//äquivalente Einträge
53
Realisierung der PROFIBUS-Seite
10. Realisierung der PROFIBUS-Seite
Da bei der Implementation der SNMP-Seite schon ein Multitasking Kernel gewählt wurde, ist es
einfacher, auch das PROFIBUS-Protokoll in diese Umgebung einzubetten. In der ersten
Ausbauphase wird die Komunikationsbeziehungsliste statisch vor den Start des Programmes
geladen. Eine dynamische Erweiterung der KBL des Gateways kann als Erweiterung implementiert werden. Der Zugriff auf den PROFIBUS erfolgt über von Treibermodulen zur Verfügung
gestellte Funktionsaufrufe.
10.1. Installation der PROFIBUS-Karte
Die Implementierung erfolgte mit einer PC-Einsteckkarte CIF 11 der Firma Hilscher. Bevor die
Karte in Betrieb genommen werden kann, sind sie und der PC entsprechend zu konfigurieren.
Folgende Einstellungen müssen auf der Karte selbst vorgenommen werden:
J1: 1-2, J2: 2-3
für Verwendung des Speicherbausteins 27C020 auf der Karte
J3: 1-2, 5-6, 7-8, 10-11
für Verwendung des 28F256A-120 FlashROMS auf der Karte
J5: IRQ5
für Verwendung des Interrupt 5 des PC
J6: A17, A14, A13, A12, A11 für Verwendung der Basisadresse 0xD800 für das DualportMemory der Karte
J7: 2-3
für Verwendung des Interruptbetriebes
J8: 1-3, 2-4, J9: 1-2, J10: 1-2, J11: offen, J12: offen, J13: 1-2 für Verwendung im
PROFIBUS-Netz
Nachdem die richtige Einstellung der Jumper auf der Karte vorgenommen worden ist, muß auch
noch das PC-Setup dementsprechend geändert werden. Der Basisadressbereich, in diesem Fall
0xD800, muß für 2 kByte geschützt werden und darf hier nicht als Shadow-RAM benutzt
werden, da sonst ist ein Betrieb des Dual-Port-Memory nicht möglich ist.
10.2. Test der PROFIBUS-Karte
Im Lieferumfang der PC-Karte ist auch eine Projektierungs- und Testsoftware mit dem Namen
COMPRO inkludiert, mit deren Hilfe die Funktion der Karte überprüft werden kann. Weiters wird
diese Software auch zur Konfiguration der Karte verwendet. Um den Aufwand gering zu halten,
54
Realisierung der PROFIBUS-Seite
wird dieses Programm mit einem Batch-Programm aufgerufen (Listing 10.1 Compro.bat), das
folgenden Zeilen enthält, um COMPRO auf die zuvor durchgeführte Karteneinstellungen
abzustimmen.
Inhalt von CPRUN.BAT:
@ECHO OFF
CLS
ECHO Starting ComPro ..
COMPRO /A:D800 /H:IRQ /I:5
Listing 10.1
Compro.bat
Mit diesem Batch-Programm wird die Adresse des Dual-Port-Memory auf 0xD800 gesetzt und
Interrupt 5 als der für die Karte verwendete angegeben. Das Programm COMPRO benötigt viel
konventionellen Speicher, deshalb ist es eventuell notwendig, nicht verwendete Treiber aus
CONFIG.SYS und AUTOEXEC.BAT zu entfernen.
Um sicherzugehen, daß die bisherigen Schritte erfolgreich waren, empfiehlt es sich an dieser
Stelle, mit einem Bus-Monitor festzustellen, ob die Karte im Profibus-Karte als Busteilnehmer
aufscheint. Bei der hier vorliegenden Testimplementation in Kompetenzzentrum des Institutes für
Computertechnik wurde der Karte die Teilnehmeradresse 11 zugeteilt. Diese müßte zu diesem
Zeitpunkt auch am Bus-Monitor angezeigt werden.
Um eventuelle Fehlerquellen auszuschalten, sollte beim Einschalten der Profibuswand die
Hilscher-Karte schon in Betrieb sein, damit etwaige andere Master nicht die vorhandenen SAPs
bei Slaves, die eventuell nur wenige besitzen, belegen und die Karte keinen Zugriff mehr
bekommt.
10.3. Projektierung der PROFIBUS-Seite
Um eine Kommunikation zu einem anderen Profibus-Gerät aufbauen zu können, müssen die
Teilnehmeradresse der Karte eingestellt und die Kommunikationsbeziehnungsliste (KBL) erstellt
werden. Diese Projektierung wird mit dem oberhalb erwähnten Programm COMPRO durchgeführt. Es wird damit eine Projektdatenbank erstellt und in ein EEPROM auf der Karte
hinuntergeladen. Es müssen hier alle Einträge für die Sektionen BUS, KBL-Header und KBL
gemacht werden. Die Sektionen OV-Header und S_OV_0 sind in diesem Fall nicht notwendig, da
die Karte nur als Client arbeitet und keinerlei Variablen für andere Master zur Verfügung stellt.
55
Realisierung der PROFIBUS-Seite
Hier wurden Kommunikationsbeziehungen zu den an der Multivendoranlage vorhandenen FMSSlaves erstellt. Das sind ein Zähler der Firma Hengstler, ein Entfernungsmesser der Firma
Endress+Hauser und Ein/Ausgabe-Module der Firma Weidmüller.
KR
ADRL
SAPL
ADRR
SAPR
SCC
RCC
MPDU
Serv
1
11
1
10
3
1
0
241
30
2
11
2
12
34
1
0
204
30
3
11
3
8
3
1
0
241
30
Listing 10.2
KBL Hilscherkarte
Die in Listing 10.2 ersichtlichen Kommunikationsreferenzen (KR) werden gemeinsam mit der
Objekt Nummer die eindeutige Identifikation eines PROFIBUS Objektes ermöglichen. Die Abkürzungen, die in Abb. 5.3 genauer erklärt sind, lauten wie folgt:
KR
Kommunikationsreferenz
ADRL
lokale Adresse
SAPL
lokaler SAP
ADRR
remot Adresse
SAPR
remot SAP
SCC
Source recive Confirmed Counter
RCC
Destination recive Confirmed Counter
MPDU
maximale PDU-Länge
Serv
unterstützte Dienste
10.4. Der zweite Teil der Struktur Feld_Knoten
Da dieses Konzept auch leicht auf andere Feldbussysteme übertragbar sein soll, wurde auf eine
strikte Trennung von SNMP und Feldbus geachtet. Erst sehr spät werden beide Teile miteinander
verbunden. Deshalb wird hier zuerst nur der für den Feldbus notwendige Teil der Struktur
Feld_Knoten behandelt.
Wie in Kapitel 7 erörtert wurde, wird im Gateway ein Abbild der PROFIBUS-Seite erstellt. Diese
kann entweder in einer dynamischen oder einer statischen Datenstruktur (wie in dieser
Implementation) erfolgen. Eine Änderung von der einen zur anderen Art kann ohne Änderung des
Grundkonzeptes jederzeit erfolgen. Das hier verwendete Array hat die in der MIB angegebene
Länge und hat als Felder Records, die alle in der MIB enthaltenen Tabelleneintragsfelder und
zusätzlich die für den Feldbus und die Verwaltung notwendigen Einträge enthalten (Listing 10.3
56
Realisierung der PROFIBUS-Seite
Zweiter Teil der Struktur Feld_Knoten). Für PROFIBUS sind das Kommunikationsreferenz, die
man aus der KBL entnehmen kann, Objektindex und zur leichteren Auswahl der richtigen
PROFIBUS-Funktionen eine Angabe über den Datentyp. Um alles ganz modular zu halten,
werden noch Felder, ob ein Trap Ereignis aufgetreten ist und ob der Inhalt in der Feldbus
geschrieben werden soll und deshalb nicht überschrieben werden darf. Dieses Schreibeflag muß,
wenn der Feldbus den Wert geschrieben hat, zurückgesetzt werden.
// Konstanten-Definitionen für die Art des Schreibstatus
#define
read_only
-1
//Verbot für SNMP-Seite diese Variable
//zu beschreiben
#define
read
0
//SNMP_Seite liest diesen Wert
//(Normalzustand)
#define
write
1
//SNMP Seite hat diese Variable g esetzt,
//darf von Feldbus erst nach
//Übertragung und Rücksetzung wieder
//beschrieben werden
// Konstanten-Definitionen ob ein Trap aufgetreten ist
#define t_no
0
//kein erlaubter Trap ist aufgetreten
#define t_yes
1
//ein erlaubter Trap ist aufgetreten
struct tabellen_eintrag{
...............
...............
int kbl_nr;
//Nummer der Kommunikationsbeziehung in der KBL
int ov_nr;
//Feldbus-Objektnummer der Variable
int o_type;
//Typ des Objektes (z.B. Integer8, Integer16,
//Integer32, ..... ..)
int read_status;
//angaben über den Zugriffstatus laut obriger
//Konstanten Definitionen
int a_trap;
//Anzeige ob ein erlaubter Trap aufgetreten ist
};
Listing 10.3
Zweiter Teil der Struktur Feld_Knoten
Generell muß darauf geachtet werden, daß diese Datenstruktur allen notwendigen Tasks
zugänglich sein muß und diese die Änderungen so durchführen, daß keine ungültigen Zustände in
einem Record auftreten. Dies erreicht man dadurch, daß während der Änderung eines Records ein
Taskwechsel verboten wird. Bei dem von KA9Q verwendetem Schedulingmechanismus, der jeden
Task für die Abgabe der Resourcen selbst verantwortlich macht, bildet dies keine
Schwierigkeiten. Beim Wechsel auf ein anderes Schedulingsystem wäre dafür extra Sorge zu
tragen.
10.5. Der PROFIBUS-Task
Der Aufbau des PROFIBUS-Task ist sehr an die Vorgaben der Firma Hilscher angelehnt. Die CProgramme drv.c und dpml.c wurden samt dazugehörigen Headerfiles eins zu eins übernommen.
Sie erledigen die Kommunikation mit dem Betriebsystem und der PC-Karte und stellen die zur
57
Realisierung der PROFIBUS-Seite
Kommunikation notwendigen Grundlagen zur Verfügung. Da sie weder Ausgabefunktionen besitzen noch Funktionen beinhalten, die von KA9Q redefiniert wurden, ist diese unveränderte
Übernahme gerechtfertigt. Auf diesen Unterbau setzt das C++ Programm hil-card.cpp auf. Bei
diesem C++ Programm ist gleich auf mehrere Sachen zu achten. Einerseits handelt es sich um das
erste C++ Programm. Für dieses sind einige Änderungen im Makefile vorzunehmen. Alle
Anweisungen, die das Compilieren von C-Programmen zur Folge haben, müssen ein zweites Mal
für die Handhabung von C++ geschrieben werden. Die schon im Abschnitt „Einfügen eines Tasks
in den Kernel“ beschriebenen Ergänzungen müssen natürlich ebenfalls vorgenommen werden.
Andererseits muß auch das Programm der Firma Hilscher umgeschrieben werden. Alle printfBefehle müssen entweder durch tprintf, fprintf oder durch Beschreiben der Variable Feld_Knoten
ersetzt oder gänzlich gestrichen werden. Weiters muß das Programm multitaskingfähig werden.
Alt:
*/
#define ToScr(a)
tprintf(a)
/* MSC graphic output
#define _settextposition( a, b )
...................................................
_settextposition( 8,30);
sprintf( Str, " , Value
=%-7d\n", sVar);
ToScr( Str);
..........................................................
sRet = TeleRcv( &tMyCon, 500 );
Neu:
extern "C"
{
#include "timer.h"
}
//exportiert pause(x)
.............................................
tprintf(" , Value
=%ld\n", (long)sVar);
//dieser Wert wird jetzt am Bildschirm angezeigt
....................................................
pause(500);
//mit diesem Befehl erfolgt ein Taskwechsel
sRet = TeleRcv( &tMyCon, 0 );
//hier wurde die Wartezeit auf 0 gesetzt
Listing 10.4
Änderungen in hil_card.cpp
Dies wird am einfachsten dadurch erreicht, daß man die Funktionsaufrufe, die eine gewisse Zeit
lang auf eine Antwort warten sollen, so umändert, daß zuerst eine Pause programmiert wird und
dann ein Funktionsaufruf mit keiner Wartezeit. Der pause-Befehl aus timer.h nimmt einen
Taskwechsel vor (Listing 10.4 Änderungen in hil_card.cpp).Auf dieses Programm setzen zwei
weitere auf. Das erste, genannt hilscher_z.cpp, stellt Zugriffe auf „normale“ (einfache, wie etwa
Integer8, Integer16 usw.) PROFIBUS-Variablen zur Verfügung. Eh_fmu.cpp ist speziell für den
Entfernungsmesser von Endress und Hauser geschrieben. Dieser verwendet einen speziellen
58
Realisierung der PROFIBUS-Seite
Record zur Übermittlung der Daten. Um die gewünschten herauszuholen, mußten zum
hilscher_z.cpp einige Zusätze gemacht werden. Alle die genannten Programme stellen nur
Funktionen, Typen und Zugriffsverfahren für profibus.cpp zur Verfügung. Profibus.cpp wird wie
vorher für die SNMP-Seite beschrieben als eigener Task in KA9Q eingefügt.
profibus.cpp
Feld_bus
hengst_z.cpp
eh_fmu.cpp
hilscher.cpp
drv.c
drpm.c
PROFIBUS
Hilscher -Karte
Abb. 10.1
Zusammenspiel der PROFIBUS Programmteile
Der Task profibus ist dafür zuständig, die gelesenen PROFIBUS-Daten in die Struktur Feld_Bus
hineinzuschreiben. Davor wird das Feld Wert in das Feld Wert_Alt abgespeichert. Dasselbe
geschieht mit dem Zeit-Feld. Dies alles darf aber nur gemacht werden, wenn nicht das Feld zum
Lesen gesetzt ist. Für die Implementierung von trap Funktionen ist ein eigener Task zuständig.
Die Aufgabe eines weiteren Tasks ist es, die Felder über die Zuverlässigkeit der Daten aktuell zu
halten.
10.6. Zusätze beim SNMP-Task
Zusätzlich zu den für die allgemeine MIB notwendigen Funktionen benötigt man speziell solche,
die Anfragen der Feldbus-MIB beantworten. Dafür wurden in die Funktionsauswahl der Unterbaum fBAcces und fBDescr (Listing 10.6 m_devDescr) eingetragen. Auf Grund der Programmierung ist darauf zu achten, daß die einzelnen Einträge in aufsteigender Reihenfolge eingetragen
werden (Listing 10.5 Erweiterungen in mib.h).
59
Realisierung der PROFIBUS-Seite
struct u_mib mibs[] =
{
{m_system,
43,6,1,2,1,1,-1},
.....................................
// Hier sind die Verweise auf die
// restlichen Unterbäume der MIB eingetragen
.....................................
.....................................
{m_Access,
43,6,1,4,1,1093,51,6,2,-1},
{m_DevDescr, 43,6,1,4,1,1093,51,6,3,-1},
{0,
0,0,0,0,0,0,0,0}
};
Listing 10.5
Erweiterungen in mib.h
In einem eigenen C-Programm, das wie schon vorher beschrieben in das Multitaskingsystem
eingebettet wird, werden diese beiden Funktionen bereitgestellt. Es besitzt einen ähnlichen Aufbau
wie die Unterprogramme zum Auslesen von Systemwerten. Nur werden in diesem Fall Werte aus
der gemeinsamen Struktur Feld ausgelesen.
#include "feld.h"
#include "snmp_sok.h"
extern int f_in, f_out, f_error;
//diese drei Variable müssen vom SNMP-Task
//zur Verfügung gestellt werden für fBDescr
void m_DevDescr(oid_s_p,l,art)
struct oid_seq *oid_s_p;
int
l,art;
{
int i;
switch(oid_s_p->oid[l]){
//da es sich hier um eine
// einfache Liste handelt,
// muß nur nach der Endzah
// entschieden werden
//die erste Fallunterscheidung ist
//zur Gänze dargestellt, bei
//den restlichen wurde alles bis auf
//die Wertzuweisung weggelassen
case 1:
free(oid_s_p->wert);
//Löschen des alten Wertes
oid_s_p->wert = calloc(1,sizeof(int));
//Platz für neuen Wert reservieren
oid_s_p->wert = f_in;
//Wert zuweisen; in diesem Fall
60
Realisierung der PROFIBUS-Seite
//Anzahl der hereinkommenden SNMP-Pakete
oid_s_p->typ = INTEGER;
//Typ des Wertes zuweisen
break;
case 2:
oid_s_p->wert = f_out;
//Wert zuweisen; in diesem Fall
//Anzahl der hinausgehenden SNMP-Pakete
case 3:
oid_s_p->wert = f_error;
//Wert zuweisen; in diesem Fall
//Anzahl der fehlerhaften SNMP-Pakete
case 4:
i=0;
//Berechnung, wie viele Einträge in der
//Struktur Feld vorhanden sind
while(liste[i].index != -1) i++;
oid_s_p->wert = i; ;
//Wert zuweisen; in diesem Fall Anzahl
// der Einträge in der Struktur Feld
case 5:
oid_s_p->wert = 128;
//Wert zuweisen; in diesem Fall Anzahl
//der in der Struktur Feld
//möglichen Einträge
}
}
Listing 10.6
m_devDescr
Bei den in diesem Abschnitt behandelten Werten stößt man auf ein bei SNMP weit verbreitetes
Problem. Die Daten, die zur Verfügung gestellt werden, klingen sehr einfach, werden aber
teilweise von verschiedenen Leuten jeweils verschieden interpretiert. Wie sind also die Werte f_in,
f_out und f_error zu verstehen? Werden die fehlerhaften Pakete auch als einlangende gezählt oder
nicht? Bei dieser Implementation werden sie bei beiden Zählern mitgezählt. Bei anderen Werten,
die SNMP-fähige Geräte unterstützen, kann es jedoch bei unterschiedlichen Herstellern aus
diesem Umstand zu großen Differenzen kommen. Zusammenfassend gesagt: Einige Werte von
SNMP sagen wenig aus, ohne die genaue Auffassung des Herstellers zu kennen. Schön und
übersichtlich wäre es, wenn für alle derartigen Werte verbindliche Vorschriften wie für diese drei
Werte mittels Casediagramm gemacht würden (Abb. 10.2).
61
Realisierung der PROFIBUS-Seite
darüberliegender Layer
f_error
f_in
f_out
darunterliegender Layer
Abb. 10.2
Case Diagramm
Als letztes in diesem Abschnitt über den PROFIBUS-Task soll noch die zweite Funktion, nämlich
f_access angeschnitten werden. Dies speziell aus dem Grund, daß Kenntnis über den Aufbau
dieser Funktion es erheblich erleichtert, mit Tabellen in der MIB umzugehen. Um es
übersichtlicher zu gestalten, werden zuerst die interessanten Zeilen ohne Kommentar in den Text
gestellt und dann genau beschrieben.
void m_Access(oid_s_p,l,art)
struct oid_seq *oid_s_p;
int
l,art;
Diese Zeilen sind für alle aufzurufenden Unter-MIBs gleich und in feld.h definiert.
switch(oid_s_p->oid[l]){
Da die Tabelle an Stelle eins in diesem Unterbaum steht, muß in der charakteristischen Zahlenfolge an dieser Stelle eine 1 stehen.
case 1:
if((oid_s_p->oid[l+1]==1)&&(oid_s_p->oid[l+2]
==-1)&&
62
Realisierung der PROFIBUS-Seite
(art==GETNEXTREQUEST))
{oid_s_p->oid[l+2]=1;
oid_s_p->oid[l+3]=1;
oid_s_p->oid[l+4]=-1;
}
Es existieren zwei Möglichkeiten, Werte aus einer Tabelle einer MIB zu bekommen: Entweder
man spricht einen Wert direkt an und bekommt mit Get diesen oder mit GetNext den nächsten,
oder man verwendet den GetNext-Befehl, um zum ersten Wert der Tabelle zu kommen. Im
zweiten Fall wird die Endung 1.1 gewählt. Der erste Einser steht als Ordnungszahl für die Tabelle,
der zweite für Tabellenindex. Dieser zweite Einser darf auch bei allen anderen Zugriffen nicht
weggelassen werden. Deshalb hat auch die Endung für Zugriffe auf diese einfach indizierte
Tabelle vier Zahlen. Die Zahl -1 wurde als nicht in der MIB vorkommende Zahl als Abschluß
einer OID gewählt.
else
if((oid_s_p->oid[l+1]==1)&&(oid_s_p->oid[l+4]==-1)&&
(art==GETNEXTREQUEST))
if(liste[oid_s_p->oid[l+3]].index==-1)
{oid_s_p->oid[l+3]=1;
oid_s_p->oid[l+2]++;}
Mit dem GetNext-Befehl wird in der MIB jeweils eine Spalte von oben nach unten durchwandert.
Dies ist hilfreich, wenn man z.B. von allen Sensoren wissen möchte, ob ihre Werte zuverlässig
sind. Nachdem das letzte Element einer Spalte erreicht wurde, wird mit dem ersten der nächsten
fortgefahren. Nicht vergessen werden darf, daß der GetNext-Befehl die neue OID zurückliefern
muß, und diese unterscheidet sich in diesem Fall nicht nur in der letzten Stelle.
else
oid_s_p->oid[l+3]++;
i=oid_s_p->oid[l+3];
Nachdem nun unter Umständen Änderungen in der OID vorgenommen worden sind, kann mit
einer case-Anweisung, die auf die dritte Stelle getriggert ist, die Art des Wertes entschieden
werden. Der erste Wert benennt die Tabelle, und der zweite ist Eins, da es sich um einen
Tabelleneintrag handelt. Um allzu lange Ausdrücke zu vermeiden, wurde dem vierten Wert der
Variablenname i zugewiesen. Dieser wählt nun von der bekannten Spalte die richtige Reihe und
somit den gesuchten Wert.
switch(oid_s_p->oid[l+2]){
63
Realisierung der PROFIBUS-Seite
case 1:
free(oid_s_p->wert);
oid_s_p->wert = calloc(1,sizeof(int));
oid_s_p->wert= liste[i-1].index;
oid_s_p->typ = INTEGER;
break;
case 2:
free(oid_s_p->wert);
oid_s_p->wert =
calloc(128,sizeof(char));
strcpy(oid_s_p->wert,liste[i-1].descr);
oid_s_p->typ =STRING;
break;
Die Werte werden jetzt wie bei normalen Variablen zugewiesen. Der einzige Unterschied besteht
darin, daß der Wert aus einem Array stammt. Auch die weiteren Elemente der MIB werden
analog zugewiesen. Deshalb wird diese Funktion nur bis zu dieser Stelle abgebildet.
64
Zusammenfassung der gemachten Änderungen
11. Zusammenfassung der gemachten Änderungen
Die gemachten Änderungen wurde jeweils im Zusammenhang mit den thematischen Hintergründen beschrieben. Es sollen auch hier nicht alle wiederholt werden, sondern nur jene, wo an
verschiedenen Stellen dasselbe Programm mehrmals geändert wurde, und so die Zusammenfassung aus Übersichtsgründen notwendig scheint.
Änderungen in daemon.h: Hier sind alle neu dazugekommenen Tasks nochmals angeführt.
/* In snmp_sok.c: */
void knizak __ARGS((int,void*,void*));
/* In profibus.cpp: */
void profi __ARGS((int,void*,void*));
Listing 11.1
Alle Änderungen in daemon.h
Dazugehörige Änderungen in config.c: Hier sind die Tasks samt Namen und Speicherbedarf in die
Daemon Liste eingetragen.
/* daemons to be run at startup time */
struct daemon Daemons[] =
{
{ "killer", 512,
killer },
{ "gcollect", 256,
gcollect },
{ "timer",
1024, timerproc },
{ "network", 1536, network },
{ "keyboard", 250,
keyboard },
{ "ich knizak",
250,
knizak },
{ "PROFIBUS", 250,
profi },
{ NULLCHAR, 0,
NULLVFP }
};
Listing 11.2
Alle Änderungen in config.c
Makefile: Hier ist eine Zusammenfassung aller Änderungen sowohl für die zusätzlich zu
compilierenden und zu linkenden Programme, als auch die Änderungen für die C++ Programme
gemacht wurden.
65
Zusammenfassung der gemachten Änderungen
.c.obj:
$(CC) -c $(INCLUDE) $(MODEL) $(CFLAGS) $<
.cpp.obj:
$(CC) -c $(INCLUDE) $(MODEL) $(CFLAGS) $<
// Diese Zeile wurde zur comilierung der C++ Programme eingefügt
.asm.obj:
$(ASM) $(AFLAGS) $<;
...............................................
CLIENTS= telnet.obj ftpcli.obj finger.obj \
smtpcli.obj hop.obj tip.obj \
dialer.obj nntpcli.obj bootp.obj \
popcli.obj nettime.obj novelcli.obj \
rlogin.obj sz.obj rz.obj rbsb.obj \
zm.obj hil_card.obj hengst_z.obj \
eh_fmu.obj dpmi.obj drv.obj feld.obj \
asn_subr.obj obl_mib.obj f_mib.obj
// In die Clients-Bibliotek wurden alle Funktionen, Daten und Typen bereitstellenden
// C-Programme aufgenommen
....................................................
NET=
ftpsubr.obj sockcmd.obj sockuser.obj \
socket.obj sockutil.obj \
iface.obj timer.obj ttydriv.obj cmdparse.obj \
mbuf.obj misc.obj pathname.obj audit.obj files.obj \
kernel.obj ksubr.obj alloc.obj getopt.obj \
wildmat.obj lzw.obj \
devparam.obj snmp_sok.obj profibus.obj
// Die beiden „Haupt-Tasks“ wurden in die Net-Bibliotek eingefügt
.....................................................
$(CC) -c $(CFLAGS) $(MODEL) *.c
$(CC) -c $(CFLAGS) $(MODEL) *.cpp
$(ASM) $(AFLAGS) *.asm
// Auch die Direktiven zur Compilierung mußten um die C++ erweitert werden
Listing 11.3
Änderungen im Makefile
66
Der Weg eines Paketes durch das Gateway
12. Der Weg eines Paketes durch das Gateway
In diesem Abschnitt wird ein GetRequest nach der Kontaktperson auf seinem Weg durch das
Gateway verfolgt.
Die Ethernet-Karte liefert über den Pakettreiber über Interrupt 0x61 Ethernet-Pakete an den IPTask von KA9Q (Abb. 12.1). Dieser Task stellt an der Protokollnummer (17) fest, daß dieses an
den UDPZiel
Type
Prüf-Summe
Ethernet-Frame 00 00 00 00 00 00 00 00 00 00 00 00 80 00
00 00 00 00
IP
00 00 00 00
Quelle
00 00 00 00
00 00 00 00
Quelle
Ziel
80 82 50 01
80 82 50 3D
0E 56 00 A1 00 B1 60 A3
UDP
Quell- ZielPort Port
SNMP
30 26
SNMP-Daten
Version
Community
02 01 00 04 06 70 75 62 6C 69 63
A1 19
02 01 29
02 01 00 02 01 00
PDU
Nummer
Fehler
30 0C
Abb. 12.1
06 08
30 0E
2B 06 01 02 01 01 01 00
05 00
hereinkommendes Ethernet-Paket
Task weiterzuleiten ist. Dieser entfernt, wie auch die vorhergegangenen, die für ihn bestimmten
Steuerinformationen und leitet es laut Port-Adresse (161) an den SNMP-Task weiter. Bis hierher
erfolgte die Weitergabe in der Form von Message-Buffern.
Der SNMP-Task wandelt über die Funktion asn_to_c diese nicht strukturierten Daten in eine
leicht zu bearbeitende Zeigerstruktur um (Abb. 12.2).
67
Der Weg eines Paketes durch das Gateway
asn_pack
Pointer
nr (int)
36
laenge (int)
42
version (int)
0
name (char[64])
“public”
art (int)
A0
error (int)
0
error_ind (int)
0
oids (*)
->oid_seq
oid_seq
flags (int)
0
oid (char[128]) 1.3.6.1.2.1.1.4.0.-1
Abb. 12.2
typ (int)
1
wert (*)
->“Knizak”
next (*)
->NULL
Pointerstruktur mit Get (sysContakt)
Über die Einträge in mib.h wird nun zur Funktion m_system gesprungen, die den gewünschten
Wert zurückliefert
Nun wandelt der SNMP-Task mittels der Funktion c_to_asn die Pointerstruktur wieder in einen
mbuf um. Dieser wird an udp_send weitergeleitet. Dort wird er mit Header-Daten und Kontrollsumme versehen und an ip_send weitergeleitet. Dort erhält es genauso wie auch dann für das
Ethernet, die entsprechend Kontrolldaten (Abb. 12.3).
68
Der Weg eines Paketes durch das Gateway
Das fertige Paket wird über den Pakettreiber und die Ethernetkarte entweder sofort an einen
anderen Zielrechner oder an den nächsten Router geschickt.
Ziel
Quelle
Type
Prüf-Summe
Ethernet-Frame 00 00 00 00 00 00 00 00 00 00 00 00 80 00
00 00 00 00
Quelle
IP
00 00 00 00
00 00 00 00
00 00 00 00
80 82 50 3D
Ziel
80 82 50 01
00 A1 0E 56 00 B1 60 A3
UDP
Quell- ZielPort Port
SNMP
30 2A
Version
Community
02 01 00 04 06 70 75 62 6C 69 63
A2 1D 02 01 29 02 01 00 02 01 00
PDU
SNMPDaten
30 11
Nummer
30 13
Fehler
06 08 2B 06 01 02 01 01 04 00 04 06 4B 6E 69 7A 61 6B
Abb. 12.3
hinausgehendes Ethernetpaket
69
Erstellung einer beispielhaften Anwendung
13. Erstellung einer beispielhaften Anwendung
Um das Gateway in Betrieb zu nehmen, muß die Datei feld.c mit den entsprechenden Daten über
die einzelnen Sensoren gefüllt werden. Dies sind im speziellen die PROFIBUS-Daten und die
verbalen Beschreibungen. In einer weiteren Ausbaustufe wird es sinnvoll sein, zur Konfiguration
eine normale Textdatei zu verwenden, die auch während des Betriebes geladen werden kann und
kein neues Compilieren mehr erfordert.
Die am ICT vorhandene PROFIBUS-Multivendoranlage wurde zum Testen verwendet.
Landis & Gyr
FMS
Allen Bradley
Endress + HauserHirschmann
Saia 2
Phoenix Contact
Hengstler
Bosch
Weidmüller
Klöckner Moeller
Siemens
Saia 4
DP
Gantner
Bosch
Abb. 13.1
Weidmüller
Festo
Siemens
Multivendoranlage am ICT
Der DP-Teil wurde absichtlich auch abgebildet, da die im Resümee angestellten Überlegungen
eine Erweiterung auf DP als sinnvoll erscheinen lassen. In der im Listing dargestellten Anwendung
ist als Tabelleneintrag 1 der Zählwert des Zählers der Firma Hengstler eingetragen, als zweites die
Entfernung des Ultraschallsensors der Firma Endress und Hauser und als letztes ein Slave der
Firma Weidmüller als fiktiver Temperatursensor.
Da die einzelnen Zeilen länger als der Bildschirm sind, wurde von der Regelung in C Gebrauch
gemacht, die erlaubt, als Abstand beliebig viele Leerzeichen zuzulassen. So wurde zum Eintrag in
diese Liste wenigstens etwas an Übersichtlichkeit gewonnen. Um einen weiteren Eintrag in diese
Tabelle einzufügen, kopiert man am besten einen schon bestehenden Eintrag und bessert die sich
ändernden Werte aus. Die als Kommentar über den Werten stehenden Bezeichnungen sind mit
70
Erstellung einer beispielhaften Anwendung
denen aus der MIB identisch. Die zusätzlichen sind in ihrer Bedeutung im Abschnitt „Der zweite
Teil der Struktur Feld_Knoten" genau beschrieben. Der letzte Eintrag, der Nulleintrag, muß
immer erhalten bleiben, um die Funktionsfähigkeit des Programms zu gewährleisten, da
Programmteile dies als Abbruchbedingung verwenden.
#include "feld.h"
struct tabellen_eintrag liste[] =
{
//
1.Zeile
//Index ,descr
,type
{1
,"hengstler"
,0
,i_value
,666
,s_value
,"0"
,time
,0
,
,
//o_type,i_value_o
0
,0
,s_value_o ,o_time
,"0"
,trap
,0
,value1 ,
,0
,0
//value2,status
0
,0
,kbl_nr
,1
,ov_nr
,41
, o_type
,4
,read_status
,0
//,a_trap
,0
,1,1},
,i_value
,23
,s_value
,"0"
,time
,0
,trap
,0
,value1 ,
,0
,0
,
, kind
//
2. Zeile
//Index ,descr
{2
,"endress+h"
,type
,0
//o_type,i_value_o
0
,0
,s_value_o ,o_time
,"0"
//value2,status
0
,0
,kbl_nr
,2
//,a_trap
,0
,1,2},
,ov_nr, o_type
,508
,15
,
,
,
,read_status
,0
, kind
//
letzte. Zeile
//Index ,descr
{-1
,"0"
,type
,0
,i_value,s_value
,0
,"0"
,trap
,time
,
,0
,
,value1 ,
,0
,0
,0
,
//o_type,i_value_o
0
,0
,s_value_o ,o_time
,"0"
//value2,status
,
0
,0
,kbl_nr
,ov_nr, o_type
,read_status
,a_trap
,0
,0
,0
,0
,0
//kind
0,0}};
Listing 13.1
feld.c
Nachdem das Programm mit der so geänderten Datei feld.c assembliert und gelinkt worden ist,
muß noch der Pakettreiber mit „3c509 0x61“ gestartet werden und dann das Programm mit „net“
in Betrieb genommen werden.
71
,
Erstellung einer beispielhaften Anwendung
Zur Überprüfung der Funktion des Gateways erwies es sich als sinnvoll, zuerst mit einem htmlProgramm mit dem Namen Mib-Master die System-MIB anzusehen (Abb. 13.2). Bei dieser
Konfiguration sollte das am Bildschirm sichtbare Bild so aussehen:
Abb. 13.2
MIB-Master betrachtet mit Netscape
Mit geeigneten Werkzeugen kann man eigene ASN.1 files in ein Format übersetzen lassen, das die
eigene MIB genauso übersichtlich anzeigt wie die System-MIB. Hiermit ist offensichtlich, daß
diese Art der Verbindung zwischen einem LAN und einem Feldbus vom Endanwender keine
Kenntnisse über den Feldbus verlangt. Einzig die Konfiguration muß von einem Fachmann
erledigt werden.
Hiermit ist die Funktion der SNMP-Verbindung nachgewiesen. Nun geht man daran, die FeldbusMIB zu erforschen.
Als einfaches Beispiel sollte man im Unterbau fBDescr beginnen:
hier findet man mit
GetRequest(1.3.6.1.4.1.1093.51.6.3.1.0)
die Anzahl der eingegangenen Anfragen.
Wesentlich interessanter gestaltet sich die Erforschung der Zweiges fBAccess. Mit
GetNextRequest(1.3.6.1.4.1.1093.51.6.3.1.0)
fordert man das erste Element der Tabelle an, und erhält in der Antwort auch gleich seine Adresse
mitgeliefert:
72
Erstellung einer beispielhaften Anwendung
Wert:
1
Adresse:
1.3.6.1.4.1.1093.51.6.2.1.1.1.1
Zur Illustration noch einige weitere Beispiele:
GetNextRequest(1.3.6.1.4.1.1093.51.6.2.1.1.2.2)
Wert:
hengstler
Adresse:
1.3.6.1.4.1.1093.51.6.2.1.1.3.1
GetNextRequest(1.3.6.1.4.1.1093.51.6.2.1.1.3.1)
Wert:
endress+h
Adresse:
1.3.6.1.4.1.1093.51.6.2.1.1.3.2
GetNextRequest(3.1.0)
Wert:
1.3.6.1.4.1.1093.51.6.1.1
Adresse:
1.3.6.1.4.1.1093.51.6.2.1.1.4.1
73
Resümee und Aussichten
14. Resümee und Aussichten
Die hier gewählte Methode der Kopplung erweist sich als einfach und billig. Ein PC, der unter
Umständen nur einen 80286 Prozessor besitzen muß, und eine PC Einsteckkarte sind die einzigen
Hardware-Voraussetzungen. Das System ist offen für weitere Entwicklungen wie etwa andere
Feldbussysteme. Die Schwachpunkte liegen in der Konfiguration. Diese ist noch zu umständlich.
Eine Voreinstellung in einer Textdatei, die angibt, nach welchen Geräten am Feldbus gesucht
werden soll, und die Ergebnisse selbsttätig in die Feld_bus-Tabelle einträgt, wäre ein bedeutender
Fortschritt. Zur Übertragung von kritischen Daten ist dieses System von vornherein nicht
geeignet, da das IP keine wie auch immer geartete Zustellungskontrolle bietet. Die Bedienung der
SNMP-Seite und somit auch des gesamten Feldbusses bietet - abgesehen von der Konfiguration auch ungeschultem Personal keine Schwierigkeiten. Dies ist ein bedeutender Vorteil, der auch
eingangs angestrebt wurde.
Das Feldbussystem PROFIBUS erlebte während dieser Arbeit eine nicht unerhebliche Änderung.
PROFIBUS DP bekam einige Erweiterungen. Jetzt ist nicht mehr nur zyklischer, sondern auch
azyklischer Verkehr zwischen Master und Slaves zugelassen. Ebenfalls ist der Datenverkehr
zwischen einem sogenannten „Master 2“ und Slavestationen mögich. Diese sollen eine Visualisierung oder dergleichen ermöglichen. Diese Änderuhngen machen nun auch PROFIBUS DP als
Feldbussystem der gegenständlichen Arbeit interessant. Eine Abänderung dieser Arbeit auf
PROFIBUS DP ist sehr leicht möglich. Statt des PROFIBUS-Tasks müßte ein Task geschrieben
werden, der laufend die Daten zwischen dem Speicher-Bereich, wo sie von PROFIBUS DP
hingeschrieben werden, in die Struktur Feld überträgt. Diese Überlegungen in die Realität
umzusetzen wäre sinnvoll, da PROFIBUS DP 80-90% der in Verwendung stehenden
PROFIBUS-Anlagen ausmacht.
74
Resümee und Aussichten
A Abkürzungen
ASN.1
Abstract Syntax Notation One; eine formale Sprache zur Beschreibung von
Spezifikationen
CMIP
Common Management Informatio Protokol
CMOT
CMIP over TCP
DP
Dezentrale Peripherie;
PROFIBUS
EGP
Externa Gateway Protokoll; eine von Sun Microsystems entwickelte transfer
Syntax
FAN
Field Area Network; ein für den Betrieb in der Feldebene ausgelegtes Netzwerk
FDDI
Fiber Distributed Data Interface
FDL
Fieldbus Data Link; Bezeichnung der Schicht 2 lt. OSI Modell bei P.
FMS
Fieldbus Message Spezifikation; Applikationsfunktionen der gleichnamigen P.
Variante
FTP
File Transfer Protokoll; Protokoll zum Übertragen von Files zwischen zwei
Computern, setzt auf TCP auf
ICMP
Internet Controll Message Protokoll; einfaches Protokoll zur Übermittlung von
Geräteinformationen
IP
Internet Protokoll; weit verbreitetes Schicht 3 Protokoll
ISO
Internationale Standartisierungs Organisation
KBL
KommunikationsBeziehungsListe
KISS
Keep It Simple, Stupid protokol
KR
Kommunikations Referenz
LAN
Lokal Area Network
MIB
Management Information Base
OID
Objekt IDentifier
OSI
Open Systems Interconection
OV
Objektverzeichnis
spezielle
75
Ausführungsform
des
Feldbussystems
Resümee und Aussichten
PA
Prozeß Automation; P. Variante für den eigensicheren Bereich
PDU
Protokol Data Unit
PNO
P. Nutzerorganisation
PROFIBUS
PROzeß FIeld BUS; Bussystem für den Feldbereich, genormt in EN50170
RFC
Request for Comments; eine Dokumentenserie, die die Internetprotokolle
beschreibt
SAP
Service Access Point; Dienstzugangspunkt
SNMP
Simple Network Management Protokoll
TCP
Transport Controll Protokoll
UDP
User Datagramm Protokoll
76
Resümee und Aussichten
A Literatur
[SIE95]
Siegl, M.; Schmalek, R., "FAN-LAN-Kopplung", Feldbustechnologie ‘95, ÖVESchriftenreihe Band 9, S. 431-438, Wien 1995.
[EN50170]
Europäische Norm 50170, Teil2, PROFIBUS, Dezember 1996.
[RFC791]
Request for Comments Dokument Nr. 791, Internet Protokoll.
[HUI96]
C. Huitema, Routing im Internet,Prentice-Hall, New Jersey, 1996.
[MAR94]
J. Martin, "TCP/IP networking. Architekture, administration, and programming",
Prentice-Hall, New Jersey, 1994.
[RFC793]
Request for Comments Dokument Nr. 793, Transmission Control Protokoll.
[RFC768]
Request for Comments Dokument Nr. 768, User Datagramm Protokoll.
[RFC1157]
Request for Comments Dokument Nr. 1157, Simple Network Management
Protokoll.
[RFC1156]
Request for Comments Dokument Nr. 1156, Management Information Base.
[RFC1213]
Request for Comments Dokument Nr. 1213, Management Information Base II.
[ROS91]
M. T. Rose, "The Simple Book, An Introduktion to Management of TCP/IP based
internets", Prentice-Hall, New Jersey, 1991.
[GOR92]
W. Gora, "ASN.1, Abstract Syntax Notation One", Datacom-Verlag, 1992.
77
Resümee und Aussichten
[BEN92]
K. Bender, "PROFIBUS Der Feldbus für die Automation", Carl Hanser Verlag
München Wien, 1992.
[POP97]
M. Popp, "The rapid way to PROFIBUS-DP", PROFIBUS Nutzerorganisation
Karlsruhe, 1997.
[COM94]
D. E. Comer und D. L. Stevens, "Internetworking with TCP/IP", Band3, ClientServer Programming And Applications,Prentice-Hall, New Jersey, 1994.
[KNI97]
Knizak M., Manninger M., Sauter Th., "Einbindung von Feldbussen in das Internet
via SNMP", e&i 5/97, S.258.
[WAD92]
I. Wade, "NOSintro, TCP/IP over Packet Radio", Dowermain, 1992.
78