機器検出

ドライバーに機器や点を探させること、それぞれのスキャンが何を必要として何を返すか、進行と取りやめの振る舞い、結果の追加、そして Bluetooth 越しの Matter の機器のペアリング。

プロトコルが本当のスキャンに対応しているドライバーでは、機器検出が機器や点を探してくれるので、自分で入力する必要はありません。検出はドライバーのノードのコマンドバーにあり（Modbus RTU ではシリアル回線のページの「ユニットを検出」のカードにあります）、スキャンが取るものはドライバーのページの「スキャンの範囲」のカードにあります。バーがコマンドを持ち、カードがその範囲を持つわけです。すべてに Connector の構成が必要で、そのビットのないロールには範囲のカードもボタンも描かれません。実行がステーションを占有しているあいだ、またはランタイムが停止しているあいだ、スキャンは拒否されます。スキャンが何も返さなかったとき、それは機能の欠落ではなくスキャンの結果です。ボタンは、スキャンが結果を出せるところにだけ出るからです。

どのドライバーがスキャンするか

Siemens S7、Beckhoff ADS、Mitsubishi MC、IEC 61850、LoRaWAN、HTTP にはスキャンがなく、ボタンも出ません。ボタンは内蔵サーバーが動き出してから初めて出ます。スキャンが走れるかどうかに答えるのは、サーバー自身のドライバーの一覧だからです。そして、このバージョンが導入するドライバーにだけ出ます。一覧がアプリケーションの知らないアセンブリで答えた場合、ボタンは出ず、導入されているドライバーがこのバージョンの出荷したものではないことが Events のページに記録されます。

Modbus TCP：「スキャンの範囲」のカード

このカードは Modbus TCP のドライバーのページに出ます：「機器の識別だけを読み取ります。レジスターは追加のあとで設定します。」

項目の下の行は見積もりです：「ホスト 2 件 × ユニット ID 3 件 = 探索 6 回 · 上限 256。」で、設定していれば「· ホストごとに 100 ms の休止。」が付きます。1 回のスキャンが送れる探索は最大で 256 回です。上限を超えると行は赤くなり（「このスキャンは探索を 512 回送ります。ネットワークかユニット ID の範囲を 256 回以下に減らしてください。」）、検出が灰色になります。入力の誤りも同じように名指しされます（「「10.0.0」は正しい 4 オクテットの IPv4 アドレスではありません。」「CIDR の接頭長は /24 から /32 のあいだである必要があります。」「ユニット ID を 1 つ以上入力してください（0〜255）。」「ユニット ID の範囲「9-3」は昇順である必要があります。」）。範囲の項目を変えると、前のスキャンの結果は捨てられます。それは別の範囲を説明していたものだからです。同時にスキャンするホストは最大 4 つ、ホストごとに接続 1 つです。

Modbus RTU

このスキャンはドライバーではなく回線のページにあります。ユニット ID の開始とユニット ID の終了（1 から 247、昇順。既定は 1 から 32）と、専用の検出のボタンがあり、最悪の場合の見積もりが添えられます（「探索 32 回 · 最大およそ 32.1 秒。各探索の前に置く 4.011 ms の休止を含みます。」）。スキャンは回線の保存済みの設定でポートを一度だけ開き、各ユニットを順に探索し、動いている回線を中断する代わりに拒否します：「この回線は使用中です。機器検出の前に無効にしてください。Ganter Lab がバスを勝手に中断したり、有効に戻したりすることはありません。」回線に未保存の編集があれば、スキャンが始まる前に保存されます。保存できないときはスキャンが始まりません（「シリアル回線の編集を保存できなかったため、機器検出は始まりませんでした。」）。そのカードの残りはシリアル回線のページで扱います。

Redfish と AVEVA PI：スキャンが読むサービス

