OPC UA란? 간단 정리 및 요약(아키텍쳐의 이해, Classic OPC와의 차이)

 

OPC UA 간단 정리 및 요약(아키텍쳐의 이해, Classic OPC와의 차이)

 

OPC UA란?

Open Platform Communications Unified Architecture의 줄임말로 

산업용 표준 프로토콜을 말합니다.

 

*영어 원문을 읽고 주관적인 해석으로 기술한 내용이기 때문에 정확성이 떨어질 수 있다는 점 참고해주시길 바랍니다.

*영어 원문에 기반하기 때문에 중요한 의미는 추가적으로 영어를 붙혀서 서술합니다.

 

 

1. 클래식 OPC 인터페이스의 개요

 

먼저 OPC UA를 이해하려면 클래식 OPC에 대해서 알아두어야 합니다.

OPC UA가 클래식 OPC에서 발전된 형태이기 때문에 이 둘의 차이를 알아야지 이해가 편합니다.

 

산업 자동화 어플리케이션을 위한 인터페이스로 HMI 및 SCADA 시스템과 같은 인터페이스들이 있는데, 클래식 OPC는 디바이스에서 현재 데이터를 소비하고 관리 어플리케이션으로 데이터와 이벤트를 제공해주는 역할을 가지고 있습니다.

 

산업 응용 분야의 다양한 요구사항에 따라 데이터 엑세스(DA), 경보 빛 이벤트(AE), 기록 데이터 엑세스(HDA)가 주요 세가지 OPC 사양입니다.

 

프로세스 데이터에 대한 엑세스는 DA 사양에 설명되어 있고, AE는 프로세스 알람 승인을 포함하여 이벤트 기반 정보에 대한 인터페이스를 설명하고, HDA는 보관되어 있는 데이터에 액세스하는 기능을 설명합니다.

 

모든 인터페이스는 주소 공간(Address Space)를 탐색하고 사용가능한 데이터에 대한 정보를 제공합니다.

 

OPC는 정보 교환을 위해 클라이언트-서버 접근 방식을 사용합니다.

 

OPC 서버는 장치와 같은 프로세스 정보 소스를 캡슐화 하고 인터페이스를 통해 정보를 사용할 수 있게 합니다.

 

 

 

위 사진은 OPC 서버와 클라이언트의 일반적인 사용 사례의 구조입니다.

 

클래식 OPC 인터페이스는 Microsoft의 COM 및 DCOM 기술의 기반입니다.

 

COM 및 DCOM은 클라이언트가 동일한 프로세스, 다른 프로세스 또는 다른 네트워크 노드에서 실행중인 서버의 COM 개체에서 메서드를 호출할 수 있는 투명한 메커니즘을 제공합니다.

 

하지만 이런 클래식 OPC는 두 가지 단점이 있는데, 하나는 OPC의 Windows 플랫폼에 종속되어 있다는 것이고, OPC와의 원격 통신시 DCOM에 문제가 발생한다는 점(Network)입니다.

 

DCOM은 구성이 어렵고 구성이 매우 길고 구성 불가능한 시간 제한이 있으며 인터넷 통신에 사용할 수 없다는 단점이 있습니다.

 

 

 

 

2. OPC 데이터 엑세스(DA)

 

 

OPC 데이터 엑세스 인터페이스는 현재 프로세스 데이터가 포함된 변수를 읽고 쓰고 모니터링 할 수 있는 기능입니다.

그 사용 사례로서, DLC, DCS 같은 기타 제어 장치에서 HMI 및 디스플레이를 할 수 있는 클라이언트로 실시간 데이터를 이동하는 것입니다.

 

분산되어 있는 단말기에서 수집한 데이터를 한 곳에서 모니터링 하는 것이지요.

 

OPC DA는 가장 중요한 것은 OPC 인터페이스입니다.

 

OPC DA 클라이언트는 서버에서 읽고 쓰거나 모니터링 할 수 있는 변수(OPC Object)를 명시적으로 선택합니다.

 

