OPC UA

ほかのメーカーのサーバーに向かう OPC UA のクライアント。証明書で守られた信頼、ノード ID によるアドレス指定、アドレス空間の機器検出。

OPC UA のドライバーは、ほかのメーカーの OPC UA サーバー、つまり PLC、ゲートウェイ、ヒストリアン、ほかの SCADA システムに opc.tcp で向かうクライアントです。このステーション自身のアドレス空間を公開する内蔵の OPC UA サーバー（OPC UA サーバーで説明します）の、出ていく側の相手役にあたります。2 つはステーションのアプリケーションの身元を共有しますが、相手を信頼するかどうかはそれぞれ別に決めます。

機器

サーバーの準備

たいていの OPC UA サーバーは、出荷時のままでは新しいクライアントを断ります。理由はサーバー自身の 2 つの設定で、どちらもサーバー側で行います。

よく使われるサーバーで、クライアントの証明書を信頼する場所は次のとおりです。

サーバーがどちらかの理由で断ると、機器のページはサーバーの状態の代わりにお知らせで、どちらの理由かを伝えます。証明書のときは、その名前とフィンガープリント（SHA-1。サーバーが一覧に示すもの）をそれぞれコピーのボタン付きで示し、ファイルをそのフォルダーを開くボタン付きで示します。ユーザーのときは、サーバーが匿名のセッションを受け付けないのか、ユーザーを拒否したのかを伝え、機器のユーザー名とパスワードを指し示します。セッションが開くとお知らせはひとりでに消え、ジャーナルとエージェントも同じ指示を読みます。このステーションはアプリケーション名やネットワーク名が変わると新しい証明書を発行し、サーバーはその新しい証明書を信頼し直す必要があります。

セキュリティと証明書

接続は、サーバーの endpoint の一覧から始まります。クライアントはサーバーが公開しているうちで最も安全な endpointを選び、このステーション自身の証明書、つまり内蔵サーバーが使うのと同じ OPC UA のアプリケーションの身元で、アプリケーションを認証します。多くのサーバーは、セッションを受け入れる前に相手側でその証明書を信頼しておくよう求めます。どこで行うかはサーバーの準備にあります。

セキュリティなしの endpointより良いものを公開しない現場設備は拒否され、機器がその理由を伝えます。そのセッションは測定値も資格情報も平文で運び、現場設備の身元を何も証明しないので、その機器でそう頼んだところでだけ開きます。接続のカードのセッションのセキュリティ、セキュリティなしのセッションを許可するです。この選択はその機器のものであり、その機器のアドレスに ?security=none として乗り、読み取りのセッションにも機器検出の巡回にも同じように効きます。オンにしても、セキュリティを備えた現場設備が格下げされることはありません。公開されているうちで最も安全な endpoint が選ばれるままです。

反対の方向では、信頼は閉じた側に倒れ、明示的です。現場設備の証明書は、セッションが開く前に確かめられます。

• このステーションが一度も承認していない証明書は拒否され、確認のために記録され、機器のパネルには何の承認を待っているかを名指しする知らせが出ます。その機器は「オフライン」なのではなく、判断を待っています。
• 証明書はこのページの現場設備へのアクセスのカードで確認します。ここは証明書の信頼のうち、出ていく側の半分です。記録された証明書は、承認する（新しいセッションが開けるようになります）か遮断する（繰り返し尋ねずに拒否します）まで、承認待ちに置かれます。これは現場設備の一覧です。OPC UA サーバーのパネルのクライアントアクセスは逆向き、つまりこのステーション自身のサーバーへ入ってくる接続を誰に許すかです。
• 承認済みの行にある承認を取り下げるは、その証明書で動いているセッションを閉じ、確認の一覧に戻すので、次の接続でもう一度尋ねられます。
• 証明書をまったく出さない現場設備は、誰が応答したのかを何も証明しません。承認すべきものがないので、そのセッションはアドレスを日誌に書いたうえで拒否されます。同じセキュリティなしのセッションを許可するのもとでだけ接続でき、そのときはその選択が承認の代わりになります。

機器のサーバーを承認しても、その証明書がこのステーション自身のサーバーへ入ってくることを認めたことにはなりません。2 つの方向は、意図して別々の保管場所を持ちます。

セッションの振る舞い

