1. 서론

* 아주대학교 기계 및 산업공학부

모니터링 시스템이란 장비, 설비 혹은 시스템의 상태의 감시 및 이상발생 시 적절한 조치를 할 수 있는 체계를 말한다. 이러한 모니터링의 과정은 감시 대상으로부터의 데이터 수집, 저장, 분석 및 조치의 과정으로 표현할 수 있다.

제조 시스템들은 많은 장비와 설비들로 구성되므로 수집해야 할 데이터의 종류와 양이 다양하다. 따라서 모니터링을 효율적으로 수행하기 위하여는 컴퓨터를 기반으로 한 시스템의 사용이 필수적이다. 이러한 시스템들 중 현장에서 많이 사용되고 있는 것에는 DAS (Data Acquisition System), SCADA (Supervisory Control And Data Acquisition System), MAP (Manufacturing Automation Protocol)을 이용한 시스템들이 있다. 이들 시스템들은 모니터링 데이터들을 주기적으로 수집하여 이를 LAN을 통하거나 직·병렬 통신을 이용하여 관리용 컴퓨터에 전송하여, 저장, 분석 및 제어를 할 수 있는 구조를 가지고 있다.

그러나 DAS, SCADA, MAP등을 이용한 모니터링 시스템의 경우는 시스템간의 호환이 어려우며, 변화에 대한 유동적인 대처가 어렵다는 취약점을 가지고 있다. 또한 LAN이나 직·병렬 통신을 이용하여 데이터를 전송하기 때문에 시·공간적인 제약을 갖는다.

본 연구에서는 이와 같은 문제점을 보완하기 위하여 인터넷 기반의 모니터링 시스템 및 제어 시스템을 개발 하고자 한다. 본 시스템에서는 시·공간의 문제를 해결하기 위하여 웹 기술과 네트웍 관리의 표준 프로토콜인 SNMP (Simple Network Management Protocol) [6][9][11]를 채용한다. 웹 기술은  TCP/IP 네트웍이 연결된 곳이라면 어느 곳에서나 접속할 수 있으며, 클라이언트의 관리를 하지 않아도 된다는 장점을 가지고 있다.

기존의 장비나 설비들은 기본적으로 네트웍을 지원하지 못하기 때문에, 이 문제를 해결하기 위하여 네트웍을 지원하고 SNMP 에이전트를 탑재한 Add-on카드를 설비에 부착하여 설비의 모니터링 및 제어를 할 수 있게 한다.

본 연구에서는 파일럿 시스템의 개발을 위하여 개발 대상이 되는 하드웨어를 구성하며, 모니터링 및 제어의 기본 정보인 MIB (Management Information Base) [9][11]를 정의하고, 이를 바탕으로 Add-on 카드에 들어갈 SNMP 에이전트와 에이전트를 관리하는 관리국을 개발한다. 관리국 쪽에는 모니터링 데이터를 통계적으로 분석 관리할 수 있는 SPC (Statistical Process Control) 도구들을 제공하며, 이들은 모두 웹 인터페이스를 통하여 관리되어지도록 한다.

본 연구에서는 또한 PLC, DAS, 컨트롤러에 대하여 SNMP 에이전트와의 인터페이스를 제안한다. 이렇게 표준적인 인터페이스를 제공하고 이를 각 업체에 제공하여 드라이버를 제작할 수 있게 하여주면 SNMP 에이전트 개발이 용이해 진다.

2. 시스템 기본구조

시스템의 기본 구조는 [그림 1]과 같이 모니터링 대상이 되는 설비, 이들의 상태를 가져오거나 컨트롤 할 수 있는 SNMP 에이전트가 탑재된 Add-on 카드와 관리국으로 구성되어 진다. SNMP 에이전트와 관리국은 MIB를 기준으로 하여 서로 정보를 주고받는데, 이 MIB에는 관리 하고자 하는 장비의 모니터링 및 컨트롤 파라메터가 정의되어 있다. 관리국에서는