OPC 클라이언트는 OPC Server Object를 작성하여 서버에 연결합니다.

 

Server Object는 주소 공간 계층 구조(Address Space Hiarechey)를 탐색하여 데이터 유형 및 액세스 권한과 같은 항목 및 해당속성을 찾는 방법을 제공합니다.

 

데이터에 엑세스하기 위해 클라이언트는 OPC Group 개체의 업데이트 시간과 같은 동일한 설정으로 OPC 항목을 그룹화합니다.

 

 

 

데이터에 엑세스하기 위해 OPC 클라이언트가 생성한 Object의 흐름도입니다.

 

OPC Item이 OPC Group에 추가되면 클라이언트가 항목을 읽거나 쓸 수 있습니다.(Read&Write기능)

 

그러나 클라이언트가 주기적으로 데이터를 읽는 가장 좋은 방법은 서버의 값 변경을 모니터링하는 것입니다(OPC A&E를 활용하라는 것).

 

OPC는 장치와의 통신이 일시적으로 중단되는 경우와 같이 영구적으로 액세스할 수 없는 실시간 데이터를 제공합니다.

 

클래식 OPC 기술은 전달된 데이터에 타임 스탬프 및 품질을 제공하여 문제를 처리합니다.

 

여기서의 품질은 데이터가 좋거나(Good), 이용할 수 없거나(Bad), 알려지지 않는 지(Uncertain)를 지정합니다.

 

 

 

 

3. OPC 경보 및 이벤트(OPC Alarm & Events)

 

*Alarm을 경보로 명시해서 기술합니다.

 

클라이언트는 OPC A & E 인터페이스를 통해 이벤트 알람 및 경보을 수신할 수 있습니다.

 

이벤트(Event)는 클라이언트에게 이벤트 발생을 알리는 단일 알람입니다.

 

경보(Alarm)은 프로세스의 조건 변경에 대해 클라이언트에게 알리는 알림입니다.

 

이러한 상태는 Tank라고 하는 레벨을 기준을 두는데, Tank가 최대 레벨 제한을 초과하거나, 최소 레벨 아래로 떨어지게 되면 조건 변경이 발생할 수 있습니다.

 

OPC AE는 다른 이벤트 소스에서 프로세스 알람 및 이벤트를 전송하기 위한 유연한 인터페이스를 제공합니다.

 

알림을 받으려면 OPC AE 클라이언트가 서버에 연결해 알림을 구독(Subcribe)하고, 서버에서 트리거(Trigger)된 모든 알림을 수신합니다.

 

특정 서버에 연결해서 특정 Object의 데이터가 변경이 발생할 경우(Trigger), 이 데이터가 변경되었다는 사실을 클라이언트에게 통지하는 것이지요.

 

알림 수를 제한하기 위해 OPC 클라이언트는 특정 필터 기준을 지정할 수 있습니다.

 

OPC 클라이언트는 첫번째 단계에서 AE 서버에 OPCEventServer 오브젝트를 작성하고, 두번째 단계에서 이벤트 메시지를 수신하는 OPCEventSubscription을 생성하여 연결합니다.

 

이러한 이벤트 메시지에 대한 필터는 각 구독마다 별도로 구성할 수 있습니다.

 

 

 

 

위 흐름도는 이벤트를 수신하기 위해 OPC 클라이언트가 사용하는 오브젝트의 흐름도입니다.

 

OPC DA와 달리 값 읽기와 같은 특정 정보에 대한 명시적 요청은 없습니다(Read,Write같은 기능)

 

그러나 모든 프로세스 이벤트가 제공되고 클아이언트는 특정 필터 기준(이벤트 유형별, 우선순위 별, 필터별)등을 설정하여 이벤트 수량을 제한할 수 있습니다.

 

 

 

 

4. OPC Historical Data Access

 

 

OPC Data Access가 지속적으로 변화하는 데이터에 실시간으로 액세스 할 수있는 경우 OPC Historical Data Access는 이미 저장된 데이터에 대한 액세스를 제공합니다. 간단한 직렬 데이터 로깅 시스템에서 복잡한 SCADA 시스템에 이르기까지 기록 아카이브를 균일 한 방식으로 검색 할 수 있습니다.

 

