장치 검색

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

Markdown으로 보기

프로토콜이 실제 스캔을 지원하는 드라이버에서는 장치 검색이 장치나 지점을 직접 입력하는 대신 찾아 줍니다. 이 명령은 드라이버 노드의 명령 모음에 있고(Modbus RTU에서는 시리얼 회선 페이지의 슬레이브 검색 카드에 있습니다), 스캔이 읽는 것은 모두 드라이버 페이지의 스캔 범위 카드에 있습니다. 모음은 명령을 담고, 카드는 그 범위를 담습니다. 이 모든 것에는 Connector 구성이 필요합니다. 그 권한이 없는 역할에게는 범위 카드도 단추도 그려지지 않습니다. 실행이 스테이션을 잡고 있거나 런타임이 정지된 동안에는 스캔이 거부됩니다. 스캔이 아무것도 내놓지 않는 것은 기능이 빠진 것이 아니라 스캔의 결과입니다. 단추는 스캔이 결과를 낼 수 있는 곳에만 나타납니다.

어느 드라이버가 스캔하는가

드라이버 스캔이 하는 일 필요한 것
Simulated 시뮬레이션 장치 모델의 카탈로그를 나열하며, 모델마다 바로 쓸 수 있는 인스턴스 하나를 채널과 함께 내놓습니다. 없습니다.
Modbus TCP 명시한 호스트와 슬레이브 ID에 Read Device Identification(기능 43/14)을 보냅니다. 형식이 맞는 Modbus 예외 응답은 이름을 알려 주지 않고도 그 슬레이브가 있다는 것을 증명합니다. 엔드포인트를 돌려주고 태그는 돌려주지 않습니다. 스캔 범위 카드.
Modbus RTU 회선에 저장된 조합으로 슬레이브 ID 범위(양 끝 포함)를 순서대로 탐색하며, 같은 요청을 쓰고 레지스터에는 접근하지 않습니다. 꺼져 있거나 켜진 장치가 없는 회선, 그리고 슬레이브 ID 범위.
OPC UA 서버 하나에 광고하는 엔드포인트를 물은 다음, 각 엔드포인트의 주소 공간을 훑어 지점을 찾습니다. 드라이버 페이지의 스캔 범위 카드에 적는 서버 주소("OPC UA 서버 주소, 예: opc.tcp://plc-host:4840"). 주소가 없거나 주소가 아닌 것이 적혀 있으면 장치 검색이 회색이 되고 무엇을 기다리는지 말합니다.
Rockwell EtherNet/IP ListIdentity를 브로드캐스트하고 각 컨트롤러의 태그를 훑습니다. 없습니다.
BACnet Who-Is를 브로드캐스트하고 I-Am 응답을 듣습니다. 장치는 답하는 순간마다 하나씩 나타납니다. 주소와 포트와 장치 인스턴스를 돌려주고 태그는 돌려주지 않습니다. 없습니다.
Redfish 받은 서비스 주소를 읽고 그 첫 시스템과 매니저와 섀시를 훑습니다. 서비스와 그 지점을 돌려줍니다. 스캔 범위 카드.
AVEVA PI 받은 AF 요소와 그 아래에 있는 모든 것을 훑습니다. 서비스와 속성마다 지점 하나를 돌려줍니다. 스캔 범위 카드.
OCPP 지금 이 스테이션에 접속해 있는 충전기를 나열합니다. 없습니다.
Matter 이 스테이션의 Fabric에 이미 커미셔닝된 노드를 나열합니다. 없습니다.

Siemens S7, Beckhoff ADS, Mitsubishi MC, IEC 61850, LoRaWAN, HTTP에는 스캔이 없으며 단추도 보이지 않습니다. 단추는 내장 서버가 실행 중일 때에만 나타납니다. 스캔을 돌릴 수 있는지 답하는 것이 서버의 드라이버 등록부이기 때문입니다. 그리고 이 버전이 설치하는 드라이버에만 나타납니다. 등록부가 애플리케이션이 알아보지 못하는 어셈블리로 답하면 단추는 나타나지 않고, 설치된 드라이버가 이 버전이 싣는 것이 아니라는 사실이 Events 페이지에 기록됩니다.

