장치 검색

드라이버에게 장치나 지점을 스캔하게 하는 일, 스캔마다 필요한 것과 돌려주는 것, 진행과 취소 동작, 결과를 추가하는 일, 장치에 없는 태그를 그 장치의 페이지에서 검색하는 일, 그리고 Matter 장치를 Bluetooth로 페어링하는 일.

프로토콜이 실제 스캔을 지원하는 드라이버에서는 장치 검색이 장치나 지점을 직접 입력하는 대신 찾아 줍니다. 이 명령은 드라이버 노드의 명령 모음에 있고(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 대기."가 붙습니다. 한 번의 스캔은 탐색을 최대 256회까지 보낼 수 있습니다. 예산을 넘으면 줄이 빨강이 되고("이 스캔은 탐색을 512회 보내게 됩니다. 네트워크 범위나 슬레이브 ID 범위를 256회 이하로 줄이십시오.") 장치 검색이 회색이 됩니다. 잘못 입력한 값도 같은 방식으로 이름을 얻습니다("'10.0.0'은(는) 올바른 네 마디 IPv4 주소가 아닙니다.", "CIDR 접두사는 /24에서 /32 사이여야 합니다.", "슬레이브 ID를 적어도 하나 입력하십시오(0-255).", "슬레이브 ID 범위 '9-3'은(는) 오름차순이어야 합니다."). 범위 칸을 하나라도 바꾸면 앞선 스캔의 결과가 버려집니다. 그 결과는 다른 범위를 이야기하고 있었기 때문입니다. 한 번에 최대 네 호스트를 스캔하며, 호스트마다 연결 하나를 씁니다.

Modbus RTU

스캔은 드라이버가 아니라 회선의 페이지에 있습니다. 시작 슬레이브 ID와 끝 슬레이브 ID(1에서 247까지, 오름차순. 기본값은 1에서 32), 그리고 그 카드의 장치 검색 단추입니다. 최악의 경우를 어림한 줄이 함께 나옵니다("탐색 32회 · 탐색마다 앞에 두는 4.011 ms 대기를 포함해 최대 약 32.1 s."). 스캔은 회선에 저장된 설정으로 포트를 한 번 열고 유닛을 차례로 탐색하며, 사용 중인 회선을 끊는 대신 거부합니다. "이 회선은 사용 중입니다. 장치 검색 전에 사용 안 함으로 바꾸십시오. Ganter Lab은 버스를 임의로 끊거나 다시 켜지 않습니다." 회선에 저장하지 않은 편집이 있으면 스캔이 시작되기 전에 저장되고, 저장할 수 없으면 스캔은 시작되지 않습니다("시리얼 회선 편집을 저장하지 못해 장치 검색을 시작하지 않았습니다."). 그 카드의 나머지는 시리얼 회선에 있습니다.

Redfish와 AVEVA PI: 스캔이 읽는 서비스

Redfish 서비스도 PI System도 이 스테이션이 들을 수 있는 네트워크에 자기를 알리지 않으므로, 이 두 스캔은 드라이버 페이지의 스캔 범위 카드에서 가리킨 그 서비스 하나만 읽습니다. Redfish는 서비스 주소(https://bmc-host, 다른 포트에서 답한다면 https://bmc-host:8443)를 받고 언제나 HTTPS로 읽습니다. 장치의 자격 증명이 요청마다 함께 실려 가기 때문입니다. 평문 전송을 요구하는 주소는 입력하는 그 자리에서 거부됩니다. AVEVA PI는 서비스 주소와, # 뒤에 훑기를 시작할 AF 요소를 받습니다. https://pi-host/piwebapi#\\AF-SRV\Plant\Line 3입니다. 그 요소가 없으면 훑을 것이 없으므로 장치 검색이 회색이 되고 무엇을 기다리는지 말합니다.

두 스캔 모두 자격 증명 없이 서비스를 읽습니다. 자격 증명을 담고 있을 장치가 생기기 전에 도는 스캔이기 때문입니다. 그러므로 요청마다 인증을 요구하는 서비스는 아무것도 답하지 않고 스캔도 아무것도 찾지 못합니다. 그런 서비스는 직접 추가하십시오. 그다음 Redfish 장치는 장치와 똑같이 로그인하는, 자기 페이지의 태그 검색으로 지점을 찾습니다. AVEVA PI 장치의 지점은 직접 추가합니다.

스캔 돌리기

스캔이 도는 동안 드라이버의 페이지는 상태 줄을 적고 모음의 장치 검색은 취소로 바뀝니다. 상태는 서로 독립된 두 단계, 곰 endpoint 검색과 채널 훑기에서 옵니다. "endpoint를 스캔하는 중…", "endpoint 2을(를) 살펴보는 중…", "opc.tcp://plc:4840에서 채널을 읽는 중…", 그다음 "장치 3개를 찾았습니다."입니다. 스캔을 스스로 돌리는 드라이버는 어디까지 왕는지만 알리고 페이지가 셈니다. "장치 검색 진행: 2개 중 1개…". Modbus 스캔 두 가지만 줄 전체를 씁니다. 포트와 호스트와 슬레이브 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개를 찾은 뒤 오류로 스캔이 멈췄습니다. 목록이 완전하지 않을 수 있습니다." 채널을 읽지 못한 endpoint도 태그 0개로 목록에 남습니다.

스캔은 도는 동안 드라이버를 차지합니다. 스캔이 끝날 때까지는 다른 노드를 선택할 수 없고("이 드라이버를 떠나기 전에 장치 검색을 취소하십시오."), 장치나 회선을 추가할 수도, 회선을 켜고 끌 수도, 행 동작을 쓸 수도 없습니다. 결과는 스캔을 시작한 그 창의 것입니다. 같은 스테이션의 다른 브라우저 탭은 결과를 보지 못합니다.

취소

취소(누르면 "취소하는 중…")는 두 단계를 모두 멈춥니다. 취소 전에 완전히 준비된 후보는 목록에 남고, 채널을 읽고 있던 endpoint는 버려집니다. 상태는 "장치 검색을 취소했습니다."라고 읽히고, 작업 기록 줄은 "OPC UA의 장치 검색을 취소했습니다. 완료된 결과 2개는 그대로 남았습니다."라고 알립니다. 드라이버의 임시 소켓이나 클라이언트나 세션이 닫힐 때까지 스캔은 계속 자리를 차지하며, 2초가 지나면 상태가 스캔이 이미 멈춘 척하는 대신 "드라이버가 장치 검색 자원을 놓기를 기다리는 중…"이라고 말합니다. 드라이버가 요청받은 그 순간에 언제나 손을 놓아 주지는 않기 때문입니다.

결과

검색된 장치 카드(회선에서는 검색된 슬레이브)는 후보마다 카드 하나를 나열합니다. 고칠 수 있는 이름, Endpoint, 그리고 "태그 5개 중 2개 선택됨"입니다. 그 아래에는 후보 태그의 촘촘한 표가 놓이며 추가 체크(기본값은 켜짐), 태그, 형식, 접근이 들어 있습니다. 태그가 없으면 "보고된 태그가 없습니다. 장치를 추가한 다음 편집기에서 태그를 설정하십시오."입니다. 드라이버가 채널을 찾은 자리보다 짧은 이름을 태그에 붙이면, 태그 칸은 이름 아래 둘째 줄에 그 자리를 보여 줍니다. OPC UA에서는 노드의 경로 전체입니다(OPC UA 참고). 카드의 장치 추가를 누르기 전까지는 아무것도 저장되지 않습니다(누르면 "추가하는 중…"). 드라이버 안에서 고유한 이름으로, 체크한 태그만 정확히 가진 장치가 만들어지고, 카드는 목록에서 빠지며, 새 장치는 스캔한 페이지의 장치 표에서 강조 표시되고 그 페이지는 화면에 남으며, 작업 기록 줄은 "태그 3개와 함께 'Pump'을(를) 추가했습니다."라고 읽힙니다. 검색된 태그는 드라이버가 알려 준 대로 읽기 전용이나 쓰기 가능으로, 자기 형식과 기본 변환 경로를 가지고 들어옵니다. 그 밖에 추측되는 것은 없습니다.

이미 가지고 있는 장치와 맞는 후보에는 이미 설정됨 표시가 붙고 추가 대신 열기가 제시되므로, 스캔이 실수로 중복을 만드는 일은 없습니다. 신원이 안정된 것만 맞춰 봅니다. 같은 회선의 Modbus RTU 슬레이브, 같은 브로커의 Sparkplug B 엣지 노드나 장치, 같은 VISA 리소스의 SCPI 계측기, NI MAX의 같은 이름을 쓰는 NI-DAQmx 장치, 장치를 통해서나 같은 호스트와 포트에서 스캔한 SNMP 에이전트, File 장치가 같은 폴더에서 같은 이름과 같은 방식으로 읽는 파일, 자체 Database 장치를 통해 스캔한 데이터베이스, 이름으로 읽는 장치와 같은 호스트의 Siemens CPU, 그리고 Matter 노드 id입니다. 다른 드라이버는 아무것도 맞추지 않습니다. 닿을 수 있는 endpoint라는 사실이 같은 장비라는 증거는 아니기 때문입니다. 설정된 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를 사용합니다."

장치 페어링은 이름과 코드가 채워지고, 쓸 수 있는 네트워크가 있고, 스테이션이 변경을 받아들일 때 쓸 수 있게 됩니다. 그러면 양식은 검사, 찾기, 페어링, 네트워크 가입, 저장의 다섯 단계를 지나가며 그 아래 상태 줄을 적습니다. "설정 코드와 네트워크를 검사하는 중…", "Bluetooth로 장치를 찾는 중…", "장치를 인증하고 페어링하는 중…", 이어서 Wi-Fi 네트워크라면 "Wi-Fi 네트워크의 이름과 비밀번호를 장치에 보내는 중…"과 "장치가 Wi-Fi 네트워크에 들어오기를 기다리는 중…"(Thread 네트워크라면 "기존 Thread 네트워크 구성을 보내는 중…"과 "장치가 Thread 네트워크에 들어오기를 기다리는 중…"), "시운전된 노드를 로컬 Fabric에 저장하는 중…", "페어링을 마쳤습니다."입니다. 취소는 맞는 광고가 선택되기 전까지만 받아들여지고("장치가 바뀌기 전에 멈춥니다"), 그 뒤로는 단추가 "안전하게 마무리하는 중…"이 됩니다. 장치가 이미 바뀌었으므로, 사용자가 자리를 떠나더라도 스테이션은 그 노드를 기록해야 하기 때문입니다. 아무것도 돌지 않을 때는 닫기가 양식을 치웁니다.

성공하면 노드 id를 신원으로 하고 들어간 네트워크의 이름을 읽기 전용 네트워크 칸에 담은 장치가 만들어지고, 작업 기록 줄은 "Matter 장치 '주방 조명'을(를) 페어링했습니다."라고 읽힙니다. 이어서 페이지가 Matter 드라이버를 열어 장치 표에서 새 장치를 강조 표시하고, 그 장치 하나만 스캔합니다. 그 카드에는 장치가 공개하는 값이 체크된 채 태그로 추가 옆에 나열되고, 스캔은 "'주방 조명'에서 태그로 만들 값을 체크한 다음 태그로 추가를 누르십시오."로 끝납니다. 장치가 무엇을 내놓고 각 값이 무엇을 하는지는 Matter에 있습니다. 설정 코드는 저장되지도, 기록되지도, 다시 보이지도 않습니다. 네트워크의 비밀번호나 데이터셋은 네트워크 카드에 남아 이 Windows 사용자용으로 암호화되어 저장되며, 장치에도, 그 주소에도, 로그에도 가지 않습니다. 노드는 커미셔닝되었지만 장치를 만들지 못했다면 작업 기록 줄이 그렇게 말하고, 되찾는 길은 장치 검색입니다. 실패는 있는 그대로 말해지고 양식은 다시 시도할 수 있도록 열린 채 남습니다. 올바르지 않은 코드, 이름이나 비밀번호나 데이터셋이 올바르지 않은 네트워크, 쓸 수 있는 Bluetooth 어댑터 없음, Bluetooth 거부나 꺼짐, 맞는 장치를 찾지 못함("장치를 페어링 모드로 두고 가까이에 둔 다음 다시 시도하십시오."), 거부된 설정 코드, 다른 종류의 네트워크나 케이블로 들어가는 장치(장치에는 아무것도 기록되지 않습니다), 네트워크에 가입할 수 없다고 응답한 장치(찾지 못한 Wi-Fi 이름, 거부된 비밀번호 또는 그 밖의 거부: 장치는 아무것도 남기지 않고 페어링 모드로 돌아가므로 네트워크를 고치고 다시 페어링합니다), 응답하지 않고 로컬 네트워크에도 끝내 나타나지 않은 장치(그 노드는 Fabric에 남으며 장치 검색으로 되찾을 수 있습니다), 저장하지 못한 Fabric(장치가 이미 커미셔닝된 경우: "Fabric 저장 문제가 풀릴 때까지 장치를 초기화하지 마십시오."), 또는 이미 진행 중인 다른 페어링입니다. 실패마다 장치에 무엇이 남는지는 페어링이 실패할 때에 있습니다. 페어링은 한 번에 하나만 돌며, 도는 동안에는 드라이버를 떠날 수 없습니다("이 드라이버를 떠나기 전에 Matter 페어링이 끝나기를 기다리십시오.").

장치 검색이 하지 않는 일

스캔은 스스로 아무것도 저장하지 않고, 이미 있는 장치를 바꾸지 않으며, 저절로 다시 돌지 않습니다. 서브넷도 레지스터 지도도 시리얼 설정도 추측하지 않고, 회선이나 브로커를 켜거나 끄지 않으며, 치워 버린 후보를 장비에서 제거하지도 않습니다. 패키지에 들어 있지 않은 드라이버에서는 거부됩니다. 드라이버마다 결과에 무엇이 들어 있는지는 드라이버 아래 그 드라이버의 페이지에 있습니다.