3.3 OPC 표준(정의 및 장점)

OPC는 프로세스 제어 분야인 DCS, SCADA, PLC 시스템에서 아주 적절하게 사용될 수 있다. 마이크로 소프트의 기본적인 OLE 기술을 기반으로 Client와 Server사이에서 통신과 데이터의 변환을 하기 위한 산업표준 메커니즘을 제공하고 있다.

 

제조실행시스템

3.3.1 OPC란

OPC 사양의 개발 노력은 WinSEM으로 잘 알려진 마이크로소프트 인더스트리 포커스 그룹으로부터 시작되었다. 이 그룹은 마이크로소프트 테크놀로지를 사용하는 제품들을 개발하는 데에 공통의 관심사를 가지고 있는 다양한 회사들로 구성된 그룹이다.
 

OPC 표준의 출현

초기에 5개의 회사가 프로세스 컨트롤 산업에 기여하기 위해 오픈 스탠더드의 초기 개발에 이니셔티브를 갖기로 결정했다. 처음에는 비교적 짧은 시간 내에 작고 제한적인 초기 버전을 개발하기 위해 프로세스의 값을 읽고 쓰는 기능으로 제한했고, 알람처리, 프로세스 이벤트, 배치구조, 그리고 히스토리컬 데이터 액세스 등은 모두 이 표준의 후속 버전에 포함되었다. 
 
비영리 조직인 OPC Foundation(TM)은 OPC 사양의 첫 번째 릴리즈부터 초기 릴리즈에서 미루어온 부분들에 대한 표준 확장 작업을 계속해오고 있다. 지금까지 클라이언트 애플리케이션 벤더들은 각각의 컨트롤 장비들에 대한 서로 다른 인터페이스 드라이버들을 개발해야만 했다. 
 

OPC 표준의 장점

OPC 표준은 프로세스 컨트롤 장비로부터 데이터를 액세스 하기 위해 단지 하나의 인터페이스 드라이버를 개발하면 되는 대단히 큰 장점을 클라이언트 애플리케이션 벤더들에게 제공한다. OPC의 출현 이전까지는 컨트롤 장비 벤더가 그 장비의 인터페이스 방식을 수정하면 클라이언트 벤더 또한 이에 따라 클라이언트 드라이버를 수정해야만 했다.
 
그러나 OPC 이후에는 OPC 인터페이스 이하 서로 다른 여러 종류의 시스템들에 대한 상세한 기술적인 사양에 대해 클라이언트 소프트웨어를 독립시켜 준다. 따라서 장비 벤더는 클라이언트 소프트웨어에 영향을 주지 않고 OPC Server Interface 환경하에서 여러 가지 기능들을 수정/변경할 수 있다.
 
이로 인하여 클라이언트 벤더들은 각종 장비들에 대한 인터페이스 드라이버의 라이브러리를 유지/보수 및 업그레이드하기 위해 기울였던 지금까지의 노력 대신에 그들 자신의 제품 개발에 더 많은 자원을 투입함으로써 실질적으로 부가가치가 높은 부분에 자원을 활용할 수가 있다.
 
OPC 이전에는 특정한 컨트롤 장비를 위해 아주 제한적이거나 특정 소프트웨어만이 그 장비와 인터페이스 할 수 있기 때문에 사용자는 클라이언트 소프트웨어의 선택 권한이 극히 제한되는 경우가 종종 있었다. OPC의 경우에는 어떠한 OPC 호환 클라이언트 애플리케이션이든 OPC 호환 서버를 적용한 컨트롤 장비에 쉽게 인터페이스 한다. 
 
따라서 사용자는 자신의 특정한 목적에 가장 알맞은 솔루션을 선택하고 사용할 수 있다. 또 다른 이점으로 저비용의 통합과 낮은 위험부담을 들 수 있다. 여러 벤더들로부터 플러그 앤 플레이 기기들이 공급됨으로써 시스템 통합자는 각각의 기기에 따른 인터페이스 드라이버를 개발할 필요 없이 최종적인 통합 목적에 더 많은 시간을 투입할 수 있게 된다.
 
이 솔루션이 각 기기별 인터페이스 드라이버의 요구 없이 표준 OPC컴포넌트에 기반을 둠으로써 사용자의 위험을 한층 더 낮출 수 있게 된다.

