IT 지식/OPCUA

OPCUA 통신 쉽게 알기 - 3편 OPC 서버와 PLC 의 연결

셔니아빠. 2020. 2. 10. 15:15

6. OPC와 PLC의 연결 개념 잡기

 

 이 항목이 제가 이 글을 쓰게된 주된 이유입니다. OPC서버와 PLC는 어떤 구조로 연결이 되어있을까요? 이 부분이 많은 개발자들이 궁금해 하는 부분입니다. 저도 마찬가지였습니다. OPC 서버를 개발하기 위해서는 기본적으로 PLC 프로토콜을 개발해야 합니다. 구성은 다음과 같습니다. 결론부터 말씀드리자면 PLC에 있는 메모리에 있는 값을 서버를 통해 클라이언트에서 받아온다고 이해하시면 됩니다.

그림 6. Sensor 의 데이터가 OPC 클라이언트까지 가는 데이터 흐름

 장비에 부착된 센서는 PLC와 연결이 되어있습니다.

(1) 이 센서의 값은 Ladder 프로그램을 거칩니다. (물론 다른언어를 거치기도 합니다.)

(2) 해당 데이터는 PLC 메모리의 D 영역의 0001에 Word로 저장이 됩니다.

(3) 이 저장된 데이터는 OPC 서버에서 사용자가 지정한 NodeID 의 value가 됩니다. 이때 PLC와 OPC서버는 통신을 하게 되며 PLC와 TCP나 UDP 통신을 하기위해 통신 드라이버가 필요합니다.

(4) 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 서버의 구조

그림7 과 같이 OPCUA 서버는 트리구조로 데이터를 제공합니다. 트리구조는 [Root - Object - 공정라인 - 연결된 장비 - 연결된 PLC의 메모리주소 ] 의 구조를 가지고 있습니다. 현재 그림상에서는 Root - Object - TEST LINE - EQUIP 까지 되어있는 것을 알 수 있습니다. 트리의 Depth는 서버개발자에 따라 변동될 수 있습니다. 물론 공정라인과 연결된 장비의 의미는 회사 사정에 따라 다르게 규정할 수 있습니다. OPCUA에서는 이 트리에 있는 항목을 Node라고 부릅니다. 또는 Tag라고도 해요. 이 Node들은 다음과 같은 속성들을 제공합니다. 

그림 8. OPCUA의 Node Class

 여기서 Root와 Object와 TEST LINE 의 Node는 Object 클래스를 지니고 있습니다. Object 클래스를 지닌 노드 들은 폴더라고 이해하시면 됩니다. 결국 우린 폴더에 접근하는것 보다는 폴더 안에 있는 Node가 가지고 있는 현재 PLC의 값에 접근해야 합니다. (지금 해당 프로그램으로 보고 계신 내용들은 프로그래밍 Source 레벨에서 모두 확인이 가능합니다. 트리의 구조나 속성들이 가지고 있는 값들 모두 OPCUA에서 제공하는 라이브러리를 통해 받아볼 수 있습니다.)

그림 9. OPC 서버에서 주는 Node의 정보와 구성

 먼저 그림 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개입니다.

 

  1. Numeric (value is a UInteger)
  2. String (value is a String)
  3. Guid (value is a Guid/UUID)
  4. 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#을 통한 클라이언트 접속법과 데이터 가져오는 두가지 루트에 대해서 소스를 통해 설명드리겠습니다.