作業スペースにおけるライフサイクルの定義

接続されたWorkspace内の各アイテムは、一連のリビジョンで構成されます。データが変更され、コミット、アップロード、またはリリースされるたびに、新しいリビジョンを使用して新しいデータを格納します。したがって、リビジョンは、変更に伴うアイテムの進捗を表します。言い換えると、アイテムが表すデータの実体が変更された場合は、その変更を反映するためにリビジョンを上げる必要があります。

アイテムのどのリビジョンについても、その現在の状態、つまり「ライフサイクル」のどの段階に達しているかを示すことも重要です。この状態は、アイテムリビジョンのLifecycleと呼ばれます。

ライフサイクルを使用することで、企業はビジネスの観点から、社内の方針や業務慣行に従ってアイテムを管理できます。このライフサイクル情報により、リリース済みの設計「ビルディングブロック」の再利用を検討する設計者から、基板の製造と実装に必要なデータを扱うサプライチェーン担当者まで、Workspace内のアイテムを使用する人は、アイテムのリビジョンが「ライフサイクル」のどの段階に達しているか、したがってどの用途に安心して使用できるかを一目で確認できます。

ライフサイクルのモデル化

組織によって、設計アイテムのライフサイクルのモデル化やラベル付けの方法は多少異なりますが、基本的な流れは共通しています。たとえば、製品の一般的なライフサイクルは、設計のアイデアから始まり、試作を経て量産に移行し、やがて廃止されて製造や販売が終了する、といったものです。

設計内のすべてのコンポーネントのライフサイクル状態情報を使用することで、設計を上位の状態に移行できるのは、移行先の状態が設計内で最も低い状態のコンポーネントと同等以下である場合に限られるようにできます。たとえば、設計が量産に移行できる段階に達していても、設計内のすべてのコンポーネントも量産状態になっている場合にのみ、移行を許可する必要があります。つまり、まだIn Prototype（またはNew From Design）にあるコンポーネントは、設計全体をそのレベルに移行する前に、In Productionに移行させる必要があります。

多くの場合、設計アイテムのリビジョンは、さまざまなライフサイクル状態を順番に進んでいきます。ただし、それが唯一の経路とは限りません。たとえば、試作段階に達する前に破棄されるアイテムリビジョンもあります。接続されたWorkspaceでは、アイテムのリビジョンが移行できる状態は、ライフサイクル定義に含まれるTransitionテーブルで定義されます。

接続されたWorkspaceは、SimpleとAdvancedという2つのレベルのライフサイクル管理をサポートしています。これらは基本的に管理方式を決定するものであり、その方式に基づいてライフサイクル定義を構築します。シンプル管理方式に基づくライフサイクル定義には、状態と状態遷移のみが含まれます。詳細管理方式に基づくライフサイクル定義では、状態をさらに、定義されたステージにグループ化できます。

状態、ステージ、遷移

Related page: アイテムの詳細ビューへのアクセス

アイテムリビジョンのライフサイクルにおける各時点は、Stateと呼ばれます。たとえば、In Productionです。アイテムのリビジョンが状態を変更することをTransitionと呼び、移行先は必ず別の状態になります。

詳細管理方式に基づくライフサイクル定義では、状態をStagesにグループ化できます。ステージを使用すると、アイテムのリビジョンが開発のどの段階にあるかを示すラベルを作成できます。たとえば、Design、Prototype、またはProductionなどです。

状態を3つのステージにグループ化したライフサイクル定義の例。

下の画像は、Model、Prototype、Revisionという3階層のリビジョン命名スキームを使用するアイテムの、詳細なItemビューの一部です。各モデルは独立したブロックとして表示されます。各モデル内では、それぞれの試作がサブブロックになっています。各試作の下には、そのモデル／試作のリビジョンが表示され、さらに各リビジョン内には、そのリビジョンが経てきた各状態が表示されます。

アイテムの各リビジョンにおけるライフサイクル状態の例。

デフォルトのライフサイクル定義

接続されたWorkspaceには、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ダイアログでライフサイクル定義を表示および管理できます。現在サインインしている接続先Workspaceのこのダイアログにアクセスするには、次の手順を実行します。

1. PreferencesダイアログのData Management – Serversページを開きます。
2. アクティブなサーバーの項目の右端にあるPropertiesコントロールをクリックします。
3. 表示されるメニューからLifecyclesコマンドを選択します。

アクティブな接続先Workspaceのライフサイクル定義は、Altium DesignerのEdit Lifecycle Definitionsダイアログで作成および編集します。

新しい定義の追加

新しいライフサイクル定義を作成するには、Edit Lifecycle Definitionsダイアログの下部にあるボタンをクリックします。ダイアログに新しいタブが表示され、設定できるようになります。

独自のカスタムライフサイクル定義を作成します。

定義の設定

ライフサイクル定義のタブ内にあるコントロールを使用して、必要に応じて定義を設定します。

まず、Definition Nameフィールドに定義のわかりやすい名前を入力します。入力した名前はタブに即座に反映されます。

Lifecycle Managementコントロールを使用して、ライフサイクル管理のスタイルをSimpleまたはAdvancedから選択します。シンプルスタイルでは、StatesとState Transitionsのみを使用します。高度なスタイルでは、状態をグループ化するStagesを定義できます。

