OPC UA

다른 회사의 서버에 접속하는 OPC UA 클라이언트이며, 인증서로 신뢰를 가르고 노드 id로 주소를 적으며 주소 공간을 훑어 장치를 검색합니다.

OPC UA 드라이버는 다른 회사의 OPC UA 서버에 접속하는 클라이언트입니다. PLC, 게이트웨이, 히스토리안, 다른 SCADA 시스템이 상대이며 opc.tcp로 이야기합니다. 이 드라이버는 이 스테이션 자신의 주소 공간을 공개하는 내장 OPC UA 서버(OPC UA 서버에서 설명합니다)의 나가는 쪽 짝입니다. 둘은 스테이션의 애플리케이션 신원을 함께 쓰지만, 상대를 신뢰하는 일은 각자 따로 합니다.

장치

서버 준비

대부분의 OPC UA 서버는 출고 상태 그대로는 새 클라이언트를 거절합니다. 이유는 서버 자신의 두 가지 설정이며, 둘 다 서버에서 합니다.

흔히 쓰는 서버에서 클라이언트 인증서를 신뢰하는 곳은 다음과 같습니다.

서버가 두 이유 중 하나로 거절하면, 장치 페이지가 서버 상태 대신 알림으로 어느 이유인지 알려 줍니다. 인증서라면 그 이름과 지문(SHA-1, 서버가 목록에 보여 주는 것)을 각각 복사 버튼과 함께, 그리고 파일을 그 폴더를 여는 버튼과 함께 보여 줍니다. 사용자라면 서버가 익명 세션을 받지 않는지, 아니면 사용자를 거부했는지 알려 주고, 장치의 사용자 이름과 비밀번호를 가리킵니다. 세션이 열리면 알림은 저절로 사라지고, 저널과 에이전트도 같은 안내를 읽습니다. 이 스테이션은 애플리케이션 이름이나 네트워크 이름이 바뀌면 새 인증서를 발급하며, 그러면 서버가 새 인증서를 다시 신뢰해야 합니다.

보안과 인증서

접속은 서버의 endpoint 목록에서 시작합니다. 클라이언트는 서버가 광고하는 가장 안전한 endpoint를 고르고, 이 스테이션 자신의 인증서로 애플리케이션을 인증합니다. 내장 서버가 쓰는 것과 같은 OPC UA 애플리케이션 신원입니다. 많은 서버가 세션을 받아들이기 전에 그 인증서를 자기 쪽에서 신뢰하도록 요구하며. 어디에서 하는지는 서버 준비에 있습니다.

보안 없는 endpoint보다 나은 것을 광고하지 않는 장비는 거부되고, 장치가 그 이유를 말합니다. 그런 세션은 측정값과 자격 증명을 평문으로 실어 나르고 장비의 신원을 전혀 증명하지 못하므로, 그 장치에서 그렇게 요청한 곳에서만 열립니다. 연결 카드의 세션 보안, 보안 없는 세션 허용입니다. 이 선택은 그 장치의 것이고, 그 장치의 주소에 ?security=none으로 실려 다니며, 읽기 세션에도 검색의 훑기에도 똑같이 적용됩니다. 이것을 켜도 보안을 제공하는 장비가 낮춰지는 일은 없습니다. 광고된 것 중 가장 안전한 endpoint가 그대로 선택됩니다.

반대 방향에서 신뢰는 닫힌 채로 실패하며 명시적입니다. 장비의 인증서는 세션이 열리기 전에 확인됩니다.

• 이 스테이션이 한 번도 승인한 적 없는 인증서는 거부되고 검토를 위해 기록되며, 장치 패널은 무엇의 승인을 기다리는지 밝히는 알림을 보여 줍니다. 그 장치는 "오프라인"이 아니라 결정을 기다리고 있는 것입니다.
• 인증서는 이 페이지의 현장 장비 접근 카드에서 검토합니다. 인증서 신뢰의 나가는 쪽 절반입니다. 기록된 인증서는 승인 대기 중에 놓여, 사용자가 승인하거나(새 세션이 열릴 수 있게 됩니다) 차단할 때까지(같은 물음을 되풀이하지 않고 거부합니다) 그 자리에 있습니다. 이것은 현장 장비 목록입니다. OPC UA 서버 패널의 클라이언트 접근은 반대 방향, 곧 누가 이 스테이션 자신의 서버로 들어오는 연결을 맺을 수 있는지입니다.
• 승인된 행의 승인 철회는 그 인증서로 도는 실시간 세션을 닫고 인증서를 검토 목록으로 되돌리므로, 다음 연결에서 다시 묻습니다.
• 인증서를 전혀 내놓지 않는 장비는 누가 응답했는지 아무것도 증명하지 못합니다. 승인할 것이 없으므로 그 세션은 주소를 일지에 적은 뒤 거부됩니다. 같은 보안 없는 세션 허용 아래에서만 연결되며, 그때는 그 선택이 승인을 대신합니다.

