Fernwartung für heterogene IT-Infrastrukturen

Inhaltsverzeichnis

ABKÜRZUNGSVERZEICHNIS

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

KAPITELÜBERSICHT

VORWORT

1 EINLEITUNG

2 STAND DER TECHNIK
2.1 Entwicklung der Ferndiagnose und Fernwartung
2.2 Remote-Service Angebot von Sun Microsystems
2.3 Remote-Service der StorageTek Corporation

3 PRÄZISIERUNG DER AUFGABENSTELLUNG
3.1 Funktionelle Anforderungen
3.2 Wirtschaftliche Anforderungen
3.3 Weitere Anforderungen

4 SYSTEMKONZEPT
4.1 Betrachtung möglicher Hardware Konzepte
4.2 Gegenüberstellung von Embedded Lösungen
4.2.1 TINI Tiny Network Interface
4.2.2 RCM 2000 / RCM
4.2.3 Auswahl der Hardware
4.3 Betrachtung möglicher Software Konzepte
4.4 Konzeptentscheidung
4.5 Funktion der Fernwartungseinheit
4.6 Der Aufbau der Fernwartungseinheit

5 DIE ETHERNUT HARDWARE UND SOFTWARE
5.1 Das System-Board
5.1.1 Der ATmega128 Microcontroller
5.1.2 Der LAN91C111 LAN Controller
5.1.3 SRAM und Flash Speicher
5.1.4 Der CPLD Adress-Decoder
5.2 Das Betriebssystem Nut/OS
5.2.1 Threads
5.2.2 Events
5.2.3 Speicherverwaltung
5.2.4 Ein/Ausgabe
5.2.5 Device Driver
5.3 Der Netzwerk-Stack Nut/Net
5.3.1 Data Link Layer
5.3.2 Network Layer
5.3.3 Transport Layer
5.3.4 Applikations-Layer

6 DIE ERWEITERUNGSPLATINE FÜR SERIELLE ANSCHLÜSSE
6.1 Die Hardware der Erweiterungsplatine
6.1.1 Design und Bauteilauswahl
6.1.2 Funktion und Aufbau
6.1.3 Der MAX3110E Serial Interface Bauteil
6.1.4 Bauteilliste der Erweiterungsplatine
6.2 Die Software für die Erweiterungsplatine
6.2.1 Ein-/Ausgabe über das Serial Peripheral Interface
6.2.2 Interrupt-Behandlung
6.2.3 Der Device-Driver

7 DIE APPLIKATIONSSOFTWARE DER FERNWARTUNGSEINHEIT
7.1 Das Konfigurationsprogramm
7.1.1 Globale Einstellungen
7.1.2 Gerätespezifische Einstellungen
7.1.3 Speicherung und Konvertierung der Einstellungen
7.1.4 Konfigurationsdaten in der Fernwartungseinheit
7.2 Das zentrale Steuerprogramm
7.3 Die aktiven Überwachungsprogramme
7.3.1 Der ICMP Echo Sender
7.3.2 Der Request/Response Sender
7.3.3 Der SNMP Request Sender
7.4 Die reaktiven Überwachungsprogramme
7.4.1 Der E-Mail Empfänger
7.4.2 Der SNMP-Trap Empfänger
7.5 Die Nachrichten-Sender
7.5.1 Der SMS-Sender
7.5.2 Der E-Mail-Sender
7.6 Die Benutzerschnittstelle
7.7 Der TFTP Server

8 SYSTEMINTEGRATION

9 TEST UND INBETRIEBNAHME

10 ZUSAMMENFASSUNG
10.1 Einschätzung der Ergebnisse
10.2 Mögliche Weiterentwicklungen an der Hardware
10.2.1 HW-Interrupt-Register auf der Erweiterungsplatine
10.2.2 Real Time Clock
10.3 Mögliche Weiterentwicklungen an der Software
10.3.1 Dynamische Konfigurationsänderungen
10.3.2 HTTP Server statt Telnet-Benutzerschnittstelle
10.3.3 Remote Software Update für die Fernwartungseinheit
10.3.4 Anschluss von speziellen Einzelgeräten

ANHANG

LITERATURVERZEICHNIS

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1 Remote Support Arbeitsplatz, ca. 1983

Abbildung 2 Heterogene RZ-Infrastruktur

Abbildung 3 Fernwartung bei heterogener IT-Infrastruktur

Abbildung 4 Architektur von Sun Net Connect

Abbildung 5 SMC Gliederung

Abbildung 6 V20z System Board mit System Controller

Abbildung 7 StorageTek L-Series Diagnosekommandos

Abbildung 8 StorageTek L-Series Library Fault Symptom Code Listing

Abbildung 9 Fernwartung durch Service-Partner bei heterogener IT-Infrastruktur

Abbildung 10 Heterogene RZ-Infrastruktur mit Fernwartungseinheit

Abbildung 11 Microcontroller Hersteller und Produkte

Abbildung 12 TINI Board (beidseitig)

Abbildung 13 TINI Prototyp Board

Abbildung 14 TINI Run-Time Softwareumgebung

Abbildung 15 RCM3200 Core Modul

Abbildung 16 RCM3200 Prototyp Board

Abbildung 17 Ethernut System Board Blockschaltbild

Abbildung 18 Ethernut System Board

Abbildung 19 Blockschaltbild LAN91C111

Abbildung 20 Hierarchischer Aufbau der Ausgabefunktionen

Abbildung 21 Hierarchischer Aufbau der Eingabefunktionen

Abbildung 22 Nut/Net Software Schichten

Abbildung 23 Blockschaltbild Erweiterungsplatine

Abbildung 24 Blockschaltbild MAX3110E

Abbildung 25 MAX3110E Beschaltung

Abbildung 26 Adressdecodierung und MISO Buffer

Abbildung 27 Prototyp der seriellen Erweiterungsplatine

Abbildung 28 SPI Datenübertragung

Abbildung 29 HW/SW-Struktur Fernwartungseinheit

Abbildung 30 Programm- und Datenfluss

Abbildung 31 Nut/OS Message Queue Funktionen

Abbildung 32 Globale Einstellungen

Abbildung 33 Übersicht Geräteeinstellungen

Abbildung 34 Detailinformation Geräteeinstellungen

Abbildung 35 Zugriff auf den Konfigurationsfile

Abbildung 36 Übertragung der Konfiguration

Abbildung 37 EEPROM Speicherzuordnung

Abbildung 38 Pseudocode zentrales Steuerprogramm

Abbildung 39 Pseudocode ICMP Echo Sender

Abbildung 40 Nut/Net ICMP API

Abbildung 41 Pseudocode Request/Response Sender

Abbildung 42 Pseudocode SNMP Request Sender

Abbildung 43 Kommunikation zw. NMS und Agent

Abbildung 44 Pseudocode E-Mail Empfänger

