JP2006309413A - Software failure restoring system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To return to an old configuration only by held information at the time of occurrence of a failure in the middle of re-configuration by downloading a configuration management profile and holding difference information extracted by comparing with a configuration in operation. <P>SOLUTION: This software failure restoring system is equipped with an application package 110 and middleware 120 in a communication equipment 100. An object control part 130 of the middleware has a configuration management part 131, a connection management part 132 and a difference analysis part 133. The object configuration management part 131 of a middleware has an object configuration repository 142, an additional object information repository 143 and a deletion object information repository 144. The object control part 130 has a failure restoring part 134 which returns the configuration to the one operated last time based on the difference information held in the additional object information repository 143 or the deletion object information repository 144 when the failure occurs. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a software failure recovery system in a function update technique that changes the function of a communication device such as a radio device by replacing software and enables application to various systems by a single device.

Up to now, various approaches have been taken for recovery methods in the event of a failure in software replacement (function update) technology by downloading communication devices and the like.
A common disaster recovery method is to manage software resources in a distributed environment, and to store the file information of the entire application related to the old and new versions in the management table and to return to the old version of the application (if necessary) It has been proposed (see, for example, Patent Document 1).

  In addition, as a firmware remote update method, when downloading from the base station to the remote device, the address area (old part) to be updated is saved in the save area of the remote device memory (difference save). When startup fails, a method has been proposed in which partial update and restoration are realized by restoring the saved old part to the original address area (see, for example, Patent Document 2).

  Also, in the operation program update method in the mobile communication system, after a new program is downloaded from the higher-level device to the lower-level device, if the lower-level device determines a start failure, the higher-level device is notified of the failure and notified. Further, a method has been proposed in which the host device is restored by instructing the lower device to restart the old program. This is realized by having two memories in the lower-level device, holding the old and new programs, and switching the programs based on the determination of the higher-level device (see, for example, Patent Document 3).

  In addition, it is a software update method for mobile communication systems, etc., and when the new software is downloaded, the current software is held, and by the lower device, the trial operation result with the new software and the compatibility with the hardware are judged by itself. A method for restoring to the current operation (old software) when necessary (failure) has also been proposed (see, for example, Patent Document 4).

JP-A-10-171635 JP 2000-330777 A JP 2001-134428 A JP 2003-122574 A

  However, in Patent Document 1 described above, since the application file is registered in a software area such as a work memory on the terminal and restarted in units of application files when necessary, the software replacement method is restored. Partial replacement of only application file differences is not supported.

  In addition, processing related to connection such as connection of objects is not required at the time of recovery, but when an application package is composed of multiple files and data is exchanged between files, the interface specifications for communication are not included. Since there is no provision, the interface specification cannot be supported unless it is fixed. That is, there is a problem that interface specifications such as data to be transferred cannot be changed.

  In addition, since the managed version is one each for new and old, there is a problem that it is possible to return to the configuration used immediately before at the time of failure, but not to any previous configuration.

  Moreover, in patent document 2, a version is acquired from a remote device in a base station, a replacement part is identified by analyzing an update part from the acquired version, and only a specific address area of firmware to be replaced is downloaded. Therefore, the remote device only needs to save the address area instructed by the base station, and only the corresponding address area needs to be restored in the event of a failure, so that the difference can be saved and restored without the need for analysis processing by the remote device. Can do. However, since each software area such as work memory and flash ROM (Read Only Memory) on the terminal is replaced, area management such as work memory and flash ROM address and size is required, which makes the management complicated. It was.

  In addition, since an arbitrary address area is replaced from the entire fixed address area, there is a problem that it is difficult to restore the original configuration when a function is added. In addition, when a large number of terminals are managed in order to analyze the difference at the base station, there is a problem that the analysis processing load by the base station increases and management becomes difficult.

  In addition, the old and new software configurations are held at the same time, and these are replaced to ensure reliability. However, the software in the updated part detects a failure only during functional verification after reconfiguration. However, there is a problem that the time until the failure is detected cannot be detected.

  Also, in Patent Document 3, the entire program is downloaded from the host device to the lower device, stored for each program in the lower device, and if the activation fails, the saved old program is restarted. Can be easily restored without the need for complicated processing, but it does not support partial replacement of programs, so the entire program information must be retained for restoration. In other words, there is a problem that a sufficient capacity is required for resources such as a memory.

  Further, in Patent Document 4, since the entire program is downloaded from the host device to the lower device, and the downloaded new program is trial run, if a failure occurs as a result of the trial run, the system is restored to the original configuration. Although updating and recovery can be performed safely, there is a problem that once updated, the area saved for recovery is overwritten by a new program, so it cannot be restored to the original configuration. .

  In addition, as in Patent Document 3, it does not support partial replacement of programs, so information for the entire program must be retained for recovery, and sufficient resources such as memory are required. There is also a problem.

  Further, these conventional software failure recovery methods do not support dynamic replacement, and all of them have problems such as requiring restart at the time of recovery and increasing time until recovery.

  The present invention has been made to solve the above-described problems, and is information that defines connection relationships (connections) of objects (functions) constituting software in a general application package in a configuration management profile. When a new object is downloaded by resolving a bug in the program or adding a function, a configuration management profile that describes the new configuration is downloaded, and the difference is extracted by comparing it with the configuration in operation However, by retaining the extracted difference information, some kind of failure occurred, such as failure to start an object during reconfiguration, or connection failure due to mismatched specifications such as interface specifications with other objects. In this case, it is possible to revert to the old configuration using only the minimum necessary information that has been retained. To achieve a software failure recovery system that can achieve partial recovery of only differences by exchanging object units and reduce the overhead of reconfiguration such as management information, analysis processing amount, and processing time. Objective.

  The software failure recovery system according to the present invention manages a function of a communication device as a set of objects, and implements various functions in a single device by exchanging objects and switching interconnections between objects. A software failure recovery system according to claim 1, wherein the application package comprises a configuration management profile describing object connection relations and a group of objects to be managed, which are downloaded from a management device as a server in the communication device, and the application package. Middleware comprising an object control unit and an object configuration management unit for supporting communication between objects in the middleware, and the middleware object control unit is based on the configuration management profile. Control the object to establish the connection of the object based on the configuration information managed after starting, stopping, and registering the configuration A connection management unit, and a difference analysis unit that compares a new configuration management profile with an object configuration in operation at the time of object update and analyzes a difference, and the object configuration management unit of the middleware stores an object configuration in operation An object configuration repository that holds, an additional object information repository that holds information on additional objects extracted as differences by the difference analysis unit, and a deleted object information repository that holds information on deleted objects, and the object control unit Of the middle of the reconstruction Difference information stored in the additional object information repository or the deleted object information repository when a failure occurs due to a connection failure due to a failure in starting an object or a specification failure such as interface specifications with other objects And a failure recovery unit for returning to the configuration operated last time.

  According to the present invention, connection relations of objects constituting software in a general application package are established based on information defined in the configuration management profile, and new objects are downloaded by correcting problems in the program or adding functions. When downloading, download the configuration management profile that describes the new configuration, extract the difference by comparing it with the configuration in operation, and retain the extracted difference information. If any failure occurs, such as failure to start an object or connection failure due to a specification mismatch with the interface specifications with other objects, the old configuration is restored using only the minimum required information. Make it possible. Further, by replacing the object unit, partial recovery of only the difference can be realized, and the overhead for reconfiguration such as management information, analysis processing amount, and processing time can be reduced.

  The software failure recovery system according to the present invention is based on CORBA (Common Object Request Broker Architecture), which is an international standard for distributed object technology, and is based on information that defines connection relationships of objects using a configuration management profile. By establishing a connection relationship between them and analyzing the object to be replaced when replacing the object, partial replacement of the object group in the application package is performed. When some kind of failure occurs, such as a connection failure due to a mismatch of specifications such as interface specifications with the object, it is analyzed as a difference and restored to the configuration used last time based on the stored difference information.