[그림 1] 시스템의 기본구조

피 관리 대상의 정보를 MIB로부터 얻어낸 후 이를 SNMP를 통하여 에이전트에게 전달한다.    에이전트는 수신된 메시지를 분석하고, MIB로부터 관리국의 요구하는 정보를 알아내어 이를 관리국 쪽에 전송한다. 따라서 MIB는 관리국 쪽에는 피 관리 대상의 모든 MIB항목을 가지고 있어야 하나, 각 에이전트들은 자신과 관련된 MIB항목만을 가지고 있으면 된다.

관리자는 웹브라우저를 통하여 관리국에 접속하여 모니터링 데이터를 확인하거나 분석할 수 있다. 때에 따라서는 각 장비에 컨트롤 정보를 입력하여 장비들을 제어 할 수 있다.

SNMP는 TCP/IP기반의 표준 네트웍 관리 프로토콜로서 크게 Request와 Response로 나뉘어 진다. Request에는 다시 GET, SET로 나뉘어 진다. GET은 MIB에 정의된 파라메터의 값을 가져올 때,  SET은 값을 설정할 때 사용되어 진다. 장비의 컨트롤 시에는 이 SET 방법을 사용하여 장비에 컨트롤 정보를 넘겨주게 된다.

[그림 2] 시스템 구조

3. 시스템 상세 구조 설계

시스템의 구조는 [그림 2]에서처럼 설비, SNMP에이전트와 관리국으로 구성되어 진다. SNMP에이전트는 물리적으로는 설비와 연결되어 직·병렬 통신을 통하여 설비의 정보를 가져오거나 설정 정보를 전달한다. 관리국은 모니터링 데이터를 수집 및 저장, 분석하는 시스템과 이런 정보를 웹을 통하여 클라이언트에게 보여주는 장비관리시스템과 HTTP 서버로 구성된다.

관리국의 구성 요소인 MDGC (Monitoring Data Gathering and Control System)는 주기적으로 기본 설정 정보를 바탕으로 SNMP 에이전트로부터 모니터링 데이터를 가져와 이를 데이터 베이스화 하거나, HTTP를 통하여 요청된 모니터링 및 제어 정보를 받아 이를 SNMP로 변환한 다음 SNMP 에이전트에게 정보를 요청하여 해당 정보를 다시 넘겨주는 역할을 한다.

3.1 하드웨어 설계

[그림 2]에서 보듯이 이 시스템에서 하드웨어는 모니터링 대상 설비나 장비와 부착되는 Add-on 카드로 크게 양분된다.

1) Add-on 카드의 정의

현재까지 사용되어지는 대부분의 설비나 장비들은 외부와 정보 교환을 위해서 직·병렬 통신을 사용하였다. 따라서 인터넷 환경에서 기존의 장비들을 사용하기 위해서는 이들 설비에 TCP/IP통신을 할 수 있는 방법을 고려해야만 한다. 이러한 점을 해결하기 위해서 기존의 설비에 부착되어 이들의 통신 방법인 직·병렬 통신을 통하여 설비와 정보 교환을 하고 이를 다시 TCP/IP통신을 이용하여 인터넷을 통해 정보를 전달할 수 있는 기능을 가진 장치인 Add-on 카드를 사용하여야 한다. Add-on 카드에는 SNMP 에이전트가 탑재되며 이 에이전트가 관리국의 요청에 따라 모니터링 정보를 설비에서 가져오거나 제어 정보를 설비에 전달하는 역할을 한다.

2) Add-on 카드의 구성 및 기능

Add-on 카드에는 SNMP 에이전트가 탑재되므로 이를 운용할 수 있는 운영체제를 가지고 있어야 한다. 본 연구에서는 임베디드 리눅스를 사용한다. 또한 설비와 통신할 수 있는 직·병렬 통신 포트와 관리국과 통신할 수 있는 이더넷 포트를 가지고 있어야 한다.

