Lifecycle-Definitionen für einen Workspace definieren

Jedes Item in einem verbundenen Workspace besteht aus einer Reihe von Revisionen, wobei jeweils eine neue Revision verwendet wird, um neue Daten aufzunehmen, sobald diese Daten geändert und festgeschrieben/hochgeladen/freigegeben werden. Die Revision spiegelt daher den Fortschritt des Items wider, während es Änderungen durchläuft. Anders ausgedrückt: Wenn sich die durch das Item repräsentierte Dateneinheit ändert, muss die Revision erhöht werden, um dies widerzuspiegeln.

Für jede Revision eines Items ist es außerdem wichtig, den aktuellen Status dieser Revision widerzuspiegeln – also welche Phase ihres „Lebens“ sie erreicht hat. Dieser Status wird als Lifecycle der Item-Revision bezeichnet.

Der Lifecycle ermöglicht es einem Unternehmen, das Item aus geschäftlicher Sicht und im Einklang mit Unternehmensrichtlinien und -praktiken zu verwalten. Mit diesen Lifecycle-Informationen können Personen, die ein Item in einem Workspace verwenden müssen – vom Entwickler, der die Wiederverwendung eines freigegebenen Design-„Bausteins“ in Betracht zieht, bis hin zur Lieferkette, die die Daten zur Fertigung und Bestückung einer Leiterplatte benötigt – auf einen Blick erkennen, welche Phase eine Revision eines Items in ihrem „Leben“ erreicht hat und wofür sie daher sicher verwendet werden kann.

Modellierung des Lifecycle

Auch wenn verschiedene Organisationen den Lifecycle von Design-Items leicht unterschiedlich modellieren oder benennen, folgen sie doch alle einem ähnlichen Grundmuster. Zum Beispiel verläuft der allgemeine Lebenszyklus eines Produkts etwa so: Es beginnt als Designidee, wird dann zu einem Prototyp, geht anschließend in die Produktion und wird irgendwann obsolet und nicht mehr hergestellt oder verkauft.

Die Verwendung von Lifecycle-Statusinformationen für jede Komponente eines Designs hilft sicherzustellen, dass ein Design nur dann in einen höheren Status überführt werden kann, wenn dieser neue Status kleiner oder gleich dem Status der Komponente mit dem niedrigsten Status innerhalb des Designs ist. Wenn ein Design beispielsweise bereit ist, in die Produktion überzugehen, sollte dies nur dann zulässig sein, wenn sich auch alle darin enthaltenen Komponenten in der Produktion befinden – d. h. Komponenten, die sich noch in In Prototype (oder New From Design) befinden, müssen in In Production überführt werden, bevor das Design als Ganzes auf diese Ebene angehoben werden kann.

In vielen Fällen durchlaufen die Revisionen von Design-Items die verschiedenen Lifecycle-Status linear. Es sollte jedoch nicht angenommen werden, dass dies der einzige mögliche Weg ist. So kann es beispielsweise vorkommen, dass einige Item-Revisionen verworfen werden, bevor sie überhaupt die Prototyping-Phase erreicht haben. In einem verbundenen Workspace werden die zulässigen Status, zwischen denen sich die Revision eines Items bewegen kann, durch eine in der Lifecycle-Definition enthaltene Transition-Tabelle festgelegt.

Ein verbundener Workspace unterstützt zwei Ebenen des Lifecycle-Managements: Simple oder Advanced. Diese bestimmen im Wesentlichen den Verwaltungsstil, auf dessen Grundlage dann die Lifecycle-Definitionen selbst aufgebaut werden. Bei einer Lifecycle-Definition auf Basis des einfachen Verwaltungsstils sind nur Status und Statusübergänge beteiligt. Bei einer Lifecycle-Definition auf Basis des erweiterten Verwaltungsstils können Status zusätzlich in definierte Phasen gruppiert werden.

Status, Phasen und Übergänge

Related page: Zugriff auf die detaillierte Item-Ansicht

Jeder Punkt im Lifecycle einer Item-Revision wird als State bezeichnet, zum Beispiel In Production. Wenn die Revision eines Items ihren Status ändert, wird dies als Transition bezeichnet, der nur in einen anderen Status erfolgen kann.

Lifecycle-Definitionen auf Basis des erweiterten Verwaltungsstils unterstützen die Gruppierung von Status in Stages. Phasen ermöglichen die Erstellung von Bezeichnungen, die kennzeichnen, wo sich die Revision eines Items in ihrer Entwicklung befindet. Sie könnte sich beispielsweise in Design, in Prototype oder in Production befinden.

Ein Beispiel für eine Lifecycle-Definition, deren Status in drei Phasen gruppiert sind.

Das folgende Bild zeigt einen Ausschnitt aus der detaillierten Item-Ansicht für ein Item, das ein 3-stufiges Revisionsbenennungsschema verwendet: Model, Prototype und Revision. Jedes Modell wird als separater Block dargestellt. Innerhalb eines Modells ist jeder Prototyp ein Unterblock. Unter jedem Prototyp befinden sich die Revisionen dieses Modells/Prototyps, und innerhalb jeder Revision die verschiedenen Status, in denen sich die Revision befand.

Beispielhafte Lifecycle-Status für verschiedene Revisionen eines Items.

Standard-Lifecycle-Definitionen

Ein verbundener Workspace stellt acht Standard-Lifecycle-Definitionen bereit. Diese Standarddefinitionen können unverändert verwendet oder an Unternehmens- (oder persönliche) Anforderungen angepasst werden. Bei Bedarf können auch neue, benutzerdefinierte Definitionen hinzugefügt und konfiguriert werden.

Die Standard-Lifecycle-Definitionen sind wie folgt:

• Component Lifecycle
• Design Lifecycle
• Extension Lifecycle
• Generic Lifecycle
• Sample - Basic Lifecycle
• Sample - Simple Lifecycle
• Sample - Simple Lifecycle With Approvals
• Sample - Structured Lifecycle With Approvals

Die angewendete Lifecycle-Definition wird beim Erstellen eines Items auf der Ebene des einzelnen Items ausgewählt. Unterschiedlichen Items können daher unterschiedliche Lifecycle-Definitionen zugewiesen werden.

Verwalten von Lifecycle-Definitionen

Innerhalb von Altium Designer können Lifecycle-Definitionen im Dialog Edit Lifecycle Definitions angezeigt und verwaltet werden. Um auf diesen Dialog für den verbundenen Workspace zuzugreifen, bei dem Sie derzeit angemeldet sind:

1. Öffnen Sie die Seite Datenverwaltung – Server des Dialogs Preferences.
2. Klicken Sie auf das Steuerelement Properties ganz rechts im Eintrag des aktiven Servers.
3. Wählen Sie im zugehörigen Menü den Befehl Lifecycles.

Lifecycle-Definitionen für den aktiven verbundenen Workspace werden – in Altium Designer – über den Dialog Edit Lifecycle Definitions erstellt und bearbeitet.

Hinzufügen einer neuen Definition

