Zum Inhalt springen
Decision-State-Infrastruktur
ende
Anwendungen

Produktänderung & Produktfreigabe

PRODUCT RELEASE / CHANGE GOVERNANCE

Was muss geklärt sein, bevor eine geänderte Produktkonfiguration freigegeben werden kann?

Ein genehmigter Änderungsantrag ist noch keine Produktfreigabe. Auch bestandene Tests reichen nicht automatisch aus. Entscheidend ist, ob sie genau die Hardware-, Firmware- und Variantenkonfiguration abdecken, die tatsächlich in Produktion, Service oder Markt gelangen soll.

In diesem vollständig illustrativen Fall muss die fiktive Norevia Motion Systems SE über die Freigabe ihrer Servoantriebsfamilie Vektorion SafeDrive S4 entscheiden. Wegen der Abkündigung eines elektronischen Bauteils wird die Hardware von Revision H3 auf H4 und die Embedded Firmware von Version 4.7.2 auf 4.8.0 geändert.

Die Varianten S4-08 und S4-22 sind für die neue Konfiguration vollständig geprüft. Für die leistungsstärkere Variante S4-45 fehlt eine kombinierte Hochtemperatur- und Single-Fault-Prüfung. Engineering hält eine Übertragung vorhandener Nachweise für vertretbar; Verification und Product Safety sehen die variantenspezifische Abdeckung noch nicht als ausreichend belegt.

Die relevante Frage lautet nicht nur: Wurde die technische Änderung bearbeitet und freigegeben?

Bilden die genaue Produktkonfiguration, die betroffenen Varianten, die anwendbaren Anforderungen, die tatsächlich geltenden Prüfungen, offene Abweichungen, Release-Bedingungen und die zuständige Freigabebefugnis gemeinsam einen ausreichend bestimmten Zustand für genau diesen Product Release?

ENGINEERING CHANGE APPROVED ≠ PRODUCT CONFIGURATION RELEASED

I / DIE PRODUKTFREIGABE

Die Entscheidung betrifft nicht den Änderungsantrag. Sie betrifft eine exakt definierte Produktkonfiguration.

01

Der Product Release ist konkret

Norevia Motion Systems SE und Vektorion SafeDrive S4 sind vollständig fiktiv. Norevia wird als Hersteller industrieller Servoantriebe dargestellt.

Variante

S4-08

Nennleistung

7,5 kW

Typischer Einsatz

Kleinere Maschinenachsen

Variante

S4-22

Nennleistung

22 kW

Typischer Einsatz

Mittlere Maschinenachsen

Variante

S4-45

Nennleistung

45 kW

Typischer Einsatz

Leistungsstarke Haupt- und Förderachsen

02

Die bisherige Baseline ist bereits freigegeben

Dimension

Product Family

Freigegebene Baseline

Vektorion SafeDrive S4

Dimension

Varianten

Freigegebene Baseline

S4-08 / S4-22 / S4-45

Dimension

Hardware Revision

Freigegebene Baseline

H3

Dimension

Embedded Firmware

Freigegebene Baseline

4.7.2

Dimension

Safety Functions

Freigegebene Baseline

STO / SS1

Dimension

Produktionsstandort

Freigegebene Baseline

Norevia Plant West

Dimension

Markt-Scope

Freigegebene Baseline

EU / EEA

Dimension

Product State

Freigegebene Baseline

RELEASED

Die historische Baseline bleibt erhalten; die geplante Änderung überschreibt sie nicht rückwirkend.

03

Der Change ist eine gebundene Hardware-/Firmwarekonfiguration

Ein abgekündigtes elektronisches Bauteil im zweikanaligen Safety Input wird ersetzt; zugleich wird das diagnostische Sampling- und Plausibilisierungsfenster der Embedded Firmware angepasst.

HARDWARE H3 → H4

FIRMWARE 4.7.2 → 4.8.0

Die relevante Change Identity ist Hardware H4 in Verbindung mit Firmware 4.8.0.

04

Derselbe Produkttyp bedeutet nicht dieselben Prüfbedingungen

Die Varianten teilen Safety-I/O-Architektur, Firmware und Kommunikationsschnittstelle, unterscheiden sich aber bei Leistung, thermischer Belastung, Leiterplattenlayout, Kühlung und interner Verlustleistung.

SAME PRODUCT FAMILY ≠ IDENTICAL VERIFICATION CONDITIONS

05

Change Approval und Product Release sind verschiedene Entscheidungen

Ein Engineering Change kann beschrieben, geprüft und administrativ genehmigt sein, ohne festzulegen, welche Varianten, Märkte, Produktionspopulationen, Servicefälle und Release-Bedingungen freigegeben sind.

CHANGE REQUEST ACCEPTED

≠

PRODUCT CONFIGURATION RELEASED

06

Der geplante Full-Family Release

Dimension

Hardware

Vorgesehener v1-Scope

H4

Dimension

Firmware

Vorgesehener v1-Scope

4.8.0

Dimension

Varianten

Vorgesehener v1-Scope

S4-08 / S4-22 / S4-45

Dimension

Markt

Vorgesehener v1-Scope

EU / EEA

Dimension

Release Mode

Vorgesehener v1-Scope

Reguläre Neuproduktion

Dimension

Service Scope

Vorgesehener v1-Scope

H4-Ersatzgeräte für die Familie

Dimension

Field Firmware Update

Vorgesehener v1-Scope

AUSGESCHLOSSEN

Dimension

Geplanter Termin

Vorgesehener v1-Scope

18. November 2026

Dimension

Release Authority

Vorgesehener v1-Scope

Product Release Board

Darf Norevia H4 mit Firmware 4.8.0 für alle drei Varianten und den vorgesehenen Neuproduktions- und Service-Scope freigeben?

07

Responsibility und Authority sind getrennt

Rolle