タグは読みに行きます。読み取りのたびに、そのノードの現在の値をサーバーに尋ねます。サーバー自身の判断は、どのサンプルにも付いてきます。Bad や Uncertain の印が付いた値は拒否され、そのタグは品質が悪いものとして読まれるので、疑わしい取得元がきれいな読み取りに化けることはありません。サーバー上にもう存在しないノードは、機器全体を失敗させるのではなく、値なしとして読まれます。

サーバーの時刻もサンプルと一緒に届きます。良い値にサーバーが付けた SourceTimestamp は、タグのページでそのタグの取得元の時刻になります。サーバーは値や品質が変わるまでその時刻を変えないことがあるので、変わらない値ではアプリケーションの時刻より前の時刻が出ることがあります。アプリケーションの時刻は、いつもステーションが読み取りを受け取った瞬間です。

セッションはキープアライブで見張られます。キープアライブを 3 回取り逃がすと、クライアントは自動の再接続を始めて先に進みます。最初の接続はアプリの背後の再試行の繰り返しが受け持つので、届かないサーバーがあっても起動時の損はありません。

タグのアドレス指定

タグは ノード ID でアドレスを取ります。自由記述で入力し、そのまま送られます。受け付ける形は、OPC UA の標準の書き方です。

タグはノードの Value 属性を読み書きします。

値の型

値はスカラーだけです。配列、構造体、そのほかの複雑な値は、紛らわしい数値に押しつぶされるのではなく、読めないものとして拒否され、そのタグは品質が悪いものとして読まれます。そういうタグは自分だけが失敗します。その機器のほかのタグは読み取りを続け、そのために再接続が起こることもありません。空の文字列は値であって、失敗ではありません。出る型に入らない型は、このドライバーではタグの型として使えません。SByte、Byte 以外の符号なしの各幅（UInt16、UInt32、UInt64）、DateTime、Guid、ByteString がそれにあたります。

タグの型がノードの型と違うときは、バイト列を読み直すのではなく、数値として変換します。読み取りにも書き込みにも同じ規則が働きます。実数は実数（Float と Double）に、整数は値が収まるかぎり幅の違う整数に移ります。整数のノードに対する Boolean のタグは、0 と 1 をオフとオンとして読み、書き込むときも 0 と 1 として書きます。収まらない値や、別の種類の値を持つノード（整数のタグに対する実数、テキストのタグに対する数値）は、その 1 点だけで拒否され、こうして拒否された書き込みがサーバーに送られることはありません。

そのため、サーバーをスキャンして出るチャネルは、サーバーが持っているものより少なくなります。値の並びを宣言しているノードや、スキャンが読んだときに値の並びを持っていたノードと、出る型に入らない型のノードが外れるからです。多くのサーバーは、値を 1 つしか持たない変数でも、宣言する形を開いたままにしています（ValueRank が Any や ScalarOrOneDimension）。そのため、そうしたノードはスキャンが読んだときに持っている値で判断され、その値が並びでなければ出ます。あとで並びを持つようになった場合は、そのタグだけが自分の読み取りで失敗します。タグが持てない値ならどれでも同じで、その機器のほかのタグは読み取りを続けます。ノードの型は、宣言された型のもとになっている基本の型です。VersionTime と宣言されたノードは UInt32 を、UtcTime と宣言されたノードは DateTime を持つので、どちらも外れます。一方、Duration と宣言されたノードは Double を持つので出ます。形を開いたままにするサーバーは、宣言する型も開いたままにしていることがよくあります（BaseDataType、または Number、Integer、UInteger。どれも、値がその型のまま送られることのない型です）。そのため、そうしたノードはスキャンが読んだときに持っている値の型をとり、その型によって出るか外れるかが決まります。そうしたノードのうち、読み取りで値が返ってこなかったものは型を示さないので外れます。あとでサーバーが別の型の値を送ってきた場合は、その値は上の変換の規則で読まれ、そのタグが失敗するのは規則がその値を拒否するときだけです。ただし黙って落とされるわけではありません。スキャンはそれを数え、締めくくりの文言が、何件、どの型が外れたかを伝えます。たとえば「チャネル 5 件が外れました：UInt32 の型が 3 件、値 1 つではなく値の並びを持つものが 2 件。」といった具合で、短い一覧が、中身の乏しいコントローラーではなく短い一覧として読めるようになります。

