Häufige Fragen

Wir arbeiten in drei Schritten: Verstehen (Termin im Werk, Zielbild), Beweisen (Proof of Concept in Ihrer Umgebung), Ausrollen. Erste sichtbare Ergebnisse entstehen in Wochen. Ist die Datenbasis erstmal gelegt, sinkt die Total Cost of Ownership mit jedem weiteren Anwendungsfall deutlich, da Integration, Berechtigungen und Betrieb bereits stehen.

Ein MES steuert Aufträge, ein Historian speichert Zeitreihen, ein BI-Tool visualisiert, eine Cloud-Suite verlangt in der Regel, dass Daten den Standort verlassen. tensoryze deckt die Lücke dazwischen: Daten erfassen oder zusammenführen, in den Produktionskontext bringen und sofort für unterschiedliche Anwendung nutzbar machen – auf Ihrer Infrastruktur, mit einem Berechtigungsmodell, einer Datenbasis und einem Audit-Pfad.

Lizenzierung erfolgt pro Standort, mit klarem Rahmen für angebundene Linien und genutzte Anwendungen – nicht pro Datenpunkt und nicht pro User. Den konkreten Rahmen stimmen wir gemeinsam mit Ihnen ab, abhängig vom Betriebsmodell (On-Premises, Air-gapped, Cloud) und dem Umfang an Anwendungen, die Sie nutzen wollen.

Daten liegen in offenen Formaten in Ihrer Infrastruktur, Export-Schnittstellen sind Plattform-Funktion, Schnittstellen folgen Industriestandards (OPC UA, Sparkplug B, MQTT, REST). Open-Source-Komponenten bilden das Fundament – kein proprietäres Lock-in. Im Worst Case behalten Sie Daten, Modelle und Strukturen; nur die Anwendungsoberfläche müssten Sie ersetzen.

Beides funktioniert. Funktioniert mit kleinen IT-Teams ebenso wie mit etablierten DevOps-Organisationen. Auf Wunsch übernehmen unsere Ingenieure Betrieb, Updates und Monitoring komplett (Managed-Service-Option). Die Einrichtung im Werk – Anbindung an Ihre Linien, Anpassung an Ihre Rollen, Schulung der Mitarbeitenden – machen wir immer gemeinsam mit Ihrem Team.

Auf dem Linienterminal sieht der Operator den aktuellen Zustand seiner Linie, offene Tickets der laufenden Schicht und Alarme, die seine Reaktion brauchen. Eintragen muss er das, was vorher auf den Zettel ging: Stillstandsgrund, Übergabenotiz, Qualitätsbefund. Oberflächen sind für den Shopfloor gemacht – bedienbar mit Handschuhen, unterwegs und unter Lärm, mit Spracheingabe am Mobiltelefon oder Tablet für freihändige Situationen.

Tickets, Stillstände, Schichtnotizen und Qualitätsereignisse liegen auf einer Timeline pro Schicht – mit Zeitstempel, Maschine, Auftrag und beteiligten Personen. Beim Schichtwechsel wandert das Wissen mit, nicht mit der einzelnen Person. Frühere Schichten sind durchsuchbar; das Schichtbuch ist gleichzeitig die Grundlage für Audits und Ursachenanalysen.

OEE und seine drei Bestandteile (Verfügbarkeit, Leistung, Qualität), Stillstands- und Störgrundauswertungen, Linien- und Schichtvergleiche. Berechnet automatisch aus den angebundenen Daten, sobald die Linie im Unified Namespace verortet ist. Die exakte Bererchnungsregeln können initial individuell angepasst werden. Verlässlich werden die Zahlen über die Verknüpfung mit Auftrag und Schicht – ein Stillstand zwischen zwei Aufträgen wird anders bewertet als einer mitten in der Produktion.

Regeln definieren Sie nicht nur über Schwellwerte, sondern auch über Trends, Muster und SPC-Karten – und mit Eskalationsketten (z.B. Operator → Schichtführer → Instandhaltung) und Zeitfenstern pro Stufe. Darüber hinaus ist jeder Alarm nach einem opt-in-Modell gestaltet, sollte eine Nachricht nicht mehr gewünscht sein, kann diese jederzeit individuell unterdrückt werden.

Kamera-basierte Echtzeit-Inspektion für Oberflächenfehler, Montageabweichungen und Vollständigkeitskontrollen – mit klassischen Bildverarbeitungsmethoden und KI-Modellen, oft kombiniert. Die Inspektion entscheidet pro Bauteil im Takt mit der Linie; das Ergebnis steht direkt im Schichtbuch und in der Qualitätsauswertung. Ob ein Anwendungsfall geeignet ist, prüfen wir mit Ihren Bauteilen vor der ersten Investition.

Eine hierarchisch geordnete Struktur (ISA-95: Enterprise → Site → Area → Line → Cell → Equipment), in der jeder Messwert eindeutig adressierbar ist. Erst dadurch wird aus einem Wert eine nutzbare Information. Sie brauchen ihn nicht vorher: existiert keine Struktur, bauen wir sie gemeinsam auf; existiert eine (z.B. über Sparkplug B), integrieren wir uns als Host Application.

OPC UA, MQTT werden nativ unterstützt. Der Unified Namepspace und Sparkplug B strukturieren die Kommunikation zwischen Applikationen. Weitere Protokollo binden wir nach Bedarf durch unsere Ingenieure an.

Sparkplug B macht MQTT für die Produktion nutzbar: definierte Topic-Strukturen, Geburts- und Todesnachrichten, klare Zustandssemantik pro Edge Node und Device. Auch die Kommunikation zwischen diversen Applikationen ist hierdurch standardisert. tensoryze bindet bestehende Sparkplug-Infrastruktur als Host Application oder stellt eigene Lösungen bereit.