Um eine neue Lifecycle-Definition zu erstellen, klicken Sie unten im Dialog auf die Schaltfläche Edit Lifecycle Definitions. Im Dialog erscheint eine neue Registerkarte, die zur Konfiguration bereit ist.

Erstellen Sie Ihre eigene benutzerdefinierte Lifecycle-Definition.

Konfigurieren einer Definition

Verwenden Sie die innerhalb der Registerkarte einer Lifecycle-Definition verfügbaren Steuerelemente, um diese Definition nach Bedarf zu konfigurieren.

Geben Sie zunächst im Feld Definition Name einen aussagekräftigen Namen für die Definition ein. Die Registerkarte übernimmt den eingegebenen Namen dynamisch.

Verwenden Sie die Steuerelemente Lifecycle Management, um den Stil des Lifecycle-Managements auszuwählen – entweder Simple oder Advanced. Der einfache Stil bedeutet, dass nur States und State Transitions beteiligt sind. Der erweiterte Stil ermöglicht die Definition von Stages, in die die Status gruppiert werden.

Geben Sie Name und Stil für die Lifecycle-Definition an.

Anfangsstatus

Verwenden Sie das Feld Initial State of Revisions, um den Startstatus für eine Item-Revision festzulegen, also den Status der Revision, in dem sie keine freigegebenen Daten enthält – gewissermaßen den „Vor-Freigabe-Status“. Standardmäßig trägt dieser Status den Namen Planned. Um ihn zu ändern, klicken Sie auf den Link und verwenden den Dialog State Properties, um seinen Namen und eine Beschreibung sowie Text- und Hintergrundfarben festzulegen.

Konfigurieren Sie den Anfangsstatus für Revisionen.

Phasen

Wenn der Lifecycle-Managementstil Advanced gewählt wird, werden Steuerelemente zum Hinzufügen und Definieren der erforderlichen Phasen verfügbar. Standardmäßig wird eine einzelne Phase mit dem Namen Design - bereitgestellt, mit der Möglichkeit, zwei weitere Phasen hinzuzufügen. Um eine zusätzliche Phase hinzuzufügen, klicken Sie auf den Link Add Stage.

Geben Sie die Namen für die Phasen nach Bedarf ein, indem Sie direkt in das jeweilige Feld Stage Name schreiben.

Fügen Sie nach Bedarf Phasen hinzu, die zum Gruppieren von Status und zum Erstellen einer umfassenderen, strukturierten Lifecycle-Definition verwendet werden.

Zum Entfernen einer Phase klicken Sie auf das Steuerelement rechts neben dem jeweiligen Feld Stage Name.

Status

Der nächste Schritt besteht darin, die erforderlichen Zustände für die Lifecycle-Definition hinzuzufügen. Bei einer Lifecycle-Definition, die auf dem einfachen Verwaltungsstil basiert, ist dies eine flache Liste. Beim erweiterten Verwaltungsstil müssen Zustände zu den verschiedenen definierten Phasen hinzugefügt werden.

Klicken Sie auf das Steuerelement unterhalb einer Zustandsliste, um einen neuen Zustand hinzuzufügen. Verwenden Sie den daraufhin angezeigten Dialog State Properties, um diesen Zustand anhand von Name, Beschreibung und Farbmerkmalen zu definieren.

Hinzufügen eines Zustands zur Lifecycle-Definition.

Ein neuer Zustand wird am Ende der Liste hinzugefügt. Klicken Sie auf einen Zustand, um ihn auszuwählen, und verwenden Sie dann die Steuerelemente und (unterhalb der Zustandsliste), um ihn an die gewünschte Position in der Liste zu verschieben.

Beim Definieren von Zuständen für eine Lifecycle-Definition im erweiterten Stil stehen zusätzliche Steuerelemente zur Verfügung (unterhalb der Zustandsliste), um einen Zustand zwischen Phasen zu verschieben. Je nach Position der Phase verschieben Sie den Zustand nach Bedarf in die Phase rechts () oder links ().

Um die Eigenschaften eines Zustands zu bearbeiten, klicken Sie darauf, um ihn auszuwählen, und klicken Sie dann ganz rechts auf das Steuerelement . Um einen ausgewählten Zustand zu löschen, verwenden Sie das Steuerelement .

Beispiel für Zustände, die über eine Lifecycle-Definition mit zwei Phasen definiert sind.

Übergänge

Der letzte Schritt besteht darin, die State Transitions zu definieren – die Pfade zwischen den verschiedenen Zuständen. Klicken Sie auf einen Zustand, um ihn auszuwählen, und klicken Sie dann ganz rechts auf das Steuerelement , um einen neuen Zustandsübergang hinzuzufügen. Verwenden Sie den daraufhin angezeigten Dialog State Transition Properties, um den Übergang anhand von Name, Zielzustand (nächster Zustand), Menütext und Berechtigungen zu definieren.

Hinzufügen eines Zustandsübergangs.

Ein neuer Übergang wird am Ende der Liste hinzugefügt. Klicken Sie auf einen Übergang, um ihn auszuwählen, und verwenden Sie dann die Steuerelemente und unterhalb der Zustandsliste, um ihn an die gewünschte Position in der Liste zu verschieben.

Befindet sich der nächste Zustand für einen Übergang in einer anderen Phase, wird ein Hinweis-Pfeil – in der Farbe des Zielzustands – angezeigt, um dies zu verdeutlichen.

Beispiel für vollständig definierte Zustände und Zustandsübergänge über eine Lifecycle-Definition mit zwei Phasen. Pfeile werden verwendet, um Übergänge zwischen Phasen anzuzeigen.

Um die Eigenschaften eines Übergangs zu bearbeiten, klicken Sie darauf, um ihn auszuwählen, und klicken Sie dann ganz rechts auf das Steuerelement . Um einen ausgewählten Übergang zu löschen, verwenden Sie das Steuerelement .

Steuerung von Übergängen zwischen Lifecycle-Status

Der verbundene Workspace bietet große Flexibilität bei der Entscheidung, wer bestimmte Statusübergänge für eine Item-Revision in diesem Workspace durchführen kann – also die Aktion, eine Revision von einem Status in einen anderen zu überführen, wie durch die für das übergeordnete Item verwendete Lifecycle-Definition festgelegt. Es ist möglich, Standardbenutzern (ohne Administratorrechte) spontane Übergänge zwischen bestimmten Lifecycle-Status zu untersagen und gleichzeitig Berechtigungen über den Kreis der Workspace-Administratoren hinaus zu vergeben. Sie können Berechtigungen auf globaler Ebene festlegen – als Teil der globalen Betriebsberechtigungen für den Workspace – und auch auf Ebene einzelner Statusübergänge. Letztere wirken zusammen mit den Einstellungen auf globaler Ebene und ermöglichen eine Feinabstimmung der Berechtigungen für wichtigere Übergänge (zum Beispiel das Setzen einer Item-Revision auf Ready for Production).

Alternativ können Standardbenutzer dazu verpflichtet werden, für bestimmte Statusübergänge eine Genehmigung anzufordern. Diese Approval Requests werden wiederum an diejenigen gesendet, von ihnen angezeigt und bearbeitet, die als Mitglieder einer oder mehrerer Approval Groups festgelegt sind.