Modbus TCP: 스캔 범위 카드

이 카드는 Modbus TCP 드라이버의 페이지에 나타납니다. "읽기 전용 장치 식별입니다. 레지스터는 추가한 뒤에 설정합니다."

값과 기본값 효과
IPv4 호스트 또는 CIDR 주소 하나, 또는 /24에서 /32까지의 CIDR. 애플리케이션은 로컬 서브넷을 결코 추측하지 않습니다. 네트워크 주소와 브로드캐스트 주소를 뺀, 그 범위의 모든 호스트 주소.
포트 1에서 65535까지. 502. 모든 호스트를 두드릴 포트.
슬레이브 ID 값, 쉼표로 구분한 목록, 또는 0에서 255까지의 오름차순 범위("1, 3, 8-16"). "1". 호스트마다 각 ID를 묻습니다.
최소 트랜잭션 간격(ms) 0에서 1000까지. 0. 같은 호스트에서 끝난 탐색 사이의 침묵이며, 호스트마다 따로 속도를 맞춥니다. 스캔에만 쓰이며, 추가하는 장치에는 적히지 않습니다.

칸 아래 줄은 예산입니다. "호스트 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입니다. 그 요소가 없으면 훑을 것이 없으므로 장치 검색이 회색이 되고 무엇을 기다리는지 말합니다.

두 스캔 모두 자격 증명 없이 서비스를 읽습니다. 자격 증명을 담고 있을 장치가 생기기 전에 도는 스캔이기 때문입니다. 그러므로 요청마다 인증을 요구하는 서비스는 아무것도 답하지 않고 스캔도 아무것도 찾지 못합니다. 그런 서비스는 직접 추가하고, 그 지점도 함께 직접 추가하십시오.

스캔 돌리기

스캔이 도는 동안 드라이버의 페이지는 상태 줄을 적고 모음의 장치 검색은 취소로 바뀝니다. 상태는 서로 독립된 두 단계, 곧 엔드포인트 검색과 채널 훑기에서 옵니다. "엔드포인트를 스캔하는 중…", "엔드포인트 2을(를) 살펴보는 중…", "opc.tcp://plc:4840에서 채널을 읽는 중…", 그다음 "장치 3개를 찾았습니다."입니다. 자기 진행을 스스로 알리는 드라이버는 "OPC UA 서버 …에 광고하는 엔드포인트를 묻는 중…", "엔드포인트 2개를 찾았습니다.", "Rockwell 컨트롤러를 찾는 중…", "BACnet 장치를 스캔하는 중…", "커미셔닝된 Matter 노드 2개 중 1개를 살펴보는 중…", "호스트 2개 × 슬레이브 ID 3개를 스캔하는 중…", "슬레이브 5을(를) 탐색하는 중(32개 중 5개)…"이라고 말합니다. 드라이버 오류로 멈춘 스캔은 찾은 것을 그대로 두고 그렇게 말합니다. "장치 1개를 찾은 뒤 오류로 스캔이 멈췄습니다. 목록이 완전하지 않을 수 있습니다." 채널을 읽지 못한 엔드포인트도 태그 0개로 목록에 남습니다.

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

취소

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

결과

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

이미 가지고 있는 장치와 맞는 후보에는 이미 설정됨 표시가 붙고 추가 대신 열기가 제시되므로, 스캔이 실수로 중복을 만드는 일은 없습니다. 신원이 안정된 것만 맞춰 봅니다. 같은 회선의 Modbus RTU 슬레이브와 Matter 노드 id입니다. 다른 드라이버는 아무것도 맞추지 않습니다. 닿을 수 있는 엔드포인트라는 사실이 같은 장비라는 증거는 아니기 때문입니다.

