IQEM:   Integrated Quality and
Environmental Management

EUREKA EUROENVIRON
E! 1892   (endorsed April '98)

 

Integrated Quality and Environmental Management System

Eureka EU-1892 IQEM

 

Förderungsübereinkommen:

Zl. 800712/4063

 

Endbericht

Januar - Dezember 1999

 

Environmental Sofware & Services GmbH

Kalkgewerk 1 A-2352 Gumpoldskirchen

http://www.ess.co.at

 

Table of Contents

Integrated Quality and Environmental Management System: Eureka EU-1892 IQEM *

Festlegung der IQEM Gesamtarchitektur, der Schnittstellen und externen Datenformate in Zusammenarbeit mit Chiron, Dokumentation. *

Definition der Klassenhierarchie, Objektstrukturen und Datenformate *

Entwicklung der Regel, ACTION und Descriptor Syntax - Erweiterungen für den forward chaining Teil des Expertensystems (XPS) *

ACTION Syntax: *

RULE Syntax (forward chaining): *

DESCRIPTOR Syntax: *

Syntax Prüfung *

Implementierung der Regelabarbeitung *

Integration einer allgemeinen Funktionsschnittstelle
(für 0-5D Datenstrukturen, GIS)
*

Festlegung der Java client Funktionalität (Benutzerschnittstelle) *

Entwicklung der Java Klassen *

Implementierung des Java clients *

Anbindung an den XPS server *

RTXPS Implementierungsbeispiele: *

 

Integrated Quality and Environmental Management System: Eureka EU-1892 IQEM

Der Arbeitsfortschritt für das erste Jahr des Projekts hat sich neben der gemeinsam mit dem portugiesischem Partner entwickelten Definition und Festlegung der Gesamtstruktur des Systems und seiner Architektur in erster Linie auf die Entwicklung mehrerer Komponenten konzentriert, die die Grundlagen für erste Prototypen integrierter Komponenten bilden konnten.

Diese Testapplikationen wurden in den Bereichen Umweltverträglichkeitsprüfung, betriebliches Umweltmanagement, und Sicherheitsmanagement (nach 96/82/EG) bzw. die Erstellung von Sicherheitsberichten für gefahrengeneigte Anlagen (ÖNORM A9030) entwickelt.

Der Arbeitsplan für das erste Jahr hat folgende Komponenten vorgesehen:

  1. Festlegung der IQEM Gesamtarchitektur, der Schnittstellen und der wesentlichen externen Datenformate in Zusammenarbeit mit Chiron, Dokumentation.
  2. Definition der Klassenhierarchie, Objektstrukturen und Datenformate
  3. Entwicklung der Regel, ACTION und Descriptor Syntax, Erweiterungen für den forward chaining Teil des Expertensystems (XPS)
  4. Implementierung der KB parser, Werkzeuge zur Syntax Überprüfung und zum Editieren der Wissensbasis
  5. Implementierung der Regelabarbeitung (forward chaining)
  6. Integration einer allgemeinen Funktionsschnittstelle
    (für 0-5D Datenstrukturen, GIS)
  7. Festlegung der Java client Funktionalität (Benutzerschnittstelle)
  8. Entwicklung der Java Klassen
  9. Implementierung des Java clients
  10. Anbindung an den XPS server

Als wesentliche Veränderung gegenüber dem ursprünglichen Plan wurde dabei die vorgesehene Java Entwicklung weitgehend hintangestellt und durch entsprechende Entwicklung und Implementierung in HTML FORMS und cgi server Funktionen ersetzt. Der Hauptgrund sind die aus ersten Experimenten erkennbare vergleichsweise schlechte Performance, sowie zahlreiche Inkompatibilitäten und Einschränkungen bei der Verwendung von Java. Diese sollten aber mit der weiteren Entwicklung und Stabilisierung der Java Werkzeuge und Entwicklungsumgebung sowie auch einer weiter standardisierten Unterstützung von Java Applets durch die gebräuchlichsten Browser Netscape und Internet Explorer im Laufe der Zeit abnehmen.

Geringfügige Probleme haben sich lediglich in der Koordination mit dem portugiesischen Partner ergeben, die in einigen Fällen zu unwesentlichen Verzögerungen beim Projektablauf geführt haben. Ingesamt aber ist die Kooperation mit Chiron als positiv zu beurteilen.

Parallel zu den laufenden Arbeiten in IQEM wurden die Grundideen und erste Komponenten des Projekts im Planungs- und Frühstadium der Entwicklung als Ausgangsbasis für den IST Projektantrag A-TEAM (Advanced Technical Training for Emergency Assessment and Management) im fünften Rahmenprogramm verwendet.

Das von der EU bewilligte Forschungs- und Entwicklungsprojekt A-TEAM (Projektbeginn mit 1. Februar 2000, http://www.ess.co.at/A-TEAM) kann damit auf den Ergebnissen des ersten Entwicklungsjahres von IQEM aufbauen und erlaubt die Weiterführung der in IQEM begonnenen Arbeiten mit EU Mitteln. Chiron als EURKA EU-1892 Partner ist auch Projektteilnehmer in A-TEAM.

Die Ergebnisse, und zwar in erster Linie in Form von Softwarekomponenten, wurden in das von ESS vermarktete Informations- und Entscheidungshilfesystem RiskWare (http://www.ess.co.at/RISK) integriert. Erste Präsentationen bei der chemischen Indutrie, Behörden, und den Feuerwehren haben vielversprechende Resultate gezeigt.

 

Für das erste Projektjahr sind folgende Ergebnisse zu berichten:

Festlegung der IQEM Gesamtarchitektur, der Schnittstellen und externen Datenformate in Zusammenarbeit mit Chiron, Dokumentation.

Die Gesamtarchitektur wurde definiert und in einem Architekturdokument festgeschrieben; Details zu den Schnittstellen, insbesondere der Daten- bankanbindungen des Expertensystems, sind weiterhin mit Chiron in Diskussion.

Dabei wurde grundsätzlich eine modulare client-server Architektur festgelegt, bei der der Datenbank (ORACLE) eine wesentliche Integrationsfunktion zukommt. Durch die Verwendung von ODBC Formaten zum Datenimport bzw. ORACLE Developer 2000 Forms als plattformunabhängiges Werkzeug zum Editieren können PC basierte Applikationen, Web basierte Applikationen, und X11/Motif basierte Applikationen einfach kombiniert werden.

 

Definition der Klassenhierarchie, Objektstrukturen und Datenformate

Strukturdefinitionen für die zentralen Komponenten wurden festgelegt und eine Datenbeschreibungssprache entwickelt. Diese verwendet TEMPLATES im ASCII Format um die Verbindung zwischen Datenbank und Expertensystem herzustellen. Die dazugehörigen Objekte werden über Methoden instantiiert, wobei die Defaultmethode das Laden aus der Datenbank darstellt. Alternativen sind das Laden der Daten aus einfachen Dateien, oder allgemeine METHODEN, die auch direkt auf das http Protokoll zugreifen können und damit Daten über das Internet/Intranet (GET und POST requests) laden können.

Beliebige Alternativen und Ergänzungen sind über die TEMPLATES definierbar, wobei auf eine offene Architektur mit einfachen Erweiterungsmöglichkeiten nach dem Vorbild von HTML/XML Wert gelegt wurde.

Das Beispiel zeigt die Deklaration eines TEMPLATES für die Objektklasse Sicherheitsbericht dessen Daten zum Teil aus der ORACLE RDBMS dynamisch initialisiert werden können.


INSTANTIATE from dyn_oracle:IQEMDEMO

NA Sample Chemical Storage 1 # object name

ID SITE1 # unique ID

ME Meta Information 1 # meta information 1

ME Meta Information 2 # ...

ME Meta Information n #meta information n

AU kurt Tue Mar 28 12:45:55 2000 #autom. inserted

GX 1566613 # latitude / reference X

GY 5058113 # longitude/ reference Y

EL 25.5 # masl

HY demo.exp

 

TABLE

input_sets

E method

E data_table

E default_prefix

D widget content s_report.widget

D disp_hypertext content s_report.htext

D disp_properties descriptors s_report.descr_list

D disp_map global_map s_report.global_map

END_TABLE

 

TABLE

content

E type

E value

D TITLE Safety_report.92

D HYtitle report.21

D HYfile report2000.html

D EXtitle report.21

D EXfile report.21

END_TABLE

 

TABLE

global_map

E type

E value

D x 755725

D y 330688

D extent 2000

D index 1

D scale on

END_TABLE

 

TABLE

descriptors

E name

E value

E method

D Version 1.3_Februar_2000 ask_box

D Sachbearbeiter DI_Dr._Meier ask_box

D Telefon 02252_633_059 ask_box

D Abgabetermin 28.02.2000 ask_box

D Letzte_Revision 28.02.2000 ask_box

D Landesdienstelle NÖ_LR ask_box

D Abteilung MB_ET ask_box

D Bearbeiter Dr._Winkler ask_box

D Kontakt 02742 200 4398 ask_box

D Seveso_class yes ask_box

D Total_area 4.5 ask_box

D Permanent_staff 180 ask_box

D Fire_fighters 8 ask_box

D Monitoring_sensors 12 ask_box

END_TABLE


 

 

 

Darstellung der Objektklasse Sicherheitsbericht

 

Entwicklung der Regel, ACTION und Descriptor Syntax - Erweiterungen für den forward chaining Teil des Expertensystems (XPS)

Neben den Objektklassen (Project, Document, Activity) wurde die Syntax der zentralen Objekte Descriptor, Rule, ACTION festgelegt. Ausgehend vom Expertensystem Shell XPS wurden zwei wesentliche Erweiterungen eingeführt:

  • die backward-chaining Strategie von XPS wurde in eine forward-chaining Strategie eingebettet, die Regelsyntax entsprechend erweitert (RTXPS Rules)
  • das neue Hybridsystem wurde um Echtzeitkomponenten erweitert (Real-Time XPS: RTXPS). Dazu wurden folgende Komponenten entwickelt

  • das Konzept pending, als Status einer ACTION, d.h., eine im Ablauf notwendige Aktion kann übersprungen werden und wird zu einem späteren Zeitpunkt wieder zur Bearbeitung angeboten;
  • das Konzept timer, das explizit im Regelablauf gesetzt und abgefragt werden kann.

ACTION Syntax:

ACTIONS beinhalten zwei wesentliche Komponenten:

  • den Hypertext Teil (in HTML Format) der die Instruktionen and den Benutzer sowie Hintergundinformation beinhaltet;
  • den FUNCTION Teil der von der Regel ausgelöste Funktionen beschreibt.

 


###### generic ACTIONS:

ACTION

Zero_Action

TI Start_des_Sicherheitsmanagementsystems

A start

V ready / pending / ignored / failed / done /

Q <HTML>

Q <H1> <FONT COLOR=RED>

Q Sicherheitsmanagementsystem </FONT></H1>

Q nach 96/82/EG, Art. 9 und Annex II

Q <P>

Q Folgende Punkte werden durch das <B>Sicherheitsmanagementsystem</B>

Q geregelt: <BR><BR>

Q <OL>

Q <LI> Organisation und Personal

Q <LI> Ermittlung und Bewertung der Risiken

Q schwerer Unf&auml;lle

Q <LI> Betriebskontrolle

Q <LI> Sichere Durchf&uuml;hrung von &Auml;nderungen

Q <LI> Planung f&uuml;r Notf&auml;lle

Q <LI> Qualit&auml;tssicherung

Q <LI> Kontrolle und Analyse

Q </OL>

Q <P>

Q <TABLE WIDTH=610 BORDER=1 CELLPADDING=6 BGCOLOR=RED>

Q Folgen Sie bitte den Anweisungen in diesem Dialogfenster

Q <BR>

Q und starten Sie das System mit dem <TT>DONE</TT> Button.

Q </TABLE>

ENDACTION


RULE Syntax (forward chaining):

Die forward-chaining Regeln von RTXPS entsprechen in ihrer Syntax weitgehendst den backward-chaining Regeln des ursprünglichen XPS Systems, mit der wesentlichen Erweiterung, dass der THEN Teil die Attribute einer ACTION auf AUSFÜHREN ( => ready) setzt.

 


###### Forward chaining rules:

RULE 00001

IF ACTION(Zero_Action) == done

THEN ACTION(Step_1) => ready

ENDRULE

 

RULE 000010

IF DESCRIPTOR(Fire_Prob) > 0

OR [ ACTION(run_BLAST) == done

AND DESCRIPTOR(fuel_mass) > 0 ]

THEN ACTION(run_FIRE) => ready

ENDRULE


DESCRIPTOR Syntax:

Descriptoren sind die im Expertensystem verarbeiteten Variablen. Die Definition beinhaltet neben Name, Typ, und einem optionalen internen Alias die Masseinheit, den zulässigen Wertebereich, die Methoden der Instantiierung oder Ableitung (Regelreferenzen), und den Fragetext für direktes Editieren durch den Benutzer (in HTML Format).


###### Descriptor Definitions:

DESCRIPTOR

fuel_mass

A Fuel

T S

U kg

V none [ 0, 0, 0] /

V extremely_small [ 0, 10, 20] /

V small [ 20, 100, 200] /

V medium [ 200, 1000, 2000] /

V large [ 2000, 10000, 20000] /

V very_large [20000, 50000,100000] /

R 3007 / 30071 /

Q <HTML>

Q <H1>Total fuel involved in the fire</H1>

Q What is the total amount of flammable substance involved?

Q This is the difference of the total mass available

Q minus any fraction evaporated or infiltrated.

LAYOUT

FORMAT %8.1f

ENDLAYOUT

ENDDESCRIPTOR


Die drei zentralen Objektklassen Descriptor, Rule, ACTION, sind eng miteinander verknüpft. Um ein effizientes Abarbeiten der Regeln zu erlauben, und auch die Inferenzstrategie der backward-chaining Regeln einfach integrieren zu können, sind zahlreiche symbolische Referenzen erforderlich, die dynamisch beim Einlesen (parsen) der Wissensbasis gebildet werden.

Zur vollen Integration der Wissensbasis in die Datenbank wurden erste Versuche mit der Descriptorklasse durchgeführt: Descriptoren können in ORACLE abgelegt werden, und mit in Developer 2000 implementierten Masken (Forms) editiert werden. Die Descriptor Definitionen werden dann direkt aus der Datenbank in die Wissensbasis geladen.

Um das Entwickeln und Editieren der Wissensbasis zu erleichtern, wurden mehrere Hilfswerkzeuge, insbesondere zur Überprüfung der Syntax, Konsistenz, and Vollständigkeit der Abhängigkeiten entwickelt.

Diese Werkzeuge erlauben es, komplexe und hierarchisch strukturierte Wissenbasen zu entwicklen die generische Komponenten bibliotheksartig mehreren Applikationen gleichzeitig zur Verfügung stellen und die mit applikationsspezifischen Komponenten flexibel kombiniert werden können.

 

Syntax Prüfung

RTXPS wurde als Test- und Entwicklungsumgebung implementiert, die Parser Funktionen implementiert bzw. für die neue Funktionaliät erweitert, und erste Werkzeuge zur Syntaxprüfung der Wissensbasis entwickelt. Das Kbchecker Werkzeug zur Syntaxprüfung wurde mit einer HTML/FORMS Schnittstelle als Intranetapplikation konzipiert und implementiert.

 

Implementierung der Regelabarbeitung

Für die oben angeführten Entwicklungen wurde die notwendige Regelabarbeitung implementiert und ein funktionsfähiger Prototyp von RTXPS erstellt. Die Regeln sind mit einfacher Syntax in ASCII text Dateien abgelegt (siehe Regelsyntax).

Zur Syntaxprüfung von komplexen Reglbasen und den dazugehörigen Variablen (Descriptor) Definitionen wurden eigene Werkzeuge entwickelt. Diese sind mit einer Benutzerschnittstelle in HTML ebenfalls über einen Internet Browser nutzbar (siehe oben)

Integration einer allgemeinen Funktionsschnittstelle
(für 0-5D Datenstrukturen, GIS)

Zur Integration des Expertensystems mit externen Funktionen (Datenanalyse, Darstellung, GIS-Anbindung, Modellschnittstelle) wurde eine allgemeine, vollständig datengesteuerte Funktionsschnittstelle als Erweiterung der ACTION Syntax entwickelt. Die Funktionsparameter werden dabei über die dynamische Wissensbasis des Expertensystems übergeben (Attribute der Objektklassen).

Die zur Zeit in den ACTIONs unterstützten Funktionen sind:

clear_descriptor_value(DESCRIPTOR_ID)

Löscht den Wert eines Descriptors in der Wissensbasis; der Wert wird auf UNKNOWN gesetzt und damit wieder zum potentiellen Target von Regeln.

 

close_html()

Schliesst den externen HTML Browser (siehe auch: display_html).

 

display_chemical(CHEMICAL_ID)

Lädt die Daten einer Chemikalien aus der Datenbank und stellt sie dar, in einer Kombination von Descriptorliste und Hypertext (HTML oder internes Hypertext Format, wird vom Dateinamen bzw. einem <HTML> tag im File selbst gesteuert) für die MSDS Inhalte.

 

display_html(URL)

Lädt eine Hypertext Seite über ihr URL und stellt sie im HTML browser dar (siehe auch: close_hypertext); der Browser ersetzt btw. überlagert die Kartendarstellung des GIS und der darunterliegenden Legende.

 

display_hypertext(URL)

Analog für internes und HTML Format, der Browser ist aber als pop-up über die jeweilige Applikation gelagert und muss interaktiv geschlossen werden; dient insbesondere zur Darstellung von Hilfs- und Erklärungstexten bzw. obligatorischen Meta Daten.

 

display_msds(CHEMICAL_ID,SECTION_ID)

Darstellung (im Hypertext Browser abhängig vom Dateinamen bzw. dem <HTML> Tag im File selbst) eines der 16 (nach EU/ISO Standard) Kapitel eines MSDS (Material Data Safety Sheet).

 

display_object(OBJECT_ID)

Laden und Darstellung eines beliebigen Objekts als pop-up Fenster.

 

draw_concentration()

Stellt das Ergebniss der letzen Modellrechnung im GIS Fenster als Overlay (zB der Konzentration) dar.

 

draw_truck()

Darstellung eine Fahrzeugobjektes mit seiner Descriptoren Liste inklusive seiner Postionierung auf der Karte (für die Analyse von Transportunfällen).

 

execute_rt_rule(RULE_ID)

Erlaubt das Abarbeiten einer RT (forward chaining) Regel aus einer ACTION; damit können Regelschleifen programmiert werden.

 

execute_rule(RULE_ID)

Erlaubt das Abarbeiten von XPS (backward chaining) Regeln innerhalb einer ACTION; damit kann deren Kontext bzw. der Kontext für weitere FUNCTIONs verändert bzw. aktualisiert werden.

 

export(DESCRIPTOR)

Schreibt den Wert des Descriptors in eine Datei mit dem Namen des Descriptors (eingeschränkt auf die ersten 14 Zeichen des Namens); die Datei wird in einem über Konfigurationsdaten festgelegten Verzeichnis erstellt.

 

Get_descriptor_value(DECSRIPTOR_ID)

Started die Editier Funktion bzw. in der Descriptordefinition implizierte Methoden wie Regeln, um den Wert des Descriptors interaktiv festzusetzen.

 

Get_highway_km

Konvertiert GPS Koordinaten (Descriptor Werte) in Strassenkilometer Werte (setzt den Dsecriptorwert für higway_km).

Get_location_by_name

Sucht das nächstgelegene Orts Objekt für ein Koordinatenpaar und setzt den Descriptor Object_Name.

 

get_truck_data

Datenbankschnittstellenbeispiel: lädt die Werte einer Frachtdatenbank für ein Strassenfahrzeug.

load_chemical(Chemical_Name)

Initialisiert alle Descriptoren einer Chemikalie mit den Werten der im Descriptor Chemical_Name ausgewählten Substanz.

 

load_CIS

Datenbankschnittstellenbeispiel: lädt die Werte einer Frachtdatenbank (Cargo Information System) für ein Schienenfahrzeug.

 

preview

Stellt ein automatisch generiertes Fax (siehe auch: export) im Hypertext Browser zur Voransicht dar.

 

run_BLAST

Started das Explosionmodell BLAST für die Sicherheitsanalyse; lädt die erforderlichen Modellparameter aus den Wissenbasis und startet den interaktiven Descriptor Editor für alle fehlenden Werte.

 

run_FIRE

Started das Feuermodell FIRE für die Sicherheitsanalyse; lädt die erforderlichen Modellparameter aus der Wissenbasis und startet den interaktiven Descriptor Editor für alle fehlenden Werte.

 

run_GW

Started das Explosionmodell BLAST für die Sicherheitsanalyse; lädt die erforderlichen Modellparameter aus den Wissenbasis und startet den interaktiven Descriptor Editor für alle fehlenden Werte.

 

run_MS

Started die empirische Metodo Speditivo für die Sicherheitsanalyse; lädt die erforderlichen Modellparameter aus den Wissenbasis und startet den interaktiven Descriptor Editor für alle fehlenden Werte.

 

run_PUFF

Started das Ausbreitungsmodell PUFF für die Sicherheitsanalyse; lädt die erforderlichen Modellparameter aus den Wissenbasis und startet den interaktiven Descriptor Editor für alle fehlenden Werte.

 

run_SOURCE

Started das Austrittsmodell SOURCE für die Sicherheitsanalyse; lädt die erforderlichen Modellparameter aus den Wissenbasis und startet den interaktiven Descriptor Editor für alle fehlenden Werte.

 

set_descriptor_value(DESCRIPTOR_ID,VALUE)

Setzt den Wert des Descriptors DESCRIPTOR_ID auf VALUE

 

set_wind_dir

Started den automatischen Download von meteorologischen Daten über eine http Verbindung; das entsprechende URL und Datenformat ist in den Konfigurationsdateien festgelegt; bei Nichtzustandekommen einer Verbindung können die erfordlerichen Daten über eine interaktive graphische Schnittstelle von Hand eingegeben werden.

 

shell(COMMAND)

Der String COMMAND wird über das System Shell (/bin/csh) abgearbeitet.

 

start_assessment

Bringt das System vom RTXPS real-time modus in the Assessment Modus zur Szenario Analyse

 

system(COMMAND)

Der String COMMAND wird mit der Systemfunktion system(COMMAND) abgearbeitet

 

Als Ergänzung dieser Funktionen wurde die Möglichkeit geschaffen einzelne Komponenten der Wissensbasis, die von einer FUNCTION initialisiert oder verändert wurden, in die Log-Datei des Expertensystems bzw. über eine geeignete Darstellungsfunktion (scroll window) direkt am Bildschirm als Teil der Ablaufdokumentation auszugeben .

Erste Beispiele zur Darstellung von Monitoringdaten (Zeitreihen) und deren räumlicher Interpolation als web-basiertes Werkzeug (cgi mit HTML/FORM Benutzerschnittstelle) wurden implementiert.

 

 

Zur weiteren Zusammenführung der X11 Version und der Internet Version wurde der integrierte HTML Browser über eine FUNCTION innerhalb der ACTION Syntax ansteuerbar gestaltet. Damit ist neben der Darstellung von Multimedia Inhalten innerhalb der Regelabarbeitung auch ein einfacher Export der dynamisch generierten HTML Dateien für einen Web Server als parallele Ausgabeform möglich.

Festlegung der Java client Funktionalität
(Benutzerschnittstelle)

Die Basisfunktionalität des Systems wurde festgelegt. Neben allgemeinen Basisfunktionen, die z.T. von ORACLE Werkzeugen direkt abgedeckt werden können, sind dies vor allem die Benutzerschnittstelle für das Expertensystem RTXPS und die über das Expertensystem gesteuerten client-server Funktionen (Datenanalyse und Darstellung, GIS, Modelle).

Entwicklung der Java Klassen

Siehe oben.

Implementierung des Java clients

Siehe oben.

Anbindung an den XPS server

Die Integration der client-server Komponenten mit dem RTXPS Server wurde in einem Prototyp mit X11 Schnittstelle verwirklicht. Dazu wurden mehrere Projektbeispiele (Umweltverträglichkeitsprüfung, betriebliches Umweltmanagement, Sicherheits-management und Sicherheitsbericht) erstellt, die nachfolgend dokumentiert sind.

 

 

RTXPS Implementierungsbeispiele:

Sicherheitsanalyse für einen gefahrengeneigten Betrieb; RTXPS stellt den Hypertext der ACTION im linken Fenster dar, das Betriebsobjekt im GIS im rechten Fenster. Echtzeit Uhr und Projektzeit werden über dem Dialogfenster dargestellt, die Log Dateien darunter.

 

 

 

RTXPS Implementierungsbeispiele:

RTXPS arbeitet anhand einer Prüfliste eine Sequenz von ACTIONs ab, die vom Benutzer Information abfragen; diese Daten können direkt eingegeben werden, oder aber von Regeln des Expertensystems abgeleitet werden.

 

 

RTXPS Implementierungsbeispiele:

Zu den Fragen des Expertensystem sind ergänzende und erklärende Texte im Hypertextformat HTML über den integrierten Browser darstellbar. Diese können entweder direkt aus der ACTION gesteuert, oder aber vom Benutzer bei Bedarf interaktiv aufgerufen werden.

 

 

RTXPS Implementierungsbeispiele:

Die in der ACTION dargestellten HTML Texte sind dynamisch, d.h. sie können auch variable Daten aus der Wissensbasis des System beinhalten, etwa um den Zwischenstand oder Ergebnisse der Untersuchung anzuzeigen. Diese Werte werden bei jedem Aufruf der Texte aktualisiert.

 

 

 

RTXPS Implementierungsbeispiele:

RTXPS unterstützt mehrere externe Kommunikationmöglichkeiten, unter anderem das Laden externer Daten (z.B. Mess- und Monitoringdaten) über http, also von Web-Servern mit GET oder POST Requests. Ein Beispiel sind meteorologische Daten, die für Modelle zur Risikoabschätzung verwendet werden (Ausbreitungsrechnung für toxische Substanzen).

 

 

RTXPS Implementierungsbeispiele:

RTXPS kann mehrere Simulationsmodelle direkt ansteuern.

Dabei werden die notwendigen Modellparameter, die ein Simulationsszenario beschreiben, entweder direkt aus der Wissenbasis geladen, aus Datein die in der Wissensbasis referenziert werden geladen, oder über komplexe Methoden (wie die Regelabarbeitung des Expertensystems) initialisiert.

 

Als default bzw. fall back Methode ist die direkte Eingabe durch den Anwender vorgesehen.

 

Modelle unterschiedlicher Komplexität liefern als Ergebniss wieder skalare bzw. symbolische Grössen, die in die Wisenbasis übernommen werden. Dazu werden aus den Modellergebnissen (Skalare Grössen, Vektoren, Matrizen, Tensoren) die entsprechenden Grössen über Regeln oder einfache Algorithmen (Aggregation, Beprobung) ermittlet, und in die jeweiligen Descriptoren kopiert. Sie stehen damit weiteren Modellen für ein kaskadenartiges Ablaufschema beliebiger und völlig datengesteuerter Komplextät zur Verfügung.

 

 

 

 

 

 

 

 

 

RTXPS Implementierungsbeispiele:

Integrationsbeispiel in RiskWare für die Erstellung eines Sicherheitsberichtes nach 96/82/EC (Seveso II).

 

 

 

RTXPS Implementierungsbeispiele:

Risikonalyse; der im rechten Bildabschnitt sichtbare Hypertext Browser wurde mit der integrierten Funktion display_html(URL) (siehe oben) implementiert.

Der HTML Hypertext kann dynamische Elemente die aus der aktuellen Wissenbasis initialisiert werden beinhalten.

 

 


Copyright 1995-2002 by:   ESS   Environmental Software and Services GmbH AUSTRIA