Mit den immer tiefer greifenden Integrationen von Systemen wird die erfolgreiche Verbindung von technischen Fähigkeiten und ihren wirtschaftlichen Pendants ein integraler Bestandteil erfolgreicher Projektabwicklungen im Anlagenbau. Moderne Unternehmen bedienen sich in diesem Zusammenhang des Konfigurationsmanagements (KM). Diese Managementmethode dient unter anderem zur Erfüllung verschiedener Qualitätsanforderungen [1]. In diesem Bereich er-hebt das Systems Engineering einen zumindest verwandten Anspruch. Die erfolgreiche Kombination dieser Methoden wird nachfolgend betrachtet. Dafür werden zunächst die Einzeldisziplinen für diesen Anwendungsfall charakterisiert. Die hieraus abgeleitete Hypothese wird im Anschluss vor dem Hintergrund der SysML-Fähigkeiten und der Anforderungen des KM geprüft.
Die DIN ISO 10007 ist Teil der Qualitätsmanagementnormen. Das KM ist dabei ein mögliches Verfahren, um die Anforderungen der ISO 9001 bezüglich der Rückverfolgbarkeit eines Produktes zu erfüllen. Sie beschreibt ferner die Anwendung des KM über den gesamten Lebenszyklus von Produkten. Dabei ist sie lediglich ein Leitfaden und damit nicht zur Zertifizierung von Organisationen vorgesehen [1].
KM beinhaltet die notwendigen Tätigkeiten, um die Lenkung und Leitung der Konfiguration eines betreffenden Produktes über den Lebenszyklus hinweg sicherzustellen. Dafür sind die Konfigurationsangaben in Bezug auf einzelne Konfigurationseinheiten (KE) maßgebend. Die Summe der Konfigurationsangaben zu einer Einheit bildet eine Konfiguration. Wird diese zu einem bestimmten Zeitpunkt fixiert, spricht man von einer Bezugskonfiguration (auch als Baseline bezeichnet). Diese kann im weiteren Verlauf des Produktlebens zu verschiedenen Zwecken herangezogen werden. Änderungen einer Konfiguration bedürfen zum einen einer strukturierten Freigabe durch eine entsprechend befähigte Organisationseinheit (Verfügungsstelle) und zum anderen einer strukturierten Dokumentation mit Hilfe von Änderungsanträgen (ÄA) und einer Buchführung [1].
Das KM hilft damit immer komplexer werdende Produkte erfassen und über verschiedene Lebensphasen steuern zu können.
Mit den ersten formalisierten Anwendungen des SE in den Bell Laboratories zu Beginn des 20. Jahrhunderts wurden zunächst vor allem technisch orientierte Projekte begleitet [2]. Aus den Ursprüngen in den 1930er Jahren haben sich zunächst militärische Standards (bspw. MIL-STD-499) gebildet. Im weiteren Verlauf der Zeit hat sich zuletzt die ISO 15288 als maßgebende Norm für das SE durchgesetzt [3]. Diese wurde kürzlich aktualisiert und ist als ISO 15288:2015 auf neuestem Stand [4].
Das SE verwendet zur Lösung von Problemen einen generischen Problemlösungszyklus. Dafür werden Systeme hinreichend erfasst, die Differenz zwischen Ist- und Soll-Zustand methodisch beschrieben und mit verschiedenen Lösungsansätzen gelöst. Dabei wird ein besonderes Augen-merk auf die Erfassung und Erfüllung von diversen Randbedingungen gelegt [5]. In diesem Zusammenhang werden neben den oben genannten Anforderungen auch die statische Systemarchitektur und das dynamische Systemverhalten erfasst. Vor allem dieses Verhalten generiert in einer formalen Sprache diverse Möglichkeiten zur Arbeitserleichterung und Qualitätssicherung in großen Projekten [6].
Aus den oben dargestellten Rahmenbedingungen wird die nachfolgende Hypothese abgeleitet: Das Verhalten komplexer Produkte kann mit formalen Sprachen entwickelt und dokumentiert werden. Die Konfigurationserfassung im Sinne des KM ist dabei noch nicht Bestandteil dieser Sprachen.
Methodisch wird die Lösungsfindung hierbei durch ein Lastenheft geführt. Es wird ein Lastenheft für eine etwaige Erweiterung von Standards, die zur formalisierten Beschreibung von Systemen verwendet werden, erarbeitet.
Zur formalen Beschreibung eines Systems im Kontext des SE werden diverse Sprachen verwendet. Diese sind beispielsweise:
Die Methoden eignen sich jeweils für unterschiedliche Anwendungszwecke und sind damit im gegebenen Fall auszuwählen [6]. Einige der genannten Sprachen wie beispielsweise die Specification and Description Language oder Petri-Netze sind jeweils sehr spezifisch geprägt. Sie wurden in verschiedenen Domänen entwickelt und haben dort ein hohes Maß an Integration in die Bedürfnisse der jeweiligen Domäne [6].
Um an dieser Stelle nicht nur eine fachliche Domäne betrachten zu können und einen universellen Ansatz zu verfolgen, werden lediglich die generischen Sprachen betrachtet. Die nachfolgende Betrachtung bezieht sich daher auf die SysML und damit auch die in Teilen enthaltene Unified Modeling Language (UML).
Es werden nun die Eckpunkte der Systembeschreibung in SysML dargestellt (Kapitel 3).1 Im Anschluss werden die Bedarfe des KM an die Beschreibung einer Konfiguration und einer KE zusammengefasst. Aus diesem Delta zwischen SysML-Fähigkeiten und den KM-Anforderungen, kann dann das Lastenheft abgeleitet werden (Kapitel 4), sodass ein Lösungsansatz ausgearbeitet (Kapitel 5) und bewertet (Kapitel 6) werden kann.
Die formalisierte Beschreibung von Systemen mit der Hilfe von SysML basiert auf der Modellierungssprache UML. In der Entstehung von SysML wurden dabei viele Aspekte und Prinzipien aus der UML übernommen. Für den Anwendungsfall der Systemmodellierung wurden einige neue Aspekte hinzugefügt und einige Bestandteile der UML weggelassen. SysML verfolgt bei der Modellierung von Systemen einige Grundsätze, die für die nachfolgende Lösungssynthese erhalten bleiben müssen und sollen:
Die Erweiterung der UML für die Verwendung von SysML wird nachfolgend näher erläutert.
Die interdisziplinäre Arbeit an einem Systemmodell auf Basis von SysML erfordert, dass die jeweiligen Domänen passende Ansichten des zugrundeliegenden Modells zur Verfügung ha-ben. Dafür werden in SysML verschiedene Diagrammarten definiert, wie sie nachfolgend in Abbildung 1 dargestellt werden. Auf einige Diagrammarten wird im weiteren Verlauf noch detaillierter eingegangen.
In den Diagrammen werden die Elemente des Modells instanziiert. Das heißt, dass ein Modellelement in einer beliebigen Anzahl von Diagrammen verwendet werden kann und dabei nicht den Bezug zum Quellelement im Modell verliert. Damit werden Änderungen am Systemelement in alle referenzierte Diagramme umgehend eingebracht.
Die Verknüpfung erlaubt es außerdem, die Darstellung der Instanz eines Elements in einem Diagramm anzupassen, ohne das Element selbst zu verändern. Konkret können beispielsweise Darstellungsformen in Form von Bildern, Symbolen oder Textblöcken verwendet werden. Die benötigte äußere Form ergibt sich dabei aus dem jeweiligen Diagramm und dem Anwendungsfall [8]. Je Diagrammart spezifiziert SysML die Art der designierten Systemelemente. Allerdings ist eine Berücksichtigung der übrigen Systemelemente zulässig [7]. Abschließend wird der Zusammenhang von Diagramm und Modell nachfolgend in Abbildung 2 dargestellt. Die Trennung von Modell und Diagramm bedingt im operativen Umgang, dass im Modell durchaus mehr Elemente enthalten sein können, als in der Summe der Sichten enthalten sind [6].
Seitens der Object Management Group (OMG) wird mit dem Profilmechanismus ein Verfahren beschrieben, das die Möglichkeit bietet, die standardisierte UML zu erweitern [6]. Durch dieses Verfahren im UML-Standard werden die Fähigkeiten der UML sehr umfassend erweiterbar. Der Anwendungsbereich der UML ist somit nicht nur der konkret definierte Teil der OMG-Spezifikation, sondern er umfasst darüber hinaus alle weiteren Anwendungsfälle, die sich über Erweiterungen des Anwenders realisieren lassen.
Um Anpassungen zu realisieren, werden Elemente des UML-Metamodells mit Hilfe von Stereotypen erweitert. Damit kann einem Element beispielsweise ein weiteres Attribut als Eigenschaft zugewiesen oder seine äußere Form modifiziert werden [9]. Auf dieser Basis lassen sich vielfältige Anpassungen realisieren. Beispielsweise kann eine UML-Erweiterung erzeugt wer-den, um Petri-Netze abbilden zu können [6].
Mit diesem Verfahren ist auch die SysML als Profil der UML spezifiziert worden [7]. Die Stereotypen innerhalb des SysML-Profils werden nachfolgend in Abbildung 3 dargestellt.
Mit den Anpassungen der Sprache für einen spezifischen Zweck wird die Standardisierung demnach nicht verlassen. Die OMG ermöglicht es somit, die Sprache zu erweitern und trotzdem noch standardisierte Werkzeuge zu nutzen [6]. Infolgedessen müssen UML-Werkzeuge mit dem Profilmechanismus arbeiten können.
Um neben den Anforderungen der System Engineers auch die Informationsbedürfnisse der weiteren Stakeholder zu erfüllen, bietet SysML das Konzept der Views und Viewpoints. Dieses Konzept ist dabei konsistent zur ISO/IEC/IEEE 42010 [10]. In einem Viewpoint wird beschrieben, welche Informationen des Systemmodells für den Stakeholder relevant sind, der View setzt diese Anforderungen dann um. Je nach Anforderungen werden spezielle Informationen ausgeblendet oder beispielsweise in einer speziellen, äußeren Form dargestellt. Aus diesen Kriterien entsteht dann eine Sicht auf das Modell (View). Der entstehende View zeigt also eine besondere Sicht auf das Systemmodell. Dieses Verhalten lässt sich mit den oben genannten Diagrammen vergleichen. Daher wird der mittlere Teil in Abbildung 2 auch mit „Sicht/Diagramm“ beschrieben.
Im Viewpoint wird außerdem hinterlegt, in welcher Form der View aus dem Modell extrahiert wird. Um die Bedürfnisse der zugeordneten Stakeholder zu erfüllen, ist es zudem möglich, auf mehr als ein Modell zur View-Erzeugung zuzugreifen [7]. Der View selbst ist ein Modellelement. Für den Stakeholder wird, wie zuvor bereits erwähnt, ein Dokument erzeugt, das den View entsprechend abbildet. Dieses erzeugte Dokument ist nicht per se Teil des Modells, sondern wird lediglich durch den View repräsentiert [7].
Während der Viewpoint mit jedem Aufruf einen aktuellen Zustand (unter Anwendung der Anforderungen) zeigt, wird mit dem extrahierten Artefakt ein Schnappschuss erstellt. Klassische Beispiele dieser Artefakte sind PDF-Dokumente oder Foliensätze, die die entsprechenden Da-ten enthalten [7]. Im Gegensatz zu den oben beschriebenen Diagrammen sind die Inhalte der Viewpoints nicht fix beschrieben, sondern dienen der konkreten Ausprägung im spezifischen Einzelfall, um damit den Anforderungen eines Stakeholders und seiner spezifischen Informationsaufbereitung zu dienen [6].
Obwohl das generelle Konstrukt beschrieben wird, liegt auch mit der SysML 1.4 die finale Implementierung der View-Erzeugung außerhalb der Spezifikation. In der Vergangenheit ha-ben die verfügbaren Modellierungswerkzeuge ihre jeweils eigenen Umsetzungen gehabt [11].
Die strukturelle Systembeschreibung wird in SysML durch block-Elemente erzeugt. Blöcke werden als Erweiterung der UML-Class spezifiziert. Dabei werden die Definitionen der UML für SysML erweitert. Allerdings wurden auch einige Aspekte, wie beispielsweise sehr spezielle Beziehungstypen zu weiteren Elementen, entfernt. Diese Aspekte werden ausgeschlossen, um die SysML einfach zu halten [7].
Jeder Block für sich beschreibt eine Sammlung an Eigenschaften des zu spezifizierenden Systems. Damit können neben Hard- und Software auch Verhaltensmuster spezifiziert werden [7]. In der Systemmodellierung werden zuvor definierte Blöcke in den entsprechenden Diagram-men instanziiert (diese heißen dann properties). Die Definition der Blöcke erfolgt dabei im block definition diagram. Sie werden außerdem in einer gemeinsamen Bibliothek zur übergreifenden Nutzung bereitgestellt [6].
Der Block hat in SysML lediglich ein Attribut. Der boolesche Wert isEncapsulated gibt an, ob der Block als Blackbox betrachtet werden soll. Wird dieses Attribut mit WAHR beschrieben, werden weitere Details des Blocks nicht beschrieben [7]. Diese Blackbox kann beispielsweise verwendet werden, wenn die weitere Spezifizierung des Systems nicht relevant ist, da sie an Dritte vergeben wird oder das System off the shelf verfügbar ist.
Darüber hinaus wird bereits in der SysML-Spezifikation eine Vielzahl von Stereotypen für die Blöcke angegeben [7]. Da sie an dieser Stelle nicht von weiterer Relevanz sind, wird auf die Details nicht eingegangen. Das Prinzip der Instanziierung von Blöcken findet analog auch Anwendung für die Schnittstellen in SysML [6]. Die Schnittstellen werden als sogenannte ports definiert. Dabei können an diesen Schnittstellen verschiedenste Objekte ausgetauscht werden. Über unterschiedliche Arten von Ports können neben physikalischen Größen auch komplexe Informationen ausgetauscht werden [7]. Die Verschachtelungen von Flow Specifications machen diese komplexen Übertragungen möglich [6]. Für die weitere Unterstützung in der praktischen Anwendung werden in SysML SI-Einheiten implementiert. Dies stellt eine Erweiterung zu UML dar und wurde initial mit der SysML eingeführt [6].
Die Definition der generellen Fähigkeiten erfolgt also über Blockdefinition. Im Anschluss findet dann die spezifische Ausprägung über die Instanziierung der Blöcke statt. Dabei werden dann auch spezifische Größen eingepflegt, die zuvor in der Schnittstellendefinition angelegt wurden.
In der SysML können verschiedene Systemelemente zueinander in Beziehung gesetzt werden. Es können sowohl Beziehungen von Elementen gleichen Typs (bspw. zwischen Block-Elementen) als auch Beziehungen zwischen Elementen verschiedenen Typs erzeugt werden. Damit können die „unterschiedlich abstrakten Blickwinkel“ auf das Systemmodell verbunden werden [6]. So lässt sich beispielsweise darstellen, welche Anforderung mit welchem Testfall geprüft wird oder welche Komponente welche Anforderungen zu erfüllen hat. Für diese Beziehungen definiert SysML den Typ allocate. Mit dieser Beziehung wird von einem jeweils abstrakteren auf ein passendes, konkreteres Objekt referenziert [6]. Aus dieser Grundregel lassen sich bereits vielfältige Informationen abbilden.
Weitere Beziehungen sind jeweils innerhalb der einzelnen Elementtypen definiert. So werden beispielsweise für die oben beschriebenen Blöcke verschiedene Formen der association definiert [7]. Damit kann dann der strukturelle Aspekt des SE zwischen den Blöcken modelliert werden.
Sofern es für das Systemmodell notwendig ist, dass externe Dokumente im Modell angezogen werden müssen, steht der Stereotyp document für diesen Anwendungsfall zur Verfügung. Über eine trace-Beziehung kann ein Dokument dann auf ein beliebiges Modellelement bezogen wer-den. Über die properties können dem Artefakt weitere Eigenschaften zugewiesen werden. Das Stereotyp ist aus der UML2 übernommen [7]. Aus der dortigen Spezifikation geht außerdem hervor, dass ein Artefakt mit unterschiedliche Eigenschaften mehrfach instanziiert werden kann [9].
Innerhalb der SysML-Spezifikation wird ein Beispiel für das Erfassen von Konfigurationen gegeben. Dabei wird ein PKW in einige Komponenten aufgegliedert. Der eindeutigen Fahrzeugidentifikationsnummer werden dabei die Seriennummern der verbauten Komponenten zu-geordnet. Um die Konfiguration zu erfassen gibt es die Möglichkeit, einen context block zu erzeugen. Innerhalb dieses Blocks werden dann die Merkmale der spezifischen Konfiguration angegeben. Die Merkmalsausprägungen müssen innerhalb der zuvor festgelegten Definitionsbereiche liegen. Im gegebenen Beispiel kann es beispielsweise nur einen Motor geben, der je-doch je nach Konfiguration zwischen vier und acht Zylindern enthalten kann [7].
Je nach angewandter Norm werden etwas unterschiedliche Definitionen der Konfiguration bzw. auch der KE angeführt. Für die Betrachtung der Fähigkeiten im Zuge der Systembeschreibung mit SysML werden daher an dieser Stelle die signifikanten Eckpunkte der KM-Anforderungen betrachtet:
Aus den oben ausgearbeiteten Merkmalen der Systemmodellierung in SysML und der zusammengefassten Anforderungen des KM wird nun ein Abgleich durchgeführt. Dafür werden in Tabelle 1 die gelisteten Anforderungen der SysML-Spezifikation gegenübergestellt.
| Anforderung | Enthalten in SysML? | Erläuterung |
|---|---|---|
| Umfang der Konfiguration | Ja | Keine Vorgabe zur Tiefe der Modellierung. Prinzipiell ist eine hinreichend detaillierte Modellierung möglich. |
| Hierarchie der Systemelemente | Teilweise | Es werden Beziehungstypen definiert, die hierarchische Strukturen ermöglichen. Die An-wendung auf KE ist zunächst nicht vorgesehen. |
| Identifizierung | Nein | Eine systematisierte Identifizierung (ID o. ä.) ist nicht vorgesehen. Allerdings verfügen die Werkzeuge in der Praxis in Ansätzen über solche Mechanismen. |
| Dokumentensteuerung | Teilweise | Dokumente können über den document Stere-otyp abgebildet werden. Eine umfangreiche Steuerung ist nicht vorgesehen. |
| Dokumentengenerierung | Teilweise | Prinzipiell sind Dokumentengenerierungen möglich. Allerdings ist fraglich, ob KM-relevante Inhalte hinreichend abbildbar sind. |
| CMII-Baselining | Teilweise | Aus den Instanzen der Elemente in freigegebenen Diagrammen kann die aktuelle Konfiguration ermittelt werden. Praktische Anwendung nicht spezifiziert. |
| DIN ISO 10007-Baselining | Teilweise | Über ein kontextbezogenes Blockdiagramm kann eine Baseline festgehalten werden. Die Inhalte sind ggf. nicht hinreichend im Modell enthalten. |
| Freigabe- und Änderungsverfahren | Nein | Status und Sperrung von Änderungen sind für die Modellelemente nicht explizit vorgesehen. |
Die Versionierung von SysML-Modellen stellt sich praktisch als sehr schwierig dar. Zwar kann ein SysML-Modell (genau wie ein UML-Modell) abgespeichert werden, doch sind damit einige Probleme verknüpft [12].
Die OMG definiert für den Austausch von UML-Modellen die XML Metadata Interchange (XMI). Damit können die Modelle gespeichert und entsprechend adressiert werden [13]. Mit diesem Mechanismus kann allerdings nur ein gesamtes Modell betrachtet werden [12]. Im Hinblick auf den Anlagenbau mit seinen großen Teams und der parallelen Bearbeitung vieler Themengebiete erscheint diese Lösung daher als wenig tragbar. Die Versionierung müsste vielmehr auf Subsystem- oder sogar Blockebene geschehen. Im Zuge der Versionierung ist auch die Änderung der Systemelemente nicht hinreichend spezifiziert. Definierte Änderungsprozesse, wie sie beispielsweise mit einem ECP gesteuert wer-den können, werden im Anlagenbau benötigt [14]. Diese sind in SysML allerdings nicht vorhanden.
Für die Erweiterung/Anpassung der SysML werden nachfolgend Lösungen erarbeitet, die neben der Versionierung auch die Änderungsverfahren von SysML-Modellen betrachten.
Das erarbeitete Delta zwischen normierten SysML-Fähigkeiten und KM-Anforderungen wird nun in mögliche Lösungen überführt.
Die hinreichende Darstellung von Systemelementen für das KM kann potenziell über den Profilmechanismus realisiert werden. Die Elemente müssen als eindeutige KE bzw. als Konfiguration identifizierbar werden. Um die dafür notwendigen Eigenschaften zu etablieren, wird eine Erweiterung über den Profilmechanismus erzeugt. Das dafür notwendige Stereotyp definiert dann folgende, zusätzliche Eigenschaften:
Über einen entsprechenden Viewpoint werden die Informationen im Anschluss für den Stakeholder KM aufbereitet und in einem entsprechenden Dokument (als Artefakt) zur Verfügung gestellt. Nachfolgende Abbildung 3 zeigt eine schematische Darstellung dieser Lösung. Zur Selektion der relevanten Informationen wird als Selektionskriterium das oben genannte Stereotyp angezogen. Alle Elemente, die mit dem Stereotypen erweitert sind, werden selektiert. Inwiefern Elemente nach ihrem Status ausgefiltert werden sollen, hängt vom jeweiligen Anwendungsfall ab. Für diese Lösung werden die Elemente ungeachtet ihres Status in die Selektion aufgenommen.
Wie in Kapitel 3 beschrieben, werden bereits im SysML-Standard verschiedene Beziehungen definiert. So kann die Allokation eine Hierarchie der Elemente, wie sie auch im KM benötigt werden, darstellen. Es können sogar, wie im KM benötigt, mehrere übergeordnete Elemente abgebildet werden, sodass die Fähigkeit der Allokation zunächst hinreichend erscheint.
Allerdings ist zu fraglich, ob die Hierarchie der Modellstruktur auch der benötigten KM-Struktur entspricht. Aus diesem Grund werden im Stereotypen die über- bzw. untergeordneten IDs spezifiziert. Zeigt sich in der praktischen Anwendung, dass beide Hierarchien gleich sind, so kann natürlich auf eine redundante und damit potenziell fehlerträchtige Datenerfassung verzichtet werden. Dies ist einheitlich je Anwendungsfall zu bestimmen. Um an dieser Stelle aber ein Stereotyp zu definieren, das für beide Fälle adäquat ist, werden die IDs aufgenommen.
Nachfolgende Abbildung 5 enthält die abstrakte Syntax des Stereotypen ConfigurationItem. Zur besseren Einordnung wird neben dem direkten Metaelement („block“) auch dessen Ursprung in UML („class“) mit aufgenommen.
Die benötigten Attribute werden im Stereotypen definiert. Dabei wird die ID der KE (CI_ID) als Text definiert, um ggf. auch alphanumerische Identifizierer zu ermöglichen. Die Attribute für die über- bzw. untergeordnete KE (MetaCI und SubCI) werden als Typ des Stereotypen ConfigurationItem definiert. Damit können in diesen Attributen Elemente angezogen werden, die mit dem Stereotypen erweitert sind. Entsprechend wird umgekehrt sichergestellt, dass keine Blöcke ohne die KE-Erweiterung aufgenommen werden können. Der Status der KE wird über das Attribut Status in Textform festgehalten.
Aus der zuvor dargestellten Erweiterung der SysML und den bereits in SysML enthaltenen Fähigkeiten ist in dieser Lösung zu prüfen, ob auch KM-relevante Dokumente abgeleitet wer-den können.
Bereits berücksichtigt wurden oben die Dokumentationen der Baselines des jeweils betrachteten und modellierten Systems. Nachfolgend werden zunächst potenzielle KM-relevante Dokumente identifiziert und im Anschluss eine adäquate Umsetzung in einem SysML-Modell unter-sucht.
Die 1 beschreibt eine Reihe von typischen Berichten, die im Rahmen des KM benötigt werden. Nachfolgend werden diese Beispiele kurz aufgeführt:
In der DIN ISO 10007 wird außerdem die Forderung nach einem KM-Audit definiert. Dabei ist die KE einerseits funktionsbezogen auf die geforderten Leistungsmerkmale und andererseits auf die physische Umsetzung der gestellten Anforderungen zu überprüfen [1]. Zur Durchführung des Audits werden entsprechende Dokumente benötigt, die über den Prüfumfang einen hinreichend detaillierten Aufschluss geben.
Die einzelnen Konfigurationen eines Produktes inklusive ihrer Hierarchien untereinander sind in ihren Eigenschaften zu beschreiben. Neben einer eindeutigen Identifizierung sind sowohl eine Abbildung der enthaltenen Konfigurationen und KE als auch übergeordneten Konfigurationen vorzuhalten. Des Weiteren sind die für die Produktkonfigurationsangaben notwendigen Dokumente wie Stücklisten, Zeichnungen o. Ä. mit ihren jeweiligen Metadaten (Identifikation, Status, Änderungsindex, Freigabedatum, etc.) vorzuhalten. Aus diesen Informationen entsteht ein Konfigurationsidentifikationsdokument (KID).