SiLA 2のFeature設計｜Command・Property・データ型の決め方

この記事で学べること

SiLA 2のFeatureが、装置の「できること」を表す契約書である理由
CommandとPropertyをどう分け、Observableをいつ使うか
Parameter、Response、Intermediate Responseの設計方法
データ型、単位、制約、Custom Data Typeを使って曖昧さを減らす方法
Defined Execution Errorと安全機能の責任範囲
Feature Definition（FDL）を作り、公式Python SDKで検証する手順

SiLA 2で装置をつなぐとき、通信が通るだけでは自動化は完成しません。「温度を設定する」「現在温度を読む」「運転完了を待つ」といった装置の能力を、クライアントが誤解しない形で定義する必要があります。その中心がFeatureです。

SiLA公式サイトは、FeatureをSiLA Serverが提供する能力と説明し、Featureが呼び出せるCommandと、読み取り・購読できるPropertyを公開するとしています［1］。本記事では温度調節装置を例に、Featureを実務で設計する順番を解説します。なお、ここで示すXMLは説明用の公開可能な仮想例であり、特定メーカーの実装ではありません。

結論：Featureは装置の通信コマンド表ではなく「意味のある能力」で切る

最初に結論をまとめます。

Featureは、装置型式や通信プロトコルではなく、利用者から見た能力で分ける。
状態を変える操作はCommand、現在値や状態の参照はPropertyにする。
短い設定変更はUnobservable、長時間処理や再接続後も追跡したい処理はObservableを優先する。
数値には単位と許容範囲を付け、同じ意味の型はCustom Data Typeで再利用する。
予測可能な業務上の失敗はDefined Execution Errorとして列挙する。
FDLは目視確認だけで終えず、XSD検証と使用SDKのコード生成をCIで実行する。

重要なのは、RS-232の「SET 50」のような装置固有文字列をそのまま表に出さないことです。その文字列を背後に隠し、クライアントには「SetTargetTemperature」という意味を提供します。SiLA 2はHTTP/2、Protocol Buffers、gRPCを基盤にしますが、Feature設計では通信の細部より機能を表すことが中心です［1］。全体像は実験自動化の通信・制御・標準を整理するも参照してください。

Feature Definition（FDL）の構造

FeatureはXML形式のFeature Definition Language（FDL）で記述します。主な要素は次のとおりです［2］。

要素	役割	温度制御の例
Feature	一まとまりの能力	TemperatureController
Command	状態を変える処理、または仕事の実行	SetTargetTemperature、RunTemperatureHold
Parameter	Commandへ渡す入力	TargetTemperature、HoldDuration
Response	正常完了時の最終結果	AcceptedTargetTemperature、CompletedAt
Intermediate Response	実行中に届く中間結果	ElapsedSeconds
Property	現在値・状態・構成情報の参照	CurrentTemperature、CurrentOperatingState
DataTypeDefinition	Feature内で再利用する型	Temperature、OperatingState
Defined Execution Error	予測可能な実行失敗	DeviceBusy、SafetyInterlockOpen

FeatureのIdentifierはUpperCamelCaseで、公式仕様は能力に応じてService、Provider、Controllerなどの接尾辞を推奨しています［2］。したがって「TC01」や「ModelABC」のような機種名ではなく、温度を制御する能力ならTemperatureControllerとする方が再利用しやすくなります。

CommandとPropertyをどう分けるか

Commandは「動詞」、Propertyは「現在の事実」

迷ったときは、呼び出しによって装置の状態や処理が変わるかを確認します。

Command：目標温度を設定する、測定を開始する、試料を搬送する、校正を実行する
Property：現在温度、シリアル番号、扉の開閉状態、運転状態、現在の測定値

「TargetTemperatureをPropertyにして書き込む」という設計は一見簡単ですが、SiLA 2のPropertyは読み取り・購読のための概念です。設定変更はCommandにし、受理した値をResponseとして返すと、入力と結果を追跡しやすくなります。

1つの巨大Commandを避ける

「RunExperiment」に温度、時間、測定、保存先をすべて詰めると、再利用や部分テストが難しくなります。一方、1バイト操作までCommandへ分解すると、クライアントが装置固有手順を組み立てることになります。

実務では、利用者が意味を理解でき、独立してテストできる単位を選びます。「目標温度を設定する」と「設定温度に到達後、所定時間保持する」は、所要時間と失敗条件が異なるため別Commandにする価値があります。装置をPythonから統合する一般的な層分けはPythonによる実験装置・研究データ連携にもつながります。

