KR950005986B1

KR950005986B1 - 전전자 교환기의 프로세서 장애 검증 방법

Info

Publication number: KR950005986B1
Application number: KR1019910023147A
Authority: KR
Inventors: 박현; 정창신
Original assignee: 재단법인 한국전자통신연구소; 경상현; 한국전기통신공사; 이해욱
Priority date: 1991-12-17
Filing date: 1991-12-17
Publication date: 1995-06-07
Also published as: KR930015905A

Abstract

내용 없음.

Description

전전자 교환기의 프로세서 장애 검증 방법

제1도는 본 발명이 적용되는 전전자 교환기의 구조도.

제2도는 본 발명에 의한 프로세서 장애 검증 방법의 흐름도.

제3도는 발생된 하드웨어 경보 분석 단계의 흐름도.

제4도는 관련 DB내의 데이터 갱신 단계의 흐름도.

제5도는 발생된 경보 구동 요구 및 경보 메시지 출력 단계의 흐름도.

제6도는 메시지 출력 단계의 흐름도.

제7도는 프로세서 경보 분석 단계의 흐름도.

제8도는 프로세서 장애 경보 검증 단계의 흐름도.

* 도면의 주요부분에 대한 부호의 설명

1 : CCS 2 : INS

3 : ASS 4 : OMP

5 : MMP 6 : 중앙제어 유지보수 정합 프로세서

7 : 연결망 유지보수 8 : 연결망 유지보수 정합 프로세서

9 : 통화로계 장비 유지보수 10 : 접속교환 유지보수 정합 프로세서

본 발명은 분산 처리 구조를 갖는 전전자 교환기에 있어서, 각 모듈(Module)을 구성하는 프로세서(Processor)들의 장애 정보를 받아 이를 분석하고 타당성을 검증하는 프로세서 장애 검증 방법에 관한 것이다.

전전자 교환기의 유지보수는 계층적 개념으로 운용된다. 하위레벨에서는 시스팀에서 발생되는 각종 장애를 전송 프로세서에서 감지하여 직접 상위 레벨에 전달하거나 프로그램 수행 중 소프트웨어에 의하여 감지되는 장애를 상위 레벨로 보고한다. 상위 레벨에서는 하위 레벨에서 보고된 장애 정보를 전체적으로 진단하고 관리하며 운용자에게 전달하는 기능을 한다.

그러나, 하위 레벨에서 보고된 장애 정보는 비정상적일 수 있으며 상위 레벨에서의 장애 분석 미숙으로 인하여 출력되는 메시지를 운용자가 신뢰하기는 어려운 문제점이 있었다. 즉, 프로세서의 경우, 주프로세서(MP : Main Processor)나 부 프로세서(PP : Peripheral Processor) 들의 다운(down), 복구 정보는 시스팀운용에 중요한 정보가 되지만 종래에는 프로세서 다운(down), 복구 기준을 MPMA(Main Processor Memroy Management Board Assembly) 기능의 이상유무에 의존했으므로 프로세서 다운(down), 복구를 판단하는 기준이 미비하여, 실제 하위 레벨에서 보고된 장애 정보를 신뢰하기는 어려운 문제점이 있었다.

상기 문제점을 해결하기 위하여 안출된 본 발명은 전전자 교환기에 있어서, DCCA(Duplication Control Channel Board Assembly) 기능과 PCCA(Processor Communication Control Board Assembly) 기능 등의 이상 유무를 첨가하여 하위 레벨에서 보고된 정보를 분석에 의해 이전의 정보와의 검증을 통하여 운용자에게 신뢰성 있는 장애 복구 정보를 제공하기 위한 프로세서 장애 검증 방법을 제공하는 데 그 목적이 있다.

상기 목적을 달성하기 위하여 본 발명은, 분산되 호처리 기능을 수행하는 ASS(Access Switching Subsystem) ; 집중화된 호처리 기능을 수행하는 INS(Interconnection Network Subsystem) 및 시스팀의 운용 및 보전의 집중화 기능을 수행하는 CCS(Central Processing Unit)를 구비하는 전전자 교환기의 각 모듈(Module)을 구성하는 프로세서(Processor)들의 장애 정보를 받아 이를 분석하고 타당성을 검증하는 프로세서 장애 검증 방법에 있어서 ; 하위 레벨로부터 장애 경보가 도착되면 상기 발생된 하드웨어 경보를 분석하여 DB(Data Base)내의 관련 내용을 갱싱(Updata)한 후에 경보 구동 요구 및 경보 메시지를 출력한 다음에 발생된 경보가 프로세서 자체와 관련이 있는지 검색하는 제1단계 ; 상기 제1단계 수행 후, 발생된 경보가 프로세서 자체와 관련이 없으면 종료하는 제2단계 및 상기 제1단계 수행후, 발생된 경보가 프로세서와 관련이 있으면 프로세서 경보를 분석하여 프로세서 상태에 관련된 내용을 관리하는 데이터베이스를 갱신한 후 경보 구동 요구 및 경보 메시지를 출력하는 제3단계를 포함하는 것을 특징으로 한다.

