System configuration derivation device, system configuration derivation method, and program

Abstract

To provide a method for efficiently deriving configuration information for a system that simultaneously satisfies functional requirements and recovery time requirements of a service.SOLUTION: A system configuration derivation device includes: means for calculating a recovery cost required for recovery of a structure derived from an expected configuration of an entity having as a type a constituent component model based on information on a recovery model and the expected configuration; means for constructing a global state model representing an operation model relating to failure recovery of an abstract configuration; means for verifying whether the global state model satisfies recovery time requirements; and means for generating an abstract configuration that embodies functional requirements using a mechanism for gradually embodying the abstract configuration as a possible system configuration candidate, and deriving a system configuration that simultaneously satisfies the functional requirements and the recovery time requirements by eliminating any candidates that do not satisfy the recovery time requirements.SELECTED DRAWING: Figure 32

Description

Technical Field

[0001] The present disclosure relates to a system configuration derivation device, a system configuration derivation method, and a program.

Background Art

[0002] When constructing an ICT (Information and Communication Technology) system for purposes such as service operation, a design operation of the system configuration is necessary. In the design operation of the system configuration, it is necessary to construct without shortage the constituent parts of the system and their connection relationships (hereinafter, these are collectively referred to as "system configuration") necessary to satisfy the requirements required for the desired system (hereinafter, referred to as "system requirements"), and further, all the setting items necessary for the entire system to operate normally must be set correctly, and this is sometimes a very labor-intensive operation.

[0003] The technology for automating the above-described design process, that is, the process of concretizing from system requirements to system configuration, is an automatic design technology. As existing automatic design technologies, although many technologies limit problems to specific domains of ICT systems, such as network paths and allocation of computing resources, and perform automatic design by solving certain optimization problems thereon, research is also progressing on technologies for dealing with general-purpose requirement descriptions.

[0004] For example, Non-Patent Document 1 describes a technology for automatically deriving a system configuration based on functional requirements described using a general-purpose system configuration information model in a graph-like format. According to the technology described in the document, by preparing necessary models, automatic design with general-purpose and multifaceted requirements as input becomes possible.

[0005] The requirements describable by the general-purpose model described in Non-Patent Document 1 are mainly those specified by a graphical representation in which components such as functions and devices are represented as nodes, and the relationships between those nodes are represented by edges (directed edges) (hereinafter referred to as "abstract configuration". However, Non-Patent Document 1 refers to this as "dependency configuration"). For example, the requirement that "communication by TCP (Transmission Control Protocol) is possible between two servers" is expressed as an abstract configuration in which nodes corresponding to the respective servers are connected by an edge representing "TCP communication possible". The method described in Non-Patent Document 1 is a mechanism for automatically deriving a method for concretizing the abstract "TCP communication possible" edge included in the above abstract configuration. (Hereinafter, nodes and edges are collectively referred to as "entities".)

[0006] It should be noted that the automatic design method described in Non-Patent Document 1 does not concretize the given requirements all at once. In the above automatic design method, for model data (hereinafter referred to as "component model") representing the relevant information for the type of entity (hereinafter referred to as "type"), the peripheral configuration information (hereinafter referred to as "expected configuration") necessary for the entity having the type to function properly as a component of the system is held as data, and this is sequentially applied to the abstract configuration representing the requirements, or the type of the node and edge is replaced with a more specific type to gradually convert it into a more specific abstract configuration.

[0007] Here, "applying the expected configuration" is an operation performed on an abstract node or edge (hereinafter referred to as "unit requirement") included in the abstract configuration, and refers to adding a structure corresponding to the expected configuration to the abstract configuration for a unit requirement that does not have the expected configuration.

[0008] The operation of replacing the type of the entity with a more specific type with respect to the "applying the expected configuration" operation is called "type refinement". The operations of applying the expected configuration to the entity or refining the type are collectively called "concretization" operations.

[0009] The automatic design method described in Non-Patent Document 1 can be said to be a method of obtaining an abstract configuration in which all unit requirements included in the requirements are solved by repeating the concretization for the input functional requirements. Further, the abstract configuration thus obtained can be considered to be a completely concretized system configuration (hereinafter simply referred to as "concrete configuration") without any abstract elements.

[0010] As described above, automatic design by the stepwise concretization of functional requirements expressed in an abstract configuration becomes possible.

[0011] The functional requirements handled in the above-described automatic design mainly include matters necessary for each component to operate normally with appropriate performance that meets the requirements, and these are merely requirements regarding the behavior when the system operates normally.

[0012] However, on the other hand, users of system automatic design technology (hereinafter referred to as "service operators") often have requirements not only regarding the state in which the system operates normally but also regarding recovery from some kind of abnormal situation. One of the most common of these is the recovery time requirement (Recovery Time Objective, hereinafter referred to as "RTO") such as "Can it be recovered within one day to the normal state?" or "Can it be recovered to an operable state of the system within 10 minutes?". The RTO is expressed as the upper limit of the recovery state and the execution time of the procedure (recovery procedure) from the failure state to that state.

[0013] If the automatic design can correctly reflect the RTO, it is possible to design by automatic design a system that operates a highly fault-tolerant service.

[0014] When attempting to reflect RTO within an existing automated design framework, a method can be considered where, when it is determined that the RTO is not satisfied for an abstract configuration during the process of materialization, that abstract configuration is removed from the list of valid configuration candidates. For example, in the method described in Patent Document 1, when materializing an abstract configuration, constraint conditions regarding parameters are added to the abstract configuration, and when there is no combination of parameter values that satisfies the constraint conditions, the materialization of the abstract configuration is terminated, thereby enabling the output of a system that satisfies quantitative constraint conditions.

[0015] As a method for obtaining the recovery procedures necessary to determine RTO, a method can be considered where the "behavior" in which each component operates is described in a component model and materialized in parallel with the abstract configuration, thereby materializing not only the system configuration but also the operation model. When considering RTO, model data (hereinafter referred to as "recovery model") that defines the "recovery operation from a failure" is described in the component model. This is materialized during the materialization of the abstract configuration, the transition procedure from the failure state to the state to be recovered is obtained on the recovery model, and the recovery time can be obtained by calculating the execution time cost of that procedure.

[0016] By applying a method similar to that described in Patent Document 1 to the reflection of RTO, a method can be considered where the recovery time is calculated for an abstract configuration and it is confirmed whether this satisfies the RTO specified in the requirements. However, this method has a problem in terms of computational efficiency.

[0017] An abstract configuration is a configuration in which a part of the system is in an undetermined state, and when calculating the recovery procedure in this state, a part of it will inevitably be undetermined. Currently, there is no means to estimate the time required for the execution of the undetermined part of the recovery procedure, and therefore, the recovery time for the undetermined part has no choice but to be treated as non-existent. Then, the recovery time becomes "the time required for the execution of the determined part of the recovery procedure (hereinafter referred to as the 'determined recovery time')".

[0018] However, since the determined recovery time is inevitably estimated to be much less than the recovery time of the system finally obtained, pruning by the upper limit value hardly functions in this method. Pruning using the determined recovery time only functions for configurations that are clearly redundant and take too long to recover, or for configurations at the stage where the difference between the determined recovery time and the actual recovery time becomes sufficiently small after most components are materialized.

[0019] This method is not a problem as long as it only guarantees that the finally obtained configuration satisfies the RTO. However, in cases where the RTO is specified practically, it is considered that the desired configuration cannot be obtained within a realistic time by such a method. For example, in a case where it is necessary to additionally prepare a specific configuration (for example, including a standby system that operates temporarily at the time of failure in addition to a normal system that operates during normal operation) to satisfy the RTO, a proper configuration is searched including an abstract configuration including a pattern without such an additional structure (for satisfying the RTO). However, in existing automatic designs, it is basically easy to proceed with the search preferentially from a configuration with a small number of elements within the range that satisfies the constraints. Then, in the above case, it is impossible to reach a specific configuration that correctly satisfies the RTO without searching all abstract configurations that do not include the structure necessary to satisfy the RTO (and thus cannot be a correct specific configuration). As a result, it is necessary to materialize a huge number of abstract configurations and confirm that they do not satisfy the RTO until reaching the correct specific configuration that satisfies the RTO.

Prior Art Documents

Patent Documents

[0020]

Patent Document 1

Non-Patent Documents

[0021]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0022] One of the objectives is to provide a method for efficiently deriving configuration information of a system that simultaneously satisfies functional requirements and recovery time requirements.

Means for Solving the Problems

[0023] According to one aspect of the present disclosure, an expected configuration is a peripheral structure necessary for system components to operate normally. A recovery model is model data representing the relationship between the failure recovery operations of system components and the peripheral structures. A component model is model data that defines type-specific information including the expected configuration and the recovery model of various abstract or concrete system components. An abstract configuration is a representation of the configuration of a system that includes uncertain parts, which is composed of nodes corresponding to components and edges indicating the relationships between the components. The combination of the nodes and the edges is collectively referred to as an entity, and the type of the entity is the type. When concretization is a conversion of a graph structure that determines the uncertain parts of the abstract configuration based on the information of the expected configuration, taking the component model as an input, based on the recovery model and the information of the expected configuration defined in association with the component model, means for calculating a recovery cost for recovering the structure derived from the expected configuration of the entity having the type indicated by the component model; means for constructing a global state model indicating an operation model related to failure recovery of the abstract configuration, taking the abstract configuration and the recovery cost as inputs; means for verifying whether the global state model satisfies the recovery time requirement, taking the global state model and the recovery time requirement as inputs; means for generating, as candidates for possible system configurations, the abstract configuration in which the functional requirement is concretized by a mechanism for gradually concretizing the abstract configuration, taking the functional requirement and the recovery time requirement as inputs, inputting the generated abstract configuration to the means for constructing to obtain the global state model, and inputting the global state model and the recovery time requirement to the means for verifying to exclude the candidates that do not satisfy the recovery time requirement, thereby deriving a system configuration that simultaneously satisfies the functional requirement and the recovery time requirement.

[0024] According to one aspect of the present disclosure, an expected configuration is a peripheral structure necessary for a system component to operate normally. A recovery model is model data representing the relationship between the failure recovery operation of a system component and the peripheral structure. A component model is model data defining type-specific information including the expected configuration and the recovery model of various abstract or concrete system components. An abstract configuration represents the configuration of a system including undetermined parts by a graph-like structure composed of nodes corresponding to components and edges indicating the relationships between the components. The combination of the nodes and the edges is collectively referred to as an entity, and the type of the entity is called a type. When concretization is a conversion of a graph structure that determines undetermined parts of an abstract configuration based on information of the expected configuration, taking the component model as an input, calculating a recovery cost for recovering a structure derived from the expected configuration of an entity having a type indicated by the component model based on the recovery model and the information of the expected configuration defined in association with the component model, taking functional requirements and recovery time requirements as inputs, generating, as candidates for possible system configurations, the abstract configuration in which the functional requirements are concretized by a mechanism for gradually concretizing the abstract configuration, taking the generated abstract configuration and the recovery cost as inputs, constructing a global state model indicating an operation model related to failure recovery of the abstract configuration, taking the global state model and the recovery time requirements as inputs, verifying whether the global state model satisfies the recovery time requirements, and excluding candidates that do not satisfy the recovery time requirements, thereby deriving a system configuration that simultaneously satisfies the functional requirements and the recovery time requirements.

[0025] According to one aspect of the present disclosure, it is a program for causing a computer to execute the above processing.

Advantages of the Invention

[0026] According to the present disclosure, it is possible to efficiently derive configuration information of a system that simultaneously satisfies functional requirements and recovery time requirements of a service.

Brief Description of the Drawings

[0027]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Embodiments for Carrying Out the Invention

[0028] Hereinafter, the system configuration derivation device according to each embodiment of the present disclosure will be described with reference to the drawings. The system configuration derivation device automatically generates a desired ICT system from system requirements (hereinafter referred to as "new requirements") input by a user. The system configuration derivation device designs the system so that the recovery time from a failure is within a specified time. In the drawings used in the following description, the configuration of parts not related to the present disclosure may be omitted and may not be illustrated. In all the drawings, the same or corresponding configurations are denoted by the same reference numerals, and common descriptions may be omitted.

[0029] <First Embodiment> (Configuration) FIG. 1 is a first block diagram showing a configuration example of the system configuration derivation device 100. As shown in FIG. 1, the system configuration derivation device 100 includes a configuration concretization unit 101, a dependent recovery cost calculation unit 102, a recovery model construction unit 103, and a recovery time requirement verification unit 104.

[0030] The configuration concretization unit 101 receives, as inputs, an abstract configuration representing system requirements, a recovery time requirement for the abstract configuration, and a component model necessary for concretizing the system requirements, and derives a specific configuration by gradually concretizing the input abstract configuration.

[0031] The dependent recovery cost calculation unit 102 receives a type as an input, and calculates the dependent recovery cost for each recovery task in the recovery model defined in each component model corresponding to the type.

[0032] The restoration model construction unit 103 receives an abstract configuration as input, and calculates a global state model that corresponds to the abstract configuration and reflects the dependency restoration cost.

[0033] The restoration time requirement verification unit 104 receives the global state model and the restoration time requirement as input, and verifies whether the abstract configuration that is the basis of the global state model satisfies the restoration time requirement.

[0034] In addition, the dependency restoration cost calculation unit 102 of the present embodiment further includes a subdivided auxiliary operation unit inside. FIG. 2 is a block diagram showing a configuration example of the dependency restoration cost calculation unit 102.

