KR100433007B1 - 실행중인통신프로그램중단없이전기통신스위치내부의소프트웨어를변경하는방법및장치 - Google Patents

Abstract

전기통신 스위치(104)내에서 시스템을 재작동시키지 않고 구소프트웨어 버전을 신소프트웨어 버전으로 교체하는 시스템 및 방법. 스위치는 기억장치(110), 소프트웨어 로딩 서브시스템(390), 데이터베이스 관리 서브시스템(124), 그리고 프로그램 교환 서브시스템(394)을 포함하고 있다. 신소프트웨어 버전은 소프트웨어 로딩 서브시스템을 사용하여 신소프트웨어 버전을 스위치의 기억장치 속으로 올림으로써 구소프트웨어 버전을 교체한다. 신소프트웨어 버전은 데이터베이스 관리 서브시스템을 사용하여 프로그램 교환 서브시스템에 등록된다. 구소프트웨어 버전은 무력화되고 신소프트웨어 버전은 프로그램 교환 서브시스템을 사용하여 활성화되고, 그에 의해 구소프트웨어 버전을 신소프트웨어 버전으로 교체된다.

Description

실행중인 통신프로그램을 중단없이 전기통신 스위치 내부의 소프트웨어를 변경하는 방법 및 장치

본 발명은 전기통신 스위치(a telecommunication switch)내에서 소프트웨어를 갱신하는 것으로서, 특히, 본 발명은 전기통신 스위치를 재시작하는 일이 없이 구소프트웨어 버전을 신소프트웨어 버전으로 변경함으로써 구소프트웨어를 갱신하는 방법 및 그 장치에 관한 것이다.

현대의 전기통신산업에서 컴퓨터 소프트웨어는 전기통신 스위치 내에서 호출을 처리하는 여러가지 특징들을 제어하는데 사용되고 있다. 그러나 불행하게도 전기통신 소프트웨어, 그리고 다른 형태의 소프트웨어에는 오류나 원하지 않는 응답이 자주 나타난다. 오류나 원하지 않는 응답들을 결함이 있는 버전을 치유하는데 사용하는 새로운 버전의 소프트웨어로 정정된다.

독립형(standalone)이나 일괄처리 시스템(batch processing system)과 같은 소정 유형의 컴퓨터 시스템에서는, 구 버전의 소프트웨어를 새로운 버전의 소프트웨어로 교환할 때 별로 애로사항이 없다. 전형적으로, 활동을 거의 하지 않아 유지보수요원이 쉽게 이용할 수 있는 하루 중의 소정 기간 중에 단순히 컴퓨터를 끈다. 그런 다음에, 구소프트웨어를 제거하고 새로운 버전으로 교체한다. 그 다음에 컴퓨터를 다시 켜고 모든 장래의 데이터를 새로운 버전의 소프트웨어로 처리한다.

현대의 프로그램 내장(SPC) 전기 통신교환시스템(산업계에서는 단순히 스위치라고 한다)과 같은 다른 유형의 컴퓨터 시스템에서는, 시스템의 소프트웨어를 교체하는 것은 독립형의 일괄처리 시스템에서와 같이 간단하지 않다.

전기통신 스위치는 지역사회에서 전기통신 서비스를 지속적으로 제공하기 위해 중단없이 영구히 작동할 수 있도록 설계된다. 다시 말하면, 전기통신 트래픽의 흐름은 업무시간이 끝나도, 밤에도 끊기지 않도록 스위치가 처리해야 한다. 스위치가 작동 중에 소정의 중단(인터럽션)이 있으면 결국 스위치에서 전기통신의 트래픽을 혼란스럽게 만들고 이러한 혼란은 전기통신산업에서 매우 못마땅한 노릇이다.

전기통신 스위치에는 실시간(real-time)이 필요하기 때문에, 스위치가 처리하고 있는 현재의 전기통신 트래픽을 중단하는 일이 없이 구 버전의 소프트웨어를 에러 정정 또는 "버그 치유"를 포함하는 새로운 버전의 소프트웨어로 교체함에 있어서 심한 제약이 따른다. 비가동 시간 없이 동작 중에 스위치 내에서 소프트웨어를 교환할 수 있는 능력을 제공하는 시스템과 방법을 가지는 것이 전기통신산업에서 가장 필요하다.

그러므로, 스위치 내에서 진행중인 전기통신 트래픽을 중단하는 일이 없이 전기 통신스위치 실제 동작 중에 소프트웨어를 교환할 수 있는 것이 전기통신 산업에서 가장 유용하다.

도 1은 본 발명의 바람직한 실시예에서 채용된 전기통신 스위치와 컴퓨터 시스템을 나타내는 블록도.

도 2는 본 발명의 바람직한 실시예에 따른 도 1의 전기통신 스위치 기억장치의 프로그램 저장 영역, 참조 저장 영역, 데이터 저장 영역을 위한 구조와 내용을 매우 상세하게 나타내는 블록도.

도 3은 본 발명의 바람직한 실시예에 따른 도 1의 전기통신 스위치 내에서 프로그램에 의한 교환(PXCP)서브시스템의 구성요소들과 그 구성요소들이 소프트웨어 로딩 서브 시스템(software loading subsystem)과 로딩 중앙 처리 서브시스템(loading central processor subsystem)의 구성요소들과 상호작용하는 것을 나타내는 블록도.

도 4는 본 발명의 바람직한 실시예에 따른 도 1의 스위치 내에서 구 소프트웨어 유닛을 신소프트웨어 유닛으로 교환하는 프로그램 교환 방법의 단계들을 나타내는 흐름도.

도 5는 본 발명의 바람직한 실시예에 따른 도 4에서 신소프트웨어 유닛을 등록하는 단계를 매우 자세히 나타내는 흐름도.

도 6A, 6B는 본 발명의 바람직한 실시예에 따른 도 4에서 신 소프트웨어 유닛을 활성화시키는 단계를 매우 자세히 나타내는 흐름도.

도 7은 본 발명의 바람직한 실시예에 따른 도 4에서 신 소프트웨어 유닛을 확인하는 단계를 매우 자세히 나타내는 흐름도.

도 8A, 8B는 본 발명의 바람직한 실시예에 따른 제4도에서 신 소프트웨어 유닛을 보증하는 단계를 매우 자세히 나타내는 흐름도.

도 9A, 9B는 본 발명의 바람직한 실시예에 따른 도 4에서 구 소프트웨어 유닛을 비활성화시키는 단계를 매우 자세히 나타내는 흐름도.

도 10A, 10B는 본 발명의 바람직한 실시예에 따른 도 4에서 구 소프트웨어 유닛을 제거하는 단계를 매우 자세히 나타내는 흐름도.

도 11은 본 발명의 프로그램 교환 방법을 통하여 신소프트웨어 유닛을 교환할 때에 여러 가지 다양한 새로운 소프트웨어 유닛의 프로그램 교환 상태들을 설명하는 블록도.

본 발명의 목적은 전기통신 스위치 내에서 구소프트웨어를 새소프트웨어로교체할 때 스위치를 재작동시키지 않고 교체할 수 있는 방법과 장치를 제공하는 것이다.

다른 측면에서는, 본 발명은 전기통신 스위치 내에서 구소프트웨어 버전을 새로운 소프트웨어 버전으로 교체할 때 스위치를 재작동시키지 않고 교체할 수 있는 방법이다. 이 스위치는 기억장치(memory), 소프트웨어 로딩 서브시스템(software loading subsystem), 데이터베이스를 관리하는 서브시스템(database management subsystem) 그리고 프로그램을 교체하는 서브시스템(program exchange subsystem)을 포함한다. 이 방법은 몇 가지 단계, 즉 새 버전의 소프트웨어를 소프트웨어 로딩 서브시스템으로 기억장치에 로딩하는 단계와, 데이터베이스 관리 서브시스템으로 프로그램 교환 서브시스템에 신소프트웨어를 등록시키는 단계를 포함한다. 이 방법은 또한 프로그램 교환 서브시스템으로 구소프트웨어 번전을 비활성화시키고, 등록된 신 소프트웨어 버전을 활성화시키는 단계들을 포함한다.

또 다른 측면에서는, 본 발명은 전기통신 스위치 내에서 구소프트웨어 버전을 새소프트웨어 버전으로 교체할 때 스위치를 재작동 시키지 않고 교체할 수 있는 방법이다. 이 스위치는 기억장치, 소프트웨어 로딩 서브시스템(software loading subsystem), 데이터베이스를 관리하는 서브시스템(database management subsystem)그리고 프로그램을 교체하는 서브시스템(program exchange subsystem)을 포함한다. 이 방법은 몇 가지 단계, 즉 신 소프트웨어 버전을 소프트웨어 로딩 서브시스템으로 기억장치에 로딩하는 단계, 데이터베이스 관리 서브시스템을 사용하여 프로그램 교환 서브시스템에 신 소프트웨어 버전을 등록시키는 단계를 포함한다. 이 방법은 또한 프로그램 교환 서브시스템으로 구소프트웨어 버전을 비활성화시키고, 등록된 신 소프트웨어 버전을 활성화시키는 단계들을 포함한다. 이 방법은 또한 프로그램 교환 서브시스템으로 신소프트웨어가 활성화된 것을 확인하는 단계, 프로그램 교환 서브시스템으로 신소프트웨어가 활성화된 것임을 보증한 것을 증명하는 단계를 포함한다.

