JPH0728724A - Software update control method - Google Patents

Abstract

(57) [Abstract] [Objective] The present invention enables independent development of OpS and NE, guarantees interoperability, and is flexible to change or addition of update type on NE side and introduction of new NE. An object is to provide a corresponding software update control method. According to the present invention, in order to achieve the above object, the update status of software update is expressed by the value of an attribute indicating the update status in a class object of a program of an operating system. Further, it is represented by a state α that is a state in which failback is not possible, a state β that is a state that can be switched back from a high speed storage medium such as a file memory, and a state γ that is a state that can be switched back from a low speed storage medium such as a hard disk. Therefore, N
Since the OpS control operation interface for E is independent of the NE model, update type and vendor, the OpS and NE can be independently developed by the logicalization of the control operation interface and the control operation sequence, and the interoperability is improved. Can be guaranteed.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software update control method, and in particular, an environment in which an operation system (hereinafter abbreviated as OpS) which is a system for maintaining and operating a network element (hereinafter abbreviated as NE) such as an exchange maintains an NE. In the case where OpS remotely executes NE software update (file update, patch input, local data change, etc.) via a communication network, the OpS controls the NE.

[0002]

2. Description of the Related Art Currently, NEs having various physical memory configurations as shown in FIGS. 13 and 14 exist. FIG. 13 shows a main memory (hereinafter abbreviated as MM), a file memory (hereinafter abbreviated as FM) and a hard disk (hereinafter abbreviated as DK).
4 is a diagram showing an example of an NE having a dual memory configuration of FIG. FIG. 14 shows an NE having a dual memory configuration of MM and DK.
It is a figure which shows the example of.

The software update work performed by OpS for NEs is to update the entire system file for the purpose of correcting software bugs and add functions to the exchange, and to update software bugs and add functions to the exchange. There are operations such as patch input to rewrite the system file to partially modify it, and site data modification to partially modify the site data in response to equipment additions, line extensions, station number changes, etc. In these business sequences, OpS performs various control operations for NE as follows.

FIG. 15 shows an N having the physical memory configuration of FIG.
FIG. 16 shows file update in the software update sequence of E, FIG. 16 shows patch input, and FIG. 17 shows data change. FIG. 18 shows file update in the software update sequence of the NE having the physical memory configuration of FIG.

First, the file update sequence of the NE having the physical memory structure of FIG. 13 shown in FIG. 15 will be described. A new file is loaded into the FM1 of the 1st system by the first FUP NEW / control operation (this process Indicated in the middle knit). By the next CNV FUP OK / control operation, the file update restart processing is performed, the new file is loaded into MM0 and MM1 of both systems, and the NE starts up in the 1 system. Last FUP FI
By the control operation of N /, the new file is copied to the FM0 of the 0 system, and subsequently the backup files are collected in the DK0 and DK1 of both systems.

Next, the patch input sequence of the NE having the physical memory configuration of FIG. 13 shown in FIG. 16 will be described. A new patch is input to MM0 and MM1 of both systems by the first control operation of MLD PAT, PUP /. . By the next MLD PAT, SUP / control operation, the new patch is put into the new file in FM0 and FM1 of both systems. The last FST BFM, LAF / collects backup files in DK0 and DK1 of both systems.

The data change sequence of the NE having the physical memory configuration of FIG. 13 shown in FIG. 17 will be described below.
By the first control operation of TCA /, the data in the intermediate table (indicated by a thick ruled line in the figure) between MM0 and MM1 of both systems is changed. MM0 and M of both systems by the next control operation of TCH NEW /
The intermediate table of M1 is changed. FM0 and FM1 of both systems are changed by the control operation of ODB /, and the last FST BFM, LA
F / collects backup files in DK0 and DK1 of both systems.

The file update sequence of the NE having the physical memory configuration of FIG. 14 shown in FIG. 18 will be described below.
The first FUP NEW / control operation loads a new file into MM1 of system 1. By the next CNV FUP OK / control operation, the file update restart processing is performed and the NE starts up in the 1st system. By the last FUP FIN / control operation, backup files are collected in DK0 and DK1 of both systems.

[0009]

Normally, in the conventional software update control method, the control operation interface and control sequence performed by the OpS for the NE differ depending on the update type. Therefore, according to the conventional example, the NE If the update type is changed or added due to the specification change of
The control sequence of must be changed or added. Therefore, since the OpS side program is affected by the change of the NE side program, there is a problem that NE and OpS cannot be independently developed.

Depending on the configuration of the NE physical memory, O
Since the control operation interface and the control sequence performed by the pS for the NE are different, the NE model maintained by the OpS (for example, D70, ISM, D51, DM in the case of an exchange)
If S10, etc.) increases, according to the conventional example, the OpS control operation interface and control operation sequence must be added. Therefore, various vendors (especially overseas northern tel
Considering the multi-vendor environment where ecom, ericsson, ATT, etc.) provide NE, there is a problem that the interoperability between NE and OpS is not guaranteed.