ライフサイクル定義の名前とスタイルを指定します。

初期状態

Initial State of Revisionsフィールドを使用して、アイテムリビジョンの開始状態を指定します。これは、リビジョンにリリース済みデータが含まれていない状態、いわば「リリース前の状態」です。デフォルトでは、この状態にはPlannedという名前が付いています。変更するには、リンクをクリックし、State Propertiesダイアログで名前、説明、文字色、背景色を設定します。

リビジョンの初期状態を設定します。

ステージ

ライフサイクル管理のスタイルとしてAdvancedを選択すると、必要なステージを追加および定義するためのコントロールが使用可能になります。デフォルトではDesign -という名前のステージが1つ用意されており、さらに2つのステージを追加できます。ステージを追加するには、Add Stageリンクをクリックします。

それぞれのStage Nameフィールドに直接入力して、必要に応じてステージ名を設定します。

必要に応じてステージを追加します。ステージを使用して状態をグループ化することで、より充実した構造的なライフサイクル定義を作成できます。

状態

次に、ライフサイクル定義に必要な状態を追加します。シンプルスタイルの管理に基づくライフサイクル定義では、状態はフラットなリストになります。高度なスタイルの管理では、定義した各ステージに状態を追加する必要があります。

新しい状態を追加するには、状態リストの下にあるコントロールをクリックします。表示されるState Propertiesダイアログを使用して、状態の名前、説明、色属性を定義します。

ライフサイクル定義に状態を追加します。

State Propertiesダイアログのオプションとコントロール

プロパティ

• State Name - 状態の名前を指定します。
• Description - 状態の説明を入力します。
• Text Color - カラーボックスをクリックしてChoose Colorダイアログを開き、目的の文字色を選択します。
• Background Color - カラーボックスをクリックしてChoose Colorダイアログを開き、目的の背景色を選択します。

文字色のプレビュー

文字色のプレビューを表示します。

背景色のプレビュー

背景色のプレビューを表示します。

• Visible in Vault panels - このオプションを有効にすると、このライフサイクル定義を使用するアイテムのリビジョンが、このライフサイクル状態に設定されたときに Explorerパネル に表示されます。このオプションを無効にすると、リビジョンは両方の場所で非表示になります。ただし、ExplorerパネルのShow Hidden Revisionsコントロールを有効にすると、このオプションの設定を上書きして、非表示のリビジョンを表示できます。

• Allowed to be used in designs - このオプションを有効にすると、この状態のアイテムリビジョンを設計で使用できます。このリビジョンはApplicableと見なされます。このオプションを無効にすると、この状態のアイテムリビジョンは有効に使用できず、 Inapplicable （またはNot-applicable）と見なされます。ComponentモードのProperties panelおよびItem Managerダイアログで、その旨のフラグが付けられます。プロジェクトコンパイラーを設定して、このような使用箇所を検出することもできます。

  リビジョンの状態が Inapplicable（Not-applicable） に設定されているコンポーネントは、Componentsパネルに表示されないことに注意してください。

新しい状態はリストの末尾に追加されます。状態をクリックして選択し、状態リストの下にあるおよびコントロールを使用して、リスト内の目的の位置に移動します。

高度なスタイルのライフサイクル定義で状態を定義する場合は、状態をステージ間で移動するための追加コントロールが状態リストの下に表示されます。ステージの位置に応じて、必要に応じて状態を右側（）または左側（）のステージに移動します。

2つのステージからなるライフサイクル定義での状態定義の例。

遷移

最後に、異なる状態間の経路であるState Transitionsを定義します。状態をクリックして選択し、右端のコントロールをクリックして新しい状態遷移を追加します。表示されるState Transition Propertiesダイアログを使用して、遷移の名前、遷移先（次）の状態、メニューテキスト、権限を定義します。

状態遷移を追加します。

State Transition Propertiesダイアログのオプションとコントロール

プロパティ

• State Transition Name - 状態遷移の名前を入力します。
• State After - ドロップダウンを使用して、追加する状態遷移の後に続く状態を選択します。
• Menu Entry Text - アイテムビューの右クリックメニューに表示されるテキストです。このメニューから、対象のアイテムリビジョンに対してこの状態遷移を実行できます。パラメーター$RevisionId は、リビジョンのIDに置き換えられます。

状態遷移の権限

ドロップダウンを使用して、状態遷移の権限の設定方法を選択します。

• Controlled - デフォルトのサーバー権限に基づいて権限を制限するには、このオプションを選択します。
• Using Approvals - この特定の状態遷移に対して選択された権限を許可するには、このオプションを選択します。権限は、Add ボタンを使用して下の表に追加できます。

追加コントロール

• Add - ドロップダウンから次のオプションを選択します。
  • Add Approval Group - 承認グループを追加するには、これを選択します。新しいグループには、デフォルトでNew Approval Groupという名前が付けられます。名前は、以下で説明する Edit Approval Group Name コマンドを使用して編集できます。
  • Add Role - Search for Roleダイアログを使用してグループを追加するには、これを選択します。
  • Add User - Search for Usersダイアログを使用してユーザーを追加するには、これを選択します。
  • Edit Approval Group Name - 新しく追加した承認グループの名前を入力するダイアログを開くには、これを選択します。
  • Move Up - 現在選択されている項目を1つ上に移動するには、これをクリックします。
  • Move Down - 現在選択されている項目を1つ下に移動するには、これをクリックします。
  • Remove - 現在選択されているグループまたはユーザーを削除するには、これをクリックします。