닫기는 목록을 비우며, 스캔을 기다립니다. 스캔이 도는 동안에는 회색이 되는데, 스캔 도중에 목록을 비우는 일은 스캔을 함께 취소하고 이미 답한 것을 모두 버리는 일이기 때문입니다. 다른 드라이버를 선택하거나 범위를 바꾸어도 목록은 비워집니다. 스캔이 도는 동안에는 장치나 태그를 삭제하는 일과 장치를 폴더로 옮기는 일도 같은 이유로 회색이 됩니다. 스캔이 드라이버를 잡고 있어서, 확인을 누른 뒤에 그 명령이 실패하게 되기 때문입니다. Modbus RTU에서는 슬레이브 ID가 자기 열을 가지며, 회선에 이미 설정된 ID를 추가하려 하면 거부됩니다. "슬레이브 5은(는) 이미 'Line 1'에 설정되어 있습니다."

Matter 장치 페어링

Matter는 실제 장치가 여기에 생기기 전에 Bluetooth로 그 장치를 커미셔닝하므로, Matter 드라이버의 첫 동사는 장치 추가가 아니라 장치 페어링이며, 이 동사는 드라이버 페이지에 양식을 엽니다(새로 만들기… 메뉴와 드라이버의 오른쪽 단추 메뉴도 같은 것을 내놓습니다). 페어링에는 Connector 구성, 이 컴퓨터에서 쓸 수 있는 Bluetooth LE 무선, 그리고 데이터셋을 받을 수 있는 기존 Thread 네트워크가 필요합니다. 양식이 그렇게 말합니다. "계속하기 전에 실제 장치를 페어링 모드로 두십시오. 페어링에는 이 컴퓨터의 Bluetooth를 사용합니다."

무엇인가
장치 이름 그 장치가 Connector에서 가지게 될, 고칠 수 있는 이름입니다. 기본값은 "Matter 장치"이고 자리 표시는 "주방 조명"입니다.
Matter 설정 코드 장치에 인쇄된 정식 11자리 또는 21자리 수동 코드이거나, MT:로 시작하는 QR 페이로드 전체입니다. 입력하는 동안 가려지며 설정 코드 표시가 드러냅니다.
Thread 운영 데이터셋 Thread 네트워크의 활성 데이터셋 전체이며, 16진수 형태로 네트워크 관리자나 Border Router에서 받습니다. "Ganter Lab은 이미 있는 네트워크의 자격 증명을 만들어 낼 수 없습니다." 입력하는 동안 가려지며 데이터셋 표시가 드러냅니다.

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

성공하면 노드 id만을 신원으로 가진 장치가 만들어지고(설정 코드와 데이터셋은 저장되지도, 기록되지도, 다시 보이지도 않습니다), 페이지가 그 장치를 열며, 작업 기록 줄은 "Matter 장치 '주방 조명'을(를) 페어링했습니다."라고 읽힙니다. 노드는 커미셔닝되었지만 장치를 만들지 못했다면 작업 기록 줄이 그렇게 말하고, 되찾는 길은 장치 검색입니다. 실패는 있는 그대로 말해지고 양식은 다시 시도할 수 있도록 열린 채 남습니다. 올바르지 않은 코드나 데이터셋, 쓸 수 있는 Bluetooth 어댑터 없음, Bluetooth 거부나 꺼짐, 맞는 장치를 찾지 못함("장치를 페어링 모드로 두고 가까이에 둔 다음 다시 시도하십시오."), 거부된 설정 코드, Thread 네트워크에 들어오지 못한 장치(그 노드는 Fabric에 남으며 장치 검색으로 되찾을 수 있습니다), 저장하지 못한 Fabric(장치가 이미 커미셔닝된 경우: "Fabric 저장 문제가 풀릴 때까지 장치를 초기화하지 마십시오."), 또는 이미 진행 중인 다른 페어링입니다. 페어링은 한 번에 하나만 돌며, 도는 동안에는 드라이버를 떠날 수 없습니다("이 드라이버를 떠나기 전에 Matter 페어링이 끝나기를 기다리십시오.").

장치 검색이 하지 않는 일

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