ObservableとUnobservableの選択

CommandにはObservable=”Yes”または”No”を指定します。公式仕様では、長時間動作、進捗を知りたい処理、接続が切れても結果を失いたくない処理はObservableが適します。一方、設定値を送るだけの短い処理はUnobservableが適する場合があります［2］。

判断	Unobservable	Observable
典型例	設定値の変更、短いリセット	測定、加熱保持、長い校正
時間	短い、即時応答が期待できる	人が待つと感じる時間
進捗・中間結果	不要	必要、または有用
切断後の追跡	結果を受け取れない可能性	Execution UUIDを使って再追跡しやすい

今回の例では、SetTargetTemperatureはUnobservable、RunTemperatureHoldはObservableです。後者にはElapsedSecondsというIntermediate Responseを定義します。ただし中間応答は「進捗率」と同じではありません。温度到達時間が不確かな装置で根拠なく50%と返すより、「現在温度」や「経過時間」という観測可能な事実を返す方が安全です。

PropertyもObservableを選べます。Observable Propertyを購読すると、初回の現在値と、その後の変化が送られます［2］。現在温度や運転状態には向きますが、シリアル番号のように変化しない値はUnobservableで十分です。

Parameter、Response、中間応答を設計する

Parameterは必要最小限にする

ParameterにはCommand実行時に必ず確定している入力を置きます。入力が省略可能か、装置側の既定値に依存するかを曖昧にすると、同じ呼び出しでも装置ごとに結果が変わります。自動化で再現性を重視するなら、結果へ影響する設定は明示的なParameterにするか、使用した設定をResponseへ含めます。

Responseは「呼び出せた」ではなく、後工程に必要な結果を返す

成功時に単なるtrueだけを返すと、実際に採用された値、結果ファイル、完了時刻が分かりません。SetTargetTemperatureではAcceptedTargetTemperatureを返し、装置が丸めた値を後工程で確認できるようにします。RunTemperatureHoldではCompletedAtを返せば、実験記録と時刻を関連づけられます。

測定処理なら、結果そのものをStructureで返すか、ファイル参照とメタデータを返すかを、データ量と保存責任に応じて決めます。巨大なバイナリを毎回Responseに含めることが最善とは限りません。

データ型・単位・制約で曖昧さを消す

基本型だけでは意味が足りない

「Realだから温度」とは限りません。数値だけでは、摂氏かケルビンか、許容範囲はいくつか、端点を含むかが分かりません。SiLA 2にはInteger、Real、String、Boolean、Date、Time、Timestamp、Binary、Anyなどの基本型に加え、List、Structure、Constrainedといった派生型があります［2］。

物理量にはUnit Constraintが推奨されます。送信値はUnit Labelの単位で扱い、Factor、Offset、SI単位要素で換算関係を表します［2］。

<DataTypeDefinition>
  <Identifier>Temperature</Identifier>
  <DisplayName>Temperature</DisplayName>
  <Description>A temperature between minus 40 and 200 degrees Celsius.</Description>
  <DataType>
    <Constrained>
      <DataType><Basic>Real</Basic></DataType>
      <Constraints>
        <Unit>
          <Label>degree Celsius</Label>
          <Factor>1</Factor>
          <Offset>273.15</Offset>
          <UnitComponent><SIUnit>Kelvin</SIUnit><Exponent>1</Exponent></UnitComponent>
        </Unit>
        <MinimalInclusive>-40</MinimalInclusive>
        <MaximalInclusive>200</MaximalInclusive>
      </Constraints>
    </Constrained>
  </DataType>
</DataTypeDefinition>

Custom Data Typeは同じ意味を一度だけ定義する

TemperatureをCustom Data Typeにすれば、CommandのParameter、Response、Propertyが同じ単位・範囲を参照できます。仕様上、Custom Data TypeはParameter、Response、Intermediate Response、Property、Metadataで通常の型と同様に利用できます［2］。

ただし、装置ごとに許容温度が違うのに、無理に共通範囲を固定してはいけません。Featureが表す共通契約と、個体の能力値を分けます。例えば規格上のTemperatureは広い物理型とし、装置固有の最小・最大温度を別Propertyとして公開する設計も可能です。

状態値は自由記述にしない

