7
1 Einleitung und Ƞberblick Der Begriff Agent wird in der Software- technik fɒr teils sehr unterschiedliche Konzepte verwendet (siehe z. B. Franklin [ FrGr96]). Die verschiedenen AnsȨtze kɆnnen entweder dem Bereich der kɒnst- lichen Intelligenz oder dem Bereich der verteilten Systeme zugeordnet werden. Im Bereich der kɒnstlichen Intelligenz wer- den Agenten oft als Assistenten des Men- schen gesehen, die die FȨhigkeit haben, selbststȨndig zu handeln und Entscheidun- gen zu treffen. Im Bereich der verteilten Systeme sind Agenten meist mobile Soft- warekomponenten, die unter bestimmten Annahmen (z. B. unsichere Netzwerkver- bindungen, geringe Bandbreite) die Reali- sierung flexiblerer und robusterer Soft- warearchitekturen ermɆglichen. Agenten, die dieser Sichtweise entsprechen, werden als mobile Agenten bezeichnet. Die in diesem Artikel beschriebene Umgebung basiert auf mobilen Agenten. Unter mobilen Agenten verstehen wir Softwarekomponenten, die die FȨhigkeit haben, ihren Zustand und Programmcode von einem Rechner in einem Computer- netzwerk zu einem anderen Rechner zu transferieren [siehe CaLZ98; FrGr96; Whit97]. Die im Folgenden beschriebene Arbeit wird im Rahmen einer Forschungskoope- ration mit Siemens Deutschland durch- gefɒhrt. Das Hauptziel dieser Kooperation ist, das Potenzial agentenbasierter Archi- tekturen fɒr die Ferndiagnose, -ɒber- wachung und -steuerung von Prozess- automatisierungssystemen zu untersu- chen. Die Arbeit erfolgte auf Basis der Ja- va-basierten Agentenplattform Aglets [ LaOs98], die mittlerweile von IBM als Open Source Projekt zur Verfɒgung ge- stellt wurde [IBM00]. In einem Teilprojekt wurde eine Bridge zu CORBA-Systemen unter Einsatz des MASIF-Standards [OMG97] entwickelt. Wir bezeichnen die von uns entwickel- ten Komponenten, Frameworks und Werkzeuge als RSE (Remote Supervising Environment). RSE wurde vor allem mit dem Fokus auf die Einsetzbarkeit in der ProzesssteuerungsdomȨne konzipiert. Die Umgebung enthȨlt aber auch Dienste fɒr die Konfiguration von Agenten zur Lauf- zeit und fɒr die Integration von betriebs- systemspezifischen Diensten, die ganz all- gemein fɒr mobile Agentensysteme wich- tig sind. Wir geben in diesem Artikel einen Ƞberblick ɒber die wesentlichen Konzepte und Bestandteile des von uns entwickelten Softwaresystems. Im nȨchsten Abschnitt beschreiben wir zunȨchst die Anwen- dungsdomȨne, fɒr die RSE entwickelt wurde. In Abschnitt 3 erlȨutern wir wich- tige Anforderungen an das System und stellen dann wesentliche Elemente der Ar- chitektur vor. In Abschnitt 4 werden Bei- spiele fɒr Diagnose- und Ƞberwachungs- agenten vorgestellt. Abschnitt 5 gibt einen Ƞberblick ɒber die zur Verfɒgung stehen- den Konfigurationswerkzeuge. Wir schlie- ßen mit einer Beschreibung der gesammel- ten Erfahrungen und mit einem Ausblick auf weitere Arbeiten. 2 AnwendungsdomȨne RSE unterstɒtzt die Ƞberwachung von Prozessautomatisierungssystemen in der Stahlindustrie. Typischerweise bestehen solche Systeme aus mehreren Rechnern (oft mit unterschiedlichen Betriebssyste- men), die durch ein lokales Netzwerk mit- einander verbunden sind. Die Funktionali- tȨt von RSE kann in die Bereiche Ferndiag- nose und Systemɒberwachung gegliedert werden. Bei der Ferndiagnose werden bestimm- te Aspekte eines Automatisierungssystems ɒber einen definierten Zeitraum ɒber- wacht und Messdaten erfasst. Die gesam- melten Daten werden verdichtet und visu- ell aufbereitet. Die verantwortlichen Anla- genɒberwacher sollen dadurch in die Lage versetzt werden, Probleme rechtzeitig zu erkennen und Gegenmaßnahmen zu er- greifen. Die zu ɒberwachenden Aspekte hȨngen vom jeweiligen Automatisierungs- system und von den Kundenwɒnschen ab. Beispiele sind die Belegung und IntegritȨt von Festplatten, die Auslastung von Hauptspeicher und Prozessor durch aus- gewȨhlte Betriebssystemprozesse sowie QualitȨtsparameter, die von der Prozess- steuerungssoftware geliefert werden. Die gesammelten und zum Teil verdichteten Dr. Reinhold PlɆsch, Dr. Rainer Weinreich, Arbeitsgruppe Software Engineering, Institut fɒr Wirtschafts- informatik, Johannes Kepler UniversitȨt Linz und Software Competence Center Hagenberg, Austria, E-Mail: {ploesch|weinreich}@swe.uni-linz.ac.at Ein agentenbasierter Ansatz fɒr die Ferndiagnose und -ɒberwachung von Automatisierungssystemen Reinhold PlɆsch, Rainer Weinreich WI – Schwerpunktaufsatz WIRTSCHAFTSINFORMATIK 43 (2001) 2, S. 167–173 167