Add-on 카드의 기능은 크게 SNMP 에이전트의 운용과 통신기능으로 대별되며 에이전트의 기능에 따라 Add-on카드의 실제적인 수행기능은 달리한다.

3) Add-on 카드의 동작방식

Add-on 카드의 동작방식은 SNMP 에이전트의 동작이라고 말 할 수 있다. 즉 에이전트의 동작방식에 따라 Add-on의 카드의 동작방식이 결정된다. 그러므로 여기서는 Add-on 카드 안에 있는 에이전트와 Add-on카드를 동일시하여 동작방식을 설명한다.

관리국에서는 대상 장비들에 대한 모니터링 및 제어 관련 정보를 가지고 있다. 모니터링의 경우에는 관리국에서 이들 정보를 바탕으로 주기적으로 SNMP 에이전트 즉 Add-on카드에 모니터링 정보를 요청한다. Add-on카드는 설비에서 직·병렬 통신을 통하여 해당 정보를 가져와서 이를 관리국 쪽에 전송한다. 제어의 경우에는 사용자로부터 제어 정보가 관리국 쪽에 전달되고 이 정보가 다시 Add-on카드 쪽으로 전송되어진다.

3.2 소프트웨어 설계

위와 같은 모니터링 시스템을 설계시에 소프트웨어로서 SNMP 에이전트와 관리국의 설계가 필요하다.

1) SNMP 에이전트

SNMP 에이전트는 Add-on카드 안에 탑재되는 소프트웨어로서 관리국에서 요청된 모니터링 및 제어 정보를 설비와 주고받으며 이를 관리국에 전송하는 기능을 담당한다. 뿐만 아니라 장비의 이상 발생 시에는 Trap 메시지를 해당 관리국 쪽에 전송하여 이상에 대한 적절한 조치를 취할 수 있게 하여준다.

SNMP 에이전트를 설계 요소에는 MIB, 하드웨어와의 인터페이스, Trap이 있다. 이들에 대해서 살펴보면 다음과 같다.

첫째, SNMP 에이전트는 각 설비의 모니터링 및 제어의 요소를 MIB의 형태로서 보관하고 관리한다. 따라서 에이전트를 개발하기 위해서는 MIB를 정의해 주어야 한다. 일반적으로 MIB의 private항목의 하위는 각 네트웍 장비의 업체들에게 할당되어 있다. 따라서 이 부분을 확장하여 MIB를 정의한다. 보다 구체적으로 보면 private 밑에 enterprise-machine(4)을 정의하고 그 하위에 여러 장비군 별로 나누어 정의한다.

둘째, 하드웨어와의 인터페이스를 살펴보면 개발 대상이 되는 설비들은 제조회사나 설비 종류별로 외부와 정보를 주고받는 규약 즉 프로토콜이 서로 상이한 경우가 대부분이다. 따라서 에이전트에서는 각 설비에 대해서 이런 프로토콜에 맞추어 개발해야 한다.

셋째, Trap은 앞서 설명한 바와 같이 장비의 이상 발생 시 관리국 쪽에 통보하는 기능이라고 말 할 수 있다. Trap을 처리하기 위해서는 관리국의 IP, Trap발생조건에 대한 설정이 필요하다. 그러나 이들 정보는 언제든지 변경이 필요한 요소들이다. 따라서 해당 정보를 쉽게 변경할 수 있는 방법이 필요하다. 이를 위해서 Add-on카드 안에는 SNMP 에이전트의 Trap 설정을 변경할 수 있는 소프트웨어가 같이 탑재된다. 이 소프트웨어는 웹서버와 에이전트의 Trap 관련 설정을 변경과 에이전트의 구동을 제어 할 수 있는 CGI(Common Gateway Interface)로 구성된다.

[표 1] SNMP 에이전트 관리 CGI의 기능