OperatingStateを単なるStringにすると、Idle、IDLE、Standbyなどが混在します。本例ではSet ConstraintでIdle、Heating、Holding、Cooling、Errorに限定しました。将来状態を追加するとクライアントへの影響があるため、FeatureVersionと変更方針も合わせて管理します。

Defined Execution Errorをどう設計するか

型や範囲の不正はValidation Errorで扱えます。一方、値の形式は正しいが実行できない条件はDefined Execution Errorとして設計します。公式仕様は、装置が忙しい、搬送元にプレートがない、搬送先が埋まっている、といった予測可能な前提条件を例示しています［2］。

温度制御例では次の3つを定義しました。

DeviceBusy：同時実行できない処理が進行中
SafetyInterlockOpen：扉や安全インターロックが開いている
TargetNotReached：装置内タイムアウトまでに目標温度へ到達しない

「Error1」「Failed」のような名称では、上位システムが再試行、中止、作業者通知を判断できません。エラーはクライアントが次の行動を選べる粒度にします。ただし予期できないソフトウェア障害や通信断まで、Defined Execution Errorに押し込む必要はありません。仕様でも、設計時に予測できない実装依存の失敗はUndefined Execution Errorと区別しています［2］。

実務でのFeature設計手順

利用場面を書く：「装置を制御する」ではなく、「ワークフローが目標温度を設定し、保持完了を待つ」と記述する。
能力の境界を決める：温度制御、攪拌、測定など、独立して再利用できるFeature候補へ分ける。
CommandとPropertyを列挙する：動作と現在の事実を分ける。
Observableを判断する：時間、進捗、切断後の追跡、結果消失リスクを確認する。
入出力を定義する：Parameter、Response、中間応答を後工程の判断から逆算する。
型と単位を固定する：範囲、単位、候補値、構造を定義し、再利用部分をCustom Data Typeにする。
失敗条件を列挙する：再試行可能、作業者対応、安全停止など、復旧行動を意識してエラーを分ける。
FDLを機械検証する：XSD検証、コード生成、クライアントとの契約テストを自動化する。
実装と安全を分離する：Featureは上位インターフェースであり、PLCや装置内部のインターロックを置き換えない。

自動実験全体の位置づけは実験自動化とは？、閉ループ探索との関係は自律実験・Self-driving Labとは？で整理しています。

公式Python SDKでFDLを検証する

本記事では、2026年10月12日時点で公式GitLabに公開されているsila_python v0.14.0（2025年12月1日付タグ）を使い、説明用のTemperatureController.sila.xmlを検証しました［3］［4］。SDKは規格そのものではなく実装の一つです。規格要件はSiLA仕様書で確認し、SDK固有のコマンドや生成物は使用版で固定してください。

python -m venv .venv
.venv/bin/python -m pip install "sila2[codegen]==0.14.0"
.venv/bin/sila2-codegen generate-feature-files \
  --output-directory generated \
  TemperatureController.sila.xml

正常なFDLからは、proto、Featureクラス、Client、Base実装、型、エラーなど8ファイルが生成されました。異常系としてFeature Identifierを「Temperature-Controller」に変えたところ、識別子パターン「[A-Z][a-zA-Z0-9]*」に違反すると検出されました。公式リポジトリのTimerProviderも、Observable Command、Intermediate Response、Property、Defined Execution Errorの実例として参考になります［5］。

注意：今回確認したCLIは、検証エラーを表示してもプロセス終了コードが0になる場合がありました。CIではCLIの終了コードだけを合否にせず、SDKのparse_feature_definitionなどで例外を捕捉し、異常時に非0を返す検証スクリプトを併用するのが編集部の推奨です。これはv0.14.0で観測したSDK固有動作であり、SiLA 2規格の要件ではありません。

よくある失敗

装置固有コマンドをそのままFeatureにする

SCPI文字列やメーカーSDKの関数名を公開すると、装置交換時にクライアントまで変更が必要になります。下位ドライバで装置固有差を吸収し、Featureには意味のある能力を出します。

単位をDescriptionだけに書く

「温度（℃）」と文章に書くだけでは、クライアントが機械的に換算できません。Unit Constraintと数値範囲を型に含めます。

長時間処理をUnobservableにする

通信断時に完了結果を受け取れず、同じ処理を再実行して二重実行になる恐れがあります。長時間の測定や保持処理はObservableを優先し、再接続とExecution UUIDの運用まで試験します。