Ein agentenbasierter Ansatz für die Ferndiagnose und-überwachung von Automatisierungssystemen

  • Upload
    rainer

  • View
    214

  • Download
    1

Embed Size (px)

Citation preview

1 Einleitung und �berblickDer Begriff Agent wird in der Software-technik f�r teils sehr unterschiedlicheKonzepte verwendet (siehe z. B. Franklin[FrGr96]). Die verschiedenen Ans�tzek�nnen entweder dem Bereich der k�nst-lichen Intelligenz oder dem Bereich derverteilten Systeme zugeordnet werden. ImBereich der k�nstlichen Intelligenz wer-den Agenten oft als Assistenten des Men-schen gesehen, die die F�higkeit haben,selbstst�ndig zu handeln und Entscheidun-gen zu treffen. Im Bereich der verteiltenSysteme sind Agenten meist mobile Soft-warekomponenten, die unter bestimmtenAnnahmen (z. B. unsichere Netzwerkver-bindungen, geringe Bandbreite) die Reali-sierung flexiblerer und robusterer Soft-warearchitekturen erm�glichen. Agenten,die dieser Sichtweise entsprechen, werdenalsmobile Agenten bezeichnet.

Die in diesem Artikel beschriebeneUmgebung basiert auf mobilen Agenten.Unter mobilen Agenten verstehen wirSoftwarekomponenten, die die F�higkeithaben, ihren Zustand und Programmcodevon einem Rechner in einem Computer-netzwerk zu einem anderen Rechner zutransferieren [siehe CaLZ98; FrGr96;Whit97].

Die im Folgenden beschriebene Arbeitwird im Rahmen einer Forschungskoope-ration mit Siemens Deutschland durch-gef�hrt. DasHauptziel dieser Kooperationist, das Potenzial agentenbasierter Archi-tekturen f�r die Ferndiagnose, -�ber-wachung und -steuerung von Prozess-automatisierungssystemen zu untersu-chen. Die Arbeit erfolgte auf Basis der Ja-va-basierten Agentenplattform Aglets[LaOs98], die mittlerweile von IBM alsOpen Source Projekt zur Verf�gung ge-stellt wurde [IBM00]. In einem Teilprojektwurde eine Bridge zu CORBA-Systemenunter Einsatz des MASIF-Standards[OMG97] entwickelt.

Wir bezeichnen die von uns entwickel-ten Komponenten, Frameworks undWerkzeuge als RSE (Remote SupervisingEnvironment). RSE wurde vor allem mitdem Fokus auf die Einsetzbarkeit in derProzesssteuerungsdom�ne konzipiert. DieUmgebung enth�lt aber auch Dienste f�rdie Konfiguration von Agenten zur Lauf-zeit und f�r die Integration von betriebs-systemspezifischen Diensten, die ganz all-gemein f�r mobile Agentensysteme wich-tig sind.

Wir geben in diesem Artikel einen�berblick �ber die wesentlichen Konzepteund Bestandteile des von uns entwickeltenSoftwaresystems. Im n�chsten Abschnittbeschreiben wir zun�chst die Anwen-dungsdom�ne, f�r die RSE entwickeltwurde. In Abschnitt 3 erl�utern wir wich-tige Anforderungen an das System undstellen dann wesentliche Elemente der Ar-chitektur vor. In Abschnitt 4 werden Bei-spiele f�r Diagnose- und �berwachungs-agenten vorgestellt. Abschnitt 5 gibt einen�berblick �ber die zur Verf�gung stehen-den Konfigurationswerkzeuge. Wir schlie-ßen mit einer Beschreibung der gesammel-ten Erfahrungen und mit einem Ausblickauf weitere Arbeiten.

2 Anwendungsdom�ne

RSE unterst�tzt die �berwachung vonProzessautomatisierungssystemen in derStahlindustrie. Typischerweise bestehensolche Systeme aus mehreren Rechnern(oft mit unterschiedlichen Betriebssyste-men), die durch ein lokales Netzwerk mit-einander verbunden sind. Die Funktionali-t�t von RSE kann in die Bereiche Ferndiag-