Mit verschiedenen Stufen der Berechtigungssteuerung können Sie eine Strategie für Lifecycle-Statusübergänge definieren, die dem bevorzugten Ansatz Ihrer Organisation entspricht.

Berechtigungen können auf zwei Ebenen definiert werden:

• Globally – legt fest, welche Benutzer und/oder Gruppen Statusübergänge für den gesamten Bereich definierter Übergänge über alle definierten Lifecycle-Definitionen hinweg durchführen können.
• Locally – gibt Berechtigungen auf Ebene einzelner Statusübergänge an.

Globale Berechtigungen für Statusübergänge

Globale Berechtigungen für Statusübergänge werden in Altium Designer im Dialog Edit Operation Permissions dialog definiert und verwaltet. Auf diesen Dialog greifen Sie über die Seite Data Management – Servers page des Dialogs Preferences dialogProperties zu. Klicken Sie für den verbundenen Workspace, dessen Berechtigungen Sie durchsuchen/ändern möchten, rechts auf das Steuerelement Operations und wählen Sie im zugehörigen Menü den Befehl .

Der hier relevante Workspace-Operationseintrag ist Move revision between lifecycle states.

Greifen Sie auf globaler Ebene darauf zu und konfigurieren Sie, wer Lifecycle-Statusübergänge durchführen darf.

Für einen neuen verbundenen Workspace sind die Standardberechtigungseinstellungen für diese Operation:

• Administratoren
• Mitarbeiter
• Bibliothekare
• Manager

Definieren Sie bei Bedarf zusätzliche Berechtigungen (klicken Sie auf die Schaltfläche Add). Berechtigungen für Statusübergänge auf dieser globalen Ebene können den folgenden Entitäten zugewiesen werden:

•   Administratoren (selbst eine definierte Gruppe).
•   Mitarbeiter (dies ist ein Benutzer mit Bearbeitungsrechten für ein Item/eine Revision).
•   Eigentümer (bei freigegebenen Daten ist dies die Person, die das ursprüngliche Item erstellt hat).
•   Bestimmte benutzerdefinierte Gruppe.
•   Bestimmter Benutzer.

Lokale Berechtigungen für Statusübergänge

Berechtigungen für einen bestimmten Statusübergang werden im zugehörigen Dialog State Transition Properties dialog definiert, auf den Sie über den entsprechenden Bereich States and Transitions der aktuell im Dialog Edit Lifecycle Definitions dialog konfigurierten Lifecycle-Definition zugreifen.

Um die Eigenschaften eines Übergangs zu bearbeiten, klicken Sie darauf, um ihn auszuwählen, und klicken Sie dann ganz rechts auf das Steuerelement .

Zugriffssteuerungen zum Definieren von Berechtigungen für den aktuell bearbeiteten Statusübergang.

Wählen Sie über das Feld State Transition Permissions die Art der Berechtigungssteuerung aus, die Sie für den Übergang verwenden möchten. Es stehen zwei Optionen zur Verfügung:

• Controlled – dieser Typ ermöglicht es Ihnen, genau festzulegen, wer diesen Übergang durchführen kann, indem Sie einen oder mehrere Benutzer und/oder Gruppen angeben. Diese Art der lokalen Berechtigungssteuerung wird in Kombination mit Berechtigungen verwendet, die auf globaler Ebene festgelegt wurden (siehe How Permissions are Applied). Verwenden Sie die Steuerelemente im unteren Bereich, um die zulässigen Entitäten entsprechend zu definieren. Standardmäßig wird die Entität Anyone hinzugefügt, was bedeutet, dass alle Benutzer auf dieser lokalen Ebene den Übergang durchführen dürfen.

  Um bestimmte Benutzer und/oder Gruppen einzurichten, wählen Sie zuerst die Entität Anyone aus und entfernen Sie sie. Anschließend können Sie über das Menü der Schaltfläche Add nach Bedarf einen Benutzer oder eine Gruppe hinzufügen. Verwenden Sie anschließend den Dialog Search for Users bzw. den Dialog Search for Role, um den gewünschten Benutzer bzw. die gewünschte Gruppe zu finden.

  
  Mit Berechtigungen vom Typ Controlled können Sie von Zugriff für alle auf nur die angegebenen Benutzer/Gruppen umschalten.

• Using Approvals – dieser Typ erlaubt es jedem Standardbenutzer, anzufordern, dass dieser Statusübergang durchgeführt wird. Anfragen werden von einem oder mehreren Benutzern bearbeitet, die definierten Genehmigungsgruppen hinzugefügt wurden – einzeln oder über Gruppen. Jedes Mitglied einer solchen Gruppe kann eine Übergangsanfrage genehmigen oder ablehnen. Zusätzlich können mehrere Genehmigungsgruppen definiert und geordnet werden. Dies ermöglicht mehrere Genehmigungsstufen.

  Verwenden Sie die Steuerelemente im unteren Bereich, um die Genehmigungsgruppe(n) entsprechend zu definieren. Standardmäßig wird eine einzelne, leere Genehmigungsgruppe hinzugefügt – New Approval Group. Diese kann bei Bedarf über den Befehl Edit Approval Group Name im Menü der Schaltfläche Add (oder im Kontextmenü des Bereichs) umbenannt werden.

  Sie können einer ausgewählten Genehmigungsgruppe nach Bedarf einen Benutzer oder eine Gruppe hinzufügen – über das Menü der Schaltfläche Add (oder das Kontextmenü des Bereichs). Verwenden Sie anschließend den Dialog Search For Users oder den Dialog Search For Role, um den gewünschten Benutzer bzw. die gewünschte Gruppe zu finden. Ordnen Sie mehrere Genehmigungsgruppen mit den Befehlen Move Up und Move Down aus einem Menü – die Genehmigung erfolgt von oben nach unten.

  
  Mit Using Approvals müssen alle Nicht-Admin-Benutzer einen Übergang anfordern, der dann von einem Benutzer in einer oder mehreren definierten Genehmigungsgruppen bearbeitet wird.

Wie Berechtigungen angewendet werden

Wie Berechtigungen angewendet werden, hängt von der Art der Berechtigungssteuerung ab, die auf Ebene des Statusübergangs ausgewählt und konfiguriert wurde:

• Controlled Permissions – damit ein Benutzer den Statusübergang durchführen kann, müssen die folgenden Bedingungen erfüllt sein:
  • Er muss auf globaler Ebene die Berechtigung haben, Move revision between lifecycle states (definiert im Dialog Edit Operation Permissions dialog).
  • Er muss auf lokaler Ebene für diesen speziellen Statusübergang berechtigt sein.
  • Er muss außerdem ein Mitwirkender an der Item-Revision sein, deren Lifecycle-Status geändert wird (d. h. er muss Bearbeitungsrechte haben).
  Diese drei Bedingungen sind per UND verknüpft – wenn eine davon nicht erfüllt ist, wird der Benutzer daran gehindert, diesen spezifischen Übergang durchzuführen.
  Für nicht-administrative Benutzer bedeuten die Standard-Berechtigungseinstellungen (Collaborator auf globaler Ebene und Anyone auf lokaler Ebene des Statusübergangs), dass Sie einen Benutzer lediglich als Mitwirkenden für die erforderliche Item-Revision festlegen müssen, damit alle Bedingungen erfüllt sind. Für wichtige Übergänge können Sie die Berechtigungen dann einfach auf lokaler Ebene des Statusübergangs verschärfen, sodass nicht jeder beliebige Mitwirkende den Übergang durchführen kann.

