SiLA 2の装置検出と接続管理｜UUID・証明書・バージョン対応

By /
SiLA 2の装置検出と接続管理のアイキャッチ

SiLA 2対応装置をネットワークにつなぐと、クライアントは利用可能なServerを探して接続します。しかし、一覧に表示された名前だけを見て接続すると、同名の別装置、交換済み装置、古いFeatureを実装したServerへ誤接続するおそれがあります。実験自動化では「見つかった」ことと「接続してよい」ことを分けて考えなければなりません。

この記事では、SiLA 2の装置検出を入口に、Server UUID、TLS証明書、Server Version、Feature Versionを照合し、意図した装置へ安全に再接続するための設計を解説します。規格上の識別情報、Python SDKの現在の実装、運用上の推奨を混同しないことがポイントです。

この記事で学べること

  • 「装置を発見すること」と「正しい装置だと確認すること」の違い
  • Server Name、Server UUID、IPアドレス、TLS証明書の役割分担
  • mDNS・DNS-SDを使う装置検出の仕組みと、VLANを越えにくい理由
  • 証明書更新、装置交換、ソフトウェア更新を安全に扱う方法
  • Server VersionとFeature Versionを使った互換性判定
  • Pythonで接続候補を「接続・確認待ち・拒否」に分類する実装例

結論：検出結果をそのまま信用せず、装置台帳と照合する

実務では、次の順に判定するのが安全です。

  1. 発見：ネットワーク上のSiLA Server候補と接続先アドレスを得る
  2. 識別：Server UUIDを装置台帳と照合する
  3. 認証：TLS証明書または組織の認証基盤で相手を確認する
  4. 互換性確認：必要なFeatureと許容バージョンを確認する
  5. 認可：そのクライアントや利用者が操作してよいかを判断する
  6. 接続：条件を満たした候補だけをワークフローへ組み込む

IPアドレスは通信経路、Server Nameは人が読む表示名、Server UUIDは継続的な識別子、証明書は接続相手の真正性を確かめる材料です。どれか一つで全部を代用しないことが重要です。

SiLA 2の装置検出と接続を整理する

SiLA 2では、装置側のソフトウェアをServer、装置を利用するワークフローや上位アプリケーションをClientとして扱います。Serverは一つ以上のFeatureを実装し、ClientはFeatureが定義するCommandやPropertyを利用します［1］。SiLA 2全体の通信・制御・標準の位置づけは、実験自動化の通信・制御・標準を整理するも参照してください。

検出は「候補の住所を知る」工程

装置検出の目的は、利用可能なServerのホスト名やIPアドレス、ポートなど、接続に必要な候補情報を得ることです。現在の公式Python SDKでは、ローカルネットワーク上のSiLAサービスをmDNS/DNS-SDで告知・探索する実装があり、サービス種別として _sila._tcp.local. を使います。また、SDKのサービス情報にはServer UUID、Server Name、説明、プロトコルバージョンなどが含まれます［2］。

ここで注意したいのは、これは現在の公式Python SDKの実装を説明したものであり、SiLA 2 Core Specificationのすべてを「mDNSしか使えない」と限定する説明ではないことです。固定アドレス、組織内DNS、構成管理データベース、オーケストレーターから接続先を与える方式もあり得ます。

mDNSとDNS-SDは何をしているのか

mDNS（Multicast DNS）は、通常のDNSサーバーがなくても、同一リンク上でDNSに似た名前解決を行う仕組みです。UDP 5353とリンクローカルのマルチキャストを使用し、.local. 名を扱います［3］。DNS-SD（DNS-Based Service Discovery）はDNSレコードを使って、特定種類のサービスがどこで動いているかを発見する仕組みです［4］。

この組み合わせにより、利用者がIPアドレスを手入力しなくても、同一ネットワーク内のServer候補を一覧化できます。試作ラインや研究室で、装置の追加・移動が多い場合には便利です。

mDNSが見つからない典型的な環境

mDNSの通信は原則としてローカルリンクの範囲です。そのため、次の環境では「Serverは起動しているのに見つからない」という事象が起こります。

  • ClientとServerが別のVLANまたは別サブネットにいる
  • 無線LANで端末間通信が遮断されている
  • ファイアウォールがUDP 5353やマルチキャストを遮断している
  • VPN経由でマルチキャストが転送されない
  • コンテナや仮想マシンのネットワークがホストから分離されている
  • 複数NICを持つPCで探索対象のインターフェースが違う