nose und System�berwachung gegliedertwerden.

Bei der Ferndiagnose werden bestimm-te Aspekte eines Automatisierungssystems�ber einen definierten Zeitraum �ber-wacht und Messdaten erfasst. Die gesam-melten Daten werden verdichtet und visu-ell aufbereitet. Die verantwortlichen Anla-gen�berwacher sollen dadurch in die Lageversetzt werden, Probleme rechtzeitig zuerkennen und Gegenmaßnahmen zu er-greifen. Die zu �berwachenden Aspekteh�ngen vom jeweiligen Automatisierungs-system und von den Kundenw�nschen ab.Beispiele sind die Belegung und Integrit�tvon Festplatten, die Auslastung vonHauptspeicher und Prozessor durch aus-gew�hlte Betriebssystemprozesse sowieQualit�tsparameter, die von der Prozess-steuerungssoftware geliefert werden. Diegesammelten und zum Teil verdichteten

Dr. Reinhold Pl�sch, Dr. RainerWeinreich, Arbeitsgruppe SoftwareEngineering, Institut f�rWirtschafts-informatik, Johannes Kepler Universit�tLinz und Software Competence CenterHagenberg, Austria, E-Mail:{ploesch|weinreich}@swe.uni-linz.ac.at

Ein agentenbas ier terAnsat z f�r die

Ferndiagnose und-�berwachung von

Au tomat is ierungssy stemen

Reinhold Pl�sch, Rainer Weinreich

WI – Schwerpunktaufsatz

WIRTSCHAFTSINFORMATIK 43 (2001) 2, S. 167–173 167

Daten werden unter Verwendung vonStandardtechniken (HTML, Java-Applets)mittels Webbrowser visualisiert.

W�hrend bei der Ferndiagnose die Er-kennung langfristiger Trends im Vorder-grund steht, zielt der Bereich System�ber-wachung darauf ab, Probleme zu erkennenund sofort ad�quate Aktionen auszul�sen.Dabei werden kritische Aspekte des Sys-tems (wie z. B. Qualit�tsparameter) lau-fend �berwacht. Wenn spezifizierte Tole-ranzwerte verletzt werden, werden vonder �berwachungssoftware automatischvorkonfigurierte Reaktionen eingeleitet.Solche Reaktionen k�nnen sein: Benach-richtigung des Anlagen�berwachers viaE-Mail, Senden von Nachrichten an lokaleAnlagenbediener oder autonome Eingriffein die Steuerung der Anlage (z. B. Ver-�ndern von Parametern f�r Temperatur-oder Geometriemodelle).

3 Systemarchitektur

Aus der Anwendungsdom�ne und aus denBesonderheiten des Zielsystems ergebensich eine Reihe von grundlegenden Anfor-derungen an das System, die im Folgendenkurz erl�utert werden. Beispiele sind Por-tabilit�t, die Ber�cksichtigung tempor�rerNetzwerkverbindungen, die Interaktionmit anderen Hardware- und Softwareres-sourcen und die dynamische Konfigurier-barkeit des Systems. Dazu kommen typi-sche Verteilungsaspekte, wie die Gew�hr-leistung von Sicherheit und die Synchroni-sation paralleler Abl�ufe (z. B. paralleleMessungen).

RSE basiert auf dem Aglets SDK [La-Os98] der Firma IBM. Aglets SDK ist inJava [siehe Sun00] implementiert, was in-h�rent ein gewisses Maß an Portabilit�t si-cherstellt und die Integration von Java-

Komponenten von Drittanbietern erleich-tert. Dar�ber hinaus bietet Aglets nebender notwendigen Grundfunktionalit�t f�rmobile Agentensysteme (z. B. Objektmi-gration, Codetransport) auch eine Reihen�tzlicher Sicherheitsmechanismen [Ka-LO97] an.

In den folgenden Unterkapiteln wirddie Architektur der beiden wichtigstenfunktionalen Bereiche von RSE vor-gestellt, wobei wir an geeigneter Stelle aufdie Ber�cksichtigung der angesprochenenAnforderungen Bezug nehmen.

3.1 Ferndiagnose

Bild 1 gibt einen �berblick �ber die f�r dieFerndiagnose relevanten Teile der Archi-tektur unseres Systems. In der Abbildungist die Beziehung zwischen Administrati-onseinheit und Automatisierungssystemdargestellt. Aus der Sicht der Administra-tionswerkzeuge des RSE-Systems bestehtein Automatisierungssystem aus einerMenge von Rechnern, die �ber ein lokalesNetzwerk miteinander verbunden sind.