본 발명의 기술분야에서 통상의 지식을 가진 사람은 다음의 도면들, 그리고 이와 첨부하는 상세한 설명을 참조하면 본 발명을 더욱 잘 이해하고 본 발명의 여러 가지 목적과 장점들이 분명해질 것이다.

도 1을 참조하여 보면, 본발명의 바람직한 실시예에 사용하는 전기통신 스위치(104)와 컴퓨터 시스템(102)을 설명하는 블록도가 도시되어 있다. 스위치(104)는 저장장치(storage device, 110), 소프트웨어(software, 108), 하드웨어(hardware, 106), 기억장치(memory, 122), 그리고 데이터베이스 관리 서브시스템[a database management subsystem(DBS), 124]를 포함한다. 스위치(104)는 스웨덴의 텔레포나 크리에볼라 케트 엘엠 에릭슨이 생산하는 AXE 10과 같은 저장된 프로그램으로 제어되는 스위치일 수 있다. 저장장치(110)는 플로피 드라이브, 하드 드라이브, 자기 테입 드라이브, 또는 광디스크 드라이브 같은 것일 수 있다.

도 2에 아주 자세히 도시된 바와 같이, 기억장치(122)는 데이터 저장[Data Storage(DS)]영역(206)과 참조 저장[Reference Storage(RS)]영역(204), 그리고 프로그램 저장[Program Storage(PS)]영역(202)으로 나누어진다. 소프트웨어(108)는 저장장치(110)에서 기억장치(122)로 로딩되고, PS영역(202), DS영역(206), RS영역(204)의 각각에 상주한다. 소프트웨어(108)는 통신경로(112, 114)를 통해 하드웨어(106)를 제어하는데 사용된다(도 1). 컴퓨터 시스템(102)은 통신경로(116)를 통해 스위치(104)와 통신한다. 컴퓨터 시스템(102)은 개인용 컴퓨터, 유지보수용 중앙컴퓨터, 네트웍 관리 중앙컴퓨터, 또는 다른 엇비슷한 유형의 시스템일 수 있다. 데이터베이스 관리 서브시스템(DBS, 124)은 반 관계형 데이터베이스 관리 시스템과 같은 것일 수 있다.

도 2를 살펴보면, 본 발명의 바람직한 실시예에 따라 도 1의 기억장치(122)의 PS영역(202), RS영역(204), 그리고 DS영역(206)의 각각의 구조와 내용을 자세히 보여주는 블록도가 도시되어 있다. 프로그램 저장영역(PS, 202)은 여러 개의 기능블록(컴퓨터 프로그램이며 각각은 고유의 식별번호로 식별된다)을 저장하는데 사용된다. PS영역(202)에 저장된 프로그램은 각각 그것들과 관련된 변수와 같은 데이터를가질 수 있다. PS영역(202)에 저장된 기능 블록이 참조하는 변수들은 DS영역(206)에 독립적으로 저장된다. DS영역(206)에 저장된 각각의 변수는 고유한 변수 식별번호로 식별할 수 있다. 참조 저장영역(RS, 204)은 PS영역(202)에 저장된 기능 블록의 위치와 DS영역(206)에 저장된 그들의 관련 변수의 위치를 결정하는데 사용된다.

RS영역(204)은 여러 개의 참조표(reference table)와 기초표(base table)들을 사용하는데, 이는 PS영역(202)에 저장된 기능 블록의 위치와 DS영역(206)에 저장된 관련 변수들의 위치를 찾아내기 위한 것이다. PS영역(202)에 저장되는 각 기능 블록은 각각 RS영역(204)내에 관련 참조표를 갖고 있고 이는 기능 블록의 고유식별번호에 따라 색인되어 있다. PS영역(202)내의 소정 기능 블록에 의해 사용되는 각각의 변수는 DS영역(206)내에서 기본 어드레스표(a Base Address Table, BAT)에 규정된 그의 위치를 갖는다. 참조표(a reference table)는 프로그램 시작 어드레스(a Program Start Address, PSA)와 기본 시작 어드레스(a Base Start Address, BSA)를 포함하고 있다. PSA는 PS영역(202)에 저장된 관련 기능 블록의 시작 어드레스를 표시한다. BSA는 BAT(기능 블록과 연관되며 RS영역에 저장되어 있다)의 위치를 표시한다.

신호 분산표(a Signal Distribution Table, SDT)는 PS영역(202)에 저장된 각 기능 블록의 시작 어드레스에 있다. SDT는 기능 블록 내에서 태스크(진행내용/기능)을 수행하기 위한 위치를 규정하고 있다. 기능 블록(208)과 그것의 관련 표와 변수의 예를 도 2에서 보여준다. 기능 블록(208)은 PS영역(202)에 저장되며, 기능블록 #1으로 식별된다. SDT(210)는 기능 블록(208)의 시작 어드레스에 자리잡으며, 기능 블록(208)내에서 일정한 태스크를 찾아내기 위해 채용되었다. 기능 블록(208)은 RS영역(204)내에 관련 참조표(212)를 갖는다. 참조표(212)는 RS영역(204)내에서 기능 블록 #1으로 색인되어 있다. 참조표(212)는 PSA(220)와 BSA(222)을 포함하고 있다. PSA(220)는 기능 블록(208)을 대한 시작 어드레스를 식별한다. BSA(222)는 RS영역 (204)내에 저장된 BAT(224)의 위치를 식별해 낸다. BAT(224)는 기능 블록(208)에 의해 사용되는 변수들의 위치를 식별해 낸다. 그 변수들은 예를 들면 변수상태(variable state)(214), Distinct(216), 그리고 Mup(218)와 같은 것들이다.

다음에는 기능 블록(208)내에서 규정된 태스크를 어떻게 시작시킬 수 있는지를 보여주는 사례에 대해 설명한다. 우선 RS영역(204)에 액세스하여 기능 블록 #1에 의해 색인된 참조표가 있는지 검색한다. 이 특정 사례에서는, 참조표(212)가 검색 조건에 부합한다. 다음에 PSA(220)가 기능 블록(208)에 대한 시작 어드레스의 위치를 찾아내는데 사용된다. 시작 어드레스는 규정된 태스크와 관련하여, SDT(210)에 액세스하여 규정된 태스크를 시작시키는데 사용된다. 규정된 태스크를 실행하는 동안에, 기능 블록(208)은 변수상태[variable state](214), Distinct(216), 또는 Mup(218)]을 사용을 필요로 한다. 만약 기능 블록(208)이 변수들을 사용을 필요로 한다면, 기능 블록(208)은 DS영역(206)내에서 변수들의 위치를 결정하기 위해 BAT(224)에 액세스하는데 BSA(222)를 사용한다.

도 3을 참조하여 보면, 본 발명의 적절한 실시예에 따른 제1도의 스위치 내에서 프로그램 교환 서브시스템(PXCP, 394)의 구성요소들과, 소프트웨어 로딩 서브시스템(CPS, 390)과, 그리고 로딩 중앙 처리 서브시스템(LOCP, 392)의 구성요소들과의 그들의 상호작용을 나타낸다. PXCP(394)는 프로그램 교환 관리자(a program exchange administrator=PXZA, 320), 프로그램 교환 데이터 차이 처리기(a program exchange data difference handler=PXZD, 318), 프로그램 교환 신호 차이 처리기(a program exchange signal difference handler=PXZS, 316), 그리고 프로그램 교환 기계 종속 경로(a program exchange machine dependent routine=PXZMD, 314)의 구성요소를 포함하고 있다. PXCP(394)는 다음과 같은 CPS(390) 구성요소들과 통신한다. 즉, 감사 기능 제어기(an audit function controller=AFCO, 302), 프로그램 테스트 모니터(a program test monitor=TEM, 304), 로딩 관리자 참조 정보 처리기(a loading administrator reference information handler=LARI, 308) 그리고 시스템 사건 정보 동보통신기(a system event information broadcaster=KEED, 306)의 구성요소들이다. 또한 PXCP(394) 다음의 LOCP(302) 구성요소들, 즉 로딩 관리 제어기(a loading administration controller=LACO, 310)와 로딩 관리 심볼 처리기(a loading administration symbol handler=LASYMB, 312)의 구성요소들과 통신한다. PXCP(394)의 각 구성요소들과, CPS(390)과 LOCP(392)의 구성요소들과 그들의 상호작용 내용을 다음에 간략하게 설명한다.