Add コマンドは、State Transitions PermissionsでUsing Approvalsが選択されている場合にのみ使用できます。

• Remove - 現在選択されているグループまたはユーザーを削除するには、これをクリックします。

新しい遷移はリストの一番下に追加されます。遷移をクリックして選択し、状態リストの下にあるおよびコントロールを使用して、リスト内の目的の位置に移動します。

遷移先の状態が別のステージにある場合は、遷移先の状態と同じ色の矢印が表示され、そのことを示します。

2段階のライフサイクル定義で、状態と状態遷移をすべて定義した例。矢印はステージ間の遷移を示しています。

デフォルトのライフサイクルの状態と遷移の例

次の表は、デフォルトのSample - Structured Lifecycle With Approvalsライフサイクル定義で使用される状態と状態遷移の一覧です。

現在の状態	可能な遷移	次の状態	コメント
Planned	リリースの実行	New From Design	新規の未リリースのアイテムリビジョンはすべて、Planned状態から始まります。この状態のアイテムリビジョンは、ライフサイクルの状態を手動で変更することはできません。リリースのみが可能で、リリースすると自動的にNew from Designへ遷移します。
New from Design	試作準備完了に設定	Pending Prototype Approval	このアイテムリビジョンがリリースされ、現在はNew from Designであることを示します。試作に進む準備ができたら、Pending Prototype Approvalへ遷移できます。
	設計の中止	Abandoned	この段階でアイテムリビジョンが不要と判断された場合は、Abandonedにできます。
Pending Prototype Approval	試作の承認	In Prototype	アイテムリビジョンは、試作の承認を受ける準備ができています。承認されると、リビジョンはIn Prototype状態へ遷移します。
	試作の不承認	New From Design	アイテムリビジョンの試作が承認されなかった場合は、New from Designに戻ります。
Abandoned	設計の復元	New from Design	中止されたアイテムリビジョンは復元して、New from Designに戻すことができます。
In Prototype	生産準備完了に設定	Pending Production Approval	アイテムリビジョンはIn Prototypeです。通常、これは最初の実機試作品を組み立てる準備ができた段階の状態です。試作テストに合格したら、Pending Production Approvalへ遷移できます。
	設計段階に戻す	New from Design	アイテムリビジョンがテストに合格しなかった場合は、New from Designに戻す必要があります。
	試作の終了	Closed Prototype	アイテムリビジョンの開発をこれ以上進められない場合（たとえば、設計変更が必要で、新しいリビジョンを作成する必要がある場合）は、Closed Prototypeへ遷移させます。
Pending Production Approval	生産の承認	In Production	アイテムリビジョンは、生産の承認を受ける準備ができています。承認されると、リビジョンはIn Production状態へ遷移します。
	生産の不承認	In Prototype	アイテムリビジョンを生産に移行できない場合は、In Prototypeに戻すことができます。
Closed Prototype	試作の復元	In Prototype	Closed Prototypeは、これ以上開発を進められないと判断されたものです。継続が可能になった場合は、In Prototypeに戻すことができます。
In Production	試作段階に戻す	In Prototype	アイテムリビジョンが生産中であっても、何らかの理由で生産できなくなった場合は、In Prototypeに戻すことができます。
	非推奨にする	Deprecated	現在のリビジョンでアイテムの生産を停止する予定がある場合（たとえば、基板で使用している部品の入手が困難になってきた場合）は、Deprecatedへ遷移させます。
	生産中のアイテムを廃止	Obsolete	現在生産中のアイテムリビジョンを生産できなくなった場合は、直ちにObsoletedにできます。
Deprecated	非推奨のアイテムを廃止	Obsolete	Deprecatedは通常、既存の在庫を使用して生産を継続できるものの、そのアイテムリビジョン用の新しい部品は発注すべきではないことを意味します。状況が変わり、そのような在庫もなくなった場合は、リビジョンを廃止にできます。
	非推奨のアイテムを再有効化	In Production	DeprecatedのアイテムをIn Productionに戻します。
Obsolete	廃止されたアイテムを再有効化	In Production	ObsoleteのアイテムをIn Productionに戻します。
	廃止されたアイテムを非推奨に変更	Deprecated	ObsoleteのアイテムをDeprecatedに戻します。

ライフサイクルの状態間の遷移を制御する

接続されたWorkspaceでは、そのWorkspace内のアイテムリビジョンに対して、特定の状態遷移を実行できるユーザーを柔軟に設定できます。状態遷移とは、親アイテムに適用されるライフサイクル定義に従って、リビジョンをある状態から別の状態へ移行する操作です。Workspace管理者以外にも権限を付与しながら、一般ユーザー（管理者以外のユーザー）が特定のライフサイクル状態間で直接遷移を実行できないようにすることができます。権限は、Workspaceのグローバルな操作権限の一部としてグローバルレベルで指定できるほか、個々の状態遷移レベルでも指定できます。後者はグローバルレベルの設定と組み合わせて適用され、重要な遷移（たとえば、アイテムリビジョンをReady for Productionに設定する操作）の権限を細かく調整できます。

