機器検出

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

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

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

Beckhoff ADS、Mitsubishi MC、LoRaWAN、HTTP、Generic serial and TCP にはスキャンがなく、ボタンも出ません。ボタンは Connector が動き出してから初めて出ます。スキャンが走れるかどうかに答えるのは、Connector のドライバーの一覧だからです。そして、このバージョンが導入するドライバーにだけ出ます。一覧がアプリケーションの知らないアセンブリで答えた場合、ボタンは出ず、導入されているドライバーがこのバージョンの出荷したものではないことが 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。その要素がなければ巡るものがないので、検出は灰色になり、何が要るかを伝えます。

どちらのスキャンも資格情報なしでサービスを読みます。それを持つはずの機器がまだ存在しないうちに走るからです。したがって、すべての要求を認証するサービスは何も答えず、スキャンは何も見つけません。そのサービスは手で追加してください。そのあと Redfish の機器は、機器と同じようにサインインする、自分のページのタグ検出で点を見つけます。AVEVA PI の機器の点は手で追加します。

スキャンを走らせる

スキャンが動いているあいだ、ドライバーのページは状態の行を書き、バーの検出はキャンセルに変わります。状態は互いに独立した 2 つの段階、つまり接続先の検出とチャネルの巡回から来ます：「endpoint をスキャンしています…」「endpoint 2 を調べています…」「opc.tcp://plc:4840 からチャネルを読み取っています…」、そして「機器を 3 台見つけました。」。自分でスキャンを行うドライバーはどこまで進んだかだけを伝え、ページが数えます。「機器検出の進み具合：2 件中 1 件…」。Modbus の 2 つのスキャンだけは行全体を書きます。ポート、ホスト、ユニット ID こそが見守る人の読むものだからです：シリアルの回線では「COM7 をスキャンしています · 探索 32 回…」「ユニット 5 を探索しています（32 件中 5 件目）…」「32 件中 5 件を探索しました。ユニット 5 を確認しました。」「探索 32 回を終えました。」、ネットワークでは「ホスト 2 件 × ユニット ID 3 件 をスキャンしています…」「192.168.0.10:502 · ユニット 3 を探索しています…」「つながらないホスト 192.168.0.11:502 を飛ばしました。」と伝えます。Rockwell のスキャンは同報を出したネットワークを名乗ります。「192.168.0.255, 10.0.0.255 で Rockwell のコントローラーを探しています…」ですので、結果が 0 件でも問いがどこへ行ったかが分かります。ドライバーのエラーで止まったスキャンは、見つけたものを保ってそう伝えます：「機器を 1 台見つけたところで、エラーによりスキャンが止まりました。一覧は不完全かもしれません。」チャネルを読めなかった接続先も、タグ 0 件として並びます。

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

取りやめる

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

結果

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

すでに持っている機器と一致する候補は設定済みと示され、追加の代わりに開くを出すので、スキャンがうっかり重複を作ることはありません。一致を見るのは安定した識別名だけ、つまり同じ回線上の Modbus RTU のユニット、同じブローカー上の Sparkplug B のエッジノードか機器、同じ VISA リソースの SCPI 測定器、NI MAX の同じ名前の NI-DAQmx 機器、機器を通して、または同じホストとポートでスキャンした SNMP エージェント、File の機器が同じフォルダーから同じ名前、同じ読み方で読むファイル、自身の Database の機器を通してスキャンしたデータベース、名前で読む機器と同じホストにある Siemens の CPU、Matter のノード ID です。ほかのドライバーは何とも一致させません。届く接続先があることは、それが同じ設備である証拠にならないからです。Matter の設定済みの機器、SNMP の設定済みのエージェント、File の設定済みの機器、Database の設定済みの機器、名前で読む Siemens の設定済みの機器は、一致してもまだ受け取るものがあります。そのカードには、機器が公開していてまだタグのない値がチェック付きで並び、開くの前にあるタグにして追加が、チェックした値をその機器に追加します（Matter、SNMP、File、Database、Siemens S7を参照）。

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

機器のタグを検出する

すでにある機器は、ドライバーのページに戻らなくても、さらに点を読めます。ドライバーが一台の機器の点を読めるところでは、その機器の「タグ」のカードの見出しに、タグを追加と並んでタグ検出があります。スキャンはその機器だけを、保存されているとおりに読み（保存を待っている編集があれば先に保存されます）、機器が公開する値のうち、まだタグがないものだけを一覧にします。比べるのはそれぞれが読む点で、名前では比べません。機器が別の名前ですでに読んでいる値は、もう一度は出てきません。

AVEVA PI にはタグ検出が出ません。巡回は AF 要素から始まり、その要素を機器は持っていないので、点はドライバーの機器検出から来るか、手で追加します。Modbus、BACnet、Omron、SCPI、それにスキャンのないドライバーは点を見つけないので、やはり出ません。

