接続されたワークスペース内の各アイテムは、一連のリビジョンで構成されており、データが変更されてコミット/アップロード/リリースされるたびに、新しいリビジョンが新しいデータを収容するために使用されます。したがって、リビジョンはアイテムが変更を受けるにつれての進捗を反映します。または、逆に言えば、アイテムによって表されるデータエンティティが変更された場合、その変更を反映するためにリビジョンを増やす必要があります。
アイテムのリビジョンについては、そのリビジョンの現在の状態、つまりその「生涯」のどの段階に達しているかを反映することも重要です。この状態はアイテムリビジョンのライフサイクルとして参照されます。
ライフサイクルにより、企業はビジネスの観点からアイテムを管理し、企業のポリシーと実践に従って管理できます。このライフサイクル情報により、ワークスペース内のアイテムを使用する必要がある人々（リリースされた設計の「ビルディングブロック」の再利用を検討している設計者から、ボードを製造および組み立てるためにデータが必要なサプライチェーンまで）は、アイテムのリビジョンがその「生涯」のどの段階に達しているか、そしてそれが安全に使用できるものであるかを一目で確認できます。
ライフサイクルのモデリング
異なる組織は設計アイテムのライフサイクルをわずかに異なる方法でモデル化またはラベル付けするかもしれませんが、すべて同様のテーマに従います。例えば、製品の一般的なライフサイクルは、設計アイデアとして始まり、プロトタイプになり、生産に入り、そしてある時点で廃止され、もはや製造または販売されなくなるというものです。
設計の各コンポーネントにライフサイクルステータス情報を使用することで、新しい状態が設計内の最低状態コンポーネント以下である場合にのみ、設計をより高い状態に昇格させることができるようになります。例えば、設計が生産に移行する準備ができている場合、それに含まれるすべてのコンポーネントも生産中である場合にのみ、そうすることが許可されるべきです。つまり、まだプロトタイプ中（または設計からの新規）のコンポーネントは、設計全体がそのレベルに昇格する前に生産中に昇格させる必要があります。
多くの場合、設計アイテムのリビジョンは、さまざまなライフサイクル状態を線形に進行しますが、これが唯一の経路であると仮定すべきではありません。例えば、一部のアイテムリビジョンは、プロトタイピング段階に到達する前に放棄されることがあります。接続されたワークスペースでは、アイテムのリビジョンが移動できる許可された状態は、ライフサイクル定義に含まれる遷移表によって定義されます。
接続されたワークスペースは、ライフサイクル管理の2つのレベルをサポートしています：シンプルまたはアドバンスド。これらは基本的に管理のスタイルを決定し、その上でライフサイクル定義自体が構築されます。シンプルな管理スタイルに基づくライフサイクル定義の場合、状態と状態遷移のみが関与します。アドバンスドな管理スタイルに基づくライフサイクル定義の場合、状態はさらに定義された段階にクラスター化されることがあります。
シンプルおよびアドバンスドのライフサイクル管理スタイルは、同じセットの状態（アイテムのリビジョンがその生涯で存在できる異なるポイント）と遷移（アイテムのリビジョンがそれらの状態間を移動する方法）をサポートしています。
状態、段階、および遷移
関連ページ： 詳細なアイテムビューへのアクセス
アイテムリビジョンのライフサイクルの各ポイントは状態として参照されます。例えば生産中などです。アイテムのリビジョンが状態を変更する場合、それは遷移として参照され、それは他の状態へのものに限られます。
アドバンスドな管理スタイルに基づくライフサイクル定義は、状態を段階にクラスター化することをサポートしています。段階により、アイテムのリビジョンが開発のどの段階にあるかを識別するラベルを作成できます。例えば、それは設計中、またはプロトタイプ中、または生産中である可能性があります。
状態が3つの段階にクラスター化されたライフサイクル定義の例。
下の画像は、3段階のリビジョン命名スキーム（モデル、プロトタイプ、リビジョン）を採用したアイテムの詳細なItemビューのスニペットを示しています。各モデルは別々のブロックとして表示されます。モデル内では、各プロトタイプがサブブロックとなります。各プロトタイプの下には、そのモデル/プロトタイプのリビジョンがあり、リビジョン内にはそのリビジョンが存在したさまざまな状態があります。
アイテムのさまざまなリビジョンに対するライフサイクルの状態の例。
高度なスタイルのライフサイクル定義におけるステージは、使用されるリビジョン命名スキームのリビジョンレベルにリンクさせることもでき、アイテムのライフサイクルの提示に横の次元を作り出し、アイテムのリビジョンと融合します。詳細についてはリビジョン命名スキームのレベルへのステージのリンクセクションを参照してください。
デフォルトライフサイクル定義
接続されたワークスペースは、8つのデフォルトライフサイクル定義を提供します。これらのデフォルト定義はそのまま使用することも、会社や個人の要件に合わせて変更することもできます。また、新しいカスタム定義を追加し、必要に応じて設定することも可能です。
デフォルトのライフサイクル定義は次のとおりです：
-
Component Lifecycle
-
Design Lifecycle
-
Extension Lifecycle
-
Generic Lifecycle
-
Sample - Basic Lifecycle
-
Sample - Simple Lifecycle
-
Sample - Simple Lifecycle With Approvals
-
Sample - Structured Lifecycle With Approvals
適用されるライフサイクル定義は、アイテムを作成する際に個々のアイテムレベルで選択されます。したがって、異なるアイテムには異なるライフサイクル定義が割り当てられる場合があります。
ワークスペース内のアイテムが定義されたライフサイクル定義を使用している場合、その定義は削除できません。ただし、名前の変更、状態属性（色、遷移、適用性、可視性）の変更、新しい状態の定義への追加、未使用の状態の削除、段階をリビジョンレベルにリンクする（該当する場合）など、定義をある程度修正することはできます。アイテムが作成され、そのアイテムの計画されたリビジョン版への初回リリースが行われると、そのアイテムのライフサイクル定義を別のものに変更することはできません。
専用の承認状態と遷移を特徴とするライフサイクル定義は、アイテム修正がデザインからプロトタイプ、またはプロトタイプから生産に移動できるかどうかについて、適切な権限が最終的な決定権を持つことを実現します。
ライフサイクル定義の管理
Altium Designerの内部から、ライフサイクル定義はEdit Lifecycle Definitionsダイアログ内で表示および管理できます。現在サインインしている接続されたワークスペースのこのダイアログにアクセスするには：
-
PreferencesダイアログのData Management – Serversページを開きます。
-
アクティブサーバーのエントリーの最右端にあるPropertiesコントロールをクリックします。
-
関連メニューからLifecyclesコマンドを選択してください。
アクティブな接続されたワークスペースのライフサイクル定義は、Altium Designer内のEdit Lifecycle Definitionsダイアログを通じて作成および編集されます。
ブラウザベースのライフサイクル管理
接続されたワークスペースは、そのブラウザインターフェースを通じてライフサイクル定義を定義および管理する機能を提供し、Altium Designerを通じてこれを行う能力を補完します。また、関与する状態と遷移の可視性を向上させるために、各ライフサイクルはグラフィカルな方法で構築されており、関与するフローを一目で示しています。
ワークスペースのブラウザインターフェースを通じてライフサイクル定義を定義し管理することは、非常に視覚的な作業です。定義は、さまざまなグラフィカルオブジェクトを使用して、状態や状態遷移（および
Advanced管理スタイルを使用している場合は段階）を表すフローダイアグラムのように構築されます。
詳細については、
Lifecycle Management（
Altium 365 Workspace、
Enterprise Server Workspace）を参照してください。
新しい定義を追加する
新しいライフサイクル定義を作成するには、Edit Lifecycle Definitionsダイアログの下部にある
ボタンをクリックします。ダイアログに新しいタブが表示され、設定される準備が整います。
独自のカスタムライフサイクル定義を作成してください。
新しく追加されたライフサイクル定義は、そのタブに'+'のサフィックスが付いていることで区別されます。これは、その定義がまだ設定中であり、ワークスペースで利用可能なライフサイクル定義のセットにまだ「保存」されていないことを反映しています。
定義の設定
ライフサイクル定義のタブ内で利用可能なコントロールを使用して、その定義を必要に応じて構成します。
一度ワークスペース内のアイテムが定義されたライフサイクル定義を使用すると、その定義は削除できません。しかし、名前の変更、状態属性（色、遷移、適用性、可視性）の変更、定義への新しい状態の追加、未使用の状態の削除、および適用可能な場合は段階をリビジョンレベルにリンクすることなど、ある程度定義を修正することができます。
最初に、Definition Nameフィールドに意味のある名前を入力してください。タブは、入力された名前を動的に反映します。
Lifecycle Managementコントロールを使用して、ライフサイクル管理のスタイルを選択します - SimpleまたはAdvancedのいずれかです。シンプルスタイルは、関与するのが状態と状態遷移だけであることを意味します。アドバンスドスタイルでは、状態がクラスター化されるステージの定義が可能です。
ライフサイクル定義の名前とスタイルを指定してください。
初期状態
アイテムのリビジョンの初期状態を決定するには、Initial State of Revisionsフィールドを使用します。つまり、公開データを含まないリビジョンの状態、いわば「プレリリース状態」です。デフォルトでは、この状態はPlannedと名付けられています。これを変更するには、リンクをクリックし、State Propertiesダイアログを使用してその名前と説明、テキストおよび背景色を決定します。
リビジョンの初期状態を設定します。
ステージ
ライフサイクル管理のAdvancedスタイルが選択された場合、必要なステージを追加して定義するためのコントロールが利用可能になります。デフォルトでは、Design -という名前の単一ステージが提供され、さらに2つのステージを追加することができます。追加のステージを追加するには、Add Stageリンクをクリックします。
必要に応じて、各Stage Nameフィールドに直接入力することでステージの名前を入力してください。
必要に応じてステージを追加し、状態をクラスタリングして、より豊かで構造化されたライフサイクル定義を作成します。
ステージを削除するには、該当する
コントロールをクリックします。
状態
次のステップは、ライフサイクル定義に必要な状態を追加することです。管理のシンプルなスタイルに基づくライフサイクル定義の場合、これはフラットリストになります。高度な管理スタイルの場合、定義された各ステージに状態を追加する必要があります。
状態リストの下にある
コントロールをクリックして新しい状態を追加します。表示される状態プロパティダイアログを使用して、その状態を名前、説明、色属性の観点から定義します。
ライフサイクル定義に状態を追加します。
State Propertiesダイアログのオプションとコントロール
プロパティ
-
State Name - 状態の名前を指定します。
-
Description - 状態の説明を入力します。
-
Text Color - 色ボックスをクリックしてChoose Colorダイアログを開き、希望のテキスト色を選択します。
-
Background Color - 色ボックスをクリックしてChoose Colorダイアログを開き、希望の背景色を選択します。
テキスト色プレビュー
テキスト色のプレビューを表示します。
背景色プレビュー
背景色のプレビューを表示します。
-
Visible in Vault panels- このオプションを有効にすると、親ライフサイクル定義を使用するアイテムのリビジョンがこのライフサイクル状態に設定されている場合、Explorerパネルで表示されます。このオプションが無効の場合、リビジョンは両方の場所で非表示になります。ただし、非表示のリビジョンはShow Hidden RevisionsコントロールをExplorerパネルで有効にすることで表示することができます。
-
Allowed to be used in designs - このオプションを有効にすると、この状態のアイテムリビジョンを設計で使用することが許可されます。それは適用可能と見なされます。このオプションが無効の場合、この状態のアイテムリビジョンは有効に使用できず、適用不可（または非適用）と見なされます。ComponentモードのPropertiesパネルおよびItem Managerダイアログでそのようにフラグが立てられます。プロジェクトコンパイラも、そのような発生を見つけるように設定することができます。
新しい状態はリストの最下部に追加されます。状態を選択してから、
および
コントロール（状態リストの下）を使用して、リスト内の必要な位置に移動します。
高度なスタイルのライフサイクル定義の状態を定義する場合、追加のコントロールが利用可能になります（状態リストの下）ステージ間で状態を移動するために。ステージの位置に応じて、右のステージ（
）へ、または左（
）へ状態を押し出すことが必要です。
状態のプロパティを編集するには、それを選択してから、右端にある
コントロールをクリックします。選択した状態を削除するには、
コントロールを使用します。
2段階のライフサイクル定義を通じて定義された例示状態。
遷移
最後のステップは、状態遷移を定義することです – 異なる状態間のパスです。状態を選択するにはクリックし、次に最右の
コントロールをクリックして新しい状態遷移を追加します。表示されるState Transition Propertiesダイアログを使用して、名前、対象（次の）状態、メニュー テキスト、および権限の観点から遷移を定義します。
状態遷移を追加します。
ライフサイクル状態間の遷移を制御する
接続されたワークスペースは、そのワークスペース内のアイテムリビジョンの特定の状態遷移を誰が行うことができるかを決定するための優れた柔軟性を提供します。これは、親アイテムのライフサイクル定義によって定義されたように、リビジョンをある状態から異なる別の状態に遷移させるアクションです。標準（非管理者）ユーザーが特定のライフサイクル状態間での遷移を制限しつつ、ワークスペース管理者だけでなく、より多くの権限を開放することが可能です。グローバルレベルでの権限を指定する能力があります。これはワークスペースのグローバル操作権限の一部として、また個々の状態遷移レベルでも可能です。後者は、グローバルレベルの設定と連携して動作し、より重要な遷移（例えば、アイテムリビジョンをReady for Productionに設定すること）のための権限の微調整を容易にします。
また、標準ユーザーは特定の状態遷移の承認を要求するように設定できます。その結果、これらの承認要求は、一つまたは複数の承認グループのメンバーに指定された人々に送信され、表示され、対応されます。
さまざまなレベルの権限管理により、組織の好ましいアプローチに従ったライフサイクル状態遷移戦略を定義できます。
権限は二つのレベルで定義できます：
グローバル状態遷移権限
グローバルな状態遷移権限は、Altium Designer内のEdit Operation Permissionsダイアログを使用して定義および管理されます。このダイアログには、PreferencesダイアログのData Management – Serversページからアクセスできます。権限を参照または変更したい接続されたワークスペースについては、右側のPropertiesコントロールをクリックし、関連するメニューからOperationsコマンドを選択してください。
ここで重要なワークスペース操作のエントリは、Move revision between lifecycle statesです。
ライフサイクル状態の遷移を実行することを許可されている人物を、グローバルレベルでアクセスし構成します。
新しい接続されたワークスペースのために、この操作のデフォルトの権限設定は次のとおりです。
-
管理者
-
コラボレータ
-
ライブラリ担当者
-
マネージャ
ほとんどの場合、これらのデフォルトのアクセス許可設定で問題なく、特別な場合にのみ変更する必要があります。
必要に応じて追加の権限を定義します（Addボタンをクリックしてください）。このグローバルレベルでの状態遷移権限は、次のエンティティに割り当てることができます：
ユーザーおよび定義されたグループの管理は、ワークスペースのブラウザベースのインターフェースを使用して行われます。これは外部ブラウザから行うことができます。詳細情報については、「ワークスペースメンバーシップの管理」（Altium 365 Workspace、Enterprise Server Workspace）を参照してください。
ローカル状態遷移許可
特定の状態遷移に対する権限は、現在、State Transition Propertiesダイアログで構成されているライフサイクル定義の該当するStates and Transitions領域からアクセスされる関連付けられたEdit Lifecycle Definitionsダイアログで定義されています。
トランジションのプロパティを編集するには、それを選択してから、右端にあるコントロールをクリックします。
編集中の状態遷移のための権限を定義するアクセス制御。
State Transition Permissionsフィールドを使用して、トランジションに使用するパーミッション コントロールのタイプを選択します。次の 2 つのオプションが用意されています：
-
Controlled – このタイプでは、1人または複数のユーザーおよび/またはグループの指定を通じて、誰がこの遷移を実行できるかを正確に絞り込むことができます。このタイプのローカル権限制御は、グローバルレベルで設定された権限と組み合わせて使用されます（権限の適用方法を参照）。以下の領域のコントロールを使用して、許可されるエンティティを適宜定義してください。デフォルトでは、Anyoneエンティティが追加されており、これはこのローカルレベルですべてのユーザーが遷移を実行することを許可されていることを意味します。
特定のユーザーやグループを設定するには、まずAnyoneエンティティを選択してから削除します。その後、Addボタンに関連付けられたメニューから必要に応じてユーザーまたはグループを追加できます。Search for UsersやSearch for Roleを使用して、それぞれ必要なユーザーやグループを見つけます。
Controlled権限を使用すると、誰でもアクセスできる状態から指定されたユーザー/グループのみに切り替えることができます。
-
Using Approvals – このタイプでは、標準ユーザーがこの状態遷移を実行するようにリクエストできます。リクエストは、定義された承認グループに個別またはグループを通じて追加された1人以上のユーザーによって処理されます。そのようなグループの任意のメンバーが、遷移リクエストを承認または拒否できます。さらに、複数の承認グループを定義して順序付けすることもできます。これにより、複数レベルの承認が可能になります。
以下のコントロールを使用して、承認グループを適宜定義します。デフォルトでは、空の承認グループが1つ追加され、準備が整います – New Approval Group。これは、Addボタン（または領域の右クリックメニュー）に関連付けられたメニューからEdit Approval Group Nameコマンドを使用して必要に応じて名前を変更できます。
選択した承認グループに必要に応じてユーザーまたはグループを追加できます。Addボタン（または領域の右クリックメニュー）に関連付けられたメニューから。Search For UsersダイアログやSearch For Roleダイアログを使用して、それぞれ必要なユーザーやグループを見つけます。メニューからMove UpおよびMove Downコマンドを使用して複数の承認グループを順序付けします – 承認は上から下へ行われます。
Using Approvalsでは、非管理ユーザーはすべて遷移をリクエストする必要があり、定義された承認グループのユーザーによって対応されます。
権限の適用方法
権限の適用方法は、状態遷移レベルで選択および設定された権限制御のタイプによって異なります：
-
Controlled Permissions – ユーザーが状態遷移を実行できるようにするためには、以下の条件が満たされている必要があります：
-
グローバルレベルでMove revision between lifecycle states（Edit Operation Permissionsダイアログで定義）の権限を持っている必要があります。
-
この特定の状態遷移に対してローカルレベルで権限を持っている必要があります。
-
アイテムリビジョンのライフサイクル状態が遷移されている場合、コラボレーターである必要があります（つまり、編集権を持っている必要があります）。
これら3つの条件はAND条件です – 1つでも満たされていない場合、その特定の遷移を実行することはできません。
非管理ユーザーの場合、デフォルトの権限設定（グローバルレベルでのCollaborator、およびローカル状態遷移レベルでのAnyone）は、必要なアイテムリビジョンのコラボレーターにユーザーをするだけで、すべての条件を満たすことを意味します。その後、重要な遷移については、ローカル状態遷移レベルで権限を厳しくすることで、どのコラボレーターでも遷移を実行できないようにすることができます。
-
Using Approvals – すべての非管理ユーザーは承認システムを使用して状態遷移を実行するリクエストを送信する必要があります。承認システムでは、ユーザーがグローバルレベルで状態遷移を行う権限を持っている必要はなく、アイテムリビジョンのコラボレーターである必要もありません。
ユーザーがアイテムリビジョンのコラボレーターである必要はありませんが、それが共有されていない場合、ワークスペースでそれを見ることはできません。
ワークスペース管理者は、ローカルに定義された状態遷移権限に関係なく、常にアイテムリビジョンを異なる状態間で遷移させることができます。
段階とリビジョン命名スキームのレベルを関連付ける
リビジョンとライフサイクルの状態は、Itemビューの適用される右クリックメニューまたはExplorerパネルのLifecycleアスペクトビュータブからインクリメントできます。新しいリビジョンを確立し、ライフサイクルを昇進させることは、異なる理由で行われる完全に別の作業であり（設計変更がある場合には新しいリビジョンが、新しいライフサイクル状態はそのアイテムリビジョンの使いやすさの向上を反映します）、相互に関連しています。
高度な管理スタイルに基づくライフサイクル定義では、定義された段階は、使用されているリビジョン命名スキームのリビジョンレベルにリンクできます。これをEdit Lifecycle Definitionsダイアログの下部にあるオプションを使用して行ってください。
ステージをリビジョンレベルにリンクするオプション。
これによりライフサイクルステージとリビジョンレベルとの関係が生まれます。つまり、アイテムリビジョンのライフサイクルがインクリメントされて、あるステージの状態から別のステージの状態に移動する際、右クリックメニューにある利用可能なリビジョン変更タイプコマンドも変わるということです。
デフォルトのライフサイクル定義Sample - Structured Lifecycle With Approvalsと、3レベルのリビジョン名付けスキーム（リビジョン、プロトタイプ、モデルのレベル）。アイテムリビジョンがNew From Design状態にある場合、最初の段階では、右クリックメニューのリビジョンタイプのオプションには、新しいリビジョンの設定、新しいプロトタイプ、および新しいモデルが含まれます。
ライフサイクルがインクリメントされてIn Prototypeの段階に達した場合、第二段階に移行します。それを右クリックすると、利用可能なリビジョンタイプのオプションには新しいプロトタイプを確立するか、新しいモデルが含まれています。つまり、新しいリビジョンを開始するオプションはありません。この動作は直感的に期待されるもので、デザインがプロトタイプに進展した場合、デザイン変更が必要なら、新しいプロトタイプが必要になりますし、その変更の範囲によっては新しいモデルが必要になることもあります。
アイテムリビジョンがIn Productionの状態に達すると、第三段階では新しいモデルを確立するためのリビジョンタイプのオプションが再び期待通りにのみ利用可能になります。
リンクされた場合、リビジョンタイプのコマンドは、アイテムリビジョンのライフサイクル状態が定義されたさまざまな段階を進むにつれて変更されます。
定義を保存する
新しいライフサイクル定義が追加された場合、または既存のライフサイクル定義が何らかの形で変更された場合、そのライフサイクル定義は保存されなければなりません。実際の「保存」コントロールは存在しませんが、これを実行するためのコントロールは用意されています：
いずれにせよ、接尾辞は削除され、新しい（または変更された）定義がワークスペースで利用可能なライフサイクル定義のセットの一部として利用できるようになります。
ダイアログのメイン 
ボタンを使用すると、ダイアログを開いたままバッチスタイルの「保存」ができます。
OKボタンをクリックする前に、ライフサイクル定義が確実に追加されているか、変更が適用されていることを確認してください。定義を「保存」せずにこれを行うと、ダイアログが閉じられ、変更が失われます。さらに、ライフサイクル定義の最初の状態だけでなく、複数の状態が定義されている場合、それらの状態を効果的に接続するための遷移を定義する必要があり、そうでないと変更を適用できません。エラーダイアログはこの状況を示し、「到達不可能」な状態をリスト表示します。
Edit Lifecycle Definitionsダイアログを再オープンすると、定義のコレクションは名前順に、左から右に昇順のアルファベット順で表示されます。
明確で透明な監査トレイルを促進する精神で、誰が何を、いつ変更したかの詳細が、ライフサイクル定義が最後に変更された日時として、タブの右下に提供されています。
ライフサイクル定義が最後に変更された時期と、誰によって変更されたかを特定すること。
アクティブな定義に変更を適用する前の任意の時点で、変更はその定義のタブの右上にあるResetコントロールをクリックすることで完全に「元に戻す」ことができます。
定義の改名
この機能は、ワークスペースの管理者権限を持つユーザーのみ利用可能です。
既存の使用中のライフサイクル定義を再命名するには：
-
アクティブな接続されたワークスペースのEdit Lifecycle Definitionsダイアログにアクセスします。
-
名前を変更する必要がある定義のタブをクリックしてください。
-
Definition Nameフィールドの名前を変更します。
ライフサイクル定義の名称変更の例と、その定義をすでに使用しているアイテムのプロパティの変更を検証すること。
定義のコピー
新しいライフサイクル定義を一から作成する必要はありません。ライフサイクル定義の編集ダイアログでは、既存の定義をすばやくコピーすることができます。そのためには：
-
コピーする必要があるライフサイクル定義をアクティブな定義として設定します。
-
その定義のタブの右上にあるMake a copyコントロールをクリックします。
-
定義の正確なコピーが作成され、初期のデフォルト名New Lifecycle Definitionで新しい定義が作成されます。必要に応じて名前を変更してください。
-
新しい定義を実際に保存するために、Add Definitionコントロール（またはメインのボタン）をクリックします。
定義の削除
既存のライフサイクル定義を削除するには、それを選択してEdit Lifecycle Definitionsダイアログでアクティブな定義にし、その定義のタブの右上にあるDeleteコントロールをクリックします。
ワークスペース内のアイテムで現在使用されているライフサイクル定義は削除できません。
ライフサイクル定義の永久削除は、ダイアログのメインボタン（またはOKをクリック）をクリックすることで行われます。これに先立ち、削除操作はダイアログの下部にある
ボタンをクリックすることで元に戻すことができます。
ライフサイクル定義の削除操作は元に戻すことができます。
定義のエクスポートとインポート
ユーザー定義のライフサイクル定義は、それらが定義されている接続されたワークスペースでのみ使用できます。ライフサイクル定義の編集ダイアログには、定義をワークスペース間で移植するためのエクスポートとインポートの機能があります。
ライフサイクル定義はライフサイクル定義ファイル（*.definition）に保存されます。
ライフサイクル定義をエクスポートするには、そのタブの右上にあるExportコントロールをクリックします。続くライフサイクル定義の保存ダイアログを使用して、ファイルをどこに、どの名前で保存するかを決定します。
ライフサイクル定義をインポートするには、
ボタンをクリックしてライフサイクル定義の編集ダイアログの下部にあります。必要なライフサイクル定義ファイルを参照して開くためにライフサイクル定義を開くダイアログを使用します。ライフサイクル定義は、ワークスペースで利用可能な既存のライフサイクル定義のリストに追加されます。
インポートされたライフサイクル定義は、'+'サフィックスを伴う新しい定義として表示されます。その名前は定義ファイル内で定義された名前であり、ファイル自体の名前ではありません。ダイアログのメインボタンまたはAdd Definitionコントロールをクリックして「保存」されていることを確認してください。
一部の事前定義された例のライフサイクル定義ファイルは、デフォルトのAltium Designerインストールの\Program Files\Altium\AD<Version>\System\EDMSTemplatesフォルダーで利用可能です。
ライフサイクル定義の使用制御
特定のアイテムタイプが使用できる特定のライフサイクル定義については、各定義を定義する際にグローバルレベルで定義および有効化することにより制御できます。この機能が有効になっている場合、特定のアイテムタイプのライフサイクル定義を選択するときに、許可された定義のみが利用可能になります。これにより、特定のタイプの作成されたアイテムが必要とするライフサイクル定義のみを使用するという追加の制御レベルを得ることができます。
制御はContent Typesダイアログ内で行われます。アクセスを構成したい特定の定義のタブをクリックし、次に定義のタブの右上にあるContent Typesリンクをクリックします。
Content Typesダイアログへのアクセス – どのコンテンツタイプが構成されているライフサイクル定義を使用できるかを決定するためのコマンドセンター。
Content Typesダイアログは、アクティブな接続されたワークスペースで作成できる（ユーザーによって、またはシステムによって）すべてのサポートされているコンテンツタイプをリストします。リストの上にあるオプション – Control Lifecycle Definition per Content Type – は、その特定の定義に対してこの機能がアクティブ（有効）かどうか（無効）をグローバルに制御するためのものです。このオプションを有効にし、その定義を使用したい各コンテンツタイプの関連するUseオプションを有効にします。
Workspaceプロジェクトを作成するには、少なくとも1つのライフサイクル定義でProjectコンテンツタイプのUseオプションを有効にする必要があります。
高度なライフサイクル管理モードとシンプルなライフサイクル管理モードの切り替え
既存のライフサイクル定義をAdvancedライフサイクル管理スタイル（状態、状態遷移、ステージ）からSimple管理スタイル（状態と状態遷移のみ）に切り替えることができます。Simpleオプションを有効にすると、Confirm Merge Statesダイアログが表示されます。このダイアログを使用して、切り替えを次のように処理する方法を決定します。
ライフサイクル管理のスタイルを、他のステージでの状態（および状態遷移）の扱いを制御しながら、AdvancedからSimpleに切り替えます。
状態遷移承認要求
次のセクションでは、承認システムを使用して、ワークスペースの非管理者ユーザーが特定の状態遷移を実行できるようにするさまざまな側面について詳しく見ていきます。
リクエストの作成（承認のリクエスト）
Altium Designer内での状態遷移の承認要求は、必要なアイテムリビジョンのLifecycleアスペクトビュー（Explorerパネル内）または詳細Itemビューのグラフィカルライフサイクル領域から実行されます。リビジョンのライフサイクルを右クリックし、遷移を要求するコマンドを選択します。Confirmダイアログが表示され、要求を行う理由としてメモを入力できます。これにより、承認グループのメンバーがあなたの要求を承認するかどうかの検討に役立ちます！要求の作成を実行するにはYesをクリックします。
状態遷移を要求し、あなたのケースを裏付けるために役立つメモを追加してください。
作成時に、その状態遷移に適用される承認グループのメンバーは、メール通知機能が有効になっている場合、メール通知を受け取ります。
メール通知機能の構成は、ワークスペースのブラウザーインターフェースのメール通知ページ（Admin – Settings – Email Notifications）でワークスペース管理者によって行われます。
承認リクエストの表示
状態遷移要求の発信者（リクエスター）と、その状態遷移の適用承認グループで定義されたユーザー（アプローバー）の両方に対して、保留中の要求は専用のApproval Requestsフォルダを使用してExplorerパネルを通じて提示されます。
Approval Requestsフォルダ内の承認リクエストの例で、リクエスタ（サイモン・エンティスト）と特定の状態遷移のための定義された（初期）承認グループのメンバーの一人（デス・アイグナー）が閲覧したものです。
Approval Requestsフォルダ名の横にある数字は、保留中のリクエストの数を示しています。Show Approved Requestsを表示するオプションが有効になっている場合（
メニューから）、この数字は合計（保留中 + 承認済み）を反映します。
各承認要求について以下の情報が提示されます：
-
Item Revision – リクエストが行われている特定のアイテムのリビジョン。
-
Requested By – リクエストの発信者（リクエスター）。ここに入力するのはユーザーのユーザー名です。
-
Requested At – リクエストが作成された日時。
-
Status – リクエストの現在の状態。これは以下のいずれかの状態である可能性があります：
-
Transition – このアイテムのリビジョンに対して要求されている特定の状態遷移。
-
Request Note – リクエスターによってリクエストが行われた際に追加されたメモ。
-
Action Forward – ここに示されているコントロールは、保留中のリクエスト（状態がAwaitingのもの）のみのものであり、コントロールは次のように2つの当事者に合わせて異なります。
-
Action Backward – ここに示されているコントロールは、保留中のリクエスト（状態がAwaitingのもの）のみのものであり、コントロールは次のように2つの当事者に合わせて異なります。
アイテムリビジョンのライフサイクル（Lifecycleアスペクトビュー内）に対する右クリックメニューからも、承認リクエストに対するアクションベースのコマンドが利用可能です。
ページの中央セクションは、承認情報の提示に使用されます - 詳細については、
承認情報ストリームセクションを参照してください。
リクエストの処理
前のセクションで簡単に説明したように、リクエスターと承認者はそれぞれが取れるアクションがあります。以下の折りたたみセクションでは、それぞれのアクションをより詳しく見ていきます：
リマインド
承認を待っているがまだ得られていない場合、リクエスターが取れるアクションです。これは、誰かを催促するか、フォーラムの投稿を再度上げることに相当します - 言い換えれば、適用される承認グループの中でアクションを取る必要があることを礼儀正しくリマインドする方法です。承認リクエストに関連付けられたRemindコントロールをクリックします。承認が行われるように緊急性を高めるかもしれないメモを入力できるConfirmダイアログが表示されます。リマインダーを実行するためにYesをクリックすると、その状態遷移のための適用される承認グループのメンバーは、メール通知を受け取ります - メール通知機能が有効になっている場合。
Remindアクションの使用例。
承認
適用される承認グループのメンバーが、そのリクエストを承認するために取れるアクションです。承認リクエストに関連付けられたApproveコントロールをクリックします。必要に応じてメモを入力できるConfirmダイアログが表示されます。Yesをクリックして承認を実行すると、その状態遷移のリクエスターはメール通知を受け取ります - メール通知機能が有効になっている場合。
Approveアクションの使用例。
承認グループが一つだけの場合、リクエストの承認により状態遷移が自動的に行われます。承認グループが複数ある場合、リクエストは次のグループのメンバーからの承認を待ちます。最初の承認グループの承認者が次の承認グループのメンバーでもある場合、その二番目のグループに対する承認は自動的に行われます。
拒否
承認グループのメンバーが、そのリクエストを拒否するために取れるアクションです。承認リクエストに関連付けられたRejectコントロールをクリックします。必要に応じて、リクエストが拒否された理由を示すメモを入力できるConfirmダイアログが表示されます。Yesをクリックして拒否を実行すると、承認リクエストは削除され、その状態遷移のリクエスターはメール通知を受け取ります - メール通知機能が有効になっている場合。
Rejectアクションの使用例。
キャンセル
承認を待っているが、その後リクエストをキャンセルすることに決めたリクエスターが取れるアクションです。たとえば、必要なライフサイクル状態への遷移を無効にする別の問題が見つかった場合などです。承認リクエストに関連付けられたCancelコントロールをクリックします。必要に応じてメモを入力できるConfirmダイアログが表示されます。Yesをクリックしてキャンセルを実行すると、承認リクエストは削除されます。
Cancelアクションの使用例。
承認情報ストリーム
リクエストが承認されると、その承認リクエストを閲覧する際に、ページの中央領域にも通知が利用可能になります。この情報には、以下の要素が含まれます：
特定のアイテムリビジョンに対する承認フローの例で、リクエスターが見たものです。この場合、承認は二つの異なる承認グループのメンバーから承認を得るという二段階の承認を通過する必要がありました。
そのような承認情報は、承認されたステータスを持つApprovedリクエスト、またはAwaitingのステータスを持つ承認リクエストであり、複数の関連承認グループの最初に承認されたものでのみ利用可能です。
次の人々がこの情報を見ています：
アイテムリビジョンの可視性と適用性の制御
ライフサイクル定義のために各個別の状態を設定する際には、そのライフサイクル定義を使用し、その状態に入るアイテムのリビジョンの可視性や適用性を制御する追加の状態属性を定義する能力があります。適用性の観点から、プロジェクト違反レポートも構成され、適用外の状態にあるリビジョンを持つデザインで使用されているワークスペースアイテムを検出してフラグを立てることができます。これにより、リリース前に問題を把握し回避することができます。
特定の状態におけるアイテムのリビジョンが表示可能かつ適用可能であるかを判断するためのコントロールは、State Propertiesダイアログにあります。Edit Lifecycle Definitionsダイアログの中から必要な状態のために、このダイアログにアクセスするには、親ライフサイクル定義内の状態のエントリをダブルクリックするか、そのエントリを選択して表示される編集アイコン (
)をクリックします。
その状態に入るアイテムリビジョンの可視性および/または適用性を制御するために、状態レベルで定義された属性を使用します。
二つの選択肢は次の通りです：
-
Visible in Vault panels – このオプションが有効になっている場合、親ライフサイクル定義を使用したアイテムの改訂が、このライフサイクル状態に設定されると、Explorerパネルに表示されます。このオプションが無効になっている場合、改訂は非表示になります。非表示の改訂は、エクスプローラーパネル内でShow Hidden Revisionsコントロールを有効にすることで表示できます（非表示の改訂の表示を参照）。
-
Allowed to be used in designs – このオプションが有効である場合、この状態のアイテムリビジョンはデザインで使用することが許可されます。これは適用可能と見なされます。このオプションが無効の場合、この状態のアイテムリビジョンは有効に使用することができず、適用外（または非適用）と見なされます。その場合、プロパティパネルやItem Managerダイアログにフラグが付けられます（適用外リビジョンのフラグ付けを参照）。プロジェクトコンパイラも、このような事象を検出するように構成できます（コンパイル時の適用外リビジョン状態の検出を参照）。
Componentsパネルには、設計に使用が許可されているすべての最新のコンポーネントの改訂版が表示されます。たとえそれらのコンポーネントがVisible in Vaultパネルオプションが無効になっている状態に入った場合でもです。LifeCycleフィルタを使用して、特定の状態（または状態）にあるコンポーネントを検索することができます。
隠された改訂を表示
ライフサイクル状態に入るアイテム修正がVisible in Vault panels属性が無効になっている場合、その修正はデフォルトでExplorerパネルに表示されません。そして、それがアイテムの最新修正である場合、そのアイテムの全エントリは事実上表示されなくなります。この可視性状態は、状態レベルで定義されており、Explorerパネルでブラウズする際にすべてのアイテムに対してグローバルにオーバーライドできます。現在表示されていないすべてのアイテム修正を表示するには、パネルのItems領域の右上にあるコントロールをクリックし、関連するメニューでShow Hidden Revisionsオプションを有効にしてください。
Explorerパネルでコンテンツを閲覧しているときに、隠されたアイテムの修正を表示します。画像にカーソルを合わせると結果が表示されます。
不適用な改訂のフラグ
通常、非表示に設定されたライフサイクル状態（Visible in Vault panelオプションが無効）は、適用不可にもなります（Allowed to be used in designsオプションも無効）。たとえば、現在ObsoleteまたはDepracatedとされているコンポーネントの改訂版は、最新のデザインスピンには存在すべきではありません！このような状態に入ったアイテムの改訂版を隠すことは一つのことですが、たとえばコンポーネントが見えない場合、配置することはできません。しかし、デザイン内でそのようなアイテムの改訂版のインスタンスを既に使用しているか、隠された改訂版を表示しているために、適用不可の改訂版をうっかり配置してしまうことがあるかもしれません！
心配しないでください。コンパイレーション時に不適用状態のコンポーネントアイテムリビジョンをキャッチすることを除けば（次のセクションを参照）、デザインソフトウェア内でアイテムリビジョン（コンポーネントと管理シート）の適用性を手動で確認できます。これは、アイテムのプロパティをブラウジングする際のPropertiesパネル、またはアイテムマネージャーを使用することで実現されます。
-
Properties panel – このパネルを使用してコンポーネントまたは管理された回路図シートのリビジョンの配置インスタンスのプロパティをブラウズする際、リビジョンステータスエントリの右側に表示が出ます。リビジョンが適用不可の状態（設計で使用することが許可されていない）である場合、エントリにはNot applicableと表示されます。リビジョンが適用可能な状態（設計で使用することが許可されている）である場合、エントリにはそのリビジョンが最新であること（Up to date）またはそうでないこと（Out of date）を反映します。
コンポーネントの修正の配置されたインスタンスに対するプロパティレベルでの不適用性を反映し、管理された回路図シート。
-
Item Manager – Item Managerダイアログ（Tools » Item Manager）では、Revision Statusフィールドに表示される情報が示されます。リビジョンが不適用状態（設計に使用することが許可されていない）である場合、エントリにはNot applicableと表示されます。リビジョンが適用状態（設計に使用することが許可されている）である場合、エントリはそのリビジョンが最新であること（Up to date）またはそうでないこと（Out of date）を反映します。
コンポーネントの改訂版の配置インスタンスと管理された回路図シートに対するItem Manageダイアログを通じて、適用不可能性を反映しています。
-
PropertiesパネルやItem Managerダイアログで利用可能なコントロールを使用して、適用可能な状態にあるアイテムの後のリビジョンを選択するか、もしそれが不可能であれば（アイテムが一般には設計用ではない場合）、別のアイテムの適用可能なリビジョンを選択してください。
-
コンポーネントアイテムリビジョン(詳細を学ぶ)のライフサイクル状態を変更する際、Altium Designerは、その参照されている子アイテムリビジョン（テンプレートや参照モデル）が適用可能な状態にあるかどうかを確認します。そうでない場合、状態遷移のステータスは子アイテムリビジョンが適用不可能な状態にあることを示します。
プロジェクト検証における適用不可能な改訂状態の検出
コンポーネントアイテムリビジョンの設置されたインスタンスについて、これらのリビジョンの状態の適用性は、プロジェクト検証の一環として確認できます。この確認の核心は、コンポーネントリビジョンが不適用状態違反タイプを持つことであり、これはコンポーネントに関連する違反のカテゴリの一部です。このチェックの報告モードをProject OptionsダイアログのError Reportingタブで設定します。
この違反タイプのデフォルトのReport Modeは 
です。設計要件に合わせて修正してください。
プロジェクトの検証には、適用できない改訂状態にあるコンポーネントに関する違反のチェックが含まれます。配置されたコンポーネントアイテムの改訂のライフサイクル状態が設計目的で許可されていないと指定されている場合、違反が発生します。
コンパイラエラーと警告が回路図に表示するように設定されている場合（設定はPreferencesダイアログのchematic – Compilerページで行います）、問題のあるオブジェクトの下には色付きの波線が表示されます。また、通知はMessagesパネルに以下の形式で表示されます：
Component <Designator> <Comment>: Component revision has inapplicable state,
where:
例外違反（影響のため致命的エラーに設定）
注意すべき事項：
-
配置されたコンポーネントが、配置された接続ワークスペースとの接続を失うと、例えばそのワークスペースが切断された場合や、ワークスペースからサインアウトされた場合、Component revision has inapplicable stateチェックに違反します。これはメッセージパネルに反映され、次の形式のエントリが表示されます:Component <Designator> <Comment>: Can't perform revision status validation: Failed to connect to server。
-
設計リリースプロセス中に設計内で不適切に使用されているコンポーネントをキャッチすることもできます。全体のリリース検証体制にコンポーネント状態チェックを追加して構成してください。詳細については、コンポーネントステータスの検証を参照してください。
AI-localized