また、特定の状態遷移について、一般ユーザーに承認を申請させることもできます。この場合、これらのApproval Requestsは、1つ以上のApproval Groupsのメンバーとして指定されたユーザーに送信され、そのユーザーが確認して処理します。

さまざまなレベルで権限を制御することで、組織の方針に沿ったライフサイクル状態遷移の運用を定義できます。

権限は次の2つのレベルで定義できます。

• Globally – 定義されているすべてのライフサイクル定義の全遷移を対象に、状態遷移を実行できるユーザーやグループを定義します。
• Locally – 個々の状態遷移レベルで権限を指定します。

グローバルな状態遷移権限

グローバルな状態遷移権限は、Altium Designerの「操作権限の編集」ダイアログで定義および管理します。このダイアログには、Preferencesダイアログの「データ管理 – サーバー」ページからアクセスします。権限を確認または変更する接続済みWorkspaceについて、右側のPropertiesコントロールをクリックし、表示されるメニューからOperationsコマンドを選択します。

ここで対象となるWorkspaceの操作項目はMove revision between lifecycle statesです。

ライフサイクル状態遷移を実行できるユーザーを、グローバルレベルで確認および設定します。

新しく接続されたWorkspaceでは、この操作の権限はデフォルトで次のように設定されています。

• 管理者
• 共同作業者
• ライブラリ管理者
• マネージャー

必要に応じて権限を追加します（Addボタンをクリック）。このグローバルレベルの状態遷移権限は、次の対象に割り当てることができます。

•   管理者（定義済みのグループ）。
•   共同作業者（アイテム／リビジョンの編集権限を持つユーザー）。
•   所有者（リリース済みデータの場合、最初のアイテムを作成したユーザー）。
•   特定のユーザー定義グループ。
•   特定のユーザー。

ローカルな状態遷移権限

特定の状態遷移の権限は、対応する「状態遷移のプロパティ」ダイアログで定義します。このダイアログには、Edit Lifecycle Definitionsダイアログで現在設定しているライフサイクル定義の、該当するStates and Transitions領域からアクセスします。

遷移のプロパティを編集するには、クリックして遷移を選択し、右端のコントロールをクリックします。

編集中の状態遷移の権限を定義するためのコントロールにアクセスします。

State Transition Permissionsフィールドで、その遷移に適用する権限制御の種類を選択します。次の2つのオプションがあります。

• Controlled – 1人以上のユーザーや1つ以上のグループを指定して、この遷移を実行できる対象を厳密に絞り込めます。この種類のローカルな権限制御は、グローバルレベルで設定された権限と組み合わせて使用します（権限の適用方法を参照）。下の領域にあるコントロールを使用して、許可する対象を定義します。デフォルトではAnyoneが追加されており、このローカルレベルではすべてのユーザーに遷移の実行が許可されています。

  特定のユーザーやグループを設定するには、まずAnyoneを選択して削除します。その後、Addボタンに関連付けられたメニューから、必要に応じてユーザーまたはグループを追加できます。続いて表示されるSearch for UsersまたはSearch for Roleを使用して、それぞれ必要なユーザーまたはグループを検索します。

  
  Controlled権限では、誰でもアクセスできる設定から、指定したユーザー／グループのみにアクセスを許可する設定に切り替えられます。

• Using Approvals – 一般ユーザーであれば誰でも、この状態遷移の実行を申請できます。申請は、定義済みの承認グループに個別に、またはグループを通じて追加された1人以上のユーザーが処理します。承認グループのメンバーは誰でも、遷移申請を承認または却下できます。また、複数の承認グループを定義し、その順序を設定することもできます。これにより、多段階の承認が可能になります。

  下の領域にあるコントロールを使用して、承認グループを定義します。デフォルトでは、空の承認グループNew Approval Groupが1つ追加されています。この名前は、Addボタンに関連付けられたメニュー（または領域内の右クリックメニュー）のEdit Approval Group Nameコマンドを使用して、必要に応じて変更できます。

  Addボタンに関連付けられたメニュー（または領域内の右クリックメニュー）から、選択した承認グループに必要なユーザーまたはグループを追加できます。続いて表示されるSearch For UsersダイアログまたはSearch For Roleダイアログを使用して、それぞれ必要なユーザーまたはグループを検索します。複数の承認グループの順序は、メニューのMove UpコマンドとMove Downコマンドで設定します。承認は上から下の順に行われます。

  
  Using Approvalsでは、管理者以外のすべてのユーザーは遷移を申請する必要があり、定義済みの1つ以上の承認グループに属するユーザーがその申請を処理します。

権限の適用方法

権限の適用方法は、状態遷移レベルで選択および設定した権限制御の種類によって異なります。

• Controlled Permissions – ユーザーが状態遷移を実行するには、次の条件を満たす必要があります。
  • グローバルレベルでMove revision between lifecycle statesの権限が付与されていること（「操作権限の編集」ダイアログで定義）。
  • この特定の状態遷移について、ローカルレベルで権限が付与されていること。
  • ライフサイクル状態を遷移させるアイテムリビジョンの共同作業者であること（つまり、編集権限を持っていること）。
  これら3つの条件はAND条件で適用されます。1つでも満たされていない場合、そのユーザーは該当する遷移を実行できません。
  管理者以外のユーザーの場合、デフォルトの権限設定（グローバルレベルではCollaborator、ローカルの状態遷移レベルではAnyone）では、対象のアイテムリビジョンの共同作業者にユーザーを追加するだけで、すべての条件を満たせます。そのうえで、重要な遷移についてはローカルの状態遷移レベルで権限を制限することで、共同作業者であれば誰でも遷移を実行できるわけではないように設定できます。