Abbildung 45 Empfangen einer E-Mail

Abbildung 46 Pseudocode SNMP Trap Empfänger

Abbildung 47 SNMP Trap Paket

Abbildung 48 Pseudocode SMS Sender

Abbildung 49 F-BUS Protokoll

Abbildung 50 F-BUS Nachrichtenaufbau

Abbildung 51 Pseudocode E-Mail Sender

Abbildung 52 Nachrichtenfluss beim Senden einer E-Mail

Abbildung 53 Pseudocode Benutzerschnittstelle

Abbildung 54 Telnet Session zur Benutzerschnittstelle

Abbildung 55 Threadinformationen

Abbildung 56 Anzeige des device Kommandos

Abbildung 57 Anzeige des PHONE und STATUS Kommandos

Abbildung 58 Pseudocode TFTP Server

Abbildung 59 TFTP Übertragung

Abbildung 60 Geräteanordnung

Abbildung 61 E-Mail-Nachrichtenübersicht

Abbildung 62 SMS-Nachrichteneingang

Abbildung 63 Prototyp der Fernwartungseinheit

Abbildung 64 Layer 1 der Erweiterungsplatine

Abbildung 65 Layer 2 der Erweiterungsplatine

Abbildung 66 Bauteilanordnung der Erweiterungsplatine

Abbildung 67 Schaltplan der Erweiterungsplatine

Tabellenverzeichnis

Tabelle 2-1 Verfügbarkeit und Down-Time 7

Tabelle 3-1 Überwachungsmethoden 18

Tabelle 3-2 Anforderungen an die Fernwartungseinheit 19

Tabelle 3-3 Kommunikationsmethoden 19

Tabelle 3-4 Servicevertragstypen 20

Tabelle 4-1 DS80C390 Eigenschaften 26

Tabelle 4-2 TINI Board Komponenten 26

Tabelle 4-3 R2000 / R3000 Gegenüberstellung 29

Tabelle 4-4 HW und SW Auswahlkriterien 31

Tabelle 4-5 Software-Konzepte 32

Tabelle 4-6 Komponenten der Fernwartungseinheit 34

Tabelle 5-1 Ethernut System Board Eigenschaften 35

Tabelle 5-2 Nut/OS Funktionen 38

Tabelle 5-3 Device-Driver Funktionen 43

Tabelle 5-4 Nut/Net Funktionen 44

Tabelle 6-1 Adressdecodierung der Erweiterungsplatine 50

Tabelle 6-2 MAX3110E Register 52

Tabelle 6-3 Bauteilliste Erweiterungsplatine 53

Tabelle 6-4 Signalrichtungen am SPI 54

Tabelle 7-1 Globale Einstellung 60

Tabelle 7-2 Gerätespezifische Einstellungen 62

Tabelle 7-3 Anschlusstyp vs. Kommunikation 63

Tabelle 7-4 Konfigurationsdatei 65

Tabelle 7-5 Konfigurationsdaten - Zugriffsfunktionen 68

Tabelle 7-6 Implementierte SMTP Kommandos 76

Tabelle 9-1 Komponenten der Fernwartungseinheit 100

Kapitelübersicht

Kapitel 1 Einleitung

Die Einleitung beleuchtet in kurzer Form den Hintergrund des Themas und den Konnex zu meinem Arbeitgeber Bacher Systems.

Kapitel 2 Stand der Technik

Hier wird ein Abriss über die technologische Entwicklung der Fernwartung gegeben. Weiters wird gezeigt, welche Produkte und Dienstleistungen namhafte IT-Hersteller heute vermarkten.

Kapitel 3 Präzisierung der Aufgabenstellung

Dieses Kapitel beschreibt die Anforderungen an eine Fernwartungseinheit, sowohl technisch-funktionell, als auch wirtschaftlich.

Kapitel 4 Systemkonzept

In diesem Kapitel wird dargestellt, welche Konzepte zur Implementierung der Fernwartungseinheit umgesetzt werden können. Es werden verschiedene Konzepte und Gerätevarianten beschrieben.

Kapitel 5 Die Ethernut Hardware und Software

Es werden die drei Komponenten gezeigt, welche die Basis für die Fernwartungseinheit bilden: Das System-Board, das Betriebssystem Nut/OS und der TCP/IP Stack Nut/Net.

Kapitel 6 Die Erweiterungsplatine für serielle Anschlüsse

Diese Hardware und die dazu notwendige Software wurden für die Fernwartungseinheit entwickelt. Hier werden das Design und die Funktion beschrieben und die Einbettung der Software in Nut/OS erklärt.

Kapitel 7 Die Applikationssoftware der Fernwartungseinheit

Aufsetzend auf die in den Kapiteln 5 und 6 beschriebene Hardware und Software wird die Implementierung der Funktionen der Fernwartungseinheit dargestellt. Dies umfasst auch das für PCs entwickelte Konfigurationsprogramm.

Kapitelübersicht

Kapitel 8 Systemintegration

Hier wird zusammengefasst, in welche Phasen sich die Entwicklungsarbeit der Fernwartungseinheit aufteilte. Ferner wird die Vorgangsweise während des

Integrationstests beschrieben.

Kapitel 9 Test / Inbetriebnahme

Die Tests der Hardware und Software sowie der verwendeten Hilfsprogramme werden hier erläutert.

Kapitel 10 Einschätzung der Ergebnisse / Ausblick

Es werden die ersten Testergebnisse dargelegt und Überlegungen zu möglichen Weiterentwicklungen der Hardware und Software der Fernwartungseinheit aufgezeigt. Die Software bietet eine Menge an Möglichkeiten, Funktionalität und Handhabung der Fernwartungseinheit zu erweitern.

Vorwort

Die hier vorliegende Diplomarbeit wurde in der Zeit von September 2004 bis Mai 2005 angefertigt.

Schon im Jahr 2002 fiel mir als Mitarbeiter von StorageTek Österreich die Diskrepanz zwischen dem technisch Möglichen und den vorhanden Funktionen von IT-Produkten bezüglich ihrer Ferndiagnose und Fernwartbarkeit auf. Dies wurde durch die Erfahrungen mit einer breiteren Produktpalette bei Bacher Systems noch untermauert: Möglichkeiten, Informationen über ihren Betriebszustand an die Außenwelt zu kommunizieren haben fast alle Server, Disk-Subsysteme, Bandroboter, Firewalls und andere Geräte, welche in einem modernen Rechenzentrum zu finden sind. In solchen heterogenen IT-Umgebungen muss aber oft auf große, komplexe, und mit beträchtlichen Investitionen verbundene Softwarelösungen zurückgegriffen werden, um alle diese Geräte, oder zumindest die meisten davon, zu überwachen.