Embodiment 1 FIG.
<Difference management and rollback only for differences>
FIG. 1 is a diagram showing a functional configuration of a software failure recovery system necessary for realizing the present invention. The software failure recovery system shown in FIG. 1 manages the functions of communication devices as a set of objects, and implements various functions in a single device by exchanging objects and switching interconnections between objects. The software failure recovery system in FIG. 1 is provided in a communication device (terminal station, mobile station, base station, or the like) 100 whose function is changed by software replacement, and is a management target downloaded from the management apparatus 160 via the network. An object control unit and object configuration management for supporting communication between an application package (a set of related functions such as a file necessary for realizing a function) 110 composed of objects and an object in the package Middleware 120 made of, and a OS (Operating System) 150 underlying the software in the communication device. Note that the management device 160 becomes a download source of software newly created by the software developer, and executes download and update instructions.

  The application package 110 is a management target in the package and a profile 111 necessary for function update such as connection information of objects constituting the application package 110 and interface information provided by each object for connection between objects. The profile 111 is composed of a configuration management profile 112 that describes the connection relationship of functions (objects) downloaded from the management device in the communication device, and a CORBA standard description format that is an international standard for distributed object technology. And an interface definition language (IDL) file 113 in which information on the interface provided by each object in the package is described.

  The middleware 120 restores the object configuration repository information to the original object configuration when a failure occurs, an object management unit that manages the object configuration, a connection management unit that manages object connections, a difference analysis unit that performs object difference analysis The object control unit 130 includes a failure recovery unit, a history management unit that manages the result of the difference analysis as a history, and an object configuration management unit 140 that manages a repository for constructing an object configuration.

  The object control unit 130 fetches data from the configuration management profile 112, registers and manages configuration information in the object configuration repository 142, and the object information based on the configuration information managed in the object configuration repository after the configuration registration. Based on information in the connection management unit 132 that controls objects for establishing a connection relationship (connection), and the object configuration repository 142 that holds the new configuration management profile and the object configuration in operation when the object is updated The difference analysis unit 133 that analyzes the difference by comparing the object configuration with the new object configuration and registers the analysis result in the additional object information repository 143 and the deleted object information repository 144, and when a failure occurs Based on the additional object information repository 143 and the deleted object information repository 144 extracted by the difference analysis unit 133, the failure recovery unit 134 that restores the information of the object configuration repository 142 to the object configuration before update and the difference analysis unit 133 extracted It has a history management unit 135 that restores information in the object configuration repository 142 to an arbitrary object configuration that has been used in the past by storing the difference information for each update and managing the information as a history.

  The object configuration management unit 140 stores the object configuration repository 142 that holds the object configuration in operation, and information on the newly added object among the difference information extracted by the difference analysis unit 133 for recovery from a failure. Additional object information repository 143 to be deleted, deleted object information repository 144 that holds information on objects to be replaced among the difference information, and an object that holds the difference information accumulated for each update by the history management unit 135 as a history The configuration history repository 145 includes a repository group 141 necessary for constructing and restoring an object configuration.

  Next, in the communication device 100 whose function is changed by software replacement, a software application package 110 newly developed by a software developer is downloaded from the management device 160, and a plurality of objects existing in the downloaded package are between. By establishing a connection relationship, when updating the function by replacing software until the function of the communication device is realized, the specification of the object startup failure or interface specification with other objects does not match during the reconfiguration In the event of a failure such as a connection failure due to a failure, an operation at the time of failure recovery that returns to the old configuration with only the minimum necessary information that is held will be described.

  A block diagram showing the functional configuration of the present invention shown in FIG. 1, an example when an object in the application package 110 shown in FIG. 2 is restored after a failure occurs, and a table of the object configuration repository 142 shown in FIG. An example of the structure, an example of the object configuration information of the configuration management profile 112 shown in FIG. 4, an example of the table structure of the additional object information repository 143 shown in FIG. 5, and a table structure of the deleted object information repository 144 shown in FIG. This will be described with reference to the flowchart shown in FIG.

  In the first embodiment, in the object configuration as shown in FIG. 2, an operation when a failure occurs after restoration by replacing the object b with b ′ due to the version upgrade of the object b and recovery is described. . However, it is assumed that the object b ′ is changed only in the program, and the interface is not changed. For this reason, the connection destination of the object a is not changed (the connection destination b is changed to b ′ by the middleware 120).

  First, in step S <b> 100, a new configuration management profile 112 is downloaded from the management device 160 to the communication device 100.

  Next, in step S101, the configuration management unit 131 identifies that the update instruction from the management device 160 or the instruction from the user of the communication device 100 or the download has been completed, and requests the difference analysis unit 133 to make a difference analysis request. . Next, the difference analysis unit 133 extracts the difference between the new configuration management profile 112 and the information in the object configuration repository 142 that is in operation.

  In the analysis of the difference, the object names in the object configuration repository 142 are compared in order. For example, if the configuration information of the object in operation is FIG. 3 and the object configuration of the downloaded new configuration management profile 112 is FIG. 4, the number of objects constituting the application package 110 is the same, but the object name b is It turns out that it changed to b '. For this reason, the difference analysis unit 133 determines that the difference is the object b, and adds the information of the new object b ′ as an additional object to the additional object information repository 143 and stores the information of the old object b to be replaced. The deleted object is registered in the deleted object information repository 144 (step S102).

  Next, in step S103, upon receiving the difference analysis result from the difference analysis unit 133, the configuration management unit 131 updates the object configuration repository 142, requests the management device 160 to download a new object b ′, and communicates with the communication device. Download to 100.

  Next, in step S104, the configuration management unit 131 disconnects the connection relationship between the activation of the downloaded new object b ′ and the adjacent object to which the old object b is connected.

  Next, in step S105, the configuration management unit 131 requests the connection management unit 132 to establish a connection relationship. Upon receiving the request, the connection management unit 132 reads the configuration information from the object configuration repository 142, searches for an IOR (Interoperable Object Reference) used as the address of the target new object b ′, and based on the object configuration information and the IOR. Establish a connection relationship for the new object b ′. After the establishment, the difference update is completed by stopping the object b which is information of the old object.

  However, if any failure occurs during this reconfiguration, such as failure to start an object, connection failure due to specification mismatch with interface specifications with other objects, data registration failure to the repository, etc. In order to recover from the failure, it is necessary to return to the original configuration before the update.

  Next, an operation for recovering a failure that has occurred at the time of updating will be described.

  In step S106, when the failure is detected by the failure recovery unit 134, the object configuration information in the object configuration repository 142 is recovered to the information before update based on the information in the additional object information repository 142 and the deleted object information repository 144. That is, since the object added from FIG. 5 and FIG. 6 is b ′ and the deleted object is b, the information related to the object b ′ is deleted from the object configuration repository 142, and the object b is newly added. Add information. As a result, it is possible to return to the original object configuration information before the update.

  Next, in step S107, the configuration management unit 131 that has received a recovery request from the failure recovery unit 134 activates the object b, which is an object held in the deleted object information repository 144, and establishes a connection relationship with the connection management. Request to section 132.

  Next, in step S108, the connection management unit 132 that has received the request reads the configuration information from the object configuration repository 142, searches for an IOR (Interoperable Object Reference) to be used as the address of the target old object b, and sets the object configuration. The connection relationship of the old object b is established based on the information and the IOR. After the establishment, the object b ′ which is information on the new object is stopped.

  Next, in step S109, upon receiving the connection completion result from the connection management unit 132, the failure recovery unit 134 clears the information stored in the additional object information repository 143 and the deleted object information repository 144, thereby recovering the failure. Processing is complete.

  In this example, the example of changing the object name is described. However, not only the object name but also the version number and other information held in the object configuration repository 142 should be compared. Can do.

  Further, if there is a sufficient resource such as a memory capacity of the communication device, the object may be used without being stopped. In other words, it is also possible to keep the computer waiting while it is activated. On the other hand, if the resource seems to be small, it can also be realized by stopping the object, deleting the object file, and then downloading again at the time of recovery.

  Furthermore, although the table configuration is shown in the configuration management profile 112 of FIG. 4, if such information is described, it may be described as a text file such as XML (eXtensible Markup Language).

  As described above, according to the first embodiment, the difference information extracted by the difference analysis unit 133 is retained, so that the object activation failure or the interface specification with other objects during reconfiguration. If some kind of failure occurs, such as connection failure due to non-matching specifications, data registration failure, etc., it is possible to restore the information before update by holding the difference information before update. Therefore, a safe function update can be realized.

  In addition, since it is possible to return to the object configuration before the update with only the minimum necessary information held as a difference, the overhead required for reconfiguration such as management information, analysis processing amount, processing time can be reduced. it can.

  Unlike conventional software failure recovery methods, it is not necessary to manage areas such as work memory and flash ROM addresses, and it is only necessary to manage information related to objects, so that management can be facilitated.

  Also, by managing the interface information and analyzing the difference together with the configuration management profile 112, even if the interface specification is changed, it is possible to recover from the failure only with the difference information.

  Furthermore, based on CORBA, which is an international standard for distributed object technology, the connection relationship of objects (processes) to be downloaded is managed by an indirect connection relationship based on interface information (IDL). Since a connection relationship with an existing adjacent object can be established only by activating a new object, there is no need to restart the program when replacing the object, and it is possible to recover dynamically and rapidly.