この場合、探索の再試行だけでは解決しません。ネットワーク設計を確認し、必要に応じてDNS-SDの集約、mDNSリフレクター、固定エンドポイント、装置レジストリなどを検討します。ただし、ブロードキャストドメインを安易に広げると、不要な装置の露出や運用複雑化を招きます。ネットワーク管理者と責任範囲を決めるべきです。

装置を識別する4つの情報

情報 主な役割 変化する場面 単独使用の問題
IPアドレス・ポート 通信先を指定 DHCP、移設、再起動、構成変更 別装置へ再割り当てされ得る
Server Name 人が装置を見分ける表示 命名変更、用途変更 同名や表記揺れが起こり得る
Server UUID Serverの継続的な一意識別 原則として変えない UUIDだけでは相手の真正性を証明しない
TLS証明書 暗号化と接続相手の認証 期限更新、鍵更新、CA変更 更新手続きがなければ正常更新を障害扱いする

Server Nameは表示名であり、主キーではない

「恒温槽A」「PlateReader-01」のような名前は人には便利ですが、重複、改名、全角・半角差、装置交換後の名前流用が起こります。画面表示やログの可読性には使えても、接続許可を決める唯一の識別情報には向きません。

Server UUIDは再起動のたびに作らない

SiLAServiceのFeature Definitionでは、Server UUIDはグローバルに一意であり、一度生成した後は継続して同じ値を提供する識別情報として定義されています［2］。一般にUUIDは128 bitの識別子で、中央登録を必要とせず空間・時間にわたる一意性を意図した形式です［6］。

したがって、Server起動時に毎回 uuid4() を呼んでUUIDを作り直す実装は避けます。初回登録時に生成し、設定ファイルや永続ストレージへ保存し、再起動・IP変更・軽微なソフトウェア更新後も維持します。

一方、物理装置そのものを交換した場合に旧UUIDを引き継ぐか、新UUIDにするかは資産管理方針が関わります。編集部では、トレーサビリティを優先し、原則として交換装置には新UUIDを付与し、旧資産との関係を台帳で記録する方法を推奨します。制御PCだけを交換し物理装置を継続使用する場合などは、リスク評価の上で明示的に移行します。

TLS証明書はUUIDと異なる役割を持つ

TLSは通信内容を暗号化し、証明書に基づいて通信相手を認証するためのプロトコルです。TLS 1.3はRFC 8446で規定されています［5］。Server UUIDが「どの論理装置として登録されているか」を表すのに対し、証明書は「この接続相手が信頼された鍵を保有しているか」を確認する材料です。

証明書の扱いには主に次の方式があります。

  • 組織内CA：組織の認証局が証明書を発行し、ClientはCAを信頼する
  • 証明書ピンニング：登録時の証明書または公開鍵の指紋を台帳に保存し、接続時に照合する
  • TOFU：初回接続時に見えた証明書を信頼し、次回から変更を検知する

TOFU（Trust On First Use）は小規模な閉域試験では導入しやすい反面、初回接続が正しい相手かを別経路で確認しないと、最初から偽のServerを登録する危険があります。装置本体のラベル、導入記録、管理画面、メーカー提供情報など、独立した経路でUUIDや証明書指紋を確認します。

証明書変更を「即拒否」だけで終わらせない

証明書には有効期限があり、鍵漏えいの疑い、CA更新、制御PC交換などでも変更されます。指紋が変わったからといって必ず攻撃とは限りません。しかし、自動的に新証明書を信頼すると、なりすましも受け入れてしまいます。

そこで接続判断を二値ではなく、次の3段階にします。

判定 条件例 動作
接続 UUID、証明書、必要Feature、許容Versionが一致 ワークフローへ接続
確認待ち UUIDは一致するが証明書指紋が変更 自動運転から外し、計画更新か人が確認
拒否 UUID不一致、TLS必須なのに平文、必須Feature欠落、非互換Major 接続せず記録・通知