• Using Approvals – 管理者以外のすべてのユーザーは、承認システムを使用して状態遷移の実行リクエストを送信する必要があります。承認システムでは、ユーザーがグローバルレベルで状態遷移の権限を持っている必要はなく、アイテムリビジョンの共同作業者である必要もありません。

  ユーザーはアイテムリビジョンの共同作業者である必要はありませんが、そのアイテムリビジョンがユーザーと共有されている必要があります。共有されていない場合、ユーザーはWorkspace内でそのアイテムリビジョンを表示できません。

ステージとリビジョン命名規則のレベルの関連付け

リビジョンとライフサイクルの状態は、Itemビュー、またはExplorerパネルのLifecycleアスペクトビュータブにある該当する右クリックメニューから進めることができます。新しいリビジョンの作成とライフサイクルの昇格は、それぞれ異なる理由で行う完全に別個の作業ですが（設計変更時には新しいリビジョンを作成し、アイテムリビジョンの利用可能性の向上を反映するには新しいライフサイクル状態に進めます）、互いに関連しています。

高度な管理スタイルに基づくライフサイクル定義では、定義したステージを、使用するリビジョン命名規則のリビジョンレベルに関連付けることができます。これには、Edit Lifecycle Definitionsダイアログの下部にあるオプションを使用します。

ステージをリビジョンレベルに関連付けるオプション。

これにより、ライフサイクルのステージとリビジョンレベルの間に関係が設定されます。つまり、アイテムリビジョンのライフサイクルが進み、あるステージの状態から別のステージの状態に移ると、右クリックメニューで使用できるリビジョン変更タイプのコマンドも変わります。

デフォルトのライフサイクル定義Sample - Structured Lifecycle With Approvalsと、3レベルのリビジョン命名規則（Revision、Prototype、Modelの各レベル）を例に考えます。アイテムリビジョンが最初のステージのNew From Design状態にある場合、右クリックメニューのリビジョンタイプの選択肢には、新しいRevisionの作成、新しいPrototypeの作成、新しいModelの作成が含まれます。

その後、ライフサイクルがIn Prototypeまで進むと、2番目のステージに移ります。この状態で右クリックすると、使用できるリビジョンタイプの選択肢は、新しいPrototypeの作成、または新しいModelの作成になります。つまり、新しいRevisionを開始する選択肢はありません。これは直感的にも自然な動作です。設計がPrototypeまで進んでから設計変更が必要になった場合は、変更の規模に応じて、新しいPrototype、場合によっては新しいModelが必要になるためです。

アイテムリビジョンが3番目のステージのIn Production状態に達すると、想定どおり、新しいModelを作成するリビジョンタイプの選択肢だけが使用可能になります。

関連付けを行うと、アイテムリビジョンのライフサイクル状態が定義済みの各ステージを進むにつれて、リビジョンタイプのコマンドが変化します。

定義の保存

新しいライフサイクル定義を追加した場合も、既存のライフサイクル定義を何らかの形で変更した場合も、そのライフサイクル定義を保存する必要があります。明示的な「保存」コントロールはありませんが、次の操作で保存できます。

• 新しいライフサイクル定義（末尾の「+」で識別）の場合は、定義のタブの右上にあるAdd Definitionコントロールを使用するか、ダイアログのメインのボタンをクリックします。
• 変更した既存のライフサイクル定義（末尾の「*」で識別）の場合は、定義のタブの右上にあるApply Changesコントロールを使用するか、ダイアログのメインのボタンをクリックします。

いずれの場合も末尾の記号が消え、新しい定義（または変更した定義）が、Workspaceで使用できるライフサイクル定義の一つとして利用可能になります。

誰が、何を、いつ変更したかを明確かつ透明に追跡できるように、各タブの右下にはライフサイクル定義の最終変更日時などの詳細が表示されます。

ライフサイクル定義の最終変更日時と変更者の確認。

定義の名前変更

使用中の既存のライフサイクル定義の名前を変更するには、次の手順を実行します。

1. 現在接続しているWorkspaceのEdit Lifecycle Definitionsダイアログを開きます。
2. 名前を変更する定義のタブをクリックします。
3. Definition Nameフィールドで名前を変更します。

ライフサイクル定義の名前を変更し、その定義をすでに使用しているアイテムのプロパティで変更を確認する例。

定義のコピー

新しいライフサイクル定義を最初から作成する必要はありません。Edit Lifecycle Definitionsダイアログでは、既存の定義をすばやくコピーできます。コピーするには、次の手順を実行します。

1. コピーするライフサイクル定義をアクティブにします。
2. 定義のタブの右上にあるコピーを作成 コントロールをクリックします。
3. 定義の完全なコピーが作成され、初期のデフォルト名がNew Lifecycle Definitionの新しい定義が作成されます。必要に応じて名前を変更します。
4. Add Definitionコントロール（またはメインのボタン）をクリックして、新しい定義を保存します。

定義の削除

