질문으로 알아보는 스마트팩토리 - 'OPC UA' (하) 편

https://blog.naver.com/PostView.naver?blogId=suresofttech&logNo=221394471984 

질문으로 알아보는 스마트팩토리 - 'OPC UA' (하) 편

 

OPC UA에 대해 알아가는 마지막 시간입니다!

 

(상) 편까지는
OPC UA의 계층화된 아키텍처에
Client-Server, Pub-Sub 패러다임이 어떤 의도로 반영된 것인지까지 알아봤습니다.

 

(하) 편에서는
OPC UA의 특징을 질문과 답변 형태로 알아보는 시간을 가지겠습니다.
그리고 OPC UA를 통한 문제 해결 사례와 도입 사례를 끝으로
(상) 편의 도입부에서 보여드렸던 '1분으로 소개하는
OPC UA' 영상을 다시 보여드리면서 마치겠습니다.

 

(하) 편에서는 다음과 같은 OPC UA 관련 질문을 통해 답변하는 시간을 가지겠습니다.

 

1. OPC UA를 적용하게 되면 기업에서는 기존의 Classic OPC를 더 이상 사용할 수 없는 건가요?

2. 윈도우에 의존성이 높았던 부분들은 어떻게 해결이 됐나요?

3. 데이터와 정보 모델링 방식은 어떻게 변화 또는 강화됐나요?

4. 느리고 불안정하며 보안이 약했던 통신 및 네트워크 기능은 어떻게 강화됐나요?

5. OPC UA를 적용해서 Classic OPC가 가진 문제점을 해결한 사례들이 있다면 설명해주시겠어요?

6. OPC UA가 클라우드 서비스에 도입된 사례를 알 수 있을까요?

​

1. OPC UA를 적용하게 되면
기업에서는 기존의 Classic OPC를 더 이상 사용할 수 없는 건가요?

결론부터 말씀드리면 아닙니다!

OPC UA에는
Client-Server 패러다임이 적용됐다는 사실 저번 시간에 알려드렸죠?

 

기존 Classic OPC에는
DA(Data Access), AE(Alarm & Events), HDA(Historical Data Access) 서버가
각각 따로 존재했지만,

OPC UA에서는
특정한 단일 OPC UA 서버에서
DA, AE, HDA 등의 모든 스펙을 지원하도록 강화됐습니다!

 

당연히 하위 호환성을 위해서
기존 Classic OPC의 COM/DCOM 응용 프로그램에서도
OPC UA와 상호 간에 운용이 가능하도록 설계되었습니다.

​

COM Client가 UA Client로

DA, AE, HDA Server가 UA Server로 변화 및 강화된 것을
아래의 그림을 통해 확인하실 수 있어요.

 

 

 

 

2. 윈도우에 의존성이 높았던 부분들은 어떻게 해결이 됐나요?

높은 윈도우 의존성을 탈피하고자 OPC UA는
어떤 운영체제로도 포팅 될 수 있게 강화됐습니다.

애플의 MAC OS, Linux, VxWorks 등 다양한 운영체제를 지원합니다.

공식적으로 OPC UA는 C/C++, Java, .NET을 지원합니다.

아래의 그림을 통해 빠르게 이해하실 수 있습니다.

 

플랫폼 의존성만 낮춘 것은 아닙니다.
그렇게 가능하게 된 이유는
크로스 플랫폼 간에 통신이 가능한
표준 인터넷 프로토콜을 사용하기 때문인데요.​

아래의 그림과 같이
임베디드 시스템 또는 디바이스부터
제어기, 모바일, 태블릿, 데스크톱, 서버 클러스터 등
최대 엔터프라이즈 시스템 또는
클라우드 급으로 확장함에도 무리가 없도록 표준을 개정했습니다.

 

 

 

3. 데이터와 정보 모델링 방식은 어떻게 변화 또는 강화됐나요?

OPC 재단에서 New Generation OPC 개정을 위해
제조업 관련 기업들에게 요구 사항을 수집했다고 설명드린 부분이 기억나시나요?