Redfish のサービスも PI System も、このステーションが聞き取れるネットワーク上で自分を知らせないので、この 2 つのスキャンは、ドライバーのページの「スキャンの範囲」のカードで指し示した 1 つのサービスを読みます。Redfish はサービスのアドレス（https://bmc-host、別の場所で答えるなら https://bmc-host:8443）を取り、必ず HTTPS で読みます。要求のたびに機器の資格情報が乗るからです。平文のトランスポートを求めるアドレスは、入力したその場で拒否されます。AVEVA PI はサービスのアドレスと、# のあとに、巡回を始める AF の要素を取ります：https://pi-host/piwebapi#\\AF-SRV\Plant\Line 3。その要素がなければ巡るものがないので、検出は灰色になり、何が要るかを伝えます。

どちらのスキャンも資格情報なしでサービスを読みます。それを持つはずの機器がまだ存在しないうちに走るからです。したがって、すべての要求を認証するサービスは何も答えず、スキャンは何も見つけません。そのサービスは手で追加し、その点も一緒に入れてください。

スキャンを走らせる

スキャンが動いているあいだ、ドライバーのページは状態の行を書き、バーの検出は中止に変わります。状態は互いに独立した 2 つの段階、つまり接続先の検出とチャネルの巡回から来ます：「接続先をスキャンしています…」「接続先 2 を調べています…」「opc.tcp://plc:4840 からチャネルを読んでいます…」、そして「機器 3 台を見つけました。」。自分で進み具合を報告するドライバーは、「OPC UA サーバー … に公開エンドポイントを問い合わせています…」「エンドポイント 2 件を見つけました。」「Rockwell のコントローラーを探しています…」「BACnet の機器をスキャンしています…」「参加処理済みの Matter のノード 2 件中 1 件を調べています…」「ホスト 2 × ユニット ID 3 をスキャンしています…」「ユニット 5 を探索しています（32 件中 5 件目）…」と伝えます。ドライバーのエラーで止まったスキャンは、見つけたものを保ってそう伝えます：「機器 1 台を見つけたあと、スキャンはエラーで止まりました。一覧は不完全かもしれません。」チャネルを読めなかった接続先も、タグ 0 件として並びます。

スキャンは、動いているあいだそのドライバーを占有します。終わるまで、別のノードを選ぶこと（「機器の操作を使う前に、機器検出を中止してください。」）、機器や回線を追加すること、回線を有効または無効にすること、行の操作を使うことはできません。結果は、そのスキャンを始めたウィンドウのものです。同じステーションの別のブラウザーのタブからは見えません。

取りやめる

中止（押すと「中止しています…」）は、両方の段階を止めます。取りやめの前に完全に用意できた候補は並んだまま残り、チャネルをまだ読んでいた接続先は捨てられます。状態には「機器検出を中止しました。」、操作ログ帯には「OPC UA の機器検出を中止しました。完了した結果 2 件は残しています。」と出ます。スキャンは、ドライバーの一時的なソケット、クライアント、セッションが閉じるまで占有したままです。2 秒たつと、状態は「ドライバーが機器検出の資源を解放するのを待っています…」と伝えます。すでに止まったふりをしないためです。ドライバーは、頼まれた瞬間に必ず手放すとは限らないからです。

結果

検出した機器のカード（回線では検出したユニット）は、候補ごとに 1 枚のカードを並べます。編集できる名前、接続先、そして「タグ 5 件中 2 件を選択中」です。その下に候補のタグの小さなグリッドがあり、追加のチェック（既定はオン）、タグ、型、アクセスが並びます。ひとつもなければ「タグの報告はありませんでした。機器を追加してから、その編集画面でタグを設定してください。」と出ます。カードの機器を追加を押すまで（実行中は「追加しています…」）、何も保存されません。押すと、ドライバーの中で一意な名前で、チェックの入ったタグだけを持つ機器が作られ、カードは一覧から消え、ページが新しい機器に開き、操作ログ帯には「「Pump」をタグ 3 件とともに追加しました。」と出ます。検出されたタグは、ドライバーが報告したとおりに読み取り専用か書き込み可能で届き、その型と既定の変換経路を持ちます。ほかに推測されるものはありません。