구 분	구성 정보 및 기능
Trap 관련	·관리국 IP ·Trap발생 항목 선택 및 발생 레벨 설정
SNMP 에이전트 관리	·에이전트의 프로그램 시작, 중지, 재시작

2) 관리국

관리국은 주기적 혹은 사용자의 요청에 따라 에이전트로부터 모니터링 정보를 가져와 이를 저장하거나 사용자에게 넘겨준다. 사용자는 관리국을 통하여 모니터링 데이터의 확인 및 분석을 행할 수 있다. 또한 사용자는 제어하고자 하는 장비에 대하여 관리국에 요청하면 관리국은 이 제어정보를 SNMP 에이전트에 전송하여 준다.

관리국은 기능적으로 크게 장비관리, 데이터 분석, 사용자관리로 나뉘어 질 수 있다. 각 기능별로 살펴보면 다음과 같다. 장비관리는 장비의 일반정보와 모니터링 및 제어 정보를 관리한다. 장비의 일반정보들에 대하여 정리하면 [표 2]와 같다. MDGC에서는 장비일반 정보를 바탕으로 해서 각 SNMP 에이전트에게서 해당 모니터링 정보를 받아와서 이를 데이터 베이스에 저장한다. 뿐만 아니라 사용자가 제어 명령을 내리면 이를 받아 다시 에이전트에게 해당 명령을 전달한다. MDGCs는 사용자와의 제어 정보를 사용자에게 받기 위하여 해당 제어 화면의 각 요소와 통신을 하게 된다. 이 때는 HTTP 프로토콜을 이용하지 않으므로 MDGCs와 사용자 컨트롤간의 통신할 수 있는 프로토콜이 필요하다. 이 프로토콜에 대하여 살펴보면 다음 [그림 3]과 같다.

모니터링 시스템에서의 장비관리는 사용자 그룹별로 기능을 다르게 제공하는 것이 일반적이다. [표 3]은 본 연구에서 구성한 장비관리 기능이다.

[표 2] 장비관련 정보

구 분	항 목
네 트 웍 관련정보	IP
	포트
장 비 일반정보	장비구분
	모델명
	관리 담당자
	비 고
모니터링 설정정보	모니터링 시간간격
	모니터링 시작여부
	커뮤니티 명
대 상 파라메터	모니터링, 제어 파라메터들(가변적)
	파라메터 이름
	파라메터 형태 {디지털, 아날로그}
	파라메터 타입 {integer, octet string, IpAddress, Counter, Gauge, TimeTicks, Opaque}
	용도구분 {모니터링용, 제어용}
	접근권한
	경고 상한 및 하한 값
	에러 상한 및 하한 값
	파라메터 설명

[그림 3] 제어 정보 교환 프로토콜

[표 3] 각 그룹별 수행기능

그 룹	기 능
관리자 그룹	① 사용자 관리 ② 장비일반정보 관리 ③ 모니터링 화면 구성 ④ 데이터 분석
사용자 그룹	① 개인 모니터링 화면 구성 ② 데이터 분석

모니터링 시스템에서는 수집된 데이터를 통계적인 방법들로 분석할 수 있는 기능을 제공하여 보다 근본적인 문제 발생을 대하여 예방 및 개선을 할 수 있게 하여야 한다. 통계적인 방법으로는 관리도, Cp / Cpk, 평균, 분산, 표준편차, 기계 이용률 등 SPC에서 일반적으로 필요로하는 지표들을 지원한다.

본 연구에서는 사용자 관리기능을 개발하였는데, 이 것은 사용자의 등록, 수정 및 삭제의 기능으로 구성된다. 사용자의 개념을 도입함으로써 사용자별의 화면의 개인화를 지원할 수 있다. 이를 위하여 본 연구에서는 모니터링 화면 위저드를 개발하였는데, 이는 각 화면을 각 단계별로 선택하면서 구성하는 방법, 모니터링 화면이미지를 가지고 각 장비의 정보에 매핑 해주는 방법, 기본 화면 템플릿을 제공하여 이를 바탕으로 화면을 구성하는 방법 등을 제공한다.