다행히, OPC 재단은 해당 요구 사항을 거의 반영하여 OPC UA를 개정했습니다.

​

첫 번째로, 정보 접근을 위한 공통 아키텍처를 제공하여 시스템 통합 비용을 감소하도록 설계했습니다.

 

위 그림에서 가장 먼저 눈에 띄는 것은
객체 지향적으로 모델링이 가능하도록 해달라는
기업의 요구 사항을 반영했다는 점입니다.

그래서, 언제든 확장 가능한 타입 시스템을 가질 수 있게 됐고
메타 정보도 손쉽게 모델링 할 수 있으며
복잡한 데이터와 메소드 호출도 가능하게 해달라는
기업들의 요구 사항을 대부분 반영했습니다.

 

또, OPC UA를 적용한 제품은
OPC UA의 풍부한 정보 모델을 이용해
복잡한 시스템 표현이 가능해졌는데요.

 

UA 정보 모델을 통해 모델링 요소와 모델링 규칙 등을 정의할 수 있게 됐습니다.
복잡한 데이터 유형, 메소드, 상태 기계, 상속 등의 개념이
활용된 것을 아래 그림에서 확인하실 수 있습니다.

 

<그림 5> 복잡한 정보 모델링이 가능한 OPC UA (출처: Vision/Benefits/Introduction OPC UA - Randy Armstrong)

 

 

4. 느리고 불안정하며 보안이 약했던 통신 및 네트워크 기능은 어떻게 강화됐나요?

OPC UA에서는 네트워크 트래픽 보안도 신경을 많이 썼습니다.

 

​첫째로, 웹 표준을 따르는 보안 인증서로 통신 내역을 암호화할 수 있습니다.

둘째로, 응용프로그램 인증서를 통해 오직 허가받은 응용프로그램만 연결될 수 있도록 보장합니다.

셋째로, 허락된 사용자 계정만 접근할 수 있도록 보장합니다.

 

다음은, 통신의 안정성 부분에서 어떻게 강화됐는지 살펴보겠습니다.

 

OPC UA는 통신 손실을 막기 위해 강건하고 안정적인 통신을 보장하도록 개선됐습니다.

첫째로,
OPC UA 서버와 클라이언트 사이에서 서로가 살아있는지를 확인할 수 있는
Keep-Alive 모니터링이 가능해졌습니다.

둘째로,
서버와 클라이언트 사이에 있는 UA Session에서 데이터 버퍼링이 가능해졌습니다.
또, 세션을 통해 송신된 어떤 내용에 대한 확인 응답 메시지를 수신할 수 있게 됐습니다.

 

셋째로,
통신 에러가 발생할 경우 빠른 회복이 가능해졌습니다.
이중화 컨셉이 반영됐기 때문에 데이터가
불특정한 이유로 사라져도 회복이 가능해진 것입니다.

 

네트워크의 성능 면에서도 기존보다 강화됐음을 아래 그림을 통해 알 수 있습니다.

​

 

첫째로, 초 당 수 천 개의 point들을 전송할 수 있도록 개선됐습니다.
둘째로, Poll-Report-By-Exception 메커니즘이 전 대역폭 제어를 보장하도록 강화됐습니다.
셋째로, 사용자가 선택한 바이너리나 HTTP 같은 네트워크 프로토콜로
             응용 프로그램이 거의 모든 네트워크 토폴로지를 횡단할 수 있도록 보장하고 있습니다.

 

결국, OPC 재단에서 개정한 OPC UA는
기본적으로 공장 내의 수직적 통합이 그 목표 중 하나였습니다.
위에서 설명드린 것처럼,
네트워크 성능이 향상된 OPC UA를 활용함에 따라
다음과 같은 그림의 수직적 통합이 가능해졌어요.

 

상호운용성이라는 초점에서 이 글을 보고 계신 분들은 왼쪽 그림에서
Enterprise Network 부분을 보실 때,
여러분 뇌리 속에 떠오르는 용어가 하나 있어야 합니다.
제가 의도적으로 생략을 했는데요. 바로 '수평적 통합'이라는 용어입니다!