PXZA(320)은 프로그램 교환 실시를 조정한다. PXZA(320)는 PXZD(318), PXZS(316), KEED(306), PXZMD(314), 그리고 LACO(310)과 양방향 논리 경로(324, 326, 348, 328, 그리고 322)를 통해 직접 통신한다. PXZD(318)는 구소프트웨어와 신소프트웨어 유닛들에 대해 저장된 데이터 변수 간의 호환성을 확인하여, 프로그램을 교체할 동안 신소프트웨어 유닛에 필요한 RS(204)와 DS(206)영역의 크기를 최적화 한다. PXZD(318)는 PXZA(320), LACO(310), LARI(308)과 양방향 논리 경로(324, 334, 330)을 통하여 각각 통신한다. PXZS(316)은 구소프트웨어와 신소프트웨어 유닛들에 대한 신호 인터페이스 간의 호환성을 확인하여, 신호 인터페이스간의 소정 차이점에 대한 모든 정보를 저장한다. PXZS는 PXZA(320)과 LARI(320)과 통신경로(326과 332)를 통하여 각각 통신한다. PXZMD(314)는 신소프트웨어 유닛에 대한 참조표와 BAT를 직접 갱신하는데 어셈블리 루틴을 사용하여 프로그램의 교환을 실시한다. 사실상 같은 기능을 수행하는 상이한 버전의 PXZMD가 AXE 10 스위치에서 사용되는 각각의 상이한 하드웨어 플랫폼에 필요하다. PXZMD(314)는 AFCO(302), TEM(304), LASYMB(312), LACO(310), 그리고 PXZA(320)과, 양방향 통신 경로(342, 344, 340, 338, 그리고 328)을 통하여 각각 통신한다.

프로그램을 교환 방법 동안에 논리 경로(324, 326, 330, 332, 334, 338, 340, 342, 344, 그리고 348)각각을 지나가는 통신 신호가 별표A에 목록으로 만들어져 있다.

LACO(310)는 프로그램 교환을 위해 신소프트웨어 유닛이 로딩되었을 때를 PXCP(394)에게 알려주고, PXCP(394)와 CPS(390)들의 저장 기능 간의 인터페이스로서 활동한다. LASYMB(312)는 교환하여야 할 구소프트웨어와 신소프트웨어 유닛들에 대한 신호와 변수명 심볼을 관리한다.

AFCO(302)는 PXCP(394)와 CPS(390)들의 감사 기능 간의 인터페이스 기능을 수행한다. TEM(304)는 프로그램 테스트 시스템을 위한 중앙 기능을 포함하고 있다. LARI(308)는 기계 종속형이며, 스위치(제1도에서 104)의 운영 체계(OS)에서 사용하는 참조 정보를 판독하여 갱신하는 다수의 서비스 루틴을 포함하고 있다.

도 4을 참조하여 보면, 본 발명의 바람직한 실시예에 따라 제1도의 스위치(104) 내에서 구소프트웨어 유닛(기능 블록)을 신소프트웨어 유닛으로 바꾸는 프로그램 교환방법의 단계를 보여주는 흐름도가 도시되어 있다. 이 방법은 단계(402)에서 시작하여, 단계(404)로 진행하는데, 단계(404)에서 구소프트웨어 유닛과 교체하여야할 새로운 소프트웨어 유닛이 스위치(104)(도 1)의 기억장치(122)로 로딩된다. 다음에 신소프트웨어 유닛이 등록되는 단계(406)로 진행하고, 신소프트웨어 유닛이 활성화되는 단계(408)로 계속 진행한다. 신소프트웨어가 활성화된 뒤에, 단계(410)에서 신소프트웨어를 확인한다. 그런 다음 방법은 단계(412)로 진행하는데, 여기서 신소프트웨어 유닛이 적절하게 작동하지 아닌지를 결정한다. 제대로 작동한다고 판단되면, 단계(418)로 진행하고, 제대로 작동하지 않는다면 단계(414)로 넘어간다. 단계(414)에서, 신소프트웨어는 비활성화시키고, 비활성화된 신소프트웨어를 스위치(104)에서 제거하는 단계(416)로 진행한다. 단계 418에서, 새로운 소프트웨어 유닛이 보증되고, 방법은 구소프트웨어 유닛이 스위치(104)(도 1)기억장치(122)에서 제거하는 단계(420)로 진행한다. 그리고 이 방법은 단계(422)에서 끝난다. 상기 단계들에 대한 상세한 설명을 아래에서 계속한다.

본 발명의 바람직한 실시예에서, 도 1의 DBS(124) 내에서 명령 트랜잭션(a command transaction)은 관련 구소프트웨어 유닛을 각각 대체하는 다수의 신소프트웨어 유닛을 규정하는데 사용할 수 있다.

도 4의 단계(404)에서, 신소프트웨어 유닛은 스위치(104)의 기억장치[122, 즉 PS(202), RS(204), 그리고 DS(206)]로 로딩된다. 프로그램 교환을 위해 신소프트웨어 유닛이 무사히 로딩된 후에, LACO(310)을 통해 DBS(124)는 교환 정보를 PXPROGRAM 데이터베이스 표에 삽입하기 위해 PLEX-SQL(DBS) 명령문을 사용한다. 교환 정보는 다음과 같은, 즉 신소프트웨어 유닛에 대한 블록 명칭, 새로운 그리고 구소프트웨어 유닛의 블록 번호, 새로운 그리고 구소프트웨어 유닛의 제품 번호, 그리고 신소프트웨어와 구소프트웨어 유닛의 R-STATE와 같은 정보를 포함할 수 있다. 교환 정보를 PXPROGRAM 표에 로딩하면, 신소프트웨어 유닛이 단계(406)에서 등록된다.

도 5를 참조하여 보면, 발명의 바람직한 실시예에 따라 제4도의 단계(406)에서 신소프트웨어 유닛의 등록을 상세하게 흐름도가 도시되어 있다. 신소프트웨어 유닛의 등록은 단계(500)에서 시작하여 단계(504)로 진행하고, 이 단계에서 PXPROGRAM 표에 표 횡렬(row) 삽입이 허용되는지 아닌지를 결정한다. 표 횡렬은 반드시 (도 3의) 프로그램 교환 서브시스템(PXCP, 394)에 의해 PXPROGRAM 표 속으로 삽입되어야 하며 조작자(an operator)에 의해서는 안된다. 표의 횡렬 삽입이 허용되면, 단계(506)로 진행하고, 만약 허용되지 않으면 단계(514)로 진행한다.

단계(506)에서 신소프트웨어 유닛이 구소프트웨어 유닛과 호환성이 있는지를 결정한다. 신소프트웨어 유닛이 호환성이 있는지는, 블록의 형태와 블록의 외부 형태가 구소프트웨어 유닛의 블록 형태와 블록 외부형태와 동일하고, 수정 영역 내에서 수정 부분이 없고, 신호 인터페이스가 구소프트웨어 유닛과 신소프트웨어 유닛이 서로 호환 가능하며, 변수들의 구조가 서로 호환성이 있느냐에 따라 판별된다. PXZS(316)는 구소프트웨어 유닛과 신소프트웨어 유닛의 신호 인터페이스가 서로 호환성이 있는지를 결정한다. 신호 인터페이스가 서로 동일하다면 호환성이 있다. PXZD(318)도 신소프트웨어 유닛과 구소프트웨어 유닛의 구조가 호환성이 있는지를 결정한다. FXZD(318)는 또한 호환성이 있는 소정의 변수의 차이를 도 1의 DBS(124)내에서 VARIABLEDIFF 데이터베이스 표에 저장한다. 신소프트웨어 유닛이 호환성이 있는 것으로 결정되면, 단계(508)로 나아간다. 그러나 호환성이 없는 것으로 결정되면, 단계(510)로 진행한다.

단계(508)에서 구소프트웨어 유닛에 현재 존재하고 있는 신소프트웨어 내의 동일한 변수들을 신소프트웨어 유닛에서 제거한다. 동일한 변수들은 제2도의 DS영역(206)에서 공간을 절약하기 위해 삭제해 버릴 수 있는데 신소프트웨어 유닛은 구소프트웨어의 변수들을 물려받기 때문이다. 신소프트웨어 유닛에서 동일한 변수를 삭제하고 나면, 신소프트웨어 유닛의 BAT는 압축되므로, 추가, 변경. 삭제된 변수들 각각에 대해 단지 한 위치만이 존재한다. 신소프트웨어 유닛의 BAT가 압축된 뒤, VARIABLEDIFF 표는 압축된 BAT 내의 변수들에 대한 위치와 구소프트웨어 유닛의 BAT내의 변수에 대한 위치들 간을 맵핑하기 위해 갱신된다. 다음에 단계(512)로 계속된다. 단계(510)에서, 변수 결과_코드(result_code)는 구소프트웨어 유닛과 신소프트웨어 유닛이 호환성이 없다는 것을 표시하도록 설정된다. 다음에 단계(512)로 진행한다. 단계(514)에서, 변수 표 연산이 유효하게 수행되었는지 결정한다. 변수 표 연산이 제대로 수행되었다면 단계(512)로 진행하고, 만약 그렇지 못하다면 단계(516)로 진행한다.

단계(516)에서, 변수 표 연산이 제대로 수행되지 못한 것을 표시하는 오류가 도 1의 DBS(124)에로 리턴된다. 그리고 단계(518)로 진행한다. 단계(512)에서, 도 3의 LACO(310)내의 기능을 시작시키고, 단계(518)에서 종료한다. LACO(310)에서 시작된 기능에 의해 신소프트웨어 유닛을 등록할 것을 결론 짓는다.

