Funktion
Es läuft
Alle sind zufrieden — solange es läuft.
Verluste · Leistung · Risiko
Was wäre, wenn Ihre Anlage selbst sagt,
wo sie Leistung verliert?
Heute steckt das Verhalten Ihrer Maschinen in einer BlackBox. Verluste, Leistung und Risiko werden geschätzt — mit MES, Datenprojekten und Interpretation. Bei einer WhiteBox liegt das Sollverhalten als Referenz vor, und diese Information entsteht direkt.
01 — Kennen Sie das?
Kennen Sie das?
Die Daten sind da. Die Antwort fehlt.
Sie investieren in MES, Datenerfassung und Auswertungen. Trotzdem bleibt die wichtigste Frage offen: Was ist an der Maschine passiert — und was kostet es?
Verluste
Die Maschine steht — und keiner weiß, warum. Gesprochen wird über Motoren, Sensoren und den Programmierer, nicht über die Ursache.
Leistung
Die Linie läuft, aber langsamer als geplant. Welcher Schritt die Taktzeit kostet, bleibt eine Vermutung.
Zusätzliches Investment
Die Daten liegen im MES, aber niemand kann sagen, was sie bedeuten. Jede Auswertung braucht IT, Spezialisten und jemanden, der interpretiert.
Risiko
Die Inbetriebnahme dauert länger, weil das Verhalten erst vor Ort entsteht. Die Überraschung kommt, wenn der Business Case schon gerechnet ist.
02 — Die Ursache
Die Ursache
Alles, was Sie auf die Maschine setzen, baut auf einer BlackBox auf.
Beschrieben wird, was die Maschine tun soll — nicht, woran man erkennt, dass sie es tut. Eine Funktionsbeschreibung kennt zwei Ergebnisse: Es läuft, oder es gibt eine Störung. Gemeldet wird nur, woran jemand gedacht hat.
Auch die Abnahme schließt diese Lücke nicht. Eine bestandene Abnahme ist eine Momentaufnahme einer Stichprobe: Sie gilt für den geprüften Ausschnitt und für den Prüfzeitpunkt. Was nie beobachtet wurde, ist nicht geprüft — es ist nur nicht aufgefallen. Und eine spätere Änderung kann die Aussagekraft des Nachweises verändern.
Dazwischen liegt ein Bereich, der weder Funktion noch Störung ist. Dort entstehen Stillstand, Minderleistung und Streit.
Nicht-Funktion
Störung
Gemeldet wird, was jemand vorhergesehen hat.
Undefiniert
Weder noch
Die Maschine steht ohne Meldung oder läuft langsamer, ohne dass es jemand merkt.
Dieser undefinierte Teil ist die BlackBox Ihrer Maschine.03 — Was möglich ist
Heute · BlackBox
Störung 4711
Station 30 · Zeitüberschreitung. Dauer 18 Minuten, Ursache offen. Der Instandhalter sucht, der Programmierer wird angerufen. Das Management sieht einen OEE-Wert ohne Erklärung.
Signal → Störmeldung → Suche → Interpretation
Mit WhiteBox
Abweichung
Station 30 · Spannen · Schritt „Spannung bestätigen“. Erwartet: Spannstellung bestätigt innerhalb der festgelegten Zeit. Ergebnis: nicht erfüllt. Folge: Vorschub gesperrt, wie in der Behavior Reference (BR) vorgesehen. Verlust: 18 Minuten, 42 Stück.
Soll → Ist → Urteil → Verlust in Zeit und Stück
WhiteBox heißt nicht, dass man den Code sieht. WhiteBox heißt, dass Konformität entscheidbar ist statt beurteilbar.
Verlust-Pareto · Verfügbarkeit · Beispiel
Station 30 · Spannen · Spannung nicht bestätigt96 min · 210 Stück
Station 50 · Zuführen · Teil nicht erkannt63 min · 140 Stück
Station 20 · Handbetrieb angewählt ohne Fehler39 min · 85 Stück
Station 70 · Interlock21 min · 46 Stück
Beispielhafte Darstellung mit fiktiven Werten. Ohne zusätzliches MES-Projekt: Die Bedeutung jedes Zustands steht in der Behavior Reference (BR), das Cockpit zeigt sie an. Es greift nicht in die Steuerung ein — die Maßnahmen entscheiden Sie.
OEE Cockpit · zwei Beispiele zum AusprobierenBeispiel 1 · Verlust-Übersicht
Wohin geht die Zeit? Verfügbarkeit, Leistung, Engpass und Wartezeit auf einen Blick, mit Nachweis je Verlustquelle. Beispiel öffnen
Beispiel 2 · Pareto 80/20
Welche wenigen Positionen erklären den Großteil des Verlusts? Jede Position im Klartext aus der Behavior Reference (BR). Beispiel öffnen
04 — Wie das funktioniert
Die Referenz liegt zur Laufzeit vor.
Die Abweichung wird bestimmt, nicht gesucht.
Ein Bedienbild zeigt, was gerade passiert. Ob das, was passiert, dem entspricht, was passieren soll, lässt sich nur gegen eine Referenz entscheiden. Die Behavior Reference (BR) ist keine nachträgliche Dokumentation des Codes. Sie entsteht vor dem Code — so wie ein Schaltplan vor der Installation.
01
Das Soll
Das Soll steht fest
Zustände, Übergänge, Zeiten und Reaktionen sind in der Behavior Reference (BR) festgelegt, bevor programmiert wird.
02
Der Vergleich
Abweichungen werden entschieden
Jede Situation wird gegen das Soll entschieden: entspricht, weicht ab oder ist derzeit nicht beurteilbar. Keine Meldung heißt nicht mehr „in Ordnung“. Erkannt wird die Abweichung vom definierten Verhalten; was nicht modelliert ist, ist nicht abgedeckt.
03
Die Information
Eine Sprache für alle Maschinen
Die Information ist standardisiert — gleich aufgebaut über Maschinen, Lieferanten und Steuerungshersteller hinweg.
Jede BlackBox kann eine WhiteBox werden — auch Ihre bestehende Anlage.
Verifikation fragt: Wurde richtig gebaut? Validierung fragt: Wurde das Richtige gebaut? Selmo adressiert die Verifikation gegen die freigegebene Behavior Reference (BR). Die Validierung gegen den ursprünglichen Intent bleibt davon getrennt erforderlich.
05 — Die Wirkung
Aus der Verlustgröße
wird eine Gewinngröße.
Der Nutzen entsteht nicht durch eine einzelne Softwarefunktion, sondern dadurch, dass entschieden statt interpretiert wird. Die Kausalität ist klar; die Höhe ist projektspezifisch.
01
Verluste erkennen02
Leistungspotenzial erkennen03
Risiko senken04
Produktivität steigernVerluste erkennen
Stillstand in Zeit und Stück, mit Station, Schritt und Grund — als Pareto, nicht als Vermutung.
Leistungspotenzial erkennen
Schrittzeiten gegen Soll zeigen den Engpass. Sie wissen, wo eine Taktzeitsteigerung ansetzt.
Risiko senken
Weniger ungeplante Stillstände, belastbare Wirtschaftlichkeit und belegbare Abweichungen — auch gegenüber Lieferanten.
−50 bis −80 %Integrationszeit
−40 bis −70 %ungeplanter Stillstand
+3 bis +10 %OEE
−25 bis −50 %Instandhaltung
+5 bis +20 %Output
Bandbreiten aus umgesetzten Kundenprojekten. Der tatsächliche Wert ist projektspezifisch und wird im Assessment an Ihrer Anlage gemessen. Integrationszeit: vom ersten Laden der Software bis zum bestandenen Verifikations-Gate.
06 — Hinschauen
Keine technische Frage.
Die Frage ist: Wie ist es denn jetzt?
Vergleichen kann nur, wer hinschaut. Dafür muss niemand ein Programm lesen. Fünf Kriterien zeigen, wo Ihre Anlage heute steht. Jedes Nein ist keine Bewertung, sondern eine Feststellung.
Die Leitfrage
„Gegen welches Dokument prüfen Sie ab, ob sich Ihre Maschine richtig verhält?“
Definiert
Gibt es für das Verhalten ein eigenes Dokument — wie den Stromlaufplan?
Entscheidbar
Können Sie das Verhalten prüfen, ohne das Programm zu lesen?
Diagnostizierbar
Zeigt die Maschine, welche Erwartung nicht erfüllt wurde?
Kontrolliert veränderbar
Wird eine Änderung zuerst im Sollverhalten gemacht?
Übergebbar
Bleibt das Wissen, wenn die Person oder der Lieferant geht?
L0
BlackBox
Verhalten nur im Code.
L1
Beschrieben
in Prosa, nicht formal prüfbar.
L2
Explizite Zustände
strukturiert, ohne normative Autorität.
L3
Entscheidbar
Wendepunkt WhiteBox.
L4
Lebenszyklus
Entscheidbarkeit bleibt über Änderungen erhalten.
L5
Architektur
vollständig aus der Behavior Reference (BR) abgeleitet.
Den Reifegrad vergibt das WhiteBox Assessment, mit Belegen an der Anlage. Einen ersten Eindruck gibt der Selbstcheck.
07 — Der Weg zur Entscheidung
In zwei Schritten
zu einer klaren Entscheidung.
Beide Schritte arbeiten mit Ihren Leuten und Ihren Unterlagen. Sie verlangen keine Vorleistung und keine Umstellung — und beide dürfen ergeben, dass jetzt nicht der richtige Zeitpunkt ist.
Schritt
Was passiert
Was Sie erhalten
Strategy Workshop
zwei Tage vor Ort
zwei Tage vor Ort
Tag 1: Zielbild und Anwendungsfall. Tag 2: Umfang, Grenzen und Reihenfolge. Mitgeschrieben wird während der Diskussion, nicht danach.
Zielbild · Anwendungsfall mit Begründung · Umfang und Grenzen · Roadmap · offene Annahmen
WhiteBox Assessment
ein bis drei Tage vor Ort
ein bis drei Tage vor Ort
Unterlagen, Gespräche mit den Menschen, die die Anlage kennen, Beobachtung an der Anlage. Jede Anforderung wird eingestuft: direkt entscheidbar, indirekt, eingeschränkt oder nicht entscheidbar.
Einstufungsbericht · Reifegradprofil L0–L5 · Lückenliste nach Auswirkung · Maßnahmenpfad
Ihre Entscheidung
Ist das Ziel so klar, dass das Engineering ohne stillschweigende Annahmen beginnen kann?
Eine Einstufung, keine Kaufempfehlung. Die Unterlagen gehören Ihnen.
08 — Aufwand und Ersparnis
Ihr Aufwand wird nicht höher.
Er verschiebt sich nach vorne.
Die Fragen zum Verhalten werden ohnehin beantwortet — heute nur zu spät: in der Inbetriebnahme, im Stillstand, im Streit. Mit Selmo werden sie beantwortet, bevor programmiert wird.
In der UmsetzungWeniger Nacharbeit, eine kürzere Integration und eine Inbetriebnahme, in der nicht mehr entwickelt wird.
Im BetriebKürzere Zeit bis zur Ursache, weil die Maschine zeigt, welche Erwartung nicht erfüllt wurde.
An ZusatztoolsKeine Werkzeuge mehr, die nachträglich deuten sollen, was die Maschine gemeint hat.
Am meisten gespart wird hier: entscheiden statt beurteilen, interpretieren und probieren.
Jede Situation, die entschieden werden kann, muss niemand mehr beurteilen. Das spart Zeit in jeder Besprechung, jeder Störung und jeder Abnahme — über die gesamte Lebensdauer der Anlage. Gewährleistung ersetzt die Reparatur, nicht den Stillstand: Der Ausfall liegt beim Betreiber.
09 — Die Studie zum Maschinenverhalten
Wir schauen 100 Anlagen an.
Ist Ihre dabei?
Jeder Strategy Workshop und jedes WhiteBox Assessment beantwortet dieselbe Frage: Wie ist es denn jetzt? Mit Ihrer Zustimmung fließen die Ergebnisse anonymisiert in eine Studie über das Maschinenverhalten in der Produktion.
Nie wieder ohne Behavior Reference (BR). So wie nie wieder ohne Zeichnung oder Schaltplan.
10 — Für Maschinenbau und Automatisierung
Ihre Verantwortung bleibt.
Ihre Leistung in der Programmierung wird beweisbar.
Wenn Ihre Kunden das Sollverhalten einfordern, verschieben sich die Marktanforderungen. Wer nachweisen kann, was er geliefert hat, hebt sich ab. Wer es nicht kann, steht im Wettbewerb unter Druck.
Wie engineeren Sie heute Ihre Programmierung?
Entsteht das Verhalten im Engineering — oder erst in der Inbetriebnahme?
Wogegen wird Ihre Programmierung verifiziert?
Gegen ein freigegebenes Soll — oder gegen das, was am Ende läuft?
Was ist Ihr Ergebnis aus dem Engineering?
Außer dem Code: Gibt es ein Objekt, das Ihr Kunde prüfen kann?
Schritt
Was er verlangt
Grundlage
01 Wirkung festlegen
Welche Aktion, welche erwartete Reaktion?
Prozess
02 Auslegen statt ausprobieren
Ist die Wirkung realisierbar, messbar und entscheidbar? Risiken werden vor dem Code erkannt und bewertet — möglich schon vor der Hardware, im Rahmen der Risikobeurteilung.
Technologie
03 Sollverhalten freigeben
Zustände und Übergänge gehen in die Behavior Reference (BR) — freigegeben, bevor programmiert wird.
Funktion · Behavior Gate
04 Gegen das Soll verifizieren
Die Umsetzung erhält Struktur und Ablauflogik der Behavior Reference (BR).
Verifikations-Gate
05 Wirkung nachweisen
Integration, FAT und SAT prüfen gegen das freigegebene Soll — nicht gegen ein As-Built.
Abnahme
06 Änderungen zuerst im Soll
Jede Änderung beginnt in der Behavior Reference (BR); der Nachweis wird gezielt erneuert.
Change Verification
Ausgearbeitet über die PTF (Prozess · Technologie · Funktion) nach Behavior-Centric Engineering (BCE).
11 — Maschinenverordnung
Verordnung (EU) 2023/1230
Ab 20. Januar 2027 wird aus „Es läuft“ eine Nachweisfrage.
Die Verordnung schreibt keine Methode vor. Sie verlangt aber, dass sich belegen lässt, was beurteilt und ausgelegt wurde.
Eine Behavior Reference (BR) strukturiert Nachweise und trägt zur Dokumentation bei. Sicherheitsfunktionen brauchen weiterhin ihre eigene Auslegung und Validierung; die Konformitätsbewertung bleibt beim Maschinenhersteller.
Anhang III · Allgemeine Grundsätze
Risikobeurteilung
über den gesamten Lebenszyklus, als Grundlage der Konstruktion.
Anhang III · 1.2.1
Steuerungen
Hardware- und Softwaredefekte sowie Logikfehler dürfen nicht zu Gefährdungssituationen führen.
Anhang III · 1.2.1
Rückverfolgung
Eingriffe und hochgeladene Versionen sicherheitsrelevanter Software müssen nachvollziehbar bleiben.
Zusammenfassung, keine Rechtsberatung. Maßgeblich ist der Wortlaut der Verordnung.
12 — Engineering auf den Tisch
Schauen Sie hin,
wie Ihre Programme heute entstehen.
Legen Sie uns Auslegung, Übersetzung und Nachweis der Wirkung vor. Wir zeigen Ihnen, wo Ihr Engineering heute steht.
Inbetriebnahme
Entsteht das Verhalten im Engineering — oder wird es in der Inbetriebnahme erst gefunden?
Leistung
Ist Ihre Leistung in der Programmierung beweisbar — oder nur funktionsfähig?
Risikobeurteilung
Könnten Sie belegen, dass die Risikobeurteilung vor der Programmierung stattfand?
Und was heißt das für Ihre Verantwortung?
Die Verantwortung verändert sich nicht. Neu ist, dass sich belegen lässt, was verlangt war, was geliefert wurde und wo eine Abweichung liegt.
13 — Wer das baut
Warum wir über Verhalten
sprechen können.
Selmo ist aus der Inbetriebnahme entstanden, nicht aus der Beratung. Die Methode wurde an realen Anlagen entwickelt und dort korrigiert, wo eine Abweichung Stillstand bedeutet. Was wir über Verhalten behaupten, haben wir vorher selbst gegen eine Referenz geprüft.
Was die Methode nicht leistet
Selmo ersetzt weder Inbetriebnahme noch Erfahrung — es reduziert den Ursachenraum. Und geprüft ist immer der definierte Verhaltensraum: Was nicht modelliert ist, ist nicht abgedeckt.
Die entscheidende Frage
Wenn Ihre Maschine morgen steht — was davon wäre beweisbar?
Hinschauen — Erstgespräch vereinbaren15–30 Minuten, konkret an Ihrer kritischsten Maschine. Kostenlos und unverbindlich.