[0035] The dependency restoration cost calculation unit 102 includes a dependency restoration cost calculation procedure control unit 200, a tangible type dependency restoration cost construction unit 201, an intangible type dependency restoration cost construction unit 202, a dependency restoration cost propagation unit 203, and a dependency restoration cost integration unit 204.

[0036] The dependency restoration cost calculation procedure control unit 200 receives a state element model as input, and calculates the dependency restoration cost for all types.

[0037] The tangible type dependency restoration cost construction unit 201 receives a tangible type (described later) as input, and calculates the dependency restoration cost for the tangible type.

[0038] The intangible type dependency restoration cost construction unit 202 receives an intangible type (described later) as input, and calculates the dependency restoration cost for the intangible type.

[0039] The dependency restoration cost propagation unit 203 receives a type and (intermediate calculation) all dependency restoration cost information as input, and complements the information lacking in the dependency restoration cost information of the type according to the type inheritance information (described later).

[0040] The dependency restoration cost integration unit 204 receives a list of dependency restoration costs as input, and integrates the list of dependency restoration costs into a single dependency restoration cost.

[0041] Hereinafter, the abstract configuration and its data structure in this embodiment will be described. The abstract configuration refers to an abstract system configuration including undetermined parts regarding the configuration and settings. The abstract configuration plays a role of defining a desired system without specifically referring to the details of the system by writing only the information that has been determined by the entity desiring the ICT system, that is, the information indicating "what requirements the system should meet and what functions it should have".

[0042] The abstract configuration is basically composed of a graph consisting of "nodes" corresponding to the functions and logical / physical component parts of the system, and "edges" that express the relationship between two nodes by stretching between the two nodes. The above-mentioned edge has a direction, and for an edge going from node n1 to node n2, node n1 is called the "source" and node n2 is called the "destination". Also, hereinafter, when referring to nodes and edges without distinction, these are collectively called "entities".

[0043] An entity has, as data, an "identifier" for uniquely identifying the entity throughout the system, a "type" representing what concept the entity corresponds to, and a "satisfaction flag" for managing whether the expected configuration has been applied. The identity of entities in two different abstract configurations is determined by the identifier. That is, even if the types are different, if the identifiers are the same, they are treated as "the same entity".

[0044] In addition, a node has its own "initial state" as data. This "initial state" refers to any one of the states included in the "state element model (described later)" associated with its own type.

[0045] FIG. 19 is an example of an abstract configuration. In this specification, a node is represented by a rectangle with a label of "(identifier):(type name)", and an edge is represented by an arrow with a label of "(identifier):(type name)". Hereinafter, in the description of the specification, "(type name) - typed entity named (identifier)" will also be expressed as "(identifier):(type name)".

[0046] The abstract configuration described in FIG. 19 includes four nodes, namely S1:Service, App1:AppX, App1:AppY, and M1:Machine, and three edges, namely i1:Include, i2:Include, and h:Host. i1 is an edge from S1 to App1, i2 is an edge from S1 to App2, and h1 is an edge from App1 to M1. Intuitively, S1 uses App1 and App2 as applications that make up the service, and App1 indicates that it is a machine that hosts M1.

[0047] The "type" of an entity and the corresponding "component model" will be described in more detail below.

[0048] The type of an entity serves to indicate what kind of entity it is. There are two types of types: "abstract type" and "specific type". The abstract type indicates an entity of a kind that, intuitively, does not correspond to specific parts or connection relationships that actually exist in reality, such as "Machine" or "HTTP connectable", and requires further concretization. On the other hand, the specific type indicates an entity that corresponds to specific parts or connection relationships that actually exist in reality, such as "(model number of a specific machine)" or "wired LAN connection".

[0049] In addition, there may be an inheritance relationship defined between different types. The inheritance relationship will be described below.

[0050] When type Ta inherits type Tb, it means that an entity of type Ta can also be regarded as an entity of type Tb. For example, type MachineX corresponding to the model number of a specific machine inherits type PhMachine that represents "all physical machines". Furthermore, type PhMachine inherits type Machine that represents "(all machines, whether physical or virtual)". Also, it is assumed that there is one or more specific types that inherit each abstract type, and there is no type that inherits a specific type.

[0051] In addition, in this specification, it is assumed that the graph represented by types and inheritance relationships is a set of tree structures. That is, it is assumed that each type inherits at most one type. Under this premise, a type that has no type inheriting it is called a concrete type.

[0052] (Supplement) Note that the assumption in the previous paragraph is not related to the essence of each embodiment of the present disclosure. That is, the structure of the inheritance relationship does not necessarily have to be a set of tree structures.

[0053] It is stipulated that "Tb ⇒ Ta" means that type Ta inherits type Tb. When there is a relationship of T(m)⇒T(m-1)⇒,..., ⇒ T(2) ⇒ T(1), it is said that "T(1) is a descendant of T(m)" and "T(m) is an ancestor of T(1)". As will be described later, all entities with all abstract types will be concretized into entity of concrete types such that they are descendants during the process of automatic design, and must have all the expected configurations of abstract types such that they are ancestors.

[0054] The above is the description of the inheritance relationship of types.

[0055] Model data that defines information specific to each type is called the "component model" of that type. Although various information can be defined in the component model, it is assumed that in each embodiment of the present disclosure, "expected configuration" data and "state element model" are included.

[0056] First, the "expected configuration" of a type refers to the peripheral configuration necessary for an entity of that type to operate properly in the system. For example, the fact that an "application" requires a "machine" to host it is expressed as the expected configuration of the App type corresponding to the "application". E1300 in Figure 13 is a graph representing the above situation, where the App type node SELF and the Machine type node M (representing the machine) are connected by the Host type edge H (representing the hosting relationship). The "SELF" used here is a special identifier, and each expected configuration represents the structure necessary for the entity with the identifier "SELF" to operate properly. That is, there is exactly one entity with the identifier SELF in all expected configurations. Hereinafter, this "SELF" entity will be referred to as the target entity of the expected configuration.

[0057] Also, there may be two or more expected configurations set for a type. This means that it is expected that any one of the multiple expected configurations will be applied. For example, Figure 13 shows the expected configurations for two "App" type nodes, E1300 and E1301. In E1301, instead of the "M:Machine" node in E1300, a node "C:Container" representing an application container (Container type) is connected. This indicates that an application container can be selected as the host destination of the application instead of a machine.

[0058] Furthermore, there are some types for which no expected configuration is specified at all. This means that they do not require dependent components and can operate properly as a system component alone.

[0059] Some of the entities including the SELF node in the expected configuration are specified as the "prerequisite configuration". The prerequisite configuration is a configuration that must be included in advance in the abstract configuration to be applied when applying the specific configuration (described later). In the drawings of this specification, the entities included in the prerequisite configuration will be drawn with double lines.

[0060] For example, in E1300 and E1301 shown in FIG. 13, only the SELF node is drawn with a double line, which indicates that the prerequisite configuration for these expected configurations is only the SELF node.

[0061] On the other hand, the prerequisite configuration may have a structure larger than the SELF node alone, as shown in Figure 20. The expected configuration in Figure 20 includes three nodes SELF:AppX, M:Machine, SA:SubApp, and three edges h1:Host, h2:Host, and u:Use, of which the three entities SELF, h1, and M are specified as the prerequisite configuration. This means that if the expected configuration in Figure 20 is applied, the abstract configuration to which it is applied must include "an AppX node and a Machine node, and a Host-type edge extending from the former to the latter."

[0062] The above is an explanation of the "expectation structure" of the type.

[0063] Secondly, a "state element model" of a type is a model that represents the state (in system recovery) of an entity that has the type. The data structure of a state element model changes depending on whether the target type is a "tangible type" or an "intangible type".

[0064] Among node types, there are those that can change their state by performing some operation on themselves, and those that can't. For example, an App-type node, which represents an application, can be thought of as being able to transition to a "running" state, "deleted" state, etc., by launching an executable file or uninstalling it. This type of node type is called a "tangible type." On the other hand, a Service-type node, which corresponds to a "service" that runs a combination of multiple applications, can be thought of as its own operating state changing in conjunction with the state transition of the application that makes it possible. This type of node type is called an "intangible type." All node types can be classified as either a "tangible type" or an "intangible type."

[0065] All tangible types have a "recovery state transition system" and all intangible types have a "recovery state set" as state element models.

[0066] The "recovery state transition system" is a graph structure that connects the states of corresponding nodes by state transitions. Here, the "state" of a node is assumed to be a state related to recovery. In this specification, a structure as shown in FIG. 14 is assumed. That is, four types of states, "during failure occurrence (hereinafter referred to as the 'F' state)", "deleted (hereinafter referred to as the 'A' state)", "deployed (hereinafter referred to as the 'C' state)", and "operating (hereinafter referred to as the 'H' state)", and four state transitions, the state transition from F to A, the state transition from A to C, the state transition from C to H, and the state transition from H to C, are assumed to be a graph structure. When it is necessary to explicitly indicate the identifier of a node, the state s of the recovery state transition system of node N is written as "N:s", and the transition from state s1 to s2 is written as "N:s1→s2".

[0067] Also, it is assumed that for the transitions of the recovery state transition system, type-specific "transition time costs", that is, data on the time required to execute the transition, are associated. This transition time cost is directly specified for concrete types, while for abstract types, it is defined as the minimum value of the values specified for all concrete types that are descendants of the abstract type. For example, if there are concrete types MachineX and MachineY as descendants of the Machine type, and the transition time costs for C→H of each are 10 and 7 respectively, then the transition time cost for C→H of the Machine type is 7.

[0068] The "recovery state set" is a recovery state transition system that does not include state transitions. That is, it refers to a graph structure that only includes nodes with states. In this specification, a structure as shown in FIG. 15 is assumed. That is, a graph structure including four types of states, "during failure occurrence (hereinafter referred to as the 'F' state)", "deleted (hereinafter referred to as the 'A' state)", "deployed (hereinafter referred to as the 'C' state)", and "operating (hereinafter referred to as the 'H' state)", as nodes is assumed.

[0069] (Supplement) However, the graph structures of the recovery state transition system and the set of recovery states are not limited to those shown in FIGS. 14 and 15. It is possible to assume a completely different graph structure, or a format in which different graph structures are associated according to the type. However, it is assumed that the states always include those corresponding to the abnormal state at the time of failure occurrence and those corresponding to the state during normal operation. In this embodiment, these are "F" and "H", respectively.

[0070] The above is the description of the "state element model" of the type.

[0071] Furthermore, in each embodiment of the present disclosure, "recovery model" data is defined to be associated with each of the expected configurations of the node type. In the following description, the expected configuration with which the recovery model is associated is referred to as the "target configuration" of the recovery model.

[0072] The description of the recovery model is given below.

[0073] The recovery model is data that represents the dependency relationship between the state of the target entity and the state of the surrounding entities when transitioning the state of the target entity in a situation where the target configuration exists around the target entity.

[0074] The recovery model is composed of the state element model for all the nodes included in the target configuration and the dependencies defined therebetween.

[0075] The "dependency" defined in the recovery model is data associated with the state transition of the recovery state transition system and the state of the set of recovery states. Specifically, it is defined as a data structure consisting of the following three types of data: "dependency items", "dependency branches", and "dependency".

[0076] A dependency item is data denoted as "N:S", which is defined using a list S = [s(1),.., s(m)] of one or more states included in the recovery state transition system corresponding to node N. If the state of node N is any of s(1), ..., s(m), it is said that node N satisfies the dependency item N: [s(1),..., s(m)]. Also, when the target configuration includes a node N that satisfies the dependency item N: [s(1),..., s(m)], it is said that the target configuration itself satisfies the dependency item N: [s(1),..., s(m)].

[0077] A dependency branch is data denoted as "{ N(1):S(1),..., N(m):S(m)}", which is defined using one or more dependency items N(1):S(1), ..., N(m):S(m) (where N(1), ..., N(m) are all different nodes from each other). When the target configuration satisfies all of the dependency items N(1):S(1), ..., N(m):S(m), it is said that the target configuration satisfies the dependency branch { N(1):S(1), ..., N(m):S(m)}.

[0078] A dependency is data denoted as "[ B(1),..., B(m) ]", which is defined using zero or more dependency branches B(1), ..., B(m). When the target configuration satisfies any of the dependency branches B(1), ..., B(m), it is said that the target configuration satisfies the dependency [ B(1), ..., B(m) ]. A dependency consisting of zero dependency branches is said to be empty, and an empty dependency is unconditionally satisfied by any target configuration.

[0079] Also, in this specification, for simplicity of description and without causing confusion, the dependency [B] is simply denoted as B, and the dependency item N:{s} is simply denoted as N:s.

[0080] Let the dependency associated with the transition N:s1 → s2 in the recovery state transition system be denoted as DEP(N:s1 → s2), and the dependency associated with the state N:s in the set of recovery states be denoted as DEP(N:s).

[0081] Also, assume that the following holds for each state s(1),..., s(m) in the set of recovery states. Regardless of the state of the target configuration, exactly one of the dependencies DEP(s(1)),..., DEP(s(m)) is satisfied.

[0082] Next, the meaning of the dependency is explained. The dependency has completely different meanings depending on whether it is related to the recovery state transition system or the set of recovery states.