Power Electronics Engineering

Authority im illustrativen Fall

Verantwortet die Hardwareänderung

Rolle

Embedded Safety Software

Authority im illustrativen Fall

Firmware und Build Identity

Rolle

Verification Lead

Authority im illustrativen Fall

Testplanung, Durchführung und Coverage

Rolle

Product Safety Manager

Authority im illustrativen Fall

Safety Impact und Evidence Assessment

Rolle

Product Compliance Lead

Authority im illustrativen Fall

Anwendbarer Compliance- und Conformity-State

Rolle

Quality Release Manager

Authority im illustrativen Fall

Change Control, Abweichungen und QMS-Gates

Rolle

Product Release Board

Authority im illustrativen Fall

Finale interne Release Authority

08

Auch eine finale interne Authority darf Evidence nicht umdeuten

  • 01Sie darf einen nicht durchgeführten Test nicht als bestanden behandeln.
  • 02Sie darf eine technische Annahme nicht still zu einem Fact machen.
  • 03Sie darf Product-Safety-Authority nicht ohne Mandat ersetzen.
  • 04Sie darf keinen breiteren Scope freigeben, als die Evidence trägt.

AUTHORITY TO DECIDE ≠ AUTHORITY TO REWRITE THE EVIDENCE STATE

09

Factory Release, Service Release und Field Update sind nicht identisch

Entscheidung

Factory Release

Scope

Neuprodukte mit definierter Konfiguration

Entscheidung

Service Replacement Release

Scope

Ersatzgeräte oder -teile für installierte Produkte

Entscheidung

Field Firmware Update

Scope

Firmware für eine installierte Population

Entscheidung

Retrofit

Scope

Physische Änderung installierter Geräte

11

Auch der regulatorische Zeitpunkt gehört zum Decision State

Die Maschinenverordnung (EU) 2023/1230 gilt grundsätzlich ab dem 20. Januar 2027. Der illustrative Release-Termin liegt am 18. November 2026. Der anwendbare Rechtsrahmen erfordert weiterhin eine gesonderte Produktklassifikation durch die zuständigen Funktionen.

Primärquelle: Verordnung (EU) 2023/1230 über Maschinen

12

Software- und Firmwareänderungen können produktrechtlich relevant sein

Der Blue Guide der Europäischen Kommission behandelt physische Änderungen und Software-Updates als potenziell relevant für den Konformitätsstatus. Er ist eine offizielle, aber nicht bindende Auslegungshilfe.

Primärquelle: Europäische Kommission — Blue Guide 2022

Eine Firmwareänderung ist nicht automatisch nur ein Software-Release-Thema.

II / KONFIGURATION UND EVIDENCE COVERAGE

Ein Nachweis wird erst release-relevant, wenn seine Konfiguration und sein Scope klar sind.

13

Vieles ist bereits geklärt

  • 01Product Identity und historische Baseline
  • 02Hardware H4 und Firmware Build 4.8.0
  • 03Engineering Change EC-2741 und Requirements Delta
  • 04Component Qualification und Manufacturing Process
  • 05End-of-Line-Test, Build Traceability und Release-Rollen

Ein großer Teil des Product State ist resolved. Ein präziser Required State bleibt offen.

14

Die Verification Campaign ist variantenspezifisch

Variante

S4-08

Abgeschlossene Coverage

Functional, Regression, Thermal, Fault Injection, STO, SS1

Offene Coverage

NONE

Variante

S4-22

Abgeschlossene Coverage

Functional, Regression, variantenspezifisch Thermal, Fault Injection, STO, SS1

Offene Coverage

NONE

Variante

S4-45

Abgeschlossene Coverage

Functional, Regression, nominale Reaction Time, Normaltemperatur, STO, SS1

Offene Coverage

KOMBINIERTE HOCHTEMPERATUR + SINGLE-FAULT

15

Die Coverage Map

Variante

S4-08

Functional

PASS

Regression

PASS

Thermal

PASS

Single-Fault

PASS

Combined

PASS

Coverage

COMPLETE

Variante

S4-22

Functional

PASS

Regression

PASS

Thermal

PASS

Single-Fault

PASS

Combined

PASS

Coverage

COMPLETE

Variante

S4-45

Functional

PASS

Regression

PASS

Thermal

PARTIAL

Single-Fault

PARTIAL

Combined

NOT COMPLETED

Coverage

INCOMPLETE

16

Ein fehlender Test ist nicht dasselbe wie ein nicht bestandener Test

TEST NOT COMPLETED

≠

TEST FAILED

Der aktuelle State belegt weder, dass die Konfiguration sicher ist, noch dass sie unsicher ist. Er belegt, dass der vorgesehene Nachweis die definierten Worst-Case-Bedingungen noch nicht abdeckt.

17

Fact, Evidence, Inference und Decision bleiben getrennt

Klasse

Fact

Aktuelle Aussage

Der kombinierte S4-45-Test ist nicht abgeschlossen

Klasse

Evidence

Aktuelle Aussage

S4-08 und S4-22 haben die definierte Kampagne bestanden

Klasse

Inference

Aktuelle Aussage

Gemeinsame Architektur könnte die Übertragung bestimmter Ergebnisse tragen

Klasse

Conflict

Aktuelle Aussage

Die S4-45-Worst-Case-Konfiguration ist nicht repräsentiert

Klasse

Decision

Aktuelle Aussage

Reicht dies für den Full-Family Release?

18

Ein gültiger Testbericht besitzt einen begrenzten Geltungsbereich

  • 01Eine andere Hardware Revision kann geprüft worden sein.
  • 02Eine andere Firmware oder Produktvariante kann verwendet worden sein.
  • 03Andere Thermal-, Fault- oder Betriebsbedingungen können gegolten haben.
  • 04Der Release Scope kann breiter als der Test Scope sein.