OPC 클라이언트는 HDA 서버에서 OPCHDAServer 오브젝트를 작성하여 연결합니다.

이 오브젝트는 히스토리 데이터를 읽고 업데이트하기위한 모든 인터페이스와 메소드를 제공합니다. HDA 서버의 주소 공간을 찾아보기 위해 두 번째 개체 OPCHDABrowser가 정의됩니다.

 

주로 세 가지 방법으로 기록 데이터를 읽을 수 있습니다.

 

첫 번째 메커니즘은 아카이브에서 원시 데이터를 읽습니다. 여기서 클라이언트는 하나 이상의 변수와 읽을 시간 도메인을 정의합니다. 서버는 지정된 시간 범위 동안 아카이브 된 모든 값을 클라이언트가 정의한 최대 값 수까지 리턴합니다.

 

두 번째 메커니즘은 지정된 타임 스탬프에 대한 하나 이상의 변수 값을 읽습니다.

 

세 번째 읽기 메커니즘은 하나 이상의 변수에 대해 지정된 시간 도메인에 대한 히스토리 데이터베이스의 데이터에서 집계 값을 계산합니다. 값에는 항상 관련 품질 및 타임 스탬프가 포함됩니다.

 

읽기 방법 외에도 OPC HDA는 기록 데이터베이스에서 데이터를 삽입, 교체 및 삭제하는 방법도 정의합니다.

 

 

 

5. 클래식 OPC 인터페이스 표준

 

 

 

6. OPC XML-DA

 

OPC XML-DA는 COM / DCOM을 HTTP / SOAP 및 웹 서비스 기술로 대체한 최초의 플랫폼 독립적 인 OPC 사양입니다. 따라서 공급 업체와 플랫폼 중립적 통신 인프라가 도입되었으며 OPC Data Access의 기능이 널리 유지되었습니다.

 

일반적인 웹 서비스는 상태가 없기 때문에 기능을 통신 컨텍스트를 작성하고 수정하기위한 방법없이 OPC 데이터 액세스 정보를 교환하는 최소 방법 세트로 축소했습니다. OPC 데이터 액세스의 주요 기능을 다루는 데는 7 가지 방법만 필요했습니다.

 

7 가지 서비스는 다음과 같습니다.

 

   1.     서버 상태를 확인하기위한 GetStatus

   2.     하나 이상의 항목 값을 읽으려면 읽습니다.

   3.     하나 이상의 항목 값을 쓰려면 쓰기

   4.     사용 가능한 항목에 대한 정보를 얻으려면 속성 찾아보기 및 가져 오기

   5.     항목 목록에 대한 구독을 작성하려면 구독하십시오.

   6.     구독의 변경된 값을 교환하기 위해 SubscriptionPolledRefresh

   7.     구독을 삭제하려면 구독을 취소하십시오.

 

 

 

7. 클래식 OPC에서 OPC UA로 발전하게 된 이유?

 

주로 클래식 OPC는 하드웨어 공급 업체가 제공하는 하나의 정의된 소프트 인터페이스를 사용하여, 여러 공급업체의 장치와 다른 유형의 자동화 하드웨어에서 데이터에 엑세스하는 HMI 및 SCADA 시스템에 사용되었습니다.

 

OPC AE, OPC HDA와 같은 표준도 SCADA 시스템에서 제공하는 정보에서 액세스 할 수 있도록 설계되었습니다.

 

수천 개의 제품에 클래식 OPC가 성공적으로 적용되면서 여러 레벨에 있는 자동화 시스템 간의 표준화된 인터페이스로 사용되기 시작했습니다.

 

하지만, OPC와 같은 표준을 사용하려고 했지만 OPC의 COM 종속성 또는 DCOM을 사용하는 원격 액세스에 대한 문제 때문에 사용할 수 없는 제품들이 더 많아지기 시작했습니다.

 