도 6A, 6B는 본 발명의 바람직한 실시예에 따라 제4도의 단계(408)에서 신소프트웨어 유닛의 활성화를 매우 상세히 보여주는 흐름도. 신소프트웨어 유닛의 활성화는 도 3의 PXZA(320)에 의해 수행된다. 신소프트웨어 유닛의 활성화는 일반적인 DBS 명령어들에 의해 시작되는데, 이 명령어가 신소프트웨어 유닛이 실행될 수 있도록 한다. 만약 프로그램을 교환하는 과정 중에 스위치(104)의 시스템을 재기동해야 하는 일이 생긴다면, 그때는 "활성화(ACTIVE)" 신소프트웨어 유닛을 비활성화시킨다. 이 이후로 용어 비활성화(passivated)는 실행할 수 있는 있지만 거부당한 소프트웨어 유닛을 규정하는데 사용된다.

도 6A를 참조하면, PXPROGRAM 표에서 규정된 신소프트웨어 유닛들의 활성화는 단계(600)에서 시작하여 단계(604)로 진행되고, 이 단계에서 시스템 참보 정보 갱신의 허가가 LACO(310)에서부터 승인되었는지 여부를 판단한다. 만약 LACO(310)가 허가를 승인한다면, 단계(610)로 진행한다. LACO(310)가 허가를 승인하지 않는다면, 단계(606)로 진행하여 기능 오류 코드를 도 1의 DBS(124)로 보고하고 단계(652)로 진행하여 끝난다.

단계(610)에서 PXPROGRAM 표는 신소프트웨어 유닛과 표 내에 지정되어 있는 구소프트웨어 유닛을 선택하도록 액세스되고, 프로그램 교환상태가 선택된 신소프트웨어와 구소프트웨어 유닛에 대해 유효한지 결정된다. 신소프트웨어의 프로그램 교환상태가 "ACTIVE"이면 그 상태는 유효하다. 구소프트웨어 유닛의 프로그램 교환 상태가 "INACTIVE"이면 그 상태는 유효하다. 선택된 신소프트웨어와 구소프트웨어 유닛에 대한 프로그램 교환상태(PXSTATEs)가 유효하다면, 그러면 단계(614)로 진행한다. 그러나, 만약 유효하지 않다면 단계(624)로 진행한다. 단계(624)에서 오류 코드가 도 1의 DBS(124)로 리턴되고, 단계(626)로 가서 선택된 신소프트웨어와 구소프트웨어 유닛들이 그들 처음 상태로 각각 복귀되고, 도 6B의 단계(642)로 진행한다.

단계(614)에서 선택된 신소프트웨어와 구소프트웨어 유닛의 신호 인터페이스가 호환이 있는지가 결정된다. 구소프트웨어와 신소프트웨어 유닛의 신호 인터페이스는 많은 이유 때문에 호환이 불가능할 수 있다. 예를 들면, 신소프트웨어 유닛의 로딩과 활성 간에 존재할 수 있는 시간 주기 동안에 구소프트웨어 유닛(즉, "ACTIVE" 유닛)에 신호 정정이 삽입될 수 있다.

선택된 구소프트웨어와 신소프트웨어 유닛의 신호 인터페이스 간의 차이는 허용되지 않는데, 신호 연결 정보는 프로그램을 교환하는 동안 갱신되지 않기 때문이다. 선택된 구 및 신소프트웨어 유닛의 신호 인터페이스의 호환성 판단은 도 3의 PXZS(316)에 의해 수행된다. 만약 PXZS(316)가 구 및 신소프트웨어 유닛의 신호 인터페이스가 호환 가능하다고 판단하면, 그러면 단계(616)로 진행한다. 그러나 호환 불가능하다고 결정 내리면, 그때는 단계(628)로 진행한다. 단계(628)에서, 오류 코드가 도 1의 DBS(124)로 리턴되고, 단계(630)로 가서 구 및 신소프트웨어 유닛은 그들의 처음 상태로 각각 복원되고, 도 6B의 단계(642)로 진행한다.

단계(616)에서, 프로그램 교환 준비 작업이 수행된다. 이 준비 작업에는 PXZA(320)가 선택된 신소프트웨어와 구소프트웨어 유닛에 대한 블록 번호를 도 3의 PXZMD(314)에서 전송하는 작업을 포함한다. 그러면, PXZMD(314)는 참조표 위치, 기초 어드레스표 위치, 변수 영역 정보 워드(이는 프로그램 교환 중에 갱신된다)에 관한 정보를 어셈블링한다. 그런 다음, 단계(618)로 진행하여 프로그램 교환 준비가 성공적인지를 결정한다. 준비가 제대로 되었다면 단계(620)로 가지만, 그렇지 못할 경우 단계(632)로 진행한다. 단계(632)에서 오류 코드는 도 1의 DBS(124)로 리턴되고, 단계(634)로 가서 선택된 신소프트웨어와 구소프트웨어는 각각의 처음 상태로 복귀되고, 도 6B의 단계(642)로 진행한다.

단계(620)에서, 제3도의 PXZA(320)는 선택된 신소프트웨어 유닛에 대해 프로그램 교환상태(PXSTATE)를 "ACTIVE"로 설정하고 단계(622)로 진행한다. 만약 너무 많은 다수의 신소프트웨어 유닛들이 DBS 명령 트랜잭션에서 규정된다면, 규정된 신소프트웨어 유닛의 활성화는 종료된다. 단계(622)에서, PXPROGRAM 표 내에 활성화를 위한 다른 신소프트웨어 유닛이 있는지를 판별한다. 만약 다른 신소프트웨어 유닛이 활성화를 위해 PXPROGRAM 표내에 규정되어 있는 것으로 판단되면, 단계(610)로 거슬러 올라가, 선택된 다른 신소프트웨어와 구소프트웨어 유닛에 대해 위에서 열거한 단계를 되풀이한다. 만일 PXPROGRAM 표 내에 활성화를 다른 신소프트웨어 유닛이 규정되어 있지 않다면, 도 6B의 단계(636)로 진행한다.

도 6B의 단계(636)에서, PXPROGRAM에서 규정된 구소프트웨어와 신소프트웨어 유닛들은 교환된다. 교환 작업은, 교체해야 할 구소프트웨어 유닛의 현존 변수들에 이외에 변수들을 가지는 지정된 신소프트웨어 유닛들의 기초 어드레스 표에 대한 크기를 증가시키도록 도 3의 PXZA(320)이 명령함으로써 시작한다. 이와는 달리, PXZA(320)는 교체해야 할 구소프트웨어 유닛의 현존 변수들에 비해 적은 변수를 가지는 규정된 신소프트웨어 유닛의 기초 어드레스 표의 크기를 감소시키도록 명령한다.

PXZA(320)는 "로우 레벨"의 프로그램 교환 실행을 수행하도록 신호를 PXZMD(314)에게 전송함으로써 프로그램 교환을 진행한다. 상기 신호에 응답하여, PXZMD(314)는 프로그램을 행하게 되는 규정된 소프트웨어 유닛들에 대해 설정되었을 수 있는 소정의 추적 수단들로 모두 제거한다. 그런 다음, PXZMD(314)는 높은 우선 순위 레벨의 인터럽트를 무능화시켜 프로그램 교환을 진행한다. 높은 우선 순위 레벨의 인터럽트가 무능화되는 동안에, PXZMD(314)는 규정된 구소프트웨어 유닛들 각각의 참조표, BAT, 변수들에서부터 교체되는 신소프트웨어 유닛들 각각으로 데이터를 복제한다. 그럼 다음, PXZMD(314)는 그때 높은 우선 순위 레벨 인터럽트를 다시 인에이블시키고, 도 3의 AFCO(302)가 규정의 신소프트웨어와 구소프트웨어 유닛에 대한 프로그램 저장 검사 합(checksum)를 교환하도록 명령한다. PXZMD(314)는 또한 규정의 신소프트웨어와 구소프트웨어 유닛들에 대한 변수 심볼 정보를 교환하도록 LASYMB(312)에게 명령한다.

단계(638)에서, 변수의 결과_코드는 프로그램 교환이 제대로 이루어졌는지 결정하기 위해 조사된다. 변수의 결과 코드가 프로그램의 교환이 성공적이라고 나타내는 것으로 판단되면, 단계(640)로 진행하고, 프로그램 교환이 제대로 이루어지지 못했다고 결정되면 단계(644)로 간다. 단계(644)에서 PXPROGRAM 표에 액세스하여 활성화를 위한 신소프트웨어 유닛을 선택한다. 선택된 신소프트웨어 유닛의 프로그램 교환상태(PXSTATES)가 "INACTIVE"와 동등하게 설정되어 있으면 단계(646)로 진행한다. 단계(646)에서, PXPROGRAM 표 내에 활성화시킬 다른 신소프트웨어가 있는지 판단한다. 만약 활성화시킬 다른 신소프트웨어가 PXPROGRAM 표에 규정되어 있다고 판단되면 단계(644)로 진행되어 새로이 선택된 다른 신소프트웨어 유닛에 대해 위 단계를 되풀이한다. 그러나 PXPROGRAM 표에 활성화를 위한 다른 신소프트웨어 유닛이 규정되어 있지 않다면 단계(648)로 진행한다. 단계(648)에서 기능 오류 코드가 도 1의 DBS(124)에게 리턴되고, 단계(642)로 진행한다.

단계(640)에서, 트랜잭션이 성공적이었다는 것을 나타내는 보고서가 도 1의 DBS(124)로 리턴되고, 단계(642)로 진행하여 시스템 참조 정보를 갱신하는 승인이 철회되고 단계(652)로 진행하여 끝난다.