EVIDENCE EXISTS ≠ EVIDENCE APPLIES TO THIS RELEASE CONFIGURATION

19

Der Evidence-Inheritance-Konflikt

Funktion

Engineering

Position

Gemeinsame Architektur und identische Firmware tragen eine Äquivalenz

Funktion

Verification

Position

Die S4-45-Worst-Case-Konfiguration ist nicht repräsentiert

Funktion

Product Safety

Position

Übertragung erfordert autorisierte Äquivalenz oder direkte Evidence

Funktion

Quality

Position

Administrative Deviation kann technische Coverage nicht erzeugen

S4-45 VERIFICATION COVERAGE — CONFLICTING

20

Evidence Inheritance ist eine fachliche Entscheidung

  • 01Technische Vergleichsbasis und identifizierte Unterschiede
  • 02Relevante Worst-Case-Bedingungen und Requirements-Bezug
  • 03Dokumentierte Unsicherheit und definierter Scope
  • 04Zuständige fachliche Authority

EVIDENCE INHERITANCE ≠ FAMILY-WIDE ASSUMPTION

21

Requirements Coverage ist ebenfalls variantenspezifisch

Die Änderung betrifft Diagnoseverhalten, Reaktionszeit, Fehlersichtbarkeit, Hardware-/Firmware-Interaktion und thermische Robustheit. Auch ein unverändertes Requirement benötigt Evidence, die für die geänderte Konfiguration gilt.

REQUIREMENT UNCHANGED ≠ OLD EVIDENCE AUTOMATICALLY SUFFICIENT

22

Manufacturing Readiness ist bereits weitgehend resolved

  • 01Wareneingangsqualifikation der Komponente
  • 02Validierter Bestückungsprozess und aktualisierte Arbeitsanweisungen
  • 03Angepasster End-of-Line-Test
  • 04Rückverfolgbarkeit über Hardware Revision H4

MANUFACTURING READY ≠ PRODUCT RELEASE READY

23

Design Release und Manufacturing Release bleiben getrennt

DESIGN DEFINED

≠ DESIGN VERIFIED

≠ PRODUCTION PROCESS READY

≠ PRODUCT RELEASED

24

Eine Deviation ist kein Ersatz für einen bestandenen Nachweis

  • 01Betroffene Requirement Coverage und Konfiguration
  • 02Scope, Auswirkung und Mitigation
  • 03Gültigkeit, Conditions und Monitoring
  • 04Zuständige Authority und Change Trigger

REQUIREMENT SATISFIED

≠ DEVIATION ACCEPTED

≠ CONDITIONAL RELEASE

25

Der Service Scope besitzt eigene Anforderungen

  • 01Ist H4 ein zulässiger Ersatzstand für jede Variante?
  • 02Welche Firmware gehört zu welcher Hardware Revision?
  • 03Sind H3 und H4 service-seitig kompatibel?
  • 04Erkennt das Service Tool die Baseline?
  • 05Ist Cross-Revision Substitution zulässig?

FACTORY EVIDENCE ≠ AUTOMATIC SERVICE-SCOPE EVIDENCE

26

Wirtschaftlicher Zeitdruck gehört in den State, aber nicht in die Evidence

Bauteilabkündigung, begrenzter H3-Bestand und Kundenlieferpläne sind für die Entscheidung relevant. Sie belegen nicht, dass die S4-45-Coverage technisch ausreicht.

DELIVERY PRESSURE ≠ VERIFICATION EVIDENCE

27

Alternatives gehören zur Release-Entscheidung

Alternative

A0 — No Release

Bedeutung

Kein H4-Release unter dem aktuellen State

Alternative

A1 — Resolve v1

Bedeutung

Fehlende S4-45-Coverage schließen

Alternative

A2 — Variant-Restricted Release

Bedeutung

H4 nur für S4-08 und S4-22

Alternative

A3 — Delayed Family Release

Bedeutung

Gesamten H4-Release verschieben

Alternative

A4 — Baseline Split

Bedeutung

S4-08/S4-22 auf H4; S4-45 bleibt auf H3

ALTERNATIVE ≠ RECOMMENDATION

28

Authority ist selbst ein State

Das Product Release Board ist identifiziert, hat die v1-Entscheidung aber nicht ausgeübt. Eine Abstimmung allein kann den offenen Coverage State nicht beseitigen.

RELEASE AUTHORITY IDENTIFIED ≠ RELEASE AUTHORITY EXERCISED

29

Decision Space v1 als vollständiger State

Dimension

Decision / Product / Baseline

State

RESOLVED

Dimension

Hardware H4 / Firmware 4.8.0

State

BOUND

Dimension

S4-08 Verification

State

COMPLETE

Dimension

S4-22 Verification

State

COMPLETE

Dimension

S4-45 Nominal Verification

State

COMPLETE

Dimension

S4-45 Combined Worst-Case Verification

State

OPEN

Dimension

Evidence Inheritance

State

CONFLICTING

Dimension

Full-Family Service Scope

State

PARTIAL / OPEN

Dimension

Release Authority

State

IDENTIFIED / NOT EXERCISED

Dimension

Full-Family Finality

State

NOT AVAILABLE

Die Nachweise für S4-08 und S4-22 tragen diese Konfigurationen. Sie schließen nicht automatisch die konfigurationsspezifische Nachweislücke von S4-45 und damit auch nicht den geplanten Full-Family Release.

Vorgeschlagene Release-Konfiguration

Hardware H4 + Firmware 4.8.0

Full-Family-Scope · S4-08 / S4-22 / S4-45

S4-08

Functional
PASS
Thermal
PASS
Single-Fault
PASS
Combined Worst-Case
PASS

Coverage: COMPLETE

S4-22

Functional
PASS
Thermal
PASS
Single-Fault
PASS
Combined Worst-Case
PASS

