Executive Summary · Stand März 2026

EPIC

Engineering Product Information Center

Version 0.86

Eine spezialisierte Web-Applikation zur strukturierten Verwaltung von Produktdaten, Technischen Daten, Variantenräumen und Stücklisten für komplexe Industrieprodukte.

4

Hierarchieebenen

3

Datenfluss-Typen

86

Versionen / Fixes

2

Export-Formate

Das Problem

Industrieprodukte sind komplex — ihre Datenverwaltung bisher nicht adäquat abgebildet.

🗂️

Heterogene Datenquellen

Technische Daten liegen verteilt in Excel, PDFs und ERP-Systemen — ohne einheitliche Struktur oder Hierarchie.

🔀

Variantenkomplexität

Ein Produkt existiert in hunderten Kombinationen (Nennweite, Anschlussart, Körperform). Welche Daten gelten für welche Variante?

🔗

Redundanz & Inkonsistenz

Gleiche Werte werden an vielen Stellen gepflegt. Änderungen führen zu inkonsistenten Datenständen in Dokumentationen.

📤

Kein strukturierter Export

Der Weg von der Datenbank in Redaktionssysteme (ST4) oder Kundenportale ist manuell und fehleranfällig.

Kernkonzepte

EPIC basiert auf drei orthogonalen Konzepten, die zusammen das gesamte Produktdatenmodell abdecken.

🏗️

Produktstruktur

Hierarchischer Aufbau: Produkt → Komponente → Sub-Komponente. Jede Ebene kann eigene technische Daten tragen oder von Kindern aggregieren.

📐

Variantenraum (Space)

Jede Komponente besitzt einen Raum aus Merkmalen (Anschlussart, Nennweite, …). Technische Daten können für Teilräume (Kombinationen) gelten.

⚙️

Constraints

Regeln definieren, welche Merkmalskombinationen erlaubt, verboten oder abhängig voneinander sind — auf Item- oder Produktebene.

Drei Datenfluss-Typen für Technische Daten

direkt

Wert ist direkt auf dem Item gepflegt. Höchste Priorität.

vererbt

Top-down: Sub-Komponente erbt transitiv vom Parent (und Grandparent).

aggregiert

Bottom-up: Parent aggregiert direkte / eigene Kindwerte (MIN / MAX / SUM / Keine).

Produkthierarchie

Reales Beispiel: D40 ohne Anbaukomponenten — 5 Hierarchieebenen.

Produkt D40 — aggregiert TDs aus allen Komponenten (MIN / MAX / SUM)

Komponente AD40 — direkt eigene TDs

Komponente BD00 — direkt z.B. Medientemperatur −50 … 200 °C

Sub-Komp. BD00 Clamp — vererbt von BD00

Sub-Sub BD00 88,8T — vererbt transitiv von BD00 (via BD00 Clamp)

Sub-Sub-Sub BD00 88,8T DN15 — vererbt + direkt Maße (H1, L, ød1, ød3)

Sub-Sub-Sub BD00 88,8T DN20 / DN25 — analog, je eigene Maßwerte

Sub-Sub BD00 80,8P — vererbt transitiv + DN15 / DN20 / DN25 mit eigenen Maßen

Sub-Komp. BD00 Stutzen — vererbt von BD00 · enthält BD00 17 / BD00 59 / BD00 60 mit DN-Varianten

Komponente AX40 · DD00 · ID00 — weitere Komponenten analog

Schlüsselprinzip: Vererbt fließt ausschließlich top-down (transitiv über beliebig viele Ebenen). Aggregiert fließt ausschließlich bottom-up — nur aus direkt definierten oder selbst aggregierten Kindwerten.

Aggregation über die Ebenen

Bottom-up: Werte steigen von den Blättern zum Produkt auf — am Produkt gewinnt der ungünstigste Wert.

direkt selbst gepflegter Wert vererbt top-down vom Parent aggregiert bottom-up aus Kindern

Beispiel · Min. Medientemperatur (TD-Definition: Aggregationsmodus = MAX → ungünstigster Minimalwert gewinnt)

Produkt D40 aggregiert −10 °C = MAX(−50 °C, −10 °C) → ungünstigster Wert der Komponenten

↑ aggregiert aus

Komponente BD00 direkt −50 °C

↓ vererbt

Sub-Komp. BD00 Clamp vererbt −50 °C

↓ transitiv

Sub-Sub BD00 88,8T vererbt −50 °C

DN-Varianten erben ebenfalls — tragen nichts zur Aggregation bei

Komponente AD40 direkt −10 °C

Eigenständige Komponente ohne Sub-Komponenten.
Trägt −10 °C direkt zur Aggregation bei.

⚠ AD40 bestimmt das Produkt-Ergebnis,
weil −10 °C > −50 °C (MAX-Modus)

Verfügbare Aggregationsmodi

MAX
Ungünstigster Minimalwert (z.B. Min. Temperatur)

MIN
Ungünstigster Maximalwert (z.B. Max. Druck)

SUM
Summe aller Werte (z.B. Gewicht)

Keine
Alle Quellwerte aufgelistet (z.B. Zertifikate)

Wichtig: Nur direkte und aggregierte Kindwerte fließen in die Aufwärts-Aggregation ein. Vererbte Kindwerte werden ausgeschlossen — sie stammen von oben und würden sonst doppelt gewertet.

Zentrale Stammdaten

TD-Definitionen, Optionen und Optionswerte werden einmalig zentral gepflegt und von allen Produkten referenziert.