OPC UA는
단순히 단일 공장 내의 수직적 통합만을 목표로 하지 않았습니다.
스마트 팩토리 시대에는 상호운용성을 위해
공장을 초월하여 Enterprise 시스템 또는 클라우드 서비스까지
수평적 통합을 목표로 하고 있다는 점
상기시켜주시면 좋을 것 같습니다.

 

따라서,
저 Enterprise Network에 방화벽이라는 요소가 존재하는 것입니다.
공장 외부와 높은 보안성을 유지하면서
인증서 또는 사용자 계정 기반으로 통신해야 하기 때문이죠.

 

왼쪽 그림에 대한 설명을 추가적으로 해드리자면,
Operation Network는
오른쪽 피라미드 그림에서 ERP 그리고 MES가 위치하는 계층의 네트워크를 말합니다.

즉, 공장 내 요소들을 운영하기 위해
사용하는 애플리케이션들이 모여있어 연결된 네트워크를 뜻하죠.

 

Plant floor Network는 단일 공장 내에서
디바이스 등과 같이 실질적인 생산에 기여하는 현장에서 동작 중인 기기들이
연결된 네트워크를 뜻합니다.​

오른쪽 그림에서 MES 아래에 그려진 네트워크가 바로
Plant Floor Network입니다.

 

UA Server는
보통 정보 및 데이터들이 모델링 되어 있어서
상호운용성을 위해 자신을 서비스 형태로 제공하는 역할을 합니다.

 

사무실로 따지면,
층마다 공용으로 이용할 수 있는 프린터가
바로 UA Server 역할과 비슷하다고 생각하시면 이해하기가 쉬워요.

 

그래서 해당 UA Server의 서비스를 이용하기 원하는
UA Client들은 인증서나 사용자 계정 기반으로
보안 접근을 한 뒤, 원하는 서비스를 이용하거나
데이터를 사용하고 또는 이벤트를 수신할 수 있게 됩니다.

 

수평적 통합을 지향하기 때문에
공장 외부에서도 UA Client가 방화벽을 지나
마찬가지로 암호화된 인증서나 사용자 계정을 기반으로 해당 서비스를 이용할 수 있게 됩니다.

5. OPC UA를 적용해서 Classic OPC가 가진 문제점을 해결한 사례들이 있다면 설명해주시겠어요?

3가지 사례가 있습니다.

​

먼저, 첫 번째 해결 사례입니다.

위 그림에서 이슈는 무엇일까요?​

HMI에서 OPC 인터페이스를 사용하려면
반드시 윈도우 운영체제가 설치된 OPC COM Server가 있어야 했습니다.

그러나! OPC UA는 크로스 플랫폼이자 임베디드 장치도 지원하므로
인터페이스 하려는 디바이스 자체에서
서비스 제공이 가능하도록 문제를 해결했습니다.
다음과 같은이 말이죠.

 

두 번째 해결 사례입니다.

Classic OPC를 적용한 솔루션 형태는

자체디바이스 드라이버를 가지고 WinCE 기반에 OPC 서버(OEM 솔루션)가 있었으며
윈도우용 게이트웨이 PC가 있는 형태였습니다.

 

그러나! OPC UA를 도입하면~
디바이스 자체에 OPC UA Server를 적용하여
기존 Classic OPC Client와도 통신이 가능하게 하거나

OPC UA Client를 레거시 시스템에 새로 적용시켜 통신을 하게 할 수 있습니다.

 

그렇게 새롭게 OPC UA Server와 Client가 적용됐다면,
향상된 속도와 안정성 및 보안성 등으로 해당 서비스를 이용할 수 있게 됩니다.
또, 윈도우의 PnP처럼 상호운용성을 위해서
자기 자신을 서비스로 제공하는 OPC Server를 발견하여 이용할 수 있습니다.
마지막으로, UA type 시스템을 이용해서 추가적으로 빠른 엔지니어링이 가능합니다.

 

세 번째 해결 사례입니다.