Coverage: COMPLETE

S4-45

Functional
PASS
Thermal
PARTIAL
Single-Fault
PARTIAL
Combined Worst-Case
NOT COMPLETED

Coverage: INCOMPLETE

Geplanter Full-Family Release v1

H4 / Firmware 4.8.0 · S4-08 / S4-22 / S4-45

NOT FINALISABLE

III / WARUM v1 NICHT SCHLIESSEN KANN

Der Blocker ist nicht unvollständige Dokumentation.

30

Der zentrale Blocker

S4-45 SAFETY-FUNCTION VERIFICATION COVERAGE — NOT SUFFICIENTLY BOUND TO THE PROPOSED RELEASE CONFIGURATION

H4 + FIRMWARE 4.8.0 VERÄNDERT DIAGNOSTIC BEHAVIOUR

↓

S4-45 COMBINED TEST — NOT COMPLETED

↓

EVIDENCE INHERITANCE — CONFLICTING

↓

S4-45 SAFETY COVERAGE — OPEN

↓

FULL-FAMILY RELEASE — NOT SUFFICIENTLY SUPPORTED

↓

DECISION SPACE v1 — NOT FINALISABLE

31

Warum unvollständige Dokumentation zu grob wäre

Dokumentation, Identitäten, Requirements und Manufacturing State sind weitgehend resolved. Der Blocker ist konfigurationsspezifische Verification Coverage für einen erforderlichen Teil des vorgeschlagenen Release Scope.

32

Warum fehlendes Quality Approval ebenfalls falsch wäre

Quality kann Change Control, Traceability, Abweichungen und QMS-Gates prüfen. Ohne entsprechendes Mandat kann es die fachliche Safety Coverage für S4-45 nicht selbst erzeugen.

33

Warum S4-45 nicht als failed dargestellt werden darf

S4-45 — REQUIRED COVERAGE OPEN

UNKNOWN ≠ FAILED

NOT VERIFIED ≠ PROVEN UNSAFE

34

Warum bestandene Tests anderer Varianten nicht automatisch genügen

S4-08 und S4-22 können gemeinsame Designmerkmale und Teile einer Äquivalenzbegründung tragen. Sie decken nicht automatisch höchste thermische Belastung, S4-45-Layout, Kühlung und kombinierten Worst-Case-State ab.

TEST PASSED ≠ ALL PRODUCT VARIANTS COVERED

35

Warum eine Sonderfreigabe den Blocker nicht automatisch löst

Eine Deviation oder Sonderfreigabe benötigt bekannte Auswirkung, zuständige Authority, definierten Scope, Conditions, Gültigkeit und Change Trigger. Sie kann einen technisch nicht ausreichend bestimmten State nicht ersetzen.

DEVIATION PROCESS ≠ SUBSTITUTE FOR UNKNOWN TECHNICAL STATE

36

Wirtschaftliche Folgen verändern den Blocker nicht

Lieferverzögerungen, Kundenbeeinträchtigungen, Kosten und knappe H3-Bestände gehören zur Entscheidung. Sie schließen die Full-Family-Coverage nicht.

37

Was SEAL an dieser Stelle nicht sagt

  • 01S4-45 ist unsicher oder Firmware 4.8.0 ist fehlerhaft.
  • 02Der Hardwarewechsel ist unzulässig.
  • 03IEC 61800-5-2 ist nicht erfüllt.
  • 04Das Produkt darf rechtlich nicht bereitgestellt werden.
  • 05Technische Äquivalenz ist unmöglich.

Der vollständige v1-Release-Scope bildet noch keinen ausreichend bestimmten, finalisierbaren Decision State.

IV / DEN RELEASE SPACE AUFLÖSEN ODER VERÄNDERN

Ein blockierter Full-Family Release kann in seinem Scope geschlossen oder als andere Release-Entscheidung modelliert werden.

39

Path A: Resolve Current Release Space

Path A hält Hardware H4, Firmware 4.8.0, alle drei Varianten, den EU-/EEA-Scope, Neuproduktion und den vorgesehenen Service Scope unverändert.

Was muss real erfüllt werden, damit genau dieser Full-Family Release erneut beurteilt werden kann?

40

Path A: fehlende Verification Evidence

  • 01High-Temperature Verification und definierte Single-Fault-Injection
  • 02Worst-Case-Reaction-Time-Messung
  • 03Diagnoseverhalten unter kombinierter Belastung
  • 04Vollständiger Testreport gebunden an H4 / 4.8.0
  • 05Dokumentierter Aufbau und nachvollziehbare Bedingungen

41

Path A: Engineering- und Safety-State

  • 01Variantenspezifische Thermal Analysis
  • 02Aktualisierte Hardware-/Firmware-Interaction Analysis
  • 03Formale Äquivalenzanalyse
  • 04Aktualisiertes Safety Assessment und explizite Product-Safety-Position

FORMAL EQUIVALENCE ASSESSMENT ≠ INFORMAL ENGINEERING EXPECTATION

42

Path A: Quality und Product Compliance

Quality muss erkennen, welche Requirements betroffen sind, welche Evidence sie trägt, welche Coverage offen bleibt und ob eine Deviation ausreichend bestimmt ist. Product Compliance beurteilt den konkreten Produkt-, Markt- und Release Scope.

43

Path A besitzt kein gewünschtes Ergebnis

Outcome

A1

Bedeutung

S4-45-Evidence trägt v1

Outcome

A2

Bedeutung

Test zeigt materiellen Deficit; v1 bleibt blockiert

Outcome

A3

Bedeutung

Autorisierte Äquivalenz trägt Inheritance

Outcome

A4

Bedeutung

Current Space kann nicht rechtzeitig schließen

Outcome

A5

Bedeutung

Kein recoverable Current Space

44

Path B: Remodel the Release Decision Space