이하, 첨부된 도면을 참조하여 본 발명에 따른 일실시예를 상세히 설명한다.

제1도는 본 발명이 적용되는 전전자 교환기의 구조도로서, 1은 CCS(Central Control Subsystem), 2는 INS(Interconnection Network Subsystem), 3은 ASS(Access Switching Subsystem), 4는 OMP(Operation and Maintenance Processor), 5는 MMP(Man Machine Processor), 6은 중앙제어 유지보수 정합 프로세서, 7는 연결망 유지 보수, 8은 연결망 유지보수 정합 프로세서, 9는 통화로계 장비 유지보수, 10은 접속교환 유지보수 정합 프로세서를 각각 나타낸다.

본 발명이 적용되는 전전자 교환기의 하드웨어는 ASS(Access Switching Subsystem)(3), INS(Interconnection Network Subsystem)(2), CCS(Central Control Subsystem)(1)의 3개의 서브시스팀으로 구성된다.

상기 ASS(3)는 분산된 호처리 기능을 수행하며 최대 60개가 실장될 수 있다.

그리고, 상기 INS(2)는 집중화된 호처리 기능 부분을 수행하며 상기 CCS(1)에서 시스팀의 운용 및 보전의 집중화 기능을 수행한다.

유지보수 체계는 상위 레벨과 하위 레벨로 이루어지는데, 하위 레벨에서의 유지보수는 각 모듈별 전송 유지보수 정합 프로세서(중앙제어 유지보수, 연결망 유지보수, 접속교환 유지보수)(6, 8, 10)로부터 시스템내에서 발생하는 각종 장애를 직접 감지하거나 시스템내 모든 프로세서 자체나 프로세서에 의하여 제어되는 장치의 장애를 프로세서가 인식하여 처리되는 정보(연결망 유지보수, 통화로계 장비 유지보수)(7, 9)를 상위 레벨인 CCS(1)내의 OMP(4)의 장애 관리 블록으로 보관한다. 상기 장애 관리 블록에서는 하위 레벨로부터 받은 장애 메시지를 분석하여 메시지 구성에 필요한 정보를 추출하거나 경보 구동을 요구한다.

제2도는 본 발명에 의한 프로세서 장애 검증방법의 흐름도이다.

하위 레벨에서 보고된 장애 정보중 하위 레벨 하드웨어 장애경보(201)나 그외 다른 부류의 장애(202)가 도착되면 장애 관리가 시작된다. 하드웨어 장애경보는 전원의 정상유무, 관련 보드의 탈장이나 기능 정상유무, 관련 케이블의 탈장 여부 등에 대한 정보이다.

발생된 하드웨어 경보를 분석하여 출력 메시지 구성에 필요한 위치 정보(모듈이름, 시스팀의 한 단위인 랙(Rack), 셀프(Shelf)정보) 및 탈장 원인 정보를 추출한다(203), 경보 발생시 자체적으로 관리하고 있는 DB(Data Base)내의 관련 내용을 갱신(Updata)한 후에(204) 경보 구동 요구 및 경보 메시지를 출력한다(205). 현재 발생된 경보가 프로세서 자체와 관련이 있는지 검색하여(206) 관련이 없는 경우에는 종료하고, 관련이 있는 경우에는 프로세서 경보가 다운(down)인지 복구(recover)인지를 분석하여(207) 프로세서 다운(down) 또는 복구인 경우 자체내 프로세서 상태에 관련된 내용을 관리하는 데이터를 갱신 한 후에(208) 경보 구동 요구 및 경보 메시지를 출력한다(209).

제3도는 제2도의 발생된 하드웨어 경보 분석 단계의 세부 흐름도이다.

발생된 하드웨어 경보 분석이 시작되면(301) 발생된 경보가 DB 내용과 일치하는지를 검사한다(302). 즉, 이미 복구된 프로세서에 대하여 복구됐다는 경보 메시지가 오는 경우 이후 처리를 생략한다.

