Ontologie (Wissensgraph der Anlage)

Übersicht

Die PlantPulse Ontologie ist ein Anlagen-Wissensgraph (Knowledge Graph), der die Entitäten der Anlage und ihre Beziehungen grafisch darstellt.

Sie hilft der KI, Fragen präzise zu beantworten, die sich nur durch das Nachverfolgen von Beziehungen lösen lassen, wie z. B.: „Welche Sensoren sind mit dieser Anlage verbunden?" oder „Wenn diese Pumpe ausfällt, welche Bereiche sind betroffen?". Wenn nur die Hierarchie benötigt wird, reicht ein Asset-Baum; für die Ausbreitung von Auswirkungen oder das Kreuzen mehrerer Bedingungen ist jedoch ein Graph erforderlich.

In die Plattform integriert

Die Ontologie ist kein separater Dienst, sondern läuft innerhalb der PlantPulse-Plattform server-web. Der Graph ist ein In-Memory-RDF-Modell basierend auf Apache Jena und wird regelmäßig aus der Plattform-DB neu erstellt. Eine separate Graph-Datenbank muss weder installiert noch betrieben werden.

Der frühere eigenständige Dienst plantpulse-ontology(:8888) wurde archiviert. Die damaligen Toolnamen (ontology_get_stats, ontology_get_graph usw.) existieren nicht mehr.

Knotentypen (11 Typen)

Dies sind die Klassen, die im RDF-Graph vorkommen.

Klasse	Beschreibung
`Site`	Werk/Standort
`Area`	Bereich (Produktionshalle, Versorgung usw.)
`Line`	Produktionslinie
`Equipment`	Anlage (Injektor, Verpackungsmaschine usw.)
`Asset`	Gemeinsame Oberklasse der obigen Hierarchieknoten – wird verwendet, um Assets unabhängig von der Hierarchie abzufragen
`Tag`	Sensor-Tag
`AlarmConfig`	Alarmkonfiguration
`CommandDef`	Anlagenbefehlsdefinition
`Statement`	Anlagenspezifikation
`Document`	Anlagenanhangdokument
`RegistryEntry`	UNS-Registry-Eintrag

Hierarchische Beziehung: Site → Area → Line → Equipment → Tag

Beziehungstypen (3 Typen)

Unabhängig von der Hierarchie gibt es gerichtete Beziehungen zwischen Assets. Fragen zur Auswirkungsausbreitung folgen diesen Beziehungen.

Beziehung	Bedeutung
`FEEDS`	A versorgt B (stromaufwärts → stromabwärts)
`DEPENDS_ON`	A hängt von B ab
`PRODUCES`	A produziert B

Graphtools (integrierter MCP)

Die KI greift über die folgenden drei Tools auf den Graphen zu. Die Namen sind ähnlich, aber die zurückgegebenen Achsen unterscheiden sich – diese drei zu unterscheiden ist der Kern dieses Dokuments.

Tool	Rückgabewert	Verwendung
`get_ontology`	ISA-95-Strukturübersicht eines Standorts + Baum (Bereich/Linie/Anlage, Tag-Anzahl pro Anlage)	„Wie ist dieser Standort aufgebaut?", „Wie viele Anlagen gibt es?"
`query_ontology`	Gerichteter Beziehungsgraph (`root` + `nodes[]` + `edges[]`)	„Wenn X ausfällt, welche Bereiche sind betroffen?", „Was versorgt X?"
`query_sparql`	SPARQL SELECT/ASK-Ergebniszeilen	Abfragen, die mehrere Bedingungen kreuzen

Wenn nur die reine Hierarchie benötigt wird, ist get_asset_tree geeigneter als die Ontologie.

`get_ontology` Wichtige Parameter

Parameter	Beschreibung
`site_id`	Erforderlich. Wenn nur der Name bekannt ist, wird die ID zuerst über `search_domains` aufgelöst
`asset_id`	Wurzel des Teilbaums. Wird angegeben, um nur eine bestimmte Linie/Anlage zu sehen
`depth`	Erweiterungstiefe unter der Wurzel. Bezogen auf die Standortwurzel: `1`=Bereich, `2`=Linie, `3`=Anlage
`include_tags`	Wenn `true`, werden die Namen der Tags im Anlageknoten aufgelistet. Standard ist nur die Anzahl (`tag_count`)

Vertrauen Sie nur total_tag_count für die Gesamtzahl der Tags

Wenn Sie die tag_count pro Knoten summieren, stimmt das nicht. Tags von nicht expandierten Zweigen fehlen. Wenn total_tag_count_unknown=true in der Antwort vorhanden ist, bedeutet das, dass nicht gezählt werden konnte; treffen Sie keine Annahmen, sondern verengen Sie den Bereich und fragen Sie erneut.

`query_ontology` Wichtige Parameter

Parameter	Standardwert	Beschreibung
`entity_id`	(erforderlich)	Startentität für die Suche
`direction`	`DOWN`	`DOWN`=stromabwärtige Auswirkung, `UP`=stromaufwärtige Ursache, `BOTH`
`relation_type`	(alle)	`FEEDS` / `DEPENDS_ON` / `PRODUCES`
`depth`	`2`	Suchtiefe 1~5

Beispiel für die Suche nach Auswirkungsausbreitung

„Wenn der Injektor DJ_M_01_1 ausfällt, welche Bereiche sind betroffen?" – Verfolgen Sie stromabwärtige Beziehungen mit direction=DOWN.

     [Equipment: DJ_M_01_1] ← 시작 노드
              │ FEEDS
       ┌──────┴──────┐
       ▼             ▼
 [Equipment:    [Equipment:
  건조기]         컨베이어]
       │ FEEDS
       ▼
 [Equipment: 포장기]

Die Antwort enthält die besuchten Knoten (nodes[]) und die verbundenen Beziehungen (edges[]). Wenn die Tiefenbegrenzung erreicht wurde und nicht weiter gegangen werden konnte, wird truncated angezeigt. Wenn dieser Wert true ist, erhöhen Sie depth und fragen Sie erneut.

Aktualisierungsmethode

Der Graph wird regelmäßig aus der Plattform-DB neu erstellt. Wenn Sie eine Anlage hinzufügen oder ein Tag ändern, wird dies im nächsten Aktualisierungszyklus berücksichtigt. Eine gerade registrierte Anlage ist möglicherweise noch nicht im Graph. Der Aktualisierungszyklus wird über die Plattformeinstellung semantic.graph.refresh.minutes festgelegt.

Anwendungsszenarien

Szenario	Vorgehen
Anlagenstruktur verstehen	`get_ontology` für Struktur von Bereich/Linie/Anlage und Tag-Anzahl auf einmal
Ursache von Anomalien verfolgen	`query_ontology` `direction=UP` – stromaufwärtige Ursachen bei der anomalen Anlage suchen
Auswirkungsbereich bei Ausfall abschätzen	`query_ontology` `direction=DOWN` – Ausbreitung stromabwärts bei Ausfall
Mehrere Bedingungen kreuzen	`query_sparql` – komplexe Bedingungen wie „Anlagen in Linie 3 mit alarmierten Tags"

Übersicht​

Knotentypen (11 Typen)​

Beziehungstypen (3 Typen)​

Graphtools (integrierter MCP)​

get_ontology Wichtige Parameter​

query_ontology Wichtige Parameter​

Beispiel für die Suche nach Auswirkungsausbreitung​

Aktualisierungsmethode​

Anwendungsszenarien​