Welche andere Release-Entscheidung wird durch die tatsächlich vorliegende Evidence getragen?

Path B fragt nicht, wie S4-45 trotz offener Coverage freigegeben werden kann. Es fragt, wie sich der Release Scope ändern muss, damit eine andere geregelte Produktkonfiguration entsteht.

45

Drei illustrative Remodel Candidates

Candidate

B1 — Variant-Restricted Release

Veränderung

H4 / 4.8.0 nur für S4-08 und S4-22

Candidate

B2 — Delayed Family Release

Veränderung

Kein H4-Release vor Abschluss von S4-45

Candidate

B3 — Baseline-Split Release

Veränderung

S4-08/S4-22 wechseln auf H4; S4-45 bleibt auf H3

46

Der ausgewählte Remodel Candidate

Variante

S4-08

Candidate-Konfiguration

H4 / Firmware 4.8.0 / Neuproduktion

Variante

S4-22

Candidate-Konfiguration

H4 / Firmware 4.8.0 / Neuproduktion

Variante

S4-45

Candidate-Konfiguration

H3 / Firmware 4.7.2 / kontrollierter Restbestand / kein H4-Release

  • 01Field Firmware Update ausgeschlossen
  • 02Cross-Baseline-Service-Substitution ausgeschlossen
  • 03Ungeprüfte Mischkonfigurationen ausgeschlossen

47

Der Candidate verändert die eigentliche Entscheidung

v1 fragt, ob die gesamte Familie auf H4 / 4.8.0 wechseln darf. Der Candidate fragt, ob nur S4-08 und S4-22 wechseln dürfen, während S4-45 auf der bisherigen Baseline bleibt.

RESTRICTED RELEASE ≠ FULL RELEASE WITH A FOOTNOTE

48

Der Baseline Split erzeugt einen neuen Configuration State

S4-08 / S4-22 → H4 / FIRMWARE 4.8.0

S4-45 → H3 / FIRMWARE 4.7.2

  • 01Falsche Variant Effectivity
  • 02Unbeabsichtigter H4-Einbau in S4-45
  • 03Falsche Firmwarebindung
  • 04Cross-Baseline-Service-Substitution
  • 05Vermischung in Lager oder Produktion

49

Neue Configuration-Management-Anforderungen

  • 01Eindeutige H3-/H4-Revisionsidentität
  • 02Variantenspezifische Effectivity und eindeutige Part Numbers
  • 03Explizite Firmwarezuordnung
  • 04Konsistente PLM- und ERP-Stände
  • 05Versionierte Manufacturing Instructions und S4-45-Successor-Conditions

50

Neue Manufacturing Controls

  • 01Getrennte Materialsteuerung
  • 02Variantenspezifische Arbeitsanweisungen
  • 03H4-Sperre für S4-45
  • 04Baselinebezogene End-of-Line-Tests
  • 05Seriennummern- und Revisionstraceability
  • 06Stop Trigger bei Configuration Drift

SCOPE RESTRICTED IN A DOCUMENT ≠ SCOPE CONTROLLED IN PRODUCTION

51

Neue Service Controls

  • 01Compatibility Matrix und Ersatzteilkennzeichnung
  • 02Service-Tool-Erkennung
  • 03Verbot von Cross-Baseline-Substitution
  • 04Klare H3-/H4-Ersatzregeln
  • 05Field Update bleibt ausgeschlossen

EIN FACTORY RELEASE KANN NICHT STILL EINEN SERVICE RELEASE ERZEUGEN

52

Externe Hard Constraints bleiben erhalten

Ein engerer Scope kann verändern, welche Konfiguration betrachtet und welche Evidence benötigt wird. Er darf keine anwendbaren Safety Requirements entfernen, die rechtliche Klassifikation ersetzen, Konformitätsanforderungen umgehen oder Product-Compliance-Authority übernehmen.

RELEASE-SPACE REMODEL ≠ REGULATORY WAIVER

Wenn der vorgeschlagene Release Scope breiter ist als die vorhandene Evidence, kann SIMULATION fehlende Coverage oder eine andere Release-Konfiguration untersuchen. Der Baseline-Split Candidate bleibt Exploration, bis er materialisiert ist und BRIDGE durchläuft.

DECISION SPACE v1

Full-Family Release · H4 / 4.8.0 · S4-08 / S4-22 / S4-45

BLOCKER / PR-01

S4-45-konfigurationsspezifische Verification Coverage nicht ausreichend gebunden

SIMULATION

01 / Current Release Space auflösen

  • S4-45 Combined Test
  • Thermal- und Interaction Analysis
  • Equivalence- und Safety Assessment

02 / Release Space remodeln

  • Variant-Restricted Release
  • Delayed Family Release
  • Baseline-Split Release — zur weiteren Untersuchung ausgewählt

SPACE REMODEL CANDIDATE

Baseline-Split / Variant-Restricted Factory Release

S4-08 und S4-22 → H4 / 4.8.0 · S4-45 → H3 / 4.7.2 · Field Update ausgeschlossen · Cross-Baseline Service ausgeschlossen

Configuration · Manufacturing · Service · Authority materialisieren

Historischer State bleibt erhalten

v1 · Full-Family H4

NOT FINALISABLE

BRIDGE

Classification · Configuration Identity · Scope Delta · Requirements · Evidence Inheritance · Controls · Readiness · Authority · Blocker

DECISION SPACE v2

Baseline-Split / Variant-Restricted Factory Release

S4-08 und S4-22 an H4 / 4.8.0 gebunden · S4-45 an H3 / 4.7.2 gebunden · Service baselinegebunden · Release Authority exercised

S4-45 H4 VERIFICATION — OPEN

Außerhalb des v2-Scope · nicht blockierend für v2 · erforderlich für einen künftigen S4-45-H4-Successor-Release

SEAL CHECK

