www.brl.pe.kr
|
|
OPC (OLE for Process Control) 규격은 프로세스 컨트롤 분야에서 사용자와 공급자 양쪽 모두에게 많은 혜택을 가져다 준다. OPC의 개요와 이점에 대하여 간략하게 소개한다.
소 개 OPC (OLE for Process Control)는 프로세스 컨트롤 분야에서 사용자와 공급자 양쪽 모두 에게 많은 혜택을 주는 새로운 산업 규격으 로 출현하였다. OPC는 각종 어플리케이션들이 여러 종류의 프로세스 컨트롤 장비 (DCS, PLC등)들로부터 데이터를 수수하는 것을 가능하게 하는 표준 인터페이스라고 정의 할 수 있다. 어플리케이션들은 각기 다른 여러 종류의 OPC호환 서버 (DCS, PLC등)들로부터 데이터를 수수하는데 단지 하나의 OPC 호환 드라이버만 설치하면 된다. OPC의 탄생 OPC 사양의 개발 노력은 WinSEM (Windows for Science, Engineering , and Manufacturing)으로 잘 알려진 마이크로소프트 인더스트리 포커스 그룹으로부터 시작되었다. 이 그룹은 마이크로소프트 테크놀로지를 사용하는 제품들을 개발하는데 있어 공통의 관심사를 가지고 있는 다양한 회사들로 구성된 공정한 그룹이다. 초기에 5개의 회사가 프로세스 컨트롤 산업에 기여하기 위하여 오픈 스탠다드의 초기 개발에 그 이니셔티브를 갖기로 결정했다. 이 그룹의 유지를 위하여 표준의 초기 릴리즈에 포함시킬 기능들에 대하여 작고 제한적으로 하면 비교적 짧은 시간 내에 초기 버젼의 표준을 개발할 수 있다고들 생각했다. 이것은 올바른 접근 방법이었음이 입증되었다. 프로세스 컨트롤 산업의 전문분야의 리더들을 투입하면서 이 표준은 시작 1 년내에 개발되었다. 이러한 OPC개발의 성공은 마이크로소프트가 마이크로소프트 테크놀로지가 포함되는 다른 표준 개발 파트들에도 이러한 방식을 제안하게 하였다. |
|
|
|
|
OPC표준은 프로세스 데이터의 클라이언트 어플케이션들과 서버들 사이의 인터페이스 방식을 규정한 것이다. 이 표준은 의도적으로 프로세스의 값을 읽고 쓰는것으로 제한 하였고. 알람 처리, 프로세스 이벤트, 배치 구조, 그리고 히스토리칼 데이터 액세스등은 모두 이 표준의 후속 릴리즈로 미루어 졌었다. OPC호환 클라이언트는 어떠한 종류의 OPC호환 서버들로 부터든지 데이터를 읽고 쓸 수가 있다. OPC는 마이크로소프트의 OLE/COM 표준에 그 기반을 두고 있다. OLE/COM은 다른 용도로 확장되어 사용될 수 있도록 마이크 로소프트에 의해 개발되었다. OLE/COM은 OPC가 완전히 새로운 테크놀로지를 창조 해내는 것이 아니라 기존의 테크놀로지 위 에서 개발이 가능하게 하여 주었다. OLE/COM은 이미 OLE를 적용하고 있는 어플리케이션에서 OPC서버 데이터를 요구하는 수많은 클라이언트들에게도 제공되어 있다. OPC는 서로 다른 벤더들에 의해 공급되는 클라이언트 어플리케이션과 서버 어플리케이션들 사이에 높은 수준의 상호 호환성 있 는 정보 처리를 제공한다. 이 개념을 설명 하기에 좋은 예로서 PC (Personal Computer) 버스 하드웨어 표준을 들 수 있다. OPC는 표준 PC 버스에 의하여 얻어지는 것과 유사한 호환성 방식을 제공한다. PC버스는 하드웨어 벤더들 모두가 같은 인터페이스 표 준을 사용하기 때문에 서로 다른 벤더들로 부터 공급되는 각종 하드웨어(그래픽 보드, 사운드보드, 모뎀카드등)들을 호환성 있게 수용한다. 같은 방식으로 OPC는 표준 인터페이스들을 통하여 각기 다른 벤더들로부터 제공되는 소프트웨어들을 호환성 있게 수용 할 수 있도록 하여 준다. 이 개념을 아래 그림-1에 표현하여 보았다.
[그림-1] Software Backplane OPC표준은 어플리케이션을 위한 두 가지의 인터페이스를 정의하고 있다. 하나의 인터페이스는 큰 볼륨과 대단위 정보 처리량을 요구하는 어플리케이션들을 위하여 개발 되었다. 이 인터페이스는 C++로 개발된 어플리케이션들에 의하여 사용된다. 다른 하나의 인터페이스는 데이터의 액세스를 쉽게 하기 위하여 제공되어진다. 이 인터페이스는 비쥬얼베이직(VB)과 어프리케이션 사용자들을 위한 비쥬얼베이직(VBA) 용으로 사용되어지도록 디자인되었다. 이것은 OPC 서버로부터 데이터를 액세스하기 위하여 요구되는 프로그램 지식의 벽을 낮추어 준다. 비쥬얼베이직, 또는 엑셀 및 워드에서 사용 되는 매크로에 익숙한 엔지니어들은 이 인터페이스를 통하여 쉽게 액세스 할 수 있다. 아래 그림-2에 이 두가지 인터페이스들을 보여주고 있다.
[그림-2] OPC OLE 인터페이스 OPC 표준은 관련된 고유 특성과 메소드들을 가진 여러가지 오브젝트들을 정의하고 있다. 이러한 오브젝트들은 표준적인 방법으로 프로세스 컨트롤 장비로부터 프로세스 데이터를 추출하기 위하여 사용되어진다. 모든 OPC서버는 이 모델을 사용하는 클라이언트들에게 데이터를 사용할 수 있도록 하여 준다. 가장 첫번째의 OPC 오브젝트는 OPC 서버 이다. 이 OPC서버는 클라이언트로부터 요청받은 데이터를 프로세스 컨트롤 장비로부터 수집할 의무가 있다. 각 서버는 OPC그룹을 가지고 있으며 데이터를 수집하는데 있어 논리적인 방식을 가지고 있다. 서버에 있는 그룹들을 많은 클라이언트들에 의해 공유되거나 하나의 클라이언트에 만 귀속될 것 이다. 서버들과 그룹들 간의 관계를 아래 그림-3에서 보여 주고 있다.
[그림-3] 서버와 그룹들 간의 관계 각각의 OPC그룹 오브젝트는 프로세스 컨트롤 장비로부터 검색된 값들을 포함하고 있는 OPC ITEM들을가지고 있다. ITEM들은 클라이언트에 의해 그룹들에 추가되어 진다. 예를 들어 어느 클라이언트는 모든 프로세스 온도 값들을 하나의 그룹으로 그룹짓고 자 할 것이다. 클라이언트는 값의 예외 범위가 변경되었는지 서버가 검색하는 주기를 정의하는 그룹의 갱신 주기를 서버에 정의 할 수 있다. 클라이언트는 또한 이 값이 클라이언트에 보고되어야 하는지를 결정하기 위하여 그룹에 있는 ITEM들을 위해 사용되는 예외 범위를 정의할 수 있다. 그룹과 ITEM들 간의 관계를 다음 그림-4에 나타 내었다.
[ 그림-4] 그룹과 ITEM들 사이의 관계 ITEM들은 프로세스 컨트롤 장비로부터 받은 실제 값을 가지고 있다. 클라이언트는 ITEM ID로 서버에 그 ITEM를 정의한다. ITEM ID는 서버 사양이다. 이것은 서버에게 값이 프로세스 컨트롤 장비 내에 위치를 지정하는 방법을 알려주는 유일한 것이다. 이것은 기존 DCS에서의 "FIC-123.PV"와 유사한 것이다. PLC에서는 레지스터 번호가 ITEM ID이다. ITEM들은 일반적으로 하나의 값을 리턴 한다. 서버는 옵션으로 값과 함께 타임스탬프와 품질 프래그를 리턴 한다. |
|
|
|
|
비영리 조직인 OPC Foundation(TM)은 OPC사 양의 첫번째 릴리즈에서부터 시작된 작업을 지속하기 위하여 구성되었다. 이 조직은 초기 릴리즈에서 미루어온 부분들(경보 처리, 이벤트 처리, 보안, 배치 구조, 그리고 히스 토리칼 데이터 액세스등)에 대한 표준 확장을 위해 공인되어 졌다. 이 조직의 멤버쉽은 이 표준에 관심을 갖고 있는 모든 조직과 개인에게 개방되어 있다. 회원들은 자신들의 전문 분야 또는 특정하게 관심을 가지고 있는 분과 위원회에 소속될 것이다. 서로 다른 시각에서의 표준 개발은 OPC규격을 신속하게 확장시킨 표준을 개발할 수 있는 견인차 역할을 하고 있다. |
|
|
|
|
지금까지 클라이언트 어플리케이션 벤더 (MMI 또는 HMI 벤더등)들은 각각의 컨트롤 장비들에 대한 서로 다른 인터페이스 드라이버들을 개발해야만 했다. OPC표준은 프로세스 컨트롤 장비로부터 데이터를 액세스하기 위하여 단지 하나 만의 인터페이스 드라이버를 개발하면 되는 대단히 큰 장점을 클라이언트 어플리케이션 벤더들에게 제공한다. 아래 그림-5에 이를 표현하였다.
[그림-5] OPC 前 과 後 OPC이전 까지는 컨트롤 장비 벤더가 그 장비의 인터페이스를 수정하면 클라이언트 벤더 또한 이에 따라 클라이언트의 드라이버를 수정하여야만 하였다. OPC는 OPC인터페이스 이하 서로 다른 여러 종류의 시스템들에 대한 상세한 기술적인 사양에 대하여 클라이언트 소프트웨어를 독립시켜 준다. 장비 벤더는 클라이언트 소프트웨어에 영향을 주지 않고 OPC서버 인터페이스 하에서 여러가지 기능들을 수정/변경등을 할 수 있 다. 이로 인하여 이제 클라이언트 벤더들은 각종 장비들에 대한 인터페이스 드라이버들 의 라이브러리를 유지/보수 및 업그레이드 하기 위하여 기울였던 지금까지의 노력 대신에 그들 자신의 제품 개발에 더 많은 자원을 투입하므로서 실질적으로 부가가치가 높은 부분에 자원을 활용할 수가 있다. |
|
|
|
|
최종 사용자의 이점 중 하나는 사용자의 필요에 가장 적합한 클라이언트 어플리케이션을 선택할 수 있도록 하여 준다는 것이다. OPC이전에는 특정한 컨트롤 장비을 위해 아주 제한적이거나 특정한 소프트웨어 만이 그 장비와 인터페이스를 할 수 있기 때문에 사용자는 클라이언트 소프트웨어의 선택 권한이 박탈당하거나 극히 제한되는 경우가 종종 있었다. OPC의 경우에 있어서는 어떠한 OPC 호환 클라이언트 어플리케이션이든 지 간에 OPC 호환 서버를 적용한 컨트롤 장비에 쉽게 인터페이스 한다. 따라서 사용자는 자신의 특정한 목적에 가장 알맞은 솔루션을 선택하고 사용할 수 있다. 다른 이점으로는 저 비용의 통합 (INTEGRATION) 과 낮은 위험 부담을 들 수 있다. 여러 벤더들로부터 플러그 앤드 플레이 (Plug & Play) 기기들이 공급됨으로서 시스템 통합자 (SI: System Integrator)는 각각 의 기기에 따른 인터페이스 드라이버를 개발할 필요없이 최종적인 통합 목적에 더 많은 시간을 투입할 수가 있게 된다.이 솔루션이 각 기기별 인터페이스 드라이버의 요구없이 표준 OPC 콤퍼넌트들에 기반을 둠 으로서 사용자의 프로젝트 리스크를 한층 더 낮출 수 있게 된다. |
|
|
|
|
- 1999.10.16.일 현재
|
|
|