証明書更新手順には、申請者、承認者、切替日時、新旧指紋、ロールバック条件を含めます。停止できない設備では、新旧証明書を一定期間併存させる方式も検討しますが、対応可否はServer実装とPKI方針を確認してください。

Server VersionとFeature Versionを分けて管理する

SiLAServiceはServer Versionと実装Featureの一覧・定義を公開するための基盤になります［2］。ここで、Server全体の版と個々のFeatureの版は意味が異なります。

  • Server Version：Serverソフトウェア全体のリリースや実装版
  • Feature Version：Command、Property、Data Typeなどのインターフェース契約の版

上位ワークフローが依存するのは、多くの場合「温度設定Feature 1.x」「測定開始Feature 2.x」のような具体的な契約です。Server Versionが更新されても必要Featureが互換なら動く可能性があります。逆にServer Versionの表記が同じでも、必要Featureが欠落したり非互換に変わったりすれば動きません。

互換性判定の実務方針

規格のバージョン表記だけから、あらゆる実装の互換性を自動保証することはできません。編集部では、次の保守的な方針を推奨します。

  1. 必要なFeature IDと最低Versionをワークフローごとに記録する
  2. Major Versionが異なる場合は自動接続を拒否する
  3. 同じMajorで古いMinorなら、必要機能不足として拒否する
  4. 同じMajorで新しいMinorなら、警告を出して検証環境で回帰試験する
  5. 接続可否だけでなく、単位、範囲、エラー、長時間Commandも試験する

「同じMajorなら必ず安全」という意味ではありません。上記は編集部の運用推奨であり、最終的にはFeature Definition、SDKの互換性規則、メーカーの変更履歴、実機試験を組み合わせて判断します。

装置台帳に持つべき情報

IPアドレスだけの台帳では、DHCPや装置交換に追従できません。最低限、次の情報を管理します。

項目 例 用途
資産ID LAB-TEMP-001 設備・保全台帳との結合
Server UUID 7a78f2bc-… 論理Serverの照合
期待するServer Name TemperatureController-A 人向け表示と改名検知
証明書指紋またはCA SHA-256値 接続相手の認証
必要Featureと最低Version TemperatureController 1.2 ワークフロー互換性
許容Server Major 2 大規模更新の誤接続防止
ネットワーク区域 LAB-VLAN-20 探索・FW設計
所有者・承認者 装置管理チーム 変更時の責任明確化
最終確認日時 2026-10-13 情報鮮度の管理

装置データを後工程へ統合する考え方は、実験データをPythonで統合する方法、自動化システム全体の役割は実験自動化とは何かにもつながります。

導入から更新までの接続管理手順

1. 初回登録

  1. 隔離または導入用ネットワークでServerを起動する
  2. 検出結果からアドレス、Server Name、UUID、Version、Featureを取得する
  3. 装置ラベルや導入記録など別経路で対象装置を確認する
  4. TLS証明書チェーンまたは指紋を確認する
  5. 必要Featureを呼び出す受入試験を行う
  6. 承認者が装置台帳へ登録し、本番ネットワークで接続を許可する

2. 通常の再接続

検出した候補をUUIDで台帳へひも付け、証明書、Server Version、必要Featureを順に照合します。IPアドレスが変わっていても、他の条件が一致すれば接続できます。逆にIPアドレスが同じでもUUIDが違えば拒否します。

3. 証明書更新

事前に変更申請へ新しい証明書情報を登録し、切替時にUUID、装置資産、署名元、指紋を再確認します。予定外の変更は「確認待ち」にし、ワークフローを自動再開しません。

4. 装置交換

旧装置のUUIDを無条件に複製せず、新しい装置を新規登録します。分析結果や監査ログには旧・新資産の関係と切替時点を残します。交換後に同じServer Nameを使う場合でも、UUIDと証明書は再審査します。

5. Server・Feature更新

本番更新前にステージング環境または模擬ワークフローで、接続、Command、Property、データ型、単位、エラー応答、タイムアウト、キャンセルを試験します。自律実験では誤接続が次の条件提案まで連鎖するため、自律実験・Self-driving Labの考え方と合わせ、承認境界を設計します。

Pythonで接続ポリシーを実装する

