この記事で学べること
- USB、SCPI、VISA、SiLA 2、OPC UA LADS、PLCがそれぞれ何を担当するか
- 「通信できる」と「実験を自動で進められる」の違い
- 装置内の制御と、複数装置をまとめる実験管理の分け方
- 既存装置を生かしながら標準インターフェースへ接続する考え方
- 装置購入・システム設計の前に作る接続要件表と、確認試験の進め方
実験自動化を調べると、SiLA、LADS、OPC UA、SCPI、PLCなど多くの名前が登場します。ところが、これらを一列に並べて「どれが最も優れているか」と考えると、設計を進めにくくなります。担当する仕事が異なるからです。
まず決めたいのは、装置へ何を指示し、何を確認して次の工程へ進むかです。そのうえで、通信、命令、機能の表現、現場制御、実験管理を分けて選びます。一つのシステムでSCPIとSiLA 2、あるいはPLCとLADSを組み合わせることも、設計の選択肢になります。
本記事は、装置連携に取り組む研究者、研究開発のシステム担当者、装置調達担当者を対象とする専門シリーズの第1回です。規格の詳細実装に入る前に、全体の構造と判断基準を整理します。導入全体の進め方は、実験自動化の導入手順・装置連携・費用対効果も参照してください。
1．装置がつながっても、実験が自動化できたとは限らない
仮想例：熱処理してから材料を測定する
次の例は編集部による仮想例です。材料試料を加熱し、冷却後に光学測定を行う工程を考えます。「温調装置へ温度を書き込み、測定装置へ開始命令を送る」だけなら、短いプログラムでも実現できるかもしれません。
しかし、実際の手順には次の問いがあります。設定値を書き込めたのか。試料は必要な温度に達したのか。保持時間はどこから数えるのか。冷却後に搬送できるのか。測定は受付済みなのか、完了したのか。結果はどの試料に対応するのか。
| 工程 | 上位システムからの指示 | 次へ進む条件の例 |
|---|---|---|
| 加熱 | 設定温度と手順を指定 | 試料を代表する測定温度が許容範囲へ到達 |
| 保持 | 保持条件を指定 | 所定時間と温度条件を満たす |
| 冷却・搬送 | 冷却手順、搬送先を指定 | 搬送可能な温度と装置状態を確認 |
| 光学測定 | 試料IDと測定手順を指定 | 測定完了と結果の取得を確認 |
| 記録 | 結果を登録 | 実行ID・試料ID・手順・結果が対応する |
この表の条件は、個別の実験手順に応じて決めるものです。装置の表示温度がそのまま試料温度を表すとは限りません。「温度到達」の定義には、センサー位置、温度差、安定判定の時間も関わります。
自動化の設計では、命令を送る方法に加えて、その工程を終えたと判断する根拠を用意します。ここを先に決めると、必要なインターフェースが見えてきます。
2．通信・命令・標準・制御を5つの役割に分ける
以下は、設計上の役割を理解するための編集部の整理です。OSI参照モデルなどの厳密な通信階層ではありません。SiLA 2やOPC UAのように、複数の役割にまたがる技術もあります。
| 役割 | 答える問い | 技術・仕組みの例 |
|---|---|---|
| ①接続・通信 | どうやってデータを届けるか | USB、RS-232、Ethernet、TCP/IP |
| ②装置へのアクセス・命令 | どの命令で、どう操作するか | SCPI、VISA、メーカーAPI・SDK |
| ③機能・情報の共通表現 | 機能や値の意味をどう共有するか | SiLA 2のFeature、OPC UA LADSの情報モデル |
| ④現場の制御 | 温度や動作をどこで維持するか | 装置内コントローラー、PLC、PID制御 |
| ⑤実験の進行管理 | どの装置を、どの順番で使うか | ワークフロー、スケジューラー、実行記録 |
API、SDK、ドライバーの違い
APIは、ソフトウェアが別のソフトウェアを操作するための窓口です。SDKは、そのAPIを利用するためのライブラリ、資料、例などをまとめた開発用の道具一式です。ドライバーは、装置固有の通信や操作をソフトウェアから扱えるようにする部品です。名称だけで判断せず、実際に何が提供されるかを確認します。
例えば「Ethernet対応」でも、独自の文字列命令なのか、メーカー独自APIなのか、OPC UAサーバーなのかで実装は異なります。「USB対応」でも、測定ファイルを取り出すだけの端子と、遠隔操作できる端子では役割が違います。接続口の存在と、必要な操作の提供を別々に確認しましょう。
3．SCPIとVISA：計測器へ命令を送るための基礎
SCPIは命令体系、VISAは入出力の共通API
SCPI（Standard Commands for Programmable Instruments）は、プログラムから計測器を操作する命令体系です。VISA（Virtual Instrument Software Architecture）は、複数の計測器インターフェースへ共通のAPIでアクセスするための仕組みです。IVI FoundationはSCPIとVISAの仕様をそれぞれ公開しています。［5］NI-VISAはVISAの実装の一つです。［6］
役割で考えると、SCPIは「送る命令」、VISAは「命令や応答を入出力する窓口」です。VISAを使っただけで、装置が任意のSCPI命令を理解するようになるわけではありません。装置のプログラミングマニュアルに、対応命令、応答形式、終端文字、タイムアウト条件があるか確認します。
既存計測器を生かしやすい利点
既に遠隔操作できる計測器なら、その接続を活用して小さく自動化を始められます。電子材料の電気特性測定などでは、設定、測定、結果取得の手順を一つずつ確認する入口になります。これは仮想的な利用場面であり、特定製品の対応を保証するものではありません。
一方、同種の装置でも測定レンジ、待ち時間、応答の単位、追加機能が異なることがあります。装置交換時の変更を抑えるには、実験管理プログラムから直接メーカー固有命令を呼び出す箇所を増やさず、装置操作をまとめた部品を介して利用する設計が役立ちます。
4．SiLA 2：装置の「できること」をインターフェースとして提供する
Feature・Command・Propertyを理解する
SiLA 2では、サーバーが提供する機能をFeatureとして表現します。Featureには、操作を呼び出すCommandと、読み取りや購読の対象となるPropertyがあります。通信にはHTTP/2、Protocol Buffers、gRPCの仕組みを用います。［1］gRPCは、引数と戻り値を定義したサービスのメソッドを、別のマシンから呼び出すための技術です。［8］
温調装置を例にすると、「設定温度を変更する操作」と「現在温度を読む値」を分けて考えられます。この例は概念説明用で、公式Feature名や必須項目を示すものではありません。実装では利用するFeatureの定義、型、バージョン、エラーの意味を確認します。
SiLA 2を導入する価値
装置側の通信処理と、上位側の実験手順を分けやすくなることが実務上の利点です。既存装置のメーカーSDKを呼び出すラッパーを作り、その上にSiLAインターフェースを設ければ、上位からの操作方法を揃える設計ができます。
ただし、ラッパーは単なる名前の置き換えではありません。「開始」が受付を表すのか、処理完了を表すのか、測定中に別の操作を受け付けるのかまで対応付けます。同じ接続方式でも機能定義が異なれば、そのまま交換可能とはいえません。
本記事では規格の位置づけを扱います。実装時は公式仕様と対象Featureを参照し、使用するSDKの対応範囲を確認してください。一般的なgRPCサーバーを作るだけでは、SiLA 2への適合を示せません。
5．OPC UA LADS：装置・状態・実行結果を共通モデルで扱う
OPC UAとLADSは何が違うのか
OPC UAは、データや機能を情報モデルとして表現し、標準サービスでアクセスする基盤です。例えばVariableは値、Methodは呼び出す機能を表現します。分野ごとの情報モデルを定める仕様はCompanion Specificationと呼ばれます。［3］
LADS（Laboratory and Analytical Device Standard）は、その基盤上で実験・分析装置の共通モデルを定める規格です。装置、構成要素、機能単位などを表現します。公式資料には遠心機を用いた構造の例があります。［2］この公開例は、装置の構造をモデルへ対応付けるための例であり、特定システムの導入効果の実測事例ではありません。
個別操作と装置内プログラムの実行を分ける
LADSでは、機能の開始・停止や設定値変更を扱うFunction-based remote controlと、装置内のプログラムを選び実行・監視するProgram-based remote controlが整理されています。結果管理には結果のほか、時刻、実行に関する識別情報、試料IDなどのメタデータも含まれます。［4］
例えば分析装置が既に検証済みの測定手順を持つ場合、上位から細かな操作を逐次指示するより、装置内手順を呼び出す構成が合うことがあります。材料処理装置でも、工程ごとの設定を上位で管理する方法と、装置内レシピへ任せる方法を比較できます。これらは設計判断を説明する仮想例です。
LADSを検討する利点は、値の取得だけでなく、装置の状態、機能、プログラム、結果を関係付けて整理できることです。調達時は「OPC UA対応」だけで終わらず、LADSへの対応と必要機能を確認します。OPC UAには機能範囲を分けるProfileの考え方があり、すべての機能が全製品で実装されるわけではありません。［3］
6．PLC・PID制御と上位の実験管理を分ける
制御とは、状態を目標に近づけて維持すること
温度を60℃に保つ場面を考えます。上位ソフトが「60℃にする」と指示しても、それだけで温度は一定になりません。センサーの値を読み、目標との差に応じて加熱量を調整する繰り返しが必要です。目標と測定値を比較して操作を調整する仕組みがフィードバック制御です。
PID制御は、差の大きさ、差の積み重なり、変化の速さに対応する3要素を組み合わせる制御方式です。最適化アルゴリズムが次の実験条件を選ぶことと、装置がその温度を維持することは別の仕事です。両者を分けると、条件探索の変更が現場の制御処理へ広がりにくくなります。
PLCは規格名ではなく、制御を担う機器
PLC（Programmable Logic Controller）は、センサー入力や機器出力を扱い、設定したロジックを実行する制御機器です。PLCに関連する標準の一つにIEC 61131-3があります。PLCopenは、この標準と関連する制御ソフトウェア技術を扱っています。［7］
PLCや装置内コントローラーには、温調、搬送、装置内の動作条件などを担当させ、上位ソフトには実験条件、試料順、装置割り当て、結果記録を担当させる構成が考えられます。ただし担当範囲は装置と要求次第です。PLCを導入しただけで、所要時間内の応答や安全機能が自動的に保証されるわけではありません。
SiLAやLADSは、上位から操作・監視する窓口を整える技術です。装置内部の制御をすべて置き換えるものと考えず、必要な応答時間と責任範囲に合わせて配置します。
7．実験をまとめるオーケストレーションは何をするか
オーケストレーションとは、複数の装置や処理を組み合わせて、実験手順全体を進めることです。装置Aで処理した試料を装置Bで測定する場合、装置の空き状況、試料位置、処理完了、測定結果を管理します。
例えば共用の光学測定装置が1台しかなければ、2つの実験が同時に開始命令を出さないように利用権を管理します。ある工程が失敗した場合、後続工程を実施するか、保留するか、人の確認へ回すかも決めます。共通規格で装置がつながっていても、研究室の実験方針や資源配分は別途設計する必要があります。
結果を保存する際は、試料IDに加え、実行ID、装置ID、手順の版、設定値、実測値、開始・完了時刻を対応付けます。実験装置・LIMS・データベースを連携する設計では測定CSVの登録を扱っています。本記事の接続設計と合わせることで、操作から結果保存までの境界を整理できます。
さらにAIが次の条件を選ぶ場合でも、実行可能範囲と承認条件を実験管理側へ引き渡します。全体像は自律実験・Self-driving Labの仕組みと導入手順を参照してください。
8．何を使えばよいか：3つの構成から考える
| 状況 | 最初に検討する構成 | 選ぶ理由・確認点 |
|---|---|---|
| 計測器1台の定型測定 | メーカーAPI、またはSCPI＋VISAなど | 既存機能で小さく検証。完了検知と結果取得を確認 |
| 異なる装置を複数つなぐ研究室 | SiLA 2またはLADSを共通窓口に利用 | 上位ソフトとの適合、必要機能、保守体制を比較 |
| 処理装置と工場側設備を含む | 現場制御＋OPC UA等の上位接続 | 既存制御基盤を生かし、LADSが適用できる装置か確認 |
これは唯一の正解を示す表ではありません。SiLA 2もLADSも、導入する価値は接続先と運用条件によって変わります。「研究室だからSiLA」「工場だからLADS」と決めず、必要機能を実際のクライアントとサーバーで照合します。
比較する際は、装置メーカーの対応だけでなく、上位システム側の対応、実装担当者の技術、証明書運用、更新時の試験、既存装置への変換処理を含めます。独自APIで十分な小規模試作に最初から標準化の全費用をかける必要はありません。一方、複数テーマへ展開する予定なら、試作段階から装置固有部分を分離しておくと拡張しやすくなります。
9．自分で試してみよう：接続要件表を1台分作る
第1回の実践は、機器を動かす前の設計作業です。装置の操作説明書とプログラミングマニュアルを開き、以下を記入してください。確認できない欄は推測せず「未確認」とし、メーカーへの質問に変換します。
| 項目 | 記入する内容 | 温調装置の仮想例 |
|---|---|---|
| 必要な操作 | 自動化したい機能 | 設定温度変更、開始、停止 |
| 取得する値 | 値・単位・更新間隔 | 温度℃、取得可能な頻度を確認 |
| 接続と命令 | 端子、プロトコル、API | Ethernet、メーカーAPI |
| 実行の確認 | 受付・進行・完了の見分け方 | 実行IDと状態を照会できるか |
| 現場制御 | 温調・動作を担当する場所 | 装置内コントローラー |
| 制約 | 操作範囲、排他、権限 | 測定中の設定変更の可否 |
| 切断時 | 継続・停止・照合の方針 | 装置の継続状態を確認 |
| 結果と識別 | 試料・手順・結果の対応 | 試料ID、実行ID、ログ |
次に、「値の読出し」「操作の受付」「処理の完了」「結果の照合」の順に確認試験を作ります。たとえば設定値を変更できても、実測温度を取得できなければ温度到達の判定はできません。必要条件を満たせないときは、測定手段を追加するか、装置内手順を利用するか、人が確認する工程として残します。
この要件表があれば、SiLAやLADSへの対応を質問するときも、「対応していますか」から「この操作と状態と結果を取得できますか」へ具体化できます。本記事には実機操作コードを掲載していません。続く実装記事では、模擬装置を用いて通信操作を段階的に確認します。
10．よくある失敗と、設計上の対策
命令を受け付けた直後に次の工程へ進む
命令の応答が返ったことと、加熱や測定が終わったことは別です。受付、実行中、完了を区別し、工程ごとに完了条件を定義します。状態を取得できない装置では、固定待ち時間だけで十分かを実験条件の変動も含めて評価します。
タイムアウト後に同じ命令を無条件で送り直す
返答が届かなくても、装置が操作を実施済みの場合があります。例えば分注命令を送り直すと、二重分注につながる可能性があります。読出しと副作用のある操作を分け、再送前に実行状況を照合します。照合機能がなければ、人の確認へ移す判断も必要です。
同じ数値なら同じ意味だと考える
値が「60」でも、設定温度、実測温度、異なる位置の温度では意味が違います。単位と測定対象、時刻、更新状態を確認します。機能名が似ているだけで、装置交換後に同じ実験が再現されるとは限りません。
通信ソフトへすべての責任を集める
上位側の停止命令だけに装置停止を依存させると、通信断やPC停止時の扱いが不明確になります。通常操作、工程異常時の処理、装置側の保護機能を分けて設計します。設備に必要な安全機能とその検証は、適用条件に応じて設備・制御の担当者が確認します。
11．導入前チェックリスト
- 必要な操作・状態・結果を、装置ごとに列挙した
- 接続方式と命令・情報モデルの対応を分けて確認した
- 受付と完了を区別し、次工程へ進む条件を決めた
- SiLAでは必要Feature、LADSでは必要なモデル・対応機能を確認した
- 装置内制御と上位管理の担当範囲を決めた
- 試料ID、実行ID、装置ID、手順の版を対応付けた
- 通信断・応答遅延・装置再起動後の照合手順を決めた
- 権限・証明書・ソフト更新の担当者を決めた
- 模擬装置の試験と実機の受入試験を分けた
共通規格は接続と再利用を支援しますが、測定の正しさ、装置の精度、試料の取り違え防止まで一括して保証するものではありません。ソフトウェアの試験に加え、装置校正と実験手順の妥当性確認が必要です。通信や動作の試験結果を、材料性能の検証結果と混同しないようにします。
12．FAQ
Q．SiLA 2とLADSは、どちらか一つに統一すべきですか？
必ずしもそうではありません。既存装置と接続先の対応に応じて共存できます。ただし、変換層を増やすほど保守項目も増えます。共通化する操作と状態を決め、変換後も実行と結果を追跡できるか確認します。
Q．既存装置が標準非対応でも使えますか？
メーカーAPIや通信機能があれば、ラッパー経由で組み込める場合があります。取得できない状態や操作を変換だけで作り出すことはできないため、装置が提供する機能を先に確認します。
Q．PLCがないと実験自動化はできませんか？
装置内コントローラーとメーカーAPIで必要な処理を実施できる構成なら、追加PLCが不要な場合もあります。PLCの要否は、入出力、要求される応答、保守方法、設備側の制御条件から判断します。
Q．Pythonから接続できれば標準対応といえますか？
接続試験の成功と規格適合は別です。対象仕様、対応機能、データ型、状態やエラーの意味を確認します。本番では、別のクライアントや装置を組み合わせた受入試験も計画します。
まとめ：規格名より先に、操作・確認・担当範囲を決める
実験自動化では、接続口、命令、機能の共通表現、現場制御、実験の進行管理が組み合わさります。SCPIとVISAは計測器アクセス、SiLA 2とLADSは装置機能や情報の共通化、PLCや装置内コントローラーは現場の制御、と役割から整理すると選びやすくなります。
最初の一歩は、装置1台について接続要件表を作り、操作の受付と完了、結果の対応を確認することです。必要な機能がわかってから規格を選び、上位の実験手順と装置固有処理を分けて実装しましょう。次回は「SiLA 2とは？」を取り上げ、Feature・Command・Propertyから仕組みを詳しく説明します。
参考文献
以下は公式仕様・公式技術資料です。公開年の明記がないWeb資料は年不明とし、参照日は2026年10月10日です。Web仕様・技術資料のためDOIはありません。本文中の番号と対応しています。
- ［1］SiLA Consortium. “Standards / Introducing SiLA 2.” 年不明。https://sila-standard.com/standards/
- ［2］OPC Foundation. “OPC UA for Laboratory & Analytical Device Standard (LADS) – Part 1: Basics,” OPC 30500-1, v1.0.0, §4.1 Introduction to LADS. 公式仕様：LADSの概要
- ［3］OPC Foundation. 同仕様、§4.2 Introduction to OPC Unified Architecture. 公式仕様：OPC UA・情報モデル・Profile
- ［4］OPC Foundation. 同仕様、§5.1 Automation. 公式仕様：遠隔制御と結果管理
- ［5］IVI Foundation. “Specification Downloads.” SCPI-99およびVPP-4.3 The VISA Libraryへの公式案内。https://www.ivifoundation.org/specifications/default.html
- ［6］NI. 「NI-VISAの概要」. NI公式技術資料
- ［7］PLCopen. “PLCopen Standards.” 年不明。https://www.plcopen.org/standards/
- ［8］gRPC Authors. “Introduction to gRPC.” 年不明。https://grpc.io/docs/what-is-grpc/introduction/