도 7을 참조하여 보면, 본 발명의 바람직한 실시예에 따라 도 4의 단계(410)에서 신소프트웨어 유닛을 확인하는 과정을 매우 상세하게 설명하는 흐름도가 도시되어 있다. 신소프트웨어 유닛의 확인은 단계(700)에서 시작하여 단계(704)로 진행하는데, 여기에서 시스템 참조 정보로의 액세스가 허용되는지 아닌지가 판단된다. 시스템 참조표에 액세스하기 위해서는, 도 3의 PXZA(320)이 허락을 요청하는 신호를 도 3의 LACO(310)에게 전송한다. 만일 LACO(310)가 허락을 승인한다면, 방법은 단계(708)로 진행한다. 그러나 LACO(310)가 허락을 거부하면, 단계(706)로 진행하고, 이 단계에서 오류 코드를 도 1의 DBS에 보고하고 단계(730)로 진행하여 끝난다.

단계(708)에서, PXPROGRAM 표에 액세스하여 확인을 위해 규정된 신소프트웨어 유닛을 선택하고, 그리고 선택된 신소프트웨어 유닛의 프로그램 교환상태가 유효한지를 결정한다. 상태가 "ACTIVE"와 동등하면, 선택된 신소프트웨어의 PXSTATE는 유효하다. 만약 PXSTATE 가 유효하지 않다면 단계(710)로 진행한다. 그러나 선택된 신소프트웨어의 PXSTATE 가 유효한 것으로 결정되면, 단계(714)로 진행한다. 단계(710)에서, 기능 오류 코드는 도 1의 DBS(124)로 리턴되고, 단계(712)로 진행하여 선택된 신소프트웨어 유닛은 그의 이전 상태로 복귀된다. 그런 다음, 단계(728)로 진행한다.

단계(714)에서, 확인을 위한 DBS 명령 트랜잭션 내에 너무 많은 다수의 신소프트웨어 유닛들이 규정되어 있지 않은지가 결정된다. 만약 너무 많은 신소프트웨어 유닛들이 확인을 위해 규정되어 있다면, 그러면 단계(716)로 진행한다. 그러나 프로그램 교환을 위해 규정된 신소프트웨어 유닛의 수가 적당하다면 단계(722)로 간다. 단계(716)에서, 기능 오류 코드는 도 1의 DBS(124)로 리턴되고, 단계(718)로 진행하여 선택된 신소프트웨어 유닛는 그 이전 상태로 복귀되고, 단계(728)로 진행한다.

단계(722)에서, 선택된 신소프트웨어 유닛에 대한 프로그램 교환상태가 "CONFIRM"과 동등하게 설정되고, 단계(724)로 진행하여 확인을 위해 규정된 다른 신소프트웨어 유닛이 PXPROGRAM 표에 있는지 아닌지가 결정된다. 만약 PXPROGRAM 표에 다른 신소프트웨어 유닛이 있는 것으로 결정된다면, 단계(708)로 되돌아가서 다른 신소프트웨어 유닛에 대해 위에서 열거한 단계들을 되풀이한다. 그러나 PXPROGRAM 표에 확인해야 할 다른 신소프트웨어 유닛이 더 없다고 판단되면, 단계(726)로 진행하여 처리가 성공적으로 끝났다는 보고서가 도 1의 DBS(124)로 전송된다. 그리고 단계(728)로 가서 시스템 참조 정보를 갱신하는 것에 대한 허락이 철회되고 단계(730)로 간다.

이제 도 8A, 8B를 참조하여 보면, 본 발명의 바람직한 실시예에 따라 제4도의 단계(418)에서 신소프트웨어 유닛의 보증작업을 매우 상세히 나타내는 흐름도가 도시되어 있다. 보증 과정은 하나 이상의 확인된 신소프트웨어 유닛을 보증하고 시스템에서부터 관련된 구 버전의 소프트웨어 유닛을 제거한다. 규정된 신소프트웨어 유닛이 한번 보증되면, 보증된 신소프트웨어 유닛이나 대체되는 구소프트웨어 유닛에 대해 복귀될 가능성은 없다. 그러나 교체된 구소프트웨어 유닛은 도 1의 스위치에서 제거할 수 있고, 확인된 신소프트웨어 유닛과 프로그램 교환을 위해 다시 로딩될 수 있다. 스위치는 선택적으로 이전 시스템 백업으로 로딩될 수 있다.

보증 방법은 단계(800)에서 시작하고 단계(804)로 진행하여 시스템 참조 정보로 액세스가 허용되지는 여부를 결정한다. 도 3의 PXZA(320)은 제3도의 LACO(310)에게 신호를 전송하여 시스템 참조 정보를 갱신할 수 있도록 허용해 달라고 요청한다. 만약 LACO(310)가 허용하지 않으면, 그러면 단계(806)로 진행하고, 만일 LACO(310)가 허용한다면, 단계(810)로 간다.

단계(806)에서, 오류 코드는 도 1의 DBS(124)로 보내지고 방법은 단계(842)로 가서 종료한다. 단계(810)에서, PXPROGRAM 표에 액세스하여 보증을 위해 규정된 신소프트웨어 유닛을 선택하고; 선택된 신소프트웨어 유닛의 프로그램 교환상태(PXSTATE)가 유효한지 아닌지 결정한다. 상태가 "CERTIFY"와 동등하면 선택된 신소프트웨어 유닛의 PXSTATE가 유효한 것이다. 만약 신소프트웨어의 PXSTATE 가 유효한 것으로 결정되면 단계(816)로 진행한다. 그러나 신소프트웨어 유닛의 PXSTATE 가 유효하지 않은 것으로 결정되면 단계(812)로 진행한다. 단계(812)에서, 기능 오류 코드는 도 1의 DBS(124)에 통보된다. 그리고 단계(814)로 가서 선택된 신소프트웨어 유닛은 그 이전의 상태로 복귀되고 도 8B의 단계(838)로 진행한다.

단계(816)에서, 보증을 위한 DBS 명령 트랜잭션에서 너무 많은 다수의 신소프트웨어 유닛이 규정되지 않은지를 판단한다. 만약 보증을 위해 너무 많은 숫자의 신소프트웨어 유닛이 규정되어 있다고 판단되면 단계(818)로 진행한다. 그러나 숫자가 적절하면 단계(822)로 진행한다.

단계(818)에서, 오류 코드는 도 1의 DBS(124)로 리턴되고, 방법은 단계(820)로 진행하여 선택된 신소프트웨어는 그 처음 상태로 복귀되고, 도 8B의 단계(838)로 진행한다. 단계(822)에서, 도 3의 PXZA(320)는 선택된 신소프트웨어 유닛의 프로그램 교환상태(PXSTATE)를 "CERTIFY"와 같게 설정하고, 방법은 단계(824)로 간다. 단계(824)에서, PXPROGRAM 표에 보증을 위해 규정된 다른 신소프트웨어 유닛이 존재하는지를 결정한다. 만일 보증을 위해 규정된 다른 신소프트웨어 유닛이 PXRPOGRAM 표에 존재하는 것으로 결정되면, 방법은 단계(810)로 되돌아가서 다른 신소프트웨어 유닛에 대해 위에서 열거한 단계를 되풀이한다. 그러나, 보증을 위해 규정된 다른 신소프트웨어 유닛이 PXPROGRAM 표에 존재하지 않는 것으로 결정되면, 방법은 도 8B의 단계(826)로 간다.

도 8B를 참조하여 보면, 단계(826)에서, PXZA(320)는 제거해야 할 규정된 구소프트웨어 유닛의 블록 명칭들을 도 3의 LACO(310)으로 전송한다. 그런 다음, PXZA(320)는 각각의 프로그램 교환 블록 번호에 위치하는 규정된 구소프트웨어 유닛들을 제거하도록 LACO(310)에 명령한다. PXZA(320)은 또한 LACO(310)가 성공리에 제거한 규정된 구소프트웨어 유닛에 대한 프로그램 교환 정보를 PXPROGRAM 표에서 제거한다.

단계(828)에서, 규정된 모든 구소프트웨어 유닛들을 제대로 제거했는지 아닌지가 결정된다. 만일 규정된 모든 구소프트웨어 유닛들의 제거가 성공적이었는 것으로 결정되면, 단계(836)로 진행한다. 그러나, 어느 것이라도 제거가 제대로 되지 못했다면, 단계(830)로 간다. 단계(830)에서 보증을 위해 규정된 신소프트웨어 유닛이 PXPROGRAM 표에서 선택되고, 선택된 신소프트웨어 유닛의 프로그램 교환상태는 "CONFIRM"으로 설정된다. 그런 다음, 방법은 단계(832)로 진행하여 PXPROGRAM 표에 보증을 위해 규정된 다른 신소프트웨어 유닛이 존재하는지를 결정한다. 만약 보증을 위해 규정된 다른 신소프트웨어 유닛이 PXPROGRAM 표에 존재하는 것으로 결정된다면, 방법은 단계(830)로 거슬러 가서 다른 신소프트웨어 유닛에 대해 위에서 열거한 단계를 되풀이한다. 그러나, 보증을 위해 규정된 다른 신소프트웨어 유닛이 PXPROGRAM 표에 존재하지 않는다면, 방법은 단계(834)로 진행하여 오류 코드를 도 1의 DBS(124)에 통보하고 단계(838)로 진행한다.