Ein Rechner pro Automationssystemdient als Eintrittspunkt f�r alle Agenten,die innerhalb der Anlage Mess- und �ber-wachungsaufgaben wahrnehmen sollen.Dieser Rechner wird als UnitGateway be-zeichnet. Der Gateway-Rechner unter-scheidet sich von anderen Rechnern einesAutomationssystems dadurch, dass daraufein spezieller Verwaltungsagent (Unit-Agent) installiert ist, der allgemeine Infor-mationen �ber das zu �berwachende Au-tomatisierungssystem verwaltet. Dazu ge-h�ren Informationen dar�ber, welcheRechner Teil des Automatisierungssystemsind und welche Betriebssysteme jeweilsinstalliert sind.

Ein Administrator an einem Adminis-trationsarbeitsplatz ist mit dem Automati-

sierungssystem �ber eine, unter Umst�n-den nur zeitlich begrenzt verf�gbare,Netzwerkverbindung verbunden. Der Ad-ministrator kann Agenten erzeugen, kon-figurieren und beim jeweiligen Automati-sierungssystem installieren. Einige Diag-noseagenten ben�tigen f�r die Erf�llungihrer Aufgaben zus�tzlichen plattformspe-zifischen Code, um im Rahmen ihrer Di-agnoseaufgaben mit den am Zielsystemverf�gbaren Hardware- und Softwareres-sourcen kommunizieren zu k�nnen. Die-ser plattformspezifische Code muss nebendem eigentlichen Agentencode auch beimZielsystem installiert werden.

Der Installationsprozess f�r einen Di-agnoseagenten l�uft folgendermaßen ab:Zun�chst wird der Code f�r einen Agentenund u. U. auch der Code f�r Hilfsagentenvon der Administrationseinheit zum Au-tomatisierungssystem �bertragen. Nachder Ankunft des Diagnoseagenten amUnitGateway des Automatisierungssys-tems ermittelt der Agent durch Kontakt-aufnahme mit dem Verwaltungsagentender Administrationseinheit, welche platt-formabh�ngigen Bibliotheken ben�tigtwerden. Etwaig ben�tigte plattformspezi-fische Bibliotheken werden nur dann vomAdministrationsrechner zum Automati-sierungssystem �bertragen, wenn diesenicht bereits in der geeigneten Version f�rdie ben�tigte(n) Plattform(en) zur Ver-f�gung stehen.

Nach Abschluss der Installationsphasekann die Verbindung zwischen der Admi-nistrationseinheit und dem Automatisie-rungssystem unterbrochen werden. Derinstallierte Diagnoseagent wartet auf denAnstoß f�r den Beginn einer Messung.Messungen und die Auswertung vonMessergebnissen werden (m�glicherweisezu einem sp�teren Zeitpunkt) am Admi-nistrationsrechner mit einem eigenenWerkzeug, dem Measurement Manager(siehe dazu Abschnitt 5), initiiert.

Der Messvorgang wird von den Diag-noseagenten autonom und je nach Art derDiagnose unterschiedlich durchgef�hrt. Ineinigen F�llen werden die zu sammelndenDaten �ber einen bestimmten Rechner zueinem genau definierten Zeitpunkt ermit-telt, in anderen F�llen m�ssen die Datenkontinuierlich �ber einen l�ngeren Zeit-raum parallel auf mehreren Rechnern ge-sammelt werden. In letzterem Fall erzeugtein Diagnoseagent eine Menge von so ge-nannten Arbeitsagenten, die auf die zu un-tersuchenden Rechner verteilt werden.

Bild 1 Architektur f�r den Bereich Ferndiagnose

Reinhold Pl�sch, Rainer Weinreich

168

Ein Administrator kann zu jedem belie-bigen Zeitpunkt Messergebnisse mit Hilfedes Werkzeuges Measurement Manageranfordern. Wenn eine Messung noch nichtabgeschlossen ist, werden die bisher einge-langten Zwischenergebnisse �bermittelt.Die gelieferten Messergebnisse werden ge-filtert und entsprechend aufbereitet. In deraktuellen Implementierung werden dieAuswertungsergebnisse im HTML-For-mat abgespeichert und k�nnen somit miteinem gew�hnlichen Webbrowser auch�ber das Internet eingesehen werden.

3.2 System�berwachung

Die System�berwachung erlaubt es, kriti-sche Aspekte eines Automatisierungssys-tems kontinuierlich zu �berwachen undbeim Auftreten schwer wiegender Proble-me automatisch Reaktionen auszul�sen.Agenten f�r die �berwachung werden –wie Diagnoseagenten – bei der Adminis-trationseinheit erzeugt und konfiguriertund dann beim Automatisierungssysteminstalliert. W�hrend Diagnoseagenten nurbeim Gateway-Rechner einer Administra-tionseinheit installiert werden k�nnen,k�nnen Agenten f�r laufende �ber-wachungsaufgaben auf jedem beliebigenRechner eines Automatisierungssystemsinstalliert werden (siehe Bild 2).