Embodiment 2. FIG.
<Rollback operation using history information during failure recovery>
In the first embodiment described above, in the communication device 100 whose function is changed by software replacement, a software application package 110 newly developed by a software developer is downloaded from the management apparatus 160 and exists in the downloaded package. By establishing a connection relationship between multiple objects, when updating the function by replacing software until the function of the communication device is realized, object activation failure during reconfiguration or interface specifications with other objects When some kind of failure occurs, such as connection failure due to non-conforming specifications, etc., it was about the operation at the time of failure recovery that returns to the old configuration with only the minimum necessary information that was retained. In Form 2, history information is used at the time of failure recovery. In operation of the roll back.

  In other words, each time the object configuration is reconfigured, the history management unit 135 stores the difference between the object configuration repository 142 that is an object configuration being operated and the new object configuration, and the added object information repository 143 and the deleted object information repository 144. Information is acquired and stored in the object configuration history repository 145 as a difference history and managed. If any failure occurs during the reconfiguration, the history management unit 135 selects a past object configuration with an operation record from the object configuration history repository 145, and the connection management unit 132 selects the selected object configuration. The operation at the time of failure recovery for returning to an object configuration with a track record that has been used in the past by re-establishing the object connection relationship based on the above will be described.

  This embodiment 2 is a block diagram showing the functional configuration of the present invention shown in FIG. 1, an example of change in the object configuration shown in FIG. 8, and an object configuration history repository that holds a history of differences in object configuration shown in FIG. This will be described according to the flowchart shown in FIG.

  In the second embodiment, the operation when the object configuration is changed as shown in FIG. 8 and the configuration of the fourth stage is restored to the configuration of the second stage will be described.

  First, in step S200, the difference analysis unit 133 extracts difference information that becomes an added object and a deleted object for each function update.

  Next, in step S201, upon receiving the result of the difference analysis from the difference analysis unit 133, the history management unit 135 sets the object information as a difference based on the information in the added object information repository 143 and the deleted object information repository 144, and the object configuration history. Register in the repository 145. That is, only the difference from the previous line is registered.

  For example, when the initial configuration state of the first level in FIG. 8 is changed to the second level configuration (assuming that the object b has been upgraded), the additional object is b ′ and the deleted object is b. Therefore, it is determined that b is replaced, and only the object b ′ is registered in the object configuration history repository 145 as difference information. In addition, if there is no change, a no-change flag (indicated by an arrow in FIG. 9) is set, and when the difference information ends, an end flag (set to “null” in FIG. 9) in the last column of the corresponding row. Is set for each line. Note that the end flag is added to the end of the line even when it is deleted (second row in FIG. 9). In this way, FIG. 9 shows a table in which only the difference history is accumulated. This process is registered every time the object configuration is changed (step S202).

  However, if any failure occurs during this reconfiguration, such as failure to start an object, connection failure due to specification mismatch with interface specifications with other objects, data registration failure to the repository, etc. In order to recover from a failure, it is necessary to revert to a past configuration with operational experience.

  Next, an operation for recovering a failure that has occurred at the time of updating will be described.

  Next, in step S203, the history management unit 135 selects recoverable information from the objects existing on the communication device 100 and the information in the object configuration history repository 145, and uses the information in the object configuration repository 142 based on that information. Return to the original object configuration. Here, the recoverable information indicates the presence / absence of an object file on the communication device 100 and whether it is operating as a process. This is intended to restore to a configuration that preferentially uses an existing object, or to restore a communication program suitable for a corresponding area in a communication device such as a wireless device.

  Next, in step S204, the configuration management unit 131 that has received a request for recovery of the registered information from the history management unit 135 restarts the objects to be recovered (a and b ′), and establishes a connection relationship with the connection management. Request to section 132. If it is operating as a process, the restart process is unnecessary.

  Next, in step S205, the connection management unit 132 that has received the request reads the configuration information from the object configuration repository 142 and searches for an IOR (Interoperable Object Reference) that is used as the addresses of the target old objects a and b ′. The connection relationship between the old objects a and b ′ is established based on the object configuration information and the IOR. After the establishment, the objects a ′, e, and f which are information on the new object are stopped.

  As described above, according to the second embodiment, when any failure occurs during the reconfiguration, the object configuration history repository 145 manages the history of the configuration that has been operated in the past, thereby updating the configuration. In addition to returning to the previous configuration, it is possible to select a past object configuration with a track record of operation.

  In addition, by restoring an object configuration that preferentially uses existing objects, it is possible to perform high-speed restoration and automatic restoration to a communication program suitable for the corresponding area in a communication device such as a wireless device. .

  Compared with the method of managing the configuration history of all objects as a version by managing only the difference in the information managed in the object configuration history repository 145, the overhead of reconfiguration such as history information, analysis processing amount, processing time, etc. Can be reduced.