단계(836)에서, 보증이 성공적이라는 표시가 도 1의 DBS(124)로 리턴되고, 방법은 단계(840)로 진행하여 시스템 참조 정보의 갱신에 대한 허락이 철회되고, 방법은 단계(842)로 가서 종료한다.

도 9A, 9B를 참조하여 보면, 본 발명의 바람직한 실시예에 따라 도 4의 단계(414)DPTJ 신소프트웨어 유닛의 비활성화를 상세하게 설명하는 흐름도가 도시되어 있다. 비활성화(passivation) 방법은 단계(900)에서 시작하여 단계(902)로 진행하는데, 이 단계에서 PXZA(320)은 시스템 참조 정보의 갱신의 허락을 요청하는 신호를 LACO(310)에 전송한다. 만약 LACO(310)가 허락을 승인한다면, 방법은 단계(906)로 진행한다. 만약 LACO(310)가 허락을 승인하지 않는다면, 방법은 단계(904)로 진행하여 오류 코드가 도 1의 DBS(124)에 리턴되고, 방법은 단계(942)에서 종료한다.

단계(906)에서, PXPROGRAM 표에 액세스하여 비활성화를 위해 규정된 신소프트웨어 유닛과 그와 관련한 구소프트웨어 유닛을 선택하고, 선택된 신소프트웨어와 구소프트웨어 유닛에 대해 프로그램 교환상태가 유효한지 아닌지를 판단한다. 선택된 신소프트웨어 유닛의 프로그램 교환상태는 그것이 "INACTIVE"와 같으면 유효하다. 선택된 구소프트웨어 유닛의 프로그램 교환상태는 "ACTIVE" 또는 "CONFIRM"과 같을 때 유효하다. 만약 선택된 신소프트웨어와 구소프트웨어 유닛들이 유효한 프로그램 교환상태를 지닌다면 단계(912)로 진행한다. 그러나 어느 하나라도 유효하지 않은 상태이라면 단계(908)로 진행하여 오류 코드가 도 1의 DBS(124)에로 리턴되고, 방법은 단계(910)로 진행한다. 단계(910)에서, 선택된 구소프트웨어와 신소프트웨어 유닛은 이전 상태로 복귀되고, 방법은 도 9B의 단계(942)로 진행한다.

단계(912)에서, 신소프트웨어나 구소프트웨어 유닛의 신호 인터페이스가 호환성이 있는지 여부를 판단한다. PXCP(318)은 프로그램 교환 중 신호 연결 정보를 갱신하지 않기 때문에, 신호 인터페이스에서 차이가 허용되지 않는다. PXZA(320)은 PXZS(316)에게 호환성을 검증하라고 지령을 내린다. 신호 인터페이스가 호환성이 있다고 판단되면 단계(918)로 진행한다. 그러나 신호 인터페이스가 호환성이 없다고 판단되면 단계(922)로 진행하여 오류 코드를 도 1의 DBS(124)에 보고하고, 방법은 단계(924)로 간다. 단계(924)에서, 선택된 구소프트웨어와 신소프트웨어 유닛은 그들의 이전 상태로 복귀되고, 방법은 도 9B의 단계(942)로 진행한다.

단계(918)에서, 프로그램 교환을 위한 준비를 한다. 준비는, 만약 선택된 구소프트웨어 유닛이 교체하게 될 신소프트웨어의 현재 변수 이외의 변수를 가진다면, 선택된 구소프트웨어 유닛의 기초 어드레스 표를 증가시키도록 도 3의 PXZA(320)가 명령함으로써 시작한다. 이와 대조적으로, 만약 선택된 구소프트웨어 유닛이 교체하게 될 신소프트웨어 유닛 기존 변수보다 적은 변수를 가지고 있다면, 선택된 구소프트웨어 유닛의 기초 주소표에서 감소시키도록 PXZA(320)이 명령한다. 프로그램 교체를 위한 준비가 수행된 후에, 단계(920)로 진행하여 준비 작업이 성공적이었는지를 판단한다. 만약 준비가 제대로 되었다면, 도 9B의 단계(926)로 진행하지만, 준비가 성공적이지 못하다면 단계(922)로 진행하여 오류 코드가 도 1의 DBS(124)에게 통보되고, 방법은 단계(924)로 진행한다. 단계(924)에서, 선택된 구소프트웨어와 신소프트웨어 유닛들은 그들의 이전 상태로 복귀되고, 방법은 도 9B의 단계(942)로 진행한다.

도 9B를 참조하여 보면, 단계(926)에서, 선택된 신소프트웨어 유닛에 대한 프로그램 교환상태(PXSTATE)는 "INACTIVE"로 바뀌고, 방법은 단계(928)로 간다. 단계(928)에서, PXPROGRAM 표에 비활성화를 위해 규정된 다른 신소프트웨어와 구소프트웨어 유닛의 쌍이 있는지 없는지를 판단한다. 만약 PXPROGRAM 표 내에 비활성화를 위해 규정된 신소프트웨어와 구소프트웨어 유닛 쌍이 있다고 판단되면, 단계(906)로 되돌아가서, 다른 신소프트웨어 및 구소프트웨어 유닛의 쌍에 대해 위에서 열거한 단계를 되풀이한다. 그러나, PXPROGRAM 표에 다른 구소프트웨어 및 신소프트웨어 유닛의 쌍이 없다면, 방법은 단계(930)로 진행한다. 단계(930)에서, 비활성화를 위해 규정된 구소프트웨어와 신소프트웨어 유닛의 쌍의 교환을 행한다. 교환 작업은 PXZMD(314)가 TEM(304)에게 규정된 구소프트웨어와 신소프트웨어 유닛에 대해 설정되었을 수 있는 소정의 추적 수단을 제거하도록 명령함으로써 수행된다. PXZMD(314)는 또한 THL(a traflic handling level; 트래픽 처리 레벨)과 같은 높은 우선 순위 레벨의 인터럽트도 비활성화 시킨다. 높은 우선 순위 레벨 인터럽트가 비활성화되는 기간 동안에, 도 3의 PXZMD(314)는 규정된 신소프트웨어의 참조표, BAT, 그리고 변수들 각각에서부터 신소프트웨어 유닛을 대체하는 관련 구소프트웨어 유닛으로 데이터를 복사한다. 그런 다음, PXZMD(314)는 높은 우선 순위 레벨의 인터럽트를 다시 인에이블하고, AFCO(302)에게 PS 체크 합을 교환 하도록 명령하고, LASYMB(312)에게 규정된 구소프트웨어와 신소프트웨어 유닛에 대한 변수 심볼 정보를 교환하도록 명령한다. 변수 결과_코드는 또한 프로그램 교환이 성공적이었는지 여부를 표시하는 값과 동일하게 설정된다. 그런 다음, 방법은 단계(932)로 진행하는데, 여기에서 변수 결과_코드는 프로그램 교환이 성공적이었는지 여부를 판단하기 위해 분석된다. 변수 결과_코드가 프로그램 교환이 성공적이었다고 나타내는 것으로 판단되면, 방법은 단계(938)로 진행한다. 그러나 결과_코드가 프로그램 의 교환이 성공적이지 못하였다는 것을 나타내는 것으로 판단되면, 방법은 단계(934)로 진행한다.

단계(934)에서, PXPROGRAM 표에 액세스하여, 비활성화를 위해 규정된 신소프트웨어 및 구소프트웨어 유닛을 선택한다. 이외에도, 선택된 신소프트웨어 유닛의 프로그램 교환상태가 "ACTIVE"와 동등하게 설정되어 있으면 단계(936)로 진행한다. 단계(936)에서, PXPROGRAM 표에 비활성화를 위해 규정된 다른 신소프트웨어와 구소프트웨어 유닛의 쌍이 있는지를 판단한다. 만약 PXPROGRAM 표에 비활성화를 위해 규정된 다른 신소프트웨어와 구소프트웨어 유닛의 다른 쌍이 있는 것을 결정되면, 그러면 방법은 단계(934)로 되돌아가서 다른 신소프트웨어 유닛으로 위에서 열거한 단계를 되풀이한다. 만약 PXPROGRAM 표에 비활성화를 위해 규정된 다른 신소프트웨어와 구소프트웨어 유닛의 쌍이 없는 것으로 결정되면, 그러면 방법은 단계(940)로 간다. 단계(940)에서, 오류 코드는 도 1의 DBS(124)에 리턴되고, 그리고 방법은 단계(942)로 진행한다. 단계(938)에서, 프로그램 교환이 성공적이었다는 표시는 도 1의 DBS(124)에 리턴되고, 방법은 단계(942)로 진행한다. 단계(942)에서, 시스템 참조 정보 표(table)를 갱신하기 위한 허가가 철회되고, 방법은 단계(944)로 가서 종료한다.