발생된 경보에 대하여 어느 위치에서 발생된 것이며 어떤종류의 장애인가를 분석한다(303). 모든 경보를 우선적으로 디바이스 경보로 초기화하고(304) 발생된 경보가 장애 관리 자체적으로 보유하고 있는 프로세서의 세부적인 내용 테이블(table) 범위에 속하는가를 판단하여(305) 속하면 내부 테이블에서 현 경보의 상세 정보를 추출하고(306), 상기 정보에 포함된 프로세서 장애 기준 정보를 추출한다(307). 상기 발생된 경보가 기준정보인지 검색하여(308) 기준 정보중 하나일 경우 경보 종류를 프로세서 자체 경보로 판단한다(309). 상기 자체경보 판단 처리 후(309), 또는 상기 발생된 경보가 기준경보가 아닐 경우, 또는 상기 발생된 경보가 테이블 범위에 속하지 않는 경우에는 그외 필요한 정보를 DB에서 추출한다(310).

제4도는 제2도의 관련 DB내의 데이터 갱신 단계의 흐름도이다.

발생된 경보 메시지의 내용을 관리하기 위하여 관련 DB내용 갱신작업이 시작되면(401) DB의 데이터 내용중 발생된 경보와 관련된 내부 테이블에서 경보 번호를 추출하여(402) 내용을 갱신한다(403). 즉, 경보 내용에 따라 경보 빈도수를 증가, 혹은 감소시킨다.

경보 성격상 하드웨어 또는 소프트웨어적인 것인지 검색하여(404)하드웨어 또는 소프트웨어적인 것이면 DB에서 경보 소스 내용을 갱신하고(406) 경보가 몇번 발생됐는가를 기록한다(407). 하드웨어 또는 소프트웨어적인 것이 아닐 경우 그외의 처리를 수행한다(405).

제5도는 제2도의 발생된 경보 구동 요구 및 경보 메시지 출력 단계의 흐름도이다.

경보 구동 요구 및 경보 메시지 출력이 시작되면(501) 경보 정보를 추출하고(502) 경보가 발생된 위치와 경보 등급 등을 내재한 경보구동 요규정보를 중앙제어 유지보수 정합 프로세서를 통하여 경보 구동장치에게 요구한다(503). 이 경보 구동장치는 본체 외부에 설치되며 경보의 긴급 정도와 발생 위치에 따라서 각각 운용자가 파악하기 쉽도록 설계된 삼중화된 장치이다. 이 경보를 위하여 메시지 출력이 가능한지를 판단하여(504) 가능하면 메시지를 출력한다(505).

제6도는 제5도의 메시지 출력 단계의 흐름도이다.

메시지 출력이 시작되면(506) 경보 메시지 출력 형태(form)를 결정하기 위해 경보 부류(class)를 구분하고(507) 메시지를 구성하여(508) 운용자에게 출력한다(509).

제7도는 제2도의 프로세서 경보 분석 단계의 흐름도이다.

프로세서 경보 분석이 시작되면(601) 내부 테이블로부터 경보의 세부 내용 즉, 하드웨어 블럭이름, 유니트(unit), 부 프로세서 주소 등을 추출한다(602). 프로세서 다운(down) 형태를 단일 다운(single down)으로 초기화 하고(603) 프로세서의 중복형태(단일화, 이중화 ; TDX-10(상표명)의 주 프로세서는 이중화로 운용되고, 부 프로세서도 일부를 제외하고 이중화로 구성)를 판단하여(604) 단일화된 프로세서는 경보 형태 그대로 경보값을 세트(set)하고(605), 이중화된 프로세서는 경보값을 검색한다(606). 상기 검색결과 경보 형태가 온(ON)인 프로세서 다운(down)인 경우 이중화된 프로세서중 적어도 하나는 다운(down)임을 나타내며(607), 오프(OFF)인 프로세서 복구(recover)인 경우, 이는 이중화된 프로세서중 적어도 하나는 복구 됐음을 나타낸다(608).

상기 경보값에 대한 검색 처리후(605, 606, 607, 608) 정상처리가 완료되었는지 검색하여(609) 완료되지 않은 경우에는 종료하고, 완료된 경우에는 프로세서를 테스트(test)하는 프로세서 상태관리 블럭으로 프로세서 장애보고 및 그에 대한 회신을 요구하고(610) 프로세서 장애 경보 검증을 한다(611). 이때, 프로세서의 상태를 관리하는 블럭은 본체의 모든 프로세서를 일정한 간격을 두면서 각 프로세서의 시그널을 주고 받음으로써 정상 상태를 감시한다.