Sind alle erforderlichen States für diesen Factory Release Space aufgelöst?

ADMISSIBLE OUTCOME

Gebundener Product Release Decision State

LEGITIMATE OFF-RAMP

NO SEAL — erforderlicher v2-State bleibt offen

V / VOM FULL-FAMILY v1 ZUM BASELINE-SPLIT v2

Eine veränderte Varianten- und Baselinekonfiguration benötigt einen eigenen vollständigen Decision State.

53

v1 bleibt historisch erhalten

DECISION SPACE v1

H4 + FIRMWARE 4.8.0

S4-08 / S4-22 / S4-45

S4-45 COVERAGE NOT SUFFICIENTLY BOUND

NOT FINALISABLE

Ein später tragfähiger v2-State macht den ursprünglichen Full-Family Release nicht rückwirkend freigabefähig.

54

Der Remodel Candidate ist noch keine Produktfreigabe

  • 01Noch existiert keine neue PLM Effectivity.
  • 02Noch existieren keine neuen ERP- und Manufacturing Controls.
  • 03Noch existiert keine gebundene Service Compatibility.
  • 04Noch existiert kein Product-Compliance-Assessment oder Release-Authority-Event.

SPACE REMODEL CANDIDATE

≠ APPROVED PRODUCT CONFIGURATION

≠ PRODUCT RELEASE

≠ GOVERNED DECISION SPACE v2

55

v2 muss materialisiert werden

  • 01S4-08 und S4-22 an H4 / 4.8.0 binden.
  • 02S4-45 an H3 / 4.7.2 binden.
  • 03Part Numbers und Revisionen trennen.
  • 04Falsche Materialien und H4-Einbau in S4-45 verhindern.
  • 05End-of-Line, Ersatzteile, Field-Ausschluss und Dokumentation binden.
  • 06Authority für genau diesen Split Release ausüben.

56

Decision Space v2

Dimension

S4-08

v2

H4 / Firmware 4.8.0

Dimension

S4-22

v2

H4 / Firmware 4.8.0

Dimension

S4-45

v2

H3 / Firmware 4.7.2

Dimension

H4 Variant Scope

v2

S4-08 / S4-22 ONLY

Dimension

Release Mode

v2

REGULÄRE NEUPRODUKTION

Dimension

Service Scope

v2

BASELINE-BOUND

Dimension

Cross-Revision Substitution

v2

AUSGESCHLOSSEN

Dimension

Field Firmware Update

v2

AUSGESCHLOSSEN

Dimension

S4-45 H4 Release

v2

EIGENER SPÄTERER DECISION SPACE

57

v1 und v2 sind verschiedene Entscheidungen

Dimension

H4 Scope

v1

Alle drei Varianten

v2

Nur S4-08 / S4-22

Dimension

S4-45

v1

H4 / 4.8.0 vorgesehen

v2

H3 / 4.7.2 bleibt aktiv

Dimension

Production

v1

Eine neue Familienbaseline

v2

Kontrollierter Baseline Split

Dimension

Service

v1

Familienweiter H4-Scope

v2

Baselinegebunden

Dimension

Authority

v1

Full-Family Release

v2

Neue Split-Release-Freigabe

v2 ist nicht der ursprüngliche Full-Family Release mit einer Ausnahme. Es ist eine andere Configuration- und Release-Entscheidung.

58

Evidence darf übernommen werden, aber nicht blind

Weiterhin relevant für S4-08 und S4-22

  • 01Vollständige H4-/4.8.0-Verification
  • 02Fault Injection und Thermal Tests
  • 03STO-/SS1-Verification und Firmware Regression
  • 04Manufacturing Validation

Nicht automatisch übernehmbar

  • 01Familienweite H4-Aussagen
  • 02S4-45-H4-Evidence
  • 03Field-Update- und Cross-Revision-Service-Evidence
  • 04Annahmen einer einheitlichen neuen Baseline

59

Die Unsicherheit verändert sich

v1 fragt, ob S4-45 H4 / 4.8.0 durch Family Evidence getragen ist. v2 fragt, ob zwei aktive Baselines in Configuration Management, Manufacturing und Service zuverlässig getrennt werden können.

v2 besitzt einen engeren Release Scope mit einem anderen Control State.

60

BRIDGE prüft den Übergang

  • 01Decision Classification und Configuration Identity
  • 02Version Separation und Scope Delta
  • 03Requirement Delta und Evidence Inheritance
  • 04Offener S4-45-State und Configuration Control
  • 05Manufacturing- und Service-Readiness
  • 06Risk Delta, Conditions, Product Compliance und Authority
  • 07v1 Blocker Integrity und neue v2-Blocker

Es gibt keinen direkten Pfad: SIMULATION → SEAL.

61

Ein möglicher v2-State

Dimension

S4-08 Configuration

State

H4 / 4.8.0 — BOUND

Dimension

S4-22 Configuration

State

H4 / 4.8.0 — BOUND

Dimension

S4-45 Configuration

State

H3 / 4.7.2 — BOUND

Dimension

S4-45 H4 Verification

State

OPEN / OUTSIDE v2 SCOPE

Dimension

Configuration Controls

State

BOUND

Dimension

Manufacturing Readiness

State

BOUND

Dimension

Service Compatibility

State

BOUND

Dimension

Release Authority

State

EXERCISED

Dimension

Blocking v2 Objections

State

NONE

Dimension

Finality

State

ELIGIBLE FOR SEAL REVIEW

ELIGIBLE FOR SEAL REVIEW ≠ SEALED

62

Ein offener State ist nicht in jedem Decision Space ein Blocker

S4-45 H4 ist Teil von v1 und blockiert ihn. In v2 liegt es ausdrücklich außerhalb des Scope. Der offene State bleibt sichtbar und ist für einen künftigen S4-45-H4-Successor-Release erforderlich.

