질문으로 알아보는 스마트팩토리 - 'OPC UA' (하) 편
OPC UA에 대해 알아가는 마지막 시간입니다! (상) 편까지는 OPC UA의 계층화된 아키텍처에 Clie...
blog.naver.com
본 게시글에서 다룰 내용은 OPC UA입니다.
본론으로 가기 전에, 도움이 될만한 기초 지식을 짚고 넘어가 볼까요?
스마트 팩토리 분야에서 상호운용성 통합 모델이 무엇을 목표로 하는가?
- 수평적 모델과 수직적 모델을 동시에 통합함에 따라 발생되는
안전성, 보안 등에 대한 통합을 목표로 합니다.
스마트 팩토리 도입 효과를 종합적으로 정리한 내용 중에서
'연결'과 관련된 내용에는 어떤 것들이 있는가?
- 개별 공장의 설비와 공정이 지능화되고 서로 연결됩니다.
- 상, 하위 공장들과 서로 연결됩니다.
- 공장 내 모든 생산 정보 지식이 실시간으로 공유되고 활용됩니다.
스마트 팩토리 분야 주요 제품과 기술 분류 내용 중
애플리케이션, 플랫폼, 디바이스 각각의 이슈는 어떤 것들이 있는가?
[애플리케이션]
제조 관련 애플리케이션을 만드는 업체마다 자사의 솔루션의 영향을 늘리기 위해
각자 독립된 플랫폼만을 제공하기 때문에 수평적, 수직적 연계성이 매우 낮습니다.
[플랫폼]
산업용 제조 디바이스 업체들이 쉽게 접근할 수 있는 Industry IoT 그리고 빅데이터와 같은
플랫폼 전문 기업들의 제조업 지원 솔루션 개발이 필요합니다.
[디바이스]
상호운용성 극대화를 위해 이기종 디바이스 간의 연결이 필요합니다.
솔루션에서 규칙 등을 제공받아 제조기기에 반영하는 스마트 디바이스가 필요합니다.
[종합]
다품종 생산체계 하에서 이기종 디바이스들을 상호 운용하기 위한 통합 운용 솔루션의 중요성이 부각되고 있습니다.
자동화 디바이스의 통합 제어를 위해 개방형 플랫폼, 이기종 시스템 통합 운영을 위한 MTConnectTM 인터페이스 등과
같은 SW 개발이 가속화되고 있습니다.
혹시, 여기서 어떤 내용이 강조됐는지 의도를 파악하셨나요?
질문을 통해서 여러분께 강조하고 싶었던 내용은
공장을 초월한 '상호운용성'과 '연결'이라는 내용인데요.
좀 더 나은 스마트 팩토리 구축을 위해서는
제조 자동화 시절, 공장 내에서 독립적으로 동작했던
애플리케이션, 플랫폼, 디바이스 등이
서로 쉽게 연결 가능하고 상호 간에 운용되어야 한다는 것입니다.
즉, 임원진과 실무진이 힘을 합쳐
공장 내 특정 요소들(FactoryThing) 간에 '상호운용성'이 보장될 수 있도록
반드시 고민하고 개선해야 스마트 팩토리 도입 효과를 얻을 수 있다는 것이죠!
다행히도,
이처럼 고민하고 전 세계 다양한 공장의 운영 환경들을 접하며
'상호운용성'을 개선해 나가고 있는 재단이 있는데요.
바로 그 재단이 OPC Foundation이라는 곳입니다.
스마트 팩토리 구축을 위해서
반드시 고민해야 하는 부분이라고 설명드리니깐 조금 실감이 나시나요?
바로 그런 재단에서 만든 표준이 'OPC UA'라는 것입니다.
이번 질문으로 알아보는 스마트팩토리 - 'OPC UA' 편에서는,
여러분들께 상편과 하편으로 나눠서 설명드리고자 합니다.
자, 그럼 이제 OPC 재단에서 만든 '1분으로 소개하는 OPC UA' 영상으로 시작해볼까요?
여러분들이 상, 하편으로 나뉜 이 게시글을 모두 읽고 난 이후,
위에 있는 영상의 내용을 대부분 이해하게 돕는 것이 저희의 목표입니다.
상편에서는 먼저 다음과 같은 OPC UA 관련 질문을 통해 답변하는 시간을 가져보도록 하겠습니다.
1. OPC UA를 도입해야 하는 이유는 뭔가요?
2. 그렇다면, OPC 재단이 출범한 계기는 무엇인가요?
3. 동영상에 IIoT라는 용어가 나오는데, IIoT가 뭐죠?
4. 3차 산업혁명 당시 제조 자동화 시절과 4차 산업혁명의 스마트 팩토리 시대에서 통신 분야 요구 사항이 어떻게 달라지고 있나요?
5. Industry 4.0 시대로 변화함에 따라, OPC 재단이 인식한 상호운용성의 문제점은 뭔가요?
6. New Generation OPC를 위한 요구 사항은 무엇인가요?
7. OPC UA, 어디부터 이해하면 좋을까요?
8. OPC UA에 Client-Server와 Pub-Sub 패러다임이 반영됐다고 들었는데요. 이게 어떤 의미인가요?
첫 질문부터 차근차근 답변드리도록 하겠습니다.
1. OPC UA를 도입해야 하는 이유는 뭔가요?
OPC UA가
본질적으로 어떤 문제를 해결하려고 하는지를 설명드리면 이해가 빠르실 것 같습니다.
공장 내부에서뿐만 아니라,공장을 초월하여
디바이스부터 엔터프라이즈급 애플리케이션 또는 클라우드까지의
상호운용성을 확보하기 위함입니다.
각각의 디바이스, 애플리케이션, 플랫폼 등에서
OPC UA라는 표준을 채택하여 적용하면
서로 간에 상호운용성이 확보됩니다.
결국, OPC UA 표준을 채택한
디바이스, 애플리케이션, 플랫폼 등은
서로를 서비스 형태로 쉽게 발견하고
상호 간에 제공하는 서비스를 쉽게 이용할 수 있게 됩니다.
즉, OPC UA는
스마트 팩토리 환경에서 상호운용성을 위한 열쇠 역할을 합니다.
OPC UA가 적용된 디바이스, 애플리케이션, 플랫폼 등을
이용하는 제조 업체에서는 아래 그림과 같이
가장 하위의 디바이스부터 최상단 애플리케이션까지
상호운용성이 확보됩니다.
그렇다면, 상호운용성이 확보된다는 것은 무슨 의미일까요?
상호운용성이 확보된다는 것은
상호 간에 통신이 가능해지고
정확한 정보 교환이 일어나게 되며
정확한 일련의 처리들이 가능해진다는 것입니다.
즉, OPC UA라는 표준을 통해서
MES와 ERP라는 애플리케이션이
가장 하단에서 동작 중인
디바이스 또는 설비들을 서비스 형태로 발견 가능하게 되고
그 서비들을 자유롭게 이용하고 활용할 수 있으며
그 반대의 경우도 가능하다는 것입니다.
결국, 공장 내부뿐만 아니라 공장을 초월하여
제조기업 내의 상호운용성을 확보하기 위해서는 OPC UA라는 표준 도입이 필수적입니다.
2. 그렇다면, OPC 재단이 출범한 계기는 무엇인가요?
OPC 재단이 처음으로 창설된 시점은 1995년입니다.
이 시기는 마이크로소프트 운영체제인 'Windows 95'가 막 붐을 일으키던 시절이었습니다.
특히, 이목이 집중되었던 특징 중에 하나는
PnP(Plug and Play, 플러그 앤 플레이)라는 기능인데요.
이 기능 덕분에 특정 사용자가
본인의 컴퓨터에 특정 하드웨어를 연결하면
별도의 사용자 조작이나 프로그램 설치 없이
바로 해당하는 하드웨어를 사용할 수 있게 되었습니다.
OPC 재단이 출범하게 된 계기 그리고 사명이 바로 여기에서 출발했습니다.
"어떻게 하면 윈도우 Plug&Play처럼 공장 내의 각 요소들을 쉽게 연결할 수 있을까?"
OPC 재단은 자동화 분야에서
SCADA 및 HMI 시스템을 자동화 기기에 연결하는 등
공정 제어용으로 제정된 Classic OPC를 계속해서 배포하다가
2003년부터 OPC UA(New Generation OPC)를
2006년까지 정의하게 됩니다.
그리고 약 2년 동안
정의된 OPC UA를 검증 및 구현한 뒤
2008년 드디어 OPC UA 1.0을 배포하게 됩니다.
그 이후
2010년도부터 지금까지
IEC 62541이라는 명칭으로 OPC UA 표준 확산에 힘을 쓰고 있습니다.
출범 이후 약 24년 넘게
'산업 자동화를 위한 상호운용성 표준 제정'에 힘쓰고 있는 조직입니다.
3. 동영상을 보니깐 IIoT라는 용어가 나오던데, IIoT가 어떤 거죠?
사물인터넷이라는 단어 많이 들어보셨죠?
Internet of Things라는 단어의 줄임말로써,IoT라고 부르며
각종 사물에 센서와 통신 기능을 내장하여 인터넷에 연결하는 기술을 의미합니다.
IIoT는 Industrial IoT의 줄임말로써 산업용 사물인터넷을 말합니다.
즉, 같은 기술인데 산업용에 특화된 사물인터넷 기술을 의미합니다.
아래의 그림과 같이 사물인터넷과 Industry 4.0의 공통분모에 들어가는 부분이라고
이해하시면 훨씬 더 쉽게 이해되실 거라고 생각합니다.
4. 3차 산업혁명 당시 제조 자동화 시절과 4차 산업혁명의 스마트 팩토리 시대에서
통신 분야 요구 사항이 어떻게 달라지고 있나요?
아주 좋은 질문입니다!
표준 채택만으로는 궁극적인 상호운용성 확보가 어렵습니다.
스마트 팩토리 시대에 요구되는 통신 스펙이 달라지고 있어요.
- Sensor와 Actuator는 기존에 물리적으로 연결했었지만,
지금은 통신으로 연결이 되고 있으며 그러한 요구 사항이 늘어나고 있습니다.
- 통신 프로토콜은 제조 자동화 시절에 대표적으로 Fieldbus를 비롯한 다양한 종류의 표준을 사용했었으나,
현재는 표준 Ethernet과 더불어 단일 표준을 사용하는 추세로 전환되고 있습니다.
- 통신의 특성을 살펴보면, 제조 자동화 시절은
Enterprise 시스템(또는 애플리케이션)과 분리됐었고
제한된 노드와 통신했었으며 제한된 보안 수준만 제공했습니다.
그러나, 현재는 Enterprise 시스템과의 통합이 이루어지고 있고
연결될 노드의 개수가 무제한이며
보안이 강화됐고 유, 무선 모두 통합되는 추세입니다.
- 데이터 활용 면을 살펴보면,
제조 자동화 시절에는 제한적으로 수집하고 분석했었으나,
현재는 무제한에 가까운 데이터들을 수집하고 분석하며
이를 위해 빅데이터라는 학문적 지식과 기술을 요구합니다.
- 제어 시스템은 제조 자동화 시절에는 컨트롤러(제어기) 중심이었으나
현재는 IT와 융합하여 제어하는 추세이며 특히,
사물인터넷을 통한 제어가 점점 더 활발해지고 있습니다.
표로 간단히 정리하면, 다음과 같습니다.
5. Industry 4.0 시대로 변화함에 따라,
OPC 재단이 인식한 상호운용성의 문제점은 뭔가요?
사실, 2003년부터 OPC UA를 정의하기 위해
'New Generation OPC'의 요구 사항을
제조업 관련 기업으로부터 수집하기 전까지,
OPC 재단은 윈도우 운용체제에 종속적인
'Classic OPC'라는 표준을 만들어 배포하고 있었습니다.
'상호운용성'의 정의를 다시 떠올려볼까요?
OPC 재단이 출범할 당시 그들이 미션으로 생각한
진정한 의미의 상호운용성을 확보하려면,
애플리케이션이나 플랫폼이 동작하는
컴퓨터의 운영체제에 종속적이거나
디바이스(설비) 제조사에 의존적이면 안 되는 상황이었습니다.
바로 아래의 그림이 OPC 재단이 인식한 상호운용성의 문제점을 잘 나타내고 있습니다.
또, 상호운용성이라는 목적을 달성하기 위해서
OPC 재단은 기존에 정의했던 다음과 같은 Classic OPC의 문제점도
개선이 필요하다고 느꼈습니다.
Classic OPC의 문제점은 다음과 같습니다.
첫 번째 윈도우 운영체제에 종속적이다.
두 번째 보안이 취약하며 성능적인 면에서 버려야 할 기능들을 포함하고 있다.
세 번째 데이터 접근, 데이터 접근 히스토리, 알람 및 이벤트 등 분리된 아키텍처를 가지고 있다.
아래의 그림에는 Classic OPC의 문제점 중 분리된 아키텍처와 윈도우 종속성에 관련된 부분이 나타나 있습니다.
6. New Generation OPC를 위한 요구 사항으로 어떤 것들이 있었나요?
여기서 말하는 New Generation OPC는 현재의 OPC UA를 말합니다.
운영체제에 의존적이지 않고
설비 제조사에 의존적이지 않은
상호운용성 확보를 위한 표준을 만들기 위해
OPC 재단은
제조 분야의 다양한 기업으로부터
새로운 요구 사항을 수집하게 됩니다.
많은 기업들이 요구한 사항들을 한마디로 표현하면
'Service Oriented Architecture(SOA)'입니다.
즉, 공장 내 사물(설비, 디바이스)들이
서비스로서 제공되어야 한다는 내용이었습니다.
Things as a Service(TaaS),
Machine as a Service(MaaS),
Device as a Service(DaaS) 같은 개념을 요구했던 것이죠.
OPC 재단이 기업들의 요구 사항들을 정리하다 보니
다음과 같은 도표로 요구 사항이 정리되었다고 합니다.
공장 내뿐만 아니라 공장 외적으로도
다양한 애플리케이션들이 서로 커뮤니케이션하는 경우가 많았습니다.
이를 위해서는
네트워크 인프라에 너무 의존적이지 않은
성능 이슈가 해결되어야 했고
인터넷 방화벽을 통해 보안이 강화된 접근 및 제어를 해야 했습니다.
중복성의 또 다른 표현은 '이중화'입니다.
통신 중 사라지거나 저장된 데이터들의 신속한 복구 등을 위해
이중화 개념이 반드시 적용돼야 했죠.
당연히 그렇게 되려면
견고한 장애도 신속하게 회복시킬 수 있어야 했습니다.
확장적인 측면에서는 계층적으로 볼 때
최하위 디바이스(임베디드 장치)부터
SCADA를 거쳐 MES, ERP 등과 같은 애플리케이션까지
모두 서비스 형태로 이용할 수 있어야 했습니다.
디바이스부터 애플리케이션까지
서로가 상호운용성이 확보되려면
서비스 형태로 서로가 서로를 이용할 수 있어야 한다는 점 기억하고 계시죠?
그러기 위해서는 반드시
그 서비스의 내용들이 데이터 모델링이 되어야 하는데요.
그러기 위해서는 디바이스부터 애플리케이션까지
자기가 제공하는 서비스에 대해서
데이터, 메소드, 이벤트 등을 쉽게 정의할 수 있어야 했습니다.
결국, Classic OPC 대비 OPC UA의 개선사항은 다음의 그림과 같이 정리할 수 있겠습니다.
7. OPC UA, 어디부터 이해하면 좋을까요?
OPC UA의 토대부터 살펴보실까요?
그림에서 가장 먼저 봐야 하는 부분은 OPC UA의 근간을 이루는
두 기둥 Transport, OPC UA Meta Model입니다.
왼쪽 Transport 부분부터 살펴보겠습니다.
상호운용성을 위해서는 전송과 관련된 이슈들을 1차적으로 해결해야 했습니다.
웹 서비스 개념을 차용해 플랫폼 독립성 이슈를 해결했고
TCP를 사용하여 인터넷 방화벽을 통한 보안 접근 및 제어가 가능하도록 했습니다.
오른쪽 OPC UA Meta Model에서는,
상호운용성을 위해 서로에게 서비스 형태로 제공되어야 하는 부분들을
모델링 하는 기본 규칙과 제약사항에 대해서 정의했습니다.
두 기둥 위에 있는 부분들은 아래의 그림을 보면서 좀 더 설명드리겠습니다.
OPC UA Information Medel
계층화된 아키텍처에서 'DA, AC, HA, Prog'라고 그려진 부분이 보이시나요?
이 부분이 바로 New Generation OPC를 재정하기 위해서 받았던
많은 기업들의 요구 사항 중
모든 OPC 데이터를 위한 공통 모델을 제공하는 부분입니다.
OPC UA를 적용한 디바이스 또는 애플리케이션 등이
자기 데이터를 정보로 모델링 할 수 있도록 지원하는 부분입니다.
DA는
Data Access의 약자로 아날로그 또는 이산 데이터의 모델링과 같이
특정 자동화 데이터의 확장성과 관련된 부분들을 정의합니다.
AC는
Alarm & Conditions의 약자로
공정 알람 관리 및 조건 모니터링을 위한 고급 모델을 명시합니다.
HA는
Historical Access의 약자로 시간 순서대로 데이터와 이벤트 등에
접근 가능하도록 하는 메커니즘을 정의합니다.
Prog는
Programs의 약자로 프로그램 실행 등과 관련된 부분들을 시작하고 조작하며
모니터링할 수 있는 메커니즘을 명시합니다.
Specifications of Information Models of other Organizations
Specifications of Information Models of other Organizations에 해당하는 부분을 설명드리겠습니다.
그대로 직역하면 '다른 기관(조직)의 정보 모델 명세'인데요.
이게 무슨 말일까요?
화살표 옆에 뭐라고 적혀있는 거 보이시죠?
IEC, EDDL, FDT, PLCopen 등등.
New Generation OPC를 위한 요구 사항 중에
관련 있던 게 무엇이었는지 다시 상기시켜야 할 것 같습니다.
데이터 모델링 관련 요구 사항 중에서
'다른 표준 데이터 모델을 위한 토대'와 관련된 부분을 해결한 곳이
바로 Specifications of Information Models of other Organizations입니다.
즉, OPC 재단은
다른 표준 또는 제조업 도메인 전문가들과의
Collaboration(공동 작업)을 위한 아키텍처를 위해 고심했었는데요.
그 결과 끝에 도출된 부분이 바로 저 부분입니다.
'DA, AC, HA, Prog'를 다른 표현으로 'Built-in Information Models'라고 하는데요.
OPC 재단에서는 계층화된 아키텍처에서 여기까지가 자신들의 역할이라고 생각했습니다.
아래의 그림을 보시면 이해가 더 빠르실 것 같습니다.
OPC UA 메타 모델과 'DA, AC, HA, Prog'를 통해
어떻게 상호운용성을 확보할 것인가는 OPC UA가 책임지고,
그 위에 무엇을 정의하느냐는
제조업 도메인 전문가 또는 다른 표준 재정 단체에 맡긴다는 뜻입니다.
당연히 그렇게 WHAT을 정의한 부분 위에는 Vendor에 특화된 확장이 가능하게 됩니다.
조금 특이한 점으로는 계층화된 아키텍처 그림을 자세히 살펴보시면,
Companion Information Models과 Vendor Specific Extensions가
OPC UA Metal Model과 바로 연결돼있는 모습을 확인하실 수 있는데요.
이것의 의미는
Built-in Information Models를 이용해서
상호운용성을 제공할지 말지는 옵션이라는 의미입니다.
굳이 Built-in Information Models을 사용하지 않아도
Companion Information Models과 Vendor Specific Extensions가 가능한 구조입니다.
8. OPC UA에 Client-Server와 Pub-Sub 패러다임이 반영됐다고 들었는데요.
이게 어떤 의미인가요?
Client-Server와 Pub-Sub 패러다임이 반영된 모습을 간단하게 표현한 그림부터 보겠습니다.
먼저, Client-Server 패러다임이 적용된 이유는
OPC UA를 채택한 디바이스 또는 애플리케이션이 서버 입장에서
API 형태로 상호운용성을 위한 서비스를 제공하기 위함입니다.
따라서, 그 서비스를 이용하고 싶은 클라이언트는
언제든지 해당하는 OPC UA 서버의 API를 호출하여
원하는 서비스 또는 정보를 이용할 수 있게 됩니다.
다음으로,
Pub-Sub 패러다임이 채택된 이유는
상호운용성을 위해서 서비스를 제공하는
디바이스 또는 애플리케이션이 언제든
Publisher 입장에서 자신의 서비스 상태나 이벤트 상태를 발행할 수 있도록 하기 위함입니다.
따라서, 그 서비스를 이용하는 Subscriber는
그 상태에 대한 값을 구독하여
자신이 현재 그 서비스를 이용할 수 있는지를 확인하고
이용할 수 없다면 언제쯤 이용이 가능한지 등을 파악할 수 있게 됩니다.
예를 들어, Pub-Sub 패러다임에서
자주 사용되는 MQTT라는 프로토콜은
발행자와 구독자 사이에 중재자를 둬서
토픽을 기반으로 정보나 데이터 등을 발행하고 구독할 수 있도록 돕습니다.
이처럼, 스마트 팩토리의 수직적, 수평적 통합을 위해
디바이스에서부터 애플리케이션까지 OPC UA 표준을 적용한다면,
위에서 설명된 패러다임을 활용해 상호운용성을 확보할 수 있게 됩니다.
'OPC UA' 카테고리의 다른 글
| 질문으로 알아보는 스마트팩토리 - 'OPC UA' (하) 편 (0) | 2022.08.27 |
|---|---|
| OPCUA 통신 쉽게 알기 - 1편 OPC 란 무엇인가 (0) | 2022.03.28 |