An object of the present invention is to provide OpS and NE by logicalizing a control operation interface and a control operation sequence.
The goal is to enable the independent development of and ensure interoperability. Therefore, the OpS according to the present invention can flexibly cope with the change or addition of the update type on the NE side and the introduction of the NE of the new model.

[0012]

In order to solve the above-mentioned problems, the present invention represents the update status of software update by the value of the attribute indicating the update status in the class object of the OpS program, and It is represented by a state α that is a state that cannot be switched back, a state β that is a state that can be switched back from a high speed storage medium such as a file memory, and a state γ that is a state that can be switched back from a low speed storage medium such as a hard disk. Further, the control operation performed by the OpS on the NE is represented by execution β, execution γ, backup α, backup γ, and failback. Further, the OpS creates an instance of the class object upon the activation of the software update, and the NE notifies the OpS of the update status of the software update by changing the state. And OpS is NE
The update status of software update is managed by changing the attribute value of the instance of the class object triggered by the notification from, and the software update is controlled by the state transition of the instance.

In addition, for the introduction of other NEs and the addition of other software update types, the attribute indicating the state is added by subclassing the class object. Therefore, the present invention can solve the above-mentioned problems, and makes the OpS control operation interface for the NE independent of the NE model, update type, and vendor. It enables independent development of NEs and guarantees interoperability.

[0014]

Embodiments of the present invention will be described below with reference to the drawings. First of all, the progress of software update can be interrupted in a non-revertible state (this state is referred to as state α), a high-speed storage medium such as a file memory is in a revertible state (this state is referred to as state β), and a low speed such as a hard disk. A state in which switching back from the storage medium is possible (this state is called state γ)
The control operation interface is expressed by execution β, execution γ, backup α, backup γ, and failback.

FIG. 1 shows a file update sequence of the software update sequence of the NE having the physical memory configuration of FIG. 13 in this embodiment, FIG. 2 shows a data change sequence in this embodiment, and FIG. The patch input sequence in an Example is shown. Further, FIG. 4 shows a file update sequence in the software update sequence of the NE having the physical memory configuration of FIG. 14 in the present embodiment. The description of each sequence will be given later.

FIG. 5 is a diagram showing the inheritance relationship of the software update class. When it is desired to extend (detail) the update state and control operation, this class is subclassed and a new update state and control operation is defined in the subclass. To do. For example, when it is desired to extend (detailed) the “state β” into the “state β1” and the “state β2”, a new class “update class 1” is defined. This class has "β update state" as an attribute that extends "state β", and its value is "state β".
1 ”and“ state β2 ”. 6 to 8 show the inheritance relationship of class objects. As shown in FIGS. 6 to 8 and Table 1 below showing the state transition rules thereof, the update state (values: α, β, γ) as attributes, execution β, execution γ as OpS control operation (interface) for the exchange, A software update class having backup α, backup γ, and failback is defined as a superclass. In order to distinguish the two states β, the update state β is set as an attribute.
(Value: β1, β2), update class 1 having execution β2 as a control operation, update state γ (value: γ1, γ2) as an attribute, and execution γ2 as a control operation to distinguish state γ
Update class 2 with is defined as a subclass of the software update class.

[0017]

[Table 1]

These class objects and state transition rules are provided in the OpS program, and the state transition rules are provided in the NE program.

When a maintenance person or the like instructs OpS to update the intended software, OpS creates a corresponding instance. The initial state is when the update state is the α state. When the OpS performs the corresponding control operation on the NE, the NE updates the corresponding memory, determines the next state from the state transition rule, and transits to the state. Next, NE
Notifies OpS that the state has changed, OpS
Changes the update state of the instance, determines the next control operation from the state transition rule, and performs the control operation on the NE. The same process is repeated until the target software update is completed and the instance update state becomes the α state again.

FIG. 9 is a diagram showing a file update sequence for an NE having the physical memory configuration shown in FIG. 13 in this embodiment. This figure corresponds to FIG. 1, in which the first execution β control operation
The new file is loaded into the FM1 of the system, and the instance transits to the state β (β1). By the control operation of the next execution β2, the file update restart processing is performed, and MM0 of both systems,
The new file is loaded in MM1, NE starts in the 1st system, and the instance transits to state β2. By the control operation of the last execution α, the new file is copied to FM0 of system 0, the previous day's file and the guarantee file are collected in DK0 and DK1 of both systems, and the instance is in state α.
Transition to.