도 10A, 10B를 참조하여 보면, 본 발명의 바람직한 실시예에 따라 제4도의 단계(416)에서 신소프트웨어 유닛의 제거를 매우 상세하게 나타내는 흐름도가 도시되어 있다. 신소프트웨어 유닛의 제거방법은 단계(1000)에서 시작하여 단계(1002)로 진행한다. 단계(1002)에서, PXZA(320)은 시스템 참조 정보를 갱신하기 위해 허가를 요청하는 신호를 도 3의 LACO(310)로 전송한다. 만일 LACO(310)가 허락을 승인하면, 방법은 단계(1006)로 진행한다. 그러나 LACO(310)가 허락을 승인하지 않으면, 그러면 방법은 단계(1004)로 가서 오류 코드가 도 1의 DBS(124)로 리턴되고, 방법은 단계(1032)로 가서 종료한다.

단계(1006)에서, PXPROGRAM 표에 액세스하여, 제거를 위해 규정된 신소프트웨어 유닛을 선택하고, 그리고 선택된 신소프트웨어 유닛의 프로그램 교환상태가 "INACTIVE"과 같은지 여부를 판단한다. 만일 선택된 신소프트웨어 유닛의 프로그램 교환상태가 "INACTIVE"와 같으면, 그러면 방법은 단계(1012)로 진행하지만, 선택된 신소프트웨어 유닛의 프로그램 교환상태가 "INACTIVE"와 같지 않으면, 그러면 방법은 단계(1008)로 진행하여 오류 코드가 도 1의 DBS(124)로 리턴된다. 그런 다음, 방법은 단계(1012)로 진행하여 선택된 신소프트웨어 유닛은 그 이전 상태로 복귀되고, 방법은 도 10B의 단계(1030)로 진행한다.

단계(1012)에서, 제거를 위해 DBS 명령 트랜잭션 내에 너무 많은 다수의 신소프트웨어 유닛이 규정되어 있지 아닌지를 판단한다. 만약 제거를 위해 너무 많은 다수의 신소프트웨어 유닛이 규정되어 있다고 판단되면, 그러면 방법은 단계(1014)로 가지만, 제거를 위해 적당한 숫자의 신소프트웨어 유닛이 규정되어 있다고 판단되면, 그러면 방법은 단계(1018)로 진행한다. 단계(1014)에서, 오류 코드가 도 1의 DBS(124)로 리턴되고, 방법은 단계(1016)로 진행하여 선택된 신소프트웨어 유닛은 그 이전 상태로 복귀되고, 방법은 도 10B의 단계(1030)로 진행한다. 단계(1018)에서, 선택된 신소프트웨어 유닛에 대한 블록 번호는 PXPROGRAM 표내로 관련 횡렬에서부터 기록되고, 방법은 단계(1020)로 진행한다. 단계(1020)에서, PXPROGRAM 내에 제거를 위해 규정된 다른 신소프트웨어 유닛이 존재하는지 여부가 판단된다. 만약 PXPROGRAM 내에 제거를 위해 규정된 다른 신소프트웨어 유닛이 존재하는 것으로 판단되면, 그러면 방법은 단계(1006)로 되돌아가서 다른 신소프트웨어 유닛에 대해 위에서 열거된 단계를 되풀이한다. 만약 PXPROGRAM 내에 제거를 위해 규정된 다른 신소프트웨어가 더 이상 없다고 판단되면, 그러면 방법은 도 10B의 단계(1022)로 진행한다.

도 10B를 참조하여 보면, 단계(1022)에서, 비활성화 소프트웨어 유닛(즉, 비활성화된 신소프트웨어 유닛)를 제거한다. 이 제거작업은 비활성화 소프트웨어 유닛에 대한 블록 명칭들을 LACO(310)에 전송하는 PXZA(320)가 수행한다. PXZA(320)은 또한 LACO(310)에게 각각의 프로그램 교환 번호에서 로딩되는 비활성화 신소프트웨어 유닛을 제거하도록 명령한다. 그럼 다음, PXZA(320)는 LACO(310)가 성공적으로 제거한 비활성화 소프트웨어 유닛 각각에 대한 프로그램 교환정보를 PXPROGRAM 표로부터 제거한다. 그리고 방법은 단계(1024)로 간다.

단계(1024)에서, 규정된 제거작업이 성공적으로 이루어졌는지 아닌지를 판단한다. 소정의 제거작업이 성공적으로 이루어졌는 것으로 판단되면, 방법은 단계(1028)로 진행한다. 그러나 규정된 제거작업 중 어느 것이지 못한 것으로 판단되었다면, 방법은 단계(1026)로 간다. 단계(1026)에서, 오류 코드가 도 1의 DBS(124)에 보고되고, 방법은 단계(1030)로 간다. 단계(1028)에서, 규정된 비활성화 소프트웨어 유닛의 제거가 성공적이었다는 표시가 DBS(124)에 보고되고, 방법은 단계(1030)로 진행한다. 단계(1030)에서, 시스템 참조 정보를 갱신하기 위한 허가를 철회되고, 방법은 단계(1032)로 진행하여 종료한다.

비활성 소프트웨어 유닛들을 제거하는 것에 대해 앞서 설명한 단계들은 제4도의 단계(420)에서 구소프트웨어를 제거하는 작업과 실질적으로 동일하지만, 앞에서 기술한대로 각 소프트웨어 유닛의 규칙을 보존한다는 점이 다르다.

PXZMD(314)는 또한 스위치내에서 재작동 동작에 의해 일시 중단되는 프로그램의 교환을 다시 복원할 수 있는 능력도 있다. PXZMD(314)는 LACO(310)으로부터의 시스템 참조 정보를 갱신할 수 있도록 하는 허락을 얻어 복원을 수행하고, 필요하다면 재작동시에 갱신되었던 참조 정보를 복원함으로써 복구를 수행한다. 그런 다음, PXZMD(314)는 일시 중단된 프로그램의 교환 중에 미처리된 모든 소프트웨어 유닛에 대한 참조 정보를 스위치한다. PXZMD(314)는 또한 도 2의 PS영역(202)의 CHECKSUM과 선택된 신소프트웨어와 구소프트웨어 유닛에 대한 변수 심볼 정보를 교환한다.

프로그램 교환방법에 의해 도입되게 되는 신소프트웨어 유닛들에 대한 수정이나 정정의 정도는 제한된다. 상기 제한은, 스위치(104) 내에서 진행중인 트래픽을 교란하는 일이 없이 신소프트웨어 유닛을 구소프트웨어 유닛과 교환할 수 있도록 하여, 이에 의해 시스템을 재작동시킬 필요성을 없앤다.

신소프트웨어 유닛의 제한들은, 블록 속성은 구소프트웨어 유닛과 동일하여만 하고, 신호 인터페이스도 구소프트웨어 유닛의 신호 인터페이스와 동일하여야만 하고, "STATIC" 표시가 되지 않은 소정의 변수를 포함하는 현재의, 크기를 변경할 수 없는 데이터 파일(non-size-alterable data file)의 레코드 구조에서 변경이 없어야 하고, 그리고 "STATIC" 표시가 되지 않은 소정의 변수를 포함하는 비변경 데이터 파일의 초기 크기의 변경이 없어야 한다는, 것과 같은 것들이다. 제한은 또한 다음의 "non-STATIC" 표시된 변수의 속성들(즉, 변수 길이, 색인된 변수의 번호, 지시 표시자, 하부레코드의 수, 데이터 파일번호, 버퍼 특성)의 변경을 포함하지 않는다.

도 11을 참조하여 보면, 본 발명의 바람직한 실시예에 따라 구소프트웨어 유닛과 교환될 때에 신소프트웨어 유닛의 다양한 교환상태를 나타내는 블록도가 도시되어 있다. 신소프트웨어 유닛이 스위치 내로 로딩될 때, 1102에 표시된 것처럼 "INACTIVE"의 프로그램 교환상태를 갖는다. 신소프트웨어 유닛을 실행시키는 동안, 프로그램 교환상태는 1104에 표시된 것과 같이 운영자에 의해 "ACTIVE" 상태로 바뀐다. 신소프트웨어 유닛이 적절히 작동되는 것으로 검증되면, 프로그램 교환상태는 1106에 표시된 바와 같이 운영자에 의해 "CONFIRMED"로 바뀐다. 마지막으로 신소프트웨어 유닛으로 교환을 완료하면, 신소프트웨어 유닛의 프로그램 교환상태는 1108에 표시된 것과 같이 운영자에 의해 "CERTIFIED"로 바뀐다.

상세한 예

도 12를 참조하여 보면, 본 발명의 프로그램 교환방법에 따라 신소프트웨어 유닛과 구소프트웨어 유닛이 진행하게 되는 여러 가지 상태의 사례를 보여주는 블록도가 도시되어 있다. 이 예에서, 구소프트웨어 유닛은 C7TST로 어드레스되고, R1A의 R-STATE를 가지고(다음부터는 C7TST R1A라고 부른다), 신소프트웨어 유닛은 C7TST로 어드레스되고, R1B의 R-STATE를 가진다(이후부터 C7TST R1B라 부른다). 도 12도에서 구소프트웨어와 신소프트웨어 유닛에 대한 천이(변천) 과정은 도 1의 DBS(124)를 사용하여 운영자(operator)가 수행한다.