• Using Approvals – alle nicht-administrativen Benutzer müssen das Freigabesystem verwenden und eine Anfrage senden, um den Statusübergang durchzuführen. Das Freigabesystem erfordert nicht, dass der Benutzer auf globaler Ebene die Berechtigung zum Durchführen von Statusübergängen besitzt, und der Benutzer muss auch kein Mitwirkender an der Item-Revision sein.

  Auch wenn ein Benutzer kein Mitwirkender an der Item-Revision sein muss, muss diese für ihn freigegeben sein, andernfalls kann er sie im Workspace nicht sehen.

Verknüpfen von Phasen mit Ebenen des Revisionsbenennungsschemas

Revisionen und Lifecycle-Status können über das entsprechende Rechtsklickmenü in der Ansicht Item oder auf der Registerkarte der Aspektansicht Lifecycle im Bereich Explorer panel erhöht werden. Obwohl das Erstellen einer neuen Revision und das Fortschalten des Lifecycle zwei völlig getrennte Aufgaben sind, die aus unterschiedlichen Gründen durchgeführt werden (eine neue Revision bei einer Designänderung, ein neuer Lifecycle-Status zur Abbildung der erweiterten Verwendbarkeit dieser Item-Revision), stehen sie in Beziehung zueinander.

Bei einer Lifecycle-Definition, die auf dem erweiterten Verwaltungsstil basiert, können die definierten Phasen mit den Revisionsebenen des verwendeten Revisionsbenennungsschemas verknüpft werden. Verwenden Sie dazu die Option unten im Dialog Edit Lifecycle Definitions.

Option zum Verknüpfen von Phasen mit Revisionsebenen.

Dadurch wird eine Beziehung zwischen der Lifecycle-Phase und der Revisionsebene hergestellt. Das bedeutet: Wenn der Lifecycle einer Item-Revision erhöht wird, sodass sie von einem Status in einer Phase zu einem Status in einer anderen Phase wechselt, ändern sich auch die verfügbaren Befehle für den Revisionstyp im Rechtsklickmenü.

Betrachten Sie die Standard-Lifecycle-Definition Sample - Structured Lifecycle With Approvals und ein Revisionsbenennungsschema mit 3 Ebenen (mit Ebenen für Revision, Prototype und Model). Wenn sich eine Item-Revision im Status New From Design in der ersten Phase befindet, umfassen die Optionen für den Revisionstyp im Rechtsklickmenü: eine neue Revision erstellen, einen neuen Prototyp oder ein neues Modell.

Wenn der Lifecycle dann so weit erhöht wird, dass er sich nun in In Prototype befindet, ist er in die zweite Phase übergegangen. Beim Rechtsklick darauf umfassen die verfügbaren Optionen für den Revisionstyp nun: einen neuen Prototyp oder ein neues Modell erstellen; es gibt also keine Option, eine neue Revision zu beginnen. Dieses Verhalten ist intuitiv zu erwarten – wenn das Design bis zum Prototyp fortgeschritten ist, dann wäre bei einer erforderlichen Designänderung ein neuer Prototyp oder sogar ein neues Modell erforderlich, abhängig vom Umfang dieser Änderung.

Sobald die Item-Revision den Status In Production in der dritten Phase erreicht, ist erwartungsgemäß nur noch die Option verfügbar, ein neues Modell zu erstellen.

Wenn sie verknüpft sind, ändern sich die Befehle für den Revisionstyp, während der Lifecycle-Status der Item-Revision die verschiedenen definierten Phasen durchläuft.

Speichern einer Definition

Unabhängig davon, ob eine neue Lifecycle-Definition hinzugefügt oder eine vorhandene Lifecycle-Definition in irgendeiner Weise geändert wurde, muss diese Lifecycle-Definition gespeichert werden. Obwohl es keine eigentliche „Speichern“-Steuerung gibt, stehen dafür folgende Steuerelemente zur Verfügung:

• Für eine neue Lifecycle-Definition – erkennbar am Suffix „+“ – verwenden Sie entweder das Steuerelement Add Definition (oben rechts auf der Registerkarte der Definition) oder klicken auf die Hauptschaltfläche des Dialogs.
• Für eine vorhandene Lifecycle-Definition, die geändert wurde – erkennbar am Suffix „*“ – verwenden Sie entweder das Steuerelement Apply Changes (oben rechts auf der Registerkarte der Definition) oder klicken auf die Hauptschaltfläche des Dialogs.

In beiden Fällen wird das Suffix entfernt und die neue (oder geänderte) Definition steht als Teil der im Workspace verfügbaren Lifecycle-Definitionen zur Verfügung.

Die Verwendung der Hauptschaltfläche des Dialogs ermöglicht ein „Speichern“ im Batch-Stil, während der Dialog geöffnet bleibt.

Im Sinne einer klaren und transparenten Audit-Trail-Dokumentation – wer was wann geändert hat – werden unten rechts auf der Registerkarte Details dazu angezeigt, wann eine Lifecycle-Definition zuletzt geändert wurde.

Erkennen, wann eine Lifecycle-Definition zuletzt geändert wurde und von wem.

Umbenennen einer Definition Diese Funktion ist nur für Benutzer mit administrativen Rechten für den Workspace verfügbar.

So benennen Sie eine vorhandene, verwendete Lifecycle-Definition um:

1. Rufen Sie den Dialog Edit Lifecycle Definitions für den aktuell verbundenen Workspace auf.
2. Klicken Sie auf die Registerkarte der Definition, deren Namen Sie ändern möchten.
3. Ändern Sie den Namen im Feld Definition Name.

Beispiel für das Umbenennen einer Lifecycle-Definition und das Überprüfen der Änderung in den Eigenschaften eines Item, das diese Definition bereits verwendet.

Kopieren einer Definition

Neue Lifecycle-Definitionen müssen nicht von Grund auf neu erstellt werden. Der Dialog Edit Lifecycle Definitions bietet die Möglichkeit, jede der vorhandenen Definitionen schnell zu kopieren. Gehen Sie dazu wie folgt vor:

1. Machen Sie die gewünschte zu kopierende Lifecycle-Definition zur aktiven Definition.
2. Klicken Sie auf das Steuerelement Make a copy  oben rechts auf der Registerkarte dieser Definition.
3. Es wird eine exakte Kopie der Definition erstellt, wodurch eine neue Definition mit dem anfänglichen Standardnamen New Lifecycle Definition entsteht. Benennen Sie sie nach Bedarf um.
4. Klicken Sie auf das Steuerelement Add Definition (oder auf die Hauptschaltfläche ), um die neue Definition effektiv zu speichern.