スキャンのあいだ、タグ検出はキャンセルに変わり、「タグ」のカードの上に状態の行が出て、スキャンはドライバー自身の機器検出とまったく同じようにドライバーを占有します。ドライバーを必要とするコマンドは描かれたまま灰色になり、理由を示します。タグ検出そのものも、ステーションが変更を受け付けないあいだ、別のスキャンやペアリングがドライバーを占有しているあいだ（「このドライバーで機器検出のスキャンが動いています。終わるまでお待ちください。」）、そして機器がまだアドレスを待っているか、保存が拒む項目を持っているあいだは灰色になります。Connector の構成が必要で、そのビットのないロールにはボタンが描かれません。

スキャンが見つけたものは、「タグ」のカードのすぐ上の検出したタグのカードに出ます。どの値にもチェックが入り、タグ、型、アクセスが並び、名前の下には、ドライバーのページのカードと同じく、ドライバーが点を見つけたより長い場所が出ます。カードの見出しのタグにして追加は、チェックした値を機器に、それぞれ一度ずつ、機器のタグがすでにその名前を持っていれば番号を付けて加え、機器を保存します。新しいタグは画面に残る「タグ」のカードの表で強調表示され、操作ログ帯には「「Line PLC」にタグを 2 件追加しました。」と出ます。残った値は一覧に残り、閉じるでカードを空にします。公開するすべての値にタグがすでにある機器にはそう伝え（「「Line PLC」が公開するすべての値にタグがすでにあります。」）、スキャンが何も読めなかった機器にも伝えます（「スキャンで「Line PLC」の値が見つかりませんでした。機器が応答するか確認してから、もう一度タグ検出を実行してください。」）。ドライバーを離れると、ドライバーの結果と同じくカードも空になります。

ドライバー自身の機器検出は、まだない機器をこれまでどおり見つけ、その「検出した機器」のカードも変わりません。

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

Matter は、ここに機器が存在するより前に、実機を Bluetooth 越しに参加させます。そのため Matter のドライバーの最初のコマンドは機器を追加ではなく機器をペアリングで、ドライバーのページ上にフォームを開きます（新規…のメニューとドライバーの右クリックメニューにも同じものが出ます）。ペアリングには、Connector の構成、このコンピューターで使える Bluetooth LE の無線、そして機器が参加するネットワークが必要です。ネットワークは、先にドライバーのネットワークカードに登録しておきます。Wi-Fi の名前とそのパスワード、または Thread ネットワークとそのデータセットです（ネットワークを参照）。そこに使えるネットワークがないあいだ、機器をペアリングは淡色のままで、ツールチップは「先に、機器が参加するネットワークを追加してください。」です。フォームは次のように伝えます：「続ける前に、物理的な機器をペアリングモードにしてください。ペアリングには、このコンピューターの Bluetooth を使います。」

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

成功すると、機器はノード ID を識別として、参加したネットワークの名前を読み取り専用のネットワークの欄に入れて作られ、操作ログ帯には「Matter 機器「キッチンの照明」をペアリングしました。」と出ます。続いてページは Matter のドライバーに開き、新しい機器を機器の表で強調表示して、その機器だけをスキャンします。そのカードには機器が公開する値がチェック付きでタグにして追加の横に並び、スキャンは「「キッチンの照明」でタグにする値にチェックを入れてから、「タグにして追加」を押してください。」で終わります。機器が何を出し、それぞれの値が何をするかはMatterにあります。セットアップコードは保存も記録もされず、二度と表示されません。ネットワークのパスワードやデータセットはネットワークカードに残り、この Windows ユーザー用に暗号化して保存され、機器にも、そのアドレスにも、ログにも届きません。ノードは参加したのに機器を作れなかったときは、操作ログ帯がそう伝え、検出が立て直しの道になります。失敗ははっきりと伝えられ、やり直せるようにフォームは開いたままになります。コードが正しくない、ネットワークの名前やパスワードやデータセットが正しくない、使える Bluetooth のアダプターがない、Bluetooth が拒否されたか切られている、一致する機器がない（「ペアリングモードにして、近くに置いてやり直してください。」）、セットアップコードが拒否された、機器がもう一方の種類のネットワークかケーブルで参加する（機器には何も書き込まれません）、機器がネットワークに参加できなかったと応えた（見つからない Wi-Fi の名前、拒否されたパスワード、そのほかの拒否。機器は何も残さずペアリングモードに戻るので、ネットワークを直してペアリングし直します）、機器が応えずローカルのネットワークにも現れなかった（そのノードは Fabric に残り、検出で取り戻せます）、Fabric を保存できなかった（機器はすでに参加処理を終えている場合：「Fabric の保存の問題が解決するまで、機器をリセットしないでください。」）、またはほかのペアリングがすでに動いている、といった場合です。それぞれの失敗が機器に何を残すかはペアリングが失敗したときにあります。ペアリングは一度に 1 つだけです。動いているあいだ、そのドライバーを離れることはできません（「このドライバーを離れる前に、Matter のペアリングが終わるのをお待ちください。」）。

機器検出がしないこと

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