Embodiment 3 FIG.
<Rollback to any object configuration using history information>
In the second embodiment described above, every time the object configuration is reconfigured, the object configuration repository 142 that is the object configuration being operated in the history management unit 135 and the additional object information repository 143 that is the difference between the new object configuration and the deletion are deleted. Information in the object information repository 144 is acquired, stored in the object configuration history repository 145 as a difference history, managed, and when any failure occurs during reconfiguration, the history management unit 135 causes the object configuration history repository to By selecting a past object configuration with a track record of operation from 145 and reestablishing the object connection relationship in the connection management unit 132 based on the selected object configuration, the object configuration with a track record of operating in the past is obtained. About the operation at the time of failure recovery Although there was a hand, in the third embodiment, using the history information at the time of failure recovery, In operation to roll back to any object configuration.

  That is, each time the object configuration is reconfigured, the information of the added object information repository 143 and the deleted object information repository 144 that is the difference between the object configuration repository 142 that is the object configuration being operated in the history management unit 135 and the new object configuration. Is stored in the object configuration history repository 145 as a difference history, managed, and an update instruction to an arbitrary object configuration with an operation record from the user of the management device 160 or the communication device 100 regardless of the occurrence of a failure. In the past, the history management unit 135 selects the object configuration instructed from the object configuration history repository 145, and the connection management unit 132 reestablishes the object connection relationship based on the selected object configuration. Operation The operation of the fault recovery time to return to any of the object configurations that have had experience described.

  FIG. 8 is a block diagram showing the functional configuration of the present invention shown in FIG. 1, an example of a change in the object configuration shown in FIG. 8, and an object configuration history repository that holds the difference history of the object configuration shown in FIG. This will be described using an example of the table structure.

  As in the second embodiment, the difference analysis unit 133 extracts difference information that becomes an additional object and a deletion object for each function update, and the history management unit 135 registers object information that becomes a difference in the object configuration history repository 145. To go.

  Next, an instruction to return to the past object configuration is requested from the user of the management device 160 or the communication device 100 to the configuration management unit 131.

  Next, the configuration management unit 131 that has received the request requests the history management unit 135 to restore the object configuration specified by the user of the management device 160 or the communication device 100. In the third embodiment, as shown in FIG. 8, it is assumed that an instruction to restore the object configuration from the fourth level configuration to the second level configuration is issued.

Next, the history management unit 135 that has received the request returns the information in the object configuration repository 142 to the object configuration specified by the user of the management device 160 or the communication device 100 based on the information in the object configuration history repository 145 (FIG. 9). Reflects the configuration of the second stage.
The subsequent processing is equivalent to the processing after step S204 of the second embodiment.

  As described above, according to the third embodiment, the object configuration history repository 145 manages the history of the object configuration that has been operated in the past, so that the management device 160 and the communication device 100 can be used regardless of the occurrence of a failure. It becomes possible to select an arbitrary past object configuration with a track record of operation by an instruction from the user.

  In addition, according to an instruction from the user of the management device 160 or the communication device 100, it is possible to restore to the optimum communication program (communication method) suitable for the corresponding area in the communication device such as a wireless device.