Ein Konzept aufzuzeigen, wie diese Überwachung und die damit einhergehenden Kommunikationsnotwendigkeiten mit wenig Aufwand auf Basis von Embedded Systems implementiert werden können, wird mit dieser Arbeit dokumentiert.

Ich möchte mich an dieser Stelle bei all jenen bedanken, die diese Arbeit möglich gemacht und sie unterstützt haben. Allen voran meine Gattin Christine, die durch ihr Verständnis mein Studium und diese Arbeit ermöglichte. Weiters meine Kollegen bei Bacher Systems, die mit ihrer praktischen technischen Erfahrung wertvolle Impulse lieferten und insbesondere bei Herrn Prof. Dr.-Ing. Olaf Hagenbruch und Hrn. Dipl. Ing. Martin Schneider für die Durchsicht des Manuskripts und die wertvollen Anregungen während dieser Arbeit.

1 Einleitung

Die stetig anwachsende Abhängigkeit geschäftskritischer Prozesse von der Informationstechnologie bringt immer höher werdende Anforderungen an die Verfügbarkeit der Rechner, Applikationen und Netze mit sich. Diese Verfügbarkeit wird einerseits durch stabilere Hardware, andererseits durch den Einsatz von redundanten Komponenten wie Server-Cluster für hochkritische Anwendungen, erreicht. Somit kommt dem raschen Erkennen, Melden und Behandeln von Fehlersituation eine große Bedeutung zu, um Ausfallzeiten zu minimieren.

Viele Geräte, die in einem modernen Rechenzentrum betrieben werden, verfügen über Diagnosemöglichkeiten. Diese reichen von der Möglichkeit, einen Laptop direkt mit einem speziell dazu vorgesehenen Anschluss des Gerätes zu verbinden bis hin zur automatischen Übertragung von Fehlerinformationen an den Gerätehersteller über das Internet.

Diese Vielzahl birgt natürlich auch Unausgewogenheiten mit sich: Einerseits gibt es Geräte, die Fehlerinformationen intern aufzeichnen und auf Abfrage bereitstellen. In dieser Variante hängt es von den Kommunikationsfähigkeiten des Gerätes ab, ob diese Abfragen lokal oder remote durchgeführt werden können. Andere Geräte melden Betriebszustandsänderungen und Statusinformationen an Überwachungs-Zentren und erleichtern somit auch vorbeugende Servicemaßnahmen.

Bacher Systems EDV GmbH ist seit 1992 als System-Integrator am österreichischen Markt tätig und vertreibt, installiert, integriert und serviciert IT-Infrastrukturlösungen sowie eine breite Palette von Produkten und Dienstleistungen im Bereich der IT- Sicherheit. Die effiziente Erbringung von Serviceleistungen ist dabei ein wesentlicher wirtschaftlicher Faktor, welcher in seiner Kostenstruktur immer weiter zu optimieren ist.

Hier soll untersucht werden, wie eine Integration unterschiedlicher Fernwartungs- und Ferndiagnoselösungen verschiedener Hersteller vorgenommen werden kann, um dem steigenden Anspruch der Kunden nach wenigen, im Optimalfall einen, Servicepartner gerecht zu werden.

Gleichzeitig gilt es, die Arbeit der Servicetechniker zu unterstützen, indem Fehlersituationen einer umgehenden Bearbeitung zugeführt werden. Ja rascher ein eingetretener Fehler gemeldet wird, desto schneller kann mit der Behebung begonnen werden! Und letztlich soll dem steigenden Kostendruck durch einen noch effizienteren Einsatz der Ressource Servicetechniker Rechnung getragen werden.

2 Stand der Technik

In diesem Kapitel wird ein kurzer Einblick in die Entwicklung der Ferndiagnose und Fernwartung und deren Verknüpfungen mit den technologischen Verbesserungen der letzten drei Jahrzehnte gegeben. Anhand zweier Beispiele, der Firma Sun Microsystems und der Firma StorageTek Corporation, werden die unterschiedlichen Ausprägungen der heutigen Implementierungen gezeigt

2.1 Entwicklung der Ferndiagnose und Fernwartung

Betrachtet man die Computersysteme der letzten 30 Jahre so wie die wesentlichen Veränderungen und Weiterentwicklungen der zugrunde liegenden Technologien, so kann folgendes leicht ersehen werden:

Starker Verfall der Hardwarepreise durch Massenfertigung

Explosion der Komplexität der Hardware und Software

Immer weitere Vergrößerung von IC - Packungsdichten

Trend von der zentralen EDV zu vernetzten dezentralen Einheiten

Viele weitere Veränderungen sind damit verknüpft oder basieren auf diesen Entwicklungen.

Der Verfall der Hardwarepreise brachte mit sich, dass die grundlegende Preisstrategie der 60er Jahre überdacht werden musste. Hatte zuerst die Hardware einen Preis, der Software sowie notwendige Dienstleistungen inkludierte, so wurde in einem ersten Schritt die Software extra bepreist; natürlich auch um die Hardware billiger wirken zu lassen. Trotzdem war in den 70er Jahren des 20. Jahrhunderts nach wie vor die Hardware das Teuerste am gesamten Computersystem. Dementsprechend war auch die Hardwarewartung auf eine optimale Wiederverwendbarkeit von Austausch- Baugruppen ausgerichtet, deren Reparatur und Funktionstests in den Zentralen der Service-Organisationen von Computerherstellern stattfanden. Dabei war natürlich sicherzustellen, dass die richtige, also defekte, Baugruppe ausgetauscht wurde. Die Hardware-Techniker rückten Problemen mit Oszilloskop und Logikplänen zu Leibe, was einerseits einen oft nicht unbeträchtlichen Zeitaufwand bei der Fehlersuche zur Folge hatte und andererseits natürlich nur am Aufstellungsort des Computers, also beim Kunden durchgeführt werden konnte.

Mit zunehmender Komplexität der Geräte erreichte diese Form der Fehlerdiagnose ihr Limit, und Oszilloskop/Logikdiagramm wurde durch Diagnosesoftware ergänzt, und später vollkommen ersetzt. Die Diagnosesoftware war zuerst eine für sich allein stehende Sammlung von Programmen, die einzelne Systemkomponenten (CPU, Memory, I/O Kanal, etc.) testete, ohne dabei unter der Steuerung eines Betriebssystems zu stehen. Daher wurden diese Tests auch standalone oder offline genannt, da der Systembetrieb gänzlich unterbrochen war.

Die 80er Jahre brachten eine Ausweitung der Datenkommunikation über Telefonleitungen durch Konstruktion und Vermarktung der ersten erschwinglichen 300/1200 bit/s Modems und Akustikkoppler.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Remote Support Arbeitsplatz, ca. 1983 Quelle: Computer Desktop Encyclopedia