4. 파일럿 시스템의 구현

4.1 하드웨어 구성

앞에서는 SNMP를 이용하여 웹기반 모니터링 시스템을 구성하는 방법에 대하여 알아보았다. 본 연구에서는 이를 파일럿 시스템으로 개발하였다. 본 연구에서는 특히 모니터링 및 제어 시스템의 대상 장비로서 일반 업체에게 가장 많이 사용되는 PLC를 이용하였다.    SNMP 에이전트가 탑재될 Add-on 카드와 PLC는 직렬 케이블로 연결하였으며, PLC에는 모니터링용과 제어용으로 각각 광센서와 제어용 LED를 부착하였다. [그림 4]는 파일럿 시스템을 도식화 한 것이다.

PLC 에는 광센서의 입력에 따라 표시용 LED의 점멸을 하는 프로그램이 작동된다.   SNMP 에이전트로부터 제어용 LED의 점멸신호가 들어오면 PLC는 해당 LED를 점멸하는 작업을 수행한다.

[그림 4] 하드웨어 구성

4.2 SNMP 에이전트 및 MIB

파일럿 시스템은 PLC를 에이전트의 대상 하드웨어로 설계되었으므로 모니터링 및 제어 파라메터의 집합인 MIB는 [표 4]와 같이 구성하였다.

[표 4] MIB에 정의된 PLC관련 정보

MIB객체	MIB객체 ID	설 명
model	1.3.6.1.4.4.1.1	PLC의 모델명
cpu	1.3.6.1.4.4.1.2	CPU의 모델명
sensor1	1.3.6.1.4.4.1.3	광센서 입력
control1	1.3.6.1.4.4.1.4	컨트롤 변수1
control2	1.3.6.1.4.4.1.5	컨트롤 변수2

SNMP 에이전트는 PLC와 직렬통신을 통하여 관리정보를 주고받는다. 파일럿 시스템에서는 RS-232C통신을 사용한다. PLC와 통신절차를 보면 [그림 5] 과 같은 절차[4]로 이루어진다.

[그림 5] PLC와의 통신절차

4.3 관리국

관리국은 MDGC와 사용자의 인터페이스 부분인 장비관리, 데이터 분석, 사용자관리로 구분된다. MDGC는 윈도우 프로그램으로서 SNMP 에이전트 프로그램과는 ucd-snmp의 윈도우용 API (Application Program Interface)를 통하여 접속한다. 또한 사용자의 제어 정보를 받기 위해 서버로서 작동되며 소켓통신을 한다. 에이전트로부터 얻어진 데이터는 데이터 베이스에 저장된다. 나머지 인터페이스에 관련된 부분은 모두 웹을 통하여 이루어진다.

다음 [그림 6] 과 [그림 7] 은 파일럿 시스템을 이용하여 모니터링을 실시한 예를 보이고 있다.

[그림 6] 모니터링 화면

[그림 7] 모니터링 데이터의 관리도

5. 표준 인터페이스

5.1 인터페이스의 필요성

SNMP에이전트를 개발하기 위해서는 해당 설비의 관리 포인트를 설정하고 이를 MIB로 작성한 다음 다시 설비의 상태를 감시 및 제어할 수 있는 코드를 작성하여 에이전트에 이를 적용해야 한다. 그러나 일반적으로 같은 종류의 설비이더라도 제작회사별로 제어구조 및 프로토콜 등이 서로 상이한 경우가 많다. 따라서 아무리 SNMP 에이전트가 표준적인 사항이라고 할 지라도 에이전트를 제작하는 데에는 많은 어려움이 있다. 따라서 이를 해소할 방안이 필요로 한다.

