Leistung 06 · Lifecycle Services

Ein Nachweis, der mit
jeder Änderung verfällt.

laufend, als Jahresvertrag  ·  Umfang und Rhythmus je Linie im SLA  ·  Voraussetzung: ausgelieferte Behavior Defined Machine (BDM) mit freigegebener Behavior Reference (BR)

Ergebnis ist eine Behavior Reference (BR), die aktuell bleibt: Jede Änderung wird im Modell beschrieben, neu abgeleitet und als Change Verification gegen die geänderte Referenz geprüft — protokolliert im Service-Report.

01 — Warum das nötig ist

Der Nachweis gilt
für einen Zeitpunkt.

Ein Beobachtungsnachweis beschreibt einen Systemzustand, keine Systemeigenschaft. Im Betrieb ändert sich dieser Zustand laufend: eine Codeanpassung in der Nachtschicht, ein verstellter Parameter, ein getauschter Sensor, ein neues Rezept, ein Retrofit, ein Firmware-Update. Solange kein Mechanismus die Änderung mit dem Nachweis verknüpft, verfällt er unbemerkt. Genau diese Zeitpunkt-Grenze ist der Grund für diese Leistung.

Ausgangslage 01 — Zeitpunkt

Ein Zustand, keine Eigenschaft

Der Nachweis aus der Abnahme beschreibt, wie sich die Anlage an einem Tag verhalten hat. Er sagt nichts darüber, wie sie sich nach der nächsten Änderung verhält.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 jede spätere Änderung setzt den Nachweis außer Kraft, ohne dass es jemand bemerkt.

Ausgangslage 02 — Änderung

Änderungen sind Change Verification

Verifikation fragt: Wurde richtig gebaut? Validierung fragt: Wurde das Richtige gebaut? Eine Änderung im Betrieb beantwortet die erste Frage neu — gegen die geänderte Referenz, nicht gegen den Intent.Deshalb heißt der Schritt Change Verification: Die Behavior Reference (BR) wird kontrolliert geändert, die Implementierung daraus neu abgeleitet und das Runtime Behavior gegen die geänderte Referenz geprüft.

Ausgangslage 03 — Abweichung

Symptom oder Differenz

Weil im aktiven Zustand bekannt ist, welche Reaktion erwartet wird, muss Verhalten nicht abgetastet, sondern kann verglichen werden. Damit wird aus einer Störungsmeldung eine benennbare Abweichung.Ein Fehler ist ein Symptom. Eine Behavior Deviation ist eine Differenz — zwischen dem Sollverhalten der Behavior Reference (BR) und der beobachteten Realität.

Der ganze Weg in sieben Stufen ↘

02 — Was Sie bekommen

Sieben Bausteine.
Eine lebende Referenz.

Wiederkehrende Leistungen mit klarem Rhythmus und einem Ergebnis je Leistung. Umfang und Frequenz werden je Linie im SLA festgelegt. Das Modell hat Vorrang: Änderungen werden in der Behavior Reference (BR) beschrieben und neu abgeleitet — nie direkt im Code.

01
Baustein 01 · Modellpflege

Die Referenz bleibt aktuell

Laufend und je Änderung. Ergebnis ist eine gepflegte Behavior Reference (BR) mit nachvollziehbarem Versionsstand.

02
Baustein 02 · Change Verification

Jede Änderung läuft über das Modell

Je Änderung. Geprüft wird gegen die geänderte Behavior Reference (BR). Ergebnis ist ein Change-Verification-Report mit Version und Freigabe.

03
Baustein 03 · Regressionstest

Was vorher galt, gilt weiterhin

Je Release und je Retrofit. Betroffene Testfälle werden erneut ausgeführt. Ergebnis ist ein Testprotokoll.

04
Baustein 04 · Retrofit-Unterstützung

Umbau ohne Verlust der Referenz

Umbauten, neue Rezepte und Komponentenwechsel werden zuerst im Modell beschrieben, dann abgeleitet und geprüft.

05
Baustein 05 · Remote-Diagnose

Diagnose im Behavior-Kontext

Bei Vorfall und laufend. Ausgewertet werden Behavior Deviations statt Symptomlisten — die Differenz ist benannt, nicht rekonstruiert.

06
Baustein 06 · Behavior Analytics

Muster über die Zeit

Monatlich. Wiederkehrende Abweichungen, Wartezeiten und Wiederanlaufmuster werden über Perioden hinweg ausgewertet.

07
Baustein 07 · Überprüfung & Review

Quartalsweise nachgeschärft

Reifegrad- und Konformitätscheck der Behavior Defined Machine (BDM) sowie ein Service-Review mit Maßnahmen und offenen Punkten.

WhiteBox heißt nicht, dass man den Code sieht. WhiteBox heißt, dass Konformität entscheidbar ist statt beurteilbar.

03 — Das Ergebnis

Ein Report.
Je Periode.

Ein wiederkehrender Service-Report dokumentiert SLA-Erfüllung, Änderungen, Diagnose und Empfehlungen — vertraulich und nur für Sie.