Die Übertragungsgeschwindigkeit stieg dann unter Zuhilfenahme von Daten- kompression und neuen Modulationstechniken rasant an und erreichte innerhalb kurzer Zeit 2400/9600/19200 und später 38400 und 56000 bit/s. Diesen Trend machten sich die Designer der Diagnosesoftware zu Nutze und ermöglichten den Technikern, diese Testprogramme über Modem-Telefonleitungen anzuwenden. Um nicht mehr das gesamte Computersystem dabei außer Betrieb nehmen zu müssen, wurden die Diagnoseprogramme so angepasst, dass sie zumindest teilweise während des normalen, wenn auch etwas eingeschränkten Systembetriebs ablaufen konnten. Die Fernwartung war geboren.

Fernwartung

remote support maintenance

Technische Lösung, um die Wartung eines Computers aus räumlicher Entfernung (typischerweise für Kundendienst) durchzuführen. Die Verbindung erfolgt durch Datenübertragung, die unter besonderer Berücksichtigung des Datenschutzes vom Anwender vorübergehend für bestimmte Wartungsebenen (Hardware, Software, Datenbestände) freigegeben wird. Moderne Computer haben die Möglichkeit, auftretende Störungen intern aufzuzeichnen und bei Fernwartung einem zentral verfügbaren Diagnoseprogramm mitzuteilen und die Störungen analysieren zu lassen.

(vgl.23)

Aus dem vorstehenden Zitat lässt sich eine wesentliche Randbedingung dieser Entwicklung erkennen: Die Fehlerdiagnose und die sich daraus ergebende weitere Vorgangsweise war auf die Produkte des jeweiligen Hardwareherstellers bezogen. Die einzigen Ausnahmen davon waren die so genannten PCMs ( Plug-Compatible Machines ), also ganze Systeme oder Teile wie Disksubsysteme, die jedoch funktionell bis hin zum Anschlussstecker identisch zu ihrem Original waren.

Die späten 80er und beginnenden 90er Jahre brachten mit dem Schlagwort open einen zusätzlichen Trend. Die kommerzielle Ausbreitung des Betriebssystems UNIX, die Entkopplung der Hardware und Betriebssystem-Software, die früher immer vom gleichen Hersteller geliefert wurde, und die intensiver werdende Implementierung und Verwendung von standardisierten Schnittstellen wie SCSI, X.25, etc. ermöglichte das Zusammenwirken von Hardware unterschiedlicher Hersteller. Weiters hatten sich durch die hohen Stückzahlen der hergestellten Hardware die Kostenfaktoren gänzlich verschoben: Hardware war für den Kunden billig geworden, Software teuer und die Mitarbeiterkosten stiegen bei den IT-Lieferanten extrem an. Das Hardwareservice war zu einem signifikanten Kostenfaktor geworden: sowohl kunden- als auch herstellerseitig galt es, Kosten einzusparen.

Einer dieser Wege ist seither, auf Basis offener Standards Systeme oder Systemkomponenten verschiedener Hersteller zum Einsatz zu bringen. Offene Standards wie TCP/IP LANs, Fibre Channel SANs oder SCSI Schnittstellen erlauben es, Server, Disk-Subsysteme oder Bandroboter von denjenigen Lieferanten zu beziehen, welche eine Markt führende Position in technischer Funktionalität oder Preis bieten. Voraussetzung dafür ist jedoch, dass alle Geräte diese Standards umfassend und genau implementieren, sodass die Heterogenität in der Systemlandschaft keine

funktionellen Nachteile mit sich bringt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Heterogene RZ-Infrastruktur

Parallel dazu setzte die kommerzielle Nutzung des Internets ein und brachte eine Explosion an komplexen Applikationen mit sich, die das neue Medium nutzten. Die durch das Internet ermöglichte Globalisierung einer IT-basierenden Geschäftsidee (Software-Download, Bücherverkauf, etc.) brachte steigende Anforderungen an die Verfügbarkeit der IT-Infrastruktur mit sich.

Folgende Stillstandszeiten ergeben sich jährlich bei einem 24 Stunden / 7 Tage pro Woche Betrieb in Abhängigkeit von gewünschten Verfügbarkeitswerten:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2-1 Verfügbarkeit und Down-Time

Es lässt sich leicht erkennen, dass Verfügbarkeitswerte kleiner als 99,9% für ein global über das Internet zur Verfügung gestelltes Geschäftsmodell nicht akzeptierbar sind. Allerdings muss hier noch angemerkt werden, dass neben der Verfügbarkeit der IT- Infrastruktur auch die Verfügbarkeit der Applikationsprogramme, Datenbanken, etc. betrachtet werden muss. Regelmäßig durchgeführte Studien erheben die Umsatzeinbußen durch Down-Time , welche je nach Geschäftszweig in den USA zwischen Tausenden und Hunderttausenden Dollar liegen (vgl .17und 21).

Für das Service von IT-Infrastrukturen bedeutet dies, dass Fehler, Defekte oder sonstige Problemsituationen möglichst schnell ihrer weiteren Behandlung zugeführt werden müssen. In heute üblichen heterogenen IT-Infrastrukturen, in denen Geräte unterschiedlicher Hersteller zusammenwirken, müssen die Störungsinformationen derjenigen Firma oder Organisation zur Verfügung gestellt werden, die das Service für

das jeweilige Gerät erbringt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Fernwartung bei heterogener IT-Infrastruktur

Damit wird sichtbar, dass in diesem Fall nur der Kunde als einziger über die Gesamtinformation aller Gerätezustände verfügt. Es obliegt somit auch ihm, die Auswirkungen eines Fehlers auf den Gesamtbetrieb richtig zu analysieren und daraus die notwendigen Maßnahmen abzuleiten.

Im Folgenden werden stellvertretend die Service-Angebote von zwei wesentlichen IT- Lieferanten betrachtet: Sun Microsystems als Beispiel eines Systemlieferanten und StorageTek Corporation als Beispiel eines spezialisierten Speicherlieferanten (vgl.4, Seite 5ff.).

2.2 Remote-Service Angebot von Sun Microsystems

In den mehr als 20 Jahren seit der Gründung¹ hat sich Sun Microsystems vom Nischenanbieter einfach vernetzbarer UNIX Workstations zu einem umfassenden Systemlieferanten entwickelt.

Fast alle Produkte bieten dabei eine Möglichkeit der Fehlerdiagnose und unterstützen Ferndiagnose und Fernwartung. Die selbst produzierten Serverprodukte unterscheiden sich hier jedoch von den zugekauften Platten- und Bandspeicher-Subsystemen.