[0083] First, for the transition N:s1 → s2 in the recovery state transition system, the recovery state transition system of node N cannot perform the state transition from s1 to s2 unless the target configuration satisfies the dependency DEP(N:s1 → s2). That is, the dependency on the recovery state transition system defines the "conditions regarding the surrounding situation" for performing the state transition.

[0084] Second, for the state N:s in the set of recovery states, it is defined that the state of node N being s means that the target configuration satisfies the dependency DEP(s). That is, the dependency on the stateless element corresponds to the "definition" of each state of the stateless element as it is, and it expresses the property that the stateless node cannot transition its state by itself and the state changes in conjunction with the surrounding situation.

[0085] (Supplement) Regarding the dependencies attached to each state of the stateless type, note that due to its nature, more than two dependencies of the same set of recovery states cannot be satisfied simultaneously, nor can none of them be satisfied. That is, regardless of the state of the surrounding structure, among the four dependencies attached to the states F, A, C, and H one by one, exactly only one is satisfied.

[0086] FIG. 16 is an explanatory diagram showing one of the recovery models for the tangible type App, and corresponds to the expected configuration E1300 in FIG. 13.

[0087] The recovery model described in FIG. 16 includes a recovery state transition system corresponding to the App type node SELF and the Machine type node M. Also, dependencies M:H are attached to the transitions A→C, C→H, and H→C in the recovery state transition system of SELF, and dependencies SELF:F is attached to the transition H→F and dependency SELF:{C,A,F} is attached to the transition H→C in the recovery state transition system of M. Therefore, for example, the transition of the App type node from state A to state C when the expected configuration E1300 is applied cannot be executed unless the node of the host destination machine is in state H.

[0088] FIG. 18 is an explanatory diagram showing a recovery model for the intangible type Service, and corresponds to the expected configuration described in FIG. 17.

[0089] The expected configuration described in FIG. 17 represents that the type Service representing a certain service needs to be composed of two applications AppX and AppY.

[0090] The recovery model described in FIG. 18 includes a set of recovery states corresponding to the Service type node SELF and recovery state transition systems corresponding to the AppX type node AX and the AppY type node AY. Also, dependencies [{AX:F},{AY:F}] are attached to state F in the set of recovery states of SELF, dependencies [{AX:A,AY:[A,C,H]},{AX:[A,C,H],AY:A}] are attached to state A, dependencies [{AX:C, AY:[C,H]},{AX:[C,H],AY:C}] are attached to state C, and dependencies [{AX:H, AY:H}] are attached to state H, respectively. The combination of states { AX:s(x), AY:s(y)} in the recovery state transition systems of AX and AY is configured to satisfy any one of the above four dependencies, and the state corresponding to the satisfied dependency becomes the state of the node SELF corresponding to {AX:s(x), AY:s(y)}.

[0091] The above is the description of the "type" and "component model" associated with the entity.

[0092] The "satisfaction flag" of the entity will be described below.

[0093] For an entity of type T, a set of flags keyed by all the ancestor types T(1), T(2),..., T(m) of type T and type T itself are associated. This is called the satisfaction flag of the entity. Each flag is assigned a value of TRUE or FALSE.

[0094] When all the satisfaction flags are TRUE, the satisfaction flag is said to be satisfied, and when there is a FALSE one, it is said to be insufficient. In particular, when the flag regarding type T(i) is FALSE, the entity is said to be insufficient regarding type T(i). As will be described later, the expected configuration of type T(i) can be applied to an entity that is insufficient regarding type T(i), and the flag becomes TRUE simultaneously with the application.

[0095] Note that entities originally included in the abstract configuration and entities newly generated by the application of the expected configuration (described later) are given satisfaction flags keyed by themselves and their ancestor types, and the initial value of each flag's value is FALSE if there is an expected configuration for the type that is the key, and TRUE otherwise.

[0096] The above is the description of the "satisfaction flag" of the entity.

[0097] Next, the "global state model" of the abstract configuration will be described.

[0098] The "global state model" of the abstract configuration is a data structure consisting of state element models for all nodes included in the abstract configuration and the dependencies between them. Similar to the recovery model, the transitions of each recovery state transition system can be executed only when the dependencies are satisfied.

[0099] In the global state model of the abstract configuration, each time the expected configuration is applied in the automatic design procedure, the dependencies defined in the recovery model of the expected configuration are added. It can be considered that the global state model corresponding to the functional requirements received as input by the system configuration derivation device 100 has no dependencies defined, and dependencies are added only when the expected configuration is applied.

[0100] (Supplementary Note) However, each embodiment of the present disclosure does not require that there be no dependencies in the global state model corresponding to the functional requirements. Initial values of dependencies may be set for the global state model of the functional requirements based on some criteria.

[0101] The global state model can be regarded as one large state transition system (representing the state transitions of the system). The state when the global state model is regarded as one state transition system is called the "global state", which is defined as the state data {n(1): s(1),..., n(m): s(m)} obtained by combining the states s(1),..., s(m) of each node n(1),..., n(m) in the abstract configuration. The initial state of the global state model is the combination of the initial states of each node. The global state model transitions its state by transitioning one recovery state transition system contained in itself. That is, when the state of node n(i) transitions from A to C, the global state of the abstract configuration transitions from {n(1): s(1),..., s(i): A,..., n(m): s(m)} to {n(1): s(1),..., s(i): C,..., n(m): s(m)}.

[0102] FIG. 21 is an example of a global state model corresponding to the abstract configuration described in FIG. 19. However, here it is assumed that the initial state of all nodes is H. The initial state of each node is represented by a black-filled circle, and the initial state of this global state model is represented as {S1: H, App1: H, App2: H, M1: H}.

[0103] The initial state of the global state model described in FIG. 21, {S1:H, App1:H, App2:H, M1:H}, can be transitioned to the global states {S1:F, App1:F, App2:H, M1:H} and {S1:F, App1:H, App2:F, M1:H} respectively by executing the transitions H→F for App1 and App2. Here, the state of S1 also transitions in conjunction with the transitions of App1 (and App2). On the other hand, the transition H→F of M1 cannot be executed because the attached dependencies are not satisfied in the initial state, but it can be executed in the global state {S1:F, App1:F, App2:H, M1:H} where App1 has been transitioned to F, and when executed, it transitions to the global state {S1:F, App1:F, App2:H, M1:F}.

[0104] The above is the explanation of the "global state model" of the abstract configuration.

[0105] Next, the recovery time requirements will be explained. There are two types of recovery time requirements: "temporary recovery time requirement" and "complete recovery time requirement", which are defined for each node respectively.

[0106] The "temporary recovery time requirement" for node N specifies the upper limit of the time from the state where a failure has occurred in node N until the state of node N is restored to the normal operating state.

[0107] The "complete recovery time requirement" for node N specifies the upper limit of the time from the state where a failure has occurred in node N until the states of all nodes that depend on the normal operation of node N are restored to the initial state.

[0108] For any type of recovery time requirement, an upper limit of the time required for recovery is defined. This is called the "recovery time upper limit" of the recovery time requirement.

[0109] The above is the explanation regarding the recovery time requirements.

[0110] Next, the concretization of the abstract configuration will be described. For the abstract configuration, there are two concretization operations: "application of the expected configuration" and "refinement of the type". Both operations can be performed, and in either case, one or more abstract configurations are newly obtained as a result of the operation.

[0111] First, the "application of the expected configuration" for the abstract configuration D is performed according to the following steps.

[0112] 1. Select an entity e included in D for which the satisfaction flag is lacking.

[0113] 2. Select the type T that entity e lacks.

[0114] 3. For each expected configuration EX of type T such that the prerequisite configuration is included in D, output the result of performing the following operations on the abstract configuration D as the result of the "application of the expected configuration" operation.

[0115] The following operations are as follows: that is, "add the necessary entities so that the expected configuration EX appears in a form where entity e matches SELF. Then, update the satisfaction flag for the type T of entity e to TRUE. However, if there are multiple ways of making it appear, output them all as separate abstract configurations."

[0116] Supplement for the case of "multiple ways of making it appear" in step 3. For an abstract configuration D with only two nodes, an App type node A1 and a Machine type node M1, and no edges, when applying the expected configuration shown in E1300 of FIG. 13, the methods of applying the expected configuration to the abstract configuration D are as follows: "(1) newly add a Machine type node M2 to D, and further add a HOST type edge H2 connecting A1 and M2" and "(2) add a HOST type edge H1 connecting A1 and M1". There may be multiple candidates for the form of adding the expected configuration to the abstract configuration in this way, and step 3 outputs all of them as the result of the "application of the expected configuration" operation.

[0117] Second, the "type refinement" operation on the abstract configuration D is performed according to the following steps.

[0118] 1. Select an entity e with an abstract type included in D.

[0119] 2. For all types T' that inherit from the type T of the entity e, output the result of performing the following operations on the abstract configuration D as the result of the "type refinement" operation.

[0120] "Change the type of the entity e to T', and add a flag with T' as the key to the satisfaction flag. However, the value of the flag of T' shall be FALSE if there is one or more expected configurations in T', and TRUE if there is no such configuration."

[0121] The above is the explanation of the concretization of the abstract configuration.

[0122] Next, the concretization of the abstract configuration will be explained using a specific example. FIG. 22 is a diagram for explaining an example of concretizing FIG. 19 in three different ways according to the expected configuration shown in FIG. 13.

[0123] The abstract configuration 2200 is a case where the expected configuration E1300 of the type App of the node App2 is applied to generate and connect a new Machine type node M2.

[0124] The abstract configuration 2201 is also a case where the expected configuration E1300 of the type App of the node App2 is applied, but instead of generating a new node, it is a case of connecting the Machine type node M1 already included in FIG. 19.

[0125] The abstract configuration 2202 is also a case where the expected configuration E1301 of the type App of the node App2 is applied to generate and connect a new Container type node C1.

[0126] The above three cases are all conversions that advance the one-step concretization by applying the expected configuration to the node App2, which is an abstract element, to the original abstract configuration of FIG. 19.

[0127] Furthermore, although the abstract configurations 2200 and 2201 apply exactly the same expected configuration to exactly the same nodes, it is worth noting that differences occur in the resulting configurations due to differences in the concretization methods. That is, even if the original abstract configuration and the applied expected configuration are exactly the same, the conversion proceeds to various configurations due to differences in the conversion methods, and as a result, various concrete configurations are generated.

[0128] The above is the explanation of rewriting the abstract configuration by concretization.

[0129] Next, an exact definition of the concrete configuration derived from each embodiment of the present disclosure will be described.

[0130] The concrete configuration in this embodiment refers to a completely concretized abstract configuration. Here, that the abstract configuration is "completely concretized" means that all of the following three types of concretized conditions (concretized condition 1), (concretized condition 2), and (concretized condition 3) are satisfied.

[0131] (Concretized condition 1) The abstract configuration does not include any nodes having an abstract type.

[0132] (Concretized condition 2) The abstract configuration does not include any edges having an abstract type.

[0133] (Concretized condition 3) The abstract configuration does not include any entities lacking a satisfaction flag.

[0134] From the definition of the concretized conditions, it can be said that an abstract configuration that does not include unit requirements indicates a state where there is no ambiguity as an ICT system and all the parts necessary for operation (= the expected configuration for each entity) are present. Therefore, the concrete configuration corresponds to a system that functions completely operably.

[0135] (Operation) The system configuration derivation device 100 of this embodiment receives, as input, an abstract configuration representing functional requirements and recovery time requirements for nodes included in the abstract requirements, and outputs a specific configuration that satisfies both the functional requirements and the recovery time requirements.

[0136] Details of the processing of each part of the system configuration derivation device 100 will be described below.

[0137] The dependency recovery cost calculation unit 102 of this embodiment receives, as input, the entire configuration component model corresponding to each type, and calculates the dependency recovery cost for each transition of the recovery state transition system included in each configuration component model.

[0138] As a premise, the meaning of the "dependency recovery cost" output by the dependency recovery cost calculation unit 102 will be explained. In order to recover the system from a failure, it is necessary to transition an entity in a failure state to another state. At this time, since the dependency of the recovery model needs to be satisfied, it is necessary to transition the prerequisite structure for the recovery of the element. At this time, if a failure has occurred in the prerequisite structure in addition to the entity, it is necessary to additionally recover these elements in order to recover the entity. Under the premise that each entity included in the target configuration is in a failure state, the state transition of other entities required to transition the entity from the "failure" state (F) to another state is called the "dependency recovery cost".

[0139] Furthermore, regarding the peripheral configuration of the entity, the expected configuration regarding the entity included therein is additionally specified. Therefore, it is also called the dependency recovery cost including the recovery cost considering these.

[0140] The dependency recovery cost basically becomes a list of data meaning "it is necessary to move the node of type T from the state F to another state s". The data meaning "it is necessary to move the node of type T from the state F to another state s" is called the "unit recovery cost" and is denoted as Cost(T:s).

[0141] Also, as will be described later, in this embodiment, in order to obtain data approximated to a certain extent instead of the actual dependency recovery cost, for a plurality of types T(1), ..., T(m) instead of a single type, a unit recovery cost representing "the cost required to recover nodes of types T(1), ..., T(m)" is used. Such a unit recovery cost is used to ignore the specific recovery procedure and consider only the time cost L required for recovery. Therefore, the above-mentioned unit recovery cost will be denoted as AbsCost(T(1), ..., T(m):L).