既存のライフサイクル定義を削除するには、Edit Lifecycle Definitionsダイアログでその定義を選択してアクティブにし、定義のタブの右上にあるDeleteコントロールをクリックします。

ライフサイクル定義は、ダイアログのメインの ボタンをクリックする（または OK をクリックする）と完全に削除されます。それまでは、ダイアログ下部の ボタンをクリックして削除操作を元に戻すことができます。

ライフサイクル定義の削除操作は元に戻すことができます。

定義のエクスポートとインポート

ユーザー定義のライフサイクル定義は、その定義を作成した接続先の Workspace 内でのみ使用できます。Edit Lifecycle Definitions ダイアログにはエクスポート機能とインポート機能があり、Workspace 間で定義を移行できます。

ライフサイクル定義をエクスポートするには、そのタブの右上にある Export コントロールをクリックします。続いて表示される「ライフサイクル定義を保存」ダイアログで、ファイルの保存先とファイル名を指定します。

ライフサイクル定義をインポートするには、Edit Lifecycle Definitions ダイアログ下部の ボタンをクリックします。Open Lifecycle Definition ダイアログで、必要なライフサイクル定義ファイルを参照して開きます。そのライフサイクル定義が、Workspace で使用可能な既存のライフサイクル定義のリストに追加されます。

ライフサイクル定義の使用の制御

特定のライフサイクル定義を使用できる Item タイプは、各定義を作成する際にグローバルレベルで設定し、その制御を有効にすることができます。この機能を有効にすると、特定の Item タイプのライフサイクル定義を選択する際に、許可された定義のみが選択可能になります。これにより、特定のタイプの Item を作成する際に、必要なライフサイクル定義のみが使用されるよう、さらに細かく制御できます。

この制御は、Content Types ダイアログ内で行います。アクセスを設定する定義のタブをクリックし、そのタブの右上にある Content Types リンクをクリックします。

Content Types ダイアログへのアクセス。このダイアログで、設定対象のライフサイクル定義を使用できるコンテンツタイプを指定します。

Content Types ダイアログには、現在接続しているアクティブな Workspace で（ユーザーまたはシステムが）作成できる、サポート対象のすべてのコンテンツタイプが一覧表示されます。リストの上にある Control Lifecycle Definition per Content Type オプションでは、その定義に対してこの機能を有効にするか無効にするかをグローバルに制御します。このオプションを有効にしてから、その定義の使用を許可する各コンテンツタイプについて、対応する Use オプションを有効にしてください。

高度なライフサイクル管理モードとシンプルなライフサイクル管理モードの切り替え

既存のライフサイクル定義は、Advanced スタイルのライフサイクル管理（状態、状態遷移、ステージ）から、Simple スタイルの管理（状態と状態遷移のみ）に切り替えることができます。Simple オプションを有効にすると、Confirm Merge States ダイアログが表示されます。このダイアログで、切り替え時の処理を次のように指定します。

• Yes をクリック — ステージ1、2、3で定義されているすべての状態（および状態遷移）が、単一のフラットな状態リストに統合されます。
• No をクリック — ステージ2と3で定義されているすべての状態（および状態遷移）が削除されます。ステージ1（一番左のステージ）の状態（および状態遷移）のみが、単一のフラットな状態リストに残ります。

他のステージの状態（および状態遷移）の処理方法を指定して、ライフサイクル管理のスタイルを Advanced から Simple に切り替えます。

状態遷移の承認リクエスト

以降のセクションでは、Workspace の管理者権限を持たないユーザーが特定の状態遷移を実行できるようにする承認システムについて、その使用に関するさまざまな側面を詳しく説明します。

リクエストの作成（承認の申請）

状態遷移の承認申請は、Altium Designer の対象 Item リビジョンの Lifecycle アスペクトビュー（Explorer パネル内）、または詳細な Item ビューのグラフィカルなライフサイクル領域から行います。そのリビジョンのライフサイクルを右クリックし、遷移をリクエストするコマンドを選択します。Confirm ダイアログが表示され、リクエストの理由をメモとして入力できます。このメモは、承認グループのメンバーがリクエストを承認するかどうかを検討する際に役立ちます。Yes をクリックしてリクエストを作成します。

状態遷移をリクエストし、申請の根拠となる有用なメモを追加します。

リクエストが作成されると、その状態遷移に対応する承認グループのメンバーにメール通知が送信されます。ただし、メール通知機能が有効になっている必要があります。

承認リクエストの表示

状態遷移リクエストの作成者（Requester）と、その状態遷移に対応する承認グループに設定されているユーザー（Approver）の双方に対して、保留中のリクエストが Explorer パネルの専用の Approval Requests フォルダーに表示されます。

リクエスト者（Simon Entist）と、特定の状態遷移に対して設定された（初期の）承認グループのメンバーの1人（Des Igner）に表示される、Approval Requests フォルダー内の承認リクエストの例。

各承認リクエストには、次の情報が表示されます。

• Item Revision — リクエストの対象となる特定の Item リビジョン。
• Requested By — リクエストの作成者（リクエスト者）。ここにはユーザーのユーザー名が表示されます。
• Requested At — リクエストが作成された日時。
• Status — リクエストの現在のステータス。次のいずれかの状態になります。
  • Awaiting — リクエストは現在、1人以上の承認者による対応を待っています。
  • Approved – リクエストが承認されました。この状態になるのは、その遷移に対して定義されているすべての承認グループによる承認が完了した場合のみです。