Als Lieferant einer so breiten Palette von Hardware, Software und Dienstleistungen bietet Sun eine Vielzahl von Fehlerdiagnose- und Service-unterstützenden Produkten. Da als zentrale Komponente einer Sun-basierenden IT-Infrastruktur immer einer oder mehrere Server gesehen werden, zentrieren sich Fernwartungssoftware und Monitoring-Hilfsmittel um diese Serverprodukte. Das Betriebssystem Solaris hat mit seinen Administrations-Tools auch die Aufgabe, den Status der Peripheriegeräte zu überwachen und gegebenenfalls Fehlerinformationen auf der Systemkonsole anzuzeigen oder über geeignete APIs den System-Management Applikationen von Drittanbietern (CA-Unicenter, HP Openview, Tivoli, BMC Patrol u.s.w.) zur Verfügung zu stellen. In dem breiten Spektrum von externen Plattenspeichern, Bandstationen und unterschiedlichen Netzwerkkomponenten werden von Sun selbst produzierte Produkte und solche, welche von OEMs (Original Equipment Manufacturer = Originalhersteller) für Sun produziert werden, angeboten. Aber auch der Anschluss von Fremdgeräten anderer Lieferanten ist üblich. All dies bringt Unterschiede in der Art und Tiefe der Integration der Geräte in die Überwachungsfunktionen des Betriebssystems mit sich.

Die beiden wesentlichen Softwareprodukte, welche heute im Einsatz stehen, sind Sun Net Connect (vgl. [26 a]) und Sun Management Center (vgl. [26 b]). Während Sun Net Connect mit jeder Kopie des Betriebssystems Solaris kostenfrei ausgeliefert wird und eine Basisfunktionalität zur Steuerung und Überwachung des Betriebs enthält, ist Sun Management Center ein weit umfassenderes Produkt, welches jedoch seine vollen Fähigkeiten erst bei der Kombination mit kostenpflichtigen Zusatzmodulen entfaltet. Doch nicht nur Funktionsumfang und Preisgestaltung unterscheiden diese beiden Produkte.

Sun Net Connect Services ermöglichen die Kommunikation von Kundenservern mit einem Sun Service Center. Dabei werden Informationen über unterschiedlichste Ereignisse und Zustände der Systeme erfasst, ausgewertet, weitergeleitet und angezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 Architektur von Sun Net Connect Quelle: Sun Microsystems

Voraussetzung dafür ist die Verbindung der überwachten Systeme mit dem Internet, über welches die gesammelten Informationen zum Sun Support Center übertragen werden. Daraufhin stehen die ausgewerteten Informationen über ein Internet-Portal abrufbar bereit. Hier zeigt sich auch eine wesentliche Stärke von Sun Net Connect : Durch die Zuordnung von Rollen und Zugriffsberechtigungen zu den Benutzer- Identifikationen werden Views (Ansichten) erzeugt, die es erlauben, verschiedenen Personenkreisen Zugriff zu diesen Daten zu geben. Hervorzuheben ist dabei, dass zusätzlich zu den Views des Sun Support Center und des Endkunden es auch möglich ist, Dritte wie z.B. einen Servicepartner teilweise in dieses Konzept mit einzubeziehen.

Sun Net Connect bietet folgende Funktionen:

Systemüberwachung Resourcenauslastung: Nachverfolgung von Betriebssystem- Ereignissen durch ein Set von Performancemessgrößen. Auslösen von Alarmen bei Überschreitung von Systemparametern oder Schwellenwerte.

Ferndiagnose Mitarbeiter des Support Centers können Diagnoseprogramme in den Servern via Internet ablaufen lassen und die Ergebnisse auswerten.

Benachrichtigung bei Hardwarefehlern Mittels der System Controller (siehe Abbildung 6) werden wichtige Hardwarekomponenten der Server überwacht. Informationen über Anzeichen eines drohenden Defektes.

Trendberichte Treten gleiche oder ähnliche Situationen wie z.B. Lastspitzen gehäuft auf, so wird dies in Trendberichten dargestellt und damit vor Überlastungen gewarnt, bzw. Hinweise auf sinnvolle Systemerweiterungen gegeben.

Verfügbarkeitsberichte Es werden die Zeiten, in denen das Betriebssystem läuft, und solche, in denen ein Server gestoppt ist, in Relation gesetzt und daraus Verfügbarkeitsdaten errechnet.

Konfigurations- und Patch-Berichte Es wird die Systemkonfiguration mit den Auslastungsdaten verglichen um Veränderungen im Auslastungsprofil mit der aktuellen Betriebssystemkonfiguration zu vergleichen. Außerdem werden die am System installierten Softwareversionen auf Aktualität analysiert.

Während Sun Net Connect Systeme überwacht, indem in regelmäßigen Intervallen Informationen an ein Sun Remote Support Center gesendet und dort aufbereitet bzw.

von dort über das Internet abgerufen werden können, geht das Produkt Sun Management Center einen anderen Weg. Hier werden die Informationen auf dem System selbst, oder bei einem Netzwerk auf einem Management Server gesammelt,konsolidiert und ausgewertet.

Die Sun Management Center Software vereint viele verschiedene Komponenten, welche einerseits Informationen über den Zustand ganzer Netzwerke von Sun-Servern charakterisieren, und andererseits diese Informationen auswerten bzw. über APIs anderen Softwareprodukten zur Verfügung stellen. Damit ist die Einbettung solcher Netzwerke in rechnerübergreifende Management-Systeme möglich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 SMC Gliederung

Sun Management Center bietet folgende Funktionen:

Service Availability Manager steigert die Verfügbarkeit der Dienste (FTP, Webserver, Mail, etc.) auf den Systemen durch Konfigurationsvorschläge und Überprüfungen.

System Reliability Manager hilft, die Zuverlässigkeit des Systems weiter zu steigern, indem z.B. Crash-Dump Analysen nach einem Betriebsystemfehler durchgeführt werden.

Performance Reporting Manager analysiert Informationen über die Auslastung von Systemkomponenten und Peripheriegeräten und erstellt Diagramme, die potentielle Engpässe und Trends zeigen.

Change Manager unterstützt System-Administratoren beim Aktivieren neuer Versionen von Softwarekomponenten durch Analyse von Abhängigkeiten.

Advanced System Monitoring überwacht die Hardware des Gesamtsystems und das Verhalten des Betriebssystems Solaris und unterstützt Diagnoseprogramme beim Auffinden von möglichen Defekten.

Container Manager ermöglicht es dem Systemverwalter, Solaris Container²einfach zu erstellen und zu verwalten.

Um die weiter oben beschriebenen Softwaretools mit möglichst detaillierten Informationen über den Betriebszustand von Hardwarekomponenten versorgen zu können, entwickelte Sun schon vor einigen Jahren Sun Remote System Control (RSC), eine Erweiterungskarte für die Sun Fire Produktlinie der Mittelklasse-Server. Sie besitzt einen seriellen RS232 und einen RJ45-LAN Anschluss sowie ein on-Board Modem und ist in der Lage, Temperatur und Einzelkomponentenfunktionen des Servers zu messen und zu reporten. Weiters können die Funktionen der Systemkonsole und des Open Boot PROM mit seinen verschiedenen Diagnosemöglichkeiten via RSC über Modemleitungen oder LANs zum Einsatz kommen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 V20z System Board mit System Controller Quelle: Sun Microsystems