Embodiment 4 FIG.
<Rollback operation during multiplexing>
In the third embodiment described above, every time the object configuration is reconfigured, the object configuration repository 142 which is the object configuration being operated in the history management unit 135 and the additional object information repository 143 which is the difference between the new object configuration and the deletion are deleted. Information of the object information repository 144 is acquired, stored as a difference history in the object configuration history repository 145, managed, and any operation record from the user of the management device 160 or the communication device 100 regardless of the occurrence of a failure. In response to an update instruction to the object configuration, the history management unit 135 selects the object configuration instructed from the object configuration history repository 145, and the connection management unit 132 reestablishes the connection relationship of the objects based on the selected object configuration. By doing , But in which was the operation of the fault recovery time for returning to any object configuration proven that has been operating in the past, in the fourth embodiment, the operation of the roll-back during multiplexing will be described.

  That is, when the history management unit 135 selects an arbitrary object configuration with an operation record from the object configuration history repository 145 and the connection management unit 132 re-establishes the object connection relationship based on the selected object configuration, By multiplexing the configuration processing and processing in parallel, any object configuration that has been used in the past does not affect the object configuration in operation, even in the event of a failure and other than when a failure occurs The operation of the recovery method for shortening the switching time required for reconfiguration at an arbitrary timing for an arbitrary object configuration will be described.

  FIG. 8 is a block diagram showing the functional configuration of the present invention shown in FIG. 1, an example of the change in the object configuration shown in FIG. 8, and an object configuration history repository that holds the difference history of the object configuration shown in FIG. 11, an example of object reconstruction by multiplexing shown in FIG. 11, an example of a table structure of a multiplexed object configuration repository at the time of restoration shown in FIG. 12, and multiplexing at the time of switching after restoration shown in FIG. 13. The example of the table structure of the object configuration repository will be described with reference to the flowchart showing the operation in the fourth embodiment of the present invention shown in FIG.

  In this embodiment, an operation when the object configuration is changed as shown in FIG. 8 and the configuration of the fourth stage is restored to the configuration of the second stage will be described.

  First, in step S400, the difference analysis unit 133 extracts difference information that becomes an added object and a deleted object for each function update.

  Next, in step S401, upon receiving the result of the difference analysis from the difference analysis unit 133, the history management unit 135 registers object information as a difference in the object configuration history repository 145. That is, only the difference from the previous line is registered.

For example, when the initial configuration of the first level in FIG. 8 is changed to the second level configuration (assuming that the object b is upgraded), the added object is b ′ and the deleted object is b. Therefore, it is determined that b is replaced, and only the object b ′ is registered in the object configuration history repository 145 as difference information. In addition, if there is no change, a no-change flag (indicated by an arrow in FIG. 9) is set, and when the difference information ends, an end flag (set to “null” in FIG. 9) in the last column of the corresponding row. Is set for each line. Note that the end flag is added to the end of the line even when it is deleted (second row in FIG. 9). In this way, FIG. 9 shows a table in which only the difference history is accumulated.
This process is registered every time the object configuration is changed (step S402).

  Next, when a request is received from the user of the management device 160 or the communication device 100 to the configuration management unit 131 to return to the past object configuration (step S403), the configuration management unit 131 that has received the request sends the management device 160 or the communication device. The history management unit 135 is requested to restore the object configuration designated by 100 users (step S404). In the fourth embodiment, as shown in FIG. 8, it is assumed that an instruction to restore the object configuration from the fourth level configuration to the second level configuration is issued.

  Next, in step S405, the history management unit 135 that has received the request uses the object configuration specified by the user of the management device 160 or the communication device 100 based on the information in the object configuration history repository 145 to construct the object configuration repository 142. (Side 2) is registered (FIG. 12).

  Next, in step S406, the configuration management unit 131 that has received a request for recovery of the information registered from the history management unit 135, based on the construction system (Side2) of the object configuration repository 142, restores objects (a and b ′). ) To request the connection management unit 132 to establish a connection relationship.

  Next, in step S407, the connection management unit 132 that has received the request reads the configuration information from the construction system (Side2) of the object configuration repository 142 and uses it as the address of the target old objects (a and b ′). (Interoperable Object Reference) is searched, and the connection relationship between the old objects (a and b ′) is established based on the object configuration information and IOR.

  Next, in step S408, upon receiving notification of connection relation establishment from the connection management unit 132, the configuration management unit 131 restores the object configuration by switching between the operational system (Side 1) and the construction system (Side 2), and before the restoration. The objects a ′, e, and f which are the information of the objects are stopped. At the same time, the side information in the object configuration repository 142 is updated as shown in FIG.

  Thereafter, when there is an instruction to update the object configuration from the user of the management apparatus 160 or the communication device 100, the object configuration is restored after the object is once constructed in the construction system (Side 2).

  As described above, according to the fourth embodiment, when the connection management unit 132 reestablishes an object connection relationship based on the selected object configuration, the object reconfiguration processing is multiplexed and processed in parallel. Any object configuration that has been used in the past has no effect on the object configuration in operation, and any object configuration can be restored to any object configuration at any time and with reduced switching time for reconfiguration. It becomes possible. That is, the stop time of the communication device for switching can be shortened.

  In addition, the object can be multiplexed and managed while the object is operating without stopping the object, so that even when a failure occurs, high-speed switching can be used to shorten the stop time of the communication device, enabling high-speed recovery. Become.