장비 서버를 승인하는 일은 그 인증서가 이 스테이션 자신의 서버로 들어오는 연결을 맺도록 허락하는 일이 결코 아닙니다. 두 방향은 일부러 서로 다른 저장소를 씁니다.

세션의 동작

태그는 주기적으로 읽습니다. 읽을 때마다 서버에 그 노드의 현재 값을 묻습니다. 서버 자신의 판정이 샘플마다 함께 실려 옵니다. Bad나 Uncertain이 찍힌 값은 거부되고 태그는 품질이 나쁜 것으로 읽히므로, 의심스러운 신호원이 정상 읽기로 세탁되는 일은 없습니다. 서버에 더 이상 없는 노드는 장치 전체를 실패시키는 대신 값 없음으로 읽힙니다.

서버의 시각도 샘플과 함께 실려 옵니다. 서버가 정상 값에 붙인 SourceTimestamp는 태그 페이지에서 그 태그의 원본 시각이 됩니다. 서버는 값이나 품질이 바뀔 때까지 그 시각을 그대로 둘 수 있으므로, 변하지 않는 값은 애플리케이션 시각보다 앞선 시각을 보일 수 있습니다. 애플리케이션 시각은 언제나 스테이션이 읽기를 받은 순간입니다.

세션은 킵얼라이브로 감시합니다. 킵얼라이브를 세 번 놓치면 클라이언트가 저절로 다시 연결하기 시작하고 하던 일을 이어 갑니다. 처음 연결하는 일은 애플리케이션의 배경 재시도 고리가 맡으므로, 닿지 않는 서버는 시작할 때 아무 비용도 들이지 않습니다.

태그 주소 지정

태그의 주소는 노드 ID로 적으며, 자유 입력으로 쓰고 그대로 보냅니다. 받아들이는 형태는 표준 OPC UA 표기입니다.

태그는 노드의 Value 특성을 읽고 씁니다.

값 형식

값은 스칼라만 다룹니다. 배열과 구조체와 그 밖의 복합 값은 오해를 부르는 숫자 하나로 눌러 담는 대신 읽을 수 없는 것으로 거부되고, 태그는 품질이 나쁜 것으로 읽힙니다. 그런 태그는 자기만 실패합니다. 그 장치의 다른 태그는 계속 읽히고, 그것 때문에 다시 연결되는 일도 없습니다. 빈 문자열은 실패가 아니라 하나의 값입니다. 제시되는 집합 밖의 형식은 이 드라이버에서 태그의 형식으로 쓸 수 없습니다. SByte, Byte를 뺀 부호 없는 너비들(UInt16, UInt32, UInt64), DateTime, Guid, ByteString이 그렇습니다.

태그의 형식이 노드의 형식과 다르면 바이트를 다시 읽는 것이 아니라 숫자로 변환하며, 읽기와 쓰기에 같은 규칙이 적용됩니다. 실수는 실수(Float와 Double)로, 정수는 값이 들어가는 한 너비가 다른 정수로 옮겨집니다. 정수 노드 위의 Boolean 태그는 0과 1을 꺼짐과 켜짐으로 읽고, 쓸 때도 0과 1로 씁니다. 들어가지 않는 값이나, 다른 종류의 값을 담은 노드(정수 태그에 대한 실수, 텍스트 태그에 대한 숫자)는 그 지점에서만 거부되며, 이렇게 거부된 쓰기는 서버로 보내지지 않습니다.