• Transition – このアイテムリビジョンに対してリクエストされている具体的な状態遷移。
• Request Note – リクエスト時にリクエスト者が追加したメモ。
• Action Forward – ここに表示される操作コントロールは、保留中のリクエスト（ステータスがAwaitingのもの）にのみ使用できます。次のように、リクエスト者と承認者で使用できる操作が異なります。
  • Requester – リクエストを作成したユーザーは、そのリクエストをRemindできます。
  • Approvers – 承認グループ内のユーザーは、リクエストをApproveできます。
• Action Backward – ここに表示される操作コントロールは、保留中のリクエスト（ステータスがAwaitingのもの）にのみ使用できます。次のように、リクエスト者と承認者で使用できる操作が異なります。
  • Requester – リクエストを作成したユーザーは、そのリクエストをCancelできます。
  • Approvers – 承認グループ内のユーザーは、リクエストをRejectできます。

リクエストに対する操作

前のセクションで簡単に説明したように、リクエスト者と承認者の両方に、それぞれ実行できる操作があります。以下の折りたたみ可能なセクションでは、各操作について詳しく説明します。

リマインダー

この操作は、承認を待っているものの、まだ承認を得られていないリクエスト者が実行できます。相手に軽く声をかけたり、フォーラムの投稿を再び目立たせたりするのと同様に、該当する承認グループのメンバーに、承認または却下の対応が必要であることを丁寧に知らせる方法です。承認リクエストに対応するRemindコントロールをクリックします。Confirmダイアログが表示され、承認を急いでほしい旨などのメモを入力できます。Yesをクリックするとリマインダーが送信されます。メール通知機能が有効になっている場合、その状態遷移に該当する承認グループのメンバーにメール通知が送信されます。

Remind操作の使用例。

承認

この操作は、該当する承認グループのメンバーがリクエストを承認するために実行できます。承認リクエストに対応するApproveコントロールをクリックします。Confirmダイアログが表示され、必要に応じてメモを入力できます。Yesをクリックすると承認が実行されます。メール通知機能が有効になっている場合、その状態遷移のリクエスト者にメール通知が送信されます。

Approve操作の使用例。

承認グループが1つしかない場合、リクエストが承認されると状態遷移が自動的に実行されます。承認グループが複数ある場合、リクエストは次のグループのメンバーによる承認待ちになります。最初の承認グループの承認者が次の承認グループのメンバーでもある場合、2番目のグループの承認は自動的に行われます。

却下

この操作は、承認グループのメンバーがリクエストを却下するために実行できます。承認リクエストに対応するRejectコントロールをクリックします。Confirmダイアログが表示され、必要に応じて却下の理由などのメモを入力できます。Yesをクリックすると却下が実行され、承認リクエストが削除されます。メール通知機能が有効になっている場合、その状態遷移のリクエスト者にメール通知が送信されます。

Reject操作の使用例。

キャンセル

この操作は、承認を待っていたものの、その後リクエストを取り消すことにしたリクエスト者が実行できます。たとえば、別の問題が見つかったため、目的のライフサイクル状態に遷移する必要がなくなった場合などが該当します。承認リクエストに対応するCancelコントロールをクリックします。Confirmダイアログが表示され、必要に応じてメモを入力できます。Yesをクリックするとキャンセルが実行され、承認リクエストが削除されます。

Cancel操作の使用例。

承認情報ストリーム

リクエストが承認されると、その承認リクエストの閲覧時に、ページの中央領域でも通知を確認できます。この情報は次の要素で構成されます。

• Created At – 承認リクエストが承認された日時。
• Created By – リクエストを承認した、該当する承認グループのメンバー。ここには、そのユーザーのユーザー名が表示されます。
• Description – 自動生成されたメッセージと、承認時に承認者が追加したメモで構成されるエントリ。説明の自動生成部分は、承認の種類によって異なります。
  • Final approval（唯一の承認グループ、または最後の承認グループのメンバーによる承認）– task approved and completed。
  • Intermediate approval（最後ではない承認グループのメンバーによる承認）– task approved and assigned to next approval group <ApprovalGroupName>。

リクエスト者に表示される、特定のアイテムリビジョンの承認ストリームの例。この場合、遷移には2段階の承認（異なる2つの承認グループのメンバーによる承認）が必要でした。

この情報を閲覧できるのは、次のユーザーです。

• 状態遷移のリクエスト者。
• リクエストを最終承認するユーザー。したがって、複数の承認グループが関与する場合、この情報を閲覧できるのは、最終承認を行う最後の承認グループのメンバーのみです。中間段階の承認を行う承認グループのメンバーは、このストリームを閲覧できません。

アイテムリビジョンの表示と適用可否の制御

ライフサイクル定義の各状態を設定する際、そのライフサイクル定義を使用し、その状態に移行したアイテムリビジョンの表示と適用可否を制御する追加の状態属性を定義できます。適用可否に関しては、設計で使用されているWorkspaceアイテムのうち、リビジョンが適用不可の状態にあるものを検出してフラグを付けるように、プロジェクト違反レポートを設定することもできます。これにより、リリース前に問題を検出して回避できます。