Embodiment 5. FIG.
<Rollback behavior when changing object startup parameters>
In the above-described fourth embodiment, the history management unit 135 selects an arbitrary object configuration with an operation record from the object configuration history repository 145, and the connection management unit 132 reestablishes the connection relationship of the objects based on the selected object configuration. When reconfiguring, the object reconfiguration process is multiplexed and processed in parallel, so any object configuration that has been used in the past can be changed to any object configuration without affecting the current object configuration. In the fifth embodiment, the rollback operation when the object activation parameter is changed will be described.

  In other words, when the object configuration is changed, when the object whose object name and version number are the same as the active object and only the object activation parameter is replaced, the old configuration is restored due to a failure such as object activation failure. The operation of the failure recovery method will be described.

  In the fifth embodiment, a block diagram showing the functional configuration of the present invention shown in FIG. 1, an example of the table structure of the object configuration repository shown in FIG. 3, and an object activation parameter in the application package shown in FIG. An example of when a failure occurs after recovery after a change and recovery, an example of object configuration information of a new configuration management profile shown in FIG. 16, and an example of a table structure of an additional object information repository shown in FIG. An example of the table structure of the deleted object information repository shown in FIG. 4 and an example of the table structure of the updated object configuration repository shown in FIG.

  In the fifth embodiment, in the object configuration as shown in FIG. 15, a failure occurs after the activation parameter of the object b is changed and restarted, and the object is recovered by restarting with the activation parameter of the original object. The operation when doing this will be described.

  First, as in the first embodiment, a new configuration management profile 112 (FIG. 16) is downloaded from the management device 160 to the communication device 100.

  Next, the configuration management unit 131 identifies that the update instruction from the management device 160 or the instruction from the user of the communication device 100 or the download has been completed, and requests a difference analysis request to the difference analysis unit 133. Next, the difference analysis unit 133 extracts a difference between the information in the object configuration repository 142 which is the information in operation in FIG. 16 and FIG. The difference analysis shows that the number of objects constituting the application package 110, the object name, and the version number are the same, but the activation parameter of the object b is added (-Param). For this reason, the difference analysis unit 133 determines that the difference is the object b, and adds the information of the new object b to which the activation parameter has been added to the additional object information repository 143 as an additional object. Information on the object b is registered in the deleted object information repository 144 as a deleted object (see FIGS. 17 and 18).

  Next, upon receiving the difference analysis result from the difference analysis unit 133, the configuration management unit 131 updates the object configuration repository 142 (see FIG. 19).

  Next, after updating the object configuration repository 142, the configuration management unit 133 requests the connection management unit 132 to disconnect the connection relationship with the adjacent object a to which the old object b is connected. The connection management unit 132 performs connection disconnection processing. The configuration management unit 133 receives the disconnection completion notification, stops the old object b, adds an activation parameter, and activates the object b again.

  During this restart or reconfiguration, some kind of failure occurs, such as failure to start an object, failure to connect due to mismatched specifications such as interface specifications with other objects, failure to register data in the repository, etc. When the failure is detected by the recovery unit 134, the object configuration information in the object configuration repository 142 is recovered to the information before update based on the information in the additional object information repository 142 and the deleted object information repository 144. That is, since it can be seen from FIG. 17 and FIG. 18 that the replaced object is b, the information related to the object b is deleted from the object configuration repository 142 and returned to the information of the old object b for which no activation parameter is specified ( Return to FIG.

  Subsequent processing can be restored to the pre-update object configuration by performing processing subsequent to step S107 of the first embodiment, such as restart of the old object b and reconnection with the adjacent object.

  In the fifth embodiment, since the same object name is exchanged, the object to be exchanged is temporarily stopped and then a new object is activated again. However, multiplexing as in the fourth embodiment is performed. If they are processed in parallel, they can be started simultaneously. This is because different object IDs such as process IDs are assigned when an object is activated, so that the same object name can be identified.

  As described above, according to the fifth embodiment, when the object configuration is changed, even if the object name and version number of the active object and the new object are the same and only the activation parameter of the object is different, the difference By extracting and holding the difference information in the analysis unit 133, it is possible to restore the information before the update if any failure occurs.

Embodiment 6 FIG.
<Operation to detect failures related to starting and stopping of objects>
In the above-described fifth embodiment, when an object configuration is changed, an object that has the same object name and version number as the object being operated and only an object that has a different activation parameter is replaced. Although the operation of the failure recovery method for returning to the old configuration upon occurrence will be described in the sixth embodiment, an operation for detecting a failure related to activation or stop of an object will be described.

  That is, an operation of detecting a failure in the configuration management unit 131 by issuing an instruction for starting and stopping an object and determining the result of starting and stopping as a result will be described.

  When the sixth embodiment is recovered after a failure occurs after the block diagram showing the functional configuration of the present invention shown in FIG. 1 and the activation parameter of the object in the application package shown in FIG. 15 are changed and restarted An example will be described using the processing sequence for fault detection by object activation shown in FIG. 20 and the processing sequence for fault detection by object stop shown in FIG.

  First, in step S <b> 600, the configuration management unit 131 updates the object configuration repository 142 in response to the difference analysis result from the difference analysis unit 133.

  Next, in step S601, the configuration management unit 133 checks the difference in the object configuration repository 142 and requests the connection management unit 132 to release the connection relationship with the adjacent object a to which the old object b is connected (step S601). S602). Upon receiving the request, the connection management unit 132 performs a connection relation release process via the control interface (in this embodiment, the connection control interface is set to disconnect () as an example) (step S603).

  Next, in step S604, the object a releases the connection with the adjacent object b, and notifies the connection management unit 132 of the completion of disconnection (step S605).

Next, in step S606, after receiving a disconnection completion notification via the connection management unit 132, the configuration management unit 133 generates a process for the new object in order to activate the new object. After the process is generated, the activation parameter is added and the object b is activated again as a new object (step S607). By this process, the object b is activated with the activation parameter added (step S608).
The process generation and object activation processing use system calls (fork (), exec ()) provided in a general OS such as UNIX (registered trademark).

Next, in step S609, the configuration management unit 131 confirms that the new object b after activation is activated correctly. Here, if the new object b does not exist, it is determined that the activation of the object has not ended normally, and is detected as a failure. The subsequent processing is restored to the original configuration by the same flow as after the failure detection in the fifth embodiment.
Note that the object activation confirmation process can be identified by the name of the activated object and its process ID (such as a ps command generally provided in an OS such as UNIX).

On the other hand, when the activation parameter is added and the activation of the new object b is normally completed, the stop process of the old object b is continued. In the case of the object stop, similarly, the configuration management unit 133 confirms the difference in the object configuration repository 142 (step S611), and then stops the old object b (step S612).
Note that this object stop processing uses a system call (kill ()) provided in a general OS such as UNIX.