サーバーが値をまったく返さないノードも外れ、数にも入りません。何も持っていないので、取り込んでも読めることがないからです。値が Bad で返ってくるノードは、値の並びを宣言している場合と、開いた型を宣言していて型をとれる値が返ってこなかった場合を除き、出ます。その状態が示すのは、ノードの先にある現場設備がまだ応答していないこと、またはスキャンの匿名のセッションには読めないことだけで、機器は自分の資格情報でサインインするからです。

書き込み

書き込めるタグは、OPC UA の Write サービスでノードの Value 属性に書き込みます。判断はサーバーの応答です。拒否された書き込みは失敗として表に出て、保持している値は受け入れられたときにだけ進みます。ほかと同じで、書き込みの入力欄は工業値を取り、生値が送られる前に値の変換経路が逆にたどられます。

機器検出

機器検出のコマンドは、その横の入力欄で対象を取ります。opc.tcp://plc-host:4840 のような OPC UA サーバーのアドレスです。スキャンは 2 段階で、進み具合の行が今どちらが動いているかを名指しします。

1. endpoint：対象の標準の機器検出のサービスに問い合わせ、公開されているすべての機器検出の URL が候補の endpoint になります。独自のポートやサーバーの経路は、候補の接続の項目にそのまま入ります。
2. チャネル：各候補のアドレス空間を Objects のフォルダーから下へ巡り、読めるすべての変数を、その型とアクセスとともに候補のタグとして並べます（値の型で外れると書いたノードは除きます）。サーバーの診断の領域は飛ばします。

候補のタグは、そのノード自身の名前（BrowseName）で名づけられ、サーバーが示すほかのチャネルと見分けるのに要るだけの上のノードの名前を、前に付けます。別のステーションのサーバーでは Devices.Simulated.Tank.Level ではなく Level になり、Speed という名前のノードが 2 つ重なるところでだけ Line1.Speed と Line2.Speed になります。それでも同じに読める 2 つの名前（大文字と小文字や記号だけが違うもの）は、番号で見分けます。巡回した経路の全体は候補のカードに残り、名前の下の 2 行目に出るので、各タグがどのノードを読むのかがわかります。タグはノード ID で読むので、名前はその呼び名にすぎず、タグのグリッドと、そのアドレスの末尾（Connector.OpcUa.Peer.Level）で使われます。

巡回は匿名でサインインします（同じく最も安全な endpoint を選び、セキュリティなしのセッションを同じように拒み、同じ現場設備の証明書の関門を通ります）。匿名のセッションを拒むサーバー、安全な endpoint を公開しないサーバー、何らかの理由で失敗した巡回でも、その endpoint はタグ 0 件で追加できます。追加してから機器に資格情報とセッションのセキュリティを設定し、タグを手で設定してください。候補を追加するまで何も保存されず、取りやめてもすでにそろっていた候補は残ります。

すでにあるサーバーは、その機器のページから、さらにノードを読めます。タグのカードの見出しにあるタグ検出は、その機器の endpoint を、機器自身のセッションと同じくサインインして巡回します。使うのは機器のユーザー名、パスワード、セッションのセキュリティなので、匿名のセッションを拒むサーバーも、ここではノードを見せます。出すのは、機器のどのタグもまだ読んでいないノードだけで、サーバーの名前空間の表を通して比べます。名前空間の番号で書いたタグ（ns=2;s=Level）は、巡回が名前空間の URI で名付けるノード（nsu=…;s=Level）を読むので、そのノードはもう一度は出ません。セッションを拒むサーバーは、機器自身のセッションが示すのと同じ原因でスキャンを終わらせます（機器のタグを検出するを参照）。

知っておきたい限界

• 読み取りは Value 属性の定期的な問い合わせです。このドライバーが相手のサーバー上にサブスクリプションを作ることはありません。
• 値はスカラーだけです。タグが配列の要素や構造体のメンバーを指すことはできません。
• 承認の関門は証明書ごとに効きます。証明書を入れ替えた現場設備は確認の一覧に戻り、新しい判断を待ちます。

現場設備へのアクセス

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

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

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

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

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

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

承認待ち

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

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

承認した現場設備

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

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

遮断した現場設備

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

判断がどこにあるか

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

この節がしないこと

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