제8도는 제7도의 프로세서 장애 경보 검증 단계의 흐름도이다.

프로세서 장애 경보 검증이 시작되면(611) 프로세서 장애 보고에 대한 회신이 도착했는지를 판단하여(612) 도착했으면 프로세서 상태 관리 블럭으로부터 회신을 받는다(613). 회신이 오지 않는 경우에는 타이머를 구동하여(614) 타임 아웃이 되었는지 검색하여(615) 타임아웃이 아니면 상기 프로세서 장애에 대한 회신 입력 여부 검색 단계(612)로부터 다시 진행하고 타임아웃이 된 경우에는 하위레벨 프러세서 상태관리 블럭으로 재차 보고하고 회신을 기다린(616). 다시 타임아웃 여부를 검색하여(617) 타임아웃이 아니면 상기 프로세서 장애에 대한 회신 입력 여부 검색 단계(612)로부터 다시 진행하고 타임아웃이 된 경우에는 미도착으로 결정을 내린다(618).

화신이 도착된 경우 보유한 DB의 하드웨어 상태와 정상, 비정상상태를 나타내는 회신내용이 동일한가를 판단하여(619) 동일한 경우 프로세서 상태 메시지를 출력하고(620), 동일하지 않는 경우 프로세서 상태 메시지 출력을 보류한다(621).

상기와 같이 구성되어 동작하는 본 발명은 프로세서 다운, 복구 기준에 대한 내용이 로컬 데이터에 수록되어 있기 때문에 기준내용이 바뀔때마다 프로그램을 수정할 필요가 없게 되며 시스템 운용에 큰 영향을 미칠 수 있는 프로세서 다운, 복구 정보를 재차 검증을 통해 출력하므로 메시지의 신뢰성이 높아지는 적용 효과가 있다.

Claims

