판단 트리 방법을 사용한 ＯＰＣ 경보 및 이벤트 시스템의미들웨어 시스템 및 그 시스템의 판단 및 통지 방법 document_id A220623055812

OLE["올레" 또는 "오엘이"]는 복합문서 기술에 대한 마이크로소프트의 기반 기술이다. 마이크로소프트 ActiveX 기술의 일부인 OLE는 최초에는 DDE(dynamic data exchange)를 이용하였고, OLE 2.0 버전부터 DDE 대신 COM(component object model)과 그 분산판인 DCOM(distributed component object model)를 사용하였다. 하나의 OLE 객체는 필수적으로 하나의 컴포넌트 또는 COM 객체이다. 한편, OPC(OLE for Process Control 혹은 현재는 Openness, Productivity and Connectivity의 약칭으로 사용되고 있음)는 마이크로소프트사의 WinSEM 그룹(Windows for Science, Engineering and Manufacturing)으로 출발하여 OLE/COM 기술을 바탕으로 프로세스 데이터의 클라이언트 애플리케이션들과 서버(장비)들 사이의 인터페이스 방식을 규정한 것이다. OPC는 산업을 보조, 지원하기 위해 표준 명세 또는 표준 기술이며, 산업 자동화에서의 개방형 연결시스템(open connectivity)에 대한 것이다. 윈도우에 대해서 프린터 드라이버가 했었던 것과 같이, OPC는 산업 자동화에서 동일한 요구를 충족시켜주는 개방형 표준인 것이다. 다시 말해, OPC specification은 산업 자동화에서 모듈 소프트웨어 간의 상호 동작성(interoperability)을 위한 개방형이면서 유연한 플러그 앤 플레이 소프트웨어 표준을 제공하는 것을 목적으로 한다. 일반적인 컴퓨팅 시장의 기본적인 표준과 기술에 기초하여, OPC 재단(OPC Foundation)은 산업에서 요구하는 특정 니즈를 충족시키는 표준안을 제정하였다. OPC 재단은, 일련의 표준안을 발표했으며, 그 중 하나가 OPC 경보 및 이벤트 시스템에 대한 명세이다. OPC 경보 및 이벤트(OPC Alarms and Events) 시스템은 경보(alarm) 및 이벤트 통지(event notification)를 관리하는 인터페이스의 표준이다. PLC(Programmable Logic Control), DCS(Distributed Control System) 등과 같은 산업 시스템에서 감시 및 경보 시스템은 아주 중요한 역할을 담당한다. 이와 같은 감시 및 경보 시스템의 하나로서, OPC 시스템의 일부인 OPC 경보 및 이벤트(OPC A0026#E) 시스템은, 공장 내의 하드웨어 입출력(I/O) 장치로부터의 이벤트 및 경보를 구조화(structuring)하고, 감시(monitoring)하고, 제어(controlling)하며, 전송(transmitting)하고, ACK(acknowledging)하기 위한 클라이언트와 서버 프로그램 사이의 인터페이스를 규정한다. 이와 같은 종래의 OPC 경보 및 이벤트 시스템은, 프로세스 경보, 오퍼레이터 동작, 정보 메세지 및 메세지 트래킹/오디팅(tracking/auditing)에 대해서 요청시 경보 및 이벤트 통지를 제공하게 된다. 그러나, 종래의 OPC 경보 및 이벤트 시스템은 고 성능을 요구하는 감시 및 경보 시스템에서 비효율적이라는 문제점을 갖는다. 이와 같은 비효율성에 대해서 아래에서 좀 더 자세히 살펴보기로 한다. 종래의 OPC 경보 및 이벤트 시스템에서, OPC 서버의 역할은 정보를 제공하는 장치를 제어하며, 시스템에서 발생하는 경보 및 이벤트가 노출되도록 기록하며, 통지로서 클라이언트에 경보 및 이벤트를 보고한다. OPC 클라이언트는 물리적 장치로부터 데이터를 읽거나 물리적 장치에 데이터를 기록하기 위해서 OPC 서버와 통신한다. 여기서, OPC 경보 및 이벤트 시스템의 서버는 개별적인 구성요소로서 구현될 수도 있으며, 또는 OPC DA 서버(data access server)와 함께 구성요소 내에 구현될 수도 있다. OPC 경보 및 이벤트 시스템의 서버는 자동적으로 경보 및 이벤트를 포착하여, 이와 같은 정보에 관심이 있는 클라이언트가 경보 및 이벤트 정보를 이용할 수 있도록 제공한다. OPC 경보 및 이벤트 시스템에서, 경보(alarm)는 비정상적인 조건(abnormal condition)인 경우, 따라서 특별한 조건의 경우를 지칭하는 것이다. 조건은 OPC 서버의 상태이거나 OPC 클라이언트에게 관심의 대상이 되는 오브젝트 중 하나의 상태를 나타낸다. 예를 들어, 태그(tag) FC101은 해당 태그와 관련된 HighAlarm, Normal, 그리고 LowAlarm과 같은 조건(condition)들을 가질 수 있다. 한편, OPC 경보 및 이벤트 시스템에서, 이벤트(event)는 OPC 서버, 장치, OPC 클라이언트에게 중요성을 갖는 검출 가능한 사건의 발생(detectable occurrence)을 의미한다. 이벤트는 조건과 관련될 수도 있지만 관련되지 않을 수도 있다. 예를 들어, HighAlarm 조건이나 Normal 조건으로의 전이는 이벤트이며, 이 경우에는 조건과 관련된 경우이다. 하지만, 오퍼레이터의 동작, 시스템 구성상의 변화, 시스템 에러는 이벤트의 예시이지만, 이와 같은 예들은 특정 조건과 관련되지 않은 것이다. OPC 클라이언트는 특정 이벤트의 발생을 통지받을 수 있도록 통지 신청(subscription)할 수 있다. 통지는 서로 상이한 이벤트 형태에 대해 다양한 필수 속성(attribute)을 갖는다. 이벤트에는 Simple 이벤트, Tracking 관련 이벤트, 그리고 Condition 관련 이벤트로, 3가지 형태가 있다. 선택적인 속성들은 애플리케이션에서 정의될 수 있으며, 이 선택적인 속성은 특정 이벤트 카테고리에 대해서 유효하다. 클라이언트는 원하는 이벤트를 수집하고 통지받기 위한 통지 신청(subscription)을 위한 필터링 기준을 설정한다. 필터링 기준은, 이벤트를 특징짓는 정보와 eventarea 내의 이벤트의 위치를 기술하는 정보로 이루어진다. 클라이언트는 필터를 사용하기 전에, 필터 기준이 이용가능한지 문의하여야 한다. 서버는 event type, event category, severity, area 및 source와 같은 값들에 기초한 필터링을 지원한다. 단일 기준을 위한 값의 리스트는 논리적으로 모두 OR 관계이다. 다 기준(multi-criterion)이 특정된 경우, 이것들은 논리적으로 모두 AND 관계이다. 즉 모든 기준들을 만족시키는 이벤트가 선택될 것이다. 아래는 필터링의 예시이다. Type = CONDITION Category = PROCESS LowSeverity = 600 Area = AREA1, AREA2 도 1은 종래 OPC 경보 및 이벤트 시스템의 구조를 나타낸 도면이다. 도 1에 도시된 바와 같이, 이와 같은 종래의 OPC 경보 및 이벤트 시스템에서는 기본적으로 클라이언트(100)(도 1에서는 클라이언트가 1개인 경우 예시하였으나, 복수 개 존재하는 경우도 쉽게 예상할 수 있다)와 서버(200)를 포함하여 이루어진다. 종래의 OPC 경보 및 이벤트 시스템에서 서버(200)의 구조(architecture)는 OPCEventServer 오브젝트(210), OPCEvent-AreaBrowser 오브젝트(220), 그리고 OPCEventSubscription(230, 240, 250) 오브젝트로, 3가지의 오브젝트를 포함한다. OPCEventServer 오브젝트(210)는, OPC 클라이언트(110)가 다음과 같은 사항들을 가능하도록 인터페이스와 방법을 제공한다. 첫째로, OPC 서버(200)가 지원하는 이벤트의 형태인지를 OPC 클라이언트(110)가 판정하는 것을 가능하게 한다. 둘째로, 특정 이벤트에 대한 통지 신청을 입력하여서, OPC 클라이언트(110)가 그 사건 발생의 통지를 받을 수 있도록 하는 것이 가능하다. 원하는 이벤트의 부분 집합을 규정하기 위해서 필터가 사용될 수 있을 것이다. 셋째로, OPC 서버(200)에 의해 구현된 조건에 접속하고 조작하는 것이 가능하다. 또한, OPCEventServer 오브젝트(210)는 LocaleIDs의 관리와 에러 스트링(error string)의 검색과 같은 OPC 서버(200)의 공통적인 기능을 실행하기 위한 인터페이스와 방법을 제공한다. 또한, OPCEventServer 오브젝트(210)는 OPCEvent-Subscription(230, 240, 250)과 OPCEventAreaBrowser 오브젝트(220)를 생성하기 위한 인터페이스와 방법을 제공한다. 또한, OPCEventServer 오브젝트(210)는 벤더(vendor)에 적합하고 특정되어 있는 이벤트 카테고리와 이벤트 변수를 문의하고, 조건을 관리할 수 있도록 인터페이스와 방법을 제공한다. OPCEventServer 오브젝트(210)는 긴박하게 폐쇄되거나 중단된 클라이언트에 서버 통지용 콜백(callback)을 다룰 수 있도록 인터페이스와 방법을 제공한다. 한편, 선택적인 구성요소인, OPCEventAreaBrowser 오브젝트(220)는 eventarea를 검색하기 위해 사용된다. 또한 OPCEventSubscription 오브젝트(230, 240, 250)는 서버(200) 내의 이벤트 소스를 감시하고 발생되는 이벤트를 클라이언트(110)에 통지하기 위해서 사용된다. OPCEventSubscription 오브젝트(230, 240, 250)는 OPC 이벤트 보고를 위한 필터링과 다른 속성을 구성하기 위해서 사용된다. 또한, OPCEventSubscription 오브젝트(230, 240, 250)는 통지 신청을 위해 keep-alive 시간(keep-alive time)을 설정하거나 입수하는 것, 그리고 이벤트 통지를 위한 콜백을 다루기 위해서 사용된다. 경보에 관심이 있는 클라이언트(110)는 이벤트를 얻기 위해서 다음의 세 단계를 거쳐야 한다. 첫째로, OPC 서버(200)에 접속하여, 이용 가능한 기준을 문의하고, 통지 신청을 생성하여야 한다. 둘째로, 각각의 통지 신청을 위한 필터 기준을 얻거나 설정하여야 한다. 셋째로, 서버(200)는 콜백 접속을 통해서 이벤트를 클라이언트에 다시 보고한다. 이와 같은 종래의 OPC 경고 및 이벤트 시스템은 몇 가지 문제점을 안고 있다. 그 첫째로, OPC 경고 및 이벤트 시스템이 점점 더 많은 클라이언트와 데이터 리소스를 가지게 됨에 따라서, OPCEventSubscription 오브젝트(230, 240, 250)의 수가 아주 많아지게 되어 관리하는 것이 불가능하게 되는 문제점을 갖고 있었다. 둘째로, 매우 큰 시스템에서는, OPC 경고 및 이벤트 시스템이 클라이언트들에 아주 많은 통지를 전송하게 되어 네트워크 전송 장애가 발생하는 경우가 빈번하게 발생하였다. 셋째로, 시스템이 복잡해짐에 따라서, 클라이언트(100) 측의 사용자는 수많은 통지를 분석하고 처리하여야만 했다. 따라서, OPC 경고 및 이벤트 시스템은, 공장 자동화 내지 공장 시스템으로부터 불필요한 데이터 혹은 이벤트를 필터링 할 수 있는 스마트 서버(smart server)를 필요로 하게 되었다.