requested として作成し（見積もり実行時間を伴います）、後でスケジューラーがチャンネルと [planned_start_time, planned_end_time) の時間枠を割り当て、scheduled に移行させます。
予定測定は実際のセル測定を作成したり変更したりすることは決してありません。実テストが開始すると、実際の cell_measurement がプランへリンクバックし、プランを in_progress に移行させます — 予定行はリクエストとスケジュールの監査証跡として残ります。
使い分け
予定測定はオプションです — ラボビューに記載されている通り、測定を直接作成して実行時にchannel_id を設定することもできます。次のような場合に予定測定を使用します:
- プロジェクトまたは特定のセル仕様に対してリクエストされたテストのバックログを追跡したい。
- 2 人のスケジューラーが同じチャンネルと時間枠を予約しないよう、将来のチャンネル時間を予約したい。
- （科学者や PM からの）リクエストと、（ラボオペレーターによる）スケジュールの決定を分離したい。
- 各テストを誰がリクエストし、誰がスケジュールしたかの監査証跡を残したい。
ライフサイクル
スケジュールは完全に手動です — スケジューラーがチャンネルと時刻を選びます。自動オプティマイザはありません。
scheduled プランで将来のチャンネル時間を予約しても、ラボビューでチャンネルが occupied として表示されることはありません — それは実行中の実測定のみが行います。プランはカレンダーを予約し、cell_measurement は現時点を予約します。
フィールド
name はプロジェクト内で一意（大文字小文字を区別しない）です。重複する名前でプランを作成すると IonworksError が error_code == "CONFLICT"（HTTP 409）で発生します。作成を冪等にするには create_or_get を使用してください。
測定のリクエスト
チャンネルなしのrequested プランを作成し、実行するプロトコル、テスト対象のセル仕様、見積もり実行時間を指定します。具体的なセルインスタンスとチャンネルは後でスケジューラーが選択します。
create_or_get を使用します:
プロトコルの検証
protocol_id は組織内の実験テンプレートを参照する必要があり、また、その基盤となるプロトコルは実際のセルで実行可能な状態でなければなりません — 計画測定はラボが実行する正確なテストを固定するため、中途半端に設定されたプロトコルは、後で失敗した実行として現れるのではなく、リクエスト時点で拒否されます。
create と update は、protocol_id が次のいずれかの場合、IonworksError（HTTP 400）でプランを拒否します。
- 組織内に存在しない。 エラー:
protocol_id '…' does not reference a protocol in this organization. - 未解決の入力が残っている。
input["…"]プレースホルダーで作成されたプロトコル（パラメータ化入力を参照）は、計画測定にリンクする前にすべての入力を具体的な値に解決しておく必要があります。エラーには未指定の入力名が列挙されます:protocol_id '…' references a protocol with unresolved inputs (C-rate, Temperature [°C]). Planned measurements require a fully-specified protocol — set all input values first. - UCP 検証に失敗する。 構造的に無効なプロトコル（不正なステップ定義、一貫性のない終了条件など —
POST /protocols/validateと同じチェック）は、内部の検証エラーとともに拒否されます。
チャンネルへのスケジュール
schedule でチャンネルと時間枠を割り当てます — これは requested プランを scheduled に移行する便利なラッパーです。
scheduled として一度に作成することもできます:
UI でチャンネルを選ぶ
スケジュールダイアログのチャンネルピッカーには、各チャンネルの名前と並んでリアルタイムの空き状況と電気的定格が表示されるため、適合性を判断するためにラボビューへ移動する必要はありません:- 主要行 —
cycler / channel。 - 定格 — 最大電流と電圧範囲（例:
40 A · 0–5 V）。チャンネルの定格から取得されます。未設定のフィールドは省略されます。 - 状態 —
free、occupied、またはstale。ラボウォールと同じチャンネル占有状態ルールから導出されます。運用停止（out-of-commission）チャンネルは一覧には表示されますが無効化されています。
スケジュール衝突
チャンネル上ですでに使用中の枠と衝突する場合、スケジュールは拒否されます。別のチャンネルまたは時間枠を選んで再試行してください。
既存プランのキャンセルや完了は、チャンネルが運用停止になった後でも常に許可されます。
一覧取得とフィルタリング
list はプロジェクト単位で、PaginatedList[PlannedMeasurement] を返します。ライフサイクルステータス、チャンネル、名前でフィルタリングできます。
更新、キャンセル、削除
schedule を再度呼び出す（あるいは個別フィールドを update する）だけです。サーバーは新しい値に対して重複と運用停止のチェックを再実行します。
テストスケジューラーの行アクション
テストスケジューラーページ（プロジェクトごとに Lab → Test scheduler から開く）には、バックログのすべてのプランが一覧表示されます。各行のオーバーフローメニューには以下のアクションが表示されます。表示されるアクションはプランの現在のステータスに応じて変わります — エラーになる操作はボタンを押せる状態にせず、UI 側で非表示にします。
Delete は意図的に Cancel の後ろに配置されています — アクティブなリクエスト、予約済みチャンネル、または実行済みテストの記録を一度のクリックで削除できないようにするためです。まず Cancel し、その後に必要であれば Delete してください。
Copy は、ほぼ同じ内容のテスト（同じセル仕様とプロトコル、異なるメモやセットアップ）を続けて追加する最も速い方法です。Request test ボタンと同じリクエストフォームを使用するため、通常のバリデーションが適用されます。新規プランは独自の名前と監査フィールドを持ち、元のプランは変更されません。
実測定をプランにリンクする
プランを手動でin_progress に遷移させることはありません。実行が開始したら、planned_measurement_id を設定した cell_measurement を作成します — バックエンドがそれをリンクし、アトミックにプランを in_progress へ移行させます。
- プランが
scheduledである。 - 測定が
time_seriesタイプであり、channel_idを持っている（channel_idのないplanned_measurement_idは拒否）。 - プランと測定が同じプロジェクトおよび組織にある。
- 測定の
channel_idがプランのchannel_idと一致する。 - プランに
cell_instance_idが設定されている場合、測定は同じセルインスタンスで実行される必要がある。
status = scheduled に対するアトミックな compare-and-set であり、負けた側はリンクされないまま残されます（警告としてログに記録されます）。
リンク後は、ラボビュー上のチャンネル占有状態は実行中の cell_measurement によって駆動されます。予定行は監査証跡として残ります。
リクエスターの自動ウォッチ
scheduled プランが実際の cell_measurement にリンクされて in_progress に遷移すると、リクエスター（プランの requested_by）が開始された測定のウォッチャーとして自動的に追加されます。リクエスターは次回のラボステータス更新で、ラボビューの My Channels にその実行が表示されます — 手動で Watch をクリックする必要はありません。
動作:
- 両方のリンク経路で発火します:
planned_measurement_idを指定したcell_measurementの作成、およびstarted_measurement_idを伴うプランのin_progressへの PATCH。 - 冪等です — 再リンクや再遷移で重複したウォッチは作成されず、すでにウォッチしているユーザーはそのままウォッチを続けます。
requested_byのみが自動ウォッチされます。scheduled_byやラボオペレーターは対象外です。彼らは引き続きチャンネルページや測定ページから手動でウォッチできます。- ベストエフォートです — ウォッチの失敗が測定の作成やプランの更新を失敗させることはありません。リンクとステータス遷移は成功します。
プログラム
プログラムは組織スコープのカタログ項目で、Formation、Cycling、RPT
のようなラボテストの種別を表す短い再利用可能な名前です。プランに
program_id を設定するとそのテストがどの種別に属するかが記録され、実測定が
プランにリンクした時点でその値がコピーされます。
プログラムは自由入力のタグではありません。カタログは組織設定 →
プログラムから管理し、リクエストおよびスケジュールのフォームはその一覧から
選択するため、同じ種別を全員が同じ表記で扱えます。名前は組織内で一意です
（大文字小文字を区別しません）。
タグ付けされると、その Program はプラン上とテストスケジューラの計画テーブルに
表示されるため、ラボオペレーターはリクエストがどの種別に属するのかを一目で
把握できます。
program_id は登場するすべての箇所で null 許容
です。プロジェクト名やセル仕様名だけでテスト内容が分かる場合は、使わなくても
問題ありません。
権限
予定測定のエンドポイントは既存のcell_measurement 権限を再利用します:
project_id
すべての client.planned_measurement.* メソッドは任意の project_id を受け付けます。省略した場合、Ionworks クライアントに設定されている project_id（または IONWORKS_PROJECT_ID 環境変数）にフォールバックします。どこからも project_id が取得できない場合は ValueError が発生します。
次のステップ
ラボビュー
予定測定がスケジュールされるサイト、サイクラー、チャンネルをセットアップします。
測定
スケジュール済みプランへリンクバックする実際の
cell_measurement を作成します。