OPC UA는 기능이나 성능을 잃지 않으면서 기존의 모든 COM 기반 사양을 실질적으로 대체하기 위해서 탄생되었습니다. 또한 복잡한 시스템을 설명하면서 확장 가능한 모델링 기능을 갖추고, 플랫폼에서 독립적인 시스템 인터페이스에 대한 요구 사항을 모두 맞춰야 하는 제약 조건을 충족했어야 했고, SCADA 및 DCS의 임베디드 시스템에서 MES 및 ERP 시스템까지 확장될 수 있는 확장성도 충족했어야 했습니다.

 

가장 중요한 요구사항은

 

 

와 같고, 분산 시스템 간 통신의 대한 부분과 모델링 데이터에 대한 부분 2가지로 나눠볼 수 있습니다.

 

 

 

분산 시스템 간 통신 =>

 

클래식 OPC는 장치 드라이버 인터페이스로 설계되었습니다. OPC는 오늘날 시스템 인터페이스로 사용됩니다. 따라서 분산 시스템 간 통신의 신뢰성이 매우 중요합니다. 네트워크 통신은 정의상 신뢰할 수 없으므로 고 가용성을위한 중복성을 포함하여 견고성 및 내결함성이 중요한 요구 사항입니다. 다양한 플랫폼에서 실행되는 시스템에 OPC 인터페이스를 직접 통합하려면 플랫폼 독립성과 확장 성이 필요합니다. 독점적 인 통신을 대체하기 위해서는 인트라넷 환경에서 항상 고성능이 중요합니다. 또한 방화벽을 통한 인터넷 통신이 기본적으로 가능해야하므로 보안 및 액세스 제어가 또 다른 중요한 요구 사항이됩니다.

 

 

 

모델링 데이터 =>

 

데이터 모델링은 Classic OPC에서 매우 제한적이며 모든 OPC 데이터에 대해 공통의 객체 지향 모델을 제공하여 향상시켜야했습니다. 이 모델에는 메타 정보를 제공하고 복잡한 시스템을 설명 할 수있는 확장 가능한 유형 시스템이 포함되어야합니다. 서버가 제공하고 설명하고 클라이언트가 호출 할 수있는 방법은 OPC를 유연하고 확장 가능하게 만드는 데 필요한 강력한 기능입니다. 복잡한 데이터 구조의 설명 및 일관된 전송을 지원하려면 복잡한 데이터가 필요합니다. 모델링 기능을 향상시키는 것이 중요한 요구 사항 이었지만 간단한 개념으로 간단한 모델을 지원하는 것도 마찬가지로 중요했습니다. 이러한 이유로 단순 모델에서 복잡한 모델로 확장 할 수 있으려면 단순하고 추상적이지만 확장 가능한 기본 모델이 필요합니다

 

 

 

 

8. OPC UA Overview

 

 

 

OPC 통합 아키텍쳐의 기본 구성 요소는 전송 메커니즘과 데이터 모델링입니다.

 

여기서 Transport는 서로 다른 사용 사례에 최적화된 서로 다른 메커니즘을 정의합니다.

 

TCP UA Binary는 고성능 인트라넷 통신을 위해 최적화되어 집니다.

 

Web Services는 방화벽에 친화적인 인터넷 통신을 위해 XML 및 HTTP와 같은 허용된 인터넷 표준에 대한 매핑을 정의합니다.

 

이 두 전송 모두 웹 서비스에서 알려진 동일한 메시지 기반 보안 모델(base-Message Secure Model)을 사용합니다.

 

데이터 모델링은 OPC UA로 정보 모델을 노출하는 데 필요한 규칙 및 기본 빌딩 블록을 정의합니다. 또한 유형 계층 구조를 작성하는 데 사용되는 기본 공간 및 주소 공간에 대한 진입점(Entry Point)을 정의합니다.

 

이 기반은 추상적 모델링 개념을 바탕으로 구축 된 정보 모델에 의해 확장 될 수 있습니다.

 

