Ontology — Wissensgraph der Fabrik
Überblick
PlantPulse Ontology ist ein Wissensgraph (Knowledge Graph) der Fabrik, der die Entitäten einer Fabrik und ihre Beziehungen als Graph abbildet.
Sie hilft der KI, Fragen präzise zu beantworten, die sich nur durch das Verfolgen von Beziehungen klären lassen — etwa "Welche Sensoren sind an dieser Anlage angeschlossen?" oder "Wie weit reichen die Auswirkungen, wenn diese Pumpe ausfällt?". Geht es nur um die Hierarchie, genügt der Asset-Baum; für Auswirkungsausbreitung oder das Kreuzen mehrerer Bedingungen wird jedoch ein Graph benötigt.
Die Ontologie ist kein separater Dienst, sondern läuft innerhalb von server-web der PlantPulse Platform. Der Graph ist ein In-Memory-RDF-Modell auf Basis von Apache Jena und wird periodisch aus der Plattform-DB als Quelle neu aufgebaut. Eine separate Graph-DB muss weder installiert noch betrieben werden.
Der frühere eigenständige Dienst plantpulse-ontology(:8888) wurde archiviert. Die Werkzeugnamen aus jener Zeit
(ontology_get_stats, ontology_get_graph usw.) existieren nicht mehr.
Knotentypen (11 Arten)
Dies sind die Klassen, die im RDF-Graphen vorkommen.
| Klasse | Beschreibung |
|---|---|
Site | Werk/Standort |
Area | Bereich (Fertigungsgebäude, Utilities usw.) |
Line | Produktionslinie |
Equipment | Anlage (Abfüller, Verpackungsmaschine usw.) |
Asset | Gemeinsame Oberklasse der obigen Hierarchieknoten — wird verwendet, um Assets hierarchieübergreifend abzufragen |
Tag | Sensor-Tag |
AlarmConfig | Alarmkonfiguration |
CommandDef | Definition eines Anlagenbefehls |
Statement | Anlagenspezifikation |
Document | Anlagenbezogenes Anhangdokument |
RegistryEntry | UNS-Registry-Eintrag |
Hierarchiebeziehung: Site → Area → Line → Equipment → Tag
Beziehungstypen (3 Arten)
Unabhängig von der Hierarchie bestehen zwischen Assets gerichtete Beziehungen. 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 |
Graph-Werkzeuge (integriertes MCP)
Die KI greift über die folgenden drei Werkzeuge auf den Graphen zu. Die Namen ähneln sich, aber sie liefern unterschiedliche Achsen zurück — diese drei zu unterscheiden ist der Kern dieses Dokuments.
| Werkzeug | Rückgabe | Einsatzzweck |
|---|---|---|
get_ontology | ISA-95-Strukturzusammenfassung eines Standorts + Baum (Bereich/Linie/Anlage, Anzahl Tags je Anlage) | "Wie ist dieser Standort aufgebaut?", "Wie viele Anlagen gibt es?" |
query_ontology | Gerichteter Beziehungsgraph (root + nodes[] + edges[]) | "Wie weit reicht die Auswirkung, wenn X ausfällt?", "Was versorgt X?" |
query_sparql | Ergebniszeilen von SPARQL SELECT/ASK | Abfragen, die mehrere Bedingungen kreuzen müssen |
Wird ausschließlich die reine Hierarchie benötigt, ist nicht die Ontologie, sondern get_asset_tree besser geeignet.
get_ontology Wichtige Parameter
| Parameter | Beschreibung |
|---|---|
site_id | Pflicht. Ist nur der Name bekannt, wird die ID zuvor mit search_domains aufgelöst |
asset_id | Wurzel des Teilbaums. Anzugeben, wenn nur eine bestimmte Linie/Anlage betrachtet wird |
depth | Ausklapptiefe unterhalb der Wurzel. Ausgehend von der Standortwurzel: 1=Bereich, 2=Linie, 3=Anlage |
include_tags | Bei true wird an den Anlagenknoten die Liste der Tag-Namen mitgeliefert. Standardmäßig nur die Anzahl (tag_count) |
total_tag_countDas Aufsummieren der tag_count je Knoten ist falsch. Tags nicht ausgeklappter Zweige fehlen dabei.
Enthält die Antwort total_tag_count_unknown=true, bedeutet das, dass nicht gezählt werden konnte — schätzen Sie nicht,
sondern grenzen Sie den Bereich ein und fragen Sie erneut ab.
query_ontology Wichtige Parameter
| Parameter | Standardwert | Beschreibung |
|---|---|---|
entity_id | (Pflicht) | Start-Entität der Traversierung |
direction | DOWN | DOWN=Auswirkung stromabwärts, UP=Ursache stromaufwärts, BOTH |
relation_type | (alle) | FEEDS / DEPENDS_ON / PRODUCES |
depth | 2 | Traversierungstiefe 1~5 |
Beispiel: Auswirkungsausbreitung ermitteln
"Wie weit reicht die Auswirkung, wenn Abfüller DJ_M_01_1 ausfällt?" — mit direction=DOWN wird stromabwärts verfolgt.
[Equipment: DJ_M_01_1] ← 시작 노드
│ FEEDS
┌──────┴──────┐
▼ ▼
[Equipment: [Equipment:
건조기] 컨베이어]
│ FEEDS
▼
[Equipment: 포장기]
Die Antwort enthält sowohl die besuchten Knoten (nodes[]) als auch die verbundenen Beziehungen (edges[]). Wurde die Traversierung durch die Tiefenbegrenzung gestoppt, wird truncated angezeigt; steht dieser Wert auf true, erhöhen Sie depth und fragen Sie erneut ab.
Aktualisierungsverfahren
Der Graph wird periodisch neu aufgebaut, wobei die Plattform-DB als Quelle dient. Werden Anlagen hinzugefügt oder Tags geändert, wirkt sich das erst im nächsten Aktualisierungszyklus aus — eine soeben registrierte Anlage kann daher im Graphen noch fehlen. Der Aktualisierungszyklus wird über die Plattformeinstellung semantic.graph.refresh.minutes festgelegt.
Anwendungsszenarien
| Szenario | Vorgehen |
|---|---|
| Fabrikaufbau erfassen | Mit get_ontology Struktur aus Bereich/Linie/Anlage und Tag-Anzahl auf einen Blick |
| Ursache einer Anomalie verfolgen | query_ontology direction=UP — Ursachenkandidaten stromaufwärts der auffälligen Anlage suchen |
| Umfang der Stillstandsauswirkung bestimmen | query_ontology direction=DOWN — Bereich, der sich bei Stillstand stromabwärts ausbreitet |
| Mehrere Bedingungen kreuzen | query_sparql — zusammengesetzte Bedingungen wie "Anlagen der Linie 3 mit Tags, für die ein Alarm konfiguriert ist" |