그러므로 서버를 스캔하면 서버가 담고 있는 것보다 적은 채널이 제시됩니다. 값의 목록을 선언하거나 스캔이 읽을 때 값의 목록을 담고 있는 노드와, 형식이 제시되는 집합 밖에 있는 노드는 빠집니다. 많은 서버는 값을 하나만 담는 변수라도 선언된 형태를 열어 둡니다(ValueRank가 Any 또는 ScalarOrOneDimension). 그래서 그런 노드는 스캔이 읽을 때 담고 있는 값으로 판단되며, 그 값이 목록이 아니면 제시됩니다. 나중에 목록을 담게 되면 그 태그 하나만 자기 읽기에서 실패합니다. 태그가 담을 수 없는 다른 값과 마찬가지이며, 그 장치의 다른 태그는 계속 읽힙니다. 노드의 형식은 그 노드가 선언한 형식이 파생된 기본 형식입니다. VersionTime으로 선언된 노드는 UInt32를, UtcTime으로 선언된 노드는 DateTime을 담으므로 둘 다 빠지고, Duration으로 선언된 노드는 Double을 담으므로 제시됩니다. 형태를 열어 두는 서버는 선언된 형식도 열어 두는 경우가 많습니다(BaseDataType, 또는 Number, Integer, UInteger. 어느 값도 이 형식 그대로 전달되지는 않습니다). 그래서 그런 노드는 스캔이 읽을 때 담고 있는 값의 형식을 따르고, 그 형식에 따라 제시되거나 빠집니다. 그런 노드 가운데 읽기에서 값이 돌아오지 않은 노드는 형식을 보여 주지 않으므로 빠집니다. 나중에 서버가 다른 형식의 값을 보내면 그 값은 위의 변환 규칙으로 읽히고, 그 태그는 규칙이 그 값을 거부할 때만 실패합니다. 그렇다고 조용히 버려지지는 않습니다. 스캔은 그것을 세고 마무리 메시지에서 몇 개가 어떤 형식이었는지 말합니다. 예를 들어 "채널 5개가 빠졌습니다. UInt32 형식 3개, 값 하나가 아니라 값의 목록을 담는 것 2개."입니다. 그래서 짧은 목록이 텅 빈 컨트롤러가 아니라 짧은 목록으로 읽힙니다.

서버가 값을 전혀 돌려주지 않는 노드도 빠지며, 세지도 않습니다. 담은 것이 없어서 가져와도 결코 읽히지 않기 때문입니다. 값이 Bad로 돌아오는 노드는 값의 목록을 선언하거나, 열린 형식을 선언하면서 형식을 알 수 있는 값을 돌려주지 않는 경우가 아니라면 계속 제시됩니다. 그 상태는 노드 뒤의 장비가 아직 응답하지 않았거나 스캔의 익명 세션이 그 노드를 읽을 수 없다는 뜻일 뿐이고, 장치는 자기 자격 증명으로 로그인하기 때문입니다.

쓰기

쓸 수 있는 태그는 OPC UA Write 서비스로 노드의 Value 특성에 씁니다. 서버의 응답이 판정입니다. 거부된 쓰기는 실패로 드러나고, 캐시된 값은 받아들여졌을 때에만 앞으로 나아갑니다. 어디에서나 그렇듯 쓰기 칸은 공학값을 받으며, 원시값이 나가기 전에 값 변환 경로가 거꾸로 적용됩니다.

장치 검색

장치 검색 명령은 그 옆 칸에서 대상을 받습니다. opc.tcp://plc-host:4840 같은 OPC UA 서버 주소입니다. 스캔은 두 단계이며, 진행 줄이 지금 도는 단계를 밝힙니다.

1. Endpoint: 대상의 표준 검색 서비스에 묻고, 광고된 모든 검색 URL이 후보 endpoint가 됩니다. 별도의 포트와 서버 경로는 후보의 연결 칸으로 그대로 옮겨 옵니다.
2. 채널: 후보마다 Objects 폴더에서 아래로 주소 공간을 훑고, 읽을 수 있는 변수를 모두 형식과 접근과 함께 후보 태그로 나열합니다(값 형식에서 빠진다고 한 노드는 제외합니다). 서버의 진단 영역은 건너뜁니다.

후보 태그는 자기 노드의 이름(BrowseName)으로 불리며, 서버가 내놓는 다른 채널과 구별하는 데 필요한 만큼만 위 노드의 이름을 앞에 붙입니다. 다른 스테이션의 서버에서는 Devices.Simulated.Tank.Level이 아니라 Level이 되고, Speed라는 노드 두 개가 겹치는 곳에서만 Line1.Speed와 Line2.Speed가 됩니다. 그래도 똑같이 읽히는 두 이름(대소문자나 기호만 다른 이름)은 번호로 구별합니다. 훑은 경로 전체는 후보 카드에 남아 이름 아래 둘째 줄에 나오므로, 각 태그가 어느 노드를 읽는지 알 수 있습니다. 태그는 노드 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가 다음 시도에서 읽기를 시작합니다. 읽히고 있던 장비가 같은 주소에서 다른 인증서를 내밀기 시작하면 읽기가 멈추고 "인증서가 바뀜: <name>"이라는 끈질긴 카드가 올라옵니다. "<address>의 현장 장비는 이 스테이션이 승인한 인증서로 읽히고 있었는데 지금은 다른 인증서(…)를 제시하고 있어, 아무것도 읽지 않습니다. 장비를 관리하는 담당자와 지문을 확인한 다음 승인하십시오." 여기에는 검토가 붙고, 창이 감춰져 있으면 Windows 알림도 함께 나옵니다. 지금 등록하고 있는 중인 장치는 이렇게 알리지 않습니다. 등록하는 사람은 이미 Connector를 보고 있기 때문입니다.

