https://red-nose-cousin.tistory.com/2?category=874877
OPCUA 통신 쉽게 알기 - 1편 OPC 란 무엇인가
OPCUA 서버와 클라이언트를 개발하고 나서 관련 강의를 들으러 다니다 보니 실제 현장의 요구 만큼의 교육을 받기가 힘들어서 블로그에 글을 남겨보려고 합니다. 이런 분들에게 도움이 되길 바
red-nose-cousin.tistory.com
1. OPC 란 무엇인가?
OPC(OLE for Process Control) 의 약자입니다. 표준화된 통신 프로토콜입니다.
OPC Foundation 에 의해서 관리되고 있습니다.
기존에 약자를 따르는 통신이 OPCDA 즉 OPC Classic 이라고 합니다.
그리고 OPCUA로 발전하면서
(Open Platform Communications Unified Architecture)로 변경되었습니다.
개방형 플랫폼 커뮤니케이션 통합 아키텍처라는 뜻이네요.
머리 아프실 수 있는데
최초에 OPC Classic 의 개념이 나와서 윈도우 환경에서만 돌아가는 버전이 OPC-DA 입니다.
그래서 DCOM 으로 통신을 하기 때문에 포트도 지정 되어있지요.
외부에서 접속하기에 설정도 까다롭습니다.
만약에 독자분께서 일하고 계신 환경에서
PLC에 OPC 기능이 들어있다고 한다면 그것은 UA가 들어간것 입니다.
PLC에 윈도우를 설치할 수는 없으니까요.
OPCUA와 DA의 차이는 다음편에서 설명 드리겠습니다.
OLE - OLE는 윈도우의 각각의 객체(Object)를 응용프로그램에서 다양하게 사용할 수 있는
(Object Linking & Embedding) 기능을 의미합니다.
DCOM - (Distributed Component Object Model, DCOM) 으로
네트워크 컴퓨터 사이에 컴포넌트 간 통신을 위한 마이크로 소프트 기술을 의미합니다.
통신프로토콜 - 통신을 원하는 서로 다른 시스템이
어떤 식으로 어떻게 통신할 것인가를 정하는 규범입니다.
쉽게 말하자면 군대에서 암구호 처럼 서로 대화하기 전에 암구호 주고받고 대화하는 것 같이요.
깊게 들어가면 어려우나 쉽게 생각하면 어렵지 않습니다.
어떤 데이터를 주고받을 건지, 언제 주고받을 건지, 최대 얼마나 주고 받을 건지 같은 것을 지정해 놓습니다.
2. OPC 의 목적이 무엇인가?
밑에 그림과 같이 PLC는 제각각의 프로토콜로 통신을 합니다.
결국 PLC의 데이터를 상위시스템으로 인터페이스를 하기위해서는
PLC 별로 통신 드라이브를 구축해야합니다. 아래 그림 1을 참고해봅시다.
물론 그림 1. 과 같이 시스템을 구성할리는 없겠지요. 극단적인 예를 들어보았습니다. 생산장비 1대에 PLC가 1대가 있는데 그 PLC의 제품이 모두 다르다면 어떻게 될까요? 각각 다른 통신 프로토콜 별로 통신을 해야 되는 상황이 옵니다. 그래서 많은 HMI 회사들이 상위 시스템으로 데이터를 보내줄때 많은 드라이버들을 제공하고 있습니다. 그럼 OPC로 구성하게 되면 어떻게 되는지 그림2. 로 보겠습니다.
자 그럼 이런 질문이 생길 수 있을겁니다. 결국 OPC 서버가 프로토콜 통신을 해주면서 서버와 클라이언트 구조로 바뀐것 밖에 없는데 시스템 차원에서 어떠한 이득이 있을까요.
뭐가 다른지 다음편에서 이야기 해보도록 하겠습니다.
3. OPC를 도입해야 하는 이유
지난 글 마지막에서 다루었듯이
프로토콜 통신이 OPC 통신으로 바뀌게 되면 어떤 이득이 있는지 다루어 보도록 하겠습니다.
그림 3. 을 보면 다소 복잡하게 되어있지만 결론은 심플합니다.
바로 같은 통신 방법으로 하위에서 상위까지 모두 동일한프로토콜로 통신이 가능합니다.
만약 드라이버별로 나누어진 통신 프로토콜을
중국어, 한국어, 영어라고 한다면 서로 의사소통을 하기 힘들겠지요.
그래서 한가지 언어로 통합해서 의사소통을 하기위해서
OPC를 구성한다라고 이해하시면 편합니다.
이것을 상호운용성을 확보했다라고 표현합니다.
하지만 이런 의사소통을 좀 더 효율적으로 하기 위해서
OPC 서버는 많은 기능들을 제공해주고 있습니다.
상호운용성 - 하나의 시스템이 동일 또는 이기종의 다른 시스템과 아무런 제약이 없이
서로 호환되어 사용할 수 있는 성질을 말한다.
처음에는 정보통신(IT) 또는 소프트웨어 개발 분야에서 사용되는 용어였으나,
이후 정치, 법률, 군사, 사회, 조직 등 다양한 분야로 확산되어 사용되고 있다.
4. OPC 의 기능 (서비스)
Classic OPC 표준을 통해
DA(Data Access), AE(Alarm & Events), HDA(Historical Data Access)의
세가지의 서버의 서비스를 제공합니다.
DA는 말그대로 Data Access 입니다.
PLC의 현재값을 확인하고 받아올 수 있습니다. 산업현장에서 가장 유용하게 쓰는 기능입니다.
과거의 데이터는 받지 못합니다. 이 부분이 HDA와 비교된다고 볼 수 있습니다.
HDA는 과거의 데이터를 가져올 수 있습니다.
OPC HDA 서버에서 현재 데이터를 Local historian 에 저장하고
그것을 클라이언트에서 Access 합니다.
AE 는 알람엔 이벤트로 알람 TAG를 등록하면 해당 알람이 True로 바뀌었을때
이벤트로 클라이언트에 알려주는 기능입니다.
이렇게 Classic OPC는 서버가 3가지로 분류가 되어있습니다.
5. OPCUA, OPCDA 의 차이
OPC Classic(OPCDA)의 경우 4번항에서 설명했던 3개의 서버가 분리되어있었습니다.
그리고 맨 처음 글에서 말씀드렸듯이 윈도우에서만 동작을 했습니다.
OPCUA에서는 기존 OPC Classic의 DA/AE/HDA 에 Security를 보완해서 크로스 플랫폼으로 제공합니다.
즉, 윈도우를 벗어날 수 있게 되었습니다.
그림 5. 와 같이 Classic OPC는
Windows의 기술인 COM과 DCOM이라는 커다란 장벽이 존재했습니다.
결국 컴퓨터를 거치지 않으면 안되는 구조였던 겁니다.
OPCUA개념이 나오면서 많은 PLC 제조사들이
PLC에서 직접 서버를 구축하는 형태로 제품을 출시하기 시작했습니다.
6. OPC와 PLC의 연결 개념 잡기
이 항목이 제가 이 글을 쓰게된 주된 이유입니다.
OPC서버와 PLC는 어떤 구조로 연결이 되어있을까요?
이 부분이 많은 개발자들이 궁금해 하는 부분입니다. 저도 마찬가지였습니다.
OPC 서버를 개발하기 위해서는 기본적으로 PLC 프로토콜을 개발해야 합니다.
구성은 다음과 같습니다.
결론부터 말씀드리자면
PLC에 있는 메모리에 있는 값을 서버를 통해 클라이언트에서 받아온다고
이해하시면 됩니다.
장비에 부착된 센서는 PLC와 연결이 되어있습니다.
① 이 센서의 값은 Ladder 프로그램을 거칩니다. (물론 다른언어를 거치기도 합니다.)
② 해당 데이터는 PLC 메모리의 D 영역의 0001에 Word로 저장이 됩니다.
③ 이 저장된 데이터는 OPC 서버에서 사용자가 지정한 NodeID 의 value가 됩니다.
이때 PLC와 OPC서버는 통신을 하게 되며
PLC와 TCP나 UDP 통신을 하기위해 통신 드라이버가 필요합니다.
④ Node 의 value와 datatype 등의 OPC 서버가 제공해주는
속성들의 객체인 Node를 OPC 클라이언트가 받습니다.
결국 PLC와 OPC서버간의 통신은
PLC의 통신프로토콜 (예를 들면 LS산전은 LS-Fenet, 미쯔비시는 Melsec 등.)로 통신합니다.
그리고 OPC 서버와 OPC 클라이언트는 서버와 클라이언트 통신을 하게 됩니다.
그래서 PLC 레벨에서 OPCUA를 적용하고 싶을때는
반드시 해당 OPCUA 서버를 지원하는 PLC가 어떤 통신 프로토콜을 지원하는지 확인하셔야 합니다.
범용 통신프로토콜인 모드버스를 지원한다면
Ladder 프로그램을 모두 모드버스 메모리 영역대로 수정해야 합니다.
이런 케이스의 연결은 예를 들어 [LS PLC - OPC서버용 PLC - 네트워크 - 상위시스템] 이런 구조일때를 의미합니다.
7. OPCUA 데이터의 구조
6번을 읽어보신 분들은 모르는 부분이 많으셨을 겁니다.
아무래도 OPCUA의 데이터가 어떤식으로 구성되어있는지 모르는 경우가 있을테니까요.
이 부분에 대해서 자세하게 설명하고 넘어가겠습니다.
테스트 OPCUA 서버에 클라이언트로 붙어서 구조를 한번 살펴보겠습니다.
그림7 과 같이 OPCUA 서버는 트리구조로 데이터를 제공합니다.
트리구조는 [Root - Object - 공정라인 - 연결된 장비 - 연결된 PLC의 메모리주소 ] 의 구조를 가지고 있습니다.
현재 그림상에서는 Root - Object - TEST LINE - EQUIP 까지 되어있는 것을 알 수 있습니다.
트리의 Depth는 서버개발자에 따라 변동될 수 있습니다.
물론 공정라인과 연결된 장비의 의미는 회사 사정에 따라 다르게 규정할 수 있습니다.
OPCUA에서는 이 트리에 있는 항목을 Node라고 부릅니다. 또는 Tag라고도 해요.
이 Node들은 다음과 같은 속성들을 제공합니다.
여기서 Root와 Object와 TEST LINE 의 Node는 Object 클래스를 지니고 있습니다.
Object 클래스를 지닌 노드 들은 폴더라고 이해하시면 됩니다.
결국 우린 폴더에 접근하는것 보다는 폴더 안에 있는 Node가 가지고 있는 현재 PLC의 값에 접근해야 합니다.
(지금 해당 프로그램으로 보고 계신 내용들은 프로그래밍 Source 레벨에서 모두 확인이 가능합니다.
트리의 구조나 속성들이 가지고 있는 값들 모두 OPCUA에서 제공하는 라이브러리를 통해 받아볼 수 있습니다.)
먼저 그림 9의 1번을 보겠습니다.
TEST WORD는 제가 PLC의 임의의 어드레스와 연결을 시켜놓았습니다.
1Word 메모리를 지정하였으며 UInt16의 데이터 타입으로
OPCUA서버에서 클라이언트에 보내주고 있습니다.
만약 이 설명이 이해가 힘드시다면 6번항을 다시 읽고 오시면 이해가 되실겁니다.
한문장으로 정리하자면 PLC의 값을 OPC 프로토콜을 통해서 보고 있다라고 이해하시면 됩니다.
2번을 보시면 NodeId 라는 항목이 있습니다.
클라이언트에서 서버의 정보를 가져오기 위해서는 해당 Id를 알아야 합니다.
이 아이디는 서버를 구축하는 사용자가 마음대로 지정할 수 있습니다.
NodeId는 [ns=2;s=TEST LINE.EQUIP.TEST BOOLEAN] 라는 이름으로 string 타입으로 제공하고 있습니다.
앞에 ns = 2 라는 의미는 NamespaceIndex를 의미합니다.
이 NodeId의 구조는 ns=<namespaceindex>;<type>=<value>
위와 같이 구성이 되어있습니다. 여기서 지원하는 타입<type>은 4개입니다.
- Numeric (value is a UInteger)
- String (value is a String)
- Guid (value is a Guid/UUID)
- Opaque (value is ByteString)
그림 8의 3번을 보시면 가장 중요한 Value 항목입니다. Value 항목에서 의미하는 타임스탬프와 Value의 의미는 다음과 같습니다.
1. SourceTimestamp : OPC서버에서 PLC의 값을 읽어온 시간
2. ServerTimeStamp : OPC서버에서 클라이언트로 값을 준 시간
3. Value : 서버에서 PLC로 부터 가져온 값
데이터 타입은 OPC 표준에서 제공하는 데이터 타입중 UInt16을 의미합니다. 데이터 타입은 지정이 되어있습니다.
그림 10. OPCUA 가 제공하는 데이터타입 (.Net 으로 호환시)
클라이언트 프로그램(UA EXPERT) 다운로드 링크
https://www.unified-automation.com/products/development-tools/uaexpert.html
다음 글에서는 OPCUA 의 PUB/SUB 과 SECURITY 에서 다루겠습니다.
그리고 조만간 NodeJS를 통한 클라이언트 접속,
그리고 C#을 통한 클라이언트 접속법과 데이터 가져오는 두가지 루트에 대해서
소스를 통해 설명드리겠습니다.
이번 시간에는 Pub/Sub에 대해서 알아보겠습니다.
스마트 공장의 가장 기초적인 단계는 실시간 현재 데이터를 확인하는 것이겠지요.
이러한 실시간 데이터를 받아보기 위한 OPCUA 프로토콜의 핵심은 바로 Pub/Sub 입니다.
8. Pub/Sub 이란 무엇인가.
컴퓨터 용어는 사실 아무것도 아닌데 단어만 어려운 경우가 많습니다.
Pub/Sub도 마찬가지에요. Publish / Subscription 입니다. 발행과 구독을 의미합니다.
이 개념은 알아놓으면 좋은 것이 산업용 프로토콜 대부분은 이 기능이 있습니다.
그림으로 설명드릴게요.
위의 그림 10. 과 같이 Client 가 Server에게 요청을 합니다.
요청을 할때는 받고 싶은 데이터의 항목을 정할 수 있고 시간 간격도 정할 수 있습니다.
Queue도 정할 수 있지요. 아주 간단합니다. 꼭 잡지를 구독하는 것과 같지요.
1달에 한번씩 잡지를 구독한다고 가정해볼게요.
그럼 원하는 잡지명, 그리고 1달에 한번 배달받을 날짜 등등을 잡지사에 알려야겠지요.
그럼 가만히만 있어도 구매자 입장에서는 알아서 잡지를 받아볼 수 있습니다.
택배기사님이 띵동하고 방문해서 잡지가 왔음을 알려주시겠죠?
만약에 이 기능을 사용하지 않으면 개발자 입장에서 얼마나 까다로운지 설명드리도록 할게요.
Pub/Sub을 사용하지 않으면
Client는 서버에 내가 원하는 주기마다 timer 혹은 thread를 돌면서
최신값을 달라고 요청을 해야합니다.
이 루틴도 비효율적이지만 문제는 값이 바뀌었을때를
인지할 수 있도록 클라이언트를 개발해야 해요. 상당히 번거롭고 귀찮습니다.
하지만 Pub/Sub을 요청하면
클라이언트에서는 가만히만 있어도
이벤트가 발생해서 Server에서 값이 바뀐 것을 알아차릴 수 있습니다.
9. OPCUA의 Pub/Sub
8번에서 Pub/Sub이 무엇인지 알았다면 OPCUA 에서는 어떤식으로 Pub/Sub을 사용하는지 알려드리겠습니다.
오랜만에 다시 글을 적습니다. OPCUA 서버와 클라이언트를 개발해야될 일이 있어서 많이 늦었네요.
글을 적다보니 코드레벨 까지 가는 길이 멀고도 험하네요. ㅎㅎ
지난글에서 제가 Pub/Sub에 대한 개념을 설명을 드렸습니다.
OPCUA의 Pub/Sub은 어떠한 구조로 있는지 알아보도록 하겠습니다.
Subscription은 구독이라고 지난번에 설명을 드렸습니다.
이 구독 밑에는 하위 항목인 구독하고 싶은 리스트가 있습니다.
그것을 Monitored items라고 합니다.
내가 모니터링 하고 싶은 아이템들 이라는 뜻이에요.
그럼 이 아이템들 밑에는 모니터링 아이템의 각각 개별 요소가 있겠지요.
이런 형태로 구성이 되어있습니다.
DataChangeTrigger 는 총 3가지의 Filter를 제공합니다. (실제 코드상에서는 Filter로 표기되어있습니다.)
1. STATUS - Good, Bad를 의미합니다. Raw데이터의 상태, 즉
PLC의 연결이 좋고 데이터가 문제가 없다면 Good, 그게 아니라면 Bad로 표시됩니다
2. STATUS VALUE - STATUS 와 VALUE의 OR 조건입니다.
둘중에 하나라도 변경되면 알려줍니다. (알려주는 것이 Notification 입니다.)
아마 가장 많이 쓰지않을까 싶습니다. VALUE가 변경될떄마다 알려주니까 매우 편합니다.
3. STATUS VALUE TIMESTAMP - 2번외에 타입스탬프가 추가된 조건입니다.
타임스탬프는 servertimestamp 가 있고 sourcetimestamp가 있습니다.
초기 PLC의 Raw데이터가 와서 서버의 Queue에 적재되는 시간이
Servertimestamp 기 때문에 민감하게 조절한다면
더 해상도가 높은 데이터를 얻을수 있지만 실제 서버의 PLC Polling 시간보다 작을 수는 없겠죠.^^
다음시간에 간단하게 인증에 관련된 글을 적고 그 다음에 코드레벨로 들어가보도록 하겠습니다.
오랜만입니다. 게을러서 글을 올리지 못했습니다.
요즘 다른거 개발한다고 기존에 만든걸 까먹기까지 해서
정말 포스트해야지 마음먹기가 너무 힘드네요. 나이를 먹어서 그런걸까요?
OPCUA의 인증은 대략적으로 알고있어서 알고있는 수준에서만 설명을 드리겠습니다.
인증부분은 제가 테스트만 해봤지 정확한 개념을 알고있지 못하기 때문에
만약 오류가 있다면 집단지성으로 저를 꾸짖어주시기 바랍니다. ^^
제가 개발했던 환경에서는 None 방식을 사용했었습니다.
보통 우리가 말하는 OA망과 FA망이 분리되어있다면 None으로 해도 상관이 없습니다.
만약 그렇지 않다면 OPCUA 인증을 사용해야겠지요.
만약 None 방식으로 OPCUAfoundation에서 받은 서버소스를 사용하고 싶다면
XML의 주석을 해제하셔야 합니다. 이것은 다음포스트에서 다룰게요.
10. OPCUA의 인증
인증이라. 인증은 왜할까요? 만약에 아무런 보안도 되어있지 않다고 가정을 해보겠습니다. 시계열 제조데이터는 사실 분석하기도 까다로운 정보이지만 이 정보를 가지고 있는 입장에서는 누군가 내 데이터를 본다는 것은 보안상 이슈일 수 있습니다. 뿐만 아니라 내 OPCUA 서버에 아무 클라이언트나 마음대로 접근해서 생산 값을 내려버린다면 더 큰일이겠지요. 그래서 데이터베이스같은 경우는 role을 정하여 특정 사용자만 데이터베이스 조작을 가능하게 하기도 합니다. 이러한 일들을 하기위해 필요한 것이 바로 인증절차입니다.
OPCUA 는 아래 4가지 방법으로 인증합니다.
1) Tier 1 : No Authentication
- 클라이언트, 서버 모두 서로에 대한 권한 확인 없이 통신 진행. 인증서는 상호간에 교환해야 하고 유효하지 않은 인증서인 경우 통신이 되지 않는다. 독립된 네트워크 환경 혹은 보안이 필요하지 않는 공공 데이터인 경우가 이에 해당한다.
2) Tier 2 : Server Authentication
- 서버는 모든 클라이언트의 접근을 허용하고 클라이언트가 서버의 유효성 유무를 판단한다.
- 서버는 ID / Password , 사용자의 개인인증서를 이용하여 인증 관리가 가능하다.
- 클라이언트는 서버가 전송한 인증서가 신뢰하는 CA(Certificate Authority)에서 발행한 인증서이거나, 신뢰하는 인증서로 등록되어 있는 경우 통신을 허용한다.
- 미등록 인증서인 경우, 인증서의 도메인 정보와 실제 접속하고 있는 서버의 도메인의 일치 여부를 확인하고 일치하면 접속을 허용한다.
3) Tier 3 - Client Authentication
- 클라이언트는 검증없이 서버에 접속하고 서버에서 클라이언트를 인증한다.
4) Tier 4 - Mutual Authentication
- 서버, 클라이언트 상호간에 인증한다.
어려운 그림도 하나 첨부해보겠습니다.
자체 서명된 인증서의 관리
저는 도저히 무슨말인지 처음에는 그림만 보고 몰랐습니다. 쉽게 설명해드릴게요.
OPCUA는 인증서라는 것이 있습니다. 서버는 서버 인증서가 있고 클라이언트는 클라이언트 인증서가 있습니다. 그리고 인증서를 저장하는 Folder가 있습니다.
- 만들어진 인증서의 기본저장 폴더 위치는 아래와 같습니다.
C:\ProgramData\OPC Foundation\CertificateStores\MachineDefault\certs
C:\ProgramData\OPC Foundation\CertificateStores\UA Applications\certs
OPCUA의 인증을 사용하기 위해서는 다음과 같이 하면 됩니다. 신뢰하는 인증서의 위치는 기본적으로 제공하는 XML에 표기되어있습니다. 별도의 클라이언트 프로그램을 쓰는 경우라면 클라이언트 프로그램 내부에 인증서에 대한 기능이 들어있을 겁니다.
1) 서버가 클라이언트를 인증하는 경우 (Tier 3)
- 클라이언트 인증서를 서버의 신뢰하는 인증서 저장위치로 저장하면 됩니다.
C:\ProgramData\OPC Foundation\CertificateStores\UA Applications\certs
2) 클라이언트가 서버를 인증하는 경우 (Tier 2)
- 서버 인증서를 클라이언트의 신뢰하는 인증서 저장위치로 저장하면 됩니다.
C:\ProgramData\OPC Foundation\CertificateStores\UA Applications\certs
3) 상호 인증
- 서로의 인증서를 각각의 신뢰하는 인증서 위치에 복사 붙여넣기 하면 됩니다.
인증이라고 하면 내부적으로는 대단한 기술이 들어갈테지만 사용자 입장에서는 이정도만 알아도 되지 않을까 싶네요.
https://red-nose-cousin.tistory.com/14?category=874877
'OPC UA' 카테고리의 다른 글
| 질문으로 알아보는 스마트팩토리 - 'OPC UA' (하) 편 (0) | 2022.08.27 |
|---|---|
| 질문으로 알아보는 스마트팩토리 - 'OPC UA' (상) 편 (0) | 2022.08.27 |