Löschen einer Definition

Um eine vorhandene Lifecycle-Definition zu löschen, wählen Sie sie aus – sodass sie im Dialog Edit Lifecycle Definitions zur aktiven Definition wird – und klicken dann auf das Steuerelement Delete oben rechts auf der Registerkarte der Definition.

Eine Lifecycle-Definition, die derzeit von einem Item im Workspace verwendet wird, kann nicht gelöscht werden.

Das endgültige Löschen einer Lifecycle-Definition erfolgt durch Klicken auf die Hauptschaltfläche des Dialogs (oder durch Klicken auf OK). Davor kann der Löschvorgang durch Klicken auf die Schaltfläche unten im Dialog rückgängig gemacht werden.

Der Vorgang zum Löschen von Lifecycle-Definitionen kann rückgängig gemacht werden.

Exportieren und Importieren von Definitionen

Benutzerdefinierte Lifecycle-Definitionen stehen nur in dem verbundenen Workspace zur Verfügung, in dem sie definiert wurden. Der Dialog Edit Lifecycle Definitions bietet Export- und Importfunktionen, mit denen Definitionen zwischen Workspaces übertragen werden können.

Die Lifecycle-Definition wird in einer Lifecycle-Definitionsdatei gespeichert (*.definition).

Um eine Lifecycle-Definition zu exportieren, klicken Sie auf das Steuerelement Export oben rechts auf ihrer Registerkarte. Verwenden Sie den nachfolgenden Dialog Save Lifecycle Definition, um festzulegen, wo und unter welchem Namen die Datei gespeichert werden soll.

Um eine Lifecycle-Definition zu importieren, klicken Sie auf die Schaltfläche unten im Dialog Edit Lifecycle Definitions. Verwenden Sie den Dialog Open Lifecycle Definition, um zur gewünschten Lifecycle-Definitionsdatei zu navigieren und sie zu öffnen. Die Lifecycle-Definition wird der Liste der im Workspace verfügbaren vorhandenen Lifecycle-Definitionen hinzugefügt.

Eine importierte Lifecycle-Definition erscheint als neue Definition, komplett mit dem Suffix „+“. Ihr Name ist der in der Definitionsdatei festgelegte und nicht der Dateiname selbst. Stellen Sie sicher, dass sie „gespeichert“ wird, indem Sie auf das Steuerelement Add Definition oder die Hauptschaltfläche des Dialogs klicken.

Einige vordefinierte Beispiel-Dateien für Lifecycle-Definitionen sind im Ordner \Program Files\Altium\AD<Solution/Version>\System\EDMSTemplates einer Standardinstallation von Altium Designer verfügbar.

Steuern der Verwendung einer Lifecycle-Definition

Die Kontrolle darüber, welche Item-Typen eine bestimmte Lifecycle-Definition verwenden können, kann beim Definieren jeder Definition global festgelegt und aktiviert werden. Wenn diese Funktion aktiviert ist, stehen beim Auswählen der Lifecycle-Definition für einen bestimmten Item-Typ nur die dafür zulässigen Definitionen zur Verfügung. Dadurch erhalten Sie eine zusätzliche Kontrollebene, um sicherzustellen, dass erstellte Items eines bestimmten Typs nur die von Ihnen gewünschte Lifecycle-Definition verwenden.

Die Steuerung erfolgt im Dialog Content Types. Klicken Sie auf die Registerkarte der jeweiligen Definition, deren Zugriff Sie konfigurieren möchten, und klicken Sie dann oben rechts auf der Registerkarte der Definition auf den Link Content Types.

Zugriff auf den Dialog Content Types – die zentrale Stelle, um festzulegen, welche Inhaltstypen die konfigurierte Lifecycle-Definition verwenden können.

Der Dialog Content Types listet alle unterstützten Inhaltstypen auf, die in Ihrem aktiven verbundenen Workspace erstellt werden können (durch den Benutzer oder durch das System). Die Option oberhalb der Liste – Control Lifecycle Definition per Content Type – bietet eine globale Steuerung dafür, ob die Funktion für diese bestimmte Definition aktiv (aktiviert) oder nicht aktiv (deaktiviert) ist. Aktivieren Sie diese Option und aktivieren Sie dann die zugehörige Option Use für jeden Inhaltstyp, der diese Definition verwenden können soll.

• Damit ein Workspace-Projekt erstellt werden kann, muss die Option Use für den Inhaltstyp Project in mindestens einer Lifecycle-Definition aktiviert sein.

• Damit Gerber- und ODB++-Dateisätze in Ihren Workspace (Altium 365 Workspace oder Enterprise Server Workspace) hochgeladen werden können, muss die Option Use für den Inhaltstyp Fabrication File in mindestens einer Lifecycle-Definition aktiviert sein.

• Weitere Informationen zu unterstützten Inhaltstypen finden Sie auf der Seite Working with Items. Andere Inhaltstypen, die im Dialog Content Types aufgeführt sind, dort jedoch nicht beschrieben werden, sind innerhalb der Software nicht funktionsfähig.
• Eine Variante dieses Dialogs wird auch verwendet, um die Verwendung eines bestimmten Revisionsbenennungsschemas zu steuern. Weitere Informationen finden Sie unter Controlling the Use of a Revision Naming Scheme.

Wechsel zwischen erweiterten und einfachen Lifecycle-Management-Modi

Sie können eine vorhandene Lifecycle-Definition von der Verwendung des Lifecycle-Management-Stils Advanced (Zustände, Zustandsübergänge und Phasen) auf den Verwaltungsstil Simple (nur Zustände und Zustandsübergänge) umstellen. Wenn Sie die Option Simple aktivieren, wird der Dialog Confirm Merge States angezeigt. Verwenden Sie diesen Dialog, um den Wechsel wie folgt zu behandeln:

• Klicken Sie auf Yes – alle definierten Zustände (und Zustandsübergänge) über die Phasen 1, 2 und 3 hinweg werden zu einer einzigen flachen Zustandsliste zusammengeführt.
• Klicken Sie auf No – alle definierten Zustände (und Zustandsübergänge) in Phase 2 und 3 werden gelöscht. Nur die Zustände (und Zustandsübergänge) in Phase 1 (der ganz linken Phase) bleiben in einer einzigen flachen Zustandsliste erhalten.

Wechsel des Lifecycle-Management-Stils – von Advanced zu Simple – mit Kontrolle darüber, wie die Zustände (und Zustandsübergänge) in anderen Phasen behandelt werden.

Genehmigungsanforderungen für Zustandsübergänge

In den folgenden Abschnitten werden die verschiedenen Aspekte der Verwendung des Genehmigungssystems näher betrachtet, mit dem nicht-administrative Benutzer Ihres Workspace bestimmte Zustandsübergänge durchführen können.

Erstellen einer Anforderung (Genehmigung anfordern)

