现场设备访问
Connector 拨号连接的那些 OPC UA 现场设备的证书：什么在等着批准、什么已经批准、什么被阻止，在第一次连接之前导入一份证书，以及一台等着的设备在 Connector 里说什么。
现场设备访问是设置页面上 OPC UA 现场设备分组里唯一的一行：证书信任朝外的那一半。Connector 拨号连接一台 OPC UA 现场设备服务器时，那个服务器用一份证书证明自己是谁，而证书你没有批准的设备，工作站一个数都不读。卡片抬头就是这么说的：“当 Connector 拨号连接一台 OPC UA 现场设备服务器时，那个服务器会用一份证书证明自己的身份。只批准你已经和调试该设备的人核对过的指纹。”打开这个页面需要更改设置权限；决定在工作站自己的桌面上做。
抬头下面那条原则：“未经你批准的现场设备，一律不读取。证书还在这里等待的设备保持沉默，并且会在 Connector 中说明。批准它就开始读取；撤回批准会关闭会话并再次询问你。证书上的名称是设备自称的；要核对的身份是 SHA-256 指纹。”
这张卡片有意做成和客户端访问一样的形状，意思相同的地方用的是相同的话，谁可以决定也是同一条规则：另一台设备上的浏览器看到“现场设备访问只能在工作站本机的桌面应用中更改。”和那条提示条“要更改现场设备访问，请打开桌面应用”；没有更改设置的角色、正在运行的单元、停止的运行时和已经在执行的一次更改，各自用自己那句话拒绝。每一种结果都落在状态栏上。
一台等着的设备在 Connector 里做什么
Connector 第一次拨号连接一台 OPC UA 设备时，这台现场设备的证书被拒绝，在这里记作等待中，而这台设备一个数都不读。在设备自己的页面上，Connector 显示一条警示提示条，正在等待证书批准，带一个查看证书按钮，按下去就打开这一节并停在这台设备那一行上，而设备的健康状态在树里写着同一个状态。驱动自己那次失败说的是原因，而不是一个没名没姓的握手错误：“这台现场设备的证书（指纹的前 16 个字符）正在等待你在‘设置’的‘现场设备访问’里批准。批准之后就开始读取。”被阻止的那一份写的是“…在本工作站上被阻止。请到‘设置’的‘现场设备访问’里查看它。”设备发现的浏览在它那次会话打开之前，过的是同一道关卡。
一经批准，Connector 就在它下一次尝试时开始读取。本来在读的现场设备，如果在同一个地址上开始出示另一份证书，就不再被读取，并立起一张常驻卡片，“证书已更换：<name>”：“<address> 上的现场设备原先用本工作站批准过的证书供读取，现在出示的是另一份（…），因此不再从它读取任何数据。请与维护该设备的人核对指纹，然后批准它。”，带审核，窗口藏起来时还加一条 Windows 通知。正在登记中的设备不会这样宣告：登记它的那个人本来就看着 Connector。
等待批准
至少有一份证书等着的时候才画出来，抬头是“在你做出决定之前，这些设备不会被读取。”，带着数量。每一行显示一个警示色调的圆点、证书自称的名称、“自称的设备身份”、指纹、“<address> · 最近一次尝试 <date and time> · N 次连接尝试”，以及一个证书详情折叠块，里面是主体、颁发者、应用程序 URI、域名、有效期起、有效期至和首次出现。一个“审核”按钮带过去的那一行标着“已选中待审核”，并被滚动到视野里。
| 命令 | 作用 | 什么时候变灰（情形） |
|---|---|---|
| 批准 | 把这份证书挪到已批准的现场设备里，并刷新实时校验器：“<name> 已获批准。Connector 会在下一次尝试时开始读取。” |
按上面那条规则。 |
| 阻止 | 把它挪到被阻止的现场设备里，并继续拒绝它：“<name> 已被阻止。本工作站会继续拒绝这份证书。” |
按上面那条规则。 |
| 丢弃所有待处理的证书（在这一组抬头上） | 先问一句“要丢弃那份等待审核的证书吗？”或者“要丢弃那 N 份等待审核的证书吗？”（“这样做不会批准也不会阻止任何东西：这些请求被移除，列表重新腾出位置。此后 Connector 拨号连接的设备会作为新请求出现在这里。”），带丢弃和保留列表。 | 按上面那条规则。 |
这份列表最多装 100 份证书。它满着的时候，再来一份证书仍然被拒绝，但不再留存，卡片会这么说：“下面的待审列表已满。在它满着的时候，新证书会被拒绝而不会加进这里，因此你等待的那台设备可能永远不会出现。请丢弃等待审核的证书来腾出位置。”，一旦真的有拒绝，就带上它满了以后的拒绝次数。每一次这样的拒绝都记进日志。
已批准的现场设备
“Connector 可以与之建立会话的证书。”，带着数量。每一行显示一个中性色圆点、自称的名称、“自称的设备身份 · 由 <user> 于 <date and time> 批准”（或者“在本工作站上”）、指纹，以及一个详情折叠块，里面是地址、主体、颁发者、应用程序 URI、有效期至和最近出现。一个都没有时：“没有已批准的现场设备证书。”
| 命令 | 作用 | 什么时候变灰（情形） |
|---|---|---|
| 导入证书（在这一组抬头上） | 打开一个文件选择框，选这台现场设备的公开证书（.der、.cer、.crt 或 .pem，最大 64 KB），在第一次连接之前就批准它：“<name> 已从 <file> 获得批准。请把下面的指纹与设备文档里的指纹核对。”更大的文件：“<file> 比一份设备证书大。请导入公开证书文件（.der、.cer 或 .pem），而不是压缩包。” |
按上面那条规则。 |
| 撤回批准（在行上，危险色调） | 先问一句“要撤回对 <name> 的批准吗？”：“与这台设备当前的会话会被关闭，本工作站不再从它读取数据。证书回到待审列表，因此下一次连接会再次询问你。”，带撤回和保持批准。随后是：“已撤回对 <name> 的批准。它的会话已关闭，正在重新等待审核。” |
按上面那条规则。 |
抬头下面那句提示：“已经拿到设备的公开证书了？在这里导入它，就可以在第一次连接之前批准它，而不必先让连接失败一次。请把导入后出现的指纹与设备文档里的指纹核对。”现场设备通常随货带着它的证书，所以这一侧把导入放在前面。导入一份被阻止的证书会解除那次阻止。撤回是把证书退回审核，不是把它阻止：你要的是再被问一次。
被阻止的现场设备
一个收起着的折叠块，“被阻止的现场设备”，带着数量，只有至少存在一份时才画出来。每一行显示一个红色圆点、自称的名称、“自称的设备身份 · 由 <user> 于 <date and time> 阻止”、指纹，以及解除阻止，按下去它就回到待审列表，而不被批准：“<name> 已解除阻止，并回到待审列表。”一份被阻止的证书绝不会自己回来。
这些决定存在哪里
现场设备的那几个库在工作站数据根目录下的 ua\pki\southbound 里（pending、trusted、blocked 和 SDK 那个 rejected），每份证书是在哪个地址上见到的、尝试次数和各项决定在 equipment-access.json 里。它们和朝内的那几个库是分开的，所以一份现场设备的证书绝不可能变成某个应用程序连上工作站自己那个服务器的许可，也绝不会作为一个朝内的请求出现。它们不属于配置备份的一部分。
这一节不做什么
任何东西都不会被自动批准，而且没有哪个设置能把这一点关掉。这张卡片不配置设备本身（地址、凭据和轮询在 Connector 上），不显示这台现场设备的实时数值，也不决定拨号连上这台工作站的那些应用程序的事，那是客户端访问。