特定の状態にあるアイテムリビジョンの表示可否や適用可否を指定するコントロールは、State Propertiesダイアログにあります。Edit Lifecycle Definitionsダイアログ内で、親のライフサイクル定義にある対象の状態のエントリをダブルクリックするか、そのエントリを選択して表示される編集アイコン（）をクリックすると、対象の状態のダイアログにアクセスできます。

状態レベルで定義した属性を使用して、その状態に移行するアイテムリビジョンの表示可否や適用可否を制御します。

次の2つのオプションがあります。

• Visible in Vault panels – このオプションを有効にすると、親のライフサイクル定義を使用するアイテムのリビジョンがこのライフサイクル状態に設定されたときに、Explorerパネルに表示されます。このオプションを無効にすると、リビジョンは非表示になります。非表示のリビジョンは、ExplorerパネルでShow Hidden Revisionsコントロールを有効にすることで、このオプションの設定にかかわらず表示できます（非表示のリビジョンの表示を参照）。
• Allowed to be used in designs – このオプションを有効にすると、この状態のアイテムリビジョンを設計で使用できます。このリビジョンはApplicableと見なされます。このオプションを無効にすると、この状態のアイテムリビジョンは設計で有効に使用できず、Inapplicable（または適用不可）と見なされます。PropertiesパネルおよびItem Managerダイアログでは、その旨が示されます（適用不可のリビジョンの表示を参照）。プロジェクトコンパイラも、このような状況を検出するように設定できます（コンパイル時の適用不可のリビジョン状態の検出を参照）。

非表示のリビジョンの表示

Visible in Vault panels属性が無効になっているライフサイクル状態に移行したアイテムリビジョンは、デフォルトではExplorerパネルに表示されません。また、それがアイテムの最新リビジョンである場合、そのアイテムのエントリ全体が実質的に非表示になります。状態レベルで定義されるこの表示設定は、Explorerパネルでの閲覧時に、すべてのアイテムに対して一括で上書きできます。現在非表示になっているすべてのアイテムリビジョンを表示するには、パネルのItems領域の右上にあるコントロールをクリックし、表示されるメニューでShow Hidden Revisionsオプションを有効にします。

Explorerパネルでコンテンツを閲覧する際に、非表示のアイテムリビジョンを表示します。画像にマウスポインタを合わせると、結果を確認できます。

適用不可のリビジョンの表示

通常、非表示に設定されたライフサイクル状態（Visible in Vault panelsオプションが無効）は、適用不可にも設定されます（Allowed to be used in designsオプションも無効）。たとえば、現在DepracatedまたはObsoleteであるコンポーネントのリビジョンを、最新の設計に含めるべきではありません。このような状態に移行したアイテムのリビジョンを非表示にすることには意味があります。たとえば、コンポーネントが表示されなければ、配置することもできません。しかし、こうしたアイテムリビジョンのインスタンスをすでに設計で使用している場合や、閲覧時に非表示のリビジョンを表示したために、適用不可のコンポーネントリビジョンを誤って配置してしまう場合もあります。

そのような場合も心配はありません。コンパイル時に適用不可の状態にあるコンポーネントアイテムリビジョンを検出できるほか（次のセクションを参照）、設計ソフトウェア内でアイテムリビジョン（コンポーネントおよび管理対象シート）の適用可否を手動で直接確認することもできます。これには、アイテムのプロパティを閲覧する際にPropertiesパネルを使用するか、Item Managerを使用します。

• 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 Managerダイアログで適用不可であることを表示します。

プロジェクト検証時の適用不可のリビジョン状態の検出

配置済みのコンポーネントアイテムリビジョンのインスタンスについては、プロジェクト検証の一環として、リビジョンの状態の適用可否を確認できます。このチェックの中心となるのは、コンポーネントに関連する違反カテゴリに含まれる、コンポーネントリビジョンが適用不可の状態にあるという違反タイプです。このチェックの報告モードは、Project OptionsダイアログのError Reportingタブで設定します。

プロジェクト検証には、適用不可のリビジョン状態にあるコンポーネントに関する違反のチェックが含まれます。配置済みのコンポーネントアイテムリビジョンのライフサイクル状態が、設計での使用を許可しない状態として指定されている場合、違反が発生します。

回路図上でのコンパイラのエラーおよび警告の表示が有効になっている場合（PreferencesダイアログのSchematic – Compilerページで有効化）、違反のあるオブジェクトの下に色付きの波線が表示されます。また、Messagesパネルにも次の形式で通知が表示されます。

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

ここで、

• Designatorは、コンポーネントインスタンスのDesignatorです。
• Commentは、コンポーネントインスタンスのCommentです。

違反の例（影響を明確にするため、致命的エラーに設定）。

注意事項：

• 配置済みのコンポーネントが、配置元の接続先Workspaceとの接続を失った場合（たとえば、そのWorkspaceの接続が解除された場合や、Workspaceからサインアウトした場合）、Component revision has inapplicable stateチェックで違反になります。これはMessagesパネルに、Component <Designator> <Comment>: Can't perform revision status validation: Failed to connect to serverという形式のエントリで表示されます。
• 設計リリースプロセス中に、設計内で不適切に使用されているコンポーネントを検出することもできます。リリース検証全体の手順にComponent State Checkingを追加して設定するだけです。詳細については、コンポーネントステータスの検証を参照してください。