Das Anfordern einer Genehmigung für einen Zustandsübergang erfolgt in Altium Designer in der Aspektansicht Lifecycle für die erforderliche Item-Revision (im Explorer panel) oder im grafischen Lifecycle-Bereich der detaillierten Ansicht Item. Klicken Sie mit der rechten Maustaste auf den Lifecycle der Revision und wählen Sie den Befehl, der den Übergang anfordert. Daraufhin wird ein Dialog Confirm angezeigt, in dem Sie eine Notiz dazu eingeben können, warum Sie die Anforderung stellen – dies kann den Mitgliedern der Genehmigungsgruppe bei ihrer Entscheidung helfen, ob Ihre Anforderung letztlich genehmigt werden soll oder nicht! Klicken Sie auf Yes, um die Anforderung zu erstellen.

Fordern Sie den Zustandsübergang an und fügen Sie eine hilfreiche Notiz hinzu, um Ihr Anliegen zu untermauern.

Nach der Erstellung erhalten die Mitglieder der für diesen Zustandsübergang geltenden Genehmigungsgruppe eine E-Mail-Benachrichtigung – vorausgesetzt, die Funktion E-Mail-Benachrichtigungen wurde aktiviert.

Die Konfiguration der Funktion E-Mail-Benachrichtigungen erfolgt durch einen Workspace-Administrator auf der Seite „Email Notifications“ in der Browseroberfläche des Workspace (Admin – Settings – Email Notifications).

Anzeigen von Genehmigungsanforderungen

Sowohl für den Initiator einer Zustandsübergangsanforderung (Requester) als auch für die in der für diesen Zustandsübergang geltenden Genehmigungsgruppe definierten Benutzer (Approvers) werden ausstehende Anforderungen im Bereich Explorer über einen speziellen Ordner Approval Requests angezeigt.

Ein Beispiel für eine Genehmigungsanforderung im Ordner Approval Requests, wie sie vom Anforderer (Simon Entist) und einem der Mitglieder der definierten (anfänglichen) Genehmigungsgruppe für den betreffenden Zustandsübergang (Des Igner) gesehen wird.

Die Zahl neben dem Ordnernamen Approval Requests gibt an, wie viele ausstehende Anforderungen vorhanden sind. Wenn die Option Show Approved Requests aktiviert ist (über das Menü ), spiegelt diese Zahl die Gesamtzahl wider (ausstehend + genehmigt).

Für jede Genehmigungsanforderung werden die folgenden Informationen angezeigt:

• Item Revision – die spezifische Item-Revision, für die die Anforderung gestellt wird.
• Requested By – der Initiator der Anforderung (der Anforderer). Der Eintrag hier verwendet den Benutzernamen des Benutzers.
• Requested At – das Datum und die Uhrzeit, zu denen die Anforderung erstellt wurde.
• Status – der aktuelle Status der Anforderung. Dies kann einer der folgenden Zustände sein:
  • Awaiting – die Anforderung wartet derzeit auf eine Aktion durch einen oder mehrere Genehmiger.
  • Approved – die Anforderung wurde genehmigt. Beachten Sie, dass dieser Zustand erst nach vollständiger Genehmigung durch alle für diesen Übergang definierten Genehmigungsgruppen erreicht wird.
• Transition – der spezifische Zustandsübergang, der für diese Item-Revision angefordert wird.
• Request Note – jede Notiz, die der Anforderer zum Zeitpunkt der Anforderung hinzugefügt hat.
• Action Forward – die hier angezeigten Steuerelemente gelten nur für ausstehende Anforderungen (solche mit dem Status Awaiting). Die Steuerelemente unterscheiden sich für die beiden Parteien wie folgt:
  • Requester – der Benutzer, der die Anforderung erstellt hat, kann sie Remind.
  • Approvers – ein Benutzer innerhalb einer Genehmigungsgruppe kann die Anforderung Approve.
• Action Backward – die hier angezeigten Steuerelemente gelten nur für ausstehende Anforderungen (solche mit dem Status Awaiting). Die Steuerelemente unterscheiden sich für die beiden Parteien wie folgt:
  • Requester – der Benutzer, der die Anforderung erstellt hat, kann sie Cancel.
  • Approvers – ein Benutzer innerhalb einer Genehmigungsgruppe kann die Anforderung Reject.

Aktionsbasierte Befehle für die Genehmigungsanforderung sind auch über das Rechtsklickmenü des Lifecycle der Item-Revision verfügbar (innerhalb der Aspektansicht Lifecycle).

Der mittlere Abschnitt der Seite dient zur Darstellung von Genehmigungsinformationen – siehe Abschnitt Approval Information Stream für weitere Details.

Bearbeiten einer Anforderung

Wie im vorherigen Abschnitt kurz beschrieben, können sowohl der Anforderer als auch der Genehmiger Aktionen durchführen. Die folgenden aufklappbaren Abschnitte betrachten jede dieser Aktionen genauer:

Remind

Diese Aktion kann vom Anforderer ausgeführt werden, wenn er auf eine Genehmigung gewartet hat, diese aber noch nicht erhalten hat. Sie ist vergleichbar mit dem Anstupsen einer Person oder dem Hochschieben eines Forenbeitrags – mit anderen Worten eine höfliche Art, die Mitglieder der betreffenden Genehmigungsgruppe daran zu erinnern, dass sie tätig werden müssen (in die eine oder andere Richtung). Klicken Sie auf das Steuerelement Remind, das der Genehmigungsanforderung zugeordnet ist. Daraufhin wird ein Dialog Confirm angezeigt, in dem Sie eine Notiz eingeben können, die möglicherweise die Dringlichkeit der Genehmigung unterstreicht! Klicken Sie auf Yes, um die Erinnerung auszulösen – die Mitglieder der für diesen Zustandsübergang geltenden Genehmigungsgruppe erhalten eine E-Mail-Benachrichtigung – vorausgesetzt, die Funktion E-Mail-Benachrichtigungen wurde aktiviert.

Beispiel für die Verwendung der Aktion Remind.

Approve

Diese Aktion kann von einem Mitglied der betreffenden Genehmigungsgruppe ausgeführt werden, um diese Anforderung zu genehmigen. Klicken Sie auf das Steuerelement Approve, das der Genehmigungsanforderung zugeordnet ist. Daraufhin wird ein Dialog Confirm angezeigt, in dem Sie bei Bedarf eine Notiz eingeben können. Klicken Sie auf Yes, um die Genehmigung zu erteilen – der Anforderer dieses Zustandsübergangs erhält eine E-Mail-Benachrichtigung – vorausgesetzt, die Funktion E-Mail-Benachrichtigungen wurde aktiviert.

Beispiel für die Verwendung der Aktion Approve.

Wenn es nur eine Genehmigungsgruppe gibt, führt die Genehmigung der Anforderung dazu, dass der Zustandsübergang automatisch erfolgt. Wenn es mehrere Genehmigungsgruppen gibt, wartet die Anforderung auf die Genehmigung durch ein Mitglied der nächsten Gruppe. Wenn der Genehmiger in der ersten Genehmigungsgruppe auch Mitglied der nächsten Genehmigungsgruppe ist, erfolgt die Genehmigung für diese zweite Gruppe automatisch.

Reject