Das jetzt aktuelle Produkt ist der Sun Advanced Lights Out Manager (ALOM), eine Weiterentwicklung des RSC. Für ältere Server ist ALOM als Erweiterungskarte erhältlich, alle seit 2004 neu auf den Markt gebrachten Server integrieren die Hardware des ALOM System-Controllers auf dem System-Board (vgl. [26 c]).

Trotz der tiefen Integration des ALOM System-Controller (SC) auf dem System Board ist dieser vollkommen unabhängig von der Funktionsfähigkeit des eigentlichen Servers.

Zusätzlich zu den schon im RSC implementierten Überwachungs- und Kommunikationsfunktionen werden hier auch der Betriebszustand der verschiedenen im Server eingebauten Peripheriegeräte wie Disks und hotplug³ Komponenten überwacht. Das Command-Line-Interface (CLI) ist über die serielle Schnittstelle und über Telnet erreichbar. Weiters können E-Mails verschickt und SNMP Traps erzeugt werden.

2.3 Remote-Service der StorageTek Corporation

Die StorageTek Corporation ist weltweiter Marktführer als Hersteller von Datensicherungs-Robotern. Diese Tape-Libraries können bis zu tausende Magnetband-Kassetten beherbergen, dutzende Bandlaufwerke installiert haben und speichern bis zu Petabytes an Daten, wobei eine durchschnittliche Installation einige hundert Kassetten und maximal zehn Laufwerke umfasst. Allerdings muss hier angemerkt werden, dass sich diese Werte in den letzten Jahren stark reduziert haben, da sich die Speicherkapazitäten, Aufzeichnungsdichten und Übertragungsraten der Magnetbänder bzw. Bandlaufwerke erheblich verbessert haben.

So können heute auf einem SDLT/600⁴ Laufwerk mit geeignetem Medium 300 GB unkomprimierte Daten bei einer Übertragungsrate von 36 MB/Sek. aufgezeichnet werden. Die jüngste LTO⁵ Generation, LTO-3 wird bis zu 400 GB unkomprimiert bei knapp 70 MB/Sek. schreiben und lesen. Es werden bei Datensicherungen oft Komprimierungsfaktoren von 1:2 bis 1:2,5 erreicht, wodurch sich oben genannte Werte noch weiter erhöhen.

StorageTek bietet neben seinen Produkten auch Dienstleistungen und Service für Hardware und Software an. Dabei ist ein wesentlicher Unterschied zwischen den Produkten, die über ESCON oder FICON an die Großrechner der Type OS/390 (auch: z/OS) angeschlossen werden, und den open systems Produkten, die via SCSI oder Fibre Channel mit Unix- oder Windows-System kommunizieren.

Erstere werden durch die enge Integration in die OS/390 Software durch diese auch überwacht und kommunizieren sämtliche Fehlerzustände und Error-Codes an das Betriebssystem, welches diese Informationen in der Datei SYSLOG abspeichert. Ein Servicetechniker benötigt ausschließlich die Informationen, welche er vom OS/390 Dienstprogramm Environmental Record Editing and Printing Program (EREP) zur Verfügung gestellt bekommt, um über die Vorgangsweise zur Fehlerbehebung entscheiden zu können.

Im Bereich der open systems stellt sich die Situation jedoch vollkommen anders dar. Die Vielzahl der Peripheriegeräte (Bandlaufwerke) einerseits sowie der Betriebssysteme und Datensicherungsapplikationen andererseits brachten über lange Zeit ein ziemliches Durcheinander an Fehlermeldungen und Fehlerbehandlungen mit sich. Dies hat sich in jüngerer Vergangenheit durch die Implementierung von SNMP gebessert, jedoch wird diese Möglichkeit eher zurückhaltend verwendet.

Jeder Roboter der StorageTek Mid-Range Produkte verfügt jedoch über einen Service und Diagnostic Anschluss für einen Laptop.

Hier steht dem Techniker ein Command Line Interface (CLI) zur Verfügung, durch welches grundlegende Servicearbeiten unterstützt werden. So können etwa die gespeicherten Fault Symptom Codes (FSC) abgefragt werden (vgl.25).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 StorageTek L-Series Diagnosekommandos

Die FSCs geben Aufschluss über Fehler oder Situationen, in welchen vorgesehene Wertebereiche von Betriebsparametern überschritten wurden. Da sich Defekte oft durch vorherige Fehler, die durch Wiederholungen der Ein/Ausgabe-Operationen behebbar waren, ankündigen, ist das Verfolgen von soft errors ein lohnendes Vorgehen. Werden also in bestimmten Bandlaufwerken oder bei bestimmten Medien viele retries festgestellt, so lässt dies auf sich ankündigende Probleme oder Defekte schließen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8 StorageTek L-Series Library Fault Symptom Code Listing

Für den Servicetechniker ist es daher von Vorteil, die FSCs bereits zu kennen, bevor er sich mit Ersatzteilen auf den Weg zum Kunden macht. Denn der Grund eines load error , der anzeigt, dass eine Bandkassette nicht in ein Laufwerk eingelegt werden konnte, kann die Kassette selbst, das Laufwerk oder der Roboter-Mechanismus sein.

Die Roboter der Serie 93xx und SL8500 am oberen Ende des Produktspektrums, welche Tausende von Magnetbandkassetten verwalten können, besitzen eine Steuereinheit Library Management Unit (LMU). Sie verfügt über eine Dial-In und Dial-Out Funktion, wobei kritische Fehler an ein zentrales StorageTek Support-Center gemeldet werden und der diensthabende Techniker zusätzliche Informationen aus der LMU abrufen kann.

3 Präzisierung der Aufgabenstellung

Es ist für die zentralen Komponenten einer heterogenen IT-Infrastruktur wie Server, externe Speicher, SAN⁶, NAS⁷ und LAN Komponenten und Spezialgeräte wie z.B. Firewalls eine Möglichkeit zu konzipieren, Hardware-Fehler oder Defekte in geeigneter Form mittels Dial-Out an ein Servicecenter zu kommunizieren.

Dabei sollen auch die jeweils vorhandenen Funktionen der Geräte, Status- oder Fehlerinformationen zu versenden oder bereitzustellen, verwendet werden. Ziel ist es, durch schnelle Kommunikation von Fehlern, deren Behebung zu beschleunigen und dadurch die IT-Verfügbarkeit zu verbessern.