이 예에서, 구소프트웨어 유닛 C7TST R1A는 스위치 내에서 처음부터 실행되고 있고 단계 1(1202)에 설명한 것 처럼 "ACTIVE"의 상태를 갖는다. 단계 2(1204)에서, 신소프트웨어 유닛 C7TST R1B가 로딩되고, "INACTIVE"의 프로그램 교환상태를 갖는다. 이 시간주기 동안, 구소프트웨어 유닛 C7TST R1A는 여전히 작동하고 있어서, 따라서 "ACTIVE" 상태를 유지한다. 프로그램 교환의 이 단계에서 신소프트웨어 유닛은 운영자에 의해 스위치 내에서 제거될 수 있어서, 이에 따라, 프로그램 교환을 종료할 수도 있다. 단계 3(1206)에서, 신소프트웨어 유닛은 운영자에 의해 활성화(activated)되어, 그 프로그램의 교환상태가 "ACTIVE"로 바뀌고 구소프트웨어 유닛의 프로그램 교환상태는 "INACTIVE"로 바뀐다. 만일, 운영자가 신소프트웨어 유닛을 비활성화시키도록 선택하거나 또는 프로그램 교환 동안에 시스템 재시작이 발생하였다면, 상기 단계 3(1206)에서 구소프트웨어 유닛과 신소프트웨어 유닛에 대한 프로그램 교환상태는 보존될 수 있다.

단계 4(1208)에서, 운영자는 신소프트웨어 유닛의 프로그램 교환상태를 DBS 명령어를 사용하여 "CONFIRM"으로 바꾼다. 프로그램 교환의 이 단계에서, 운영자는 신소프트웨어 유닛을 비활성화시키고 구소프트웨어 유닛을 활성화시켜 단계 2(1204)으로 되돌아 갈 수 있다. 단계 5(1210)에서, 구소프트웨어 C7TST R1A는 스위치에서 제거된다.

본 발명의 작동과 구성은 앞에서 설명한 내용으로 보아 명확히 알 수 있으리라 판단된다. 도시하고 설명한 방법은 바람직한 것으로서 특징되지만, 다음의 청구범위에 규정되는 것과 같은 본 발명의 사상과 범위를 벗어나는 일이 없이 다양한 변경과 수정들이 이루어질 수 있다는 것을 쉽게 파악할 수 있을 것이다.

Claims (12)

1. 기억장치(memory), 소프트웨어 로딩 서브시스템(software loading subsystem), 데이터베이스 관리 서브시스템(database management subsystem), 그리고 프로그램 교환 서브시스템(program exchange subsystem)을 가지는 전기통신 스위치를 재기동하는 일이 없이 전기통신 스위치내에서 구소프트웨어 버전을 신소프트웨어 버전으로 교체하는 방법에 있어서,

   상기 소프트웨어 로딩 서브시스템으로 상기 신소프트웨어 버전을 상기 기억장치로 로딩하는(loading) 단계와;

   상기 데이터베이스 관리 서브시스템을 사용하여 상기 신소프트웨어 버전을 상기 프로그램 교환 서브시스템에 등록시키는(registering) 단계와;

   상기 프로그램 교환 서브시스템으로 상기 구소프트웨어 버전을 비활성화시키는 (passivating) 단계와; 그리고

   상기 프로그램 교환 서브시스템으로 상기 등록된 신소프트웨어 버전을 활성화시키는(activating) 단계를 포함하는 것을 특징으로 하는 구소프트웨어 버전을 신소프트웨어 버전으로 교체하는 방법.
2. 제1항에 있어서, 상기 프로그램 교환 서브시스템으로 상기 활성화된 신소프트웨어 버전을 확인하는(confirming) 단계를 더 포함하는 것을 특징으로 하는 방법.
3. 제2항에 있어서, 상기 프로그램 교환 서브시스템으로 상기 확인된 신소프트웨어 버전을 보증하는(certifying) 단계를 더 포함하는 것을 특징으로 하는 방법.
4. 제3항에 있어서, 상기 보증하는 단계가, 상기 스위치의 기억장치로부터 상기 비활성화된 구소프트웨어 버전을 제거하는 단계를 더 포함하는 것을 특징으로 하는 방법.
5. 기억장치(memory), 소프트웨어 로딩 서브시스템(software loading subsystem), 데이터베이스 관리 서브시스템(database management subsystem), 그리고 프로그램 교환 서브시스템(program exchange subsystem)을 가지는 전기통신 스위치를 재기동하는 일이 없이 상기 전기통신 스위치 내에서 구소프트웨어 버전을 신소프트웨어 버전으로 교체하는 방법에 있어서,

   상기 소프트웨어 로딩 서브시스템으로 상기 신소프트웨어 버전을 상기 기억장치로 로딩하는(loading) 단계와;

   상기 데이터베이스 관리 서브시스템을 사용하여 상기 신소프트웨어 버전을 상기 프로그램 교환 서브시스템에 등록시키는(registering) 단계와;

   상기 프로그램 교환 서브시스템으로 상기 등록된 신소프트웨어 버전을 활성화시키는(activating) 단계와;

   상기 프로그램 교환 서브시스템으로 상기 구소프트웨어 버전을 비활성화시키는(passivating) 단계와;

   상기 프로그램 교환 서브시스템으로 상기 활성화된 신소프트웨어 버전을 확인하는(confirming) 단계와; 그리고

   상기 프로그램 교환 서브시스템으로 상기 확인된 신소프트웨어 버전을 보증하는(certifying) 단계를 포함하는 것을 특징으로 하는, 전기통신 스위치에서 구소프트웨어 버전을 신소프트웨어 버전으로 교체하는 방법.
6. 제5항에 있어서, 상기 스위치의 기억장치로부터 상기 비활성화된 구소프트웨어 버전을 제거하는 단계를 더 포함하는 것을 특징으로 하는 방법.
7. 기억장치(memory), 소프트웨어 로딩 서브시스템(software loading subsystem), 데이터베이스 관리 서브시스템(database management subsystem), 그리고 프로그램 교환 서브시스템(program exchange subsystem)을 가지는 전기통신 스위치를 재기동하는 일이 없이 전기통신 스위치내에서 구소프트웨어 버전을 신소프트웨어 버전으로 교체하는 장치에 있어서,

   상기 소프트웨어 로딩 서브시스템으로 상기 신소프트웨어 버전을 상기 기억장치로 로딩하는(loading) 수단과;

   상기 데이터베이스 관리 서브시스템을 사용하여 상기 신소프트웨어 버전을 상기 프로그램 교환 서브시스템에 등록시키는(registering) 수단과;

   상기 프로그램 교환 서브시스템으로 상기 구소프트웨어 버전을 비활성화시키는(passivating) 수단과; 그리고

   구 소프트웨어 버전을 비활성화할 때에 구 소프트웨어에서 신 소프트웨어로 데이터의 변환을 수행함이 없이 상기 등록된 신 소프트웨어 버전을 활성화시키는(activating) 수단을 포함하는 것을 특징으로 하는, 전기통신 스위치에서 구소프트웨어 버전을 신소프트웨어 버전으로 교체하는 장치.
8. 제7항에 있어서, 상기 프로그램 교환 서브시스템으로 상기 활성화된 신소프트웨어 버전을 확인하는(confirming) 수단을 더 포함하는 것을 특징으로 하는 장치.
9. 제8항에 있어서, 상기 프로그램 교환 서브시스템으로 상기 확인된 신소프트웨어 버전을 보증하는(certifying) 수단을 더 포함하는 것을 특징으로 하는 장치.
10. 제9항에 있어서, 상기 보증하는 수단이 상기 스위치의 기억장치 내에서 상기 비활성화된 구소프트웨어 버전을 제거하는 수단을 더 포함하는 것을 특징으로 하는 장치.
11. 기억장치(memory), 소프트웨어 로딩 서브시스템(software loading subsystem), 데이터베이스 관리 서브시스템(database management subsystem), 그리고 프로그램 교환 서브시스템(program exchange subsystem)을 가지는 전기통신 스위치를 재기동하는 일이 없이 전기통신 스위치내에서 구소프트웨어 버전을 신소프트웨어 버전으로 교체하는 장치에 있어서,

    상기 소프트웨어 로딩 서브시스템으로 상기 신소프트웨어 버전을 상기 기억장치로 로딩하는(loading) 수단과;

    상기 데이터베이스 관리 서브시스템을 사용하여 상기 신소프트웨어 버전을 상기 프로그램 교환 서브시스템에 등록시키는(registering) 수단과;

    상기 프로그램 교환 서브시스템으로 상기 등록된 신소프트웨어 버전을 활성화시키는(activating) 수단과;

    상기 프로그램 교환 서브시스템으로 상기 구소프트웨어 버전을 비활성화시키는(passivating) 수단과;

    상기 프로그램 교환 서브시스템으로 상기 활성화된 신소프트웨어 버전을 확인하는(confirming) 수단; 그리고

    상기 프로그램 교환 서브시스템으로 상기 확인된 신소프트웨어 버전을 보증하는(certifying) 수단을 포함하는 것을 특징으로 하는, 전기통신 스위치에서 구소프트웨어 버전을 신소프트웨어 버전으로 교체하는 장치.
12. 제11항에 있어서, 상기 스위치의 기억장치로부터 상기 비활성화된 구소프트웨어 버전을 제거하는 수단을 더 포함하는 것을 특징으로 하는 장치.

    별표 A