Diese Aktion kann von einem Mitglied einer Genehmigungsgruppe ausgeführt werden, um diese Anforderung abzulehnen. Klicken Sie auf das Steuerelement Reject, das der Genehmigungsanforderung zugeordnet ist. Daraufhin wird ein Dialog Confirm angezeigt, in dem Sie bei Bedarf eine Notiz eingeben können, die möglicherweise darauf hinweist, warum die Anforderung abgelehnt wurde. Klicken Sie auf Yes, um die Ablehnung auszuführen – die Genehmigungsanforderung wird gelöscht, und der Anforderer dieses Zustandsübergangs erhält eine E-Mail-Benachrichtigung – vorausgesetzt, die Funktion E-Mail-Benachrichtigungen wurde aktiviert.

Beispiel für die Verwendung der Aktion Reject.

Cancel

Diese Aktion kann vom Anforderer ausgeführt werden, wenn er auf eine Genehmigung gewartet hat, sich inzwischen jedoch entschieden hat, die Anfrage zu stornieren. Dies kann beispielsweise passieren, wenn inzwischen ein anderes Problem gefunden wurde, das die Notwendigkeit des Übergangs in den erforderlichen Lifecycle-Status aufhebt. Klicken Sie auf das der Genehmigungsanfrage zugeordnete Cancel-Steuerelement. Daraufhin erscheint ein Confirm-Dialog, in dem Sie bei Bedarf eine Notiz eingeben können. Klicken Sie auf Yes, um die Stornierung durchzuführen – die Genehmigungsanfrage wird gelöscht.

Beispiel für die Verwendung der Aktion Cancel.

Informations-Stream zur Genehmigung

Wenn eine Anfrage genehmigt wird, ist beim Durchsuchen dieser Genehmigungsanfrage auch im zentralen Bereich der Seite eine Benachrichtigung verfügbar. Diese Informationen bestehen aus den folgenden Elementen:

• Created At – das Datum und die Uhrzeit, zu denen die Genehmigungsanfrage genehmigt wurde.
• Created By – das Mitglied der entsprechenden Genehmigungsgruppe, das die Anfrage genehmigt hat. Der Eintrag hier verwendet den Benutzernamen des Anwenders.
• Description – ein Eintrag, der aus einer automatisch generierten Nachricht sowie einer eventuell vom Genehmiger zum Zeitpunkt der Genehmigung hinzugefügten Notiz besteht. Der automatisch generierte Teil der Beschreibung hängt von der Art der Genehmigung ab:
  • Final approval (von einem Mitglied der einzigen oder letzten Genehmigungsgruppe) – task approved and completed.
  • Intermediate approval (von einem Mitglied einer Genehmigungsgruppe, die nicht die letzte Genehmigungsgruppe ist) – task approved and assigned to next approval group <ApprovalGroupName>.

Ein Beispiel für den Genehmigungs-Stream einer bestimmten Item-Revision, wie er vom Anforderer gesehen wird. In diesem Fall musste der Übergang zwei Genehmigungsstufen durchlaufen (Genehmigung durch ein Mitglied aus zwei verschiedenen Genehmigungsgruppen).

Diese Genehmigungsinformationen sind nur für Genehmigungsanfragen verfügbar, die den Status Approved haben oder den Status Awaiting haben und von der ersten von mehreren zugeordneten Genehmigungsgruppen genehmigt wurden.

Die folgenden Personen sehen diese Informationen:

• Der Anforderer des Statusübergangs.
• Der Benutzer, der die endgültige Genehmigung für die Anfrage erteilt. Wenn also mehrere Genehmigungsgruppen beteiligt sind, sieht nur das Mitglied der letzten Genehmigungsgruppe – das die endgültige Genehmigung erteilt – diese Informationen. Ein Mitglied einer Genehmigungsgruppe, das eine Zwischenfreigabe erteilt, sieht diesen Stream nicht.

Steuerung von Sichtbarkeit und Anwendbarkeit von Item-Revisionen

Beim Konfigurieren jedes einzelnen Status einer Lifecycle-Definition können Sie zusätzliche Statusattribute definieren, die die Sichtbarkeit und Anwendbarkeit einer Item-Revision steuern, die diese Lifecycle-Definition verwendet und in diesen Status eintritt. Hinsichtlich der Anwendbarkeit kann außerdem ein Projektverletzungsbericht so konfiguriert werden, dass er alle Workspace-Elemente erkennt und kennzeichnet, die in einem Design verwendet werden und deren Revisionen sich in nicht anwendbaren Status befinden – sodass Probleme vor der Freigabe erkannt und vermieden werden.

Steuerelemente zur Festlegung, ob eine Item-Revision in einem bestimmten Status sichtbar und/oder anwendbar ist, sind im Dialog State Properties verfügbar. Innerhalb des Dialogs Edit Lifecycle Definitions greifen Sie auf diesen Dialog für den gewünschten Status entweder durch Doppelklick auf den Eintrag des Status innerhalb der übergeordneten Lifecycle-Definition zu oder indem Sie seinen Eintrag auswählen und auf das angezeigte Bearbeitungssymbol klicken ().

Verwenden Sie auf Statusebene definierte Attribute, um die Sichtbarkeit und/oder Anwendbarkeit einer Item-Revision zu steuern, die in diesen Status eintritt.

Die beiden Optionen sind:

• Visible in Vault panels – wenn diese Option aktiviert ist, wird eine Revision eines Items, das die übergeordnete Lifecycle-Definition verwendet, im Explorer panel angezeigt, wenn sie auf diesen Lifecycle-Status gesetzt ist. Wenn diese Option deaktiviert ist, wird die Revision ausgeblendet. Eine ausgeblendete Revision kann im Explorer-Panel angezeigt werden (wodurch diese Option überschrieben wird), indem das Steuerelement Show Hidden Revisions aktiviert wird (siehe Ausgeblendete Revisionen anzeigen).
• Allowed to be used in designs – wenn diese Option aktiviert ist, darf eine Item-Revision in diesem Status in einem Design verwendet werden. Sie gilt als Applicable. Wenn diese Option deaktiviert ist, kann eine Item-Revision in diesem Status nicht gültig verwendet werden und gilt als Inapplicable (oder nicht anwendbar). Dies wird im Properties-Panel und im Dialog Item Manager entsprechend gekennzeichnet (siehe Nicht anwendbare Revisionen kennzeichnen). Der Projekt-Compiler kann ebenfalls so konfiguriert werden, dass er solche Vorkommnisse erkennt (siehe Nicht anwendbare Revisionsstatus bei der Kompilierung erkennen).

Im Components panel werden alle neuesten Revisionen von Komponenten angezeigt, die in Designs verwendet werden dürfen, selbst wenn diese Komponenten einen Status erreicht haben, bei dem die Option Visible in Vault panels deaktiviert wurde. Der Filter LifeCycle kann verwendet werden, um nach Komponenten in einem bestimmten Status oder in bestimmten Status zu suchen.

Ausgeblendete Revisionen anzeigen