Unmittelbar nach der Installation eines�berwachungsagenten beginnt dieser mitder zyklischen �berwachung der jeweili-gen Aspekte eines Automatisierungssys-tems. Wir haben Agenten f�r die �ber-wachung des Ressourcenverbrauchs (ver-f�gbarer Festplattenspeicher, Hauptspei-chernutzung, Prozessornutzung) und f�rdie �berwachung von Qualit�tsattributen(z. B. Breite und Dicke von Stahlb�ndernin einem Walzwerk) realisiert. �ber-wachungsagenten l�sen im Falle von Pro-blemen nicht selbst eine Reaktion aus, son-dern delegieren diese Aufgabe an eine be-liebige Anzahl vonReaktionsagenten.

Reaktionsagenten warten darauf, von�berwachungsagenten �ber einen kriti-schen Zustand informiert zu werden. Bei-spiele f�r Reaktionsagenten sind Agenten,die E-Mails an Anlagen�berwacher ver-senden, die Nachrichten an die lokalenAnlagenbediener schicken oder die direktin die Steuerung des Automatisierungspro-zesses eingreifen. Jeder �berwachungs-agent kann mit einer beliebigen Zahl vonReaktionsagenten gekoppelt werden. Die

Verbindungen zwischen den �berwa-chungs- und Reaktionsagenten werdenentweder mit einem Konfigurationswerk-zeug (z. B. von einer Administrationsein-heit aus) erstellt (siehe Abschnitt 4) oderunter Verwendung eines Traders (sieheBild 2) zur Laufzeit von den Agentenselbst definiert.

4 Beispiele f�r typischeSystemdiagnose-Agenten

Eine wichtige Aufgabe bei der Diagnosevon Prozessautomatisierungssystemen istbeispielsweise die Analyse von Speicher-und Prozessornutzung ausgew�hlter Be-triebssystemprozesse. Bild 3 zeigt die Be-nutzerschnittstelle f�r die Konfigurationeines Diagnoseagenten f�r Hauptspeicher-und Prozessornutzung. Allgemeine Para-meter (in Bild 3 nicht sichtbar) erlaubendie Einstellung des Agentennamens, derAdresse der zu diagnostizierenden Anlage

Kernpunkte f�r dasManagement

Die TechnologieMobiler Agenten ist ein homogener Ansatz f�r die Realisierungflexibler verteilter Anwendungsarchitekturen mit Mobilit�tsunterst�tzung., Diagnose und �berwachung von Ressourcen in verteilten Systemen sind

geeignete Anwendungsgebiete f�r diese Technologie., Bestehende Agentenplattformen bieten Basisfunktionalit�t f�r Mobilit�t,

Kommunikation, und Sicherheit in agentenbasierten Systemen., RSE bietet zus�tzliche Dienste, Rahmenwerke undWerkzeuge f�r Diagnose-

und �berwachungsaufgaben.

Stichworte:Mobile Agenten, Rahmenwerk f�r Agenten, Softwarekomponen-ten, Ferndiagnose, Fern�berwachung

Bild 2 Architektur der �berwachungs- und Reaktionsagenten

Ferndiagnose und -�berwachung von Automatisierungssystemen

169

und die Festlegung jener Rechner der An-lage, auf denen dieMessung vorgenommenwerden soll.

Neben diesen Einstellungen kann auchdas Messverfahren parametrisiert werden.In dem in Bild 3 gezeigten Beispiel wirdder Ressourcenbedarf des Betriebssystem-prozesses tracker alle 60 Minuten gemes-sen. Dabei werden �ber einen Zeitraumvon 1 Minute jeweils 10 Messungen vor-genommen, d. h. es werden alle 6 Sekun-den die Messwerte f�r den tracker-Prozess

ermittelt und der Durchschnittswert dieser10 Messungen als ein Messergebnis an denDiagnoseagenten gesendet. In dem o. a.Beispiel werden jeweils die 24 neuestenWerte gespeichert, d. h. die Messungen ei-nes ganzen Tages.

Bild 4 zeigt, wie die Messergebnisse ineinem Web-Browser dargestellt werden.Neben der Visualisierung der Messergeb-nisse ist auch eine Trendanalyse (lineareRegression) m�glich, die eine bessere Ab-sch�tzung der langfristigen Entwicklung

des Speicherbedarfs und der Prozessornut-zung der betrachteten Betriebssystempro-zesse erm�glicht.