OPEN STATE

≠

BLOCKER IN EVERY DECISION SPACE

63

Factory Release bleibt von Field Update und Service getrennt

FACTORY RELEASE DECISION

≠ FIELD UPDATE DECISION

≠ SERVICE SUBSTITUTION DECISION

Der mögliche v2-State gilt nur für die Neuproduktion von S4-08 und S4-22 in der gebundenen H4-/4.8.0-Konfiguration.

64

SEAL Eligibility für v2

DECISION IDENTITY — FIXED

PRODUCT CONFIGURATION — FIXED

HARDWARE / FIRMWARE BINDING — FIXED

VARIANT / MARKET / FACTORY / SERVICE SCOPE — BOUND

APPLICABLE REQUIREMENTS — RESOLVED

S4-08 / S4-22 VERIFICATION — COMPLETE

S4-45 H4 STATE — PRESERVED OUTSIDE v2

CONFIGURATION SEGREGATION — VERIFIED

MANUFACTURING / SERVICE READINESS — BOUND

RELEASE AUTHORITY — EXERCISED

BLOCKING v2 STATES — NONE

65

Was SEAL für den Product Release festhalten kann

SEAL kann Product Identity, Approved Baseline, Hardware und Firmware, Variant- und Market-Scope, Release Mode, Requirements, Impact Assessment, Risk- und Safety-State, Verification Coverage, Ausschlüsse, Configuration Controls, Manufacturing- und Service-Conditions, Authority und Change Trigger festhalten.

66

Was SEAL ausdrücklich nicht behauptet

  • 01Das Produkt ist technisch sicher oder rechtlich marktfähig.
  • 02IEC 61800-5-2 ist vollständig erfüllt oder das Produkt ist CE-konform.
  • 03S4-45 H4 ist sicher oder unsicher.
  • 04Jede denkbare Prüfung wurde durchgeführt.
  • 05Manufacturing kann keine Fehlkonfiguration erzeugen.
  • 06Eine Behörde oder Konformitätsbewertungsstelle hat das Produkt freigegeben.
  • 07Spätere Produkthaftung ist ausgeschlossen.

SEAL hält den damaligen governed Decision State fest. Es übernimmt nicht die technische, rechtliche oder wirtschaftliche Release-Entscheidung.

VI / SPÄTERE PRÜFUNG

Nach der Freigabe muss die Verbindung von Konfiguration, Nachweisen, Scope und Authority lesbar bleiben.

67

Vorhandene Systeme bewahren wichtige Teile der Wahrheit

System

PLM

Typischer autoritativer Ausschnitt

Product Structure und Revision

System

ALM

Typischer autoritativer Ausschnitt

Firmware Build und Softwareartefakte

System

Test Management

Typischer autoritativer Ausschnitt

Testfall und Testergebnis

System

QMS

Typischer autoritativer Ausschnitt

Change- und Deviation-State

System

ERP / MES

Typischer autoritativer Ausschnitt

Material, Effectivity und Production State

Beziehen sich ihre maßgeblichen States auf dieselbe Product Configuration, denselben Scope und denselben Entscheidungszeitpunkt?

68

Einzelne Records rekonstruieren den Release State nicht automatisch

  • 01Engineering Change und Stücklisten
  • 02Software Build und Test Reports
  • 03Safety Assessment und Deviation Records
  • 04Release Notes und Manufacturing Instructions
  • 05Board Approval und Service Documentation

Diese Unterlagen verbinden nicht automatisch, welche Version galt, welche Tests welche Variante abdeckten, welche Evidence übernommen wurde, warum v1 blockiert war, wie v2 materialisiert wurde und wer genau v2 freigab.

69

T0: Was galt bei der Freigabe?

  • 01Historische Baseline und vorgeschlagene Hardware-/Firmwarekombination
  • 02Varianten und betroffene Requirements in v1
  • 03Evidence für S4-08 und S4-22
  • 04Fehlende S4-45-Coverage und Äquivalenzannahmen
  • 05Fachliche Positionen und Grund der v1-Blockade
  • 06Candidate, Controls, Ausschlüsse und Authority für v2

Spätere Prüfung beginnt nach der Freigabe. Nachvollziehbarkeit muss während der Entscheidungsentstehung gesichert werden.

70

T1: Ein späterer Diagnoseevent

Zwölf Monate später meldet ein Maschinenbaukunde bei einem S4-22-Gerät einen Safety-Input-Diagnoseevent. Zunächst ist offen, ob Hardware, Firmware, Installation, Verdrahtung, thermische Bedingungen oder ein unabhängiger Field State beteiligt sind.

Welche konkrete Konfiguration wurde bei T0 freigegeben, welche Evidence deckte sie ab und welche Informationen entstanden erst nach der Freigabe?

71

Later Outcome ist nicht T0 Knowledge

Jahrelanger störungsfreier Betrieb würde v1 bei T0 nicht ausreichend getragen machen. Ein späterer Fehler würde die eingeschränkte v2-Freigabe bei T0 nicht automatisch unvertretbar machen.

LATER OUTCOME ≠ T0 KNOWLEDGE

72

Konkrete spätere Prüffragen

  • 01Welche Hardware-/Firmwarekonfiguration wurde freigegeben?
  • 02Welche Varianten waren enthalten, und war S4-45 ausdrücklich ausgeschlossen?
  • 03Welche Tests deckten S4-08 und S4-22 ab, und welche S4-45-Tests fehlten?
  • 04Warum konnte Evidence nicht automatisch auf S4-45 übertragen werden?
  • 05Wer besaß Authority über Evidence Inheritance und v2?
  • 06Wie wurden H3 und H4 in PLM, ERP, Manufacturing und Service getrennt?
  • 07Welche spätere Information war bei T0 nicht verfügbar?

