Effectivity-Konfiguration

Unter dem Begriff Effectivity-Konfiguration werden sämtliche zeit-und produktionsabhängigen Datenbanksichten bezüglich Datum zeit-und Serien-Nr. zusammengefasst. Für die Datum- und Serien-Nr. Werte muss jeweils sorgfältig unterschieden werden, ob es sich um die gesetzte Effectivity-Regel handelt, die abgefragt werden soll (Betrach-tungs-Effectivity oder Effectivity View), oder ob es sich um eine ein-schränkende Effectivity-Definition in Form von Objektattributen handelt.

4.2.1. Zeitabhängige Datenbanksichten

Zunächst soll lediglich die Abfrage unterschiedlicher Sichten auf die Datenbank betrachtet werden (vgl. Bild B018obmZ). Angenommen, zum Zeitpunkt X wird die Datenbank abgefragt, so kann entweder lediglich der aktuelle Zustand oder aber ein anderes Datum zur Betrachtung gewählt werden. Wird der Betrachtungszeitpunkt in die Vergangenheit gelegt, dann werden die Veränderungen derjenigen Benutzertransaktionen unsichtbar, deren Ende erst nach dem Betrach-tungszeitpunkt liegt (T4 für Y2, T2 für Y1). Würde im Rahmen von T4 beispielsweise ein Bauteil 4711/A Flansch erzeugt, dann ist dieses zum Betrachtungszeitpunkt X = Y3 selbstverständlich sichtbar, zum Zeit-punkt Y2 dagegen jedoch noch nicht. Abfragen in die Zukunft (Y4) können natürlich das Ende von aktuell laufenden Transaktionen (T5) sowie deren Ergebnis nicht vorhersehen. Zweckmässig sind Abfragen in die Zukunft daher nur, um gegebenenfalls bestehende Effectivity-Einschränkungen auswerten zu können.

Bild (B018obmZ) Abfragesichten auf die PLM-Datenbank

4.2.2. Zeitabhängige Datenbanksichten auf Effectivity-Definitionen

Unter einer Effectivity-Definition versteht man eine Einschränkung der Gültigkeit bzw. Verwendbarkeit freigegebener Objekte (für Start und/

oder Ende) vorwiegend in der Produktionssteuerung. Die hauptsächli-che Zielsetzung besteht darin, ein in der Konstruktion zum Zeitpunkt X freigegebenes Objekt für die Fertigung erst zu einem späteren Zeit-punkt (X+∆t) einzuführen. Neben der Einschränkung des Start-Datums kann jedoch ebenso ein Ende-Datum, eine Start Serien-Nr.

oder eine Ende Serien-Nr. sowie beliebige Kombinationen derselben angegeben werden. Da eine Effectivity-Definition immer nur zur Ein-schränkung dienen kann, müssen angegebene Start und Ende Daten sinnvollerweise jeweils nach dem Freigabezeitpunkt liegen. Weiterhin sind natürlich nur Ende-Restriktionen sinnvoll, die nach einer Start-Restriktion liegen (Ende-Datum nach Start-Datum, Ende Serien-Nr.

grösser als Start Serien-Nr.) sowie lediglich positive Serien-Nr. Werte grösser 0.

Bild (B019obmZ) Effectivity-Konzept Benutzertransaktionen: über Zustand zum Zeitpunkt Y

Y 1 Y 2 X = Y3 Y 1

Das Effectivity-Konzept findet in folgenden Bereichen Anwendung:

• Gleichzeitige Einführung verschiedener Objekte in eine Pro-duktstruktur (Start Datum)

• Verzögerte bzw. kontrollierte Einsteuerung von entwicklungs-seitig bereits freigegebenen Objekten in den Produktionsablauf (Start Datum)

• Kontrollierte Aussteuerung von Objekten aus dem Produktions-ablauf aufgrund z.B. veränderter Sicherheitsbestimmungen, Verfalldaten usw. (Ende Datum)

• Losabhängige Einsteuerung von entwicklungsseitig bereits frei-gegebenen Objekten in den Produktionsablauf, wie z.B. bei Prototypserien (Start Serien-Nr.)

• Losabhängige Aussteuerung von Objekten aus dem Produkti-onsablauf, z.B. aus Lagerbestandsgründen oder Lieferanten-wechsel (Ende Serien-Nr.)

