이더넷이 제조 및 프로세스 제어의 통합에 적극 활용되고 있다. 그러나 광범위한 서로 다른 애플리케이션들 각각이 서로 통신할 수 없다면 이더넷도 전혀 도움이 되지 않았을 것이다. 소프트웨어 인터페이스의 공통점을 달성하려는 새로운 접근방법이 개발되기 전까지는 그러했다. 그 새로운 접근 방법은 자주 충돌하는 인터페이스, 커뮤니케이션 프로토콜, 데이터 교환방식을 표준화된 방식으로 다루는 것이다. 그 방법이 바로 OPC(OLE for Process Control)이며 이것이 산업분야에서의 기술지형을 완전히 바꾸어 놓았다. < 편집자 주>
자동화 기술은 많은 양의 데이터를 만들어낸다. 이는 전형적으로 기온, 조류, 기압 같은 물리적 변수나 또는 유닛의 수, 에러정보 같은 다른 생산 데이터를 말한다. 이 데이터도 컨트롤러, 계측 디바이스, 계량기, 스캐너와 같은 다양한 소스로부터 나오는데, 이 데이터들은 대량 계산되어 지거나 다양한 종류의 소프트웨어 애플리케이션에 저장된다. 이중 일부는 데이터베이스에 저장되거나 표 계산에 직접 사용되기도 한다. HMI(Human Machine Interface)를 위한 비주얼 소프트웨어에 직접 사용되는 경우도 있다. 결국 엄청나게 많은 다른 자료들과 기기들, 제조사와 애플리케이션이 존재하는데 이들은 모두 한 공간 안에서 작동 해야만 하는 것이다.
OPC가 개발되기 전인 10년 전까지만 해도 I/O기기들이 연결되기 위해 필요한 애플리케이션에는 각각에 맞는 전용의 드라이버가 필요했다. 소프트웨어 애플리케이션 A와 컨트롤러 X를 연결하기 위해서는 드라이버가 있어야 했고 다른 애플리케이션 B를 위해서는 다른 드라이버가, 애플리케이션 C를 위해서는 또 다른 드라이버가 필요했다. 각각의 데이터 소스는 애플리케이션 A, B, C의 요청에 따라 여러 번 데이터를 공급해 주어야 했다. 그리고 당연히 다른 컨트롤러 Y에서도 같은 과정이 반복적으로 필요했다. 각각의 애플리케이션을 위한 각각의 드라이버 또한 요구되었다. 게다가 각기 다른 커뮤니케이션 프로토콜과 버스 시스템 때문에 드라이버의 수도 지속적으로 늘어날 수 밖에 없었다.
OPC이전: 중복되는 데이터 생산과 전송으로 프로그래밍이 비효율적일 수 밖에 없었다.
OPC이후: 데이터는 한 번만 생산되며 요청이 있을때마다 활용된다.
OPC의 출현으로 이런 수고는 더 이상 필요 없게 되었다. OPC DA(OPC Data Access) 인터페이스는 다른 소프트웨어 애플리케이션들이 다양한 다른 데이터 소스에 접근할 수 있도록 단일화된 솔루션을 제공한다. 하드웨어 제조사들은 이제 하나의 드라이버(즉, OPC서버)만 개발하면 그것으로 해결된다. 소프트웨어 제조사들 또한 아주 적합한 소프트 소켓인 OPC 클라이언트 인터페이스만 공급하면 되게 되었다.
클라이언트 서버 아키텍처의 원리대로 클라이언트는 서버가 제공하는 서비스를 사용한다. OPC 서버는 하드웨어 프로세스 데이터에 접근하여 클라이언트가 필요로 하는 다른 시스템에도 적용할 수 있도록 만든다. OPC 클라이언트는 제공된 데이터를 사용하거나 OPC 서버에 명령 할 수 있는데, 그러면 서버는 컨트롤 데이터를 하드웨어로 전달한다. 보편적인 OPC 소프트 인터페이스를 통해 한 기기당 하나의 드라이버(OPC서버)만이 필요하다. 다른 많은 애플리케이션들은 이 서버에 접근하는 OPC 클라이언트들이다. OPC의 유용성으로 이제는 OPC 없는 자동화는 생각할 수 없게 되었다. 인터페이스는 거의 대부분 SCADA, HMI(비주얼), 프로세스 제어 시스템이 제공한다.
OPC Data Access
OPC는 원래 1996년에 인더스트리얼 오토메이션 인더스트리 테스크포스에 의해서 개발되었으며, 당시에는 개방형 표준 사용(Open Standards Specification)이라 불리었다. 이 표준사용은 컨트롤 디바이스와 서로 다른 제조사 드라이버간의 실시간 플랜트 데이터 통신을 위한 것이다. 최초의 릴리스 이후 OPC Foundation 조직이 구성되어 OPC 표준을 지속적으로 발전시켜 오늘날에 이르고 있다.
OPC Foundation에 따르면, OPC는 ‘개방형 표준을 통한 개방형 연결성’(open connectivity via open standards)이라 정의한다. 또한 OPC는 마이크로 소프트의 윈도우를 산업 현장에서 사용하고자 하는 세계적인 주요 산업 자동화 벤더들의 공동연구에 의해 탄생한 첫번째 표준으로 ‘표준 사양의 한 시리즈’(a series of standards specifications)라고도 정의된다.
OPC는 마이크로소프트(MS)가 개발한 컴포넌트 오브젝트 프로그래밍 모델인 OLE COM(공용 객체 모형)과 DCOM(분산된 컴포넌트 객체 모델)에 기반하고 있다. MS가 개발한 이 소프트웨어는 작고 독립적인 개체(구성요소)로 나뉘는데, 한 구성요소는 특정 활동을 수행할 수 있다. 예를 들면 특정 방식을 지원한다. 가능한 방식들은 외부에서는 볼 수 있지만 개체의 내부는 숨겨져 있다. 이런 이유로 개체들은 싸여있고 한 개 이상의 인터페이스들은 외부를 위해 정의되어 있다. 그 인터페이스에는 어떤 기능이 있고, 어떻게 사용할 수 있는지가 쓰여진 레서피가 있다. 기능들은 다른 기능들을 가리키는 일명 ‘가상 펑션 테이블(virtual function table)’의 도움을 받아 전달된다. OPC는 고정화된 애플리케이션에 의존하지 않는 표준화된 인터페이스를 제공하므로 애플리케이션으로의 연결을 간소화 하는 것인데, 이로 인해서 사용자들은 각기 다른 소프트웨어와 하드웨어 제조사에 얽매이지 않고 특정 사양 조건과 공급 여건에 따라 자신에게 적합한 제품을 자유롭게 선택하여 사용할 수 있다. OPC 서버와 클라이언트는 모두 공용 객체 모형(COM)의 개체들이다.
그렇기 때문에 누가 개발했는지, 언제 개발되었는지, 어떤 프로그램 언어를 사용했는지, 어떤 OS에서 개발되었는지가 전혀 문제 되지 않는다. 공용 객체 모형의 개체로서 다른 모든 것들과 통신이 가능하다.
DCOM(Distributed COM)과 함께 COM에 네트워크 성능이 추가되었다. 이는 같은 컴퓨터에서의 OPC 서버상의 서비스뿐 아니라 네트워크로 접근할 수 있는 모든 서버의 서비스를 사용할 수 있다는 것을 의미한다. 클라이언트는 로컬 서버나 원격 서버의 상태를 알 필요없이 필요에 따라 접속하여 활용하면 되는 것이다.
OPC를 통한 데이터 통신
처리과정을 비주얼화 하는 것은 현재 OPC의 주요 애플리케이션 분야가 되었다. 이것이 더 이상 놀랄만한 일이 아닌 것은 OPC가 본래 서로 다른 컨트롤러들간의 표준화된 접근을 필요로 했던 HMI 제조사들을 위해 탄생되었기 때문이다.
포인터나 COM의 객체 지향적 접근은 사용자로 하여금 이미 관계가 끝난 OPC 서버와 클라이언트간의 기본 연결성을 훨씬 능가할 수 있도록 해준다. COM 개체는 다양한 종류의 애플리케이션에서 실행될 수 있다.
만약 프로그램 언어가 C나 C++, Delphi, Net, VB6 같은 객체 지향, 또는 포인터 지향 프로그램이라면 현재 OPC 서버의 방법을 사용하는 각각의 클라이언트를 프로그램하는 것이 가능하다.
OPC 클라이언트는 커스텀 또는 오토메이션 인터페이스와 같은 한두 가지 타입의 인터페이스를 통해 OPC 서버에 접근하게 된다. 기능 지향형 언어인 C++이 주문형 인터페이스를 사용한다면 비주얼 베이직 같은 스크립트언어를 사용해서 자동화 인터페이스와 효과적으로 커뮤니케이션 할 수 있다. 각각의 클라이언트를 프로그래밍 하는 것의 장점은 당연히 애플리케이션이 각각의 요구조건에 맞춰질 수 있다는 것이다. 예를 들어 버튼 하나로 PLC의 데이터를 교환할 수 있는 레시피 편집기가 개발되었다면 사용자에게 힘을 실어주는 OPC 프로그래밍의 좋은 예가 된다.
OPC 프로그래밍과 MS 엑셀
OPC를 프로그래밍하는 것은 생각보다 쉽다. 각 솔루션 제공업체에서 다양하게 제공하는 OPC 프로그래밍 강의만으로도 충분하다. 이는 비싼 OPC 클라이언트가 특정 애플리케이션에 정말로 필요한가 라는 의문을 제기한다. 그렇다면 MS 엑셀을 OPC 클라이언트로 사용해보면 어떨까? MS오피스 애플리케이션의 객체 지향 프로그래밍 언어인 VBA(Visual Basic for Application)가 이를 가능하게 한다. 엑셀은 여러가지 좋은 방법으로 데이터를 표현한다. 막대형, 선형, 원형, 여러 그림이나 도표들이 상호관계나 추세, 경향 등을 명확하게 보여준다. 또한 수많은 제어요소들이 있다. 그것만으로 충분하지 않다면 더 많은 그래픽을 불러올 수도 있다.
이 광범위한 계산능력 때문에 엑셀은 특히 오픈 루프나 폐루프 컨트롤에 적합하다. 공식 형태라면 거의 어떤 형태라도 수행할 수 있다. 여기에 순환 데이터 통합, 보고서, 데이터 분석, 경향 등 많은 가능성이 있다.
결정적인 장점은 역시 거의 모든 사람들이 엑셀에 친숙하다는 것이다. 서비스 업종부터 영업사원이나 관리직까지 모든 사람들이 엑셀 사용법을 알기 때문에 새로운 사용법을 익히지 않아도 된다.
레시피는 예를 들면 기온이나 압력 같은 매개변수 처리 과정을 모아놓은 것이다. 레시피는 보통 앞으로 생산될 특정 제품이나 제품타입을 대표하는데, 준비된 레시피들은 데이터베이스에 저장되어 있다. 처리될 하드웨어 PLC는 풀다운 메뉴로 선택하고 데이터 전송은 버튼 하나로 시작된다. 실행되고 있는 프로그램은 언제라도 불러서 지정하고 데이터베이스에 저장할 수 있다.
레시피 편집기는 각기 다른 제조사의 컨트롤러로 작동해야 하는데 OPC 서버에 완벽하게 맞아 떨어지는 태스크라고 할 수 있다. 선택된 소프트웨어 디바이스에는 이미 입력리스트에 이더넷을 기반으로 한 산업 프로토콜이 들어있다. 지멘스의 프로토콜인 S7, S5는 물론이고, TCP/IP, HI와도 Modbus TCP를 통해 데이터를 교환할 수 있다. 이 이더넷 프로토콜은 Beckhoff, phoenix Contact, Schneider Electric, Wago 등의 여러 산업용 통신 인터페이스들과 아무런 문제없이 잘 맞는다. 뿐만 아니라 특별한 프로토콜을 사용하는 기기를 위해 시리얼 통신을 사용하여 데이터 통신이 가능하다.
데이터베이스의 컨트롤러에서만 레시피를 읽을 수 있는 것이 아니라 필요하면 그 반대도 – 예를들어 제품이 바뀌었을 경우- 가능하다. 데이터 전송은 버튼하나로 시작되고 레시피는 컨트롤러에 불러올 수 있다. 데이터 전송 전에는 테스트 비트가 스캔된다. 이 비트가 지정되는지 여부에 따라 데이터 전송이 허용되거나 제지된다.
아이씨엔 매거진 2007년 03월호