Ein Beispiel f�r einen �berwachungs-agenten ist ein Agent zur �berwachungvon Qualit�tsparametern einer Warm-walzanlage. Die Steuerungssoftware f�rdie Walzanlage misst die Profil- und Plan-heitsabweichungen der zu walzendenStahlb�nder und stellt diese Daten in ei-nem Shared-Memory-Segment zur Ver-f�gung. Diese Daten werden vom Agentenlaufend ausgelesen und analysiert. DieKonfigurationsschnittstelle eines Quali-t�ts�berwachers ist in Bild 5 dargestellt.

Zu den in Bild 5 dargestellten Parame-tern f�r die Qualit�ts�berwachung z�hlender eindeutige Schl�ssel f�r das Shared-Memory-Segment und Toleranzgrenzenf�r die Profil- und Planheitsabweichung.Bei einer Verletzung des Toleranzbereicheswerden alle betroffenen Reaktionsagenteninformiert und l�sen eine vorkonfigurierteReaktion aus.

Eine m�gliche Reaktion ist die Verst�n-digung eines zust�ndigen Anlagenbetreu-ers mittels E-Mail. Die Konfigurations-schnittstelle eines E-Mail-Agenten ist inBild 6 dargestellt. Neben allgemeinen Pa-rametern wie SMTP-Server, E-Mail-Adresse von Empf�nger und Absender,kann spezifiziert werden, welche Nach-richt vom Agenten an den Empf�nger wei-tergeleitet wird. Der E-Mail-Agent ist da-r�ber hinaus in der Lage zu pr�fen, ob derEmpf�nger die Nachricht innerhalb eineskonfigurierbaren Zeitintervalls best�tigt.Wird die Nachricht nicht rechtzeitig best�-tigt, werden zus�tzlich weitere Mitarbeiterinformiert. Der E-Mail-Agent reagiert nurdann auf die Nachricht eines �ber-wachungsagenten, wenn zwischen beidenAgenten eine Beziehung hergestellt wurde.Zur Spezifikation von Beziehungen zwi-schen Agenten werden Konfigurations-werkzeuge verwendet, die wir im folgen-den Abschnitt beschreiben.

Bild 3 Konfiguration eines CPU- und Speicher�berwachers

Bild 4 HTML-Auswertung f�r Speicher- und CPU-Auslastung

Bild 5 Qualit�ts�berwacher

Reinhold Pl�sch, Rainer Weinreich

170

5 Konfigurationswerkzeuge

Ein wichtiger Aspekt von RSE ist dieM�glichkeit der Konfiguration des �ber-wachungssystems einer Anlage �ber Inter-netverbindungen. Dazu werden die in Bild7 und 8 dargestellten Werkzeuge verwen-det. DerMeasurement Manager dient zumAusl�sen, Stoppen und �berwachen vonMessungen. Das Werkzeug gibt einen�berblick �ber alle installierte Diagnose-agenten eines Automatisierungssystemsund visualisiert auch ihren aktuellen Sta-

tus. Die zu �berwachenden Anlagen wer-den in der Benutzerschnittstelle des Werk-zeugs durch den DNS-Namen des Gate-way-Rechners (UnitGateway) repr�sen-tiert.

DasWerkzeug f�r die Spezifikation vonBeziehungen zwischen �berwachungs-und Reaktionsagenten wird ConfigurationManager genannt und ist in Bild 8 dar-gestellt. Die im Hauptfenster dargestelltenAnlagen werden durch die DNS-Namender jeweiligen Gateway-Rechner repr�-sentiert (z. B. duck:500). Unterhalb der ei-ner Anlage sind die verf�gbaren Rechner

dargestellt und bei jedem Rechner die dortinstallierten �berwachungs- und Reakti-onsagenten.

Wenn ein �berwachungsagent aus-gew�hlt wird, k�nnen die Beziehungendieses Agenten zu den im Netzwerk vor-handenen Reaktionsagenten konfiguriertwerden. Das Werkzeug zeigt nur jene Re-aktionsagenten an, die auf eine Nachrichtdes selektieren �berwachungsagenten ent-sprechend reagieren k�nnen. In Bild 8 wer-den zwei E-Mail-Agenten mit einemAgenten f�r die Qualit�ts�berwachungverbunden.

Bild 6 E-Mail-Agent

Bild 7 Measurement Manager Bild 8 Configuration Manager

Ferndiagnose und -�berwachung von Automatisierungssystemen

171

6 Erfahrungen undgeplante Arbeiten