Die Größe der IT-Infrastrukturen, für die dieses Konzept ausgelegt sein soll, erstreckt sich von einer Handvoll Server bis hin zu insgesamt ca. 20 Geräten. Viele österreichische mittelständische Unternehmen betreiben eine IT-Infrastruktur dieser Größenordnung. Es werden also Kleinstinstallationen nicht betrachtet, genauso wie riesige Unternehmens-Rechenzentren, wobei es in sehr großen Rechenzentren eventuell Einsatzfälle für speziell zu überwachende Geräte geben kann.

3.1 Funktionelle Anforderungen

Oft werden Rechenzentren im so genannten lights out Modus betrieben, also im Dunkeln, ohne Bedienpersonal. Dieses befindet sich irgendwo im Gebäude, oft auch an anderen Firmenstandorten.

Bei Auftreten einer Störung muss nun die verursachende Komponente identifiziert werden, um den Kundendienst der Firma, die genau diese Komponente betreut, kontaktieren zu können. Fehldiagnosen können hier zu Zeitverlust und zusätzlichen Kosten führen.

Die Identifizierung von defekten Geräten soll dadurch unterstützt werden, indem die Geräte an eine Fernwartungseinheit angeschlossen werden, die regelmäßig Nachrichten an die Geräte schickt und die daraus resultierenden Antworten auswertet, oder Nachrichten von den Geräten empfängt, welche diese in bestimmten Betriebssituationen versenden.

Diese Nachrichten und Antworten sollen dazu benutzt werden, um mögliche Fehlerquellen und Ursachen an das Bedienpersonal zu signalisieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9 Fernwartung durch Service-Partner bei heterogener IT-Infrastruktur

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-1 Überwachungsmethoden

In weiterer Folge kann diese Information an den diensthabenden Kundendienst- Techniker übermittelt werden, um ihn vom Vorliegen einer Störung zu informieren. Er kann daraufhin diejenigen Maßnahmen einleiten, welche zusätzliche Informationen zur Identifikation des Fehlers oder Defektes bringen wie z.B. Verbindung zu den Geräten aufnehmen und Diagnoseinformationen abrufen. Dadurch wird die Fehlereingrenzung zusätzlich unterstützt. Ist der Fehler lokalisiert, so können die notwendigen Maßnahmen zur Behebung entweder vom Bedienpersonal, dem Techniker oder beiden eingeleitet und durchgeführt werden.

Die Fernwartungseinheit muss so konzipiert und aufgebaut sein, dass sie die folgenden grundlegenden Anforderungen erfüllt:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-2 Anforderungen an die Fernwartungseinheit

Die Kommunikation mit dem Bedienpersonal, dem Kundendiensttechniker und dem Service-Center ist auf Basis heute gängiger Nachrichtenübermittlung so unmittelbar wie möglich zu gestalten.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-3 Kommunikationsmethoden

3.2 Wirtschaftliche Anforderungen

Waren bis in die späten 90er Jahre IT-Serviceverträge eine sichere und ertragreiche Einnahmequelle, so hat sich dies durch den Preisdruck in der jüngeren Vergangenheit und durch die zunehmende Hardware-Stabilität drastisch geändert.

Die von den Herstellern eingeräumten Gewährleistungszeiträume sind bei vielen Produkten auf 2 oder 3 Jahre verlängert worden, was oft 50% - 60% des Produkt lebenszyklus darstellt.

Die Serviceverträge werden üblicherweise in unterschiedlichen Stufen angeboten, um für die verschiedenen Einsatzzwecke der Geräte eine passende Servicevariante zu haben:

Abbildung in dieser Leseprobe nicht⁸ enthalten

Tabelle 3-4 Servicevertragstypen

Da die laufenden Service- und Lizenzverträge einen wesentlichen Anteil, nämlich bis zu 75% der operativen Kosten eines IT-Budgets ausmachen, betreiben Kunden in jüngster Zeit auch geschäftskritische Komponenten ihrer IT-Infrastruktur ohne Serviceverträge. Redundanzen in der Architektur der Geräte und der IT-Architektur selbst machen eine solche Vorgehensweise zunehmend möglich.

In dieser Konkurrenzsituation zwischen den Herstellern und IT-Integratoren bzw. Serviceanbietern ist ein Alleinstellungsmerkmal, welches unser Serviceangebot von anderen Serviceangeboten unterscheidet, höchst willkommen.

Allerdings darf es den Endkundenpreis der Dienstleistung Hardware-Service nicht erhöhen. Die Kosten des Alleinstellungskriteriums, hier die Fernwartungseinheit, müssen vom Anbieter getragen werden und bei ihm Einsparungen in der eigenen Kostenstruktur mit sich bringen.

Daher sind die Kosten der Fernwartungseinheit, sowohl die Aufwendungen zum Bau und der Weiterentwicklung von Hardware und Software betreffend, als auch die Stückkosten des Gerätes selbst, von extremer Wichtigkeit.

3.3 Weitere Anforderungen

Neben den oben genannten funktionellen und wirtschaftlichen Anforderungen lassen sich noch eine Anzahl ebenfalls wichtiger, aber untergeordneter Anforderungen aufstellen:

Abmessungen der Fernwartungseinheit: Das Gehäuse soll ungefähr die Größe eines externen Modems besitzen.

Anschlüsse: Stromversorgung, RJ45 10/100 Base-T, JTAG, RS232 Systemkonsole, 4 8 x RS232 als SUB-D 9-polig oder RJ45 Stecker ausgeführt.

Stromversorgung: soll als Steckernetzgerät ausgeführt werden.

Bedienung: Eingabe von Kommandos über den Status der Fernwartungseinheit und der angeschlossenen Geräte sollen möglich sein.

Servicierbarkeit: Bei Defekten soll das Gerät ausgetauscht werden. Darum sollen die Konfigurationseinstellungen extern speicherbar sein, um in solchen Situationen einfach in das neue Gerät übertragen werden zu können.

Programmierung und Software-Tools: Die Programmierung soll in einer höheren Programmiersprache erfolgen. Assembler-Programmierung ist möglichst zu vermeiden bzw. zu minimieren. Open-Source Entwicklungswerkzeuge sind zu bevorzugen.

Konfigurationsmöglichkeiten: Je nach Einsatzzweck sind die Konfigurationsparameter der jeweiligen IT-Umgebung im Gerät permanent abzuspeichern, sodass auch nach einem Stromausfall diese Informationen verfügbar sind. Weiters ist vorzusehen, dass die Konfigurationseinstellungen auch im laufenden Betrieb verändert und aktiviert werden können.

4 Systemkonzept