---

3.3.2 OPC 통신의 장점

OPC가 프로세스 제어 분야에서 강점인 이유는 OPC를 사용하는 각 애플리케이션들이 하단의 컨트롤 장비로부터 직접 태그를 이용하여 액세스 하고 수많은 다른 태그들을 각각 다른 시간, 다른 환경에서도 액세스 할 수 있다는 점이다.
 

OPC 표준의 2가지 인터페이스 정의

OPC 표준은 애플리케이션을 위한 2가지의 인터페이스를 정의하고 있다. 하나는 큰 볼륨과 대단위 정보처리량을 요구하는 C++로 개발된 애플리케이션들을 위해 사용된다. 다른 하나의 인터페이스는 데이터의 액세스를 쉽게 하기 위해 Visual Basic과 VBA용으로 사용되도록 디자인되었다.
 
이것은 OPC 서버로부터 데이터를 액세스 하기 위해 별도의 프로그램 지식을 요구하지 않기 때문에 비주얼 베이직 또는 엑셀 및 워드에서 사용되는 매크로에 익숙한 엔지니어들은 이 인터페이스를 통하여 쉽게 액세스 할 수 있다.

 

클라이언트 애플리케이션을 개발하는 예

OPC OLE Automation Interface를 통해 Visual Basic으로 클라이언트 애플리케이션을 개발하는 간단한 예를 살펴보자. OPC Server 오브젝트는 애플리케이션과 가장 먼저 연결되는 COM 오브젝트로 OPC Group의 관리와 제어, 물리적인 디바이스의 액세스를 최적화하는 기능을 담당하고, OPC Group 오프젝트는 애플리케이션들이 태그 리스트를 확보하거나 속성을 부여하기 위해 다이내믹하게 Item을 생성하는 계층이다. 
 
OPC Group에서는 애플리케이션이 필요로 하는 데이터를 보다 간편하게 구성할 수 있는 방법을 제공하는데, 각 Group은 각기 다른 Refresh Rate를 가지고 Polling 혹은 Advising 방식을 모두 지원한다. 마지막으로 OPC Item은 물리적인 디바이스의 값에 의한 연결포인트를 제공한다.
 
또한 클라이언트들에게 값이나 양, 질, 시간, 데이터 타입 등과 같은 정보를 전달하는데 이 Item은 서버와 실제 데이터 사이의 연결을 위해 생성된다. 만약 이러한 OPC 표준 포맷에 맞추어 OPC 클라이언트뿐만 아니라 OPC 서버를 직접 개발하고자 할 경우는 OPC Development Toolkit 등을 이용하여 보다 빠르고 쉽게 개발할 수 있다.
 
OCP 서버의 가격이 HMI 가격에 비해 10% 정도밖에 차지하지 않으므로 자칫하면 그 중요성을 간과하기 쉽다. 대부분의 서버 프로그램은 외관상 비슷한 형태로 제공되므로 제품 간 차별성을 느끼지 못하는 경우가 허다하다. 주위에서 아무리 좋은 기능의 HMI를 선택했다 할지라도 잘못된 OPC 서버를 선정함으로써 낭패를 보는 프로젝트를 가끔 볼 수 있다.
 
왜냐하면 제대로 작동되지 않는 서버로 인해 HMI에서 스크립트와 같은 별도의 최적화 작업이 필요하게 되어 불필요한 성능 손실 및 불안정한 동작을 야기할 수 있기 때문이다. 어떤 프로젝트의 경우에는 많은 양의 상태 읽기 통신 부하로 인해 HMI에서 수행된 명령이 5~6초 이후에야 연결된 기기에 전달되어 작동되는 어처구니없는 성능 곤란을 겪는 경우도 있다.
 
따라서 최적화된 성능, 다양한 데이터 타입 지원 및 부가기능 지원여부, 엔지니어링의 편리성, 폭넓은 제품지원, 지술지원의 전문성 등을 따져보고 구입해야 한다. 물론 OPC 표준 제품이므로 여러 회사에서 개별적으로 구입하여 사용하여도 무방하나, 제품별로 성능 차이가 조금씩 발생하므로 가급적이면 그 성능이 검증된 제품을 구입하는 것이 필요하다.