Classic OPC를 사용하던 시절에는
서로 다른 벤더 사의 디바이스들 사이에서 통신하기가 매우 어려웠습니다.
가능하다고 해도, 시리얼 통신을 이용하거나 특정 TCP/IP 프로토콜을 사용해야 했었죠.

 

그러나! OPC UA를 도입하면~
디바이스들 모두에 적용된
OPC UA Server와 OPC UA Client를 통해 서로 통신할 수 있게 됩니다.

그리고 companion spec 들 중 하나인
PLCopen 표준을 OPC UA 위에 올려서 정보 모델링 할 수 있게 됩니다.

 

상 편에서 설명했듯이, OPC 재단에서는
어떻게 상호운용성을 확보할 수 있을지까지만 담당하고
What에 대한 부분은 모두 제조업 관련 도메인 전문가들에게 맡긴다는 점을
상기시키면 더욱 이해가 쉽습니다.

아래의 그림은 서로 다른 벤더 사의 디바이스들에 OPC UA가 적용된 모습입니다.

 

 

 

6. OPC UA가 클라우드 서비스에 도입된 사례를 알 수 있을까요?

Microsoft Azure라는 PaaS(Platform as a Service)에 적용된 OPC UA에 대해서 설명드리겠습니다.

 

         <그림 14> Azure에 적용된 OPC UA(출처: Microsoft-OPC UA-5-Clicks-To-Digital-Factory)

전체적으로는

OPC UA Server가 설치된 산업용 디바이스들에서

수집된 정보 및 데이터를 클라우드(OPC UA Client)에서 수집하여

그 자체를 모니터링하거나 데이터 분석 및 처리를 통해
기업 내에서 활용 가능하다는 아키텍처를 나타내고 있습니다.

① OPC UA에 반영된 Pub-Sub 패러다임을 이용해서
    원격 측정 채널이 열린 모습을 나타냅니다.
    OPC 노드의 데이터들이 직접적으로 Azure IoT Hub에
    JSON/AMQP 메시지 형태로 전송되는 그림입니다.

② 기존 OPC UA Server는 설계 상 무조건 UA-Binary 프로토콜을 지원합니다.
     Azure IoT Gateway SDK의 OPC UA 클라이언트 모듈은
    이러한 서버에 연결한 뒤 서버에서 이용 가능한 OPC 노드에 대해서 구독 요청을 한 다음
     JSON/AMQP 메시지와 호환되는 형태로 암호화된
    원격 측정 데이터를 Azure IoT Hub에 발행하게 됩니다.

 

③ 암호화된 UA-Binary 명령 및 제어 메시지와 응답 등이
    통신 패턴이 지원되는 Azure IoT Gateway SDK의 IoT Proxy 모듈을 통해 전송됩니다.
    이것은 방화벽이 공용 인터넷을 향해서는 닫히도록 합니다.
    게다가, 모든 트래픽은 암호화되고
    UA 인증 (X.509 인증서 및 보안 토큰 사용)이 사용됩니다.

 

④ 고객은 Azure라는 클라우드에서
     Industry 4.0 관련 서비스를 프로그래밍 할 수 있게 됩니다.
     ERP 서비스, 프로세스 최적화 서비스, 주문형 서비스 제조 등을
     클라우드 기반 OPC UA 참조 스택 및 SDK에 적용하거나
     단순히 시각화를 위해서라도 클라우드에서 OPC UA Client를 실행할 수 있습니다.

 

질문으로 알아보는 스마트팩토리 - 'OPC UA' (상)편에서 보여드린
'1분으로 소개하는 OPC UA' 영상 기억나시나요?

 

이번 OPC UA의 상, 하 편을 모두 읽고 난 뒤
이해의 정도가 얼마나 달라졌는지 확인해보면서 글을 마치겠습니다.

 

OPC UA에 대해서 더 궁금한 점이 있거나 문의사항이 있으신 분들은 슈어소프트테크로 연락 주세요!

 

What is OPC? UA in a Minute

What is OPC? UA in a Minute

www.youtube.com