[0142] When it is necessary to distinguish between the above two types of unit recovery costs, Cost(T:s) is called the "specific" unit recovery cost, and AbsCost(T(1), ..., T(m):L) is called the "abstract" unit recovery cost.

[0143] Also, the "required time" for the unit recovery cost is defined as follows in 1 to 3 below.

[0144] 1. When T is a tangible type, it is assumed that the required time for the specific unit recovery cost Cost(T:s) is the total transition time cost of the state transitions required to move T from state F to state s on the state element model.

[0145] 2. When T is an intangible type, it is assumed that the required time for the specific unit recovery cost Cost(T:s) is 0.

[0146] 3. It is assumed that the required time for the abstract unit recovery cost AbsCost(T(1), ..., T(m):L) is L.

[0147] The above is the description of the dependency recovery cost.

[0148] However, since it is generally difficult to enumerate all the structures that can be derived from the expected configuration of an entity, the dependency recovery cost calculation unit 102 of this embodiment obtains and outputs a subset of the actual dependency recovery cost.

[0149] Below, using specific examples, an overview of the dependency recovery cost actually determined by the dependency recovery cost calculation unit 102 of the present embodiment will be described.

[0150] For the exemplification of the dependency recovery cost, the ones shown in FIG. 26 are used as the assumed expected configuration and recovery model. Here, an environment is assumed where there are six node types: Target, Sub, SubA, SubB, SubC, and Machine, and two edge types: Conn and Host. (Since it is a formal one for explanation, it is not an image of specific system components.)

[0151] All node types are tangible types. Also, Target, SubA, SubB, SubC, Machine, Conn, and Host are specific types, and types other than Target do not have an expected configuration. Sub is an abstract type and is inherited by SubA, SubB, and SubC.

[0152] As shown in FIG. 26, the Target type has two expected configurations E2600 and E2601, and the Sub type has one expected configuration E2602. Also, recovery models R2603, R2604, and R2605 are respectively associated with the expected configurations E2600, E2601, and E2602.

[0153] Regarding the transition time cost of each transition in the recovery state transition system of SubA, SubB, and SubC, respectively, "(For SubA) the cost of A → C is 2, the cost of C → H is 3, and the cost of other transitions is 0" "(For SubB) the cost of A → C is 2, the cost of C → H is 1, and the cost of other transitions is 0" "(For SubC) the cost of A → C is 4, the cost of C → H is 2, and the cost of other transitions is 0" are defined.

[0154] Under the above premises, considering the case of specifying the functional requirements including only nodes of the Target type, the following three patterns can be considered. (Here, the state transition in the procedure of F → A → C → H is called "recovery".)

[0155] (Pattern 1) "SubA type node n1 and Machine type node n2 are generated, and to recover Target, the recovery of two nodes n1 and n2 is additionally required."

[0156] (Pattern 2) "SubB type node n1, SubC type node n2, and Machine type node n3 are generated, and to recover Target, the recovery of three nodes n1, n2, and n3 is additionally required."

[0157] (Pattern 3) "SubB type node n1, SubC type node n2, Machine type nodes n3, and n4 are generated, and to recover Target, the recovery of four nodes n1, n2, n3, and n4 is additionally required."

[0158] The dependency recovery cost calculation unit 102 of the present embodiment obtains the lower limit of the cost additionally required for recovery as the dependency recovery cost. Therefore, in the case of the above situation, the recovery cost required to recover the Target type node from state F to state H is considered to include, in addition to its own recovery cost, "the recovery cost required to recover one Machine type node" and "the recovery cost required to recover one SubA, SubB, or SubC type node".

[0159] Actually, when the state element model shown in FIG. 26 is input to the dependency recovery cost calculation unit 102 of the present embodiment, a value of [Cost(Machine:H), AbsCost(SubA,SubB,SubC:3)] is returned as the recovery cost DC[Target][H] from F to H of the Target type. Although details will be described later, Cost(Machine:H) means "the recovery cost for transitioning the state of the Machine type from F to H", and AbsCost(SubA,SubB,SubC:3) means "the recovery cost corresponding to any one of SubA, SubB, and SubC parts and having a transition time cost of 3".

[0160] The above is an explanation of a specific example of the value of the dependency recovery cost output by the dependency recovery cost calculation unit 102 of the present embodiment.

[0161] Details of the processing of each part of the dependency recovery cost calculation unit 102 will be described below.

[0162] (Operation of the Dependency Recovery Cost Calculation Procedure Control Unit 200) First, the details of the operation of the dependency recovery cost calculation procedure control unit 200 of the present embodiment will be described. FIG. 6 is a flowchart showing the overall operation of the dependency recovery cost calculation procedure control unit 200 of the present embodiment.

[0163] The dependency recovery cost calculation procedure control unit 200 receives as input a list T(1), T(2),..., T(m) of types (component models) (step S600).

[0164] The dependency recovery cost calculation procedure control unit 200 performs the following "duplication" operation on the recovery models included in T(1), T(2),..., T(m) until each of the dependencies included in all the recovery models contains at most one dependency branch. The following "duplication" operation means that, for a recovery model containing dependencies [B(1), B(2),..., B(m)] with two or more dependency branches, the recovery model is "duplicated" for each target configuration by the number m of the included dependency branches, and dependencies [B(1)], [B(2)],..., [B(m)] with only one dependency branch are associated with each of them (step S601).

[0165] (Note) The state element model data subjected to this "duplication" is used only during the operation of the dependency recovery cost calculation unit 102, and the original state element model data is referred to in the configuration concretization unit 101.

[0166] The dependency recovery cost calculation procedure control unit 200 initializes all the dependency recovery cost information DC as follows. Since the all dependency recovery cost information has a dictionary structure with two keys of type and transition destination state, for each type T and each state s (other than F), initialize DC[T][s] := {} (an empty dictionary) (step S602).

[0167] The dependency recovery cost calculation procedure control unit 200 groups types T(1), T(2),..., T(m) that are in an inheritance relationship with each other to form groups of types G(1), G(2),..., G(k). In this specification, it is assumed that the inheritance relationship of types is a set of tree structures, so one tree structure corresponds to one group (step S603).

[0168] The dependency recovery cost calculation procedure control unit 200 constructs a graph TG with groups as nodes by drawing a directed edge G(i) → G(j) corresponding to the relationship that "the expected configuration of the types included in group G(i) includes entities of the types in group G(j)" among the groups G(1), G(2),..., G(k) (step S604).

[0169] The dependency recovery cost calculation procedure control unit 200 removes all loops included in the graph TG by deleting the edges that form the loops (step S605).

[0170] The dependency recovery cost calculation procedure control unit 200 topologically sorts the graph TG to obtain a list of groups G(1), G(2),..., G(k) (step S606). (That is, if there is an edge G(i) → G(j) in TG, then in the list, G(j) appears earlier.)

[0171] The dependency recovery cost calculation procedure control unit 200 sequentially selects groups G from the head of the list of groups G(1), G(2),..., G(k) and executes step S608 for each of them (step S607).

[0172] For each type T included in group G, the tangible type-dependent recovery cost construction unit 201 is input for the tangible type, and the intangible type-dependent recovery cost construction unit 202 is input for the intangible type, and the output obtained by inputting type T is set to DC[T] (step S608).

[0173] For each type T included in group G, the dependency recovery cost calculation procedure control unit 200 inputs type T and all dependency recovery cost information DC to the dependency recovery cost propagation unit 203 and obtains the output ADC[T] (step S609).

[0174] For each type T included in group G and each state s of the state element model of type T, the dependency recovery cost calculation procedure control unit 200 adds the element of ADC[T][s] to DC[T][s] (step S610).

[0175] After the dependency recovery cost calculation procedure control unit 200 executes the procedures from step S608 to step S610 for all groups G(1), G(2),..., G(k), it proceeds to step S612 (step S611).

[0176] The dependency recovery cost calculation procedure control unit 200 outputs all dependency recovery cost information DC (step S612).

[0177] The above is the description of the operation of the dependency recovery cost calculation procedure control unit 200 of the present embodiment.

[0178] (Operation of the tangible type-dependent recovery cost construction unit 201) Next, the operation of the tangible type-dependent recovery cost construction unit 201 of the present embodiment will be described. FIG. 7 is a flowchart showing the overall operation of the tangible type-dependent recovery cost construction unit 201 of the present embodiment.

[0179] The tangible type-dependent recovery cost construction unit 201 receives type T as input (step S700).

[0180] The tangible type-dependent recovery cost construction unit 201 initializes the dependency recovery cost DC(T) of T with DC(T) := {} (an empty dictionary) (step S701).

[0181] The tangible type-dependent recovery cost construction unit 201 initializes the temporary dependency recovery cost TDC as follows. That is, the temporary dependency recovery cost is a dictionary structure with the states of the state element model of T as keys, and for each state s (other than F), it is initialized with TDC[s] := [] (an empty list) (step S702).

[0182] The tangible type-dependent recovery cost construction unit 201 executes the procedure from step S704 to step S707 for each expected configuration E of type T (step S703).

[0183] The tangible type-dependent recovery cost construction unit 201 obtains the recovery model M associated with the expected configuration E (step S704).

[0184] The tangible type-dependent recovery cost construction unit 201 executes step S706 for each non-redundant path PATH = F→A, F→A→C, F→A→C→H from state F to other states on the recovery model (step S705).

[0185] The tangible type-dependent recovery cost construction unit 201 calculates the node states {n(1):s(1),..., n(m):s(m)} of the target configuration necessary to execute the path PATH, and adds them to the list TDC[s] (step S706). (Here, s is the state at the end of the path PATH)

[0186] (Supplement to step S706-1) Here, a supplement is made regarding the calculation of the "node states of the target configuration necessary to execute the path PATH". Assume a state where all the states of each state element model included in the recovery model M are F, and in order to transition the state element model corresponding to the node SELF along the path PATH from there by state transition, consider minimally transitioning the state element models of the surrounding nodes (to satisfy the dependencies).

[0187] (Supplement 2 to Step S706) When the transition along the PATH is completed, the states of the peripheral nodes {n(1):s(1), ..., n(m):s(m)} are the "node states of the target configuration required to execute the PATH". To recover an entity of type T with the expected configuration EX, at least the peripheral configuration must be set to the state of {n(1):s(1), ..., n(m):s(m)}, and additional transition costs will be incurred for this.

[0188] (Supplement 3 to Step S706) For a specific explanation, consider executing Step S706 for the recovery model shown in FIG. 24. FIG. 24 is a recovery model for nodes of the Target type and includes three peripheral components S1:SubA, S2:SubB, S3:SubC. Further, as dependencies, {S1:[C,H], S2:C} is attached to the transition SELF:A → C, and {S2:H, S3:[C,H]} is attached to the transition SELF:C → H, respectively.

[0189] (Supplement 4 to Step S706) FIG. 25 is a diagram showing the node states of the target configuration required for the execution of each transition SELF:F → A, SELF:A → C, SELF:C → H. There is no state required to execute the transition SELF:F → A. The node state {S1:C, S2:C} is required to execute the transition SELF:A → C, and the node state {S2:H, S3:C} is required to execute the transition SELF:C → H. Based on this information, it can be seen that there is no node state of the target configuration required to execute the path F → A, and the node state {S1:C, S2:C} is required to execute the path F → A → C. Also, to execute the path F → A → C → H, it is considered necessary to transition to the state for executing C → H after transitioning to the state for executing A → C. Therefore, it can be seen that the node information {S1:C, S2:H, S3:C} is required.

[0190] (Supplement to Step S706) Therefore, when Step S706 is executed for the recovery model shown in FIG. 24, TDC[A]={}, TDC[C]={S1:C, S2:C}, TDC[H]={S1:C, S2:H, S3:C} are respectively set. The above is the supplementary information for Step S706.

[0191] After the tangible type-dependent recovery cost construction unit 201 executes Step S706 for all paths, it proceeds to Step S708 (Step S707).

[0192] After the tangible type-dependent recovery cost construction unit 201 executes the procedures from Step S704 to Step S707 for all expected configurations, it proceeds to Step S709 (Step S708).

[0193] The tangible type-dependent recovery cost construction unit 201 executes the procedures from Step S710 to Step S712 for each state s other than F of the state element model of type T (Step S709).

[0194] The tangible type-dependent recovery cost construction unit 201 converts each state {n(1):s(1),..., n(m):s(m)} in the temporary dependency recovery cost TDC[s] into the dependency recovery costs Cost(T(1):s(1)),..., Cost(T(m):s(m)) (where T(i) is the type of entity n(i)), and obtains a list DCList(s) of dependency recovery costs (Step S710).

[0195] The tangible type-dependent recovery cost construction unit 20 adds the dependency recovery costs derived from T(1),..., T(m) to each dependency recovery cost DCItem = Cost(T(1):s(1)),..., Cost(T(m):s(m)) included in the list DCList(s) of dependency recovery costs. That is, it adds all the contents of DC[T(i)][s(i)] for each Cost(T(i):s(i)) to DCItem (Step S711).

[0196] The tangible type-dependent recovery cost construction unit 201 inputs DCList(s) to the dependent recovery cost integration unit 204 and sets the output from the dependent recovery cost integration unit 204 to DC(T)[s] (step S712).

[0197] After the tangible type-dependent recovery cost construction unit 201 executes the procedures from step S710 to step S712 for all states s other than F in the state element model of type T, it proceeds to step S714 (step S713).