FIG. 10 is a diagram showing a patch insertion sequence for an NE having the physical memory configuration shown in FIG. 13 in this embodiment. This figure corresponds to FIG. 3, and in the figure, the new patch is input to MM0 and MM1 of both systems by the control operation of the first execution γ, and the instance transits to the state γ (γ1). By the control operation of the next execution γ2, the new patch is put into FM0 and FM1 of both systems,
The instance transits to state γ2. By the last execution α, the previous day's files are collected in DK0 and DK1 of both systems, and the instance transits to state α.

FIG. 11 is a diagram showing a data change sequence for an NE having the physical memory configuration shown in FIG. 13 in this embodiment. This figure corresponds to FIG. 2, and in the figure, the intermediate table of MM0 and MM1 of both systems is controlled by the control operation of the first execution β (the test call refers to this table, but the actual call refers to the old data). Data is changed and the instance transits to the state β. By the control operation of the next execution γ, this table of the MMs of both systems is changed, and the instance transits to the state γ (γ1). FM0 and FM1 of both systems are changed by the control operation of execution γ2, and the ion stance transits to γ2. By the last execution α, the previous day's files are collected in DK0 and DK1 of both systems, and the instance transits to state α.

FIG. 12 is a diagram showing a file update sequence for an NE having the physical memory configuration shown in FIG. 14 in this embodiment. This figure corresponds to FIG. 4, and in the figure, by the control operation of the first execution β,
The new file is loaded into the 1-system MM1, and the instance transits to the state β (β1). The file update resuming process is performed by the control operation of the next execution β2, the NE is started in the 1-system, and the instance transits to the state β2. By the control operation of the last execution α, the previous day file and the guarantee file are collected in DK1 and DK2 of both systems, and the instance transits to the state α.

[0024]

As described above, according to the present invention,
It is possible to realize a control operation interface and a control sequence for performing software update that does not depend on the physical memory configuration or update type. Therefore, OpS can realize software update without being aware of the physical memory configuration and update type. In other words, the logicalization of the control operation interface and the control sequence enables independent development of OpS and NE and guarantees interoperability. In addition, even if the control operation interface and control sequence are changed, by subclassing the superclass,
Since it is possible to flexibly deal with the addition or change of the update type and the introduction of the new model NE, the change of the OpS program which is affected by the change of the NE program is localized and the function can be easily added. , OpS programs can be used more easily.

[Brief description of drawings]

FIG. 1 is a diagram showing a file update sequence in this embodiment.

FIG. 2 is a diagram showing a local data change sequence in the present embodiment.

FIG. 3 is a diagram showing a patch insertion sequence in this embodiment.

FIG. 4 is a diagram showing a file update sequence of an NE having another physical memory configuration in the present embodiment.

FIG. 5 is a diagram showing inheritance relationships of software update classes.

FIG. 6 is a diagram showing inheritance relationships of class objects.

FIG. 7 is a diagram showing inheritance relationships of class objects.

FIG. 8 is a diagram showing inheritance relationships of class objects.

FIG. 9 is a diagram showing a file update sequence in the present embodiment.

FIG. 10 is a diagram showing a patch insertion sequence in this embodiment.

FIG. 11 is a diagram showing a local data change sequence in the present embodiment.

FIG. 12 is a diagram showing a file update sequence of an NE having another physical memory configuration in the present embodiment.

FIG. 13 is a diagram showing an example of an NE having a dual memory configuration of MM, FM, and DK.

FIG. 14 is a NE having a dual memory configuration of MM and DK.
It is a figure which shows the example of

FIG. 15 is a diagram showing a conventional file update sequence.

FIG. 16 is a diagram showing a conventional patch insertion sequence.

FIG. 17 is a diagram showing a conventional data change.

FIG. 18 is a diagram showing a file update sequence of an NE having another conventional physical memory configuration.

[Explanation of symbols]

 MM main memory FM file memory DK hard disk

Claims (2)

[Claims] 1. A software update control method, wherein an operating system remotely controls a network element such as a switch, the operating system remotely controls the network element via a communication network to update the network element. The update status of the software update is expressed by the value of the attribute indicating the update status in the class object of the operating system program, and it is in the state α that is not revertible, and the state that can be reverted from the high speed storage medium such as file memory. Is represented by a state β and a state γ that is a state capable of switching back from a low-speed storage medium such as a hard disk, and the operating system executes a control operation on the network element β, execution γ, backup α,
Expressed by backup γ and failback, the operating system creates an instance of the class object at the trigger of the software update, the network element notifies the operating system of the update status of the software update, and the operating system notifies the network. A software update control method characterized in that the update status of software update is managed by changing the attribute value of an instance of a class object upon notification from an element, and software update is controlled by state transition of the instance. 2. The software update control method according to claim 1, wherein an attribute indicating a state is added by subclassing the class object when introducing another network element or adding another software update type.