In step S613, the configuration management unit 131 confirms that the stopped old object b is stopped correctly. Here, if the old object b exists, it is determined that the stop of the object has not ended normally, and is detected as a failure.
The object stop confirmation process can be identified by the name of the stopped object and its process ID (such as a ps command generally provided in an OS such as UNIX).

  As described above, according to the sixth embodiment, it is possible to detect a failure at the time of starting an object by issuing an instruction for starting and stopping the object and determining the result of starting and stopping as a result of the instruction. This also enables recovery in units of objects (processes).

  In addition, since control is possible for each object in this way, recovery by partial replacement of application packages is possible as compared with replacement methods for each memory area.

  In addition, failure to start or stop an object can be detected as a failure during reconfiguration, so that the time until failure recovery can be shortened.

  Further, when the activation time-out time is set in the configuration management profile 112, the object activation confirmation process is repeated until the time-out time expires, so that a sufficient time to activate even an object with a long activation time. By setting, safe startup confirmation and failure detection can be performed.

Embodiment 7 FIG.
<Connection / disconnection detection operation of object connection by control interface>
The above-described sixth embodiment relates to the operation of detecting a failure in the configuration management unit 131 by issuing an instruction for starting and stopping an object and determining the result of starting and stopping the object as a result. In the seventh embodiment, the connection or disconnection detection operation of the object connection relation will be described using the control interface.

  That is, the configuration management unit 131 and the connection management unit 132 are provided with a control interface for an object to be managed, and a control interface for receiving an instruction from the configuration management unit 131 and the connection management unit 132 for the object to be managed. The object to be managed is given an instruction to establish or release the connection relationship via the control interface, and the object to be managed receives an instruction from the configuration management unit 131 and the connection management unit 132 through the control interface, and is connected to the adjacent object. Alternatively, an operation of performing a disconnection process and detecting a failure in connection or disconnection as a result of the process will be described.

  When the seventh embodiment is recovered after a failure occurs after restarting by changing the activation parameter of the object in the application package shown in FIG. 22 and the block diagram showing the functional configuration of the present invention shown in FIG. This example will be described using a processing sequence for detecting the occurrence of a failure in establishing the object connection relationship shown in FIG.

  In the seventh embodiment, in the object configuration as shown in FIG. 22, when reconfiguration is performed by replacing the object b with b ′ by upgrading the object b, a failure occurs in establishing the connection relationship with the adjacent object. The operation when detecting is described. However, it is assumed that the object b ′ is changed only in the program, and the interface is not changed. For this reason, the connection destination of the object a is not changed (the connection destination b is changed to b ′ by the middleware 120).

  First, in response to the result of the difference analysis from the difference analysis unit 133, the configuration management unit 131 updates the object configuration repository 142. The configuration management unit 133 confirms the difference in the object configuration repository 142 and the new object b ′. Start up.

  Next, in step S700, the connection management unit 132 is requested to release the connection relationship with the adjacent object a to which the old object b is connected. Upon receiving the request, the connection management unit 132 performs a connection relation release process via the control interface (in this embodiment, the connection control interface is set to disconnect () as an example) (step S701).

  In step S702, the object a releases the connection relationship with the adjacent object b, and notifies the connection management unit 132 of the result of the disconnection process (step S703). At this time, if the disconnection does not end normally, the configuration management unit 131 detects the failure via the connection management unit 132. Thereby, the recovery process is started.

  On the other hand, if the disconnection process is completed, the configuration management unit 131 continues to stop the old object b in steps S704 and S705.

  In step S706, the configuration management unit 131 requests the connection management unit 132 to establish a connection relationship with the new object b ′. Upon receiving the request, the connection management unit 132 reads the configuration information from the object configuration repository 142, and establishes a connection relation establishment process for the object a adjacent to the target new object b ′ via the control interface (this implementation). As an example, the control interface for connection is connect (), and the new object b 'can be handled by replacing the object since the interface does not change from the old object b. There is no change in the connection destination, and the connection destination object is designated as b in the control interface connect (), that is, since there is no change in the interface, the connection relation is established by changing the connection destination b to b ′ by the middleware 120. Can be established) (step S7) 7).

  Next, in step S708, the object a establishes a connection relationship with the adjacent new object b ', and notifies the connection management unit 132 of the result of the connection process (step S709). At this time, if the connection does not end normally, the configuration management unit 131 detects the failure via the connection management unit 132. Thereby, the recovery process is started.

  As described above, according to the seventh embodiment, an instruction to establish or release an object connection relationship is issued via the control interface, and the object to be managed is sent to the configuration management unit 131 and the connection management unit 132 by the control interface. In response to an instruction from, a connection or disconnection process with an adjacent object is performed, and as a result, the result of starting and stopping the object can be determined, so that a failure can be detected when establishing or releasing a connection relationship between objects. Compared to detecting a failure after object configuration, high-speed recovery is possible.

  Further, since control is possible for each object, it is not necessary to restart the entire program, and dynamic and high-speed recovery is possible.

  In addition, since the failure of connection or disconnection of the object connection relationship can be detected as a failure during reconfiguration, the time until failure recovery can be shortened.

  Furthermore, when a connection timeout time is set in the configuration management profile 112, an object connection processing response is waited until the timeout time expires, so that an object having a long connection time has enough time to connect. Setting allows safe connection confirmation and failure detection.