[0198] The tangible type-dependent recovery cost construction unit 201 outputs DC(T) to the dependent recovery cost calculation procedure control unit 200 (step S714).

[0199] (Operation of the intangible type-dependent recovery cost construction unit 202) Next, the operation of the intangible type-dependent recovery cost construction unit 202 of this embodiment will be described. FIG. 8 is a flowchart showing the overall operation of the intangible type-dependent recovery cost construction unit 202 of this embodiment.

[0200] The intangible type-dependent recovery cost construction unit 202 receives type T as input (step S800).

[0201] The intangible type-dependent recovery cost construction unit 202 initializes the dependent recovery cost DC(T) of T with DC(T) := {} (an empty dictionary) (step S801).

[0202] The intangible type-dependent recovery cost construction unit 202 initializes the temporary dependent recovery cost TDC as follows. That is, the temporary dependent recovery cost is a dictionary structure with the states of the state element model of T as keys, and for each state s (other than F), it is initialized with TDC[s] := [] (an empty list) (step S802).

[0203] The intangible type-dependent recovery cost construction unit 202 executes the procedures from step S804 to step S807 for each expected configuration E of type T (step S803).

[0204] The intangible-type dependent recovery cost construction unit 202 acquires a recovery model M associated with the expected configuration E (step S804).

[0205] For each state s = A, C, H of the recovery model M, the intangible-type dependent recovery cost construction unit 202 executes step S806 (step S805).

[0206] The intangible-type dependent recovery cost construction unit 202 calculates the node states {n(1):s(1),..., n(m):s(m)} of the target configuration necessary to set the state of the recovery model M to s, and adds them to the list TDC[s] (step S806).

[0207] (Supplement 1 to step S806) Here, a supplement is made regarding the calculation of "the node states of the target configuration necessary to set the state of the recovery model M to s". From the definition, to set the state of the recovery model M to s, it is only necessary to satisfy the dependencies associated with s. Therefore, first assume a state where all the state element models of each state element model included in the recovery model M are in F, and consider minimally transitioning the state element models of the surrounding nodes (to satisfy the dependencies) so as to satisfy the dependencies associated with s.

[0208] (Supplement 2 to step S806) The states {n(1):s(1),..., n(m):s(m)} of the surrounding nodes at the stage where the dependencies can be satisfied are "the node states of the target configuration necessary to set the state of the recovery model M to s". To recover an entity of type T having the expected configuration EX, at least the surrounding configuration must be set to the state of {n(1):s(1),..., n(m):s(m)}, and additional transition costs will be incurred for this. The above is the supplementary information for step S806.

[0209] After the intangible-type dependent recovery cost construction unit 202 executes step S806 for all states, it proceeds to step S808 (step S807).

[0210] After the intangible type-dependent recovery cost construction unit 202 executes the procedures from step S804 to step S807 for all expected configurations, it proceeds to step S809 (step S808).

[0211] For each state s other than F in the state element model of type T, the intangible type-dependent recovery cost construction unit 202 executes the procedures from step S810 to step S812 (step S809).

[0212] The intangible type-dependent recovery cost construction unit 202 converts each state {n(1):s(1),..., n(m):s(m)} in the temporary dependent recovery cost TDC[s] into the dependent recovery costs Cost(T(1):s(1)),..., Cost(T(m):s(m)) (where T(i) is the type of entity n(i)) to obtain a list DCList(s) of dependent recovery costs (step S810).

[0213] For each dependent recovery cost DCItem = Cost(T(1):s(1)),..., Cost(T(m):s(m)) included in the list DCList(s) of dependent recovery costs, the intangible type-dependent recovery cost construction unit 202 adds the dependent recovery costs derived from T(1),..., T(m). That is, it adds all the contents of DC[T(i)][s(i)] for each Cost(T(i):s(i)) to DCItem (step S811).

[0214] The intangible type-dependent recovery cost construction unit 202 inputs DCList(s) to the dependent recovery cost integration unit 204 and sets the output from the dependent recovery cost integration unit 204 to DC(T)[s] (step S812).

[0215] After the intangible type-dependent recovery cost construction unit 202 executes the procedures from step S810 to step S812 for all states s other than F in the state element model of type T, it proceeds to step S814 (step S813).

[0216] The intangible type-dependent recovery cost construction unit 202 outputs DC(T) to the dependent recovery cost calculation procedure control unit 200 (step S814).

[0217] The above is the description of the operation of the intangible type-dependent recovery cost construction unit 202 of the present embodiment.

[0218] (Operation of the Dependent Recovery Cost Integration Unit 204) Next, the operation of the dependent recovery cost integration unit 204 of the present embodiment will be described. FIG. 9 is a flowchart showing the overall operation of the dependent recovery cost integration unit 204 of the present embodiment.

[0219] The dependent recovery cost integration unit 204 receives the list DCList of dependent recovery costs as an input (step S900).

[0220] The dependent recovery cost integration unit 204 initializes the integrated dependent recovery cost IDC to be output with an empty list (step S901).

[0221] The dependent recovery cost integration unit 204 adds all the unit recovery costs commonly included in all the elements of DCList to IDC, and then removes them from each element of DCList (step S902).

[0222] The dependent recovery cost integration unit 204 removes all the specific unit recovery costs related to the intangible type from each dependent recovery cost included in DCList (step S903).

[0223] The dependent recovery cost integration unit 204 obtains the minimum value of the required time of all the unit recovery costs included in DCList, and sets this as Lmin (step S904).

[0224] The dependent recovery cost integration unit 204 obtains the minimum value of the number of unit recovery costs included in each dependent recovery cost of DCList, and sets this as Nmin (step S905).

[0225] The dependency recovery cost integration unit 204 constructs a list Types that enumerates (excluding duplicates) all types of unit recovery costs included in the DCList. That is, it collects all of T(1) for the specific unit recovery cost Cost(T(1):s(1)) and T(1), T(2), ..., T(m) in the abstract unit recovery cost AbsCost(T(1), T(2), ..., T(m):L) into one list (step S906).

[0226] The dependency recovery cost integration unit 204 adds Nmin abstract unit recovery costs AbsCost(Types: Lmin) to the IDC (step S907).

[0227] The dependency recovery cost integration unit 204 returns the IDC as output (step S908).

[0228] The above is the description of the operation of the dependency recovery cost integration unit 204 in this embodiment.

[0229] (Operation of the Dependency Recovery Cost Propagation Unit 203) Next, the operation of the dependency recovery cost propagation unit 203 in this embodiment will be described. FIG. 10 is a flowchart showing the overall operation of the dependency recovery cost propagation unit 203 in this embodiment.

[0230] The dependency recovery cost propagation unit 203 receives the type T and all dependency recovery cost information DC as input (step S1000).

[0231] The dependency recovery cost propagation unit 203 initializes the output dependency recovery cost information ADC with a dictionary having states A, C, H as keys and empty lists as values (ADC[A]=[], ADC[C]=[], ADC[H]=[])(step S1001).

[0232] The dependency recovery cost propagation unit 203 obtains a list ATypes consisting of all ancestor types of the type T (step S1002).

[0233] The dependency recovery cost propagation unit 203 executes step S1004 for all types AT included in Atypes (step S1003).

[0234] For each state s, the dependency recovery cost propagation unit 203 adds the content of DC[AT][s] to ADC[s] (step S1004).

[0235] After the dependency recovery cost propagation unit 203 executes step S1004 for all types AT included in Atypes, it proceeds to step S1007 (step S1005).

[0236] The dependency recovery cost propagation unit 203 initializes the lists DCList(A), DCList(C), and DCList(H) of the dependency recovery costs for states A, C, and H to empty lists, respectively (step S1006).

[0237] The dependency recovery cost propagation unit 203 obtains a list CTypes consisting of all types that are both descendant types of type T and concrete types (step S1007).

[0238] The dependency recovery cost propagation unit 203 executes the procedures from step S1009 to step S1013 for all types CT included in Ctypes (step S1008).

[0239] The dependency recovery cost propagation unit 203 obtains a chain of inheritance relationships T ⇒ T(1) ⇒ T(2) ⇒... ⇒ T(m) ⇒ CT that connects type T to type CT (step S1009). (Under the process where the inheritance relationship of types takes a tree structure, there is exactly one such chain.)

[0240] The dependency recovery cost propagation unit 203 executes the procedures from step S1011 to step S1012 for each state s = A, C, H (step S1010).

[0241] The dependency recovery cost propagation unit 203 obtains a list of dependency recovery costs DC[T(1)][s], DC[T(2)][s],..., DC[T(m)][s], DC[CT][s] for types T(1), T(2),..., T(m), CT other than T included in the chain T ⇒ T(1)⇒ T(2) ⇒... ⇒ T(m) ⇒ CT obtained in step S1009 (step S1011).

[0242] The dependency recovery cost propagation unit 203 concatenates the lists obtained in the previous step and adds the result, regarded as one dependency recovery cost, to DCList[s] (step S1012).

[0243] After the dependency recovery cost propagation unit 203 executes the procedures from step S1011 to step S1012 for all states s = A, C, H, it proceeds to step S1014 (step S1013).

[0244] After the dependency recovery cost propagation unit 203 executes the procedures from step S1009 to step S1013 for all types CT included in Ctypes, it proceeds to step S1015 (step S1014).

[0245] The dependency recovery cost propagation unit 203 inputs DCList[A], DCList[C], and DCList[H] to the dependency recovery cost integration unit 204 respectively, and adds the returned outputs IDC[A], IDC[C], IDC[H] for each input to ADC[A], ADC[C], ADC[H] respectively (step S1015).

[0246] The dependency recovery cost propagation unit 203 returns ADC as the output to the dependency recovery cost calculation procedure control unit 200 (step S1016).

[0247] The above is the description of the operation of the dependency recovery cost propagation unit 203 in this embodiment.

[0248] The above is the description of the operation of each part of the dependency recovery cost calculation unit 102 in this embodiment.

[0249] The overall operation will be outlined below by a specific operation example of the dependency recovery cost calculation unit 102 of the present embodiment. As input data, the state element model illustrated in FIG. 26, which consists of Target, Sub, SubA, SubB, SubC, Machine, Conn, and Host used in the exemplification of the dependency recovery cost, is used. Hereinafter, this input is referred to as the state element model EXPL.

[0250] First, the dependency recovery cost calculation procedure control unit 200 groups the node types and creates a graph structure based on the information of the expected configuration. FIG. 27 is a graph of the type groups configured based on the state element model EXPL. Three type groups are generated: G1 = {Target}, G2 = {Sub, SubA, SubB, SubC}, and G3 = {Machine}, and edges are drawn from G1 to G2 and from G2 to G3. The dependency recovery cost calculation procedure control unit 200 executes a process of obtaining the dependency recovery cost in the order of the topological sort of this graph, that is, in the order of G3, G2, and G1.

[0251] First, the processing for G3 will be described.

[0252] Since there is only one Machine type in G3 and it has no expected configuration, the procedure of the tangible type dependency recovery cost construction unit 201 for the Machine type immediately ends.

[0253] Since the Machine type has neither descendant types nor ancestor types, the processing of the dependency recovery cost propagation unit 203 also immediately ends, and as a result, the dependency recovery cost of the Machine type is completely empty, that is, DC[Machine][A] = [], DC[Machine][C] = [], DC[Machine][H] = [].

[0254] Next, the processing for G2 will be described.

[0255] Among the types included in G2, SubA, SubB, and SubC do not have the expected configuration like the Machine type, so the procedure of the tangible type - dependent recovery cost construction unit 201 ends immediately.

[0256] Explain the outline of the processing of the tangible type - dependent recovery cost construction unit 201 for Sub types.

[0257] The tangible type - dependent recovery cost construction unit 201 calculates the temporary dependent recovery cost based on the Sub - type recovery model. As a result, TDC[A]=[], TDC[C]=[], TDC[H]=[{M1:H}] is obtained.

[0258] The tangible type - dependent recovery cost construction unit 201 calculates the dependent recovery cost based on the calculated temporary dependent recovery cost. Since TDC[A] and TDC[C] are empty lists, the dependent recovery costs DC[Sub][A] and DC[Sub][C] for them are also empty. When converting the elements of TDC[H] into a list of dependent recovery costs, it becomes [[Cost(Machine:H)]]. Since the dependent recovery cost integration unit 204 outputs the single element as it is when there is only one element, as a result, DC[Sub][H]=[Cost(Machine:H)].

[0259] Since G2 contains multiple types with type inheritance relationships, the processing by the dependent recovery cost propagation unit 203 is performed. The dependent recovery cost propagation unit 203 propagates the information of the Sub - type dependent recovery cost to SubA, SubB, and SubC types. As a result, for all types T in G2, the dependent recovery costs DC[T][A]=[], DC[T][C]=[], DC[T][H]=[Cost(Machine:H)] are obtained.

[0260] Finally, describe the processing for G1.

[0261] G1 contains only one Target as a type, and this has two expected configurations. The tangible type-dependent recovery cost construction unit 201 calculates the temporary dependent recovery cost based on the recovery model of the Target type. As a result, TDC[A]=[], TDC[C]=[], TDC[H]=[{ S1:H},{ S1:H, S2:H}] is obtained.