Die grundlegende Entscheidung ist die eines Software- oder eines Hardware- basierenden Konzepts, wobei in jedem Konzept beide Komponenten benötigt werden. Ein Software-basierendes Konzept würde versuchen, die gewünschte Funktionalität möglichst auf den Geräten zu implementieren, die es zu überwachen und servicieren gilt. Dies ist bei Servern relativ einfach möglich, obwohl zwei wesentliche Punkte nicht zu übersehen sind: Die Implementierung müsste an die Betriebssysteme der Server angepasst werden Bei Ausfall eines solchen Servers fällt die Fernwartungsfunktion ebenfalls aus Weiters wäre zur Überwachung von externen Peripheriegeräten und nicht frei programmierbaren Geräten ( Appliances ) die Implementierung der Fernwartungs- funktion auf Servern notwendig, wodurch eine zusätzliche Abhängigkeit von Geräten untereinander geschaffen würde.

Aus oben genannten Gründen wurde entschieden, eine Hardware-basierende Implementierung vorzunehmen. Dies bedeutet, dass eine eigene Fernwartungseinheit zu entwickeln ist, welche an die zu überwachenden Geräte angeschlossen wird. Dies kann über eigens dafür vorgesehene Diagnose-Anschlüsse an den zu überwachenden Geräten vorgenommen werden oder über ein LAN, welches heute in jedem Rechenzentrum installiert ist.

Abbildung 10 zeigt, wie sich die Fernwartungseinheit in eine bestehende Rechenzentrums-Infrastruktur einfügt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10 Heterogene RZ-Infrastruktur mit Fernwartungseinheit

4.1 Betrachtung möglicher Hardware Konzepte

Eine Reihe von Hardware-Plattformen wären prinzipiell als Basis geeignet, allen voran der klassische PC. Viele Hersteller vertreiben Einstiegsmodelle von Servern, die auf der Intel x86 Architektur basieren. Allerdings sind auch dafür, so es sich um Markengeräte handelt, Preise über von tausend Euro zu veranschlagen.

Es werden in diesem Zusammenhang absichtlich keine No-Name PCs betrachtet, die als Sonderangebote um einige hundert Euro regelmäßig über die Ladentische diverser Supermärkte oder Elektronikketten wandern. Die Hardware-Konfigurationen solcher Produkte werden einmalig für eine bestimmte Verkaufsaktion zusammengestellt; die Wahrscheinlichkeit, genau diese Konfiguration noch einmal kaufen zu können, ist fast Null. Daraus resultieren Hardware-Variationen, welche sich negativ auf die Qualität und Servicierbarkeit des Endproduktes Fernwartungseinheit auswirken würden.

Zwei weitere Punkte machen Geräte mit PC Architektur nicht zur ersten Wahl: Die Notwendigkeit mehrerer asynchroner RS232 Schnittstellen könnte in dieser HW Architektur am einfachsten über PCI-Erweiterungsplatinen realisiert werden. Diese kosten jedoch in einer 4-fach-RS232 Ausführung knapp unter 100 Euro. Außerdem hat diese Plattform in den fast 25 Jahren ihres Bestehens ein hohes Maß an technischer Komplexität erreicht. Die heute darauf eingesetzten Betriebssysteme wie Windows und Linux besitzen einen viel zu großen Funktionsumfang gemessen an den hier zu erfüllenden Anforderungen. Dazu mehr im Kapitel 4.2.

Somit fiel die nähere Betrachtung auf Embedded Systems. Diese unterscheiden sich von klassischen Servern im Wesentlichen durch ihre Limits; sei es bei der CPULeistung, der Speicherkapazität, aber auch denn äußeren Abmessungen und nicht zu vergessen beim Preis.

Der Markt der Microcontroller für Embedded Systems ist groß und bietet 8-bit, 16-bit oder 32-bit CPUs in RISC oder CISC Architekturen.

4.2 Gegenüberstellung von Embedded Lösungen

Es werden eine Vielzahl von Embedded Lösungen angeboten, die von einem sehr kleinen und spezialisierten Funktionsumfang bis hin zu umfangreichen und generell ausgelegten Produkten reichen.

Der bestimmende Bauteil ist dabei der Microcontroller, der durch seine Architektur zwei grundlegende Rahmenparameter festlegt: Die Verarbeitungsgeschwindigkeit und die Hauptspeicherkapazität.

Während die Verarbeitungsgeschwindigkeit durch die Taktfrequenz, die Wortbreite (8 / 16 / 32 bit) und mehrere Architektureigenschaften (Instruktionsset, Verarbeitungs- parallelität, ) bestimmt wird, ist die verfügbare Hauptspeicherkapazität im Wesentlichen von der Breite des Adressbusses abhängig. Gerade in diesem Bereich wurden einige weit am Markt verbreitete Microcontrollerarchitekturen den wachsenden Anforderungen angepasst, in dem zusätzliche Adressierungsverfahren wie Bank- Switching oder Segmentierung des Hauptspeichers zum Funktionsumfang des Microcontrollers hinzugefügt wurden.

Nachstehend eine kurze Übersicht über heute populäre Microcontroller und Ihrer Hersteller. Dabei ist auch zu sehen, dass für einige sehr erfolgreiche Architekturen wie der des 8051 von Intel oder der ARM7 Familie von ARM etliche Lizenznehmer gleichartige, oft jedoch auch weiterentwickelte Produkte vermarkten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11 Microcontroller Hersteller und Produkte

Der Microcontroller selbst ist jedoch nur eine Komponente des Embedded Systems. Die Anschlussmöglichkeiten am Microcontroller, von Daten/Adressbus bis zu Ethernet, SPI und I2C definieren in hohem Maße die Verwendbarkeit eines Produktes für einen bestimmten Einsatzzweck.

Im Folgenden werden einige Produkte betrachtet, welche grundsätzlich als Basis für die Fernwartungseinheit verwendbar wären.

4.2.1 TINI Tiny Network Interface

Das TINI-Board basiert auf dem 8051-Derivat DS80C390 von Dallas Semiconductor. Abgesehen von der weitaus höheren Verarbeitungsgeschwindigkeit (Taktrate bis 40 MHz) im Vergleich zum 8051 verfügt der DS80C390 über:

¹Sun steht für Stanford University Network und benennt das Projekt, welches die Firmengründer Andreas v. Bechtolsheim, Bill Joy, Vinod Koshla und Scott McNealy gemeinsam bearbeiteten.

²Ein Solaris Container ist eine gekapselte Instanz des Betriebssystems Solaris, wovon tausende auf einem Server gleichzeitig aktiv sein können.

³ Komponenten, welche während des Betriebs des Server ein- und ausgebaut werden können.

⁴SDLT = Super Digital Linear Tape, eine Spezifikation der Quantum Corporation.

⁵ LTO steht für Linear Tape Open einem Standard für Datenaufzeichnung auf Magnetbändern.

⁶SAN: Storage Area Network, ein Glasfaser-Netzwerk zwischen Server und Speichergeräten

⁷NAS: Network attached Storage: Speichergeräte, welche Fileserver-Funktionen besitzen

⁸SLA steht für Service Level Agreement