• Kontrollierte Zuordnung auftragsspezifischer Objekte zu einzel-nen Produktionslosen (Start Serien-Nr., Ende Serien-Nr. ggf.

kombiniert mit Start Datum und/oder Ende Datum Ferner ist zu beachten:

• Das Konzept ist nur sinnvoll für freigegegebene Objekte bzw.

Zeiträume nach einer Freigabe.

• Das Schreibrecht auf Effectivity-Informationen muss auch nach der Freigabe vorhanden sein und erfordert daher einen speziel-len Autorisierungsmechanismus (z.B. über Rollenkonzept).

Sobald für ein Objekt eine Effectivity-Definition besteht, beeinflusst dies dessen Konfiguration in Abhängigkeit des Betrachtungs-Datums und/oder dessen Serien-Nr.. Verdeutlicht sei dies am Beispiel des Motors 0817, dessen neue Revision B mit einer Effectivity-Definition freigegeben wird, wodurch deren Gültigkeitsbereich eingeschränkt wird (vgl. Bild B020obmZ für Datum-Effectivity sowie Bild B021obmZ für Serien-Nr.-Effectivity). Für den Fall der Definition einer Datum-Effectivity wird beispielsweise auch nach dem Freigabezeitpunkt auf eine Konfigurationsregel bezüglich Status und Datum die ältere A-Revision konfiguriert, falls das Betrachtungsdatum entweder vor einem Effectivity-Start oder nach einem Effectivity Ende Datum gesetzt wird. Falls bis zum Ende des definierten Gültigkeitsbereichs (Effectivity Ende) keine neue Revision C eingeführt oder aber das Effectivity Ende aufgehoben wird, wird automatisch wieder die Vor-gänger-Revision A konfiguriert. Die Effectivity Konfiguration mittels Serien-Nr. verhält sich diesbezüglich völlig äquivalent (vgl. Bild B020obmZ und Bild B021obmZ).

Bild (B020obmZ) Konfiguration mittels Effectivity (Datum)

Bild (B021obmZ) Konfiguration mittels Effectivity (Serien-Nr.)

Etwas komplizierter wird die Sachlage bei einer Kombination von Effectivity-Definitionen bezüglich Datum und Serien-Nr.. Da die Zusammenhänge von Serien-Nr. und Datum im allgemeinen nicht aus-reichend bekannt sind und zudem häufig geändert werden müssten, empfiehlt sich eine separate Betrachtung beider Effectivity-Kriterien anhand zweier Achsen (vgl. Bild B022obmZ). Der Gültigkeitsbereich bezüglich beider Kriterien lässt sich hierdurch als Fläche darstellen, die bei einer kombinierten Konfigurationsregel (bezüglich Status, Datum und Serien-Nr.) „getroffen“ werden muss, um eine Revision (hier:

0817/B Motor) zu konfigurieren. Je nach vorliegendem Informations-bedürfnis des Benutzers kann eine Abfragesicht auch nur bezüglich einem Effectivity-Kriterium formuliert werden (z.B. Status und

Serien-Gültigkeitsbereich Objekt 0817/B aufgrund Effectivity-Restriktion

Gültigkeitsbereich Objekt 0817/B falls keine Effectivity definiert wäre Freigabe

Gültigkeitsbereich Objekt 0817/B aufgrund Effectivity-Restriktion

Gültigkeitsbereich Objekt 0817/B falls keine Effectivity definiert wäre Freigabe

Nr. oder Status und Datum) wobei dann dieses allein für die Konfigu-ration evaluiert wird.

Bild (B022obmZ) Konfiguration mittels Effectivity (Datum kombiniert mit Serien-Nr.)

Bei den bisherigen Betrachtungen stand die Anwendung und Funktio-nalität der Effectivity-Konfiguration im Vordergrund, wobei lediglich eine beispielhafte Produktstruktur diskutiert wurde. Unter der Prä-misse einer Mehrfachverwendung von Objekten und Effectivity-Defini-tionen in neueren Produktstrukturen soll nunmehr die Auswirkung der Effectivity auf verschiedene Verwendungen interessieren. Entschei-dend hierfür ist, wie bzw. an welcher Stelle die Effectivity-Definition erfolgt (vgl. Bild B023obmZ):

Zeitt Freigabe Motor0817/B mitEffectivity! Ausgangslage 0815/A Auto 0816/A Chassis0817/A Motor

Resultat 0815/A Auto 0816/A Chassis0817/A Motor

Status + Datum ri Se -Nr en

.

Prototypphase Nul

lse

eri

Status+ Datum+ Serien-Nr. Resultat 0815/A Auto 0816/A Chassis0817/A Motor

Status+ Datum+ Serien-Nr.

Status + Serien-Nr. Resultat 0815/A Auto 0816/A Chassis0817/B Motor

Resultat 0815/A Auto 0816/A Chassis0817/B Motor

Effectivity StartDatum Effectivity EndeDatum

EffectivityStartSerien-Nr.

EffectivityEndeSerien-Nr.

Pr odu ktion tar ss

t

• für die Objekt-Revision(Revision Effectivity) oder

• für die Strukturbeziehung(Occurrence Effectivity).

Bild (B023obmZ) Methoden zur Definition von Effectivity

Falls die Effectivity für die Objekt-Revision definiert wird, erhält sie dadurch globalen Charakter und somit Gültigkeit für sämtliche Ver-wendungen, d.h. Oberbaugruppen. Im linken Beispiel in B023obmZ beeinflusst das Effectivity-Datum infolgedessen sowohl das Auto 0815/A als auch das Sportauto 1000/A.

Demgegenüber hat eine Effectivity-Definition für eine Strukturbe-ziehung nur lokalen Charakter und somit nur Gültigkeit für die betref-fende Oberbaugruppe. Das rechte Beispiel in Bild Bild B023obmZ zeigt, dass die Occurrence-Effectivity bezüglich dem Auto 0815/A kei-nerlei Einfluss auf die Verwendung des neuen Chassis 0900/A im Sportauto 1000/A hat.

Leistungsfähige PLM-Systeme unterstützen beide Methoden, so dass der Benutzer die jeweils bestgeeignete für seinen Anwendungs-fall auswählen kann. Aufgrund der besseren Übersichtlichkeit ist nach Möglichkeit - soweit es zweckmässig ist - die Revision-Effectivity zu bevorzugen. Nur in begründeten Ausnahmefällen (wo die Revision-Effectivity nicht mehr ausreicht), sollte die Occurrence-Revision-Effectivity ange-wendet werden, da diese schwieriger in der Handhabung ist, insbe-sondere im Zusammenhang mit Release-Prozeduren und CAx-Einbindungen.

Abschliessend zur Effectivity-Thematik sei darauf hingewiesen, dass dies eine Domäne von PPS-Systemen ist. Falls in einem Unterneh-men in Anlehnung an Bild B012obmZ ein PPS-System existiert sowie ggf. eine PLM/PPS-Kopplung realisiert ist, kommt die Effectivity erst im

+ Ü + +

Revision

RevisionEffectivityEffectivity

komplizierteste Problemfälle abbildbar anspruchsvoller in der Handhabung CAx -Einbindung schwieriger weniger übersichtlich in Release

Occurrence Effectivity Occurrence Effectivity

+ Übersichtlichkeit

+ einfache Anwendung in Release Prozeduren + einfache CAx-Einbindung

Revision

RevisionEffectivityEffectivity

+

PPS-System zu tragen. Innerhalb des PLM-Systems handelt es sich daher nur um eine sogenannte „geplante Effectivity“, die anschlies-send an ein PPS-System übergeben wird. Insgesamt wird aus den bis-lang diskutierten Konfigurationsmechanismen jedoch die um ein Vielfaches grössere Funktionalität von PLM-Produktstrukturen gegen-über herkömmlichen Stücklisten deutlich.

Eine spezielle Form der generischen Konfiguration stellt die Varian-tenbildung dar, der anwendungsseitig eine eigene Semantik zukommt, weshalb diese gesondert zu betrachten ist.

5. Variantenbildung

Die Variantenbildung ist ein sehr häufig eingesetztes Rationalisie-rungsmittel, wodurch eine grössere Flexibilität für verschiedene Kun-denbedürfnisse erreicht wird und infolge der verringerten Datenredundanz erhebliche Verbesserungen für den Änderungs-dienst, die Disposition und andere Produktionsaufgaben erzielt wer-den. Unter Varianten sind nach [[DIN199/2]] Objekte ähnlicher Form und/oder Funktion mit einem in der Regel hohen Anteil identischer Baugruppen oder Einzelteile zu verstehen. Anstatt für jede mögliche Variante eine vollständige Produktstruktur anzulegen, wird durch eine gemeinsame Variantenstruktur (Variantenstückliste) die gesamte Viel-falt eines sogenannten Produkttyps zusammenfassend beschrieben.

Eine Variante stellt hierbei eine konkrete Ausführung eines Produkt-typs dar. Demzufolge müssen bei der Variantenbildung zwei grundle-gende Aspekte unterschieden werden:

• Definition einer Variantenstruktur für einen Produkttyp (Definition sämtlicher möglicher Kombinationen),

• Ableiten einer konkreten Variantenausprägung

(Auswahlentscheidung bezüglich sämtlicher variabler Positio-nen).

Im Dokument Informationstechnologien im digitalen Produkt (Seite 138-145)