[0262] The tangible type-dependent recovery cost construction unit 201 calculates the dependent recovery cost based on the calculated temporary dependent recovery cost. Since TDC[A] and TDC[C] are empty lists, the dependent recovery costs DC[Target][A] and DC[Target][C] for these are also empty. When converting the elements of TDC[H] to a list of dependent recovery costs DCList(H), it becomes [[Cost(SubA:H)],[Cost(SubB:H), Cost(SubC:H)]].

[0263] The tangible type-dependent recovery cost construction unit 201 adds the dependent recovery cost derived from the corresponding type to each dependent recovery cost included in DCList(H) based on the already calculated dependent recovery cost information. Specifically, for the dependent recovery cost [Cost(SubA:H)], the element of the dependent recovery cost DC[SubA][H]= [Cost(Machine:H)] required to transition SubA from F to H is added. Furthermore, for the dependent recovery costs [Cost(SubB:H),Cost(SubC:H)], the elements of the dependent recovery cost DC[SubB][H] = [Cost(Machine:H)] required to transition SubB from F to H and the dependent recovery cost DC[SubC][H] = [Cost(Machine:H)] required to transition SubC from F to H are added. As a result, DCList(H) = [[Cost(SubA:H), Cost(Machine:H)],[Cost(SubB:H), Cost(SubC:H), Cost(Machine:H)]] is obtained.

[0264] The tangible type-dependent recovery cost construction unit 201 inputs DCList(H) to the dependent recovery cost integration unit 204.

[0265] The Dependency Recovery Cost Integration Unit 204 integrates the input list of dependency recovery costs [[Cost(SubA:H),Cost(Machine:H)], [Cost(SubB:H), Cost(SubC:H), Cost(Machine:H)]] into one dependency recovery cost. Specifically, the Dependency Recovery Cost Integration Unit 204 outputs a dependency recovery cost [Cost(Machine:H), AbsCost(SubA,SubB,SubC:3)] that includes Cost(Machine:H) commonly included in [Cost(SubA:H), Cost(Machine:H)] and [Cost(SubB:H), Cost(SubC:H),Cost(Machine:H)], and the abstract unit recovery cost AbsCost(SubA,SubB,SubC:3) obtained by integrating Cost(SubA:H),Cost(SubB:H), Cost(SubC:H).

[0266] As a result, the Tangible Dependency Recovery Cost Construction Unit 201 returns the dependency recovery costs DC[Target][A]=[], DC[Target][C]=[], DC[Target][H]=[Cost(Machine:H),AbsCost(SubA,SubB,SubC:3)] of type Target.

[0267] Since G1 does not include types other than Target, the Dependency Recovery Cost Propagation Unit 203 does not perform processing on G1.

[0268] Since the processing for all groups has been completed above, the Dependency Recovery Cost Calculation Unit 102 outputs all the dependency recovery cost information DC calculated in the previous procedures as the calculation result for the input state element model EXPL.

[0269] The above is a specific operation example of the Dependency Recovery Cost Calculation Unit 102 of this embodiment.

[0270] (Operation of the Recovery Model Construction Unit 103) Next, the operation of the recovery model construction unit 103 of the present embodiment will be described. In the operation of the recovery model construction unit 103 of the embodiment, a "temporary state element model", which is a special state element model (recovery state transition system), is introduced. Different from the normal state element model, the temporary state element model has only two states, F and H, and only two transitions, F→H and H→F, and also has a "reception type list", which is a list of node types, as data.

[0271] FIG. 4 is a flowchart showing the overall operation of the recovery model construction unit 103 of the present embodiment.

[0272] The recovery model construction unit 103 receives the abstract configuration D as input (step S400).

[0273] The recovery model construction unit 103 acquires the global state model M of the abstract configuration D (step S401).

[0274] (Supplementary explanation) As described in the explanation of the concretization of the abstract configuration, it is assumed that the data of the global state model of the abstract configuration is associated with the abstract configuration.

[0275] The recovery model construction unit 103 executes the procedures from step S403 to step S409 for each node N included in the abstract configuration D (step S402).

[0276] The recovery model construction unit 103 executes the procedures from step S404 to step S408 for all types T such that the satisfaction flag of the node N is FALSE (step S403).

[0277] The recovery model construction unit 103 executes the procedures from step S405 to step S407 for each unit recovery cost included in the dependent recovery cost DC[T][H] of type T (step S404).

[0278] If the unit recovery cost selected in step S404 is the abstract unit recovery cost AbsCost(T(1),..., T(m):L), the recovery model construction unit 103 proceeds to step S406; if it is the specific unit recovery cost Cost(T:s), it proceeds to step S407 (step S405).

[0279] If the global state model M does not include a state element model capable of accepting the abstract unit recovery cost AbsCost(T(1),..., T(m):L), the recovery model construction unit 103 adds a temporary state element model U such that the acceptance list is "T(1),..., T(m)", the transition time cost from H to F is 0, and the transition time cost from F to H is L, and adds a dependency item "U:{H}" to the dependency of the transition C→H of the state element model corresponding to node N (step S406).

[0280] (Supplementary note) A state element model capable of accepting the abstract unit recovery cost AbsCost(T(1),..., T(m):L) refers to a state element model of any of the types T(1),..., T(m), or a temporary state element model that includes at least one of T(1),..., T(m) in the acceptance list.

[0281] If the global state model M does not include a state element model capable of bearing the specific unit recovery cost Cost(T:s), the recovery model construction unit 103 adds a state element model U of type T to the global state model M and adds a dependency item "U:{s}" to the dependency of the transition C→H of the state element model corresponding to node N (step S407).

[0282] (Supplementary note) A state element model capable of bearing the specific unit recovery cost Cost(T:s) refers to a state element model of type T, or a temporary state element model that includes type T in the acceptance list.

[0283] After the recovery model construction unit 103 executes the procedures from step S405 to step S407 for all the unit recovery costs included in the dependency recovery cost DC[T][H] of type T, it proceeds to step S409 (step S408).

[0284] After the recovery model construction unit 103 executes the procedures from step S404 to step S408 for all types T for which the satisfaction flag of node N is FALSE, it proceeds to step S410 (step S409).

[0285] After the recovery model construction unit 103 executes the procedures from step S403 to step S409 for each node N included in the abstract configuration D, it proceeds to step S411 (step S410).

[0286] The recovery model construction unit 103 outputs the global state model M (step S411).

[0287] The above is the description of the operation of the recovery model construction unit 103 of this embodiment.

[0288] Below, a specific example of the output of the recovery model construction unit 103 of this embodiment will be described with reference to the drawings. As the prerequisite dependency recovery cost, all the dependency recovery cost information DC calculated for the state element model EXPL shown as a specific example of the operation of the dependency recovery cost calculation unit 102 of this embodiment is used.

[0289] FIG. 30 shows the result obtained when an abstract configuration containing only one Target type node T1 is input to the recovery model construction unit 103 of this embodiment. Since the expected configuration is not applied to node T1, two state element models U1 and U2 are generated based on DC[Target][H]=[Cost(Machine:H), AbsCost(SubA, SubB, SubC:3)], and the dependency {U1:H, U2:H} is given to C → H of the recovery model of T1.

[0290] Figure 31 shows the result obtained when an abstract configuration including two nodes, a Target-type node T1 and a SubA-type node S1, is input to the recovery model construction unit 103 of the present embodiment. Since the expected configuration has not been applied to nodes T1 and S1, a state element model has been generated based on DC[Target][H]=[Cost(Machine:H),AbsCost(SubA, SubB, SubC:3)] and DC[SubA][H]=[Cost(Machine:H)]. However, unlike the global state model shown in Figure 30, the state element model has generated only U1, which corresponds to a state transition system of the Machine type. This is because the SubA-type node S1 can tolerate the unit recovery cost AbsCost(SubA,SubB, SubC:3).

[0291] The above is the description of a specific example of the output of the recovery model construction unit 103 of the present embodiment.

[0292] (Operation of the Recovery Time Requirement Verification Unit 104) Next, the operation of the recovery time requirement verification unit 104 of the present embodiment will be described. Figure 5 is a flowchart showing the overall operation of the recovery time requirement verification unit 104 of the present embodiment.

[0293] The recovery time requirement verification unit 104 receives, as input, the global state model M and the recovery time requirement RTO (step S500).

[0294] The recovery time requirement verification unit 104 acquires the node N for which the recovery time requirement is specified (step S501).

[0295] The recovery time requirement verification unit 104 acquires a list ErrorStates of all global states reachable by executing only the transition H→F (from the initial state of the global state model M) of each recovery state transition system (step S502).

[0296] The recovery time requirement verification unit 104 removes from ErrorStates all global states other than the global state in which "the state of node N is F" (step S503).

[0297] The recovery time requirement verification unit 104 obtains a list RecoveredStates of all global states in the global state of the global state model M that satisfy the RTO recovery criteria (step S504).

[0298] (Supplementary note) The meaning of "the global state NS satisfies the RTO recovery criteria" varies depending on the type of RTO. If the RTO is the primary recovery time requirement, it means that "the state of node N in NS is H". If the RTO is the complete recovery time requirement, it means that "the states of all state models related to node N included in NS match the initial states".

[0299] The recovery time requirement verification unit 104 initializes an integer value checking with the number of elements in ErrorStates (step S505).

[0300] The recovery time requirement verification unit 104 defines the list ClosedStates as [RS(1), RS(2),..., RS(m)] using RecoveredStates = RS(1), RS(2),..., RS(m) (step S506).

[0301] The recovery time requirement verification unit 104 defines the list OpenStates as [(RS(1), 0), (RS(2), 0),..., (RS(m), 0)] using RecoveredStates = RS(1), RS(2),..., RS(m) (step S507).

[0302] (Supplementary note) In the following description, the pairs included in OpenStates are called "exploration states". Also, the integer value paired with the global state is called the "transition time", which represents the shortest time required to transition from the paired global state to any state in RecoveredStates.

[0303] If the recovery time requirement verification unit 104 determines that OpenStates is an empty list, it proceeds to step S517; otherwise, it proceeds to step S509 (step S508).

[0304] The recovery time requirement verification unit 104 selects the search state (CS, time) with the smallest transition time value among the search states included in OpenStates, deletes it from OpenStates, and adds the global state CS to ClosedStates (step S509).

[0305] The recovery time requirement verification unit 104 executes the procedures from step S511 to step S515 for all global states NS that are not included in ClosedStates among the global states that can transition to the global state CS by state transition (step S510).

[0306] (Note) Note that in step S510, the global state NS is taken out as the global state that can transition to the global state CS, not the global state that can transition from the global state CS.

[0307] The recovery time requirement verification unit 104 compares time with the upper limit of the recovery time of RTO. If time is larger, it proceeds to step S517; otherwise, it proceeds to step S512 (step S511).

[0308] When the global state NS is included in ErrorStates, the recovery time requirement verification unit 104 decrements the value of checking by 1 and deletes NS from ErrorStates (step S512).

[0309] When checking becomes 0, the recovery time requirement verification unit 104 proceeds to step S518; otherwise, it proceeds to step S514 (step S513).

[0310] The recovery time requirement verification unit 104 sets the transition time cost of the state transition required to transition from the global state NS to the global state CS as Δtime, and defines time’: = time + Δtime (step S514).

[0311] The recovery time requirement verification unit 104 adds the search state (NS, time’) to OpenStates (step S515).

[0312] (Supplementary) When adding the search state (NS, time’) to OpenStates in step S515, if there is a state where “the global state is NS” and “the transition time is equal to or greater than time’”, it may be removed from OpenStates.

[0313] After the recovery time requirement verification unit 104 executes the procedures from step S511 to step S515 for all global states NS that can transition to the global state CS by state transition, it returns to step S508 (step S516).

[0314] The recovery time requirement verification unit 104 outputs FALSE and ends the operation (step S517).

[0315] The recovery time requirement verification unit 104 outputs TRUE and ends the operation (step S518).

[0316] The above is the description of the operation of the recovery time requirement verification unit 104 in this embodiment.

[0317] A specific example of the operation of the recovery time requirement verification unit 104 in this embodiment will be described with reference to the drawings. FIG. 28 is an image diagram of a state transition system consisting of global states and transitions between them. The circles correspond to global states, and the global states can transition along the arrows between them. For simplicity, how each global state is specifically represented is omitted, and for the simplicity of the following description, the transition time cost is unified to 1 for all transitions.

[0318] Also, FIG. 28 shows the “operable state” that meets the RTO recovery criteria and the “fault state” corresponding to ErrorStates obtained in steps S502 and S503.

[0319] The procedure after step S508 of the recovery time requirement verification unit 104 is, intuitively, a process that starts from the operable state, scans in the direction opposite to the arrow on the graph in FIG. 28, and determines the shortest transition time cost required to reach any recovery state from each major state. FIG. 29 shows the transition time costs required to reach any operable state from each major state, obtained by such a process, indicated at the nodes of FIG. 28.

[0320] Each case where the recovery time requirement verification unit 104 returns an output will be described with reference to FIGS. 28 and 29.

[0321] (Case 1: The case where checking becomes 0 in step S513) checking is initially initialized with the number of failure states, and decreases by 1 when a new failure state is selected in step S508 and the transition time is within the recovery time upper limit of RTO. For example, when the recovery time upper limit is 10 and FIG. 28 is used as input, checking is initialized to 4, and then, during the graph scan, at the timing when all failure states are found in the order of major state 2800 (transition time 5), major state 2803 (transition time 6), major state 2801 (transition time 7), major state 2802 (transition time 7), the value of checking just becomes 0. Thus, the fact that the value of checking has become 0 means that it has been confirmed that it is possible to reach the operable state from all failure states within the recovery time upper limit of RTO, and therefore it has been verified that RTO is satisfied.