승인 대기 중

인증서가 하나라도 기다리는 동안 그려지며, "이 장치들은 결정하기 전까지 읽히지 않습니다."라는 머리와 개수를 담습니다. 줄마다 호박색 점, 인증서가 주장하는 이름, "장비가 주장하는 신원", 지문, "<address> · 마지막 시도 <date and time> · 연결 시도 N회", 그리고 주체, 발급자, 애플리케이션 URI, 도메인 이름, 유효 시작, 유효 종료, 처음 본 시각을 담은 인증서 상세 펼침이 있습니다. 검토 단추가 데려온 줄에는 "검토하도록 선택됨" 표시가 붙고 눈에 들어오도록 스크롤됩니다.

이 목록은 최대 100개의 인증서를 담습니다. 가득 찬 동안 그다음 인증서는 물리치되 남지 않고, 카드가 그렇게 말합니다. "아래 검토 목록이 가득 찼습니다. 가득 찬 동안에는 새 인증서가 이 목록에 오르지 못한 채 거부되므로, 기다리는 장비가 끝내 나타나지 않을 수 있습니다. 자리를 만들려면 검토를 기다리는 인증서를 버리십시오." 가득 찬 뒤에 거부된 것이 생기면 그 개수도 함께 나옵니다. 그런 거부는 모두 진단 로그에 남습니다.

승인된 현장 장비

"Connector가 세션을 열 수 있는 인증서입니다."와 개수입니다. 줄마다 중립 점, 주장하는 이름, "장비가 주장하는 신원 · <user>이(가) <date and time>에 승인함"(또는 "이 스테이션에서"), 지문, 그리고 주소, 주체, 발급자, 애플리케이션 URI, 유효 종료, 마지막으로 본 시각을 담은 상세 펼침이 있습니다. 하나도 없으면 "승인된 현장 장비 인증서가 없습니다."입니다.

머리 아래의 힌트입니다. "장비의 공개 인증서를 이미 가지고 있습니까? 첫 연결이 한 번 실패하게 두는 대신, 여기에서 가져와 미리 승인하십시오. 추가된 지문을 장비 설명서에 적힌 지문과 대조하십시오." 장비는 보통 자기 인증서와 함께 오므로, 이쪽에서는 가져오기가 먼저입니다. 차단된 인증서를 가져오면 차단이 풀립니다. 승인을 철회하면 인증서는 차단이 아니라 검토로 돌아갑니다. 다시 물어 달라고 한 것이기 때문입니다.

차단된 현장 장비

접혀 있는 펼침이며 개수와 함께 "차단된 현장 장비"로 적히고, 하나라도 있을 때에만 그려집니다. 줄마다 빨간 점, 주장하는 이름, "장비가 주장하는 신원 · <user>이(가) <date and time>에 차단함", 지문, 그리고 승인하지 않은 채 검토 목록으로 되돌리는 차단 해제가 있습니다. "<name>의 차단을 해제했으며 검토 목록으로 돌아갔습니다." 차단된 인증서가 스스로 돌아오는 일은 결코 없습니다.

결정이 남는 곳

현장 장비 보관소는 스테이션 데이터 뿌리의 ua\pki\southbound 아래에 있고(pending, trusted, blocked과 SDK 자신의 rejected), 인증서마다 어느 주소에서 보였는지, 시도 횟수, 결정은 equipment-access.json에 있습니다. 들어오는 쪽 보관소와 따로 있으므로, 현장 장비 인증서가 어떤 애플리케이션이 스테이션 자신의 서버에 접속해도 된다는 허가가 되는 일도, 들어오는 요청으로 나타나는 일도 결코 없습니다. 구성 백업의 일부가 아닙니다.

이 구역이 하지 않는 일

자동으로 승인되는 것은 아무것도 없고, 그것을 끄는 설정도 없습니다. 이 카드는 장치 자체를 설정하지 않고(주소, 자격 증명, 주기적 읽기는 Connector에 있습니다), 장비의 실시간 값을 보여 주지 않으며, 이 스테이션에 전화를 거는 애플리케이션에 대해 결정하지도 않습니다. 그것은 클라이언트 접근입니다.