現場設備へのアクセス

Connector が接続する OPC UA の現場設備の証明書です。承認を待っているもの、承認したもの、遮断したもの、最初の接続の前に証明書を取り込むこと、そして待っている機器が Connector で何を述べるかです。

現場設備へのアクセスは、設定のページの OPC UA 現場設備の組のただ 1 つの行です。証明書の信頼の、出ていく側の半分です。Connector が OPC UA の現場設備サーバーに接続すると、そのサーバーは証明書で自分が何かを示します。そして、あなたが証明書を承認していない現場設備から、ステーションは何も読みません。カードの頭がそう述べます。「Connector が OPC UA の現場設備サーバーに接続すると、そのサーバーは証明書で自分が何かを示します。設備を立ち上げた担当者と照合したフィンガープリントだけを承認してください。」このページを開くには 設定の変更 の権限が要り、判断はステーション自身のデスクトップで行います。

頭の下の原則です。「承認していない現場設備からは、何も読み取りません。証明書がここで待っている機器は黙ったままになり、Connector にその旨が出ます。承認すると読み取りが始まり、承認を取り下げるとセッションが閉じて、ふたたび確認を求めます。証明書の名前は設備が名乗っているだけなので、確かめるべき身元は SHA-256 のフィンガープリントです。」

このカードは意図して クライアントアクセス と同じ形にしてあり、考えが同じところでは言葉も同じで、誰が決められるかの決まりも同じです。別の端末のブラウザーには「現場設備へのアクセスは、ステーションのデスクトップアプリでのみ変更できます。」と、通知バー「現場設備へのアクセスを変えるには、デスクトップアプリを開いてください」が出ます。設定の変更を持たないロール、実行中のユニット、止まっているランタイム、すでに進行中の変更は、それぞれ自分の文で拒みます。どの結末もステータスバーに出ます。

待っている機器が Connector で何をするか

Connector が OPC UA の機器に初めて接続すると、その現場設備の証明書は拒まれ、ここに待っているものとして記録され、その機器は何も読みません。機器のページ で、Connector は注意の通知バー 証明書の承認待ち を見せ、この節をその機器の行の上で開く 証明書を確認する のボタンを添えます。ツリーの中でも、その機器の稼働状態が同じ状態を名乗ります。ドライバー自身の失敗は、名前のない握手のエラーではなく、その理由を述べます。「この現場設備の証明書（フィンガープリントの最初の 16 文字）は、設定の現場設備へのアクセスであなたの承認を待っています。承認すると読み取りが始まります。」遮断されているものは「…はこのステーションで遮断されています。設定の現場設備へのアクセスで確認してください。」と読めます。機器検出の閲覧も、そのセッションが開く前に同じ関門を通ります。

承認されると、Connector は次の試行から読み取りを始めます。読み取れていた現場設備が、同じアドレスで違う証明書を提示し始めると、読み取りは止まり、貼り付くカード「証明書が変わりました：<名前>」が立ちます。「<アドレス> の現場設備は、このステーションが承認した証明書で読み取られていましたが、いまは別の証明書（…）を提示しているため、そこからは何も読み取っていません。設備を保守している担当者とフィンガープリントを照合してから承認してください。」確認する が添えられ、ウィンドウが隠れているときは Windows の知らせも出ます。いま登録している最中の機器が、こうして知らされることはありません。それを登録している人は、すでに Connector を見ているからです。

承認待ち

少なくとも 1 つの証明書が待っている間に描かれ、「これらの機器は、判断するまで読み取られません。」を見出しに、件数を添えます。各行は、琥珀の点、証明書が名乗る名前、「名乗っている現場設備の身元」、フィンガープリント、「<アドレス> · 最後の試行 <日時> · 接続の試行 N 回」、そして 証明書の詳細 の開閉（サブジェクト、発行者、アプリケーション URI、ドメイン名、有効期間の開始、有効期間の終了、最初に見た日時）を見せます。確認するのボタンが導いた行には「確認のために選択中」と印が付き、見えるところまで送られます。

この一覧は最大で 100 件の証明書を持ちます。いっぱいの間、さらに来た証明書は拒まれたまま保たれず、カードがそう述べます。「下の確認待ちの一覧がいっぱいです。この状態では、新しい証明書はここに追加されずに拒まれるため、待っている現場設備が現れないことがあります。確認待ちの証明書を破棄して空きを作ってください。」いっぱいになってからの拒否があれば、その件数も添えます。そうした拒否は、いずれも記録されます。

承認した現場設備

「Connector がセッションを開いてよい証明書です。」に件数が添えられます。各行は、中立の点、名乗っている名前、「名乗っている現場設備の身元 · <日時> に <ユーザー> が承認」（あるいは「このステーションで」）、フィンガープリント、そしてアドレス、サブジェクト、発行者、アプリケーション URI、有効期間の終了、最後に見た日時の詳細の開閉を見せます。1 つもないときは「承認した現場設備の証明書はありません。」です。

頭の下の案内です。「現場設備の公開証明書がすでに手元にありますか。初回の接続を一度失敗させる代わりに、ここで取り込んで先に承認できます。取り込んだフィンガープリントは、設備の資料にあるものと照合してください。」現場設備はたいてい自分の証明書とともに出荷されるので、こちらの側では取り込みが先に来ます。遮断されていた証明書を取り込むと、その遮断は解けます。取り下げは、証明書を遮断ではなく確認待ちへ返します。もう一度たずねてほしい、と求めたからです。

遮断した現場設備

畳まれた開閉で、「遮断した現場設備」と件数が付き、少なくとも 1 つあるときにだけ描かれます。各行は、赤い点、名乗っている名前、「名乗っている現場設備の身元 · <日時> に <ユーザー> が遮断」、フィンガープリント、そして 遮断を解除 を見せます。これは、承認せずにそれを確認待ちの一覧へ返します。「<名前> の遮断を解除し、確認待ちの一覧に戻しました。」遮断された証明書が、自分から戻ってくることは決してありません。

判断がどこにあるか

現場設備の保管は、ステーションのデータの根の ua\pki\southbound の下にあります（pending、trusted、blocked、そして SDK の rejected）。それぞれの証明書がどのアドレスで見られたか、試行の回数、判断は equipment-access.json にあります。受信の保管とは分かれているので、現場設備の証明書が、ステーション自身のサーバーへ接続するアプリケーションの許可になることも、受信の要求として現れることも、決してありません。これらは構成の バックアップ の一部ではありません。

この節がしないこと

自動で承認されるものはなく、それを止める設定もありません。このカードは機器そのものを設定することはなく（アドレス、資格情報、読み出しは Connector にあります）、現場設備の実時間の値を見せることもなく、このステーションに接続してくるアプリケーションについて決めることもありません。それは クライアントアクセス です。