[0322] (Case 2: The case where time exceeds the upper limit of RTO recovery time in step S511) This case is one where it is detected that the operable state cannot be reached within the upper limit of the RTO recovery time. For example, when the upper limit of the RTO recovery time is 5, this case applies when the global state 2803 or 2804 is selected in step S508. What this means is that "since checking is not 0, there is still a failure state that has not been reached" and "all the states to be reached hereafter have a 'transition time required to reach the operable state at the shortest' of 6 or more". This means that there is a failure state that cannot be recovered without taking a transition time of 6 or more, and it is certain that the RTO is violated.

[0323] (Case 3: The case where OpenStates is empty in step S508) This case applies when there is an unreachable failure state. Although there is no such failure state in Figure 29, for example, considering a model where the transition 2805 is impossible, the global state 2803 cannot be reached. In such a case, the procedure proceeds without applying to either Case 1 or Case 2, and eventually, after scanning all the states, it applies to Case 3. That is, Case 3 means the existence of a "non-recoverable" failure state, and it is certain that the RTO is violated.

[0324] The above is the description of a specific example of the operation of the recovery time requirement verification unit 104 of the present embodiment.

[0325] (Operation of the configuration concretization unit 101) Next, the operation of the configuration concretization unit 101 of the present embodiment for designing the ICT system will be described with reference to the drawings. The configuration concretization unit 101 of the present embodiment is basically the same as the configuration concretization procedure described in Patent Document 1, but is different in that it also receives the recovery time requirement as an input and includes a verification step for the recovery time requirement for the abstract configuration during concretization by the recovery model construction unit 103 and the recovery time requirement verification unit 104. It is assumed that before the process described in FIG. 3 below, the dependent recovery cost calculation unit 102 has already calculated all the dependent recovery cost information DC by the processes shown in FIGS. 6 to 10 described above.

[0326] Figure 3 is a flowchart showing the procedure by which the configuration specification unit 101 of the present embodiment derives the specific configuration of the system.

[0327] The configuration specification unit 101 receives, as input, the configuration requirements D_init expressed in the form of an abstract configuration and the list RTOs of recovery time requirements from the input / output device (step S300).

[0328] The configuration specification unit 101 initializes the search candidate list T with an empty list (step S301).

[0329] The configuration specification unit 101 initializes the searched configuration list V with an empty list (step S302).

[0330] The configuration specification unit 101 adds D_init to T and V (step S303).

[0331] If the search candidate list T contains an abstract configuration and does not contain a specific configuration, the configuration specification unit 101 proceeds to step S305; otherwise, it proceeds to step S314 (step S304).

[0332] The configuration specification unit 101 selects one abstract configuration D included in T (step S305).

[0333] The configuration specification unit 101 generates abstract configurations D_1, D_2, ..., D_N that are obtained by materializing the abstract configuration D selected in step S305 (step S306).

[0334] (Supplementary note) Here, as a specific method by which the configuration specification unit 101 of the present embodiment materializes an abstract configuration, for example, the method described in Non-Patent Document 1 can be used. However, in the present embodiment, the specific method of materialization is not limited to a specific technique.

[0335] (Supplement 2) However, the implementation of this embodiment shall satisfy the following properties (1) and (2). (The method described in Non-Patent Document 1 satisfies these.) (1) Once a node is generated, it is not deleted by implementation. (2) Once a specific edge is generated, it is not deleted by implementation.

[0336] The configuration implementation unit 101 executes the procedures from step S310 to step S312 for each abstract configuration D_i generated in the previous step (step S307).

[0337] If the exploration-completed configuration list V contains D_i, the configuration implementation unit 101 returns to step S307; if not, it proceeds to step S309 (step S308).

[0338] The configuration implementation unit 101 adds D_i to the exploration-completed configuration list V (step S309).

[0339] The configuration implementation unit 101 inputs the abstract configuration D_i to the recovery model construction unit 103 and obtains the global state model M as the output (step S310).

[0340] The configuration implementation unit 101 inputs all the recovery time requirements included in the RTOs and the global state model M to the recovery time requirement verification unit 104 and verifies the output. If even one FALSE is output, it returns to step S307. If TRUE is output in all cases, it proceeds to step S312 (step S311).

[0341] The configuration implementation unit 101 adds the abstract configuration D_i to T (step S312).

[0342] After the configuration implementation unit 101 executes the procedures from step S310 to step S312 for all the abstract configurations D_i generated in step S306, it returns to step S304 (step S313).

[0343] The configuration concretization unit 101 outputs the specific configuration D_out included in the search candidate list T to the input / output device as the result of the system configuration derivation device 100. If no specific configuration is included in the search candidate list T, a search failure is notified (step S314).

[0344] The above is the description of the operation of the configuration concretization unit 101.

[0345] (Effect) Based on the information of the component models used by the configuration concretization unit 101 of the present embodiment for the concretization of the abstract configuration, the dependency recovery cost calculation unit 102 estimates in advance the minimum operations required for the recovery of each component and their time costs.

[0346] Further, the recovery time requirement verification unit 104 of the present embodiment receives the abstract configuration and the recovery time requirement, estimates an approximate value of the recovery time for the abstract configuration during concretization based on the recovery cost information estimated by the dependency recovery cost calculation unit 102, and verifies that the abstract configuration satisfies the recovery time requirement.

[0347] Also, the configuration concretization unit 101 of the system configuration derivation device 100 of the present embodiment receives the configuration requirements and the recovery time requirements, performs a tree search on the tree structure with the abstract configuration as the node by repeatedly concretizing the configuration requirements, and also verifies the recovery time requirements for the abstract configurations generated in the process by the recovery time requirement verification unit 104, and finally outputs the configuration information of the ICT system that is completely concretized and satisfies the recovery time requirements by excluding the abstract configurations that do not satisfy the recovery time requirements.

[0348] Therefore, the system configuration derivation device 100 of the present embodiment can perform automatic design by repeatedly performing only the concretization operations that can satisfy the given recovery time requirements for the given functional requirements, so that it is possible to efficiently discover a specific configuration that satisfies both the given functional requirements and the recovery time requirements.

[0349] <Second Embodiment> Hereinafter, with reference to the drawings, the system configuration derivation device 1100 according to the second embodiment will be described.

[0350] (Configuration) FIG. 11 is a second block diagram showing a configuration example of the system configuration derivation device 1100. The system configuration derivation device 1100 includes a recovery time requirement verification unit 1101 instead of the recovery time requirement verification unit 104 of the system configuration derivation device 100, but the other components are exactly the same as those of the system configuration derivation device 100.

[0351] The input / output format of the recovery time requirement verification unit 1101 is the same as that of the recovery time requirement verification unit 104. However, as the "recovery time" used to determine whether the upper limit of the recovery time is violated, instead of the sum of the execution times of all state transitions included in the recovery procedure, the execution time when all state transitions included in the recovery procedure are executed in parallel to the maximum extent (hereinafter referred to as the "parallel execution time") is used, which is different.

[0352] Hereinafter, a specific example will be used to explain the "parallel execution time" of the recovery procedure.

[0353] FIG. 23 illustrates an example of a recovery procedure for recovering two applications A1 and A2 and the machines M1 and M2 that host them respectively in two ways (procedures 2300 and 2301). Both include 12 state transitions of "M1:F → A", "M2:F → A", "M1:A → C", "M2:A → C", "M1:C→ H", "M2:C → H", "A1:F → A", "A2:F → A", "A1:A → C", "A2:A → C", "A1:C → H", and "A2:C → H".

[0354] Procedure 2300 is a list of state transitions (hereinafter referred to as "recovery tasks") that need to be executed during recovery, arranged in the order of execution. By sequentially executing the tasks from the top, the system can be completely recovered. It can be said that in the recovery time requirement verification unit 104, it verifies whether the required time for such "sequential execution" satisfies the specified recovery time requirement.

[0355] On the one hand, the procedure 2301 shows, with arrows, the minimum "execution order" required between recovery tasks. Specifically, the order of "M1:F → A" → "M1:A → C" → "M1:C → H" → "A1:F → A" → "A1:A → C" → "A1:C → H" and "M2:F→ A" → "M2:A → C" → "M2:C → H" → "A2:F → A" → "A2:A → C" → "A2:C → H" is specified. A graph consisting of such recovery tasks and execution order is called a "recovery task model", and when task B can be executed after task A (task A → task B), it is said that task B depends on task A.

[0356] The above-mentioned "order required between recovery tasks" means that it is executable while satisfying dependencies on the corresponding state model. For example, order relationships such as "M1:F → A" → "M1:A → C" → "M1:C → H" and "A1:F → A" → "A1:A → C" → "A1:C→ H" are required because the path from F to H on the state model is F → A→ C → H. On the other hand, an order relationship such as "M1:C → H" → "A1:F → A" is required due to the dependency [{ M1:[H]}] defined in the transition F → A of A1.

[0357] The recovery task model can be executed in parallel as follows. That is, among the recovery tasks included in the recovery task model, if all dependent tasks have been executed, then execute the task.

[0358] Theoretically, procedure 2301 can complete execution in half the time of procedure 2300 by parallel execution.

[0359] As described above, the minimum time required when the recovery task model of the recovery procedure is executed in parallel is called the "parallel execution time". When considering an environment in which the system recovery is executed completely in parallel, it is also considered that the recovery time requirement should be based on the parallel execution time.

[0360] The above is the explanation of the "parallel execution time".

[0361] (Operation) The operation of the recovery time requirement verification unit 1101 of this embodiment will be described.

[0362] FIG. 12 is a flowchart showing the overall operation of the recovery time requirement verification unit 1101 in this embodiment. The operation of the recovery time requirement verification unit 1101 in this embodiment is almost the same as the operation of the recovery time requirement verification unit 104, and only the five steps indicated by the double lines in FIG. 12 are different. Specifically, step S1200 is executed instead of step S507, step S1201 is executed instead of step S509, step S1202 is executed instead of step S511, step S1203 is executed instead of step S514, and step S1204 is executed instead of step S515.

[0363] The recovery time requirement verification unit 1101 determines the list OpenStates as [(RS(1), φ), (RS(2), φ),..., (RS(m), φ)] using RecoveredStates = RS(1), RS(2),..., RS(m) (step S1200).

[0364] (Supplementary note) However, φ is an empty task model.

[0365] The recovery time requirement verification unit 1101 selects the search state (CS, TM) with the smallest value of the parallel execution time of the task model among the search states included in OpenStates, deletes it from OpenStates, and adds the global state CS to ClosedStates (step S1201).

[0366] The recovery time requirement verification unit 1101 compares the parallel execution time of TM with the upper limit of the recovery time of RTO, and if the parallel execution time of TM is larger, it proceeds to step S517, otherwise it proceeds to step S512 (step S1202).

[0367] The recovery time requirement verification unit 1101 adds the state transitions necessary for the transition from the global state NS to the global state CS to the task model TM, and constructs a task model TM' (step S1203).