すでに持っている機器と一致する候補は設定済みと示され、追加の代わりに開くを出すので、スキャンがうっかり重複を作ることはありません。一致を見るのは安定した識別名だけ、つまり同じ回線上の Modbus RTU のユニットと、Matter のノード ID です。ほかのドライバーは何とも一致させません。届く接続先があることは、それが同じ設備である証拠にならないからです。

閉じるは一覧を消し、スキャンを待ちます。スキャンが動いているあいだは灰色です。スキャンの途中で一覧を消すことは、そのスキャンを取りやめ、すでに答えていたものをすべて捨てることでもあるからです。別のドライバーを選んでも、範囲を変えても消えます。スキャンが動いているあいだ、機器やタグの削除と、機器をフォルダーに移すことも同じ理由で灰色になります。スキャンがドライバーを占有しているので、確認したあとでコマンドが失敗することになるからです。Modbus RTU ではユニット ID が独立した列になり、回線にすでに設定されている ID は追加時に拒否されます：「ユニット 5 は「Line 1」にすでに設定されています。」

Matter の機器をペアリングする

Matter は、ここに機器が存在するより前に、実機を Bluetooth 越しに参加させます。そのため Matter のドライバーの最初のコマンドは機器を追加ではなく機器をペアリングで、ドライバーのページ上にフォームを開きます（新規…のメニューとドライバーの右クリックメニューにも同じものが出ます）。ペアリングには、Connector の構成、このコンピューターで使える Bluetooth LE の無線、そしてデータセットを入手できる既存の Thread ネットワークが必要です。フォームもそう伝えます：「先に実機をペアリングモードにしてから進んでください。ペアリングにはこのコンピューターの Bluetooth を使います。」

機器をペアリングは、3 つとも埋まり、ステーションが変更を受け付けるようになると押せます。フォームはそこから検証、探索、ペアリング、Thread 参加、保存の 5 段階を進み、その下に状態の行が出ます：「セットアップコードと Thread のデータセットを検証しています…」「Bluetooth で機器を探しています…」「機器を認証してペアリングしています…」「既存の Thread ネットワークの設定を送っています…」「機器が Thread ネットワークに参加するのを待っています…」「参加処理済みのノードをローカルの Fabric に保存しています…」「ペアリングが完了しました。」中止が受け付けられるのは、一致する広告が選ばれるまでです（「機器が変更される前に止めます」）。そこから先、ボタンは「安全に終わらせています…」となります。機器がすでに変更されており、途中で離れてもステーションはそのノードを記録しなければならないからです。閉じるは、何も動いていないときにフォームを閉じます。

成功すると、機器はノード ID だけを識別名として作られ（セットアップコードとデータセットは保存も記録もされず、二度と表示されません）、ページがそこに開き、操作ログ帯には「Matter の機器「Kitchen light」をペアリングしました。」と出ます。ノードは参加したのに機器を作れなかったときは、操作ログ帯がそう伝え、検出が立て直しの道になります。失敗ははっきりと伝えられ、やり直せるようにフォームは開いたままになります。コードやデータセットが正しくない、使える Bluetooth のアダプターがない、Bluetooth が拒否されたか切られている、一致する機器がない（「ペアリングモードにして、近くに置いてやり直してください。」）、セットアップコードが拒否された、機器が Thread ネットワークに参加しなかった（そのノードは Fabric に残り、検出で取り戻せます）、Fabric を保存できなかった（機器はすでに参加処理を終えている場合：「Fabric の保存の問題が解決するまで、機器をリセットしないでください。」）、またはほかのペアリングがすでに動いている、といった場合です。ペアリングは一度に 1 つだけです。動いているあいだ、そのドライバーを離れることはできません（「Matter のペアリングが終わるまで、このドライバーを離れられません。」）。

機器検出がしないこと

スキャンがそれ自体で何かを保存することは決してなく、既存の機器を変えることも、自分でもう一度走ることもありません。サブネット、レジスターの割り付け、シリアルの設定を推測せず、回線を有効にも無効にもせず、一覧から消した候補を現場設備から取り除きもしません。パッケージが持たないドライバーでは拒否されます。それぞれのドライバーの結果に何が入るかは、ドライバーの下にあるそのドライバーのページにあります。