UA Services는 정보 모델의 공급자인 서버와 해당 정보 모델의 소비자인 클라이언트 간의 인터페이스입니다. 서비스는 추상적인 방식으로 정의됩니다. 클라이언트와 서버간에 데이터를 교환하기 위해 전송 메커니즘을 사용하고 있습니다.

 

이러한 OPC UA의 기본 개념을 통해 OPC UA 클라이언트는 복잡한 시스템에 의해 노출된 전체 모델을 이해할 필요없이 직접적으로 가장 작은 데이터에 액세스 할 수 있습니다.

 

또한 특정 모델을 이해하는 OPC UA 클라이언트는 특수 도메인 및 사용 사례에 대해 정의 된 더욱 향상된 기능을 사용할 수 있습니다.

 

 

 

Classic OPC에서 알려진 모든 성공적인 기능을 처리하기 위해 프로세스 정보 도메인에 대한 정보 모델은 기본 사양(Base specifications) 위에 OPC UA에 의해 정의됩니다.

 

DA는 아날로그 또는 이산 데이터 모델링 및 서비스 품질 노출 바업과 같은 자동화 데이터별 확장을 정의합니다.

 

경보 및 조건(AC)은 공정 경보 관리 및 상태 모니터링을 위한 고급 모델을 지원합니다.

 

히스토리 엑세스(HA)는 히스토리 데이터 및 히스토리 이벤트에 액세스하는 메커니즘을 정의합니다.

 

프로그램(Prog)은 프로그램을 시작, 조작 및 모니터링하는 메커니즘을 지정합니다.

 

Specifications of information models of other organisations은 UA 기반 또는 OPC Information Model 위에 Model을 새로 구축하여 OPC UA를 통해 특정 정보를 노출할 수 있습니다.

 

추가적인 vendor-specific information Model은 UA Base와 OPC Model 또는 다른 OPC-UA 기반 Information Model을 직접적으로 사용하여 정의되어질 수 있습니다.

 

 

 

 

9. OPC UA 소프트웨어 계층

 

 

자신의 정보를 다른 응용 프로그램에 공개하려는 응용 프로그램을 UA 서버라고하며 다른 응용 프로그램의 정보를 사용하려는 응용 프로그램을 UA 클라이언트라고 합니다.

 

일반적인 OPC UA 애플리케이션은 다음 그림에 표시된 세 가지 소프트웨어 계층으로 구성됩니다. 완전한 소프트웨어 스택은 C / C ++, .NET 또는 JAVA로 구현할 수 있습니다.

 

 

 

 

OPC UA 응용 프로그램은 OPC UA를 통해 데이터를 노출하거나 소비하려는 시스템입니다. 여기에는 OPC UA 스택 및 OPC UA SDK (Software Development Kit)를 사용하여 응용 프로그램에 대한 특정 기능과 이 기능을 OPC UA에 매핑하는 기능이 포함되어 있습니다.

 

UA 스택이 통신 채널만 구현하므로 OPC UA 클라이언트 또는 서버 SDK가 응용 프로그램 계층의 일부인 공통(Common) OPC UA 기능을 구현해야 합니다.

 

OPC UA SDK는 개발 노력을 줄이고 OPC UA 응용 프로그램의 빠른 상호 운용성을 촉진합니다.

 

 

 

위 그림은 UA의 통신 스택 계층입니다.

 

이 스택은 프로세스 또는 네트워크 경계에서 UA 서비스를 호출하는 데 사용됩니다. OPC UA는 3 개의 스택 레이어와 각 레이어마다 다른 프로파일을 정의합니다.

 

메시지 인코딩 계층(Message Serializaion)은 서비스 매개 변수의 직렬화를 2 진 및 XML 형식으로 정의합니다.

메시지 보안 계층(Message Security)은 웹 서비스 보안 표준 또는 UA 이진 버전의 웹 서비스 표준을 사용하여 메시지를 보호하는 방법을 지정합니다.

메시지 전송 계층(Message Transport)은 사용되는 네트워크 프로토콜을 정의합니다.

 

웹 프로토콜은 UA TCP 또는 HTTP 및 SOAP 일 수 있습니다.