Ergebnis: eine Behavior Reference (BR), die aktuell bleibt — und eine Konformität, die entscheidbar bleibt.
Grundlage für Verlängerung und für die Ausweitung auf weitere Linien und Standorte. Das Modell bleibt im Eigentum des Betreibers, als Objekt übergebbar.
Übersicht

Linien, Zeitraum und Beteiligte auf einer Seite.

SLA-Erfüllung

Vereinbarter Umfang gegen erbrachte Leistung, je Linie.

Change Verifications

Jede Änderung mit Ergebnis, Version und Freigabe.

Regressionstests

Welche Testfälle erneut ausgeführt wurden und mit welchem Ergebnis.

Behavior Deviations & Behavior Analytics

Benannte Differenzen zur Referenz und ihre Muster über die Periode.

Pflege der Behavior Reference (BR)

Welche Teile des Modells geändert wurden — mit Versionsstand und Anlass.

Empfehlungen & offene Punkte

Was als Nächstes ansteht, mit Verantwortlichem und Auswirkung auf den Betrieb.

Nächster Zeitraum & Freigabe

Geplanter Umfang der nächsten Periode und die dokumentierte Freigabe.

04 — Ablauf und Gates

Fünf Phasen.
Vier Gates.

Ein Gate ist eine Entscheidung, kein Termin und kein Review. Es gelten nur vier: Gate 0 fragt, ob der Intent so bestimmt ist, dass Engineering ohne stillschweigende Annahmen beginnen kann. Das Behavior Gate fragt, ob das erwartete Verhalten so vollständig definiert ist, dass die Implementierung kein eigenes Verhalten erfinden muss. Das Verifikations-Gate fragt, ob ein integriertes, betriebsfähiges, prüfbares System vorliegt. Das Validierungs-Gate fragt, ob das verifizierte System den Intent erfüllt. Eine Änderung durchläuft dieselben vier.

Phase
Was passiert
Gate
PhasePhase 1 · Änderung aufnehmen

Was passiertAnlass, Umfang und Auswirkung klären. Berührt die Änderung den Intent, beginnt sie ganz vorne.

GateGate 0, wenn der Intent berührt ist
PhasePhase 2 · Modell zuerst

Was passiertDie Änderung wird in der Behavior Reference (BR) beschrieben und freigegeben — nie direkt im Code.

GateBehavior Gate
PhasePhase 3 · Ableiten

Was passiertCode, HMI und Diagnose werden aus der aktualisierten Referenz neu abgeleitet, eine Quelle bleibt führend.

Gatekein eigenes Gate — läuft in das Verifikations-Gate
PhasePhase 4 · Change Verification

Was passiertBetroffene Testfälle erneut ausführen, Runtime Behavior gegen die geänderte Referenz prüfen, Behavior Deviations dokumentieren.

GateVerifikations-Gate
PhasePhase 5 · Freigabe und Report

Was passiertÄnderung mit Ergebnis, Version und Freigabe protokollieren, in den Service-Report übernehmen.

GateValidierungs-Gate, wenn der Intent berührt war
05 — Umfang

Was enthalten ist —
und was nicht.

Der Umfang ist entscheidbar, nicht auslegbar. Was nicht enthalten ist, verweist auf die Leistung, die es abdeckt.

Enthalten
Modellpflege

Die Behavior Reference (BR) bleibt aktuell, mit nachvollziehbarem Versionsstand.

Change Verification & Regressionstest

Prüfung gegen die geänderte Referenz, erneute Ausführung der betroffenen Testfälle.

Retrofit-Unterstützung

Umbauten und neue Rezepte zuerst im Modell, dann abgeleitet und geprüft.

Remote-Diagnose im Behavior-Kontext

Auswertung der Behavior Deviations statt Rekonstruktion aus Symptomen.

Behavior Analytics

Monatliche Auswertung wiederkehrender Abweichungen und Wiederanlaufmuster.

Überprüfung & Service-Review

Quartalsweiser Reifegrad- und Konformitätscheck sowie Service-Report mit Maßnahmen.

Nicht enthalten
Neuentwicklung und Erstumsetzung

Sie erfolgen im Behavior Defined Machine (BDM) Engineering Project.

Unternehmensweite Standardeinführung

Sie erfolgt in der Enterprise Transformation, über mehrere Werke hinweg.

Prüfung und Qualifikation von Personen

Sie erfolgen in Certification & Training, mit Selmo-eigenen Qualifikationen.

Die Behavior Reference (BR) ist keine nachträgliche Dokumentation des Codes. Sie entsteht vor dem Code.

06 — Einordnung

Sieben Leistungen.
Sie stehen bei 06.

Die Reihenfolge entspricht dem Weg, nicht dem Umsatz. Sie kombinieren die Stufen, die Ihr Weg zur Behavior Defined Machine (BDM) braucht.

Was die Methode nicht leistet

Der definierte Verhaltensraum ist der geprüfte Raum. Was nicht modelliert ist, ist nicht abgedeckt — die Grenze verschiebt sich, sie verschwindet nicht.

Der nächste Schritt

Wie lange nach der Abnahme gilt Ihr Abnahmeprotokoll noch?

Servicevertrag anfragen

15–30 Minuten Erstgespräch: Linien, SLA und Reporting für Ihre Lifecycle Services. Kostenlos und unverbindlich.