만약, SNMP 에이전트 작성시 각 설비군별로 동일한 인터페이스를 지원한다면 에이전트의 개발이 훨씬 수월해질 것이다. 이의 예는 윈도우즈의 ODBC(Open Database Connectivity)를 보면 알 수 있다. 데이터 베이스의 제조 회사는 다양하며 그 제품의 종류도 많이 있다. 그러나 ODBC에서 데이터 베이스를 사용하는 표준 인터페이스를 지정하고 있으며, 각 데이터베이스 제조 업체에서는 이 표준 인터페이스에 맞추어서 자사의 데이터베이스를 조작할 수 있는 드라이버를 제작하여 제공한다. 따라서 일반 개발자는 ODBC의 인터페이스 부분만 알면 어떠한 데이터베이스를 사용할 수 있으며, 데이터베이스가 바뀌더라도 프로그램 수정을 하지 않아도 된다. 이와 동일한 이치로 각 설비군별로 표준적인 인터페이스가 존재하며, 각 장비 제조업체에서 이 인터페이스에 맞는 드라이버를 개발하여 주면 에이전트의 개발은 좀더 용이해 질 것이다. 따라서 장비의 표준적인 인터페이스를 제안하고자 한다.

5.2 인터페이스 구성

설비의 종류는 상당히 다양하고 많다. 그러나 일반적으로 이들은 컨트롤러에 의해서 제어되며 상태를 모니터링 한다. 컨트롤러 중에서 가장 대표적인 것은 PLC 이다. PLC의 입력과 출력이 존재하며 기본 동작은 입력의 신호에 따라 출력이 바뀌는 형태를 지닌다. 입력의 형태에 따른 출력의 조정은 내부 프로그램에 따라서 변한다. 특히 내부 로직 프로그램은 사용자에 의해서 변경할 수 있으므로 PLC를 이용하면 다양한 제어구조를 만들 수 있다.

PLC는 앞에서 보았듯이 입력과 출력점이 존재하고 각 입·출력점의 값을 읽거나 설정하므로써 제어할 수 있는 구조이다. 즉 각 입·출력점의 주소 지정을 할 수 있으며 그 값을 읽거나 설정할 수 있으면 된다. 또한 이들은 직렬 통신을 바탕으로 정보를 교환한다. 이를 바탕으로 인터페이스를 만들면 [표 5] 와 같다.

[표 5]에서 정의된 PLC인터페이스는 일반적인 컨트롤러에서도 적용될 수 있다. 물론 정의된 인터페이스만으로 모든 컨트롤러에 적용하기는 어려울 것이다. 그러나 컨트롤러 역시 대상 장비나 설비에 제어 정보나 모니터링 정보를 가져오는 역할을 하므로 기본적인 모든 동작은 위의 인터페이스만으로도 가능하다.

[표 5] PLC의 인터페이스 제안

인터페이스	인 자	설 명
OpenComPort	디바이스 명 포트넘버 통신속도	해당 컴포트(COM1, COM2, ..)를 오픈한다
CloseComPort	포트넘버	열린 컴포트를 닫는다
IsOpenComPort	포트넘버	해당 포트가 열렸는지 확인한다
GetOpenPorts		현재 열려있는 포트수를 알아온다
SetPort	포트주소 설정값 포트넘버	PLC의 특정 주소에 값을 설정한다
GetPort	포트주소 포트넘버	PLC의 특정 주소의 값을 가져온다

컨트롤러 계열 이외에 모니터링 시스템에서 데이터를 수집하는 기능을 역할을 하는 DAS들은 대개 모니터링 데이터를 일정량 버퍼링한 다음 이를  넘겨주는 구조를 가지고 있다. 따라서 데이터가 연속적인 스트림의 형태를 지니는 형태를 가지고 있다. 또한 이들은 주로 DAB(Data Acquisition Board)를 통하여 데이터를 컴퓨터 쪽에 넘겨주는 형태를 취하고 있다. 이런 특성을 바탕으로 다음과 같이 인터페이스를 제안한다.

[표 6] DAS의 인터페이스 제안