분산된 호처리 기능을 수행하는 ASS(Access Switching Subsystem)(3); 집중화된 호처리 기능을 수행하는 INS(Interconnection Network Subsystem)(2); 및 시스팀의 운용 및 보전의 집중화 기능을 수행하는 CCS(Central Processing Unit)(1)를 구비하는 전전자 교환기의 각 모듈(Module)을 구성하는 프로세서(Processor)들의 장애 정보를 받아 이를 분석하고 타당성을 검증하는 프루세서 장애 검증 방법에 있어서; 하위 레벨로부터 장애 경보가 도착되면 상기 발생된 하드웨어 경보를 분석하는 제1단계(201 내지 203); DB(Data Base)내의 관련 내용을 갱신(Updata)하는 제2단계(204); 경보 구동 요구 및 경보 메시지를 출력하는 제3단계(205); 발생된 경보가 프로세서 자체와 관련이 있으면 프로세서 경보를 분석하는 제4단계(206, 207); 프로세서 상태에 관련된 내용을 관리하는 데이터베이스를 갱신하는 제5단계(208); 및 경보 구동 요구 및 경보 메시지를 출력하는 제6단계(209)를 포함하는 것을 특징으로 하는 전전자 교환기의 프로세서 장애 검증 방법.
제1항에 있어서, 상기 제1단계(201 내지 203)는, 발생된 하드웨어 경보가 DB 내용과 일치하는지를 검사하여 발생된 경보에 대하여 어느 위치에서 발생된 것이며 어떤 종류의 장애인가를 분석한 후에 모든 정보를 우선적으로 디바이스 경보로 초기화하고 발생된 경보가 장애 관리 자체적으로 보유하고 있는 프로세서의 세부적인 내용 테이블(table) 범위에 속하는 가를 판단하는 제1과정(301 내지 305); 상기 제1과정(301 내지 305) 수행 후, 프로세서의 세부적인 내용 테이블 범위에 속하지 않으면 필요한 정보를 상기 DB에서 추출하는 제2과정(310); 및 상기 제1과정(301 내지 305) 수행 후, 프로세서의 세부적인 내용 테이블 범위에 속하면 내부 테이블에서 현 경보의 상세 정보를 추출하여 정보에 포함된 프로세서 장애 기준 정보를 추출한 후에 발생된 경보가 기준정보인지 검색하여 기준정보가 아니면 필요한 정보를 추출하고, 기준정보이면 경보 종류를 프로세서 자체 경보로 판단하고 필요한 정보를 추출하는 제3과정(306 내지 310)을 포함하는 것을 특징으로 하는 전전자 교환기의 프로세서 장애 검증 방법.
제1항에 있어서, 상기 제2단계(204)와 제5단계(208)는, DB의 데이터 내용중 발생된 경보와 관련된 내부 테이블에서 경보번호를 추출하여 내용을 갱신한 후에 경보 성격상 하드웨어 또는 소프트웨어적인 것인지 아니면 그외의 정보인지를 검색하는 제1과정(401 내지 404); 상기 제1과정(401 내지 404) 수행 후, 하드웨어 또는 소프트웨어적인 것이 아니면 그외의 해당 처리를 수행하는 제2과정(405); 및 상기 제1과정(401 내지 404) 수행 후, 하드웨어 또는 소프트웨어적인 것이면 DB에서 경보 소스 내용을 갱신하고 경보가 몇번 발생됐는가를 기록하는 제3과정(406, 407)을 각각 포함하는 것을 특징으로 하는 전전자 교환기의 프로세서 장애 검증 방법.
제1항에 있어서, 상기 제3단계(205)와 제6단계(209)는, 경보 정보를 추출하고 경보가 발생된 위치와 경보 등급 등을 내재한 경보 구동 요구 정보를 경보 구동 장치에게 요구한 후에 경보를 위한 메시지 출력이 가능한지를 판단하는 제1과정(501 내지 504); 상기 제1과정(501 내지 504) 수행 후, 메시지 출력이 불가능하면 종료하는 제2과정 및 상기 제1과정(501 내지 504) 수행 후, 메시지 출력이 가능하면 메시지를 출력하는 제3과정(505)을 각각 포함하는 것을 특징으로 하는 전전자 교환기의 프로세서 장애 검증 방법.
제4항에 있어서, 상기 제3과정(505)은, 경보 메시지 출력 형태(form)를 결정하기 위해 경보 부류(class)를 구분하는 과정(507) 및 메시지를 구성하여 운용자에게 출력하는 과정(508, 509)을 포함하는 것을 특징으로 하는 전전자 교환기의 프로세서 장애 검증 방법.
제1항에 있어서, 상기 제4단계(206, 207)는, 발생된 경보가 프로세서 자체와 관련이 있으면 내부 테이블로부터 경보의 세부 내용을 추출하고 프로세서 다운(down) 형태를 단일다운으로 초기화한 후에 프로세서의 중복형태를 판단하는 제7단계(601 내지 604); 상기 제7단계(601 내지 604) 수행 후, 단일화된 프로세서인 경우에는 경보 형태 그대로 경보값을 세트(set)한 후에 정상처리가 완료되었는지 검색하여 완료된 경우 프로세서를 테스트(test)하는 프로세서 상태관리 블럭으로 프로세서 장애보고 및 그에 대한 회신을 요구하고 프로세서 장애 경보를 검증하는 제8단계(605, 609 내지 611) 및 상기 제7단계(601 내지 604) 수행후, 이중화된 프로세서이면 경보값을 검색하여 프로세서 다운(down)인 경우에는 이중화된 프로세서중 적어도 하나는 다운(down)임을 나타내고 프로세서 복구(recover)인 경우에는 이중화된 프로세서중 적어도 하나는 복구됐음을 나타내는 것으로 판단한 후에 정상처리가 완료되었는지 검색하여 완료된 경우 프로세서를 테스트(test)하는 프로세서 상태관리 블럭으로 프로세서 장애보고 및 그에 대한 회신을 요구하고 프로세서 장애 경보를 검증하는 제9단계(606 내지 611)를 포함하는 것을 특징으로 하는 전전자 교환기의 프로세서 장애 검증 방법.
7. 제6항에 있어서, 상기 제9단계(606 내지 611)의 프로세서 장애 경보를 검증하는 과정은, 프로세서 장애 보고에 대한 회신이 도착했는지를 판단하는 제10단계(612); 상기 제10단계(612) 수행 후, 회신이 도착하지 않았으면 타이머를 구동하여 2회에 걸쳐 타임 아웃여부에 따라 회신을 기다리면서 회신이 도착하면 다음 단계로 진행하고 회신이 도착하지 않으면 미도착 결정을 내리는 제11단계(614 내지 618) 및 상기 제10단계(612) 수행 후, 회신이 도착하였으면 보유한 DB의 하드웨어 상태와 정상, 비정상 상태를 나타내는 회신내용이 동일한가를 판단하여 동일한 경우 프로세서 상태 메시지를 출력하고 동일하지 않은 경우 프로세서 상태 메시지 출력을 보류하는 제12단계(613, 619 내지 621)를 포함하는 것을 특징으로 하는 전전자 교환기의 프로세서 장애 검증 방법.