📋 TD-Definitionen

Legen fest, welche Technischen Daten existieren und wie sie aggregiert werden.

Min. Medientemperatur
Typ: Zahl · Einheit: °C · Aggregation: MAX

Max. Betriebsdruck
Typ: Zahl · Einheit: bar · Aggregation: MIN

FDA-konform
Typ: Bool · Aggregation: Keine

… weitere Definitionen

🎛️ Option-Definitionen

Definieren die Merkmale des Variantenraums — einmal angelegt, für alle Komponenten nutzbar.

Anschlussart
Typ: Auswahl

Nennweite
Typ: Auswahl

Körperform
Typ: Auswahl

… weitere Definitionen

🏷️ Option-Werte

Konkrete Ausprägungen je Option-Definition — mit Bestellcode und Anzeigetext.

Clamp ASME BPE
Anschlussart · Code: 88

DN15
Nennweite · Code: 15

Durchgangskörper
Körperform · Code: T

… weitere Werte

Vorteile der zentralen Pflege

✔ Single Source of Truth — Umbenennung einer Option wirkt sich sofort auf alle Produkte aus

✔ Konsistenter Export — interne Namen und Bestellcodes immer einheitlich in ST4 und CSV

✔ Wiederverwendung — Optionen und Werte können komponentenübergreifend genutzt werden

✔ Constraint-Basis — Regeln beziehen sich auf dieselben zentralen IDs, keine Duplikate

Funktionsumfang

✔

Struktureditor mit Baumnavigation

Interaktiver Produktbaum. Items navigierbar; direkte TD-Pflege per Modal.
✔

Technische Daten: Einzel- & Tabellenmodus

Einzelwerte oder zweidimensionale Tabellen (z.B. Druck × Temperatur) je TD-Definition. Zeilen/Spalten kommen aus dem Variantenraum.
✔

Variantenraum (Space) mit Coverage-Validierung

Raum-Definitionen je Komponente. Sub-Komponenten definieren Teilräume. Vollständigkeitsreport zeigt fehlende Kombinationen.
✔

Option-Constraints (required / forbidden / exclusive / dependent)

Regelwerk für Variantenkombinationen — global oder item-spezifisch, mit Herkunfts-Badge.
✔

Einheitenumrechnung

Einheitenbibliothek mit linearen Umrechnungspaaren (bar↔psi, mm↔inch, °C↔°F, …). Live-Toggle in der UI.
✔

Interface-Constraints zwischen Komponenten

Schnittstellen-Einschränkungen filtern inkompatible TD-Werte beim Aggregieren automatisch heraus.
✔

Export: ST4-CSV & generisches CSV

Strukturierter Export aller TD inkl. Varianten, Einheiten und Composites. Europäisches Zahlenformat.
✔

Vollständigkeits-Report

Zeigt pro Komponente, welche Variantenkombinationen TD-Lücken haben — mit lesbaren Kombinationsbezeichnungen.
✔

Admin-Bereich

Verwaltung von TD-Definitionen, Option-Definitionen, Einheiten, Constraints und Quelldaten-Referenzen.

Technische Architektur

Bewusst schlank gehalten: kein Framework-Overhead, direkt deploybar auf XAMPP / Apache + PHP.

Frontend

Bootstrap 5 UI

Vanilla JS (app.js)

structure_editor.js

component_space.js

↕ REST / JSON

API Layer

api/index.php (Router)

Controllers / Endpoints

↕ PHP-Funktionsaufrufe

Service Layer

technical_data_service.php
3.500+ Zeilen Kernlogik

space_service.php

options_service.php

export_service.php

unit_conversion_service.php

↕ PDO / Named Placeholders

Datenbank

MySQL · Datenbank: gpa

PHP 8.x

MySQL / MariaDB

Apache .htaccess Routing

Bootstrap 5

Vanilla JavaScript

PDO + Prepared Statements

REST / JSON API

XAMPP (Windows)

Roadmap

Geplante Weiterentwicklungen auf Basis identifizierter Bedarfe.

Geplant · KI-Integration

🤖 PDF-Datenblatt-Analyse

Upload eines Hersteller-PDFs → automatisches Mapping auf TD-Definitionen, Optionen und Constraints via Claude API. Spart manuelle Erfassung.

Geplant · Datenqualität

📊 Erweiterte Vollständigkeitsprüfung

Proaktive Warnungen bei fehlenden Pflicht-TDs pro Variante. Integration in den Export-Workflow.

Geplant · Integration

🔗 ERP / PIM Anbindung

Bidirektionaler Datenaustausch mit vorgelagerten Systemen (SAP, Odoo) über standardisierte API-Endpunkte.

Langfristig

🌐 Multi-User / Rollen

Mehrbenutzer-Betrieb mit rollenbasierter Zugriffskontrolle (Redakteur, Freigeber, Admin) und Änderungshistorie.

Einordnung

EPIC ist kein ERP und kein klassisches PIM — es füllt die Lücke dazwischen.

🏭

ERP (z.B. SAP)

Transaktionsdaten, Bestellungen, Lager, Finanzen. Keine tiefe Produktstrukturlogik mit Vererbung/Aggregation.

⭐

EPIC

Produktstruktur + Technische Daten + Varianten + Constraints + Export. Spezialisiert, leichtgewichtig, anpassbar.

📚

PIM (z.B. Akeneo)

Marketing-Produktdaten, Medien, Channels. Keine Hierarchie-Aggregationslogik oder Variantenraum-Berechnung.