Für eine Item-Revision, die in einen Lifecycle-Status eintritt, bei dem ihr Attribut Visible in Vault panels deaktiviert ist, wird diese Revision standardmäßig nicht im Explorer panel angezeigt. Und wenn es sich dabei um die neueste Revision des Items handelt, wird der gesamte Eintrag für dieses Item effektiv ausgeblendet. Dieser auf Statusebene definierte Sichtbarkeitsstatus kann global für alle Items überschrieben werden, wenn im Explorer-Panel geblättert wird. Um alle derzeit nicht sichtbaren Item-Revisionen anzuzeigen, klicken Sie auf das Steuerelement oben rechts im Bereich Items des Panels und aktivieren dann im zugehörigen Menü die Option Show Hidden Revisions.

Anzeigen ausgeblendeter Item-Revisionen beim Durchsuchen von Inhalten im Explorer-Panel. Bewegen Sie den Mauszeiger über das Bild, um das Ergebnis zu sehen.

Nicht anwendbare Revisionen kennzeichnen

Typischerweise wird ein Lifecycle-Status, der auf ausgeblendet gesetzt ist (Option Visible in Vault panels deaktiviert), auch als nicht anwendbar festgelegt (Option Allowed to be used in designs ebenfalls deaktiviert). Beispielsweise sollte eine Revision einer Komponente, die derzeit Depracated oder Obsolete ist, im neuesten Design-Spin keinen Platz haben! Das Ausblenden von Revisionen von Items, die solche Status erreicht haben, ist das eine – wenn Sie beispielsweise eine Komponente nicht sehen können, können Sie sie auch nicht platzieren. Es kann jedoch sein, dass Sie bereits Instanzen solcher Item-Revisionen in einem Design verwenden oder versehentlich eine nicht anwendbare Revision einer Komponente platziert haben, weil Sie beim Durchsuchen ausgeblendete Revisionen eingeblendet hatten!

Kein Grund zur Sorge. Abgesehen davon, dass Component-Item-Revisionen in nicht anwendbaren Status bei der Kompilierung erkannt werden können (siehe nächsten Abschnitt), können Sie die Anwendbarkeit von Item-Revisionen (Komponenten und verwaltete Schaltplanblätter) auch direkt in Ihrer Designsoftware manuell prüfen. Dies geschieht über das Properties-Panel beim Durchsuchen der Eigenschaften des Elements oder durch Verwendung von Item Manager.

• Properties panel – wenn dieses Panel verwendet wird, um die Eigenschaften einer platzierten Instanz einer Revision einer Komponente oder eines verwalteten Schaltplanblatts zu durchsuchen, wird rechts neben dem Eintrag zum Revisionsstatus eine Kennzeichnung angezeigt. Wenn sich die Revision in einem nicht anwendbaren Status befindet (nicht zur Verwendung in Designs zugelassen), zeigt der Eintrag Not applicable an. Wenn sich die Revision in einem anwendbaren Status befindet (zur Verwendung in Designs zugelassen), zeigt der Eintrag entweder an, dass die Revision die neueste ist (Up to date) oder nicht (Out of date).

  
  Darstellung der Nichtanwendbarkeit auf Eigenschaftsebene für eine platzierte Instanz einer Revision einer Komponente und eines verwalteten Schaltplanblatts.

• Item Manager – im Dialog Item Manager (Tools » Item Manager) wird die Kennzeichnung im Feld Revision Status angezeigt. Wenn sich die Revision in einem nicht anwendbaren Status befindet (nicht zur Verwendung in Designs zugelassen), zeigt der Eintrag Not applicable an. Wenn sich die Revision in einem anwendbaren Status befindet (zur Verwendung in Designs zugelassen), zeigt der Eintrag entweder an, dass die Revision die neueste ist (Up to date) oder nicht (Out of date).

  
  Darstellung der Nichtanwendbarkeit über den Dialog Item Manager für eine platzierte Instanz einer Revision einer Komponente und eines verwalteten Schaltplanblatts.

• Verwenden Sie die im Properties-Panel oder im Dialog Item Manager verfügbaren Steuerelemente, um eine spätere Revision des Items auszuwählen, die sich in einem anwendbaren Status is befindet, oder wählen Sie, falls dies nicht möglich ist (das Item ist generell nicht für die Verwendung im Design vorgesehen), einfach eine anwendbare Revision eines anderen Items.

• Beim Ändern des Lifecycle-Status einer Komponenten-Item-Revision (mehr erfahren) prüft Altium Designer, ob sich die referenzierten untergeordneten Item-Revisionen (Vorlage und referenzierte Modelle) in einem anwendbaren Status befinden. Andernfalls zeigt der Status des Statusübergangs an, dass sich eine untergeordnete Item-Revision in einem nicht anwendbaren Status befindet.

Nicht anwendbare Revisionsstatus bei der Projektvalidierung erkennen

Bei platzierten Instanzen von Component-Item-Revisionen kann die Anwendbarkeit der Status dieser Revisionen als Teil der Projektvalidierung geprüft werden. Kernstück dieser Prüfung ist der Verletzungstyp Component revision has inapplicable state, der zur Kategorie Violations Associated with Components gehört. Konfigurieren Sie den Berichtsmodus für diese Prüfung auf der Registerkarte Error Reporting des Dialogs Project Options.

Der Standardwert Report Mode für diesen Verletzungstyp ist . Passen Sie ihn an die Anforderungen Ihres Designs an.

Die Projektvalidierung umfasst eine Prüfung auf Verletzungen im Zusammenhang mit Komponenten in nicht anwendbaren Revisionsstatus. Eine Verletzung tritt auf, wenn der Lifecycle-Status einer platzierten Component-Item-Revision so festgelegt wurde, dass sie nicht für Designzwecke verwendet werden darf.

Wenn Compiler-Fehler und -Warnungen zur Anzeige im Schaltplan aktiviert sind (aktiviert auf der Seite Schematic – Compiler des Dialogs Preferences), wird unter einem betroffenen Objekt eine farbige Wellenlinie angezeigt. Außerdem wird im Messages-Panel eine Benachrichtigung im folgenden Format angezeigt:

Component <Designator> <Comment>: Component revision has inapplicable state,

wobei:

• Designator die Designator der Komponenteninstanz ist.
• Comment die Comment der Komponenteninstanz ist.

Beispiel für eine Verletzung (für die Auswirkung auf Schwerwiegender Fehler gesetzt).

Dinge, die Sie beachten sollten:

• Wenn eine platzierte Komponente die Verbindung zum verbundenen Workspace verliert, aus dem sie platziert wurde – beispielsweise wenn dieser Workspace getrennt wird oder Sie von Ihrem Workspace abgemeldet sind –, verletzt sie die Prüfung Component revision has inapplicable state. Dies wird im Messages-Panel mit einem Eintrag in der Form Component <Designator> <Comment>: Can't perform revision status validation: Failed to connect to server angezeigt.
• Sie können während des Design-Freigabeprozesses auch Komponenten erkennen, die in einem Design unzulässig verwendet werden. Fügen Sie dazu einfach Component State Checking hinzu und konfigurieren Sie es als Teil Ihres gesamten Freigabevalidierungsprozesses. Weitere Informationen finden Sie unter Validierung des Komponentenstatus.