Flo
0 Followers · 0 Following
  • Joined on 2025-11-29
Repositories Projects
1
 Packages Public Activity Starred Repositories
1
Sort
Oldest Alphabetically Reverse alphabetically Most recently updated Least recently updated

  • ProductionBase

    0 Open
    0 Closed

    ProductionBase Roadmap & Zielarchitektur v0.4

    Version 0.4 | Planungshorizont: 1-2 Jahre | Stand: 03.07.2026 | LagerChecker ergänzt

    Leitidee
    ProductionBase wird das modulare Betriebssystem fuer die Produktion: jedes Modul ist eigenstaendig nutzbar, liefert aber standardisierte Events, Zustandsdaten und nachvollziehbare Auswertungen in ein gemeinsames Dashboard.
    Wichtigste Leitplanke
    Keine Datenwueste und keine Blackbox: Jede Kennzahl, Warnung oder ML-Prognose muss auf Quelle, Zeitpunkt, Version, Regel/Modell und Begruendung zurueckfuehrbar sein.

    Inhaltsübersicht

      1. Executive Summary inkl. aktuellem Projektstand
      1. Zielbild ProductionBase
      1. Designprinzipien
      1. Referenzarchitektur
      1. Module und fachlicher Scope
      1. Plattformdienste
      1. Datenarchitektur und Nachvollziehbarkeit
      1. ML-Roadmap für Fräserverschleiß und Spindelhealth
      1. Security, Datenschutz und blameless Kultur
      1. Schnittstellenkatalog
      1. Roadmap 2026-2028
      1. Governance, Dokumentation und Betrieb
      1. Risiken und Go/No-Go-Kriterien
      1. Erste konkrete nächste Schritte

    • Anhang: Tech-Stack, Glossar, Quellen

    1. Executive Summary

    ProductionBase soll langfristig der zentrale Rahmen fuer alle produktionsnahen Softwaremodule bei Sana werden. Die Toolbase bleibt ein eigenstaendiges Modul, wird aber in eine gemeinsame Plattform eingebettet, die Stammdaten, Authentifizierung, Ereignisse, Schnittstellen, Monitoring, Dokumentation, Dashboards und spaeter ML-Auswertungen standardisiert.

    Die Architektur muss bewusst modular bleiben: Toolbase, Ottinator, MPRBase, Holzherrscher, LagerChecker, Viking, SanaMontage und der SolidworksPDFExporter sollen auch einzeln funktionieren. Gleichzeitig sollen sie ueber klare APIs und Events gemeinsam ein verstaendliches Lagebild der Produktion erzeugen.

    Der kritischste Erfolgsfaktor ist nicht die Technik, sondern Datenvertrauen: Jede Aussage im Dashboard muss erklaeren koennen, woher sie kommt, wann sie entstanden ist, welche Regeln angewandt wurden und welche Unsicherheit bleibt. Genau deshalb werden Datenkatalog, Schnittstellenregister, Audit-Trail, Modellversionen und Human-Review-Prozesse als Grundbausteine definiert - nicht als Spaetphase.

    1.1 Aktueller Projektstand und Roadmap-Konsequenz (Update v0.4)

    Die Roadmap wird ab Version 0.2 nicht mehr als reines Zielbild betrachtet, sondern als Migrationspfad aus bereits laufenden Systemen. Wichtig ist deshalb: Bestehende produktive oder fast produktive Systeme werden stabilisiert und angebunden, statt durch einen grossen Plattform-Umbau ersetzt zu werden.

    Bereich Aktueller Stand Konsequenz fuer die Roadmap
    SolidworksPDFExporter Ca. 95 % funktionsfaehig; Rollout steht kurz bevor. Als fast fertiges Modul behandeln: nur noch Rollout, Jobstatus, zentrale Ergebnisablage, Logging und spaetere ProductionBase-Anbindung sauber definieren.
    Toolbase Befindet sich im Rollout. Prioritaet liegt auf Stabilisierung, Security, Update-Prozess, API-Vertraegen, Events und Monitoring. Keine tiefen Umbauten, die den Rollout gefaehrden.
    Ottinator Sehr fruehe Entwicklungsphase. Jetzt Datenmodell, IDs, Schnittstellen und Regeln sauber festlegen, bevor fachliche Komplexitaet entsteht. MVP klein halten.
    Produktionsueberwachung Laeuft bereits, aktuell jedoch auf manuellen Eingaben. Nicht ersetzen, sondern als bestehende operative Realitaet integrieren. Schrittweise manuelle Status durch automatische Events aus Saege, Kante, CNC, Lager und Montage ergaenzen.
    Scriptstube Montageplanung Bereits im Einsatz; noch ohne Monteur-App und ohne strukturierte Rueckfuehrung von Reklamationen. Als bestehendes Planungssystem respektieren. App, Reklamationsworkflow und Rueckmeldungen als Erweiterung/Schnittstelle planen.
    Scriptstube OSD-Ansteuerung Scriptstube arbeitet daran, die OSD-Datenbank extern anzusteuern: Datenbank bleibt Grundlage, Bedienung soll ueber moderne Oberflaechen erfolgen. Frueh Datenvertrag, Verantwortlichkeiten und Schreib-/Leserechte klaeren. ProductionBase darf OSD-Stammdaten nicht doppelt oder widerspruechlich fuehren.
    Materiallisten / LagerChecker Solidworks exportiert Materiallisten mit Artikelnummern; OSD und HHOS koennen weitere Stuecklisten-/Optimierungsquellen werden. LagerChecker ist neue Modulidee. Als Pruef- und Ampelmodul planen: Modula WMS und Barbaric lesend anbinden und Materiallisten vor Uebergabe an Lageristen auf Verfuegbarkeit pruefen.

    Priorisierung aus diesem Stand: Erst laufende Module absichern, dann gemeinsame Schnittstellen definieren, danach Automatisierung und ML ausbauen. Der Produktionsueberwachungsbestand ist ein Vorteil: Er liefert schon heute Prozesswissen und UI-Erfahrung, auch wenn die Eingaben noch manuell entstehen.

    Roadmap-Regel v0.4: ProductionBase wird nicht als Big-Bang-Projekt eingefuehrt. Jedes vorhandene System wird als Modul oder Datenquelle gekapselt, bekommt klare Schnittstellen und bleibt funktionsfaehig, wenn andere Module noch fehlen.
    Strategische Entscheidung
    ProductionBase sollte nicht als ein grosses monolithisches Programm gebaut werden. Der bessere Weg ist eine modulare Plattform mit gemeinsamen Standards, an die jedes Modul sauber andockt.

    2. Zielbild ProductionBase

    ProductionBase ist der technische und organisatorische Hut ueber alle Produktionsdaten. Sie verbindet Daten aus Werkzeugverwaltung, Kantenanleimung, CNC-Programmen, Plattensaege, Materiallisten, Lagerverfuegbarkeit, CAD-Exporten, Montage und spaeter Sensorik/ML.

    2.1 Was ProductionBase leisten soll

    • Zentrale Produktionssicht: Projektstatus ueber Saege, Kante, CNC, Vormontage, Verladung und Montage.

    • Modulare Erweiterbarkeit: neue Module koennen per API/Event-Vertrag angebunden werden, ohne den Kern umzubauen.

    • Nachvollziehbare Entscheidungen: jede Kennzahl und Warnung ist auf Quellen, Regeln, Datenstand und Versionen zurueckfuehrbar.

    • Menschliche Kultur schuetzen: keine Mitarbeiterueberwachung, keine Schuldzuweisung aus Daten, sondern Prozessverbesserung.

    • Open-Source-first: bevorzugt etablierte, offene Bausteine; proprietaere Systeme nur dort, wo Maschinenhersteller oder OSD es erzwingen.

    • Offline- und Werkstatt-tauglich: Clients muessen robust gegen Netzwerkunterbrechungen sein und spaeter sauber synchronisieren.

    • Langfristig anschlussfaehig an OSD, Maschinen, Lager/WMS, Materiallisten, mobile Apps, Sensorik und moegliche Robotik.

    2.2 Abgrenzung

    • ProductionBase ersetzt nicht sofort OSD. OSD bleibt zunaechst fuehrend fuer kaufmaennische Auftragsdaten, Stuecklisten-/Auftragskontext und spaeter fuer Montage-KW-Schnittstellen.

    • ProductionBase ersetzt nicht zwingend alle Maschinensteuerungen. Sie liest, schreibt oder ueberwacht nur definierte Schnittstellen.

    • ML-Ergebnisse sind anfangs nur Hinweise. Automatische Sperrungen oder harte Entscheidungen duerfen erst nach belastbarer Validierung kommen.

    • Kamera- und Sensordaten dienen Prozesssicherheit und Maschinen-/Werkzeugdiagnose, nicht Personenbewertung.

    3. Designprinzipien

    Prinzip Bedeutung Konsequenz
    Modular Jedes Modul besitzt klaren Scope, eigene Tests, eigene Datenverantwortung und definierte Events/API-Vertraege. Kein Modul darf voraussetzen, dass alle anderen Module existieren.
    Nachvollziehbar Jede Auswertung speichert Datenquelle, Parser-/Regelversion, Modellversion und Erklaerung. Keine Kennzahl ohne Herkunftsnachweis.
    Secure by Design Authentifizierung, Rollen, API-Keys/Zertifikate, Netzwerkzonen, Backups und Patchprozess von Beginn an. Sicherheit ist kein Add-on nach dem MVP.
    Privacy by Design Datenminimierung, Zweckbindung, Rollenrechte, begrenzte Aufbewahrung und klare Transparenz gegenueber Kollegen. Keine personenbezogenen Leistungsrankings.
    Open Source first Bevorzugt offene Standards und OSS-Komponenten mit aktiver Community. Vendor-Lock-in nur bewusst und dokumentiert.
    Blameless Daten zeigen Prozessprobleme und Systemzustaende, nicht Schuldige. Melden muss besser sein als Vertuschen.
    Robust vor Perfekt Erst stabile Datenerfassung, dann Automatisierung, dann Prognosen. Keine ML-Produktion ohne gute Datenbasis.
    Dokumentiert Architekturentscheidungen, Schnittstellen, Datenfluesse und Betriebsprozesse werden versioniert dokumentiert. Wer es nicht erklaeren kann, sollte es nicht automatisieren.

    4. Referenzarchitektur

    Die Zielarchitektur besteht aus drei Ebenen: Edge/Quellsysteme, ProductionBase Core und Nutzungsebene. Fachmodule liegen dazwischen und sprechen ueber standardisierte Schnittstellen mit dem Core. Dadurch kann Toolbase als Modul integriert werden, ohne seine heutige Betriebsfaehigkeit zu verlieren.

    Die Architektur trennt bewusst Rohdaten, fachliche Events, auswertbare Kennzahlen und menschliche Entscheidungen. Das verhindert, dass aus einzelnen Maschinensignalen unkontrolliert Managementaussagen werden.

    ProductionBase Zielarchitektur

    4.1 Kernbausteine

    Baustein Aufgabe Empfehlung
    API Gateway Ein zentraler Eingang fuer Web, Clients, mobile App und externe Integrationen. OpenAPI-Vertraege, Auth, Rate-Limits, Versionierung.
    Identity & Rollen Single Sign-on, Rollen, Rechte, API-Clients, Service-Accounts. Keycloak oder vergleichbarer OSS-IAM.
    Event Bus Maschinen, Clients und Module senden Ereignisse statt Punkt-zu-Punkt-Abhaengigkeiten. MQTT fuer Edge/Maschinen; optional NATS JetStream fuer persistente Event-Streams.
    Datenkatalog Zentrale Beschreibung: Welche Daten gibt es, woher kommen sie, wer nutzt sie, wie verlaesslich sind sie? Pflicht vor grossen Dashboards.
    Audit Trail Aenderungen, Auswertungen, Modellversionen und manuelle Eingriffe werden protokolliert. Nachvollziehbarkeit und Fehleranalyse.
    Observability Metriken, Logs, Traces, Healthchecks, Alarme. Prometheus, Grafana, Loki/OpenTelemetry.
    Object Store Ablage von Audiodaten, Spektrogrammen, KAM/CUT/MPR/PDF/Video-Clips. S3-kompatibel; Rechte und Retention beachten.
    Analytics/MLOps Trainingsjobs, Modellregistry, Modellkarten, Evaluationsberichte. MLflow/DVC-artige Versionierung.

    5. Module und fachlicher Scope

    Modul Scope Prioritaet Kommentar
    Toolbase Werkzeughalter, Werkzeugdaten, QR-Workflow, Homag/Weeke-Sync, ToolLife, ClientPro-Zustand. Sehr hoch Im Rollout. Fokus: Stabilisierung, Security, Update-Prozess, Schnittstellenvertrag und ProductionBase-Events, ohne laufende Funktionen zu destabilisieren.
    SolidworksPDFExporter Verteilte CAD-/Zeichnungsausgabe ueber Nacht auf CAD-Rechnern. Sehr hoch Zu ca. 95 % funktionsfaehig und kurz vor Rollout. Kurzfristig als Batch-Worker mit Jobstatus, Ergebnisablage und Fehlerprotokollen anbinden.
    Ottinator OSD .CUT einlesen, Teile splitten, .KAM erzeugen, Kantenfortschritt ueberwachen. Hoch Sehr fruehe Entwicklungsphase. Datenmodell, Teil-IDs, CUT/KAM-Regeln und Fortschritts-Events jetzt sauber festlegen; MVP bewusst klein halten.
    MPRBase CNC-Daten mit Stuecklisten vergleichen, Warnungen, WoodWop-Funktionsersatz/Erweiterung, Laufzaehlung. Hoch Grosser Hebel fuer Fehlervermeidung und Fortschritt CNC.
    Holzherrscher HolzHer-Saege anbinden, geschnittene Teile erkennen, Fortschritt Saege melden. Mittel Ab November nach Maschinenlieferung und Schnittstellenanalyse starten.
    Viking Barbaric-Lager auslesen, Lagerstaende, Altbestand, Plattenverfuegbarkeit, optional ML-Kamera. Mittel Zuerst Lagerschnittstelle, Kamera spaeter nur mit Datenschutzkonzept.
    SanaMontage Mobile Baustelleninfos, Ansprechpartner, Fotos/Reklamationen, Uebersetzungen DE/RO/CZ. Mittel/Hoch Scriptstube-Montageplanung ist bereits im Einsatz. Monteur-App, Reklamationsruecklauf und Uebersetzung als Erweiterung planen, nicht als Ersatz des bestehenden Systems.
    LagerChecker Vergleicht Schrauben, Scharniere, Platten, Kanten und weitere Artikelnummern aus Solidworks-, OSD- und HHOS-Listen gegen Modula WMS und Barbaric. Hoch Neue Modulidee mit starkem Sofortnutzen: Materialampel beim Herausschreiben, bevor unvollstaendige Listen an den Lageristen gehen. Read-only gegen Lagerquellen starten.
    Future Modules Robotik, weitere Maschinen, Energie, Qualitaet, Wartung. Offen Nur ueber Plugin-/Schnittstellenstandard anbinden.
    Bestehende Produktionsueberwachung Manuelle Rueckmeldungen aus Produktion, Stationsstatus, bestehendes Dashboard/Arbeitsweise. Sehr hoch Als vorhandene Datenquelle und UI-/Prozessbasis integrieren. Automatische Events spaeter schrittweise gegen manuelle Eingaben spiegeln und validieren.
    Scriptstube/OSD Modernisierung Externe Ansteuerung der bestehenden OSD-Datenbank ueber moderne Oberflaechen; spaeter Montage-KW und Auftragsdaten. Sehr hoch Fruehe Abstimmung zu Datenvertrag, Canonical IDs, Schreibrechten und Konfliktregeln. OSD bleibt bis auf Weiteres fuehrende Quelle fuer Auftrags-/Planungsdaten.

    5.1 Toolbase als erstes ProductionBase-Modul

    • Toolbase bleibt fachlich fuehrend fuer Halter, Werkzeug, QR-Label, ToolLife und Maschinen-Sync.

    • ProductionBase konsumiert Toolbase-Events: holder.loaded, holder.unloaded, toollife.updated, machine.sync.preview, machine.sync.applied, client.heartbeat.

    • ClientPro erhaelt zusaetzlich Sensor-/ML-Zustandswerte vom Server: Sensorstatus, Fräserzustand, Spindelhealth, letzte Messung, Modellversion.

    • Toolbase muss API-key-/zertifikatsfaehig werden und alle Maschinenzugriffe als auditierbare Aktionen speichern.

    5.2 SolidworksPDFExporter

    • Status v0.4: ca. 95 % funktionsfaehig, Rollout steht kurz bevor. Roadmap-Fokus: produktionssicherer Betrieb, Worker-Queue, Fehlerhandling, Ergebnisablage und spaetere Status-Events.

    • Batch-Jobs werden in ProductionBase geplant und auf CAD-Rechner verteilt.

    • Jeder Exportjob hat Status: queued, running, failed, completed, skipped.

    • Ergebnisse und Fehlerprotokolle werden zentral abgelegt und im Dashboard sichtbar.

    • Wichtig: CAD-Rechner duerfen keine unkontrollierten Schreibrechte auf Produktionsdatenbanken bekommen. Zugriff nur ueber Worker-API.

    5.3 Ottinator

    • Status v0.4: sehr fruehe Entwicklungsphase. Roadmap-Fokus: sauberes Datenmodell, CUT/KAM-Vertrag, Teilinstanz-IDs und Regeln, bevor zu viel Logik fest einprogrammiert wird.

    • Einlesen von OSD .CUT, Normalisierung, Split identischer Teile in eindeutige Instanzen, Erzeugung von .KAM.

    • Fortschrittsdaten: Auftrag, Teil-ID, Kantenstatus, Zeitpunkt, Maschinenlauf, Fehler/Abweichungen.

    • Konfigurierbare Regeln fuer Kantenfamilien, alte/neue Kantencodes und Eckverschneidung.

    • Ziel: Kantenfortschritt als belastbares Event an ProductionBase liefern.

    5.4 MPRBase

    • Vergleich CNC-Programme gegen Stueckliste: fehlen Programme, doppelte Programme, falsche Masse, ungewöhnliche Bearbeitung.

    • Erweiterung WoodWop-Funktionen, z.B. Rotation von Programmen um Z oder generierte Varianten.

    • Ueberwachung, welches Programm auf welcher Maschine wie oft laeuft.

    • Fortschritt CNC wird gegen Soll-Stueckliste abgeglichen, aber mit Unsicherheit markiert, wenn Programmnamen nicht eindeutig sind.

    5.5 Holzherrscher

    • Saege-Schnittstelle erst nach Lieferung/Analyse der neuen HolzHer-Maschine festlegen.

    • MVP: passive Beobachtung von Output-Dateien/Logs, wenn verfuegbar; keine riskanten Eingriffe in Maschinensteuerung.

    • Ziel: geschnittene Teilinstanzen als Events mit Auftrag/Position/Teil-ID.

    5.6 Viking

    • Auslesen Barbaric Lager: Plattentyp, Dekor, Format, Menge, Lagerort, Alter/Einlagerdatum, Reservierungen.

    • Auswertung: Langlieger, Mindestbestand, Materialverfuegbarkeit fuer anstehende Auftraege.

    • Optionale Kamera nur als Material-/Lagerzustandsanalyse, nicht als Mitarbeiterueberwachung.

    5.7 LagerChecker

    LagerChecker prueft Material- und Stuecklisten gegen reale Lagerbestaende, bevor Listen an Lageristen oder naechste Prozessschritte gehen. Ziel ist nicht, das Lagerhaltungssystem zu ersetzen, sondern fehlendes Material frueh sichtbar zu machen.

    • Eingangsquellen: Solidworks-Materiallisten, OSD-Stuecklisten und optional HHOS-/HolzHer-Zuschnittsoptimierer-Ausgaben.

    • Bestandsquellen: Modula WMS fuer Kleinteile/Beschlaege/Artikel und Barbaric fuer Plattenbestand; beide zunaechst nur lesend.

    • Artikelnummern, Mengeneinheiten, Ersatzartikel und Reservierungen muessen normalisiert werden, damit nicht Scheinfehler entstehen.

    • Ausgabe als Materialampel: vorhanden, knapp, reserviert/unsicher, fehlt. Jede Bewertung zeigt Quelle, Zeitpunkt, Listen-Version und Datenqualitaet.

    • Beim Herausschreiben von Materiallisten werden fehlende oder kritische Positionen hervorgehoben; die Stueckliste wird aber nicht stillschweigend veraendert.

    • Jeder Check wird als nachvollziehbarer Report gespeichert, damit spaeter klar ist, auf welchem Lagerstand eine Entscheidung beruhte.

    5.8 SanaMontage

    • Status v0.4: Montageplanung der Scriptstube ist bereits im Einsatz. Noch offen sind Monteur-App, strukturierte Reklamationsrueckfuehrung, Foto-Workflows und Uebersetzung.

    • Mobile App fuer Baustelleninfos: Adresse, Ansprechpartner, Montage-KW, Plaene, Fotos, Checklisten, Reklamationen.

    • Reklamationsfotos gehen direkt in einen Bearbeitungsworkflow mit Status und Verantwortlichkeit auf Prozessebene.

    • Automatische Uebersetzung Deutsch/Rumaenisch/Tschechisch als Textassistenz mit Originaltext-Erhalt.

    • Wichtig: mobile Rechte streng rollenbasiert; keine unnoetigen Kundendaten offline speichern.

    5.9 Bestehende Produktionsueberwachung und Scriptstube/OSD als aktive Systeme

    Die bestehende Produktionsueberwachung ist bereits im Arbeitsalltag verankert, auch wenn der Status aktuell manuell gepflegt wird. Diese manuelle Ebene ist nicht wertlos: Sie ist der Referenzprozess, gegen den automatische Events spaeter validiert werden koennen.

    Scriptstube betreibt bereits die Montageplanung und arbeitet an einer modernen externen Ansteuerung der OSD-Datenbank. ProductionBase sollte deshalb nicht versuchen, OSD zu ersetzen, sondern die entstehenden Datenvertraege sauber nutzen.

    • Produktionsueberwachung zuerst als Quelle integrieren: Auftrag, Station, Status, Zeitstempel, Kommentar, Unsicherheit und manuelle Herkunft kennzeichnen.

    • Automatische Events aus Toolbase, Ottinator, MPRBase, Holzherrscher und Montage-App duerfen manuelle Eingaben ergaenzen, aber nicht stillschweigend widerspruechliche Daten erzeugen.

    • OSD-/Scriptstube-Schnittstelle als strategische Abhaengigkeit fuehren: klare Owner, Datenrichtung, Konfliktregeln, Testdaten und Fallback bei Schnittstellenstoerung.

    6. Plattformdienste

    Dienst Zweck Empfehlung
    Auth/IAM Nutzer, Rollen, Service-Accounts, MFA, API-Zugriffe. Keycloak; lokale Admin-Fallback-Accounts; Hardwarekeys fuer Admins.
    API-Verwaltung OpenAPI-Spezifikation, Versionierung, Test-Clients. REST fuer fachliche APIs; Webhooks/Events fuer Status.
    Eventing Maschinen- und Modulereignisse entkoppeln. MVP: MQTT + DB-Outbox. Ausbau: NATS JetStream.
    Datenhaltung Transaktionen, Historie, Zeitreihen, Dateiobjekte. PostgreSQL/TimescaleDB + Object Store; SQLite nur am Edge/Client.
    Observability Health, Logs, Metriken, Traces, Alerts. Prometheus, Grafana, OpenTelemetry, Loki.
    MLOps Experimente, Modelle, Trainingsdaten, Modellkarten. MLflow + strukturierte Modellfreigaben.
    Dokumentation Architektur, ADRs, Schnittstellen, Betriebshandbuch. Git-basiertes Docs-as-Code, Markdown, Diagramme, Changelog.
    Deployment Releases, Rollback, Signierung, Updatekanaele. Stable/Beta, signierte Artefakte, reproduzierbare Builds.

    7. Datenarchitektur und Nachvollziehbarkeit

    Die Plattform sollte von Anfang an zwischen Stammdaten, Ereignissen, Rohdaten, Auswertungen und Entscheidungen unterscheiden. Ohne diese Trennung entsteht spaeter genau die unuebersichtliche Datenwueste, die vermieden werden soll.

    7.1 Datenklassen

    Datenklasse Beispiele Regel
    Stammdaten Werkzeug, Halter, Maschine, Material, Auftrag, Teil, Station. Normalisierte Tabellen, klare IDs, Aenderungshistorie.
    Events holder.loaded, part.sawn, edge.completed, cnc.program.started, sensor.capture.finished. Append-only Eventlog; nicht nachtraeglich ueberschreiben.
    Rohdaten CUT/KAM/MPR/XML/TDX, Audio, Spektrogramm, Fotos, Videos. Object Store mit Hash, Quelle, Retention und Zugriffsklasse.
    Auswertungen Fortschritt %, Werkzeugzustand, Lagerampel, Fehlerwarnung. Immer mit Input-IDs, Regel-/Modellversion und Zeitstempel.
    Entscheidungen Freigabe, Korrektur, Reklamationsstatus, manuelle Uebersteuerung. Human action log; Begruendung und Rolle speichern.

    7.2 Pflichtfelder für Nachvollziehbarkeit

    Feld Beispiel Warum wichtig
    source_system Toolbase, OSD, Ottinator, MPRBase, Raspberry-01, Barbaric. Woher kommt der Datensatz?
    source_reference Dateipfad, API-ID, Maschinenlog-ID, Message-ID. Wie findet man die Originalquelle wieder?
    ingested_at Zeitpunkt der Uebernahme. Wann wurde es in ProductionBase sichtbar?
    parser_version / rule_version z.B. ottinator-parser 0.4.2. Mit welcher Logik wurde interpretiert?
    data_quality_grade A = sicher, B = plausibel, C = unsicher, D = manuell pruefen. Wie belastbar ist die Aussage?
    confidence 0-1 oder Ampel plus Text. Wie sicher ist eine Analyse/ML-Prognose?
    explanation Kurzbegruendung: Frequenzband X, ToolLife Y, Abweichung Z. Warum wurde so bewertet?
    review_status unchecked, auto_checked, human_checked, rejected. Wurde es geprueft?
    Kein Blackbox-Prinzip
    Jede Dashboard-Kachel bekommt einen Button/Link „Warum sehe ich das?“. Dahinter stehen Quelle, Berechnung, Datenstand, Unsicherheit und Verantwortungsbereich.

    8. ML-Roadmap für Fräserverschleiß und Spindelhealth

    Die ML-Idee ist stark, aber sie muss als Forschungs- und Datenprojekt starten. Akustik/Vibration von Fraesern ist von vielen Faktoren abhaengig: Werkzeug, Drehzahl, Material, Vorschub, Eingriff, Spannmittel, Spindelzustand, Absaugung, Umgebung und Sensorposition. Deshalb ist die erste Phase nicht „Modell bauen“, sondern reproduzierbar Daten sammeln und Labelqualitaet herstellen.

    8.1 Sensorik-Setup

    • Je Maschine ein Raspberry/Edge-Geraet mit Piezo- oder Acoustic-Emission-Sensor, sauberer Befestigung, Zeitstempel und Healthcheck.

    • Der Raspberry erzeugt aus Rohsignal sowohl komprimierte Rohdaten-Snippets als auch Spektrogramme/Features.

    • Alle Daten werden erst lokal zwischengespeichert und dann an den Server uebertragen, damit Netzwerkausfaelle keinen Datenverlust erzeugen.

    • Sensorstatus wird an den Server gemeldet: online/offline, Signalpegel, Rauschen, Speicher, Uhrzeit synchron, letzte Aufnahme.

    8.2 Fräsererkennung über Drehzahl

    Das Konzept, Fraeser ueber unterschiedliche Leerlauf-Drehzahlen zu unterscheiden, ist als Fallback gut, sollte aber nicht die einzige Wahrheit sein. 50 U/min Unterschied entsprechen nur ca. 0,83 Hz. Mit 1 Sekunde Messzeit liegt die einfache FFT-Aufloesung grob bei 1 Hz. Das ist prinzipiell erkennbar, aber im echten Maschinenumfeld nicht robust genug, wenn Ramp-up, Regelabweichungen, Harmonische, Zahneingriffsfrequenzen und Stoergeraeusche dazukommen.

    • Empfehlung: Drehzahl-Fingerprint als Plausibilisierung nutzen, nicht als alleinige Werkzeug-ID.

    • Besser: Kombination aus Toolbase-Kontext, Maschinenjob, Halter/Werkzeugstatus, Drehzahl-Fingerprint und Zeitfenster.

    • Wenn Drehzahlcodierung gewuenscht ist: Abstaende groesser planen und reale Drehzahlstabilitaet je Maschine messen.

    • Die erste Sekunde Leerlauf reicht fuer eine erste Schaetzung, aber fuer robuste Erkennung sollten 2-3 Sekunden oder mehrere kurze Fenster getestet werden, falls der Prozess das erlaubt.

    8.3 Sinnvolle ML-Ansätze

    Ansatz Beschreibung Eignung Moegliche Tools
    Feature-basiert Extrahierte Merkmale: RMS, Peak, dominante Frequenzen, Zahneingriffsband, Spektralenergie, Trend. Sehr gut fuer MVP, erklaerbarer, weniger Datenbedarf. scikit-learn, LightGBM/XGBoost, Isolation Forest.
    Spektrogramm als Bild STFT/Mel-Spektrogramm wird als Bild analysiert. Gut fuer Muster, Vergleichbarkeit und visuelle Plausibilisierung. CNN/EfficientNet klein, PyTorch.
    Rohsignal direkt 1D-CNN/TCN/Transformer auf Waveform. Kann stark sein, braucht aber mehr Daten und saubere Labels. PyTorch, torchaudio.
    Anomaly Detection Lernt „normal“ je Tool/Maschine und meldet Abweichungen. Sinnvoll am Anfang, weil stumpf/scharf Labels fehlen. Autoencoder, One-Class, robuste Statistik.
    Ensemble Mehrere Modelle liefern Score + Erklaerung. Beste Zielarchitektur nach Validierung. Featuremodell + Spektrogramm + Regeln.

    8.4 Lernstrategie ohne Datenchaos

    1. Phase Datensammlung: mehrere Wochen/Monate passiv aufnehmen, ohne Produktionsentscheidung.

    2. Baseline erstellen: pro Maschine, Spindel, Fraeser, Drehzahl, Material und Prozessart typische Signatur berechnen.

    3. Labels ableiten: ToolLife, Wechselzeitpunkt, Bedienerhinweis „Fraeser stumpf“, Reklamation, sichtbare Schnittqualitaet, Werkzeugbruch.

    4. Erste Modelle nur im Schattenbetrieb: Vorhersage speichern, aber nicht anzeigen oder nur intern pruefen.

    5. Validierung: Trefferquote, Fehlalarme, verpasste Verschleissfaelle, Datenqualitaet und Erklaerbarkeit messen.

    6. Erst danach Live-Anzeige: Ampel mit Konfidenz und Begruendung, niemals nur „KI sagt stumpf“.

    8.5 Spindelhealth

    Spindelhealth ist ein sehr sinnvoller Nebenpfad, weil Spindelgeraeusche ueber viele Fraeser hinweg auftreten koennen. Der Ansatz sollte nicht fraeserspezifisch starten, sondern maschinen-/spindelspezifische Trends betrachten.

    • Spindel-Baseline im Leerlauf ohne Eingriff messen, getrennt nach Drehzahlbereichen.

    • Trends ueber Wochen: Lagergeraeusche, Unwucht, zunehmende Peaks, Temperatur falls verfuegbar.

    • Spindelhealth nur als Wartungshinweis, nicht als Schuldindikator.

    • Wartungsereignisse erfassen, damit das System lernt, was sich nach Service aendert.

    8.6 Crash-Kamera

    Eine rollende Kamera mit Ringpuffer kann bei Crash-/Stoergeraeuschen die letzten 60 Sekunden sichern. Das kann bei Fehleranalyse extrem hilfreich sein, ist aber datenschutzsensibel.

    • Kamera nur auf Maschine/Werkstueck ausrichten, keine Pausenbereiche/Wege/Personenfokus.

    • Standardmaessig nicht dauerhaft speichern, sondern nur Ereignisclips mit klarer Retention.

    • Zugriff streng beschraenken, protokollieren und zweckgebunden nutzen.

    • Transparente interne Regelung: Was wird gefilmt, wann wird gespeichert, wer darf schauen, wann wird geloescht?

    9. Security, Datenschutz und blameless Kultur

    ProductionBase verarbeitet Maschinen-, Auftrags-, Prozess- und spaeter potenziell personenbezogene Randdaten. Deshalb muessen Security und Datenschutz als Architekturthemen behandelt werden. Relevant sind besonders NIST CSF 2.0 fuer Cybersecurity-Governance, OWASP ASVS fuer Web/API-Sicherheit, DSGVO-Prinzipien fuer personenbezogene Daten und NIST AI RMF/EU AI Act als Orientierung fuer vertrauenswuerdige AI-Systeme.

    Thema Ziel Konkrete Umsetzung
    Netzwerkzonen Office, Server, Maschinen/OT, Sensorik, Gast/Internet trennen. Firewall-Regeln, nur notwendige Ports, keine direkten Adminzugriffe aus unsicheren Zonen.
    Identitaet Personen und Maschinen eindeutig authentifizieren. MFA fuer Admins, API-Keys/Zertifikate fuer Clients, keine geteilten Adminpasswoerter.
    Least Privilege Jeder Dienst darf nur das, was er braucht. Service-Accounts pro Modul; Rollen fuer Produktion, Admin, Viewer, Montage.
    Secrets Tokens, Passwoerter, Zertifikate sicher speichern. Keine Secrets in Git/Logs; Rotation; Backup der Secrets-Strategie.
    Patch/Release Kontrollierte Updates, Rollback, signierte Artefakte. Stable/Beta-Kanaele, Testserver, Changelog.
    Backups Datenverlust und Ransomware verhindern. 3-2-1-Backup, Restore-Tests, Offline/immutable Kopie.
    Logging Sicherheit und Fehleranalyse, aber ohne Datenexzess. Audit-Logs fuer Admin/Aenderungen; personenbezogene Logs minimieren.
    Incident-Prozess Vorfall erkennen, reagieren, wiederherstellen. Runbooks, Verantwortlichkeiten, Notfallkontakte, Uebungen.

    9.1 Datenschutz- und Kulturregeln

    • Keine personenbezogenen Leistungsrankings aus Maschinen-, Kamera- oder Appdaten.

    • Dashboards zeigen Auftrag, Prozess, Maschine, Station und Systemzustand - nicht „Mitarbeiter X ist langsam“.

    • Kamera- und Sensordaten werden zweckgebunden eingesetzt: Crashanalyse, Maschinen-/Werkzeugzustand, Qualitaet, Reklamation.

    • Datenminimierung: Nur speichern, was fuer Prozess, Qualitaet, Wartung oder Nachweis wirklich gebraucht wird.

    • Transparenz: Kollegen muessen verstehen koennen, welche Daten erfasst werden und wofuer.

    • Meldekultur: Ein manuell gemeldetes Problem darf nicht gegen die meldende Person verwendet werden.

    • Human Review: Kritische Entscheidungen bleiben nachvollziehbar und koennen korrigiert werden.

    Blameless Designregel
    ProductionBase darf Fehler sichtbar machen, aber nicht Menschen blossstellen. Ziel ist: schneller lernen, weniger vertuschen, bessere Qualitaet.

    10. Schnittstellenkatalog

    Der Schnittstellenkatalog ist ein lebendes Dokument. Jede Schnittstelle braucht Owner, Richtung, Datenformat, Authentifizierung, Risiko, Teststrategie und Fallback.

    10.0 Source-of-Truth-Regeln fuer v0.4

    Damit keine Datenwidersprueche entstehen, bekommt jedes Kernobjekt eine fuehrende Quelle. Andere Systeme duerfen diese Daten anzeigen, anreichern oder kommentieren, aber nicht stillschweigend ueberschreiben.

    Objekt/Datenbereich Fuehrende Quelle v0.2 ProductionBase-Rolle
    Werkzeug, Halter, ToolLife Toolbase Konsumieren, dashboarden, auditieren, ML-Kontext bereitstellen.
    Auftrag, kaufmaennische Stammdaten, spaeter Montage-KW OSD/Scriptstube-Schnittstelle Nicht duplizieren; nur ueber Datenvertrag uebernehmen.
    Aktueller Stationsstatus heute Bestehende Produktionsueberwachung Als manuelle Quelle anzeigen und spaeter mit automatischen Events plausibilisieren.
    Kantenstatus je Teilinstanz Ottinator nach MVP Automatische Events aufnehmen; Unsicherheit bei Zuordnungsproblemen zeigen.
    Lagerbestand und Materialverfuegbarkeit Modula WMS fuer Kleinteile/Beschlaege; Barbaric fuer Plattenbestand; OSD/Solidworks/HHOS fuer Bedarfskontext. Nicht selbst fuehrend fuer Bestand sein; nur pruefen, bewerten, dokumentieren und Materialampel mit Zeitstempel/Quelle anzeigen.
    CNC-Programm-/Fraesfortschritt MPRBase/ClientPro nach MVP Automatische Events gegen Stueckliste pruefen; keine Blackbox-Fortschrittswerte.
    Montageplanung/Reklamation Scriptstube + spaeter SanaMontage-App Planung konsumieren, Rueckmeldungen/Reklamationen strukturiert zurueckgeben.
    Schnittstelle Technik Daten Zeitpunkt Hinweis
    Toolbase <-> ProductionBase REST + Events Halter, Werkzeug, ToolLife, Maschinenstatus, Client heartbeat. Kurzfristig Bestehende API versionieren, Events ergaenzen.
    ClientPro <-> Server REST heartbeat + optional MQTT Status, Sensorzustand, Syncmeldungen, UI-Anzeige. Kurzfristig Offline-Faehigkeit und API-Key Pflicht.
    Homag/Weeke Datei/DB/FTP/ToolManager XML, TDX, wz_db86, XOR, done trigger, Logs. Bestehend Nur definierte Schreibpfade, Reverse-Compare als Kontrolle.
    Raspberry/Piezo MQTT/REST + Object upload Audio/Spektrogramm, RPM-Fingerprint, Sensorhealth. Pilot Edge-Buffering und Zeit-Sync wichtig.
    Crash-Kamera RTSP/Ringbuffer/Event upload 60s Clips bei Crashereignis. Spaeter Datenschutzkonzept vor Inbetriebnahme.
    Solidworks/eDrawings Worker/COM/Batch API Exportjobs, PDF/DWG/Status/Fehler. Kurz/Mittel CAD-Rechner als Worker, keine direkte DB-Manipulation.
    Ottinator Dateiimport + REST/Events CUT, KAM, Teile, Kantenstatus. Kurz/Mittel Konfigurierbare Regeln und Testfixtures.
    MPRBase Dateiimport/MPR Parser + Events Programme, Soll/Ist, Laufzaehlung, Warnungen. Mittel Parser-Regeln versionieren.
    HolzHer Saege TBD nach Lieferung Schnittlisten, Ist-Schnitte, Teilstatus. Ab Nov Erst passive Analyse, dann Schnittstelle festlegen.
    Barbaric Plattenlager -> Viking/LagerChecker TBD: DB/API/Export/PLC Plattenbestand, Dekor, Format, Lagerort, Alter, Reservierung. Mittel Nur lesend starten; Viking fuer Bestandsanalyse, LagerChecker fuer Verfuegbarkeitspruefung gegen Stuecklisten.
    Modula WMS -> LagerChecker TBD: API/DB-View/Export Artikelnummer, Bestand, Reservierung, Lagerort, Mindestbestand, letzte Aktualisierung. Kurz/Mittel Read-only beginnen; keine stillen Lagerbuchungen. Source-of-Truth bleibt Modula.
    Solidworks/OSD/HHOS -> LagerChecker Dateiimport + REST/Events Stuecklisten, Artikelnummern, Mengen, Einheiten, Projekt/Auftrag, Listen-Version. Kurz/Mittel Einheiten und Artikelnummern normalisieren; Ergebnis als Materialampel und pruefbarer Report ausgeben.
    SanaMontage App Mobile REST/API + Upload Baustelleninfos, Fotos, Reklamationen, Checklisten. Mittel Offline-Cache, Rollen, Retention.
    OSD Datenbank Schnittstelle Scriptstube Auftrag, Position, Montage-KW, Stuecklisten, Status. Fernziel Vertraglich klar definieren: Quelle, Taktung, Schreibrechte.
    Bestehende Produktionsueberwachung -> ProductionBase REST/DB-Adapter/CSV je Bestand Manuelle Stationsstatus, Auftrag, Kommentar, Zeitstempel, Bedienkontext optional. Kurzfristig Als Bestandsquelle integrieren und spaeter mit automatischen Events abgleichen. Herkunft immer sichtbar: manuell vs. automatisch.
    Scriptstube Montageplanung <-> ProductionBase REST/OpenAPI nach Datenvertrag Baustelle, Montage-KW, Ansprechpartner, Planungsstatus, spaeter App-Rueckmeldungen/Reklamationen. Mittel Bestehendes System bleibt fuehrend fuer Montageplanung. ProductionBase konsumiert/visualisiert und gibt definierte Rueckmeldungen zurueck.
    OSD-Datenbank/Scriptstube Modern UI <-> ProductionBase Noch zu definieren: API/Views/Service-Layer Auftrag, Position, Teil, Material, Montage-KW, Stammdatenreferenzen. Strategisch Frueh klaeren: Read-only vs. Write-back, Konfliktregeln, IDs, Transaktionen, Audit und Testumgebung. Keine direkte DB-Manipulation ohne Vertrag.

    10.1 Empfohlenes Event-Namensschema

    Events sollten technisch klein, fachlich klar und stabil versioniert sein. Beispiel: production.tool.holder_loaded.v1 oder production.part.edge_completed.v1.

    Event Quelle Bedeutung Minimalfelder
    production.tool.holder_loaded.v1 Toolbase Halter wurde auf Maschine geladen. holder_id, tool_id, machine_id, user_context_optional, timestamp
    production.tool.toollife_updated.v1 Toolbase ToolLife wurde bei Unload in DB geschrieben. tool_id, holder_id, previous_life, new_life, source
    production.edge.part_completed.v1 Ottinator Teil wurde gekantet. job_id, part_instance_id, edge_machine, status, timestamp
    production.cnc.program_started.v1 MPRBase/Client CNC-Programmstart erkannt. machine_id, program_id, job_id_optional, confidence
    production.saw.part_cut.v1 Holzherrscher Teil wurde gesaegt. job_id, part_instance_id, saw_id, source_quality
    production.sensor.capture_finished.v1 Raspberry Vibrationsaufnahme abgeschlossen. machine_id, capture_id, rpm_estimate, signal_quality
    production.ml.tool_health_scored.v1 ML Service Fraeserzustand bewertet. tool_id, score, confidence, model_version, explanation_id
    production.inventory.check_requested.v1 LagerChecker Material-/Stueckliste soll gegen Lagerquellen geprueft werden. job_id, bom_id, source_system, requested_by, timestamp
    production.inventory.check_completed.v1 LagerChecker Materialampel wurde berechnet und dokumentiert. job_id, bom_id, missing_items, warning_items, source_snapshot, data_quality_grade, timestamp

    11. Roadmap 2026-2028

    Phase Zeitraum Schwerpunkt Ergebnis Gate
    Phase 0: Fundament 0-2 Monate Zielbild finalisieren, Architekturentscheidungen, Datenkatalog-Skelett, Schnittstellenregister inkl. bestehender Produktionsueberwachung, Scriptstube-Montageplanung, OSD-Modernisierung sowie Material-/Lagerschnittstellen fuer LagerChecker. ProductionBase Repo, ADRs, OpenAPI-Template, Rollenmodell, erste Datenflussdiagramme, Status v0.4 je Modul inkl. LagerChecker. Keine weitere Modulvernetzung ohne Schnittstellenvertrag und klare Source-of-Truth-Regel.
    Phase 1: Toolbase hardening 2-4 Monate Toolbase Rollout absichern, SolidworksPDFExporter Rollout begleiten, ClientPro-Zustandsmodell, API-Key/Auth, Logs, erste Health-Kacheln und Voranalyse LagerChecker-Schnittstellen. Toolbase und SolidworksPDFExporter als erste echte Module sichtbar; manuelle Produktionsueberwachung als Datenquelle angebunden. Bestehende Rollouts duerfen durch ProductionBase-Integration nicht instabil werden.
    Phase 2: Daten- und Modulbasis 4-8 Monate Ottinator/MPRBase/LagerChecker MVP; gemeinsame Eventstruktur; CUT/KAM/MPR/BOM Daten im Datenkatalog; Abgleich manuelle vs. automatische Fortschritts- und Verfuegbarkeitsdaten. Kante-/CNC-Fortschritt und erste Materialampel je Auftrag mit Herkunft, Zeitstempel und Unsicherheit. Unsichere Zuordnung sichtbar markieren; manuelle Quelle bleibt Fallback.
    Phase 3: Sensorik-Pilot 8-12 Monate Raspberry/Piezo an 1-2 Maschinen, passive Datensammlung, Spektrogramme, Sensorhealth. Datensatz mit Tool-/Maschinenkontext, noch keine harte ML-Entscheidung. Go/No-Go nach Signalqualitaet und Labelquote.
    Phase 4: Analytics & ML Schattenbetrieb 12-18 Monate Baseline, Anomaly Detection, Spindeltrends, Modellregistry, interne Reviews. Tool/Spindel-Scores im Schattenbetrieb, Evaluationsberichte. Live-Anzeige erst bei nachvollziehbarer Validierung.
    Phase 5: Werksweites Dashboard 18-24 Monate HolzHer, Viking, LagerChecker, Montage, OSD-Schnittstelle, integrierte Produktionsuebersicht. Projektfortschritt ueber Saege/Kante/CNC/Vormontage/Verladung/Montage. Datenschutz- und Betriebsrat/Belegschaftstransparenz klaeren.

    11.1 MVP-Reihenfolge

    1. Laufende Systeme sichern: Toolbase-Rollout, SolidworksPDFExporter-Rollout und bestehende Produktionsueberwachung nicht destabilisieren.

    2. ProductionBase Core minimal: Login, Rollen, Modulregistry, Health-Dashboard, Schnittstellenkatalog.

    3. Schnittstellenvertrag fuer bestehende Produktionsueberwachung und Scriptstube/OSD-Abhaengigkeiten definieren.

    4. Toolbase als erstes Modul sauber integrieren, ohne Bestandsfunktionen zu gefaehrden.

    5. SolidworksPDFExporter als Batch-/Worker-Modul mit Jobstatus, Fehlerprotokoll und Ergebnisablage anbinden.

    6. LagerChecker MVP planen: Solidworks-/OSD-/HHOS-Listen einlesen, Artikelnummern normalisieren und gegen Modula/Barbaric eine erste Materialampel berechnen.

    7. Ottinator so weit bringen, dass Kantenfortschritt in ProductionBase sichtbar wird.

    8. MPRBase Parser/Checker aufbauen, um CNC-Fortschritt und Warnungen aus MPR/Stueckliste abzuleiten.

    9. Sensorik-Pilot auf einer Maschine: erst Rohdaten + Metadaten + Qualitaetsscore.

    10. Dashboard fuer Produktionsleiter: Projektstatus nach Station, Materialampel, Quelle und Unsicherheitsgrad.

    11. OSD-Schnittstelle erst fest anbinden, wenn Datenvertrag mit Scriptstube stabil ist.

    12. Governance, Dokumentation und Betrieb

    Damit ProductionBase wartbar bleibt, braucht es leichte, aber verbindliche Engineering-Regeln. Diese sollten nicht bremsen, sondern verhindern, dass die Plattform nach 12 Monaten unklar wird.

    12.1 Pflichtdokumente je Modul

    • README: Zweck, Installation, Start, Konfiguration, haeufige Fehler.

    • ARCHITECTURE.md: Modulgrenzen, Datenfluesse, Abhaengigkeiten, Sicherheitsannahmen.

    • API.md/OpenAPI: Endpunkte, Events, Versionen, Beispiele.

    • DATA.md: Tabellen, Datenquellen, Datenqualitaet, Aufbewahrung, Datenschutzklasse.

    • RUNBOOK.md: Betrieb, Backups, Recovery, Logs, Alarme, manuelle Eingriffe.

    • CHANGELOG.md: versionierte Aenderungen fuer stabile Updates.

    • ADR-Verzeichnis: wichtige Architekturentscheidungen mit Kontext und Konsequenzen.

    12.2 Erklärbarkeit als Produktfunktion

    Erklaerbarkeit darf nicht nur fuer ML gelten. Auch regelbasierte Warnungen, Parser-Entscheidungen und Fortschrittsberechnungen brauchen eine Begruendung.

    Objekt Muss erklaeren Beispiel
    Dashboard-Kennzahl Quelle, Berechnung, Datenstand, fehlende Daten, Unsicherheitsgrad. „Auftrag 25T1294 Kante 62%: 31/50 Teilinstanzen edge_completed; Quelle Ottinator; Stand 10:42.“
    Warnung Regel-ID, Eingabedaten, Schwelle, Empfehlung. „MPR-Abweichung: Programm rotiert nicht; Regel mpr.rotation.check.v2.“
    ML-Prognose Modellversion, Trainingsdatenzeitraum, Confidence, wichtigste Signalfaktoren, Validierungskennzahl. „Tool 109 gelb: zunehmende Energie 2,8-3,4 kHz, 81% Confidence, Modell fraeserhealth-0.3.“

    13. Risiken und Go/No-Go-Kriterien

    Risiko Beschreibung Gegenmaßnahme Prioritaet
    Datenchaos Module erzeugen unterschiedliche IDs und widerspruechliche Status. Canonical IDs, Datenkatalog, Schnittstellenvertrag, Data Quality Grade. Hoch
    Blackbox-ML Modell liefert richtige, aber unerklärte Aussagen. Modellkarten, Erklaerungen, Human Review, Schattenbetrieb. Hoch
    Mitarbeiterueberwachung Kamera/App/Maschinendaten werden falsch interpretiert. Privacy-Regeln, keine Personenrankings, Zugriffsbeschraenkung, Transparenz. Sehr hoch
    Maschinenrisiko Schreibzugriff stoert Maschinenlauf. Passive Analyse zuerst, Testmodus, Backup, Reverse-Compare, Rollback. Sehr hoch
    Scope Creep Zu viele Module gleichzeitig. Phasenplan und Gates, MVP pro Modul, klare Priorisierung. Hoch
    Security-Luecken Offene APIs, unsichere Clients, fehlende Updates. IAM, API-Keys/Zertifikate, Netzwerkzonen, Patchprozess, Pen-Test-Light. Hoch
    ML Labelmangel Keine klare Wahrheit fuer scharf/stumpf. Toolwechsel, Qualitaetsfeedback, manuelle Labels, Schattenbetrieb. Mittel/Hoch
    Hersteller-Schnittstellen HolzHer/Barbaric/OSD liefern Daten nicht wie erwartet. Fruehe Schnittstellenanalyse, Fallback Dateiimport, klares Erwartungsmanagement. Mittel

    13.1 Go/No-Go für ML-Liveanzeige

    • Mindestens mehrere hundert verwertbare Aufnahmen pro wichtiger Werkzeug-/Maschinenklasse oder eine belastbare Baseline je Maschine.

    • Signalqualitaet automatisch bewertet und Sensorfehler erkennbar.

    • Vorhersage im Schattenbetrieb dokumentiert und gegen echte Wechsel-/Qualitaetsereignisse validiert.

    • False-Alarm-Rate akzeptabel; verpasste kritische Faelle analysiert.

    • Jede Live-Anzeige enthält Modellversion, Confidence und kurze Begruendung.

    • Klare Regel, dass ML-Hinweise keine Schuldzuweisung erzeugen.

    14. Erste konkrete nächste Schritte

    1. Version 0.4 freigeben und Status je Modul als Roadmap-Baseline festschreiben.

    2. Schnittstellenregister um bestehende Produktionsueberwachung, Scriptstube Montageplanung, Scriptstube/OSD-Modernisierung, Modula WMS, Barbaric und HHOS erweitern.

    3. Source-of-Truth-Regel definieren: OSD fuer kaufmaennische/planerische Auftragsdaten und Stuecklistenkontext, Toolbase fuer Werkzeug/Halter, Modula/Barbaric fuer Lagerbestaende, Produktionsueberwachung fuer aktuellen manuellen Stationsstatus, spaeter automatische Module fuer validierte Events.

    4. Toolbase-Rollout absichern: Monitoring, Backups, API-Key/Auth, Rollback, Logs und Updatepfad pruefen.

    5. SolidworksPDFExporter-Rollout begleiten und Job-/Worker-Status fuer ProductionBase vorbereiten.

    6. LagerChecker-Vorstudie starten: Beispiel-Materiallisten aus Solidworks, OSD und HHOS sammeln, Artikelnummern-/Einheiten-Regeln dokumentieren und Modula/Barbaric-Zugriffsweg klaeren.

    7. ProductionBase-Repo anlegen: /core, /modules, /docs, /interfaces, /deployment.

    8. ADR-001 schreiben: „Modulare Plattform statt Monolith“; ADR-002: „Bestehende Systeme kapseln statt ersetzen“; ADR-003: „LagerChecker read-only gegen WMS/Lagerquellen starten“.

    9. Canonical-ID-Konzept definieren: job_id, part_instance_id, machine_id, tool_id, holder_id, material_id/article_id, station_id, montage_project_id.

    10. Ottinator, MPRBase und LagerChecker auf gemeinsame job_id, part_instance_id, article_id/material_id und Stuecklisten-Versionen ausrichten.

    11. Datenschutz-/Kulturpapier fuer Sensorik, Kamera, Montage-App und Reklamationsfotos schreiben, bevor diese produktiv genutzt werden.

    12. Ein „Warum sehe ich das?“-Muster fuer jede Kennzahl und jede Materialampel als UI-Standard definieren.

    15. Empfohlener Open-Source-Tech-Stack

    Bereich Empfehlung Kommentar
    Backend Python Flask/FastAPI je Modul, ProductionBase Core ggf. Flask/Quart oder FastAPI. Bei Toolbase bleibt Flask/Waitress wegen Bestand sinnvoll.
    Datenbank PostgreSQL + TimescaleDB fuer Zeitreihen. SQLite nur fuer Edge/Client-Cache.
    Dateien/Rohdaten S3-kompatibler Object Store. Audio, Spektrogramme, Videos, PDFs, CUT/KAM/MPR versioniert ablegen.
    Messaging MQTT fuer Edge/OT; NATS JetStream optional fuer persistente interne Streams. Nicht sofort beides erzwingen; MVP schlank halten.
    Identity Keycloak. Rollen, SSO, MFA, Service Accounts.
    Monitoring Prometheus + Grafana + Loki/OpenTelemetry. Systemzustand und Audit trennen.
    MLOps MLflow, PyTorch, scikit-learn, DVC/lakeFS optional. Modellversionierung und Reproduzierbarkeit.
    Frontend Web-Dashboard, spaeter mobile App. Ein Designsystem mit Sana Blau und klaren Ampeln.
    Dokumentation Markdown, MkDocs/Material, Mermaid/PlantUML, OpenAPI. Docs-as-Code im Git.
    Deployment Docker Compose fuer Server, systemd fuer Werkstattserver, signierte Releases. Kubernetes erst, wenn die Komplexitaet es wirklich rechtfertigt.

    16. Anhang: Quellen und Referenzrahmen

    Quelle Nutzung in dieser Roadmap Link
    NIST Cybersecurity Framework 2.0 Cybersecurity-Governance: Govern, Identify, Protect, Detect, Respond, Recover. https://www.nist.gov/cyberframework
    NIST AI Risk Management Framework AI-Governance: Govern, Map, Measure, Manage; vertrauenswuerdige AI. https://www.nist.gov/itl/ai-risk-management-framework
    OWASP ASVS Pruefbarer Sicherheitsstandard fuer Web-Anwendungen und APIs. https://owasp.org/www-project-application-security-verification-standard/
    EU/DSGVO-Grundprinzipien Rechtsmaessigkeit, Transparenz, Zweckbindung, Datenminimierung, Speicherbegrenzung. https://commission.europa.eu/law/law-topic/data-protection/data-protection-explained_en
    EU AI Act Risikobasierter Rechtsrahmen fuer AI-Systeme in der EU. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
    OPC UA / OPC Foundation Industrieller Interoperabilitaetsstandard fuer Maschine-zu-Maschine und Maschine-zu-Enterprise. https://opcfoundation.org/about/opc-technologies/opc-ua/
    Eclipse Mosquitto Open-Source MQTT Broker fuer leichte Edge-/IoT-Kommunikation. https://mosquitto.org/
    NATS Open-Source Messaging/Streaming fuer verteilte Systeme und Edge. https://nats.io/
    MLflow Open-Source Plattform fuer Modellversionierung, Registry und MLOps. https://mlflow.org/
    Prometheus Open-Source Monitoring und Time-Series-Metriken. https://prometheus.io/
    Grafana OSS Open-Source Visualisierung/Dashboarding. https://grafana.com/oss/
    OpenTelemetry Offenes Observability-Framework fuer Metriken, Logs und Traces. https://opentelemetry.io/
    Keycloak Open-Source Identity and Access Management. https://www.keycloak.org/
    PostgreSQL Open-Source relationale Datenbank. https://www.postgresql.org/

    17. Glossar

    Begriff Bedeutung
    ADR Architecture Decision Record; kurze, versionierte Entscheidung mit Kontext, Entscheidung und Konsequenzen.
    Data Lineage Nachweis, woher Daten kommen und welche Verarbeitungsschritte sie durchlaufen haben.
    Event Unveraenderliches Ereignis, das etwas in der Produktion beschreibt.
    MLOps Betrieb, Versionierung, Monitoring und Governance von Machine-Learning-Modellen.
    Schattenbetrieb Modell rechnet mit, beeinflusst aber noch keine Produktion.
    Object Store Dateiablage fuer grosse Rohdaten wie Audio, Video, PDF, MPR, KAM, Spektrogramme.
    Go/No-Go Gate Bewusster Entscheidungspunkt, ob ein Thema produktiv, weiter pilotiert oder gestoppt wird.