Warum konnte der ursprünglich geplante Full-Family Release nicht finalisiert werden, wie wurde sein Scope verändert und welche Configuration, Evidence, Conditions und Authority trugen den späteren eingeschränkten Release?

Fragen zu späteren Lesern, Nachweisen und Offenlegungsgrenzen im Institutionellen Dialog vertiefen

73

Change Trigger nach einem möglichen v2-SEAL

Change Trigger

H4 für S4-45 vorgesehen

Mögliche Konsequenz

Neuer Successor Decision Space

Change Trigger

Firmware 4.8.0 für H3 vorgesehen

Mögliche Konsequenz

Neues Compatibility Assessment

Change Trigger

Cross-Baseline-Service vorgesehen

Mögliche Konsequenz

Eigener Service Release State

Change Trigger

Field Update vorgesehen

Mögliche Konsequenz

Eigener Field Update Decision Space

Change Trigger

Hardware, Firmware oder Variante ändern sich

Mögliche Konsequenz

Requirements und Verification neu prüfen

Change Trigger

Configuration Drift in ERP / PLM

Mögliche Konsequenz

Stop / Reassessment

Change Trigger

Neues Safety Finding

Mögliche Konsequenz

Impact Review

74

Ein bestehender Factory-Release-State ist keine Blankofreigabe

  • 01Neue Firmware oder Hardware
  • 02Neue Varianten, Märkte oder Produktionsstandorte
  • 03Neue Serviceverfahren oder Retrofit
  • 04Field Update oder Cross-Revision-Substitution
  • 05Spätere S4-45-H4-Freigabe

Jede materielle Änderung kann einen neuen Decision State erfordern.

75

Reale Authority bleibt außerhalb von Epistemis

  • 01Epistemis führt keine Safety Verification oder Product Validation durch.
  • 02Es qualifiziert keine Komponenten und bewertet Functional Safety nicht eigenständig.
  • 03Es interpretiert Produktrecht nicht und bestimmt nicht, ob eine Norm erfüllt ist.
  • 04Es akzeptiert keine technischen Deviations und erteilt keine Design-, Manufacturing- oder regulatorische Freigabe.
  • 05Es ersetzt weder Product Safety noch Quality oder Product Compliance.

Epistemis strukturiert und bewahrt den Product-, Requirement-, Evidence-, Condition- und Authority-State, auf dem die reale Release-Entscheidung beruhte.

76

Warum dieser Fall über PLM, QMS und Test Management hinausgeht

PLM zeigt Product Structure und Revision; ALM zeigt Firmware Build; Test Management zeigt Tests; QMS zeigt Changes und Deviations; ERP und MES zeigen Material- und Production State.

Epistemis fragt, welche Kombination aus Configuration, Requirements, Impact Assessment, Verification Coverage, Deviations, Manufacturing, Service und Authority die konkrete Release-Entscheidung bei T0 trug.

77

Der Epistemis-Mechanismus in vier Sätzen

  • 01Ein Blocker erklärt präzise, warum der vorgeschlagene Scope nicht finalisierbar ist.
  • 02SIMULATION untersucht fehlende Current-Space-Evidence oder einen anderen Release Scope.
  • 03BRIDGE prüft, welche Explorationsergebnisse in einen geregelten neuen State eingehen dürfen.
  • 04SEAL hält nur den gebundenen State fest, dessen definierte Voraussetzungen erfüllt sind.

Epistemis ist Decision-State-Infrastruktur für eine haftungsrelevante Product-Release-Entscheidung, kein Product-Safety-Recommendation-System.

QUELLEN / METHODE

Domain Reality, illustratives Szenario und Epistemis-Modellierung bleiben getrennt

Reale fachliche und institutionelle Grundlage

Das Dossier verwendet ISO 9001:2026 als sektorübergreifende QMS-Referenz, IEC 61800-5-2:2016 als technische Referenz für sicherheitsbezogene Antriebssysteme, den Blue Guide der Europäischen Kommission als nicht bindende Auslegungshilfe und die Verordnung (EU) 2023/1230 als zeitabhängige Maschinenrechtsreferenz. Keine dieser Quellen definiert die Epistemis-Konzepte Decision Space, SIMULATION, BRIDGE oder SEAL.

Primärquelle: ISO 9001:2026 — QualitätsmanagementsystemePrimärquelle: IEC 61800-5-2:2016 — Anforderungen an die funktionale SicherheitPrimärquelle: Europäische Kommission — Blue Guide 2022Primärquelle: Verordnung (EU) 2023/1230 über Maschinen

Illustratives Szenario

Norevia Motion Systems SE, Vektorion SafeDrive S4, alle Varianten, Leistungen, Revisionen, Firmwareversionen, EC-2741, Bauteilabkündigung, Bestände, Prüfungen, fehlende Coverage, Rollen, Termine, wirtschaftliche Folgen und der spätere Diagnoseevent sind vollständig fiktiv.

Epistemis-Modellierung

Decision Space, Decision State, v1/v2, Blocker, Current-Space Resolution, Release-Space Remodel, Space Remodel Candidate, Evidence Inheritance, BRIDGE, SEAL, T0/T1 und State Preservation sind Epistemis-Konzepte. Die Architektur hält Exploration, kontrollierte Überführung und möglichen verbindlichen Abschluss getrennt.

Welche Produktfreigabe müsste Ihre Organisation später versions- und scopespezifisch erklären können?

Ein Enterprise Pilot beginnt mit einer abgegrenzten Product-Release-Entscheidung und bestimmt Product Identity, Baseline, Konfiguration, Varianten, Requirements, Evidence Coverage, Abweichungen, Conditions, Release Authority, Blocker, zulässige Remodels, Change Trigger und spätere Leserfragen.

Diesen Product Release Decision Space im Enterprise Pilot besprechenWeitere Anwendungsfälle ansehen