It is a figure which shows the function structure of the software failure recovery system required in order to implement | achieve this invention. It is explanatory drawing which shows an example when the failure in the object in the application package 110 which concerns on Embodiment 1 of this invention generate | occur | produces, and it recovers. It is a figure which shows the example of the table structure of the object structure repository 142 which concerns on Embodiment 1 and 5 of this invention. It is a figure which shows the example of the object structure information of the configuration management profile 112 which concerns on Embodiment 1 of this invention. It is a figure which shows the example of the table structure of the additional object information repository 143 which concerns on Embodiment 1 of this invention. It is a figure which shows the example of the table structure of the deletion object information repository 144 which concerns on Embodiment 1 of this invention. It is a flowchart explaining operation | movement of the software failure recovery system which concerns on Embodiment 1 of this invention. It is a figure which shows the example of the change of the object structure which concerns on Embodiment 2-4 of this invention. It is a figure which shows the example of the table structure of the object structure history repository which hold | maintains the difference | history history of the object structure which concerns on Embodiment 2-4 of this invention. It is a flowchart explaining operation | movement of the software failure recovery system which concerns on Embodiment 2 of this invention. It is a figure which shows the example of the object reconstruction by the multiplexing which concerns on Embodiment 4 of this invention. It is a figure which shows the example of the table structure of the multiplexed object structure repository at the time of recovery which concerns on Embodiment 4 of this invention. It is a figure which shows the example of the table structure of the multiplexed object structure repository at the time of the switch after recovery which concerns on Embodiment 4 of this invention. It is a flowchart which shows operation | movement of the software failure recovery system which concerns on Embodiment 4 of this invention. FIG. 16 is a diagram showing an example when a failure occurs and recovery is performed after changing the activation parameter of the object in the application package shown in FIG. 15 according to Embodiment 5 of the present invention and restarting. It is a figure which shows the example of the object structure information of the new structure management profile which concerns on Embodiment 5 and 6 of this invention. It is a figure which shows the example of the table structure of the additional object information repository which concerns on Embodiment 5 of this invention. It is a figure which shows the example of the table structure of the deletion object information repository which concerns on Embodiment 5 of this invention. It is a figure which shows the example of the table structure of the object structure repository after the update which concerns on Embodiment 5 of this invention. It is a figure which shows the process sequence of the failure detection by the object starting which concerns on Embodiment 6 of this invention. It is a figure which shows the processing sequence of the failure detection by the object stop which concerns on Embodiment 5 and 6 of this invention. It is a figure which shows an example when a failure generate | occur | produces after changing the starting parameter of the object in the application package which concerns on Embodiment 7 of this invention, and restarting. It is a figure which shows the process sequence which detects generation | occurrence | production of a failure in establishment of the connection relation of the object which concerns on Embodiment 7 of this invention.

Explanation of symbols

  100 communication equipment, 110 application package, 111 profile, 112 configuration management profile, 113 interface definition file, 114 managed object group, 120 middleware, 130 object control unit, 131 configuration management unit, 132 connection management unit, 133 difference analysis unit , 134 Fault recovery unit, 135 History management unit, 140 Object configuration management unit, 141 repository group, 142 Object configuration repository, 143 Additional object information repository, 144 Deleted object information repository, 145 Object configuration history repository, 150 OS (Operating System) 160 Management device.

Claims (7)

A software failure recovery system in software function update technology that manages functions of communication devices as a set of objects, and implements various functions in a single device by exchanging objects and switching interconnections between objects,
Supports communication between objects in the application package, and a configuration management profile that describes the object connection relationship downloaded from the management device, which is a server, and a management target object group in the communication device. Middleware comprising an object control unit and an object configuration management unit for
The object control unit of the middleware
A configuration management unit that captures data from the configuration management profile, registers configuration information, and starts and stops objects;
A connection management unit that controls the object for establishing connection of the object based on the configuration information managed after starting, stopping and registering the configuration of the object;
A difference analysis unit that compares the new configuration management profile with the object configuration in operation and analyzes the difference when the object is updated, and
The object configuration management unit of the middleware
An object configuration repository that holds the object configuration in operation;
An additional object information repository that holds information on additional objects extracted as differences in the difference analysis unit;
A deleted object information repository that holds deleted object information, and
In the event that a failure occurs due to a connection failure due to a failure in starting an object or a specification such as an interface specification with another object during reconfiguration, the object control unit deletes the additional object information repository or the deletion A software failure recovery system, further comprising a failure recovery unit for returning to the configuration operated last time based on the difference information stored in the object information repository. In the software failure recovery system according to claim 1,
During software operation, when downloading a new application package to a communication device and updating an object in order to correct a bug in the software or add a function,
The difference analysis unit of the middleware compares the object configuration information of the configuration management profile newly downloaded together with the object with the object configuration repository that holds the object configuration in operation, and analyzes the difference information. Extract the information of the added object and the deleted object, and store them in the added object information repository and the deleted object information repository, respectively.
The configuration management unit of the middleware uses the difference information to activate an additional object to be a new object and delete a deleted object to be replaced,
The connection management unit of the middleware performs connection or disconnection of an object connection relationship extracted as a difference based on the connection relationship of objects. In the software failure recovery system according to claim 1,
The object configuration management unit of the middleware is not only the previous configuration that has been operated, but also the object configuration of the object configuration management unit that holds a history of differences between the past object configuration that has been used and the current object configuration. A history repository,
The object control unit of the middleware further includes a history management unit that selects an arbitrary object configuration that has been used in the past using the configuration history information managed in the object configuration history repository. Software failure recovery system featuring. In the software failure recovery system according to claim 3,
The history management unit updates the software, and every time the object configuration is reconfigured, the additional object information repository and the deleted object that are differences between the object configuration history repository that is an active object configuration and a new object configuration By acquiring information in the information repository, it is stored and managed as a difference history in the object configuration history repository, and if any failure occurs during the reconfiguration, an arbitrary operation record from the object configuration history repository Select the object configuration for
The connection management unit re-establishes an object connection relationship based on a selected object configuration. The software failure recovery system according to claim 4,
The history management unit selects an arbitrary object configuration having an operation record from the object configuration history repository, and reestablishes an object connection by the connection management unit based on the selected object configuration. A software failure recovery system that processes any object configuration that has been used in the past, in parallel, without affecting the object configuration in operation by multiplexing the processing. In the software failure recovery system according to claim 1,
The configuration management unit and the connection management unit include a control interface for an object to be managed,
A software failure recovery system comprising: a control interface for receiving an instruction from the configuration management unit and the connection management unit in an object to be managed. The software failure recovery system according to claim 6,
For the object to be managed from the configuration management unit and the connection management unit, an instruction to start and stop the object, connection of the object configuration, and disconnection is given via the control interface.
An object to be managed receives an instruction from the configuration management unit and the connection management unit from the control interface, and performs connection or disconnection processing with an adjacent object. As a result of the processing, normal or abnormal termination is performed. A software failure recovery system that returns to the configuration management unit or the connection management unit.

Images