[0368] The recovery time requirement verification unit 1101 adds the search states (NS, TM') to OpenStates, respectively (step S1204).

[0369] The above is the description of the operation of the recovery time requirement verification unit 1101 in this embodiment.

[0370] (Effect) Unlike the recovery time requirement verification unit 104, the recovery time requirement verification unit 1101 of this embodiment determines the establishment or non - establishment of the recovery time requirement based on the parallel execution time.

[0371] Therefore, the system configuration derivation device 1100 of this embodiment can output a specific configuration that satisfies both the given functional requirements and the recovery time requirements in an environment where the system's failure recovery operations are executed in parallel.

[0372] (Supplementary note) Note that the sum of the execution times of the recovery tasks is always equal to or longer than the parallel execution time. Therefore, the recovery time requirement becomes "stricter" compared to the case where the parallel execution time is used as a reference. That is, even the configurations that can be output by the system configuration derivation device 1100 of this embodiment may not be output by the system configuration derivation device 100 of Embodiment 1 as violating the recovery time requirements.

[0373] (Other embodiments) FIG. 32 is a third block diagram showing a configuration example of the system configuration derivation device. The system configuration derivation device 800 includes a dependent recovery cost calculation means 801, a recovery model construction means 802, a recovery time requirement verification means 803, and a configuration concretization means 804. An expected configuration is a peripheral structure necessary for the normal operation of system components. A recovery model is model data representing the relationship between the failure recovery operations of system components and the peripheral structures. A component model is model data for managing the expected configuration and the recovery model of various abstract or specific system components. An abstract configuration is a graph-like structure composed of nodes corresponding to components and edges indicating the relationships between components, which represents the configuration of a system containing undetermined parts. When concretization is a conversion of the graph structure for determining the undetermined parts of the abstract configuration based on the information of the expected configuration, the dependency recovery cost calculation means 801 takes the component model as input, and based on the information of the recovery model and the expected configuration defined along with the component model, calculates the recovery cost required for recovering the structure derived from the expected configuration of the entity having the component model as a type. The recovery model construction means 802 takes the abstract configuration and the recovery cost as input, and constructs a global state model indicating the operation model related to the failure recovery of the abstract configuration. The recovery time requirement verification means 803 takes the global state model and the recovery time requirement as input, and verifies whether the global state model satisfies the recovery time requirement. The configuration concretization means 804 takes the functional requirement and the recovery time requirement as input, generates the abstract configuration obtained by concretizing the functional requirement by a mechanism for gradually concretizing the abstract configuration as a candidate for a possible system configuration, inputs the generated abstract configuration to the means for constructing the global state model to obtain the global state model, and inputs the global state model and the recovery time requirement to the means for verifying to exclude the candidate that does not satisfy the recovery time requirement, thereby deriving a system configuration that simultaneously satisfies the functional requirement and the recovery time requirement.

[0374] Note that, a part of the system configuration derivation devices 100, 1100, and 800 in the above-described embodiments may be implemented by a computer. In that case, a program for realizing this function may be recorded on a computer-readable recording medium, and the program recorded on this recording medium may be read into a computer system and executed to realize it. Here, the "computer system" shall mean a computer system incorporated in the system configuration derivation devices 100, 1100, and 800, including hardware such as an OS (Operating System) and peripheral devices.

[0375] Also, the "computer-readable recording medium" means a flexible disk, a magneto-optical disk, a ROM, a portable medium such as a CD-ROM, and a storage device such as a hard disk incorporated in a computer system. Further, the "computer-readable recording medium" means something that holds a program dynamically for a short time, like a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line, and may also include something that holds a program for a certain time, like a volatile memory inside a computer system that serves as a server or a client in that case. Also, the above program may be for realizing a part of the aforementioned functions, or may be such that it can be realized in combination with a program already recorded in the computer system for realizing the aforementioned functions.

[0376] Also, a part or all of the system configuration derivation devices 100, 1100, and 800 in the above-described embodiments may be realized as an integrated circuit such as an LSI (Large Scale Integration). Each processing unit of the system configuration derivation devices 100, 1100, and 800 may be made into a processor individually, or a part or all of them may be integrated and made into a processor. Also, the method of integrating into an integrated circuit is not limited to LSI and may be realized by a dedicated circuit or a general-purpose processor. Also, when a technology for integrating into an integrated circuit that replaces LSI appears due to the progress of semiconductor technology, an integrated circuit using such technology may be used.

[0377] As described above, one embodiment of the present disclosure has been described in detail with reference to the drawings. However, the specific configuration is not limited to the above, and various design changes and the like can be made without departing from the gist of this disclosure. Also, one aspect of the present disclosure can be variously modified within the scope shown in the claims, and embodiments obtained by appropriately combining the technical means disclosed in different embodiments are also included in the technical scope of the present disclosure. Further, configurations in which elements described in the above embodiments and modification examples and having the same effects are replaced with each other are also included. And each embodiment can be appropriately combined with other embodiments.

[0378] Some or all of the above embodiments can be described as follows, but are not limited thereto. Note that the description of the supplementary note corresponding to the dependent claim for the system configuration derivation device can also be made dependent on the system configuration derivation method and the program.

[0379] (Supplementary Note 1) An expected configuration is a peripheral structure necessary for the normal operation of system components. A recovery model is model data representing the relationship between the failure recovery operation of system components and peripheral structures. A component model is model data that defines type-specific information including the expected configuration and the recovery model of various abstract or specific system components. An abstract configuration is represented by a graph-like structure composed of nodes corresponding to components and edges indicating the relationships between components, and includes uncertain parts. The combination of the nodes and edges is collectively referred to as an entity, and the type of the entity is called a type. When concretization is a graph structure transformation that determines the uncertain parts of the abstract configuration based on the information of the expected configuration, taking the component model as input, based on the recovery model and the information of the expected configuration defined along with the component model, a means for calculating the recovery cost for the recovery of the structure derived from the expected configuration of the entity having the type indicated by the component model, taking the abstract configuration and the recovery cost as input, a means for constructing a global state model indicating an operation model related to the failure recovery of the abstract configuration, taking the global state model and a recovery time requirement as input, a means for verifying whether the global state model meets the recovery time requirement, taking a functional requirement and the recovery time requirement as input, generating the abstract configuration that concretizes the functional requirement by a mechanism for gradually concretizing the abstract configuration as a candidate for a possible system configuration, inputting the generated abstract configuration to the constructing means to obtain the global state model, and inputting the global state model and the recovery time requirement to the verifying means to exclude the candidate that does not meet the recovery time requirement, thereby deriving a system configuration that simultaneously meets the functional requirement and the recovery time requirement, is a system configuration derivation device provided with such means.

[0380] (Appendix 2) The means for outputting the cost is the system configuration derivation device according to Supplementary Note 1, which extracts the components that are minimally required for the system components corresponding to the node type to operate normally from the information on the expected configuration and type inheritance relationship of each node type, and calculates the cost as a list of recovery operations for the peripheral components that are minimally required for the components to be recovered.

[0381] (Supplementary Note 3) The means for verification is the system configuration derivation device according to Supplementary Note 1 or Supplementary Note 2, which, based on the input global state model, enumerates the states in which the system can operate normally and the failure states in which a failure has occurred in the system, and then scans the global state model in the direction opposite to the state transition of the system starting from the operable state on the global state model, and verifies the input recovery time requirement by examining the length of the shortest procedure from each of the failure states to the operable state.

[0382] (Supplementary Note 4) An expected configuration is a peripheral structure necessary for a system component to operate normally. A recovery model is model data representing the relationship between a system component's fault recovery operation and the peripheral structure. A component model is model data that defines type-specific information including the expected configuration and the recovery model of various abstract or concrete system components. An abstract configuration is represented by a graph-like structure composed of nodes corresponding to components and edges indicating the relationships between components, and includes undetermined parts. The combination of the nodes and edges is collectively referred to as an entity, and the type of the entity is called a type. When concretization is a graph structure transformation that determines the undetermined parts of the abstract configuration based on the information of the expected configuration, taking the component model as input, calculating the recovery cost for recovering the structure derived from the expected configuration of the entity having the type indicated by the component model based on the recovery model and the information of the expected configuration defined in association with the component model, taking the functional requirements and the recovery time requirements as input, generating the abstract configuration that has been concretized with respect to the functional requirements as candidates for possible system configurations through a mechanism for gradually concretizing the abstract configuration, taking the generated abstract configuration and the recovery cost as input, constructing a global state model indicating an operation model related to the fault recovery of the abstract configuration, taking the global state model and the recovery time requirements as input, verifying whether the global state model satisfies the recovery time requirements, and excluding the candidates that do not satisfy the recovery time requirements, thereby deriving a system configuration that simultaneously satisfies the functional requirements and the recovery time requirements, which is a system configuration derivation method.

[0383] (Appendix 5) An expected configuration is a peripheral structure necessary for system components to operate normally. A recovery model is model data representing the relationship between the failure recovery operations of system components and the peripheral structures. A component model is model data that defines type-specific information including the expected configuration and the recovery model of various system components, whether abstract or concrete. An abstract configuration is represented by a graph-like structure composed of nodes corresponding to components and edges indicating the relationships between components, and includes uncertain parts. The combination of the nodes and the edges is collectively referred to as an entity, and the type of the entity is called a type. When concretization is a conversion of the graph structure that determines the uncertain parts of the abstract configuration based on the information of the expected configuration, taking the component model as an input, calculating the recovery cost for the recovery of the structure derived from the expected configuration of the entity having the type indicated by the component model based on the recovery model and the information of the expected configuration defined in association with the component model, taking the functional requirements and the recovery time requirements as inputs, generating the abstract configuration that concretizes the functional requirements as candidates for possible system configurations through a mechanism that gradually concretizes the abstract configuration, taking the generated abstract configuration and the recovery cost as inputs, constructing a global state model indicating the operation model related to the failure recovery of the abstract configuration, taking the global state model and the recovery time requirements as inputs, verifying whether the global state model satisfies the recovery time requirements, and excluding the candidates that do not satisfy the recovery time requirements, thereby deriving a system configuration that simultaneously satisfies the functional requirements and the recovery time requirements, which is a program for causing a computer to execute the process.

Explanation of Signs

[0384] 100, 1100 ··· System Configuration Derivation Device 101 ··· Configuration Concretization Unit 102 ··· Dependent Recovery Cost Calculation Unit 103 ··· Recovery Model Construction Unit 104, 1101 ··· Recovery Time Requirement Verification Unit 200 ··· Dependent Recovery Cost Calculation Procedure Control Unit 201 ··· Tangible Type Dependent Recovery Cost Construction Unit 202···Intangible type-dependent recovery cost construction part 203···Dependent recovery cost propagation part 204···Dependent recovery cost integration part

Claims

1. An expected configuration is a peripheral structure necessary for a system component to operate normally, A recovery model is model data representing the relationship between the failure recovery operation of a system component and the peripheral structure, A component model is model data that defines type-specific information including the expected configuration and the recovery model of various abstract or specific system components, An abstract configuration represents the configuration of a system that includes uncertain parts by a graph-like structure composed of nodes corresponding to components and edges indicating the relationships between components, Those including the nodes and the edges are collectively referred to as entities, and the types of the entities are referred to as types, Concretization is a graph structure conversion that determines the uncertain parts of an abstract configuration based on the information of the expected configuration, Means for calculating a recovery cost for recovering the structure derived from the expected configuration of an entity having the type indicated by the component model, based on the component model as an input and the information of the recovery model and the expected configuration defined in association with the component model, Means for constructing a global state model indicating an operation model related to the failure recovery of the abstract configuration, with the abstract configuration and the recovery cost as inputs, Means for verifying whether the global state model satisfies the recovery time requirement, with the global state model and the recovery time requirement as inputs, Means for deriving a system configuration that simultaneously satisfies the functional requirement and the recovery time requirement. The means generates, as candidates for possible system configurations, the abstract configurations in which the functional requirements are concretized by a mechanism for gradually concretizing the abstract configuration with the functional requirement and the recovery time requirement as inputs, inputs the generated abstract configurations to the means for constructing to obtain the global state model, and inputs the global state model and the recovery time requirement to the means for verifying to exclude the candidates that do not satisfy the recovery time requirement. A system configuration derivation device comprising the above.

2. The means for outputting the recovery cost extracts the components minimally required for the system component corresponding to the node type to operate normally from the information of the expected configuration of each node type and the inheritance relationship of the types, and calculates the recovery cost as a list of recovery operations for the peripheral components minimally required for the components to recover. The system configuration derivation device according to Claim 1.

3. Based on the input large-scale state model, the means for verification enumerates the normal operating state of the system and the failure states where failures occur in the system, and then scans the large-scale state model in the direction opposite to the state transition of the system starting from the operable state on the large-scale state model, and verifies the input recovery time requirement by examining the length of the shortest procedure from each of the failure states to the operable state. The system configuration derivation device according to claim 1 or claim 2.

4. The expected configuration is the peripheral structure necessary for the system components to operate normally, The recovery model is model data representing the relationship between the failure recovery operation of system components and the peripheral structures, The component model is model data that defines type-specific information including the expected configuration and the recovery model of various abstract or specific system components, The abstract configuration represents the configuration of a system that includes undetermined parts by a graph-like structure composed of nodes corresponding to components and edges indicating the relationships between components, Those including the nodes and the edges are collectively referred to as entities, and the types of the entities are regarded as types, Concretization is a graph structure transformation that determines the undetermined parts of the abstract configuration based on the information of the expected configuration, Taking the component model as input, based on the recovery model and the information of the expected configuration defined along with the component model, calculate the recovery cost for the recovery of the structure derived from the expected configuration of the entity having the type indicated by the component model, Taking the functional requirements and the recovery time requirement as input, generate the abstract configuration that has been concretized for the functional requirements as candidates for possible system configurations through a mechanism that gradually concretizes the abstract configuration, Taking the generated abstract configuration and the recovery cost as input, construct a large-scale state model showing the operation model related to the failure recovery of the abstract configuration, Taking the large-scale state model and the recovery time requirement as input, verify whether the large-scale state model meets the recovery time requirement, By excluding the candidates that do not meet the recovery time requirement, derive a system configuration that simultaneously meets the functional requirements and the recovery time requirement. System configuration derivation method.

5. In a computer, The expected configuration is the peripheral structure necessary for the system components to operate normally, A recovery model is model data that represents the relationship between the failure recovery operations of system components and the surrounding structures, A component model is model data that defines type-specific information including the expected configuration of various system components, whether abstract or concrete, and the recovery model, An abstract configuration represents the configuration of a system that includes undetermined parts by means of a graph-like structure composed of nodes corresponding to components and edges indicating the relationships between components, Those including the nodes and the edges are collectively referred to as entities, and the types of the entities are referred to as types, Concretization is a conversion of the graph structure that determines the undetermined parts of the abstract configuration based on the information of the expected configuration, Taking the component model as input, calculating the recovery cost for recovering the structure derived from the expected configuration of the entity having the type indicated by the component model based on the recovery model and the information of the expected configuration defined in association with the component model, Taking the functional requirements and the recovery time requirements as input, generating, as candidates for possible system configurations, the abstract configurations in which the functional requirements are concretized by means of a mechanism for gradually concretizing the abstract configuration, Taking the generated abstract configuration and the recovery cost as input, constructing a global state model that represents the operation model regarding the failure recovery of the abstract configuration, Taking the global state model and the recovery time requirements as input, verifying whether the global state model satisfies the recovery time requirements, A process of deriving a system configuration that simultaneously satisfies the functional requirements and the recovery time requirements by excluding the candidates that do not satisfy the recovery time requirements, A program for executing the above.

Images