인터페이스	인 자	설 명
OpenComPort	디바이스 명 포트넘버 통신속도	해당 컴포트(COM1, COM2, ..)를 오픈한다
CloseComPort	포트넘버	열린 컴포트를 닫는다
IsOpenComPort	포트넘버	해당 포트가 열렸는지 확인한다
GetOpenPorts		현재 열려있는 포트수를 알아온다
GetData	포트주소 포트넘버	데이터 스트림을 읽어 들인다
GetVar	파라메터명 파라메터 값을 받을 변수	읽어진 데이터 스트림에서 해당 파라메터의 값을 알아온다.

6. 결론

본 연구에서는 기존의 모니터링 시스템의 지역성, 호환성, 확장성의 문제점을 보완 하고자 인터넷 기반의 모니터링 및 제어 시스템의 구조를 제안하였으며 이를 바탕으로 파일럿 시스템을 개발하였다. 파일럿 시스템은 시스템 개발의 대상이 되는 하드웨어를 구성하였으며 이를 바탕으로 SNMP에이전트 및 관리국을 작성하였다. 하드웨어는 일반적으로 제어 시스템에 많이 사용되는 PLC를 이용하였다. 구성된 하드웨어를 바탕으로 관리 포인트를 설정하고 이를 MIB로 작성하였다. 에이전트의 개발은 ucd-snmp를 확장하여 개발하였다. 관리국은 모니터링 및 제어를 할 수 있는 MGDC를 개발하였으며 사용자 인터페이스 부분으로 장비관리, 데이터분석, 사용자 관리를 나누어 개발하였다. 또한 PLC에 대한 표준 인터페이스를 제시하였다.

SNMP와 웹기술의 접목은 장비 관리가 표준적인 방법을 통하여 이루어져 시스템의 확장이나 변경에 보다 빨리 적응할 수 있게 하여준다. 그러나 장비마다 SNMP에이전트를 만들어 주어야 하는 문제점은 있으나 이는 장비와 SNMP에이전트간에 표준적인 인터페이스를 제공하고 인터페이스의 구현은 하드웨어 벤더들에게 맡김으로써 해결할 수 있을 것이다.

향후 연구과제로는 장비의 응급발생 시 처리를 하기 위한 트랩의 구현, SNMP 에이전트의 프로토콜 사용으로 인한 보안의 문제, 시스템 규모의 확장으로 인한 RMON의 도입 등에 대한 연구가 필요할 것으로 본다.

참고문헌

[1] 배영호, 박철호, □TMN 시스템과의 연동을 고려한 SNMP 트랩 정의□, 통신 소프트웨어 학술대회, 제1권, pp 415-418 , 1997.

[2] 안성진, 조영욱, 유승근, □SNMP MIB-II를 이용한 인터넷 관리 시스템의 웹 인터페이스 설계 및 구현□, 정보처리논문지, 제6권 제3호 pp 699-709, 1999.

[3] 조규억, 안성진, 정진욱, □SNMP를 이용한 PC 관리 시스템의 설계 및 구현□, 컴퓨터교육학회지, 제3권, pp 109-217, 2000.

[4] SAMSUNG PROGRAMMABLE CONTROLLER USER'S MANUAL, 삼성항공산업주식회사, 1992.

[5] Rubini, A., Linux Device Drivers, O'REILLY, 1999.

[6] Zeltserman, D., A Practical Guide to SNMPv3 and Network Management, Prentice Hall, 1999.

[7] Harold, E.R., JAVA I/O, O'REILLY, 1999.

[8] Hunter, C., Java Servlet               Programming, O'REILLY, 1999.

[9] James D. Murray, Windows NT SNMP, O'REILLY, 1998.

[10] Wall, K., Watson, M. and Whitis, M., Linux Programming Unleashed, SAMS, 2000.

[11] Mark, A. and Miller, P.E., Management Internetworks with SNMP, M&T, 1997.