상기한 목적을 달성하기 위하여, 본 발명의 오류 감시 장치는 통신 장치 내부의 프로세서 또는 서브 시스템과 정합되어 비동기 데이터 전송을 수행하며, 수신된 데이터를 내부 클럭과 동기시키기 위한 정합부와, 상기 정합부의 데이터를 수신하여, 운용자 제어 시스템에서 사용할 수 있는 데이터 포맷으로 변환하는 제어부와, 운용자 제어 시스템과 정합되어 상기 제어부에서 변환된 데이터를 운용자 제어 시스템과 비동기 전송을 수행하는 제어 시스템 정합부와, 통신 장치 내부의 프로세서 또는 서브 시스템의 출력 데이터에 따라 오류 상태를 판단하고, 그에 따라 통신 장치에 경보 신호 또는 제어 신호를 전송하는 운용자 제어 시스템을 포함할 수 있다.
상기 정합부는 통신 장치와의 비동기 전송을 위한 복수의 RS-232 포트를 구비하는 RS-232 인터페이스부를 포함할 수 있다.
상기 RS-232 인터페이스부는 통신 장치에서 출력되는 데이터를 수신하기 위한 복수의 수신용 FPGA와, 통신 장치로 데이터를 전송하기 위한 송신용 FPGA를 포함할 수 있다.
상기 수신용 FPGA는 각 RS-232 포트에 있어서, 수신된 데이터를 비트 단위로 리타이밍하는 비트 동기부와, 상기 비트 동기부를 통하여 동기된 데이터에서 스타트 비트 및 정지 비트를 검출하여 바이트 단위의 동기 신호를 발생하는 바이트 동기부를 포함할 수 있다.
상기 바이트 동기부는 입력된 데이터를 일정 시간 동안 래치시키기 위한 래치부와, 상기 래치부의 데이터에서 스타트 비트와 정지 비트를 제외한 데이터 비트의 순서를 변환하기 위한 변환부를 포함할 수 있다.
상기 송신용 FPGA는 RS-232 포트에 대하여 루프 백 기능을 테스트하는 루프 백 테스트부와, 수신용 FPGA의 클럭 신호 및 프레임 동기 신호의 상태를 모니터링하는 모니터부와, RS-232 데이터를 교환기로 전송하는 전송부를 포함할 수 있다.
상기 제어부는 정합부에서 수신된 데이터를 저장하기 위한 메모리부와, 수신된 데이터를 처리하기 전에 버퍼링하는 버퍼부와, 상기 버퍼부를 통하여 전송된 데이터를 병렬 데이터로 변환한 후에, 이를 운용자 제어 시스템에서 사용하는 HDLC 형태 또는 통신 장치에서 사용하는 RS-232 형태로 변환하는 데이터 변환부를 포함할 수 있다.
상기 제어 시스템 정합부는 운용자 제어 시스템과의 데이터 전송을 위한 복수의 RS-232 포트를 구비하는 RS-232 인터페이스부를 포함할 수 있다.
상기 RS-232 인터페이스부는 운용자 제어 시스템에서 출력되는 데이터를 수신하기 위한 복수의 수신용 FPGA와, 교환기로 데이터를 전송하기 위한 송신용 FPGA를 포함할 수 있다.
상기 수신용 FPGA는 각 RS-232 포트에 있어서, 수신된 데이터를 비트 단위로 리타이밍하는 비트 동기부와, 상기 비트 동기부를 통하여 동기된 데이터에서 스타트 비트 및 정지 비트를 검출하여 바이트 단위의 동기 신호를 발생하는 바이트 동기부를 포함할 수 있다.
상기 바이트 동기부는 입력된 데이터를 일정 시간 동안 래치시키기 위한 래치부와, 상기 래치부의 데이터에서 스타트 비트와 정지 비트를 제외한 데이터 비트의 순서를 변환하기 위한 변환부를 포함할 수 있다.
상기 송신용 FPGA는 RS-232 포트에 대하여 루프 백 기능을 테스트하는 루프 백 테스트부와, 수신용 FPGA의 클럭 신호 및 프레임 동기 신호의 상태를 모니터링하는 모니터부와, RS-232 데이터를 운용자 제어 시스템으로 전송하는 전송부를 포함할 수 있다.
또한, 본 발명의 오류 감시 장치의 운용 방법은 통신 장치 내부의 프로세서 또는 서브 시스템과 각각 연결되는 오류 감시 장치에 구비된 하나 이상의 포트 정보를 설정하는 단계와, 상기 설정된 포트 정보에 따라 해당하는 통신 장치 내부의 프로세서 또는 서브 시스템의 출력 메시지를 수신하는 단계와, 상기 수신된 메시지를 분석하여 해당하는 프로세서 또는 서브 시스템의 상태를 분석하는 단계와, 상기 분석 결과에 따라 오류가 발생한 프로세서 또는 서브 시스템에 경보 메시지를 전송하는 단계와, 프로세서 또는 서브 시스템 관리자의 요청에 따라 오류가 발생한 프로세서 또는 서브 시스템의 동작을 제어하는 단계를 포함할 수 있다.
상기 포트 정보는 통신 장치 내부의 프로세서 또는 서브 시스템에 연결된 포트에 사용되는 모듈 정보와, 해당하는 포트 번호를 포함할 수 있다.
상기 통신 장치 내부의 프로세서 또는 서브 시스템의 출력 메시지를 수신하는 단계는 수신된 메시지를 데이터베이스에 저장하는 단계를 더 포함할 수 있다.
상기 오류가 발생한 프로세서 또는 서브 시스템의 동작을 제어하는 단계는 해당하는 프로세서 또는 서브 시스템을 리셋시키는 단계를 더 포함할 수 있다.
이하, 첨부한 도면에 의거하여 본 발명의 바람직한 실시예를 자세히 설명하도록 한다. 이하에서는 교환기의 오류를 감시하는 장치 및 그 운용 방법을 예로 들어 설명한다.
도 3은 본 발명의 바람직한 실시예에 따른 오류 감시 장치를 이용한 경우의 전체 블록도를 나타낸 것이다. 도 3을 참조하면, 본 발명의 오류 감시 장치(200)는 TDX 계열이나 다른 계열에 속하는 교환기(100)에 연결되어 교환기의 입출력 포트에서 발생되는 출력 신호를 수신하여 이를 판단한다. 이 때, 오류 감시 장치(200)는 교환기(100)와 단거리에서 연결되는 경우에, 일반적으로 RS-232 포트를 이용할 수 있다.
또한, 교환기(100)에서 발생한 오류를 분석하고 판단할 수 있도록 별도의 제어 시스템(300)을 포함할 수 있다.
이 때, 오류 감시 장치(200)는 교환기(100)와의 인터페이스를 위한 RS-232 인터페이스부를 포함할 수 있다. 마찬가지로, 제어 시스템(300)은 오류 감시 장치(200)와의 인터페이스를 위하여 원격 인터페이스부를 포함할 수 있다.
이와 같은 오류 감시 장치(200)를 통하여 구현하고자 하는 기능은 교환기 내부의 각 프로세서의 메시지 처리 기능, 더미 터미널(Dummy Terminal)을 통한 운용자 정합 기능, 교환기의 시스템 포트 제어 기능, 각 프로세서 간 IPC 통신 상태 점검 기능 및 프로세서 점검 기능을 들 수 있다.
프로세서의 메시지 처리 기능은 교환기 및 주변 입출력 프로세서에서 이상 현상에 의하여 발생한 메시지를 프로세서 별로 수집 및 디스플레이 한다. 또한, 수집된 메시지를 분류하여 저장하고, 시간대 별로 메시지를 따른 검색 및 분석하여 장애가 발생될 때 이를 경보할 수 있도록 한다. 그에 따라, 사전에 오류를 차단하거나 장애가 발생하더라도 조기에 이를 복구할 수 있도록 한다. 이 때, 프로세서의 입출력 포트에 모아진 메시지는 장애 발생에 대한 실마리로 활용하여 시스템 차원의 보완이 가능하도록 한다.
운용자 정합 기능은 운용자 제어 시스템을 통해 실시간으로 각 프로세서에 대한 정합 및 해제를 가능하도록 한다. 즉, 운용자 시스템의 포트에 접속된 각 프로세서를 별도의 창으로 활성화시켜서 모니터링하고, 해당 프로세서에 명령을 전달할 수 있도록 복수의 더미 터미널을 구비한다.
시스템 포트 제어 기능은 각 기업(삼성, 현대 또는 LG 등)에서 제공하는 교환기의 구조에 따라 이에 적당하도록 접속 포트의 구성을 변경하고, 각 구성에 따라 포트 정보가 정상적으로 입력되었는지를 확인한다.
프로세서간 IPC 통신 상태 점검 기능은 IPC 점검 정보를 입력 및 변경, 삭제할 수 있고, 운용자의 요구에 따라 IPC 테스트를 수행한다. 또한, IPC 점검 정보를 저장하고 요구에 따라 이를 출력한다. IPC 점검 과정에서 장애가 발생하면, 경보 메시지를 발생하고, 매일 정해진 시간에 교환기를 점검하기 위한 IPC 로그 자동 시험 기능을 포함한다.
프로세서 점검 기능은 각 프로세서서가 슬리핑(Sleeping) 상태에 빠지는 것을 방지하기 위하여, 주기적으로 프로세서의 응답을 요구하는 기능으로서, 프로세서의 경보 상태를 감지하고 이를 통보한다.
도 3은 교환기(100)에서 발생하는 오류 메시지를 중간에서 집선하지 않고, 오류 감시 장치(200)에서 직접 수집하여 이를 제어 시스템(300)으로 제공하는 집중형 구조를 나타낸 것이다. 반면에, 교환기의 각 ASS, INS 또는 CCS 단위를 RS-232 포트를 일정 비율로 1차 집선한 후에, 교환기 오류 감시 장치(200)를 통하여 2차로 집선하는 분산형으로 구성할 수 있다.
도 3과 같은 집중형 구조는 오류 감시 장치로만 구성되고, 인터페이스 방식이 단순하기 때문에 전체 구성이 단순하다. 또한, 분산형 구조에 비하여 하드웨어 및 소프트웨어의 개발 기간이 짧은 이점이 있다. 그리고, 하나의 랙(Rack)에 오류 감시 장치를 모두 구성 및 설치함으로써, 본체의 규모가 커지지만 유지 및 관리 비용이 저렴한 장점이 있다. 반면에, 분산형 구조는 교환기 포트의 오류를 집선하는 장치가 1차 및 2차로 분산되어 있기 때문에, 본체의 규모는 작아지지만 전체적인 구조가 복잡하기 때문에 고장 확률이 높아지며, 유지 및 관리가 어렵다. 또한, 인터페이스 프로토콜이 복잡해지고, 하드웨어 및 소프트웨어의 개발 기간이 길어진다.
도 4는 본 발명의 바람직한 실시예에 따른 집중형 오류 감시 장치의 구성도를 나타낸 것이다. 도 4를 참조하면, 본 발명의 오류 감시 장치(200)는 교환기와의 접속을 위하여 최대 512 개의 RS-232C 케이블을 구비할 수 있다. 또한, 교환기에서 발생되는 디버그(RS-232C) 포트의 메시지를 직접 오류 감시 장치(200)에서 집선하고, 이를 제어 시스템(300)으로 전송할 수 있도록 내부 구성을 갖는다.
오류 감시 장치(200)는 2 개의 선반에 ISBB(IPC Supervision and operation Back Board)와 PWR(Power Pack)이 각각 1 매씩 구비될 수 있다. 2 매의 ISBB에는 각각 4 매의 RSIA(RS-232 Interface board Assembly)가 구비되고, 일 측의 ISBB에 CMIA(Control and Memory Interface board Assembly) 1 매가 구비될 수 있다. 따라서, 오류 감시 장치(200)는 전체적으로 2 매의 ISBB, 1 매의 CMIA 및 8 매의 RSIA로 구성될 수 있다.
이 때, 오류 감시 장치(200)와 교환기(100) 사이에 RS-232 포트에 대한 데이터 전송 속도는 일반적으로 9,600 bps 이고, 제어 시스템(300)의 데이터 전송량은 230.40 Kbps이며, 이더넷(Ethernet)을 통하여 최대 10Mbps의 속도로 전송될 수 있다.
예컨대, 제어 시스템(300)에서 4일 간의 전송 데이터를 저장하기 위해서는, 최대 230.40 Kbps × 3,600 sec × 24 시간 × 4일 = 7.96G 바이트의 메모리 용량이 필요하다. 이와 같은 메모리 용량은 데이터 저장 기간에 따라 달라질 것이다.
도 5는 본 발명의 바람직한 실시예에 따른 오류 감시 장치에 있어서, ISBB의 블록도를 나타낸 것이다. 도 5를 참조하면, ISBB에서 4 매의 RSIA는 RS-232 커넥터를 통하여 교환기와 비동기 통신을 한다. 그리고, CMIA는 HDLC(High level Data Link Control) 포맷을 사용하며, RJ-42 커넥터를 통하여 제어 시스템과 랜(LAN) 인터페이스를 담당한다.
각 RSIA는 64 개의 RS-232 포트를 수용할 수 있기 때문에, 1 매의 ISBB는 256 개의 RS-232 포트를 수용할 수 있고, 오류 감시 장치(200)는 총 512개의 RS-232 포트를 수용할 수 있다. RSIA는 교환기(100)로부터 9,600 bps로 전송되는 비동기 직렬 데이터 64 비트를 수신하여, 오류 감시 장치(200)의 시스템 클럭에 동기화 시킨다. 그런 다음, 수신된 신호를 병렬 데이터로 변환하고, 이를 512 : 64로 다중화 하여 CMIA로 전송한다. 한편, CMIA는 제어 시스템(300)으로부터 전송된 데이터를 수신하고, RS-232 포트 번호와 함께 9,600 bps의 데이터 씩 CMIA에 구비된 MC68360의 UART 포트를 통하여 RSIA로 전송한다. 그에 따라, RSIA는 RS-232 포트 번호를 디멀티플렉싱(Demultiplexing)하여 CMIA로부터 제공된 UART Tx 신호를 해당 포트로 전송한다. 도 5는 CMIA가 구비된 ISBB를 나타낸 것이다.
도 6a 및 도 6b는 본 발명의 바람직한 실시예에 따른 오류 감시 장치에 있어서, 상기 도 5에 도시된 ISBB에 사용되는 신호의 정의를 표로 나타낸 것이다.
도 6a 및 도 6b를 참조하면, CMIA에서 사용되는 신호는 모두 TTL(Transistor Transistor Logic) 신호로 사용할 수 있다.
CMIA에서 외부로 제공되는 UARTTX 신호는 교환기 방향으로 출력될 RS-232 Rx 신호이며, RSIA에서 수신하여 해당하는 DMXSEL 신호에 의하여 해당 포트로 디멀티플렉싱 된다. RS_TX+,- 신호는 제어 시스템(300)과 인터페이스 되는 RS-485 Tx 신호이고, RS_RX+,- 신호는 제어 시스템(300)과 인터페이스 되는 RS-485 Rx 신호이다.
RSIAOPEN 3,2,1,0 신호는 셀프-사이드 RSIA의 PBA 오픈 신호이고, RSIAOPEN D,C,B,A 신호는 다른 사이드의 RSIA PBA 오픈 신호이다. 또한, RSIAFF 3,2,1,0 신호는 셀프-사이드 RSIA의 기능 오류를 나타내는 신호이고, RSIAFF D,C,B,A 신호는 다른 사이드의 RSIA에 대한 기능 오류를 나타내는 신호이다.
RS_DPRAMDATA[7:0] 신호는 RSIA에서 송신된 다중화된 Rx 데이터이고, OUTDMXSEL[8:0] 신호는 RSIA로 전송된 RS-232 Tx 신호인 UARTTX 신호를 디코딩하기 위한 신호이다.
CMIAOPEN 2,1,0 신호는 CMIA의 PBA 오픈 신호이고, FRAMESYNC+,- 신호는 RSIA에서 동기를 맞추기 위한 신호이다. 그리고, OUTCLK49152M+,- 신호는 RSIA에서 클럭 타이밍을 재 조절하기 위한 클럭 신호이고, OUTCLK49152K+,- 신호는 RSIA에서 바이트의 동기를 맞추기 위한 클럭 신호이다. 또한, OUTCLK1536K+,- 신호와 OUTCLK96K 신호는 RSIA에서 비트 동기를 맞추기 위한 클럭 신호이다. CPUDOGCLK 신호는 RSIA의 클럭을 모니터링 하기 위한 클럭 신호이고, RS_ADDCOUNT[7:0] 신호는 RS_DPRAMDATA 의 데이터 카운트 값이다.
도 7은 본 발명의 바람직한 실시예에 따른 오류 감시 장치에 있어서, RSIA의 블록도를 나타낸 것이다. 도 7을 참조하면, 본 발명의 RSIA는 교환기(100)와의 데이터 전송을 위하여 9,600 bps의 전송 속도를 가지는 64 개의 RS-232C 포트와 접속된다. 즉, RSIA는 교환기(100)로부터 수신되는 64 비트의 RS-232 비동기 데이터를 다중화 하여 CMIA로 송신하고, CMIA로부터 RS-232 비동기 데이터를 수신하여 이를 교환기로 전송한다.
이 때, RSIA는 8 비트의 RS-232 Rx 데이터를 각각 처리하는 8 개의 수신용 FPGA(Field Programmable Gate Array: FPGA-RX0, ... , FPGA-RX7)에 의하여 64 비트의 RS-232 수신 데이터를 처리한다. 그리고, 64 비트의 RS-232 Tx 데이터를 처리하는 1 개의 송신용 FPGA(FPGA-TX)에 의하여 교환기(100)로 전송될 64 비트의 데이터를 처리한다. 또한, RS-232 송신 데이터를 위한 송신용 FPGA(FPGA-TX)는 RSIA 내의 클럭 및 기능 오류를 수집하여 CMIA로 전송하는 기능을 수행한다.
도 8은 본 발명의 바람직한 실시예에 따른 오류 감시 장치에 있어서, RSIA의 수신용 FPGA의 내부 블록도를 나타낸 것이다.
도 8을 참조하면, 수신용 FPGA는 8 개의 FPGA(OR2C12A-2S208)로 구성되며, 각 FPGA는 교환기로부터 전송되는 8 비트의 RS-232 Rx 데이터와 정합 된다. 또한, 각 수신 포트는 수신된 데이터에 대하여 비트 동기화를 유도하는 비트 동기부와 바이트 동기화를 유도하는 바이트 동기부로 구성되어 있다.
비트 동기부는 수신된 9,600 bps의 RS-232 Rx 데이터를 38.4 KHz로 리타이밍(retiming)함으로써, 9,600 bps의 데이터에 대한 비트 동기화를 수행한다. 비트 동기화가 이루어지면, 스타트 비트 검출부에서 스타트 비트를 검출한다. 스타트 비트가 검출되면, 검출 후 10 비트의 데이터를 유효 데이터로 인지하여, SP 변환기(SPCON)에서 데이터의 인에이블(Enable)을 위한 bytesynsig 신호를 발생시킨다. 다시 말해서, 스타트 비트 1 비트, 8 비트의 데이터 비트 및 정지 비트 1 비트로 구성된 10 비트의 데이터는 래치부에서 9600 Hz로 래치(latch)되고, bytesynsig 신호에 의하여 인에이블 된다. 래치부를 통과한 데이터는 9600/10, 즉 960 Hz의 클럭에 따라 래치된 데이터가 계속 유지되지 않고 클리어 된다.
스타트 비트가 검출된 데이터는 SP 변환기(SPCON)를 통하여 10 비트의 병렬 데이터로 변환되고, 병렬 변환된 10 비트 데이터는 스타트 비트와 정지 비트를 제외한 8 비트 데이터에 대하여 MSB(Most Significant Bit) 및 LSB(Least Significant Bit)의 순서가 변환된다. 이는, 수신된 RS-232 Rx 데이터는 스타트 비트, D0 ~ D7, 및 정지 비트 순서로 수신되기 때문에, MSB와 LSB가 서로 크로스 상태에 있기 때문이다. 즉, RS-232 포트를 통하여 수신된 Q1 ~ Q8 의 데이터에서 MSB가 Q1이고 LSB가 Q8인 경우에, 비트 스트림이 변환되어 MSB는 Q7이 되고 LSB는 Q0이 된다. 따라서, 제어 시스템(300)에서 데이터를 처리하기 위해서는 이를 다시 변환해야 하기 때문에, 미리 하드웨어적으로 변환하는 것이 바람직하다.
변환된 8 비트 데이터는 직렬 1 비트의 시간 간격으로 래치되고(r9.6KHz), 직렬 10 비트의 시간 간격에 대하여 1/512 시간 폭을 갖는 인에이블 신호(En491.52K)에 의하여 출력됨으로써, 바이트 동기 및 다중화가 이루어진다. 또한, 출력된 8 비트 데이터는 FPGA에서 출력되고, RS-232 Rx 데이터를 처리하는 다른 7 개의 FPGA 들과 트라이 상태(tri-state)로 연결되어 다시 74ABT16374를 통하여 CMIA로 전송된다.
스타트 비트와 정지 비트가 정상적으로 검출되면, 8 비트 카운터(8 bit CNT)는 1 씩 증가하게 되고, 직렬 10 비트의 시간 간격에 대하여 1/512 시간 폭을 갖는 인에이블 신호(En491.52K)에 의하여 카운트 신호가 출력되어 CMIA로 전송된다. 이 신호는 CMIA에서 병렬 처리되어 전송되는 8 비트 데이터에 대한 전송 데이터의 카운트를 의미한다. 즉, 스타트 비트와 정지 비트는 8 비트 카운터의 인에이블 신호로써 사용된다. 8 비트 카운터(8 bit CNT)는 스타트 비트가 0, 정지 비트가 1인 유효 데이터에 대해서만 카운트를 하여, 512:1 인에이블 신호(49152Ken)를 이용하여 카운트 신호를 CMIA로 전송한다. 전송된 카운터 값은 CMIA에서 DMA 카운트 값으로 사용된다.
8 비트 카운터(8 bit CNT)는 256/960 us 동안 최대 256 바이트의 데이터를 전송하며, rfp 신호에 의하여 주기적으로 클리어된다.
이와 같은 방법으로 8 개의 RS-232 Rx 데이터를 처리하는 FPGA가 동작된다.
도 9는 본 발명의 오류 감시 장치에 있어서, 8 개의 FPGA를 선택하기 위한 선택 신호를 각각 나타낸 것이다. 도 9에 도시된 바와 같이, 8 개의 FPGA를 선택하기 위하여 3 비트의 선택 신호(ID0, ID1, ID2)가 요구된다.
도 10은 본 발명의 바람직한 실시예에 따른 오류 감시 장치에 있어서, RSIA의 송신용 FPGA의 내부 블록도를 나타낸 것이다.
도 10을 참조하면, 송신용 FPGA(FPGA-TX)는 CMIA로부터 RS-232 데이터를 교환기로 전송하는 기능, 루프 백(Loop back) 시험 기능 및 클럭 모니터 기능을 수행한다.
도 11은 오류 감시 장치에 있어서, 송신용 FPGA에서 루프 백 기능을 수행하기 위한 선택 신호를 나타낸 것이다. 도 11을 참조하면, 루프올(Loopall) 신호가 로우 상태(0)이면, CMIA로부터 UARTTX 신호가 TXOUT[63:0]으로 루프 백 되어지며, 루프원(Loopone) 신호가 로우 상태(0)이면, DMXSEL 신호에 의하여 선택된 송신 포트에 대해서만, 루프 백 테스트 기능을 수행한다. 루프올(Loopall) 신호와 루프원(Loopone) 신호가 모두 하이 상태(1)일 경우에는 정상적인 동작 상태이다.
또한, RSIA의 송신용 FPGA는 클럭 모니터 및 각 수신용 FPGA의 오류 상태를 감지하기 위하여, 공통적으로 monitorclkout 신호를 출력시켜서, 각 수신용 FPGA로부터 monitorclk[7:0] 신호를 수신하여 클럭을 모니터링 한다. 그리고, CMIA로부터 cpudogclk 신호를 수신하여 Framesync 신호에 대해서도 모니터링 한다. 또한, 에지 핀(Edge pin)의 상단, 중단, 하단으로부터 각각 RSIAOPEN 신호를 수신하여 PBA 오픈 상태를 감시한다. 이러한 모니터 상태에 따라 논리 조합(Combinational logic)을 통하여 PBA 기능 에러 신호를 출력한다.
도 12는 모드 상태에 따라 데이터를 수신하는 상태를 나타낸 것이다. 도 12를 참조하면, 모드 신호(mode) 신호가 로우 상태(0)인 경우에, 다운로드 케이블을 통하여 FPGA에 대하여 데이터를 다운로드받는 슬레이브 모드(slave mode)로 동작한다. 반면에, 모드 신호(mode)가 하이 상태(1)인 경우에 FPGA는 ROM(Read Only Memory)으로부터 데이터를 다운로드받는 마스터 모드(master mode)로 동작한다.
한편, CMIA는 중앙 처리부, 메모리부 및 제어부로 나눌 수 있다.
중앙 처리부는 디지털(Digital) 사의 알파(Alpha), MIPS 테크놀로지, NEC, IDT, 지멘스(Siemens) 등의 MIPS, 인텔(Intel)과 사이릭스(Cyrix), AMD 및 넥스젠(Nexgen)을 포함하는 회사의 x86 및 IBM과 모토롤라(Motorola)의 파워PC(PowerPC)와 같이 다양한 아키텍쳐(Architecture)를 갖는 프로세서일 수 있지만, 본 발명에서는 MC68360을 채용하였다.
메모리부는 일반적으로 RAM(Random Access Memory) 과 ROM(Read Only Memory) 같은 저장 매체 형태인 고속의 메인 메모리와, 플로피 디스크, 하드 디스크, 테이프, CD-ROM, 플래시 메모리 등의 장기(long-term) 저장 매체 형태의 보조 저장 장치 및 전기, 자기, 광학이나 그 밖의 저장 매체를 이용하여 데이터를 저장하는 장치를 포함할 수 있다. 또한, 메인 메모리는 디스플레이 장치를 통하여 이미지를 디스플레이 하는 비디오 디스플레이 메모리를 포함할 수 있다.
본 발명에서는 도 13에 도시된 바와 같이, 512K 비트 의 ROM을 두 개 사용하거나, 1M 비트 ROM을 하나 사용하고, 64K 바이트의 SRAM(Static RAM), 프로그램 다운로드용 256K 바이트의 SRAM, RSIA로부터 RS-232 Rx 데이터 처리를 위해 더블 버퍼링(Double Buffering)으로 동작되는 128K 바이트 용량의 SRAM 두 개 및 전송된 데이터의 카운트 값을 저장하기 위한 2K 바이트 용량의 DPRAM(Dual Port RAM)로 구성된다.
제어부는 더블 버퍼링, DPRAM 제어, RSIA 기능 오류 수집 및 RS-232 전송을 위한 디멀티플렉싱 선택 신호 등을 생성할 수 있도록 FPGA로 구성된다.
RSIA는 교환기(100)로부터 512 포트의 RS-232 Rx 에 대하여, 이를 8 비트의 병렬 데이터로 변환하고 다중화하여, CMIA로 전송한다. CMIA는 이를 HDLC 포맷으로 변환하여 이더넷을 통하여 제어 시스템(300)으로 제공한다. 또한, CMIA는 제어 시스템(300)으로부터 교환기(100)로 전송할 데이터를 이더넷으로 수신하고, 이를 RS-232 방식의 데이터로 디코딩하여 RSIA로 전송한다.
이 때, CMIA는 1 프레임의 동기 동안 128K 바이트(512 포트 × 256 바이트)의 데이터를 처리할 수 있도록 설계되었다. 즉, 프레임 동기는 1/960 us × 256 바이트의 시간 간격을 가지며, 하나의 포트는 1/(960 Hz × 512) = 2.0345 us 의 주기(491.52 KHz)를 갖는다.
또한, CMIA는 8 개의 RSIA로부터 각각 64 포트 × 256 바이트가 다중화된 8 비트 병렬 데이터와, 이 데이터에 대한 전송 카운트 값을 제공받는다. RSIA로부터 전송된 데이터는 각각 128K 바이트(1M 비트)의 용량을 가지는 2 개의 SRAM을 통하여 더블 버퍼링이 이루어진다. 먼저, 상위 버퍼에 데이터를 연속으로 기록(Sequential write)하는 동작에서는 하위 버퍼를 통하여 데이터가 랜덤하게 읽혀지며, 하위 버퍼에 데이터를 연속으로 기록하는 동작에서는 상위 버퍼를 통하여 데이터 랜덤하게 읽혀진다. 이 때, 각 포트는 256 바이트의 크기를 가진다.
도 14a 및 도 14b는 각각 더블 버퍼 0 과 더블 버퍼 1에 대한 각 포트의 어드레스를 나타낸 것이다. 도 14a 및 도 14b를 참조하면, 상위 DBUFFER0 인 경우에는 200,000에서 시작되며, 하위 DBUFFER1인 경우에는 220,000에서 시작되도록 구성된다. 또한, 각 포트의 연속 기록 어드레스는 Base Address[7:0] + addcount[7:0]으로 구성되어 있다.
도 15는 본 발명의 오류 감시 장치에 있어서, DPRAM의 메모리 맵을 나타낸 것이다. 도 15를 참조하면, 2K 바이트의 DPRAM은 1 프레임 동기 동안 전송된 각 포트의 전송 바이트 수를 저장하기 위한 것이다. DPRAM 또한 마찬가지로, 연속 쓰기 랜덤 읽기(sequential write random read)로 동작되며, 왼쪽 포트를 통해 쓰기 동작이 수행되고, 오른쪽 포트를 통하여 읽기 동작이 수행된다.
DPRAM의 왼쪽 포트는 Base Address[8:0]이 어드레스가 되고, addcount가 데이터가 되어 DPRAM에 기록된다. 즉, 각 포트에 대하여 몇 바이트의 데이터가 전송되었는지를 알려주기 위하여 전송된 카운트 값이 DPRAM에 저장된다.
전송 데이터에 대한 DBUFFER0 과 DBUFFER1, 전송 데이터 카운트 값에 대한 DPRAM의 동작을 자세히 살펴보자.
먼저, RSIA는 Frame sync 신호에 동기되어, 각 포트의 데이터와 카운트 값을 CMIA로 전송한다. CMIA는 순차적으로 데이터를 DBUFFER에 저장하고, 카운트 값은 DPRAM에 저장된다. 이와 같이, 1 프레임에 대한 쓰기 동작이 완료되면, 인터럽트(Interrupt)를 발생시켜서 중앙 처리부에서 각 포트에 대해 전송된 카운트만큼 읽기 동작을 수행한다. DBUFFER0 와 DBUFFER1은 쌍으로 동작되는 더블 버퍼이기 때문에, 상위 버퍼 DBUFFER0에 연속 기록을 수행하는 경우에는 하위 버퍼 DBUFFER1에 랜덤 읽기 동작을 수행할 수 있도록 인터럽트 6을 발생시킨다. 인터럽트가 발생하면 중앙 처리부는 DPRAM에서 각 포트에 전송된 데이터 카운트 값을 읽어 들이고, 카운트 값만큼 DBUFFER0 으로부터 데이터를 읽어 온다. 그런 다음, HDLC 포맷으로 변환하고, RS-422 방식으로 제어 시스템(300)에 전송한다.
이와 같은 방법으로, 각 포트에 대하여 1/960 us 동안 최대 256 바이트의 데이터를 전송한다. 즉, 256/960 us 동안 512 포트에 대하여 최대 512 × 256 바이트 = 128K 바이트의 데이터를 제어 시스템(300)으로 전송한다.
비슷하게, 하위 버퍼 DBUFFER1에 대한 연속 기록 과정에서 상위 버퍼 DBUFFER0에 대한 랜덤 읽기 동작을 수행하기 위하여, 인터럽트 7이 발생되고, 그 동작은 상기에서 설명한 방법과 동일하다.
또한, 제어 시스템(300)으로부터 이더넷을 통하여 수신된 데이터는 중앙 처리부의 MC68360을 이용하여 스타트 비트 1 비트, 데이터 비트 8 비트, 정지 비트 1 비트의 형태로 데이터와 데이터의 어드레스를 RSIA로 전송한다. 또한, CMIA는 RSIA의 PBA 오픈 및 RSIA의 기능 오류 상태를 FPGA로부터 읽어들인다.
도 16은 본 발명의 바람직한 실시예에 따른 오류 감시 장치의 운용 방법을 나타내는 흐름도이다. 도 16을 참조하여, 본 발명의 오류 감시 장치 운용 방법을 살펴보면 다음과 같다.
본 발명의 오류 감시 장치를 운용하기 위한 운용 프로그램은 오류 감시 장치 내부에 설치될 수 있고, 오류 감시 장치에 연결된 제어 시스템에 설치될 수도 있다. 여기에서는 오류 감시 장치에 연결된 별도의 제어 시스템에 운용 프로그램을 설치하고, 이를 이용하는 경우를 살펴보기로 한다.
제어 시스템은 일반적인 개인 컴퓨터 또는 워크 스테이션(Workstation)과 같은 컴퓨터 시스템일 것이다. 운용자는 오류 감시 장치 또는 제어 시스템에 설치된 운용 프로그램을 이용하여 오류 감시 장치의 각 포트에서 출력되는 오류 메시지를 감시하고, 이를 분석하여 적절한 방법으로 프로세서를 제어하거나 교환기 관리자에게 이를 통보할 수 있다.
먼저 교환기와 제어 시스템 사이에 오류 감시 장치를 설치하고, 운용자는 제어 시스템에 오류 감시 장치를 제어할 수 있는 운용 프로그램을 설치한다. 운용자는 제어 시스템에서 운용 프로그램을 실행하여(s10), 운용 프로그램을 초기 설정을 조절할 수 있다.
도 17은 본 발명의 오류 감시 장치의 운용 방법에 있어서, 운용 프로그램을 실행한 경우의 초기 화면을 나타낸 것이다. 도 17을 참조하면, 운용 프로그램은 시스템 제어, 메시지 검색, 프로세서 제어, IPC LOG 제어 및 원격 운용자 단말 기능을 이용하기 위한 메뉴를 제공한다. 운용 프로그램의 초기 설치 과정에서는 교환기 내부의 프로세서에 대한 정보 및 오류 감시 장치의 각 포트에 대한 정보를 설정할 것이다. 이 때, 오류 감시 장치를 통하여 포트에서 수집되는 메시지는 포트 설정 정보를 기본으로 하여 운용되고, 설정된 정보가 없는 포트에서 수집된 메시지는 운용 프로그램에서 제공하는 포트 번호에 대한 정보에 의하여 처리가 이루어질 것이다.
운용 프로그램의 초기 실행 과정에서 운용자는 오류 감시 장치에 설치된 포트에 대한 정보를 각각 설정할 것이다(s12).
도 18a 내지 도 18c는 본 발명의 바람직한 실시예에 따른 오류 감시 장치 운용 방법에 있어서, 운용 프로그램을 통하여 오류 감시 장치의 각 포트에 대한 정보를 설정하는 과정의 화면 예시도이다. 먼저, 도 18a를 참조하면, 운용자는 각 포트에 대한 기본 정보를 설정하거나 변경할 수 있고, 포트에 설정된 정보를 화면을 통하여 출력할 수 있다. 즉, 운용 프로그램을 정상적으로 운용하기 위해서는 오류 감시 장치의 포트에 대한 정보 설정이 우선적으로 이루어져야 하는 것이다.
이 때, 오류 감시 장치의 포트와 교환기 프로세서의 연결은 RS-232C, LAN(Local Area Network) 또는 TTL 정합으로 이루어질 것이다.
도 18b는 운용 프로그램에서 운용자가 오류 감시 장치의 포트에 대하여, 교환기 프로세서 정보를 입력하기 위한 화면의 예시도이다.
운용자는 각 포트에 대하여, RSIA 카드 번호와 RSIA 카드의 포트를 지정하고, 교환기 내부의 프로세서를 선택하여 해당하는 포트에 대한 정보를 입력한다. 운용자는 각 포트를 통하여 수집되는 정보를 분류, 저장 및 분석함으로써, 교환기 내부의 각 프로세서를 감시한다. 이 때, 오류 감시 장치의 포트에 대한 운용자의 입력 정보는 교환기의 메시지 수집에 이용된다.
운용자가 입력한 포트에 대한 정보 및 교환기 내부의 프로세서에 대한 정보는 포트 설정 현황 화면에 출력되어, 운용자는 이를 직접 확인할 수 있다.
도 18c는 운용자가 오류 감시 장치에 설치된 포트에 각각 설정된 프로세서 정보를 출력하는 화면 예시도이다. 운용자는 RSIA 카드 또는 교환기의 서브 시스템을 지정함으로써, 여기에 할당된 포트 정보를 선택한 방법에 따라 출력할 수 있다.
운용자는 포트 설정/변경 제어 화면을 이용하여 새로운 포트를 지정하거나 설정된 정보를 변경할 수 있다.
운용자는 오류 감시 장치의 각 포트에 대한 설정 정보를 이용하여 해당하는 교환기 내부의 프로세서를 모니터링하고(s14), 각 프로세서를 통하여 출력되는 메시지를 각 저장할 수 있다(s16). 운용자는 교환기 내부의 프로세서로부터 출력된 메시지를 분석하여, 오류가 발생하는 경우의 프로세서 상태를 분석할 것이다(s18). 이 때, 교환기 내부의 프로세서에서 출력되는 오류 메시지가 과거에 발생한 오류 메시지와 동일한 경우에는 동일 오류로 판단하여 쉽게 오류를 수정할 수 있을 것이다. 따라서, 교환기 내부의 프로세서에서 출력되는 오류 메시지는 이를 메모리부에 모두 저장해 두었다고, 필요에 따라 추출하여 이용하는 것이 바람직하다.
또한, 운용자는 교환기 내부 프로세서의 오류 메시지 또는 분석 결과를 화면을 통하여 출력함으로써(s20) 이를 확인할 수 있다.
도 19a 및 도 19b는 본 발명의 바람직한 실시예에 따른 오류 감시 장치를 운용하는 방법에 있어서, 운용자가 교환기 내부의 프로세서로부터 수집한 메시지를 확인하는 과정의 화면 예시도를 나타낸 것이다. 도 19a를 참조하면, 운용자는 오류 감시 장치를 통하여 수집한 메시지를 검색하기 위하여 이를 제어하는 화면을 열 수 있다. 이 때, 운용 프로그램은 제어 시스템에 저장된 메시지의 용량을 분석하여, 사용 가능한 메모리 공간을 운용자에게 알려줄 수 있다.
도 19b를 참조하면, 운용자는 오류 감시 장치를 통하여 수집/분석된 메시지를 화면에 출력할 수 있다. 즉, 운용자는 교환기 내부의 프로세서를 지정하거나 오류 감시 장치의 포트를 지정한 후에, 검색하고자 하는 날짜와 시간 정보를 입력함으로써, 저장된 메시지를 확인할 수 있다. 이 때, 검색된 메시지는 프린터와 같은 출력 장치를 이용하여 인쇄할 수 있으며, 출력 가능한 메시지의 크기는 충분히 확장 가능할 것이다.
오류 감시 장치의 포트를 통하여 수집된 프로세서에 관한 메시지가 정상 상태의 메시지인 경우에는 해당 프로세서를 모니터링 하는 과정을 계속적으로 반복할 것이다. 반면에, 교환기 내부의 프로세서로부터 오류 메시지가 발생하는 경우에는 오류 메시지와 해당하는 제어 방법을 교환기 프로세서의 관리자에게 제공할 것이다(s24).
한편, 오류 감시 장치의 운용 프로그램은 그 자체에 교환기 프로세서를 제어할 수 있는 기능을 구비함으로써, 프로세서 관리자의 요청이 있는 경우에 운용 프로그램에 의하여 교환기 내부의 프로세서 동작을 제어할 수 있을 것이다(s26).
도 20a 및 도 20b는 본 발명의 바람직한 실시예에 따른 오류 감시 장치의 운용 방법에 있어서, 운용자가 교환기 내부의 프로세서를 제어하는 경우의 화면 예시도를 나타낸 것이다.
먼저, 도 20a를 참조하면, 운용 프로그램은 교환기의 각 프로세서를 서브 시스템별로 설정할 수 있는 기능과, 운용자에게 더미 터미널을 제공하는 기능, 수집된 메시지의 출력 상태를 감시할 수 있는 기능을 제공한다. 그에 따라, 운용자는 수집된 메시지의 분석에 의한 프로세서의 상태를 확인할 수 있다.
또한, 운용 프로그램은 제어 시스템을 통하여 교환기 내부의 프로세서 중에서 비정상 상태에 있는 프로세서를 리셋시키는 기능을 포함할 수 있다.
도 20b를 참조하면, 운용자는 교환기 내부의 프로세서 또는 서브 시스템에 대한 정보를 각각 확인할 수 있다. 즉, 운용자가 교환기의 서브 시스템 타입(type)을 입력하면, 오류 감시 장치의 포트에 연결된 프로세서 또는 서브 시스템의 정보를 확인할 수 있다. 이 때, 운용자는 교환기에 설치되어 있지 않은 프로세서를 삭제할 수 있다.
또한, 운용자가 교환기 내부의 프로세서 연결 화면을 통하여 운용자가 확인하고자 하는 프로세서를 선택하면, 운용 프로그램은 해당하는 프로세서를 모니터링 할 수 있는 화면을 제공할 것이다. 이를 통하여, 운용자는 해당하는 프로세서를 직접 제어할 수도 있다.
한편, 운용자가 화면에서 명령어를 입력하면, 운용 프로그램은 해당하는 명령을 교환기 내부의 프로세서에 전송할 수 있다. 예컨대, 운용자는 비정상 상태의 교환기 프로세서를 리셋할 수 있다. 또한, 운용 프로그램은 운용자의 요구에 따라 프로세서에 대한 정보를 화면으로 출력할 수 있다.
그리고, 운용자는 프로세서 해제 화면을 통하여 교환기 내부의 프로세서 연결 화면을 해제할 수 있다. 운용 프로그램은 교환기 내부의 프로세서 상태 출력 화면을 통하여 수집된 메시지의 분석 결과, 교환기 내부의 프로세서 또는 서브 시스템의 상태를 출력할 수 있다. 프로세서의 상태는 정상 상태 및 비정상 상태로 구분할 수 있으며, 비정상 상태는 다운 상태, OS(Operating System) 로딩(loading) 상태, 사용자 로딩 상태, IPC 통신 두절 상태 및 루프 상태로 구분할 수 있을 것이다.
운용 프로그램은 운용자의 요청에 딸 비정상 상태에 있는 프로세서를 리셋시킬 수 있다. 즉, 운용자가 화면에서 입력하는 명령어를 수신하여 해당하는 프로세서로 전송하고, 프로세서에서 출력하는 메시지를 실시간으로 화면에 출력한다. 이 때, 프로세서의 리셋 기능은 프로세서 및 프로세서 내부의 서브 시스템을 그 대상으로 할 수 있다.
도 21a 내지 도 21e는 본 발명의 바람직한 실시예에 따른 오류 감시 장치의 운용 방법에 있어서, IPC 로그 제어 화면을 나타낸 것이다.
도 21a를 참조하면, 운용자는 IPC 로그 시험을 위한 화면을 열고, 정보를 입력할 수 있다. 운용 프로그램은 입력된 정보에 따라 IPC 로그 시험을 수행하여 그 결과를 출력하고, 시험 결과에 따라 경보를 발생하는 기능을 포함할 수 있다. 이 때, 운용자는 경보 등급 비율을 조정할 수 있다. 이 때, IPC 로그 기능은 프로세서가 정상 상태인 경우에 가능한 것으로, 운용자는 프로세서 연결 화면을 통하여 직접 IPC 로그 시험을 할 수 있으며, 결과에 따라 경보가 발생된다.
도 21b를 참조하면, 프로세서의 IPC 로그 시험을 위하여 운용자는 필요한 정보를 입력하거나, 입력된 정보를 변경할 수 있다. 입력 정보 또는 변경된 정보는 설정된 시간 이후에 유효하며, 정보를 변경하는 순간에 IPC 로그 시험을 수행하고 있는 프로세서에게는 변경 내용이 해당되지 않을 것이다.
운용자가 IPC 로그 시험을 위한 정보를 입력하면, 입력 정보에 따라 시험 기능을 수행하며, 운용자가 시험 주기를 지정하면, 지정된 시간만큼의 간격을 두고 IPC 로그 시험이 이루어질 것이다. 이 때, 시험 주기는 최소 10분에서 최대 24시간 사이로 하는 것이 바람직하다. 이러한 IPC 로그 시험 기능은 하나의 프로세서에만 한정되지 않고, 동시에 복수의 프로세서에도 적용할 수 있다.
도 21c는 IPC 로그 시험 정보를 출력하기 위한 화면이다. 운용자가 특정 프로세서를 선택하면, 선택된 프로세서의 IPC 로그 시험에 대한 등록 정보가 출력된다. 운용자는 프로세서를 선택하여, 즉석 IPC 로그 시험을 수행할 수 있다.
도 21d는 IPC 로그 시험에 따른 결과를 출력하는 화면이다. 운용자는 프로세서의 IPC 로그 시험 결과를 확인하기 위하여, 서브 시스템 또는 프로세서 정보를 지정한다. IPC 로그 시험 결과에 따라, 운용자는 해당 프로세서에 대한 정상 상태를 파악하고, 결과에 따른 조치를 취할 것이다. 예컨대, 운용 프로그램은 오류가 발생한 프로세서의 관리자에게 오류에 대한 경보를 발생하고, 해당 프로세서의 상태를 정상 상태로 변경할 수 있다.
도 21e는 프로세서의 IPC 로그 시험 결과에 따라, 해당하는 프로세서의 관리자에게 발생할 경보를 제어하는 화면이다. 운용자는 각 프로세서에 대한 IPC 로그 시험 결과에 따라 발생 경보에 관한 정보를 입력한다. 즉, 운용자는 오류 상태에 따라 크리티컬 경보(Critical alarm), 메이저 경보(major alarm) 또는 마이너 경보(minor alarm)로 나눌 수 있다.
도 22는 본 발명의 바람직한 실시예에 따른 오류 감시 장치의 운용 방법에 있어서, 운용자가 교환기의 입출력 메시지를 감시하는 경우의 화면 예시도이다. 도 22를 참조하면, 운용자는 제어 시스템을 통하여 하나 이상의 교환기에 대한 모니터링이 가능하다.
상기에서는 교환기의 경우를 예로 들어 설명하였지만, 본 발명의 오류 감시 장치는 교환기의 경우에만 한정되지 않고, 일반적인 통신 장치에도 모두 적용 가능한 것은 자명할 것이다.