Nein, die Produktion läuft weiter – Anbindung pro Linie ist ein Lesevorgang. Eine Anbindung ohne Schreibrechte ist der Normalfall; Steuereingriffe sind die bewusste Ausnahme, beispielsweise im Rahmen der optischen Sichtprüfung.

Über die Verknüpfung mit ERP/MES und dem digitalen Schichtbuch. Ein Messwert weiß damit nicht nur, von welcher Maschine er kommt, sondern auch zu welchem Auftrag, welcher Schicht und welchem Bediener. Verarbeitet werden Zeitreihen, Prozesskurven, Bilder, Dokumente, Stücklisten, Schichtnotizen und Instandhaltungsdaten – alle gegen dieselbe Hierarchie.

Ja, weil alle Werke gegen dieselbe ISA-95-Hierarchie und dieselben KPI-Definitionen melden. Die Migration in diese Struktur ist Teil der Einführung – Strukturänderungen sind versioniert und folgen einem Freigabe-Workflow. So entstehen Linien- und Standortvergleiche, die fachlich belastbar sind, statt drei verschiedener „OEE“-Lesarten.

Drei Betriebsmodelle: On-Premises in Ihrem Rechenzentrum, Air-gapped ohne Internetverbindung, oder Cloud. Hardware-Anforderungen hängen an Linienanzahl, Datenmenge (insbesondere Bilddaten) und gewählten Anwendungen – wir geben für jeden Standort ein konkretes Sizing aus, bevor Sie Hardware bestellen.

Updates kommen versioniert über einen GitOps-Workflow. Konfigurationsänderungen sind als Code nachvollziehbar und auditierbar (GitOps-Audit-Trail). Auf Wunsch betreiben wir eine Staging-Umgebung neben der produktiven, in der Änderungen vor dem Rollout geprüft werden – auf Wunsch übernehmen unsere Ingenieure den Update-Betrieb komplett.

Daten bleiben beim Kunden – auch im Cloud-Betrieb in einer Umgebung, die Sie kontrollieren. Identity-Anbindung und Berechtigungsmodell stimmen wir gemeinsam mit Ihrer IT ab, passend zu Ihren Compliance-Vorgaben. Berechtigungen folgen einer Rollenhierarchie mit Vererbung über Werk-, Linien- und Maschinenebene; Service-Accounts und API-Tokens haben definierten Scope und Ablauf.

Konfigurationsänderungen, Zugriffe, Alarm-Quittierungen, Modell-Freigaben und Steuereingriffe sind mit Zeitstempel, Benutzer und Kontext nachvollziehbar. Für die typischen Anforderungen (z.B. Nachweispflichten in regulierten Branchen, NIS2-Themen wie Zugriffskontrolle und Incident-Dokumentation) reicht das in der Regel; den konkreten Abgleich gegen Ihren Kontrollkatalog machen wir mit Ihrer Compliance-Funktion gemeinsam.

Pro Standort gibt es eine eigene Instanz, die unabhängig läuft – ein Netzwerkausfall in Werk A betrifft Werk B nicht. Standorte teilen sich Strukturen, KPI-Definitionen und Anwendungsvorlagen über versionierte Konfigurationen, behalten aber Datenhoheit lokal. Hochverfügbarkeit auf Komponentenebene und Backup-Verfahren stimmen wir gemeinsam mit Ihrer IT ab – passend zu Ihren bestehenden Verfahren.

Computer Vision für die optische Inspektion (Oberflächenfehler, Montageabweichungen, Vollständigkeit), Ursachenanalyse zwischen Prozessparametern und Qualitätsergebnissen sowie Anomalieerkennung auf Sensor- und Prozessdaten als Grundlage für vorausschauende Wartung. Ob ein Anwendungsfall geeignet ist, entscheidet die Datenlage – wir prüfen das gemeinsam mit Ihrem Team in einem Proof of Concept, bevor Sie investieren.

Weder noch. Typische Anwendungsfälle sind als Anwendung verfügbar und werden gemeinsam mit unseren Ingenieuren auf Ihre Linien zugeschnitten – ohne dass Sie ein eigenes ML-Team brauchen. Wenn Sie Data-Science-Kompetenz haben, können Sie eigene Modelle einbringen und mit Plattform-Daten per tensoryze-Python-SDK direkt aus Ihrer Python-Umgebung arbeiten. Hierdurch entfällt die meist sehr zeitaufwendige Datenvorbereitung.

Trainingsdaten kommen aus dem Unified Namespace, Modelle werden trainiert und versioniert, bei Freigabe an die Zielmaschine oder Linie ausgerollt und im Live-Betrieb überwacht. Jedes Modell hat einen klaren Verantwortlichen – Roll-back auf die letzte gesunde Version ist ein Klick.

Die Modellqualität wird im Live-Betrieb überwacht – Eingangsverteilungen, Vorhersagen und (sofern verfügbar) Labels. Verschlechtert sich das Verhalten gegenüber dem Trainingsstand, löst die Plattform einen Alarm aus und markiert das Modell zur Überprüfung. Bis eine neue Version freigegeben ist, lässt sich auf die letzte gesunde zurückrollen. Operatoren können Fehlentscheidungen zudem direkt am Linienterminal zurückmelden – diese Rückmeldungen fließen in das nächste Training ein.

Assistenten beantworten Fragen zu Maschinen, Fehlermeldungen und Bedienschritten im Kontext der jeweiligen Linie oder Schicht; sie fassen Schichtberichte zusammen und helfen beim Onboarding von Springern. Welche Modelle dafür zum Einsatz kommen – lokal betrieben oder über einen externen Anbieter – entscheiden Sie.