Propertyを高速制御ループに使う

温度値を購読できても、それを使ってPC側でミリ秒周期の安全制御を実行する設計は危険です。ネットワーク遅延や切断を前提に、PIDやインターロックは装置内部またはPLCなど適切な制御層で実行します。

FeatureVersionを変えずに意味を変更する

Identifierが同じでも、単位、範囲、Response、エラーの意味を変えれば既存クライアントが誤動作します。互換性を確認し、破壊的変更では版を更新して並行試験します。

限界・不確かさ・安全と責任範囲

良いFeature定義は相互理解を助けますが、実装品質や装置安全を保証しません。FDLのXSD検証で分かるのは構文と一部の制約です。実装が本当にインターロックを確認するか、温度が正しいか、停止指令が所定時間内に効くかは、実機試験とリスク評価が必要です。

通知頻度、再購読、複数クライアント競合、認証、時刻同期、監査ログ、更新時の互換性はFeature XMLだけでは完結しません。危険な温度・圧力・可動部の保護は装置・PLC・安全回路側に置きます。

設計チェックリスト

Feature名が機種名ではなく能力を表している
Commandは動作、Propertyは現在の事実として分離されている
長時間処理と結果消失リスクを考慮してObservableを選んだ
ParameterとResponseの意味が英語Descriptionで明確になっている
物理量に単位、範囲、端点条件がある
同じ意味の型をCustom Data Typeで再利用している
状態値の表記揺れをSet Constraint等で抑えている
予測可能な失敗をDefined Execution Errorとして列挙した
クライアントがエラーごとに再試行・中止・通知を選べる
FDLをXSDと対象SDKで自動検証した
複数クライアント、切断、再接続、二重実行を試験した
安全制御をネットワーク上位層へ移していない

FAQ

Featureは装置1台につき1つですか？

いいえ。1つのSiLA Serverが複数Featureを実装できます。温度制御、攪拌、測定、識別などを能力ごとに分けると再利用しやすくなります。

設定値はPropertyにできませんか？

現在の設定値をPropertyとして読むことはできますが、変更操作はCommandとして表す方が、入力、受理値、エラー、監査を明確にできます。

Observable Commandには必ずIntermediate Responseが必要ですか？

必須ではありません。進捗や中間結果が意味を持つ場合に定義します。根拠のない進捗率を返すより、状態Propertyや実測値を購読させる方が適切な場合もあります。

すべての数値に最小・最大を付けるべきですか？

物理・仕様上の境界が明確なら付ける価値があります。ただし装置個体で能力が異なる場合、Feature型に固定するか、能力Propertyとして公開するかを検討してください。

FDLが生成できれば相互運用できますか？

それだけでは不十分です。同じFeature定義、対応バージョン、実装挙動、エラー処理、認証、実機のタイミングを組み合わせて適合試験を行う必要があります。

まとめ

SiLA 2のFeature設計は、装置固有の通信を、研究者やワークフローが理解できる能力へ変換する作業です。CommandとPropertyを分け、所要時間に応じてObservableを選び、単位・範囲・Custom Data Typeでデータの意味を固定します。予測可能な失敗はDefined Execution Errorにし、安全停止は装置やPLCの制御層に残します。

1つの利用場面と2〜3個のCommandから始め、FDL検証、コード生成、契約テスト、実機テストを繰り返す方が確実です。次の記事では、長時間Commandの進捗とエラーを扱います。

参考文献

SiLA, “Standards | SiLA Rapid Integration,” Technical Concept / SiLA 2 Features, 確認日 2026-10-12. https://sila-standard.com/standards/
Association Consortium Standardization in Lab Automation, “SiLA 2 Part (A) – Overview, Concepts and Core Specification,” Public Document Release v1.1, 19 March 2022. PDF
SiLA2, “sila_python,” official GitLab repository, 確認日 2026-10-12. https://gitlab.com/SiLA2/sila_python
SiLA2, “sila_python v0.14.0,” tag/commit b3c611565d6df1d6747eb8cb7c211aed5e3e2055, 2025-12-01. v0.14.0
SiLA2, “TimerProvider.sila.xml,” sila_python v0.14.0 example server. official example

SiLA 2のFeature設計｜Command・Property・データ型をどう決めるか

この記事で学べること

結論：Featureは装置の通信コマンド表ではなく「意味のある能力」で切る

Feature Definition（FDL）の構造