以下は、検出ライブラリそのものではなく、検出後の候補を台帳と照合する最小実装です。標準ライブラリだけで動き、UUID、証明書のSHA-256指紋、Server Major、必要Feature Versionを判定します。

from hashlib import sha256

known = KnownServer(
    asset_id="LAB-TEMP-001",
    server_uuid="7a78f2bc-31fb-4d2a-8891-4c2ce98b05b7",
    expected_name="TemperatureController-A",
    certificate_sha256=sha256(certificate_der).hexdigest(),
    required_features={"TemperatureController": "1.2"},
    allowed_major_version=2,
)

discovered = DiscoveredServer(
    address="192.0.2.10",
    port=50052,
    server_name="TemperatureController-A",
    server_uuid="7a78f2bc-31fb-4d2a-8891-4c2ce98b05b7",
    server_version="2.4.1_lab",
    tls_enabled=True,
    certificate_der=certificate_der,
    features={"TemperatureController": "1.3"},
)

result = assess_connection(discovered, known)
print(result.decision, result.reasons, result.warnings)

この例では、必要最低Version 1.2に対して実装が1.3なので接続可能としつつ、「承認済み基準より新しい」という警告を出します。完全なコードとテストファイルは記事付属資料に含めています。

実行方法

python device_connection_policy.py
python -m unittest -v test_device_connection_policy.py

検証では、正常接続、UUID不一致、証明書変更、TLS無効、必須Feature欠落、Feature Major不一致、名前変更など9ケースを実行しました。証明書変更は確認待ち、UUID不一致と非互換は拒否、表示名の変更だけなら警告という結果です。

実システムへ組み込むときの拡張

  • 実際のSiLA ClientからSiLAService情報とFeature Definitionを取得する
  • X.509証明書チェーン、有効期限、失効情報、ホスト識別を検証する
  • 判定結果と接続先を監査ログへ残す
  • 台帳更新を権限管理し、アプリ利用者が勝手に指紋を書き換えられないようにする
  • 証明書や秘密鍵をソースコードへ直接書かず、秘密情報管理基盤を使う

サンプルの指紋照合は考え方を示すもので、PKI検証の完全実装ではありません。

よくある失敗と対策

失敗1：Server Nameだけで自動接続する

同名Serverや名前流用で誤接続します。UUIDと証明書を併用し、名前は表示・警告用にします。

失敗2：IPアドレスを装置IDとして保存する

DHCPや再構成で別装置へ割り当てられます。IPは現在の経路としてキャッシュし、主キーにはServer UUIDや資産IDを使います。

失敗3：Server起動のたびにUUIDを生成する

再起動だけで新しい装置に見え、承認・履歴・キャッシュが壊れます。UUIDを永続保存します。

失敗4：探索結果に含まれる証明書情報を無条件に信頼する

未認証の探索情報と信頼の起点を同じ経路にすると、なりすましを見抜けません。CA、事前配布された指紋、現物確認など独立した信頼経路を用意します。

失敗5：証明書更新を計画しない

期限当日に突然接続できなくなるか、現場が検証を無効化します。有効期限監視と更新手順を運用開始前に決めます。

失敗6：Feature Versionを無視する

接続自体は成功しても、Command、データ型、単位、エラー処理が合わない可能性があります。ワークフローが必要とするFeature契約を管理します。

失敗7：見つからないときにネットワーク全体を開放する

原因がVLANやマルチキャスト制御でも、無制限な許可は露出範囲を広げます。必要な通信、方向、区域、ポートを特定して最小限に設定します。

技術的限界・安全・責任範囲

装置を正しく識別できても、実験操作そのものが安全とは限りません。SiLA接続管理は、安全PLC、非常停止、扉インターロック、温度・圧力上限、薬品適合性、作業手順を代替しません。危険側へ動く可能性のあるCommandは、装置側の安全制御で制限し、ネットワークやPythonだけへ依存しないでください。

また、mDNS/DNS-SDの動作はOS、ネットワーク機器、無線設定、コンテナ構成で異なります。Python SDKの探索レコードや証明書処理も更新され得ます。この記事は2026年10月13日に公式資料と公式Python SDK v0.14.0のソースを確認して作成しました。導入時は使用するSpecification、SDK、Server実装の版を固定して確認してください。

