MP-WS13-03

Aus Verteilte Systeme - Wiki
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Einbettung des Projekts

Das Projekt "Modelle für Risk-Management" ist Teil der Forschungsarbeiten, die im Verteilte Systeme Labor zum Thema "Ontologiebasiertes IT-Management" durchgeführt werden. Beim ontologiebasierten IT-Management wird die im MAPE-K Loop enthaltene Wissensbasis zum Managen eines IT-Systems durch eine Ontologie ersetzt. Das Projekt hat das Ziel, die bestehenden Forschungsarbeiten um den Teilaspekt Risikomanagement zu erweitern.

Risiko und Risikomanagement

Ein Risiko ist eine nach Häufigkeit (Eintrittswahrscheinlichkeit) und Auswirkung (Schaden) bewertete Bedrohung eines zielorientierten Systems. Das Risiko betrachtet dabei stets die negative, unerwünschte und ungeplante Abweichung von System-Zielen und deren Folgen. (aus http://lexikon.stangl.eu/596/risiko/)

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle Risiko = Eintrittswahrscheinlichkeit (Fehler) \times Schaden (Fehler)}

Risikomanagement umfasst sämtliche Maßnahmen zur systematischen Erkennung, Analyse, Bewertung, Überwachung und Kontrolle von Risiken. (aus http://de.wikipedia.org/wiki/Risikomanagement)

Der Risikomanagement-Prozess gliedert sich nach ISO 31000 wie folgt:

  • Die Kommunikation und der Informationsaustausch betonen die Wichtigkeit, den Risikomanagement-Prozess mit den internen und externen Stakeholdern abzustimmen.
  • Der Kernprozess des Risikomanagements beginnt mit dem Erstellen des Zusammenhangs. Dazu gehört die Erarbeitung der Risikokriterien, an denen das Risiko eingestuft und bewertet wird. Die Risikobeurteilung umfasst die Identifikation der Risiken (mit Ursachen und Auswirkungen), die Risikoanalyse (Verständnis der Risiken), die Risikobewertung (Tragbarkeit von Risiken) und die Risikobewältigung.
  • Die Überwachung und Überprüfung der Risiken stellen sicher, dass das Risikomanagement wirksam ist. (aus http://www.qm-aktuell.de/downloads/mq_05_08_s26-27_v.pdf)

Projektziel

Ziel des Projektes ist der Entwurf eines ontologiebasierten Risiko-Modells zur fortwährenden Einschätzung möglicher Risiken eines produktiven IT-Systems.

Das Wissen über das Managed System ist in einer Ontologie, der sogenannten System-Ontologie, repräsentiert. Diese soll mit Hilfe einer Domänenspezifischen Sprache mit dem Wissen aus einer Risiko-Ontologie, die Risikoaspekte betrachtet, verknüpft werden. Aus dieser Verknüpfung soll eine kombinierte Ontologie folgen, die sowohl System- als auch Risikowissen enthält. Diese Risiko-System-Ontologie soll es ermöglichen das System, unter Berücksichtigung von Risikoaspekten, zu managen.

Für das Masterprojekt ergeben sich daraus folgende Teilaufgaben:

  • Analyse und Bewertung bestehender Risikoverfahren
  • Modellierung ausgewählter Verfahren als Ontologie
  • Erstellung einer DSL zur Instanziierung der Ontologie
    • Definition der Syntax der DSL
    • Implementierung der Instanzengenerierung
Projektziele im Überblick

Analyse bestehender Verfahren zur Risikoanalyse

Fehlermöglichkeits- und Einflussanalyse

Die Fehlermöglichkeits- und Einflussanalyse(engl. Failure Mode and Effects Analysis kurz FMEA) ist ein analytisches Verfahren aus dem Qualitätsmanagement. Ziel der FMEA ist es potenzielle Fehlerquellen eines Produktes frühzeitig zu erkennen und zu bewerten. Entwickelt wurde FMEA in den 60er Jahren von der NASA, wo es zur Risikoanalyse des Apollo-Projekts eingesetzt wurde. Später wurde das Verfahren vor allem von der Luftfahrt und Automobilindustrie sowie für die Risikobewertung von Atomkraftwerken übernommen. Seit den 80er Jahren gibt es in Deutschland normierte Versionen der FMEA, die von der DIN bzw. der VDA herausgegeben werden. Heute ist FMEA in der Industrie weit verbreitet und an die Bedürfnisse der einzelnen Branchen angepasst. So gibt es beispielsweise eine Modifikation für die Lebensmittelbranche, deren Anforderungen sich stark von den ursprünglichen Einsatzgebieten der FMEA unterscheiden.

Durch den Einsatz einer FMEA können potenzielle Fehler eines Produkts zu einem sehr frühen Zeitpunk erkannt und vermieden werden. Im optimalen Fall wird mit der FMEA schon vor Beginn der Konstruktion des Produktes begonnen, denn so lässt sich der Produktionsprozess selbst mit einbeziehen. Im Rahmen einer FMEA identifiziert ein Expertenteam systematisch mögliche Fehler eines Produkts. Für jeden identifizierten Fehler werden dessen Ursachen und Auswirkungen protokolliert. Zusätzlich werden, wenn möglich Maßnahmen erarbeitet, die im Fehlerfall zu ergreifen sind, um den Fehler zu beheben oder abzuschwächen. Bei dieser Vorgehensweise wird nicht der komplette Ausfall des Systems betrachtet, sondern Fehler bzw. Ausfälle einzelner Komponenten eines Produktes oder Prozesses.

Die zentrale Idee der FMEA ist es, bereits beim Design eines Produkts potenzielle Fehler, die eine einwandfreie Funktion gefährden könnten, systematisch aufzudecken und zu vermeiden. Durch die systematische Vorgehensweise soll die Effizienz der Qualitätssicherung erhöht werden. FMEA dient demnach nicht nur der Qualitätssicherung eines Produktes, sondern macht diese auch effizienter und wirtschaftlicher. Diesem Ziel lassen sich die folgenden Teilziele unterordnen:

  • Kritische Komponenten des Produktes sowie kritische Komponenten innerhalb des Produktionsablauf sind zu identifizieren.
  • Auftretende Fehler sollten möglichst früh erkannt werden, um die geforderte Funktionalität des Produktes sicherzustellen.
  • Risiken sind abzuschätzen.
  • Änderungen an Produkt und Produktion nach beginn der Serienfertigung sind zu vermeiden.
  • Bestehendes Wissen soll in die FMEA einfließen. Neu entstandenes Wissen ist für eine Wiederverwendung zu konservieren.
  • Letztlich ist eine unternehmensweite, kontinuierliche Verbesserung der FMEA-Prozesse anzustreben.

Die Vorgenweise einer FMEA lässt sich in die vier Phasen Vorbereitung, Suchen, Bewerten und Umsetzen unterteilen.

  1. Im Rahmen der Vorbereitung sind die Untersuchungsinhalte der FMEA festzulegen. Die zu untersuchenden Objekte sind bezüglich ihres Aufbaus und ihrer Funktion zu beschreiben.
  2. Die Suche hat das Ziel mögliche Fehler aufzuspüren.
  3. Die gefundenen, möglichen Fehler werden mittels einer Risikoanalyse bewertet. Fehler, denen ein hohes Risiko zugesprochen wurde, werden mit Handlungsmaßnahmen zur Fehlervermeidung versehen.
  4. Die Umsetzung der Handlungsmaßnahmen, beginnt mit einer Zuordnung von personellen Verantwortlichkeiten und endet mit einer Überprüfung der Wirksamkeit. Es ist also festzustellen ob der Betreffende Fehler vermieden wird, oder zumindest dessen Risiko minimiert wurde.

Eine FMEA wird unter Zuhilfenahme sogenannter Form-Blätter, die meist unternehmensspezifisch angepasst sind, durchgeführt. Abbildung FMEA - Formblatt zeigt beispielhaftes Formblatt.

FMEA - Formblatt aus OntoFMEA S. 332 (Lars Uwe Dittmann)

Die Durchführung einer FMEA ist in fünf Schritte unterteilt und ist wie folgt vorzunehmen. Zunächst werden einzelne Systemelemente identifiziert. Aus der Menge der Systemelementen lässt sich eine Systemstruktur ableiten. Dieser erste Schritt wird als Systemanalyse bezeichnet. In einem zweitem Schritt, der Funktionsanalyse werden den Systemelementen die Funktionen, die sie anbieten zugeordnet. Hier lässt sich eine Funktionsstruktur ableiten. Nun folgt die Fehleranalyse. Hier sind Fehler zu identifizieren, die zuvor bestimmten Funktionen beeinträchtigen und so zu Fehlfunktionen führen. Aus der Menge der Fehlfunktionen folgt eine Fehlfunktionsstruktur. In der Strukturanalyse werden Vermeidungs- und Entdeckungsmaßnahmen erarbeitet und protokolliert. Das Risiko eines Fehlers wird unter Einbeziehung des entstehenden Schadens, der Auftretens- und Entdeckungswahrscheinlichkeit bestimmt. Der Vorgang, der das Risiko eines Fehler bestimmt, wird als Risikobewertung bezeichnet. In der Abschließenden Phase, der Optimierung werden Verbesserungsmaßnahmen erarbeitet und auf deren Grundlage eine neue Risikobewertung durchgeführt. Optimierung und Risikobewertung sind nun solange zu wiederholen bis die vorhanden Risiken ein vertretbares Maß unterschreiten. Abbildung FMEA Durchfuehrung zeigt eine schematische Darstellung der zu durchlaufenden Phasen einer FMEA.

FMEA Durchfuehrung nach OntoFMEA (Lars Uwe Dittmann)

Das bei der Risikobewertung ermittelte Risiko wird durch die Risikoprioritätszahl(RPZ) ausgedrückt. Sie ist das Produkt der Faktoren Auftreten, Bedeutung und Entdeckbarkeit. Diese Faktoren nehmen einen ganzzahligen Wert zwischen 1 und 10 an, sodass die RPZ einen ganzzahligen Wert zwischen 1 und 1000 annimmt. Auf diese Weise ist es möglich die Risiken zu ordnen. Eine hohe RPZ deutet auf eine hohes Risiko hin. Die Faktoren sind wie folgt zu interpretieren:

  • Auftreten - 1 = seltenes Auftreten bis 10 = häufiges Auftreten
  • Bedeutung - 1 = geringe Bedeutung bis 10 = hohe Bedeutung
  • Entdeckbarkeit - 1 = leicht zu entdecken bis 10 = schwer zu entdecken

Sowohl ein hohe RPZ als auch hohe Werte der einzelnen Faktoren weisen einen Handlungsbedarf auf.

Neben FMEA haben sich in der Industrie weitere Instrumente für das Risikomanagement etabliert. Zur Abgrenzung werden im folgenden drei weitere Vertreter vorgestellt.

Fehlermöglichkeits- und Einflussanalyse - Beispiel für eine webbasierte Foto-Community

Das folgende Beispiel zeigt die Vorgehensweise einer Fehlermöglichkeits- und Einflussanalyse im Detail. Untersucht wird eine fiktive Foto-Community, die ähnliche Funktionen wie Flickr bieten soll. Das System Foto-Community läßt sich in die folgenden Subsysteme unterteilen:

  • Web-Server
  • Application-Server
  • Search-Server
  • Cache-Server
  • Database-Server
  • File-Server

Diese Aufteilung ist nur eine von vielen möglichen Aufteilungen. In unserem Beispiel gehen wir davon aus, dass alle Server auf einer eigenen Hardware laufen, weshalb das System entsprechend unterteilt ist. Zwischen den einzelnen Subsystemen bestehen Schnittstellen. So greift z.B. der Web-Server auf die Funktionalität des File-Servers zu, wenn er ein angefordertes Bild ausliefert. Die folgende Grafik zeigt die Architektur der Foto-Community. Schnittstellen sind durch schwarze Linien zwischen den Subsystemen dargestellt.

Architektur der Foto-Community)


Strukturanalyse

Begonnen wird mit der Strukturanalyse, deren Resultat die Systemstruktur ist. Für die Analyse sind zunächst die Grenzen des betrachteten Systems und die Auflösung der Analyse festzulegen. Als Systemgrenze wählen wir selbstadministrierte Hardware sowie die darauflaufende Software. So wird beispielsweise das Netzwerk, das wir als nicht selbstadministriert annehemen, im Rahmen der Strukturanalyse nicht betrachtet, obwohl es Einfluss auf des System hat.

Systemelemente

Das betrachtete System Foto-Community unterteilen wir in die folgenen Systemelemente:

  • Web-Server
  • Application-Server
  • Search-Server
  • Cache-Server
  • Database-Server
  • File-Server

Jedes dieser Systemelemente lässt sich wiederum in die folgenden Systemelemente unterteilen:

  • Hardware
  • Betriebsystem
  • Software

Wir beschränken uns in der Auflösung der Analyse und unterteilen Hardware, Betriebsystem und Software nicht weiter. Eine weitere Unterteilung würde eine detaillierte Betrachtung des Systems erlauben, aber auch eine höhere Komplexität mit sich bringen.

Systemstruktur

Auf Grundlage der zuvor festgelegten Systemelemente ergibt sich die folgende Systemstruktur:

Systemstruktur


Die Systemstruktur ist ein Baum, dessen Wurzel das System bildet. Jeder Teilbaum entspricht einem Subsystem.

Funktionsanalyse

Der Systemanalyse folgt die Funktionsanalyse, deren Ergebnis die Funktionsstruktur ist. Zunächst werden dem System und den einzelnen Systemelementen Funktionen zugeordnet.

Systemelemente und Funktionen

Das betrachtete System Foto-Community hat die folgenden Funktionen:

  • Bild mit Metainformationen erstellen
  • Bild mit Metainformationen ansehen
  • Bild ohne Metainformationen ansehen
  • Metainformationen editieren
  • Bild mit Metainformationen löschen
  • Bild suchen
  • Benutzerkonto erstellen
  • Benutzerkonto ansehen
  • Benutzerkonto editieren
  • Benutzerkonto löschen


Das Systemelement Web-Server hat die folgenden Funktionen:

  • Webseite ausliefern
  • Bild ausliefern
  • Bild hochladen
  • Daten hochladen

Das Systemelement Application-Server hat die folgenden Funktionen:

  • Benutzerkonto anlegen
  • Benutzerkonto auslesen
  • Benutzerkonto modifizieren
  • Benutzerkonto entfernen
  • Bild mit Metainformationen anlegen
  • Bild mit Metainformationen auslesen
  • Metainformationen zu einem Bild modifizieren
  • Bild mit Metainformationen entfernen

Das Systemelement Search-Server hat die folgenden Funktionen:

  • Meta-Informationen der Bilder und Benutzerprofile durchsuchen

Das Systemelement Cache-Server hat die folgenden Funktionen:

  • Datenbankanfrage cachen

Das Systemelement Database-Server hat die folgenden Funktionen:

  • Daten abfragen
  • Daten anlegen
  • Daten ändern
  • Daten löschen

Das Systemelement File-Server hat die folgenden Funktionen:

  • Bild lesen
  • Bild speichern
  • Bild löschen


Systemelement Software hat die folgenden Funktionen:

  • Funktionalität anbieten

Systemelement Bertiebssystem hat die folgenden Funktionen:

  • Software ausführen

Systemelement Hardware hat die folgenden Funktionen:

  • Ressourcen bereitstellen

Funktionsstruktur

In einem zweiten Schritt werden Abhängigkeiten zwischen den Funktionen definiert. Es ergibt sich ein Abhängigkeitsgraph, der als Funktionsstruktur bezeichnet wird. Die Knoten entsprechen den einzelnen Funktionen und die Kanten den Abhängigkeiten. Die folgende Grafik zeigt die Funktionsstruktur der Foto-Community.

Funktionsstruktur.png

Fehleranalyse

Aus der Funktionsstruktur wird eine Fehlfunktionsstruktur abgeleitet. Häufig besteht die Fehlfunktion eines Systemelements aus der Negation der entprechenden Funktion. Hier ist die Negation der Funktion durch die jeweilige Fehlfunktion "defekt" definiert. Bei der Fehlfunktion "langsam" ist die eigentliche Funktionalität noch gegeben, sodass die Funktion das richtige Ergebnis liefert, jedoch liegt die Antwortzeit der Funktion außerhalb des Toleranzbereiches.

Systemelemente und Fehlfunktionen

Die Fehleranalyse beginnt mit der Definition von Fehlern, die einzelnen Funktionen zugeordnet werden. Hier nutzen wir die zuvor erstellte Funktionsstruktur und betrachten der Reihe nach die dort festgelegten Funktionen. Jede Funktionen bekommt die Fehler langsam und defekt zugeordnet.

Das betrachtete System Foto-Community hat die folgenden Fehlfunktionen:

  • Bild mit Metainformationen erstellen: langsam / defekt
  • Bild mit Metainformationen ansehen: langsam / defekt
  • Bild ohne Metainformationen ansehen: langsam / defekt
  • Metainformationen editieren: langsam / defekt
  • Bild mit Metainformationen löschen: langsam / defekt
  • Bild suchen: langsam / defekt
  • Benutzerkonto erstellen: langsam / defekt
  • Benutzerkonto ansehen: langsam / defekt
  • Benutzerkonto editieren: langsam / defekt
  • Benutzerkonto löschen: langsam / defekt


Das Systemelement Web-Server hat die folgenden Fehlfunktionen:

  • Webseite ausliefern: langsam / defekt
  • Bild ausliefern: langsam / defekt
  • Bild hochladen: langsam / defekt
  • Daten hochladen: langsam / defekt

Das Systemelement Application-Server hat die folgenden Fehlfunktionen:

  • Benutzerkonto anlegen: langsam / defekt
  • Benutzerkonto auslesen: langsam / defekt
  • Benutzerkonto modifizieren: langsam / defekt
  • Benutzerkonto entfernen: langsam / defekt
  • Bild mit Metainformationen anlegen: langsam / defekt
  • Bild mit Metainformationen auslesen: langsam / defekt
  • Metainformationen zu einem Bild modifizieren: langsam / defekt
  • Bild mit Metainformationen entfernen: langsam / defekt

Das Systemelement Search-Server hat die folgenden Fehlfunktionen:

  • Meta-Informationen der Bilder und Benutzerprofile durchsuchen: langsam / defekt

Das Systemelement Cache-Server hat die folgenden Fehlfunktionen:

  • Datenbankanfrage cachen: langsam / defekt

Das Systemelement Database-Server hat die folgenden Fehlfunktionen:

  • Daten abfragen: langsam / defekt
  • Daten anlegen: langsam / defekt
  • Daten ändern: langsam / defekt
  • Daten löschen: langsam / defekt

Das Systemelement File-Server hat die folgenden Fehlfunktionen:

  • Bild lesen: langsam / defekt
  • Bild speichern: langsam / defekt
  • Bild löschen: langsam / defekt


Systemelement Software hat die folgenden Fehlfunktionen:

  • Funktionalität anbieten: langsam / defekt

Systemelement Bertiebssystem hat die folgenden Fehlfunktionen:

  • Software ausführen: langsam / defekt

Systemelement Hardware hat die folgenden Fehlfunktionen:

  • Ressourcen bereitstellen: langsam / defekt

Fehlerstruktur

Nun ist die Fehlerstruktur zu erstellen. Wie zuvor bei der Funktionsstruktur handelt es sich hierbei um einen Graph. So wird kenntlich wie ein Fehler den anderen auslöst.

Fehlfunktionsstruktur

Risikobewertung

Nun sind die ersten drei Schritte der FMEA durchlaufen. Systemstruktur, Funktionen und mögliche Fehler sind analysiert und dokumentiert. Darauf aufbauend folgt nun die Risikobewertung, die mit Hilfe von FMEA-Bögen durchgeführt wird. Ziel ist es die Risiken der einzelnen Fehler abzuschätzen. Für jedes der Systemelemente wird ein FMEA-Bogen angelegt. Die Tabelle zeigt den FMEA-Bogen für das Systemelement Web-Server. Der Kopf der Tabelle enthält einige Meta-Daten. Die Tabelle selbst enthält alle möglichen Fehler des Systemelements, sowie deren Folgen und Ursachen.

Für jeden Fehler werden die Wahrscheinlichkeit für das Auftreten, die Entdeckung des Fehlers und dessen Bedeutung notiert. Zur Erinnerung die entsprechende Legende:

  • Auftreten(A) - 1 = seltenes Auftreten bis 10 = häufiges Auftreten
  • Bedeutung(B) - 1 = geringe Bedeutung bis 10 = hohe Bedeutung
  • Entdeckbarkeit(E) - 1 = leicht zu entdecken bis 10 = schwer zu entdecken
  • Risikoprioritätszahl(RPZ) = A x B x E


In der Tabelle ist die Zeile mit der höchsten RPZ markiert. Sie birgt ein zu hohes Risiko.

Systemement: Web-Server
Typ/Modell/Fertigung/Charge: Sach-Nr.: Verantwortlicher: FMEA-Nr:
Web-Server Sach_ID HS-RM / Informatik / Martin Günster FMEA_ID
Funktion/Aufgabe: Änderungsstand: Firma: Datum:
Webseite ausliefern 1 HS-RM 06.01.2014
Fehlerfolge B Fehler Ursache Vermeidungsmaßnahme A Entdeckungsmaßnahme E RPZ Verantwortlicher
Bild mit Metainformationen erstellen (defekt) 3 Webseite ausliefern (defekt) Funktionalität anbieten (defekt) (Web-Server) 3 Monitoring 3 27 Administrator
Bild mit Metainformationen ansehen (defekt) 3 3 Monitoring 3 27 Administrator
Metainformationen editieren (defekt) 3 3 Monitoring 3 27 Administrator
Bild mit Metainformationen löschen (defekt) 3 3 Monitoring 3 27 Administrator
Bild suchen (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto erstellen (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto ansehen (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto editieren (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto löschen (defekt) 3 3 Monitoring 3 27 Administrator
Bild ohne Metainformationen ansehen (defekt) 5 Bild ausliefern (defekt) Funktionalität anbieten (defekt) (Web-Server) 3 Monitoring, EMail-Benachrichtigung 3 45 Administrator
Bild mit Metainformationen erstellen (defekt) 3 Bild hochladen (defekt) Funktionalität anbieten (defekt) (Web-Server) 3 Monitoring 3 27 Administrator
Bild mit Metainformationen erstellen (defekt) 3 Daten hochladen (defekt) Funktionalität anbieten (defekt) (Web-Server) 3 Monitoring 3 27 Administrator
Metainformationen editieren (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto erstellen (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto editieren (defekt) 3 3 Monitoring 3 27 Administrator
Bild mit Metainformationen erstellen (langsam) 3 Webseite ausliefern (langsam) Funktionalität anbieten (langsam) (Web-Server) 3 Monitoring 3 27 Administrator
Bild mit Metainformationen ansehen (langsam) 3 3 Monitoring 3 27 Administrator
Metainformationen editieren (langsam) 3 3 Monitoring 3 27 Administrator
Bild mit Metainformationen löschen (langsam) 3 3 Monitoring 3 27 Administrator
Bild suchen (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto erstellen (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto ansehen (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto editieren (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto löschen (langsam) 3 3 Monitoring 3 27 Administrator
Bild ohne Metainformationen ansehen (langsam) 3 Bild ausliefern (langsam) Funktionalität anbieten (langsam) (Web-Server) 3 Monitoring 3 27 Administrator
Bild mit Metainformationen erstellen (langsam) 3 Bild hochladen (langsam) Funktionalität anbieten (langsam) (Web-Server) 3 Monitoring 3 27 Administrator
Bild mit Metainformationen erstellen (langsam) 3 Daten hochladen (langsam) Funktionalität anbieten (langsam) (Web-Server) 3 Monitoring 3 27 Administrator
Metainformationen editieren (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto erstellen (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto editieren (langsam) 3 3 Monitoring 3 27 Administrator

Optimierung

Nach der Risikobewertung folgt gegebenenfalls in einem fünften Schritt die Optimierung. Es werden alle FMEA-Bögen durchgesehen. Anhand der RPZ lässt sich bestimmen, ob ein Handlungsbedarf besteht. In unserem Beispiel ist die RPZ für Bild ohne Metainformationen ansehen (defekt) mit 45 besonders hoch. Dies ist eine Folge des Fehlers Bild ausliefern (defekt) dessen Entdeckbarkeit wir durch eine EMail-Benachrichtigung des Monitoringsystems verbessern.

Diese Aktion dokumentieren wir durch eine neue Zeile im FMEA-Bogen. Dort vermerken wir die zusätzliche Aktion und das Durchführungsdatum. In einer erneut durchgeführten Risikobewertung zeigt sich eine verringerte Entdeckungsrate (E) und die ebenfalls reduzierte RPZ. Sie wird in der neuen Version des FMEA-Bogens notiert. Der Änderungsstand wird auf zwei erhöht.

Systemement: Web-Server
Typ/Modell/Fertigung/Charge: Sach-Nr.: Verantwortlicher: FMEA-Nr:
Web-Server Sach_ID HS-RM / Informatik / Martin Günster FMEA_ID
Funktion/Aufgabe: Änderungsstand: Firma: Datum:
Webseite ausliefern 2 HS-RM 20.02.2014
Fehlerfolge B Fehler Ursache Vermeidungsmaßnahme A Entdeckungsmaßnahme E RPZ Verantwortlicher
Bild mit Metainformationen erstellen (defekt) 3 Webseite ausliefern (defekt) Funktionalität anbieten (defekt) (Web-Server) 3 Monitoring 3 27 Administrator
Bild mit Metainformationen ansehen (defekt) 3 3 Monitoring 3 27 Administrator
Metainformationen editieren (defekt) 3 3 Monitoring 3 27 Administrator
Bild mit Metainformationen löschen (defekt) 3 3 Monitoring 3 27 Administrator
Bild suchen (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto erstellen (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto ansehen (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto editieren (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto löschen (defekt) 3 3 Monitoring 3 27 Administrator
Bild ohne Metainformationen ansehen (defekt) 5 Bild ausliefern (defekt) Funktionalität anbieten (defekt) (Web-Server) 3 Monitoring 3 45 Administrator
Bild ohne Metainformationen ansehen (defekt) 5 Bild ausliefern (defekt) Funktionalität anbieten (defekt) (Web-Server) 3 Monitoring, EMail-Benachrichtigung (20.02.2014) 1 15 Administrator
Bild mit Metainformationen erstellen (defekt) 3 Bild hochladen (defekt) Funktionalität anbieten (defekt) (Web-Server) 3 Monitoring 3 27 Administrator
Bild mit Metainformationen erstellen (defekt) 3 Daten hochladen (defekt) Funktionalität anbieten (defekt) (Web-Server) 3 Monitoring 3 27 Administrator
Metainformationen editieren (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto erstellen (defekt) 3 3 Monitoring 3 27 Administrator
Benutzerkonto editieren (defekt) 3 3 Monitoring 3 27 Administrator
Bild mit Metainformationen erstellen (langsam) 3 Webseite ausliefern (langsam) Funktionalität anbieten (langsam) (Web-Server) 3 Monitoring 3 27 Administrator
Bild mit Metainformationen ansehen (langsam) 3 3 Monitoring 3 27 Administrator
Metainformationen editieren (langsam) 3 3 Monitoring 3 27 Administrator
Bild mit Metainformationen löschen (langsam) 3 3 Monitoring 3 27 Administrator
Bild suchen (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto erstellen (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto ansehen (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto editieren (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto löschen (langsam) 3 3 Monitoring 3 27 Administrator
Bild ohne Metainformationen ansehen (langsam) 3 Bild ausliefern (langsam) Funktionalität anbieten (langsam) (Web-Server) 3 Monitoring 3 27 Administrator
Bild mit Metainformationen erstellen (langsam) 3 Bild hochladen (langsam) Funktionalität anbieten (langsam) (Web-Server) 3 Monitoring 3 27 Administrator
Bild mit Metainformationen erstellen (langsam) 3 Daten hochladen (langsam) Funktionalität anbieten (langsam) (Web-Server) 3 Monitoring 3 27 Administrator
Metainformationen editieren (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto erstellen (langsam) 3 3 Monitoring 3 27 Administrator
Benutzerkonto editieren (langsam) 3 3 Monitoring 3 27 Administrator


Risikobewertung und Optimierung sind nun so lange zu wiederholen, bis das Restrisiko akzeptabel ist.

Gefahren- und Risikoanalyse kritischer Kontroll- bzw. Lenkpunkte

Die Gefahren- und Risikoanalyse kritischer Kontroll- bzw. Lenkpunkte (engl. Hazard Analysis and Critical Control Points kurz HACCP) ist eine Erweiterung der klassischen FMEA, die 1959 im Auftrag der NASA entwickelt wurde. Damals sollte eine weltraumgeeignete Astronautennahrung herzustellen, die hundertprozentig sicher sein sollte. Heute ist HACCP, wie FMEA weit verbreitet. Das Haupteinsatzgebiet ist nach wie vor die Lebensmittelindustrie. So empfiehlt beispielsweise die Ernährungs- und Landwirtschaftsorganisation der UNO die Anwendung des HACCP-Konzeptes.

In der Lebensmittelindustrie sichert es die Lebensmittelqualität und -sicherheit. Es behandelt dort Gefahren die während des Herstellungsprozess auftreten und eine Bedrohung für den Verbraucher darstellen oder eine Minderung der Produktqualität bewirken. Mikrobiologische, chemische und physikalische Gefahren sollen schon während der Lebensmittelproduktion erkannt und durch geeignete Gegenmaßnahmen beseitigt werden.

Zentrale Idee des HACCP-Konzeptes sind die kritischen Kontroll- bzw. Lenkpunkte (engl. Critical Control Points kurz CCPs) . Sie dienen der Überwachung der identifizierten Gefahren innerhalb eines Herstellungsprozesses. Ein CCP muss dort eingesetzt werden, wo eine Gefahr auftreten, beseitigt oder vermieden werden kann. Der CCP selbst beinhaltet einen definierten Grenzwert, der zur Kontrolle dient und geeignete Maßnahmen zu Beseitigung bzw. Vermeidung der Gefahr. Im Produktionstrieb werden die gemessenen Realwerte mit dem definierten Grenzwert verglichen. Kommt es zu einer Über- oder Unterschreitung des Grenzwertes sind die definierten Gegenmaßnahmen einzuleiten. Die folgende Aufzählung zeigt noch einmal die, für einen HACCP-konformen Produktionsprozess laut  Artikel 6 Absatz 2 der VO (EG) Nr. 183/2003 geforderten Punkte.

  1. Ermittlung von Gefahren, die vermieden, ausgeschaltet oder auf ein annehmbares Maß reduziert werden müssen;
  2. Bestimmung der kritischen Kontrollpunkte auf der (den) Prozessstufe(n), auf der (denen) eine Kontrolle notwendig ist, um eine Gefahr zu vermeiden, auszuschalten oder auf ein annehmbares Maß zu reduzieren;
  3. Festlegung von Grenzwerten für diese kritischen Kontrollpunkte, anhand derer im Hinblick auf die Vermeidung, Ausschaltung oder Reduzierung ermittelter Gefahren zwischen akzeptablen und nicht akzeptablen Werten unterschieden wird;
  4. Festlegung und Durchführung effizienter Verfahren zur Überwachung der kritischen Kontrollpunkte;
  5. Festlegung von Korrekturmaßnahmen für den Fall, dass die Überwachung zeigt, dass ein kritischer Kontrollpunkt nicht unter Kontrolle ist;
  6. Festlegung von Verifizierungsverfahren, um festzustellen, ob die in den Buchstaben 1) bis 5) genannten Maßnahmen vollständig und wirksam funktionieren. Die Verifizierungsverfahren werden regelmäßig angewandt;
  7. Erstellung von Dokumenten und Aufzeichnungen, die der Art und Größ des Futtermittelunternehmens angemessen sind, um nachweisen zu können, dass die in den Buchstaben 1) bis 6) genannten Maßnahmen angewendet werden.

Die HACCP bietet gegenüber FMEA seinen pragmatischen Ansatz für das Risikomanagement. Im Gegensatz zu FMEA wird auf die Untersuchung von Fehlerursachen und -folgen verzichtet. Man fokussiert sich auf die Beobachtung und Behebung von Fehlern.

Fehlerbaumanalyse

Bei der Fehlerbaumanalyse handelt es sich deduktives Verfahren, um die Wahrscheinlichkeit eines unerwünschten Ereignis zu bestimmen. Dabei beginnt man mit dem unerwünschten Ereignis, dem sogenannte Top-Ereignis, und beschreibt in Form einer Baumstruktur, welche Ereignisse auftreten müssen, damit das jeweilige übergeordnete Ereignis eintritt. Ereignisse, die den einzelnen Teilbäumen entsprechen werden durch Symbole der Booleschen Algebra logisch verknüpft. Ereignisse, die nicht weiter zerlegbar sind, werden als Primärereignisse bezeichnet und bilden die Blätter des Baumes. Den Primärereignissen werden Wahrscheinlichkeiten für ihr Auftreten zugeordnet. Abbildung Fehlerbaumanalyse stellt einen beispielhaften Fehlerbaum dar.

Fehlerbaumanalyse - TU-Chemnitz Matthias Clauß, Uwe Hübner, Thomas Müller, Christoph Ziegler, 10.07.2003 (http://www.tu-chemnitz.de/urz/lehre/psa/script03/html/disaster/fta.htm)

Auf dieser Grundlage lassen sich nun zwei relevante Größen bestimmen. Die Wahrscheinlichkeit des unerwünschten Ereignisses und sogenannten Minimalschnitten mit den zugehörigen Wahrscheinlichkeiten. Ein Minimalschnitt besteht aus einer Menge von Primärereignissen, die, wenn sie zeitgleich eintreten, das unerwünschte Ereignis auslösen. Die Summe der Wahrscheinlichkeiten dieser Minimalschnitte ergeben dann die Wahrscheinlichkeit des unerwünschten Ereignisses. Für die Berechnung der Wahrscheinlichkeit werden die Gesetze für Durchschnitt und Vereinigung verwendet.

  • Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(A \cap B)=P(B|A) \times P(A)}
  • Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(A \cup B)=P(A)+P(B)-P(A \cap B)} 

Auf diese Weise durchläuft man den Baum bis zur Wurzel, löst sukzessiv die booleschen Verknüpfungen in Wahrscheinlichkeiten auf und erhält so schließlich die Wahrscheinlichkeit des unerwünschten Ereignisses.

Ereignisbaumanalyse

Die Ereignisbaumanalyse bildet gewissermaßen das Gegenstück zur Fehlerbaumanalyse. Hier wird betrachtet welche Ereignisse sich möglicherweise aus einem Anfangsereignis entwickeln. Das Verfahren wird häufig bei technischen Systemen verwendet, um die Auswirkungen von Störfällen(Anfangsereignis) auf weitere Komponenten des Systems zu untersuchen.

Beginnend mit dem Anfangsereignis (z.B. dem Ausfall einer Festplatte) werden Folgeereignisse (z.B. dem Ausfall des betreffenden Servers ) bis zu möglichen Endzuständen (z.B. Ausfall der Webseite, die durch den betreffenden Server bereitgestellt wurde) ermittelt. Das Ergebnis ist eine Baumstruktur, in der die kausalen Abhängigkeiten der Ereignisse kodiert sind. Das Anfangsereignis bildet den Wurzelknoten und die Endzustände entsprechen den Blättern des Baumes. Jeder Ast des Baumes ist mit einer gewissen Ausfall- Fehlerwahrscheinlichkeit verbunden. Um die Wahrscheinlichkeit eines Endzustandes zu ermitteln, ist dem dem entsprechendem Pfad des Baumes ausgehen von der Wurzel des Baumes, die das Anfangsereignis repräsentiert zu folgen. Das Produkt der Wahrscheinlichkeiten entlang des Pfades entspricht der Wahrscheinlichkeit des Endzustandes.

Bayes-Netze

IT-Systeme sind genau wie die Realität meist zu komplex um in ihrer Gesamtheit genau und korrekt erfasst zu werden. Um aus diesem so genannten „unsicherem Wissen“ Schlüsse zu ziehen, also „Reasoning“ zu betreiben, hat sich die Verwendung von Bayes-Netzen bestens bewährt.

Ein Bayes-Netz (benannt nach Thomas Bayes) ist ein gerichteter, azyklischer Graph, in dem die Knoten Zufallsvariablen und die Kanten bedingte Abhängigkeiten zwischen den Variablen beschreiben. Eine Zufallsvariable hat dabei endlich viele mögliche Werte. Zu jeder Variable ist eine Tabelle, die sogenannte Conditional Probability Table (kurz CPT), angegeben, die die bedingte Wahrscheinlichkeitsverteilung der Variable bedingt ihrer Eltern angibt. Eltern einer Variablen sind die Variablen von denen eine Kante in diese Variable geht.

Zwei Variablen A und B heißen bedingt unabhängig gegeben C, wenn Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(A,B|C)=P(A|C) \times P(B|C)} , bzw. wenn Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(A|B,C)=P(A|C)} .

Neben den grundlegenden Rechenregeln für Wahrscheinlichkeiten gelten folgende Regeln:

Bayes-Formel:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(A|B)=\frac{P(B|A) \times P(A)}{P(B)}}

Marginalisierung:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(A)=P(A,B) \times P(A,\neg{B})}

Konditionierung:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(A|B)=\sum_{c} P(A|B,C=c)P(C=c|B)}

Kettenregel:

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(X_{1},...,X_{n})=\prod_{i=1}^{n} P(X_{i}|Eltern(X_{i}))}

Analyse der Anwendungsfälle von Bayes-Netzen

Bayes-Netze lassen sich vor allem für zwei Anwendungsfälle nutzen und zwar die Root-Cause-Analyse und die Hazard-Analyse. Diese beiden Anwendungsfälle sollen im Folgenden an Hand eines Beispiel erläutert werden.

In dem für das Beispiel betrachteten IT-System stellt ein Server über das Netzwerk einen Webservice zur Verfügung. Ein Fehler in der Stromversorgung kann zu Fehlern in Server und Netzwerk führen. Weitere Fehlerquellen für den Server sind in seiner CPU und HDD zu finden. Ein Fehler in Netzwerk oder Server wirkt sich auf den bereitgestellten Webservice aus. Ein Fehler im Server kann außerdem zu einem Fehler in der Datensicherheit führen.

Das betrachtete System besteht aus den folgenden Variablen:

  • HDD
  • CPU
  • Strom
  • Server
  • Netzwerk
  • Webservice
  • Datensicherheit

Der Einfachheit halber haben alle Variablen nur zwei Werte und zwar True und False, wobei True fehlerhaftes Verhalten signalisiert.

Beispielszenario als Bayes-Netz

Die Abbildung zeigt das Beispielszenario als Bayes-Netz. Außerdem sind die folgenden Wahrscheinlichkeitsverteilungen für die Variablen gegeben:

HDD True
0,3
CPU True
0,1
Strom True
0,01
Netzwerk True
Strom = True 0,8
Strom = False 0,1
Server True
HDD = True / CPU = True / Strom = True 1,0
HDD = True / CPU = True / Strom = False 0,4
HDD = True / CPU = False / Strom = True 0,8
HDD = True / CPU = False / Strom = False 0,1
HDD = False / CPU = True / Strom = True 0,8
HDD = False / CPU = True / Strom = False 0,3
HDD = False / CPU = False / Strom = True 0,8
HDD = False / CPU = False / Strom = False 0,01
Webservice True
Server = True / Netzwerk = True 1,0
Server = True / Netzwerk = False 0,9
Server = False / Netzwerk = True 0,7
Server = False / Netzwerk = False 0,1
Datensicherheit True
Server = True 0,2
Server = False 0,02

Root-Cause-Analyse:

Es sollen die wahrscheinlichen Ursachen eines Fehlers bestimmt werden. Im Beispiel sollen die wahrscheinlichen Ursachen für einen Fehler im Webservice berechnet werden.

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(Strom|Webservice) = 0,0285}
Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(HDD|Webservice) = 0,4080}
Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(CPU|Webservice) = 0,2247}

Die Berechnung ergibt, dass bei einem Fehler im Webservice mit 40 %iger Wahrscheinlichkeit auch ein Fehler in der HDD vorliegt.

Hazard-Analysis:

Es sollen die wahrscheinlichen Auswirkungen eines Fehlers bestimmt werden. Im Beispiel sollen die Wahrscheinlichen Auswirkungen für einen Fehler in der Stromversorgung berechnet werden.

Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(Webservice|Strom) = 0,7914}
Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://en.wikipedia.org/api/rest_v1/“:): {\displaystyle P(Datenverlust|Strom) = 0,0662}

Die Berechnung ergibt, dass bei einem Fehler in der Stromversorgung mit 79 %iger Wahrscheinlichkeit auch ein Fehler im Webservice vorliegt.

Weka – Waikato Environment for Knowledge Analysis

Waikato Environment for Knowledge Analysis (kurz Weka) wird von der University of Waikato entwickelt und steht unter GNU General Public License. Weka ist eine Sammlung von Machine Learning Algorithmen für Data Mining Aufgaben. Es bietet die Möglichkeit, Bayes-Netze zu verarbeiten. Neben einem grafischen Editor wird eine Java API zur Verfügung gestellt.

Die Abbildung zeigt das Bayes-Netz aus dem Beispielszenario im grafischen Editor von Weka.

Screenshot - Weka - Beispielszenario

Bewertung

Im Anschluss an die Analyse wurden zwei Verfahren (FMEA und Bayes-Netze) ausgewählt und im Folgenden sollen kurz die Vor- und Nachteile der ausgewählten Verfahren erläutert werden. Die Verfahren wurden so ausgewählt, dass sie sich gut ergänzen. Die Vorteile des einen Verfahrens sollen die Nachteile des anderen Verfahrens ausgleichen. Die Auswahl wurde so im Hinblick auf eine eventuelle, spätere Verknüpfung der beiden Verfahren getroffen.

FMEA

FMEA bietet einen gut beschriebenen und strukturierten Prozess der Erstellung. Außerdem ist FMEA in der Industrie weit verbreitet. Allerdings ist das zu Grunde liegende Berechnungsmodell ungenau und statisch.

Bayes-Netze

Bayes-Netze ermöglichen die Modellierung und Berechnung von komplexen Abhängigkeiten innerhalb eines Systems. Außerdem existieren Bibliotheken, um Bayes-Netze zu berechnen, wie etwa das vorgestellte Weka. Allerdings enthalten Bayes-Netze keinerlei weiterführende Informationen zu den im Modell enthalteten Zufallsvariablen.

Ontologien

Die am meisten verbreitete Definition ist die von Thomas Gruber aus dem Jahre 1993. Gruber definiert eine Ontologie wie folgt, "An ontology is an explicit specification of a conceptualization."

Ontologien dienen demnach dazu das Wissen über eine Domäne explizit zu erfassen. Dabei ist es vor allem wichtig zu beschreiben, welche Arten von Dingen es in der Domäne gibt, welche Eigenschaften sie haben und wie sie miteinander in Beziehung stehen.

Ontologien enthalten neben dem Wissen über die Domäne auch Integritäts- und Inferenzregeln, diese ermöglichen das Schlussfolgern von neuem Wissen und die Überprüfung der Gültigkeit von bestehendem Wissen.

Web Ontology Language

Eine Möglichkeit Ontologien zu realisieren ist die Verwendung der Web Ontology Language (kurz OWL). OWL basiert auf RDF und RDFS und wird durch den W3C spezifiziert. OWL ist 2004 erschienen und der Nachfolder OWL2 ist 2012 erschienen. Die Unterschiede zwischen OWL und dem Nachfolger OWL2 bestehen vor allem in den angeboteten Profilen, die Möglichkeiten zur Definition von Ontologien in ihrer Komplexität einschränken.

Eine OWL Ontologie besteht aus einer T-Box (terminological box) und A-Box (assertional box). Die T-Box enthält Klassen, Object Properties und Datatype Properties und die A-Box enthält die Instanzen.

In OWL gilt die Open World Assumption, das heißt das über Wissen, welches nicht explizit bekannt ist, keine Aussage getroffen werden kann. Es ist also unbekannt.

Bayes-Netze als Ontologie

Im Rahmen des Projektes wurde eine Ontologie zur Darstellung von Bayes-Netzen entwickelt. Diese Ontologie soll im Folgenden beschrieben werden.

Die Bayes-Netz Ontologie besteht aus drei Klassen. Die Klasse Variable repräsentiert die Zufallsvariablen eines Bayes-Netzes. Jede Zufallsvariable hat einen Namen. Die bedingten Abhängigkeiten zwischen Zufallsvariablen werden über die Relation causes (invers causedBy) dargestellt.

Die Klasse State repräsentiert die diskreten Zustände, die eine Zufallsvariable annehmen kann. Jeder Zustand hat einen Wert und eine Wahrscheinlichkeit für das unbedingte Auftreten des Zustandes. Über die Relation hasState (invers isStateOf) werden die Zustände den Zufallsvariablen zugeordnet.

Die Klasse ConditionalProbabilityDistribution repräsentiert die Einträge der CPTs einer Zufallsvariable. Über die Relation hasConditionalProbabilityDistribution (invers isConditionalProbabilityDistributionOf) werden die Einträge den Zuständen zugeordnet. Außerdem werden über die Relation hasConditionalState (invers isConditionalStateOf) die Einträge den Zuständen zugeordnet von denen sie bedingt abhängen. Jeder Eintrag hat eine Wahrscheinlichkeit. Diese stellt die bedingte Wahrscheinlichkeit für das Auftreten eines Zustandes dar.

Modell Bayes-Netz Ontologie

FMEA als Ontologie

Für die Fehlermöglichkeits- und Einflussanalyse ist im Rahmen des Projektes eine Ontologie entwickelt worden. Mit Hilfe der Ontologie ist es möglich FMEA spezifische Aspekte eines Systems ab zu bilden. Diese Aspekte lassen sich nun mit Aspekten der System-Ontologie verknüpfen. So läßt sich das ontologiebasierte IT-Managment um eine FMEA erweitern. Die Ontologie der FMEA wird im folgenden erläutert. Die Grafik OWL-Objekt-Relationen dient als visuelle Unterstützung.

Modell FMEA Ontologie

OWL-Klassen zur Struktur-, Funktions- und Fehleranalyse

In Abschnitt wird die Gruppe von OWL-Klassen beschrieben, die zur Struktur-, Funktions- und Fehleranalyse notwendig sind.

FMEA

Die Klasse FMEA entspricht der FMEA als Dokument. Sie enthält eine Version und eine für die FMEA veratnwortliche Instanz. Der FMEA untergeordnet sind alle betrachteten Systemelemente und das betrachtete System selbst.

Systemelement

Die Klasse Systemelement entspricht einem Systemelement aus der Systemanalyse. Systemelements können aus weiteren (Sub-)Systemelementen bestehen oder umgekehrt Teil eines Systemelements sein.

System

Die Klasse System entspricht dem System aus der Systemanalyse. Das System ist ein spezielles Systemelement. Es enthält kein übergeordnetes Systemelement. Dem entsprechend ist die Klasse System eine Unterklasse von Systemelement.

Function

Die Klasse Function entspricht der Funktion aus der Funktionsanalyse. Auch hier werden Funktionen Systemelementen zugeordnet. Für eine Funktion können deren Abhängigkeiten beschrieben werden, umgekehrt kann die Funktion selbst als Abhängigkeit gekennzeichnet werden.

Failure

Die Klasse Failure entspricht dem Fehler aus der Fehleranalyse. Fehler werden Funktionen zugeordnet und können Ursache oder Folge eines anderen Fehler sein.

OWL-Klassen zur Risikobewertung und Optimierung

Im folgenden Abschnitt werden alle Klassen beschrieben, die zur Abbildung von Risikobewertung und Optimierung notwendig sind.

State

Die Klasse State repräsentiert eine Zeile eines FMEA-Bogens. Jeder Instanz der Klasse Failure ist mindestens Instanz der Klasse State zu zuordnen. Diese Instanz der Klasse State repräsentiert dann den ersten Stand der Risikobewertung für diesen Fehler. Folgt eine Optimierung wird eine weitere Risikobewertung durchgeführt, die zu einer weiteren Instanz von State führt die ebenfalls dem Fehler zugeordnet wird. Die verschiedenen Instanzen der Klasse State unterscheiden sich durch einen Zeitstempel, in dem der Erstellungszeitpunkt der Instanz festgehalten wird und den zugeordneten Fehler.

Jede Instanz der Klasse State hält die für die Risikobewertung notwendigen Daten:

  • Detectionrate (Entdeckungswahrscheinlichkeit)
  • Probabilityrate (Auftretenswahrscheinlichkeit)
  • Severityrate (Bedeutung)
  • Riskprioritynumber(Risikoprioritätszahl)

Mit jeder Optimierung werden verschiedene Aktionen vorgenommen, die anschließend der neuen State Instanz zugordnet werden.

Action

Die Klasse Action ist eine allgemeine Klasse von der spezialisierte Klassen ableiten. Es wird zwischen den folgenden Aktionen unterschieden:

  • Counteraction
  • Damagemitigationaction
  • Detectionaction

Zu jeder Actionen wird ein Zeitstempel mit dem Ausführungszeitpunkt und ein Verantwortlicher vermerkt.

OWL-Klassen für Verantwortlichkeiten

Die folgenden OWl-Klassen bilden Verantwortlichkeiten ab. Sie sind bewusst einfach gehalten und können beispielsweise mit einer Ontologie für Personalwesen verbunden werden.

ResponsibleAuthority

Die Klasse ResponsibleAuthority ist die allgemeinste Klasse aller Verantwortlichkeiten.

Person

Die Klasse Person ist eine Spezialisierung der Klasse ResponsibleAuthority und repräsentiert einen Menschen, dessen Name hinterlegt wird.

Company

Die Klasse Company ist eine Spezialisierung der Klasse ResponsibleAuthority und repräsentiert ein Unternehmen. Für das Unternehmen kann ein Name hinterlegt werden. Instanzen der Klasse Personkönnen einer Instanz der Klasse Company als Mitarbeiter zu geordnet werden.

Domänenspezifische Sprachen

Eine domänenspezifische Sprache (engl. domain-specific language; kurz DSL) ist eine formale Sprache, die besonders für ein bestimmtes Problemfeld (die sogenannte Domäne) entworfen und implementiert wird. Beim Entwurf einer DSL wird man bemüht sein, einen hohen Grad an Problemspezifität zu erreichen: die Sprache soll alle Probleme der Domäne darstellen können und nichts darstellen können, was außerhalb der Domäne liegt. Dadurch ist sie durch Domänenspezialisten ohne besonderes Zusatzwissen bedienbar. (aus http://de.wikipedia.org/wiki/Dom%C3%A4nenspezifische_Sprache)

Xtext

Xtext ist ein Framework zum Erstellen von DSLs. Xtext ist Teil des Eclipse-Modeling-Framework-Projekts und ist in der ersten Version 2006 erschienen. Die aktuelle Version 2.5.0 ist am 11.12.2013 erschienen.

Im Gegensatz zu normalen Parsergeneratoren wird bei Xtext nicht nur ein Parser generiert, sondern auch ein Klassenmodell für den abstrakten Syntaxbaum und ein in Eclipse integrierter Texteditor sowie die notwendige Infrastruktur für die Implementierung einer modernen Entwicklungsumgebung für die entwickelte Sprache bereitgestellt. (aus http://de.wikipedia.org/wiki/Xtext)

Der von Xtext erzeugte Editor bietet Funktionen wie Syntax Coloring, Validation und Quick Fixes. Die Funktionalität kann nach Belieben angepasst und erweitert werden.

Um die eigene Domänenspezifische Sprache nutzbar zu machen, bietet Xtext die Möglichkeit Code zu generieren. Zur Generierung wird die Sprache Xtend angeboten.

Bayes-Netze als DSL

Im folgenden Abschnitt soll die Syntax der DSL für Bayes-Netze an Hand der Realisierung des in Abschnitt [[1]] eingeführtem Beispiels, erläutert werden. Das folgende Codelisting zeigt die Umsetzung des Beispiels in der DSL.

 1 Webservice has States true, false
 2 Datensicherheit has States true, false
 3 Netzwerk has States true, false
 4 Server has States true, false
 5 Strom has States true, false
 6 HDD has States true, false
 7 CPU has States true, false
 8 
 9 Strom => Netzwerk
10 Netzwerk => Webservice
11 Strom => Server
12 HDD => Server
13 CPU => Server
14 Server => Webservice
15 Server => Datensicherheit
16 
17 P(HDD=true)=0.3
18 P(HDD=false)=0.7
19 
20 P(CPU=true)=0.1
21 P(CPU=false)=0.9
22 
23 P(Strom=true)=0.01
24 P(Strom=false)=0.09
25 
26 P(Netzwerk=true|Strom=true)=0.8
27 P(Netzwerk=false|Strom=true)=0.2
28 P(Netzwerk=true|Strom=false)=0.1
29 P(Netzwerk=false|Strom=false)=0.9
30 
31 P(Server=true|HDD=true, CPU=true, Strom=true)=1.0
32 P(Server=false|HDD=true, CPU=true, Strom=true)=0.0
33 P(Server=true|HDD=true, CPU=true, Strom=false)=0.4
34 P(Server=false|HDD=true, CPU=true, Strom=false)=0.6
35 P(Server=true|HDD=true, CPU=false, Strom=true)=0.8
36 P(Server=false|HDD=true, CPU=false, Strom=true)=0.2
37 P(Server=true|HDD=true, CPU=false, Strom=false)=0.1
38 P(Server=false|HDD=true, CPU=false, Strom=false)=0.9
39 P(Server=true|HDD=false, CPU=true, Strom=true)=0.8
40 P(Server=false|HDD=false, CPU=true, Strom=true)=0.2
41 P(Server=true|HDD=false, CPU=true, Strom=false)=0.3
42 P(Server=false|HDD=false, CPU=true, Strom=false)=0.7
43 P(Server=true|HDD=false, CPU=false, Strom=true)=0.8
44 P(Server=false|HDD=false, CPU=false, Strom=true)=0.2
45 P(Server=true|HDD=false, CPU=false, Strom=false)=0.01
46 P(Server=false|HDD=false, CPU=false, Strom=false)=0.99
47 
48 P(Webservice=true|Server=true, Netzwerk=true)=1.0
49 P(Webservice=false|Server=true, Netzwerk=true)=0.0
50 P(Webservice=true|Server=true, Netzwerk=false)=0.9
51 P(Webservice=false|Server=true, Netzwerk=false)=0.1
52 P(Webservice=true|Server=false, Netzwerk=true)=0.7
53 P(Webservice=false|Server=false, Netzwerk=true)=0.3
54 P(Webservice=true|Server=false, Netzwerk=false)=0.1
55 P(Webservice=false|Server=false, Netzwerk=false)=0.9
56 
57 P(Datensicherheit=true|Server=true)=0.2
58 P(Datensicherheit=false|Server=true)=0.8
59 P(Datensicherheit=true|Server=false)=0.02
60 P(Datensicherheit=false|Server=false)=0.98

In den Zeilen 1-7 werden die Zufallsvariablen und ihre Zustände definiert. In den Zeilen 9-15 werden die Zufallsvariablen kausal miteinander verknüpft. Der Pfeil ist als Kante im Graph zu verstehen, sprich die Zufallsvariable rechts vom Pfeil ist bedingt abhängig von der Zufallsvariablen links vom Pfeil. In den Zeilen 17-60 werden die CPTs für die einzelnen Zufallsvariablen definiert. Wichtig ist, dass alle CPTs des Bayes-Netzes vollständig zu definieren sind, um ein valides Bayes-Netz zu erhalten.

Für den Texteditor wurden drei Validierungen implementiert:

  1. Zufallsvariablen müssen einzigartig sein.
  2. Zustände müssen für jede Zufallsvariable einzigartig sein.
  3. Wahrscheinlichkeiten müssen zwischen 0.0 und 1.0 liegen.

FMEA als DSL

Die DSL zur Erstellung einer FMEA orientiert sich an der bekannten Vorgehensweise. Zur Erläuterung wird hier wieder das Beispiel, der oben beschriebenen Foto-Community [[2]] herangezogen. Schrittweise wird so der Aufbau der DSL beschrieben.


DSL-Beispiel für Foto-Community als Download

Allgemeine Informationen

Eine mittels der DSL erstellte FMEA beginnt zunächt mit allgemeinen Informationen. Die FMEA ist mit einem Namen und einer Version zu versehen. Zusätzlich ist eine, für die FMEA verantwortliche Autorität anzugeben. Für unser Beispiel wählen wir den Namen FotoCommunityFMEA. Wir starten mit der Version 1 und referenzieren martin als verantwortliche Autorität.


1 fmea FotoCommunityFMEA version 1 responsible authority martin


Struktur-, Funktions- und Fehleranalyse

Nach den allgemeinen Informationen folgt die Analyse des Systems. Für jedes Systemelement, das wärend der Strukturanalyse definiert wird, ist ein Block vorgesehen. So auch für das System, das alle anderen Systemelemente beinhaltet. Der folgende Quelltextausschnitt zeigt die Definition des Systems Foto-Community.

In der ersten Zeile ist durch das Schlüsselwort system gekennzeichnet, dass die Definition des Systems folgt. Es wird mit dem Bezeichner FotoCommunity versehen. Auf das Schlüsselwort consisting of folgen in Zeile drei alle, dem Systemelement untergeordneten Systemelemente.

Innerhalb der äußeren geschweiften Klammern folgt nun die Funktionsanalyse für das Systeme FotoCommunity. Der Reihe nach werden alle Funktionen des Systems aufgelistet. Dies geschieht mit dem Schlüsselwort function, dem der Name der Funktion folgt. So wird z.B. in Zeile neun die Funktion Bild_mit_Metainformationen_erstellen definiert und implizit dem System FotoCommunity zugeordnet, da es innerhalb der entsprechenden, geschweiften Klammern definiert ist. In Zeile zehn folgen dem Schlüsselwort depending on die Abhängigkeiten der Funktion. In unserem Beispiel bestehen die Abhängigkeiten aus den Funktionen WebServer -> Webseite_ausliefern, WebServer -> Bild_hochladen und WebServer -> Daten_hochladen ApplicationServer -> Bild_mit_Metainformationen_anlegen. Abhängigkeiten werden durch das Systemelement, dass die Funktion anbietet und die Funktion selbst, getrennt durch einen Pfeil(->) beschrieben. Mit der Angabe der Abhängigkeiten ist die Funktionsanalyse für diese Funktion abgeschlossen.

Nach der Definition der Abhängigkeiten sind mögliche Fehler der Funktion anzugeben. Fehler werden innerhalb geschweifter Klammern, die auf die Funktion-Definition folgen, über das Schlüsselwort failure definiert. In unserem Beispiel hat die Funktion Bild_mit_Metainformationen_erstellen die möglichen Fehler langsam und defekt, die in Zeile 13 und 16 definiert sind. Ein Fehler kann von einem anderen Fehler verursacht werden. So wird der Fehler langsam beispielsweise durch WebServer -> Daten_hochladen -> langsam verursacht. Ähnlich wie die Abhängikgeiten werden Ursachen durch mehrere Bestandteile definiert. Der Reihe nach wird das Systemelement, dessen Funktion und deren Fehler, getrennt durch einen Pfeil(->) notiert. Sind alle Fehler und deren Ursachen für eine Funktionen definiert ist die Fehleranalyse für diese Funktion abgeschlossen.

Das folgende Codelisting zeigt nur einen kurzen Auszug der Analyse. Neben der FotoCommunity als System sind, wie in Zeile 23 angedeutet, alle Systemelemente inklusive ihrer Funktion und Fehler zu beschreiben. Für das System FotoCommunity sind zusätzlich alle fehleneden Funktionen zu definieren, was in Zeile 20 angedeutet ist.


 1 system FotoCommunity
 2 consisting of
 3 ApplicationServer, CacheServer, DatabaseServer, FileServer, SearchServer, WebServer
 4 {
 5 	/*
 6 	Bild mit Metainformationen erstellen
 7 	*/
 8 
 9 	function Bild_mit_Metainformationen_erstellen
10 	depending on
11 	WebServer->Webseite_ausliefern, WebServer->Bild_hochladen, WebServer->Daten_hochladen, ApplicationServer->Bild_mit_Metainformationen_anlegen
12 	{
13 		failure langsam
14 		caused by
15 		WebServer->Webseite_ausliefern->langsam, WebServer->Bild_hochladen->langsam, WebServer->Daten_hochladen->langsam, ApplicationServer->Bild_mit_Metainformationen_anlegen->langsam
16 		failure defekt
17 		caused by
18 		WebServer->Webseite_ausliefern->defekt, WebServer->Bild_hochladen->defekt, WebServer->Daten_hochladen->defekt, ApplicationServer->Bild_mit_Metainformationen_anlegen->defekt
19 	}
20         ...
21 }
22 
23 ...


Risikobewertung und Optimierung

Nach den ersten drei Schritten der FMEA, die der Analyse dienen, folgt mit Schritt vier und fünf die Risikobewertung und Optimierung. Für die Risikobewertung ist für jedes System und Systemelement ein FMEA-Bogen, der mit dem Schlüsselwort fmeasheet for eingeläutet wird(1. Zeile), zu erstellen. Dieser enthält für jeden möglichen Fehler des Systems oder Systemelements einen Block der mit dem Schlüsselwort failure und dem Bezeichner des Fehlers(Funktionsnamme und Fehlername) beginnt(z.B. 3. Zeile). In geschweiften Klammern folgen die verschiedenen Optimierungsstände des Fehlers, die mit den Schlüsselwort at und einem Zeitstempel beginnen(z.B. 5. Zeile). Nach der ersten Risikobewertung gibt es einen Optimierungsstand pro Fehler. Wird das Risikio des Fehler optimiert und eine zweite Risikobewertung durchgeführt, kommt für diesen Fehler ein Optimierungsstand hinzu. So wird jede Optmierung protokolliert. Innerhalb der geschweiften Klammern eines Optimierungsstands, wird die Risikobewertung durch die Schlüsselwörter severity, probability, detection und entsprechende Werte notiert. Ergänzt werden diese Werte gegebenenfalls durch Verweise auf Optimierungsmaßnahmen, die mit dem Schlüsselwort damagemitigationaction, counteraction oder detectionaction sowie dem Namen der Maßnahme festgehalten werden.

Das folgende Codelisting zeigt den FMEA-Bogen für den Web-Server aus dem obigen Beispiel.

 1 fmeasheet for WebServer
 2 {
 3 	failure Webseite_ausliefern->defekt
 4 	{
 5 		at 2014-01-06T00:00:00.000+0000
 6 		{
 7 			severity = 3
 8 			probability = 3
 9 			detection = 3
10 			detectionaction monitoring
11 		}
12 	}
13 	failure Bild_ausliefern->defekt
14 	{
15 		at 2014-01-06T00:00:00.000+0000
16 		{
17 			severity = 5
18 			probability = 3
19 			detection = 3
20 			detectionaction monitoring
21 		}
22 	}
23 	failure Bild_hochladen->defekt
24 	{
25 		at 2014-01-06T00:00:00.000+0000
26 		{
27 			severity = 3
28 			probability = 3
29 			detection = 3
30 			detectionaction monitoring
31 		}
32 	}
33 	failure Daten_hochladen->defekt
34 	{
35 		at 2014-01-06T00:00:00.000+0000
36 		{
37 			severity = 3
38 			probability = 3
39 			detection = 3
40 			detectionaction monitoring
41 		}
42 	}
43 	failure Webseite_ausliefern->langsam
44 	{
45 		at 2014-01-06T00:00:00.000+0000
46 		{
47 			severity = 3
48 			probability = 3
49 			detection = 3
50 			detectionaction monitoring
51 		}
52 	}
53 	failure Bild_ausliefern->langsam
54 	{
55 		at 2014-01-06T00:00:00.000+0000
56 		{
57 			severity = 3
58 			probability = 3
59 			detection = 3
60 			detectionaction monitoring
61 		}
62 	}
63 	failure Bild_hochladen->langsam
64 	{
65 		at 2014-01-06T00:00:00.000+0000
66 		{
67 			severity = 3
68 			probability = 3
69 			detection = 3
70 			detectionaction monitoring
71 		}
72 	}
73 	failure Daten_hochladen->langsam
74 	{
75 		at 2014-01-06T00:00:00.000+0000
76 		{
77 			severity = 3
78 			probability = 3
79 			detection = 3
80 			detectionaction monitoring
81 		}
82 	}
83 }

Das folgende Codelisting zeigt den FMEA-Bogen für den Web-Server aus dem obigen Beispiel, nach der ersten Optimierung. In Zeile 22 ist in Optimierungsstand hinzugekommen. Dort ist, in Zeile 26 die verbesserte Entdeckbarkeit festgehalten. Erreicht wurde dies durch die, in Zeile 27 notierte Optimierungsmaßnahme EMail_Benachrichtigung.

 1 fmeasheet for WebServer
 2 {
 3 	failure Webseite_ausliefern->defekt
 4 	{
 5 		at 2014-01-06T00:00:00.000+0000
 6 		{
 7 			severity = 3
 8 			probability = 3
 9 			detection = 3
10 			detectionaction monitoring
11 		}
12 	}
13 	failure Bild_ausliefern->defekt
14 	{
15 		at 2014-01-06T00:00:00.000+0000
16 		{
17 			severity = 5
18 			probability = 3
19 			detection = 3
20 			detectionaction monitoring
21 		}
22 		at 2014-02-20T00:00:00.000+0000
23 		{
24 			severity = 5
25 			probability = 3
26 			detection = 1
27 			detectionaction monitoring, EMail_Benachrichtigung
28 		}
29 	}
30 	failure Bild_hochladen->defekt
31 	{
32 		at 2014-01-06T00:00:00.000+0000
33 		{
34 			severity = 3
35 			probability = 3
36 			detection = 3
37 			detectionaction monitoring
38 		}
39 	}
40 	failure Daten_hochladen->defekt
41 	{
42 		at 2014-01-06T00:00:00.000+0000
43 		{
44 			severity = 3
45 			probability = 3
46 			detection = 3
47 			detectionaction monitoring
48 		}
49 	}
50 	failure Webseite_ausliefern->langsam
51 	{
52 		at 2014-01-06T00:00:00.000+0000
53 		{
54 			severity = 3
55 			probability = 3
56 			detection = 3
57 			detectionaction monitoring
58 		}
59 	}
60 	failure Bild_ausliefern->langsam
61 	{
62 		at 2014-01-06T00:00:00.000+0000
63 		{
64 			severity = 3
65 			probability = 3
66 			detection = 3
67 			detectionaction monitoring
68 		}
69 	}
70 	failure Bild_hochladen->langsam
71 	{
72 		at 2014-01-06T00:00:00.000+0000
73 		{
74 			severity = 3
75 			probability = 3
76 			detection = 3
77 			detectionaction monitoring
78 		}
79 	}
80 	failure Daten_hochladen->langsam
81 	{
82 		at 2014-01-06T00:00:00.000+0000
83 		{
84 			severity = 3
85 			probability = 3
86 			detection = 3
87 			detectionaction monitoring
88 		}
89 	}
90 }

Die FMEA-Bögen verweisen auf verschiedene Optimierungsmaßnahmen, deren Definition nach den FMEA-Bögen folgt. Hier unterscheiden wir wieder zwischen damagemitigationaction, counteraction und detectionaction. Sie werden mit dem entsprechendem Schlüsselwort und einem Namen eingeleitet. Für jede Maßnahme wird Ausführungsdatum und eine verantwortliche Person festgehalten. Das folgende Codelisting zeigt die Definition zweier Entdeckungsmaßnahmen.

1 detectionaction monitoring executed at 2014-01-06T00:00:00.000+0000
2 has responsible authorithy administrator
3 detectionaction EMail_Benachrichtigung executed at 2014-02-20T00:00:00.000+0000
4 has responsible authorithy administrator

Verantwortlichkeiten

Zuletzt lassen sich verantwortliche Personen und Unternehmen definieren. Sie haben jeweils einen Namen und Personen können einem Unternehmen zugeordnet werden.

1 company hsrm
2 person administrator
3 person martin employed at hsrm

Konklusion

Abschließend ist festzuhalten, dass die gestellten Aufgaben im Rahmen des Masterprojektes erledigt wurden und somit für die ausgewählten Risikoverfahren FMEA und Bayes-Netze jeweils eine Ontologie und eine zugehörige DSL erstellt wurde. Beide Modelle befinden sich in einem lauffähigen Zustand.

Inwiefern die erarbeiteten Verfahren praxistauglich sind, soll im Rahmen zweier sich anschließender Masterarbeiten überprüft werden. Dabei ist vor allem die Verknüpfung mit dem zu managendem System (System-Ontologie) durchzuführen. Mittels dieser Verknüpfung soll eine Risikobeurteilung eines konkreten Systemzustandes möglich sein.

Literartur

Bücher

  • Grundkurs Künstliche Intelligenz: Eine praxisorientierte Einführung (Wolfgang Ertel)
  • FMEA – Einführung und Moderation (Martin Werdich)
  • OntoFMEA (Lars Uwe Dittmann)
  • Ontologien - Konzepte, Technologien und Anwendungen (Heiner Stuckenschmidt)
  • Produktionsmanagement (Andreas Syska)
  • Semantic Web - Grundlagen (Pascal Hitzler, Markus Krötzsch, Sebastian Rudolph, York Sure)
  • Von Ontologien zu Bayes-Netzwerken: Entwicklung einer Modellierungsumgebung zur Repräsentation unscharfen Wissens (Philipp B. Hering)

Paper/Artikel

  • Using FMEA models and ontologies to build diagnostic models (Burton H. Lee)
  • A Review of Research on Risk Analysis Methods for IT Systems (Sardar Muhammad Sulaman, Kim Weyns, Martin Höst)
  • Automated IT Management using Ontologies (Andreas Textor, Fabian Meyer, Reinhold Kroeger)
  • Bayesian Networks (Irad Ben-Gal)
  • Development of Educational Ontology for Software Risk Analysis (C. R. Rene Robin, G. V. Uma)
  • Ein Bayes’scher Ansatz zur Bewertung technischer Risiken im Entwicklungsprozess (Michael Kempf)
  • OntoBayes: An Ontology-Driven Uncertainty Model (Yi Yang, Jacques Calmet)
  • Ontology-based generation of Bayesian networks (Stefan Fenz, A Min Tjoa, Marcus Hudec)
  • Software FMEA: A Learning Experience (Ajit Ashok Shenvi)
  • Improving the analysis of dependable systems by mapping fault trees into Bayesian networks(A. Bobbio, L. Portinale, M. Minichino, E. Ciancamerla)