Unsere Erfahrungen mit dem RSE-Systembasieren auf dem Einsatz der Umgebung inTeststellungen bei unserem Kooperations-partner Siemens. Aus der Sicht der An-wendung wurden die gesteckten Ziele er-reicht. Zeitlich lang andauernde Messun-gen und �berwachungsaufgaben k�nnenohne Verbindung zur Administrationssta-tion durchgef�hrt werden, die Reaktionauf Systemereignisse ist flexibel �ber dasInternet konfigurierbar, und Messergeb-nisse k�nnen zu jeder Zeit (d. h. auch Zwi-schenergebnisse w�hrend der Messung)ausgewertet und visualisiert werden.

Aus softwaretechnischer Sicht ergebensich durch den Einsatz von mobilen Agen-ten eine Reihe von Vorteilen. Ein wesentli-cher Vorteil ist, dass bei den zu �ber-wachenden Systemen nur eine minimaleInfrastruktur (in Form eines Agentenser-vers) vorhanden sein muss, damit beliebigeDiagnose- und �berwachungskomponen-ten installiert werden k�nnen. �ber-wachungs- und Diagnoseaufgaben k�nnensomit leichter realisiert werden, da bei denzu �berwachenden oder zu diagnostizie-renden Einheiten keine Rekonfigurationerforderlich ist. Die Agenten unseres Sys-tems installieren sich selbst und sorgen ge-gebenenfalls auch f�r die Installation vonzus�tzlichem plattformspezifischemCode.Die Entwicklung neuer Agenten wirddurch die Verwendung unseres Systemseinfacher, da große Teile der Komplexit�t,die mit Verteilung und Codemobilit�t ver-bunden sind, vom RSE-Framework �ber-nommen werden. Entwickler von Agentenk�nnen sich daher in erster Linie auf dieRealisierung der funktionalen Anforde-rungen konzentrieren.

Eine Administrationsstation muss inder derzeitigen Implementierung �ber ei-nenAgentenserver verf�gen. Es w�re w�n-schenswert, die Administration von Agen-ten auch auf sehr leichtgewichtigen Admi-nistrationsstationen zu erm�glichen. Ge-meint sind damit Administrationsstatio-nen, bei denen in der Regel nur ein Inter-netbrowser als Infrastruktur zur Ver-f�gung steht.

Dar�ber hinaus bestehen in der derzei-tigen Implementierung noch Abh�ngigkei-ten zur Agentenplattform Aglets. Ein Aus-tausch dieser Agentenplattform durch einanderes Agentensystem ist zurzeit noch

mit erheblichem Portierungsaufwand ver-bunden.

Die Konfiguration von Agenten erfolgtin der Regel �ber eine grafische Benutzer-schnittstelle. Der Bau dieser Konfigurati-onsschnittstellen ist zeitaufw�ndig undsollte vereinfacht und beschleunigt wer-den. Die Fehlersuche gestaltet sich zurzeitebenfalls schwierig, da das Debugging vonmobilen Codesystemen von klassischenEntwicklungsumgebungen nicht unter-st�tzt wird.

Ausgehend von den gewonnenen Er-fahrungen durch den Einsatz von RSEkonzentrieren wir uns in den aktuellen Ar-beiten vor allem darauf, Administrations-aufgaben von Agenten auf leichtgewichti-gen Arbeitsstationen zu erm�glichen. F�rdiesen Zweck muss u. a. eine Kommunika-tionsinfrastruktur geschaffen werden, dieausgehend von einem Web-Klienten bishin zum Agenten die entsprechenden Pro-tokollumsetzungen von einem allgemeinunterst�tzten Protokoll (z. B. http) zu ei-nem agentenspezifischem Protokoll (z. B.atp beiAglets) vornimmt.

Diese Architektur erfordert auch dieBer�cksichtigung der damit verbundenenSicherheitsprobleme. Es m�ssen nicht nurKommunikationsverbindungen abge-sichert, sondern auch Authentifizierungund Autorisierung unterst�tzt werden. Ei-ne serverseitige Authentifizierung reichtnicht aus, da gerade bei der Fernadminis-tration einer Anlage auch die Authentizit�tdes Benutzers der Administrationsschnitt-stelle sichergestellt werden muss. Die�berpr�fung von Benutzerrechten unddas Aufzeichnen (Logging) von Adminis-trationst�tigkeiten sind wesentliche Be-standteile eines Autorisierungskonzeptesf�r das Agentensystem.

Ein weiteres Ziel ist es, die Abh�ngig-keit zur Agentenplattform Aglets zu redu-zieren, indem eine allgemeine Schnittstellezu Agentensystemen mit einem �hnlichenProgrammiermodell eingezogen wird.Durch diese Abstraktionsschicht (AgentAbstraction Layer) soll der Portierungs-aufwand, d. h. die Adaptierung von RSEf�r eine neue Agentenplattform, reduziertwerden.

Neben dieser grundlegenden �nderungder Architektur arbeiten wir auch an ei-nem Framework f�r die automatische Ge-nerierung der grafischen Benutzerschnitt-stelle f�r die Konfiguration von Agenten.