責任分担は、装置メーカーがServer実装と装置安全、IT部門がネットワークとPKI、研究開発部門が装置台帳とワークフロー妥当性、システム所有者が変更承認と監査を担う形が一例です。組織規程と法規制に合わせて明文化します。

接続管理チェックリスト

  • Server UUIDは初回生成後に永続保存されているか
  • Server Nameだけで接続を許可していないか
  • IPアドレス変更と装置交換を区別できるか
  • 証明書チェーンまたは指紋を独立した信頼経路で確認したか
  • 証明書の期限監視と更新承認手順があるか
  • 必要Featureと最低Versionをワークフロー単位で記録したか
  • Major変更時に自動接続を止められるか
  • mDNSが届かないネットワークで代替の接続先管理があるか
  • 判定結果、変更者、承認者、日時を監査ログへ残すか
  • 通信切断時に二重実行せず安全停止できるか
  • 装置側インターロックをネットワーク制御から独立させたか

FAQ

Q1. Server UUIDが同じなら証明書は確認しなくてよいですか？

いいえ。UUIDは識別子であり、提示した相手が本物であることを暗号学的に証明するものではありません。UUIDと証明書または信頼済みCAを併用します。

Q2. IPアドレスが変わると再登録が必要ですか？

通常は不要です。UUID、証明書、Featureが一致するなら、新しいアドレスを現在の通信経路として更新できます。ただしネットワーク区域を越える変更は承認対象にするのが安全です。

Q3. mDNSはルーターを越えますか？

標準的なmDNSはリンクローカルです。別VLANや別サブネットでは通常そのまま届きません。ネットワーク設計に応じ、組織内DNS-SD、リフレクター、固定接続先、装置レジストリを検討します。

Q4. 自己署名証明書は使えませんか？

閉域の小規模環境で、指紋を安全に事前配布し、更新手順を持つなら選択肢になります。ただし装置数が増えるほど配布・更新・失効管理が難しくなるため、組織内CAの方が管理しやすい場合があります。

Q5. 証明書指紋が変わったら自動更新してよいですか？

推奨しません。計画された更新か、接続相手の変更かを別経路で確認し、承認後に台帳を更新します。自動更新すると、なりすましを正規装置として記録する危険があります。

Q6. FeatureのMinor Versionが上がったらそのまま使えますか？

自動的に安全とは断言できません。同じMajorを互換候補として扱うことはできますが、変更履歴とFeature Definitionを確認し、主要Command・Property・エラー処理の回帰試験を行います。

まとめ

SiLA 2の装置検出は、自動接続を便利にする入口ですが、それだけで正しい装置・安全な接続・互換性を保証するものではありません。IPアドレスは経路、Server Nameは表示、Server UUIDは継続的識別、TLS証明書は相手認証という役割を分け、必要FeatureとVersionまで照合します。

実務では、初回登録で信頼の起点を作り、通常接続では台帳と自動照合し、証明書変更は確認待ち、UUID不一致や非互換は拒否する3段階の運用が有効です。これにより、装置の移設・更新・交換があっても、「つながったから使う」ではなく「意図した装置へ、承認された契約で接続する」仕組みへ近づけます。

参考文献

  1. SiLA Consortium, “SiLA Standards,” SiLA 2 Core / Feature Definition / Mapping specifications, 参照日 2026-10-13. https://sila-standard.com/standards/
  2. SiLA2 Project, “sila_python,” official Python implementation, v0.14.0 source and SiLAService Feature Definition, 参照日 2026-10-13. https://gitlab.com/SiLA2/sila_python
  3. S. Cheshire, M. Krochmal, “Multicast DNS,” RFC 6762, IETF, 2013. https://www.rfc-editor.org/rfc/rfc6762
  4. S. Cheshire, M. Krochmal, “DNS-Based Service Discovery,” RFC 6763, IETF, 2013. https://www.rfc-editor.org/rfc/rfc6763
  5. E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, IETF, 2018. https://www.rfc-editor.org/rfc/rfc8446
  6. K. Davis et al., “Universally Unique IDentifiers (UUIDs),” RFC 9562, IETF, 2024. https://www.rfc-editor.org/rfc/rfc9562

Related Posts

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA


上部へスクロール