実験装置をネットワークへ接続できても、装置名、状態、測定条件、操作方法、結果の保存形式がメーカーごとに違えば、上位システムは装置ごとの個別対応から抜け出せません。OPC UA LADSは、分析・実験装置を共通の情報モデルで表し、監視、制御、プログラム実行、結果管理、保守管理を一貫して扱いやすくするための標準です。
この記事で学べること
- OPC UA LADSが何を標準化し、何を標準化しないのか
- Device、Component、Function、Functional Unitの違い
- Hardware ViewとFunctional Viewを分ける理由
- Function-based制御とProgram-based制御の使い分け
- 装置状態、アラーム、結果、試料ID、保守情報をどう扱うか
- 導入・装置調達時に「LADS対応」をどう確認するか
結論から言うと、LADSの価値は「OPC UAで通信できること」だけではありません。装置を構成する部品、装置が提供する機能、独立して動作する処理単位、実行プログラム、状態、結果を、メーカーをまたいで理解しやすい構造で公開する点にあります。
一方、LADSを採用すればすべての装置が自動的に同じ操作方法になるわけではありません。実装するProfileやFacet、任意要素、ベンダー拡張、装置固有機能は異なります。導入時には「LADS対応か」ではなく、どの情報モデルと機能を実装し、どの試験に合格しているかを確認する必要があります。
OPC UA LADSとは
LADSはLaboratory and Analytical Device Standardの略称です。OPC Foundation、SPECTARIS、VDMAの共同作業として策定され、分析・実験装置向けのメーカー非依存なオープン標準を目指しています。対象には遠隔監視・制御、通知、プログラムと結果の管理、資産管理、保守が含まれます［1］。
公開されている「OPC UA for Laboratory & Analytical Device Standard（LADS）Part 1: Basics」は文書番号OPC 30500-1、Release Version 1.0.0、公開日2023年11月30日です。OPC Foundationのオンラインリファレンスでは、2026年10月11日時点でこの版がcurrentと表示されています［2］。
実験自動化におけるLADS、SiLA 2、SCPI、PLCの役割を先に俯瞰したい場合は、実験自動化の通信・制御・標準を整理するも参照してください。
LADSは通信プロトコルではなく「Companion Specification」
OPC UAは、装置やソフトウェア間でデータを安全・確実に交換するための基盤です。AddressSpaceと呼ばれる空間にObject、Variable、MethodなどのNodeを配置し、Clientはそれらを探索、読出し、監視、呼出しできます。OPC UAはプラットフォーム非依存、セキュリティ、拡張性、情報モデリングを設計目標に含みます［3］。
しかし、OPC UAだけでは「遠心機のローターをどこに置くか」「測定プログラムの結果を何というNodeで表すか」までは決まりません。そこで業界・用途ごとの概念をObjectType、VariableType、DataType、ReferenceTypeなどで定義するのがCompanion Specificationです。LADSは、実験・分析装置向けのCompanion Specificationに当たります［4］。
| 層 | 決めること | 例 |
|---|---|---|
| 装置固有ドライバー | 実際の機器との通信 | シリアル、SCPI、メーカーSDK、内部API |
| OPC UA | Node、通信サービス、Subscription、セキュリティ | Variable読出し、Method呼出し、Event通知 |
| LADS | 実験装置の概念と構造 | Device、Component、FunctionalUnit、ProgramManager、Result |
| 上位システム | 複数装置を使う実験手順 | LIMS、LES、ワークフロー管理、Pythonアプリ |
したがって、LADSはRS-232やEthernetの代替名称ではありません。既存装置をゲートウェイ経由でLADSモデルに変換する構成も可能です。
装置を二つの見方で表す
LADSでは、装置をHardware ViewとFunctional Viewの二つの観点からモデル化します［5］。この分離は、資産管理と自動化で必要な情報が異なるためです。
| 観点 | 中心となる要素 | 主な用途 |
|---|---|---|
| Hardware View | Device、Component、銘板、設置日、校正、保守 | 資産管理、保守、校正期限、故障部位の特定 |
| Functional View | Function、Functional Unit、Program、状態、結果 | 監視、制御、実験ワークフロー、結果回収 |
Hardware View：何で構成されているか
Deviceは分析・実験装置そのものです。Componentは装置を構成する部品です。公式仕様は遠心機の例としてLid、Rotor、Drive、Compressorを挙げ、それぞれに銘板や保守情報を持たせられる構造を示しています［5］。
この構造があると、「遠心機全体は稼働しているが、ローターAの校正期限が近い」「コンプレッサーの保守回数が上限に近い」といった情報を、装置全体と部品単位で区別できます。
Functional View：何ができるか
Functional Viewは、装置の操作、自動化、オーケストレーションに必要な情報を表します。Functionは特定の結果を得るための動作で、センサー、コントローラー、アクチュエーター、タイマーなどが含まれます。Program Managerはプログラムテンプレート、実行中のプログラム、結果を管理します［5］。
ハードウェア部品と機能は一対一とは限りません。温度制御Functionは、温度センサー、ヒーター、ファン、制御演算を組み合わせて成立する可能性があります。反対に、一つのセンサーが監視と制御の両方で使われる場合もあります。このため、部品階層と機能階層を分けて表す意味があります。
Device・Component・Function・Functional Unitの違い
| 要素 | 意味 | 例 |
|---|---|---|
| Device | 一つの分析・実験装置 | 遠心機、分光装置、2槽式反応装置 |
| Component | 装置を構成する物理要素 | ローター、蓋、ポンプ、検出器 |
| Function | 特定の結果を得る動作 | 温度測定、回転数制御、蓋の開閉 |
| Functional Unit | 一つの目的を達成するFunction群 | 独立運転できる反応槽、測定チャンネル |
| Program Manager | テンプレート、実行、進捗、結果を管理 | 温度・撹拌プログラム、分析メソッド |
Functional Unitは、複数のFunctionをまとめた「仮想装置」に近い考え方です。通常は一人の利用者が一度に使用し、独立した状態機械を持ち、必要に応じてProgram Managerを含みます。公式仕様は、二つの容器を持つバイオリアクターを二つのFunctional Unitとして表す例を示しています［6］。
たとえば2槽式装置で、槽Aは培養中、槽Bは洗浄中という状態を別々に管理したい場合、装置全体を一つの状態だけで表すより、Functional Unitを分けた方が現実に合います。
概念的なAddressSpaceの例
次は、LADSの考え方を理解するための簡略化した仮想例です。規格に定められたNode名をそのまま再現する実装例ではありません。
LaboratoryDevices
└─ Spectrometer-01 ← Device
├─ Components ← Hardware View
│ ├─ LightSource ← Component
│ ├─ Detector ← Component
│ └─ SampleStage ← Component
├─ FunctionalUnits ← Functional View
│ └─ MeasurementChannel-1 ← Functional Unit
│ ├─ Functions
│ │ ├─ WavelengthControl ← Control Function
│ │ └─ IntensitySensor ← Sensor Function
│ ├─ StateMachine
│ └─ ProgramManager
├─ DeviceHealth
└─ Maintenance
上位システムは、特定メーカーの画面構成ではなく、標準化された型と関係をたどって装置情報を取得できます。ただし、ベンダーが追加した独自Nodeも存在し得るため、Client側はNamespaceとTypeDefinitionを確認して処理する必要があります。
Function-based制御とProgram-based制御
LADSは、装置制御を大きくFunction-basedとProgram-basedの二つの利用場面で整理しています［7］。
| 方式 | 何をするか | 向く場面 | 例 |
|---|---|---|---|
| Function-based | 個別Functionを直接操作する | 即時操作、調整、装置横断ワークフロー | 蓋を開く、目標温度を設定、撹拌を開始 |
| Program-based | 装置内のプログラムやメソッドを選択・実行する | 複数ステップを装置内で完結させる処理 | 分析メソッド、温度プログラム、遠心プロトコル |
Function-basedが向く場合
上位ワークフローが細かな順序を管理し、各装置へ個別の指示を出す場合です。Methodを呼び出してFunctionを開始・停止したり、設定値やアラーム上限を変更したりします。
利点は柔軟性です。一方、Clientが装置内部の前提条件を理解しすぎると、装置交換が難しくなります。Functionの開始順、排他条件、許容値、完了判定を契約として整理する必要があります。
Program-basedが向く場合
装置内に検証済みの分析メソッドや運転レシピがあり、上位システムはプログラムを選び、開始し、進捗と結果を回収する場合です。仕様はProgram Templateの取得、プログラム選択、実行開始、進捗監視、結果管理を想定しています［7］。
装置内の安全な実行順や高速な制御を装置側へ残せる点が利点です。上位システムは、テンプレートの版、入力パラメーター、実行ID、結果を確実に記録します。
状態を標準化する意味
実験装置の自動化で難しいのは、命令を送ることより「いま何が起きているか」を正しく判断することです。LADSではDevice、Functional Unit、Control Functionなどに状態機械を用意し、装置状態、処理状態、運転モード、健康状態を区別します［8］。
| 情報 | 答える問い | 利用例 |
|---|---|---|
| Device State | 装置全体は使用可能か | Operating、Sleep、Shutdown方向の状態判断 |
| Functional Unit State | 特定の処理単位は何をしているか | 実行、保留、停止、完了、異常 |
| MachineryItemState | 上位システムから見た大まかな稼働状況は何か | 設備一覧のセマンティックな状態表示 |
| MachineryOperationMode | どの種類の作業中か | Processing、Setup、Maintenance |
| DeviceHealth | 装置・Componentは健全か | 正常、注意、故障、詳細アラーム |
複数の状態を一つの「RUNNING」へ潰すと、運転中、校正中、洗浄中、保守中を区別できません。反対に、装置固有状態をそのまま大量に上位へ出すと、共通処理できません。LADSの共通状態と装置固有の詳細状態を分けて持つ設計が実務的です。
プログラム、結果、試料情報をつなぐ
Program ManagerはProgram Templateを管理し、プログラム実行を開始し、Active Programの状態や実行時間、現在ステップを表し、結果を管理します。仕様はプログラムのアップロードから実行、結果生成までのライフサイクルを定義しています［8］。
結果は数値だけではありません。LADSの利用場面では、結果テンプレート、利用者情報、タイムスタンプ、アクション識別子、試料IDなどのメタデータを含めることが想定されています。途中結果を監視する構造や、結果が別の保存先にある場合にURIを公開する構成も扱われます［7］。
実務では、少なくとも次のIDを混同しないようにします。
- SupervisoryJobId：上位ワークフロー全体のジョブ
- SupervisoryTaskId：上位システムにおける最小実行単位
- DeviceProgramRunId：装置が生成する個別プログラム実行ID
- SampleId：測定対象となる試料の識別子
これらを対応付けることで、「どの研究ジョブの、どの試料を、どの装置プログラムで実行し、どの結果が得られたか」を追跡できます。結果をLIMSやデータベースへ登録する設計は、実験装置・LIMS・データベースを連携する設計でも解説しています。
既存装置をLADSへ接続する3つの構成
| 構成 | 特徴 | 適する状況 |
|---|---|---|
| 装置内蔵OPC UA Server | 装置が直接LADSモデルを公開 | 新規装置、メーカーが標準対応 |
| 装置PC上のServer | メーカーSDKや内部APIをLADSへ変換 | 制御PCが付属する既存装置 |
| Gateway Server | 複数の非OPC UA装置を一つのServerで表現 | シリアル、SCPI、アナログセンサーを含む既存ラボ |
公式仕様も、一台の装置がServerを内蔵する構成、複数Deviceを一つのServerに集約する構成、異なるプロトコルのレガシー装置をGatewayで表現する構成を想定しています［9］。
Gatewayは導入しやすい反面、Gateway停止時の影響範囲が広がります。装置識別子、再接続、キャッシュした値の鮮度、時刻同期、Gatewayと実機の状態不一致を設計してください。
LADS導入の実務手順
1．ユースケースを一つ選ぶ
「LADS対応する」ではなく、「装置一覧から状態と校正期限を監視する」「LIMSから分析プログラムを開始して結果を回収する」のように決めます。資産管理と自動制御では必要なFacetが異なります。
2．対象装置と上位システムの境界を決める
装置内蔵Server、装置PC、GatewayのどこへLADS Serverを置くか決めます。ネットワーク分離、証明書管理、保守担当、停止時の影響も同時に決めます。
3．Hardware Viewを作る
Deviceと保守対象Componentを列挙します。すべてのネジや基板をモデル化する必要はありません。校正、交換、状態監視、故障解析で独立して管理する価値がある単位をComponentにします。
4．Functional UnitとFunctionを決める
同時利用や排他制御の単位をFunctional Unitにします。その配下にSensor、Controller、Actuator、TimerなどのFunctionを配置します。物理部品の階層をそのままコピーせず、利用者の目的から設計します。
5．Function-basedかProgram-basedか決める
上位が細かく操作するのか、装置内プログラムへ任せるのかを処理ごとに決めます。両方を混在させる場合、Program実行中に個別Functionを変更できるか、排他条件を明示します。
6．状態・アラーム・結果を対応付ける
メーカー固有状態をLADS状態へマッピングし、変換不能な情報は独自Namespaceへ残します。結果には上位Job、Task、装置Run、試料のIDを対応付けます。
7．Profileと任意機能を宣言する
LADS BaseServerに加え、Program Manager、Extended Program Manager、Maintenance、Sensor Function、Controller Functionなど、実装範囲を明示します。仕様のProfile表には必須・任意のConformance Unitが整理されています［10］。
8．相互接続試験を行う
別ベンダーのClientでBrowse、Read、Subscription、Method、Event、結果取得を試験します。正常系だけでなく、証明書不信頼、通信断、装置Busy、不正な設定値、実行中の再指示も確認します。
「LADS対応」を調達仕様でどう確認するか
調達時に「OPC UA対応」「LADS対応」とだけ書くと、監視だけ可能なのか、プログラム制御や結果取得まで可能なのか判断できません。最低限、次を確認します。
- LADS Namespaceの版とNodeSet
- 実装するServer Profile／FacetとConformance Unit
- Device、Component、Functional Unitの構造図
- Read、Subscription、Method、Event、Historical Accessの対応範囲
- Function-based／Program-based制御のどちらを提供するか
- Program TemplateのUpload、Download、Removeの可否
- 結果値、結果ファイル、途中結果、試料情報の取得方法
- 状態機械とメーカー固有状態の対応表
- 証明書、暗号化、ユーザー認証、RolePermissionの運用
- ネットワーク断後の実行状態確認と二重実行防止
- OPC UA認証・相互運用試験・ベンダー試験の実績
- ファームウェア更新時のモデル互換性と変更通知
とくにProgram Managerは、監視用FacetとUpload・Downloadまで含むExtended Facetで実装範囲が異なります。製品名だけで判断せず、Profile単位で確認することが重要です。
よくある失敗と対策
失敗1：OPC UAで値を読めればLADS対応と考える
独自VariableをOPC UAで公開しただけでは、他社Clientが意味を理解できません。LADSのTypeDefinition、標準Node、関係、状態機械を実装し、実装Profileを示します。
失敗2：物理部品の階層だけを作る
Hardware Viewだけでは、ワークフローが何を開始し、どの状態を待てばよいか分かりません。Functional Unit、Function、Program、Resultを利用場面に合わせて設計します。
失敗3：Functionを細かく公開しすぎる
装置内部のモーターやバルブをすべて上位へ公開すると、Clientが装置の内部構造へ依存します。安全で再利用可能な粒度のFunctionとProgramを提供し、低レベル制御は装置内に残します。
失敗4：状態変換を曖昧にする
メーカー固有の「準備中」「安定化中」「測定待ち」をすべてRunningへ変換すると、完了判定やタイムアウトが誤ります。共通状態、SubState、独自詳細状態、遷移条件を文書化します。
失敗5：結果ファイルだけを返す
ファイルが取得できても、試料ID、実行条件、プログラム版、時刻、装置IDが結び付かなければ再利用性が下がります。結果とメタデータを同じ実行コンテキストで追跡します。
失敗6：証明書運用を導入後に考える
開発環境では匿名・無暗号で動いても、本番では証明書配布、信頼リスト、失効、更新、ユーザー権限が必要です。OPC UA CoreのSecurity Modelを基に、組織のネットワーク・ID管理と統合します。OPC UA Part 2の現行公開版は1.05.06です［11］。
技術的限界・不確かさ・責任範囲
- 標準化の限界：LADSは共通構造を提供しますが、すべての装置固有機能や分析意味論を網羅しません。
- 任意機能：ProfileやNodeには任意要素があります。「LADS対応」だけでは利用可能機能を確定できません。
- リアルタイム性：OPC UA／LADSの上位通信を、サブミリ秒の制御ループや安全インターロックの代わりにしないでください。
- 安全：非常停止、扉インターロック、過温・過圧保護は装置内制御や安全PLCで成立させます。
- データ品質：標準形式で送られた値でも、校正不良、試料取り違え、単位誤りは起こり得ます。
- 版管理：Namespace版、装置ファームウェア、独自拡張の互換性を管理します。
- 導入責任：装置メーカー、Gateway開発者、上位システム担当、ラボ運用者の責任範囲を明確にします。
実験自動化全体の導入範囲、データ基盤、費用対効果は実験自動化とは？で、複数装置を閉ループ化する考え方は自律実験・Self-driving Labとは？で整理しています。
導入前チェックリスト
- 対象ユースケースを監視、制御、結果、保守のどれかで説明できる
- LADSの版とNamespaceを固定した
- Deviceと保守対象Componentを定義した
- 同時利用・排他制御の単位としてFunctional Unitを設計した
- Function-basedとProgram-basedの使い分けを決めた
- 状態、運転モード、健康状態を区別した
- Job、Task、Program Run、SampleのIDを対応付けた
- 結果値、結果ファイル、途中結果の扱いを決めた
- 実装Profile／Facetと任意機能を一覧化した
- 証明書、認証、権限、監査ログを設計した
- 通信断、Busy、異常状態、二重実行を試験した
- 安全機能をLADS通信だけに依存させていない
FAQ
Q1．OPC UA対応装置ならLADS対応ですか？
いいえ。OPC UA Serverを搭載していても、独自情報モデルしか公開していない場合があります。LADS Namespace、TypeDefinition、Profile、Conformance Unitの実装を確認してください。
Q2．LADSは装置制御にも使えますか？
使えます。個別Functionを操作する方式と、装置内プログラムを選択・実行する方式が想定されています。ただし、対応MethodやFacetは製品ごとに確認が必要です。
Q3．既存の非OPC UA装置も接続できますか？
可能です。Gatewayや装置PC上のServerで、シリアル通信、SCPI、メーカーSDKをLADSモデルへ変換します。変換後の状態・エラー・単位が実機と一致するか試験してください。
Q4．SiLA 2とLADSはどちらを使うべきですか？
既存のOPC UA基盤、装置ベンダー、資産管理、プログラム・結果管理、開発言語、運用体制で選びます。両者は同じ層を完全に同じ方法で解決する規格ではありません。次回の記事で、選定表と併用構成を詳しく比較します。
Q5．LADSを使えばプラグアンドプレイになりますか？
標準型とProfileが一致すれば統合コストを下げられますが、完全自動ではありません。独自拡張、任意機能、証明書、ネットワーク、単位、ワークフロー適合性の確認が必要です。
Q6．最初の導入対象は何がよいですか？
状態監視と銘板取得、または一つの検証済みProgramの開始・進捗・結果回収がおすすめです。価値と合否判定を明確にしやすく、全機能を一度に実装するよりリスクを抑えられます。
まとめ
OPC UA LADSは、分析・実験装置をメーカー非依存の情報モデルで表すCompanion Specificationです。Hardware ViewではDevice、Component、銘板、保守を、Functional ViewではFunction、Functional Unit、Program、状態、結果を扱います。
実務上の要点は、装置の物理構造と利用者が使う機能を分けること、Function-basedとProgram-basedの制御を目的に応じて選ぶこと、状態・結果・試料IDを一つの実行コンテキストで追跡することです。
「LADS対応」という名称だけでは実装範囲は分かりません。Namespace版、Profile／Facet、任意機能、セキュリティ、相互接続試験を確認し、小さなユースケースから段階的に導入してください。
参考文献
- OPC Foundation, “LADS – Laboratory and Analytical Device Standard,” scope and working group information（2026年10月11日確認）. https://opcfoundation.org/markets-collaboration/lads/
- OPC Foundation, “OPC 30500-1: OPC UA for Laboratory & Analytical Device Standard (LADS) – Part 1: Basics,” Version 1.0.0, 2023-11-30（2026年10月11日確認）. https://reference.opcfoundation.org/specs/OPC-30500-1
- OPC Foundation, OPC 30500-1 v1.0.0, Section 1 “Scope” and OPC UA overview, 2023. https://reference.opcfoundation.org/specs/OPC-30500-1/1
- OPC Foundation, OPC 30500-1 v1.0.0, Section 4.2.3.3 “Companion Specifications,” 2023. https://reference.opcfoundation.org/specs/OPC-30500-1/4.2.3.3
- OPC Foundation, OPC 30500-1 v1.0.0, Section 4.1.2 “Introduction to the structure of a LADS Device,” 2023. https://reference.opcfoundation.org/specs/OPC-30500-1/4.1.2
- OPC Foundation, OPC 30500-1 v1.0.0, Section 3.2 “OPC UA LADS Terms,” 2023. https://reference.opcfoundation.org/specs/OPC-30500-1/3.2
- OPC Foundation, OPC 30500-1 v1.0.0, Section 5.1 “Automation,” 2023. https://reference.opcfoundation.org/specs/OPC-30500-1/5.1
- OPC Foundation, OPC 30500-1 v1.0.0, Sections 4.1.3–4.1.4, State machines and program/result lifetime, 2023. https://reference.opcfoundation.org/specs/OPC-30500-1/4.1.3
- OPC Foundation, OPC 30500-1 v1.0.0, Section 5.2 “Service and asset management,” 2023. https://reference.opcfoundation.org/specs/OPC-30500-1/5.2
- OPC Foundation, OPC 30500-1 v1.0.0, Section 9 “Profiles and Conformance Units,” 2023. https://reference.opcfoundation.org/specs/OPC-30500-1/9
- OPC Foundation, “OPC 10000-2: OPC Unified Architecture – Part 2: Security Model,” Version 1.05.06, 2025-10-22（2026年10月11日確認）. https://reference.opcfoundation.org/specs/OPC-10000-2