7 Zusammenfassungund Ausblick

RSE ist ein in Java realisiertes agentenba-siertes System f�r die Ferndiagnose und�berwachung von Automatisierungsanla-gen. Das System stellt Werkzeuge und vor-definierte Diagnose- und �berwachungs-agenten f�r diese Aufgabe zur Verf�gung,vor allem aber Frameworks, die die Ent-wicklung neuer Agenten wesentlich er-leichtern. Obwohl das System urspr�ng-lich f�r die �berwachung von Prozess-automatisierungsanlagen in der Stahl-industrie entwickelt wurde, ist es auch f�rdie �berwachung anderer Systeme mit�hnlichen Anforderungen einsetzbar. Einzu �berwachendes System besteht aus derSicht von RSE lediglich aus einer Reihevon Rechnern in einem Netzwerkverbundmit zu �berwachenden Ressourcen.

Das ist jedoch zugleich auch eine derwesentlichen Einschr�nkungen des Sys-tems, zumindest aus der Sicht eines all-gemeinen Einsatzes von Agententechnolo-gie. Denn ein Paradebeispiel f�r den Ein-satz von Softwareagenten ist der BereichE-Commerce, wo Agenten oft als relativautonom handelnde Softwareprogrammegesehen werden, die sich in einem sehr of-fenen System aufMarktpl�tzen treffen undim Namen bestimmter Personen Gesch�f-te t�tigen [ChMa96; MoGM98]. Eine vonRSE unterst�tzte Verwaltungseinheit(Unit) ist aus dieser Sicht ein relativ ge-schlossenes System mit klar definiertenund abgesicherten Internet-basierten Ver-bindungen zu Administrationseinheiten.Trotzdem hoffen wir gezeigt zu haben,dass Agententechnologie in einem relativgeschlossenen, aber sehr dynamischen Sys-tem nicht nur ihre Berechtigung hat, son-dern auch entscheidende Vorteile bringt.

Literatur

[CaLZ98]Cabri, G.; Leonardi, L.; Zambonelli, F.:Mobile Agent Technology: Current Trendsand Perspectives. In: AICA ‘98, Neapel, Ita-lien, November 1998.

[ChMa96] Chavez, A.; Maes, P.: Kasbah – Anagent marketplace for buying and sellinggoods. In: First International Conference onthe Practical Application of Intelligent AgentsandMulti-Agent Technology. London 1996.

[FrGr96] Franklin, S.; Graesser, A.: Is it an Agent,or Just a Program? – A Taxonomy for Auto-

Reinhold Pl�sch, Rainer Weinreich

172

nomous Agents. In: Third International Work-shop on Agent Theories, Architectures, andLanguages. Springer-Verlag, 1996.

[IBM00] IBM: Homepage f�r das Aglets-Projektam Forschungslabor der IBM in Japan.http://www.trl.ibm.co.jp/aglets/#h1_s0, Abrufam 2000-11-14.

[IsHa99] Ismail, L.; Hagimont, D.:A Performan-ce Evaluation of the Mobile Agent Paradigm.In: OOPSLA ‘99, 1999, S. 306–313.

[KaLO97]Karjoth, G.; Lange, D.B.; Oshima, M.:A Security Model for Aglets. In: IEEE InternetComputing 1 (1997) 4.

[LaOs98] Lange, D.B.; Oshima, M.: Program-ming and Deploying Java Mobile Agents with

Aglets. Addison-Wesley Longman, Reading1998.

[LaOs99] Lange, D.B.; Oshima, M.: Seven GoodReasons for Mobile Agents. In: Communicati-ons of the ACM 42 (1999) 3, S. 88–89.

[MoGM98] Moukas, A.; Guttman, R.; Maes, P.:Agent-mediated Electronic Commerce – AnMIT Media Laboratory Perspective. In: FirstInternational Conference on Electronic Com-merce (ICEC ‘98), Seoul, Korea 1998.

[OMG97] Object Management Group: MobileAgent System Interoperability Specification.OMG TC Document orbos/97-10-5, Novem-ber 1997.

[StSc97] Straßer, M.; Schwehm, M.:A Performan-ceModel for Mobile Agent Systems. In: Distri-buted Processing Techniques andApplications,DPPTA ‘97, Volume II. Las Vegas 1997, S.1132–1140.

[Sun00] Sun Microsystems: Informationen �berJava Releases und Online Dokumentation un-ter http://java.sun.com, Abruf am 2000-11-14.

[Whit97]White, J.:Mobile Agents. In: Bradshaw,J. (Hrsg.): Software Agents. MIT Press, 1997, S.437–472.

Ferndiagnose und -�berwachung von Automatisierungssystemen

173