DE102013006949A1 - Method for ensuring the functionality of a technical system with regard to its configuration during installation or removal of components - Google Patents

Abstract

The invention relates to a computer-implemented method, a data carrier with data stored thereon or a signal sequence suitable for transmission over a data network and representing data to ensure the functionality of a technical system with regard to its configuration as part of an installation or removal of components of the technical system and a computer program with program code which carries out the method steps when the computer program is executed on a computer or a computer network. If components are to be installed or uninstalled in a technical system, a configuration machine determines the dependencies between all the components involved. The information obtained is transferred to a compatibility matrix. In order for the functionality of the overall system to be guaranteed, the analysis of the dependencies must show that the technical components in the intended configuration are compatible with one another and available. If this is the case, the configuration machine transfers the data in a suitable form to an installation / deinstallation machine, which analyzes the data in terms of the order in which installation or deinstallation steps have to be carried out in order to change from the actual to the target state reach. Based on this planning, the installation or deinstallation of the components can then be implemented.

Description

The invention relates to a computer-implemented method, a data carrier with data stored on it or a data sequence suitable for the transmission via a data network to ensure the functionality of a technical system with regard to its configuration in the context of installation or removal of components of the technical system and a computer program with program code which performs the method steps when the computer program is executed on a computer or a computer network.

When configuring technical systems and technical products, many dependencies between the individual components must be taken into account. In general, the components are compatible only in certain versions.

For the functionality of the technical system it is therefore crucial that only those technical components are used which are compatible with each other. To ensure this, the dependencies between compatible and incompatible components must be known and managed correctly. Furthermore, it must be considered which components are available in which version and at which time intervals.

For example, component A in version a requires component B in version b1 or b2, which in turn requires component C in version c in order to obtain a functional overall system in the interaction of A, B and C. There may be additional conditions such. Example, that the component A is not compatible with certain versions c, etc.

The management of these dependencies is a very complex task, which is hardly feasible without suitable tools.

In daily practice, these dependencies are managed by product managers and service providers. Often mistakes occur because, for. For example, a product manager may not be aware of certain technical dependencies.

These questions also play a role in computer systems, IT services and IT processes. An IT process is the fully installed, interconnected, and possibly activated environment, consisting of clients, servers, middleware components, databases, applications, and network components that an end user needs to complete a specific, IT-enabled business process.

For example, while the product manager of an IT process may know that a particular application A is running on Java, only the developer of the application knows that at least the JEE1.5 version is required for application A to be functional. In addition, for example, the patch level JEE1.5.2 must not be used because of an error.

Conversely, it is often unknown who a service manager for a technical component must inform about discontinuations of components. This leads again and again to ad hoc measures, through which the continued operation of a product must be saved.

Several attempts have already been made in the prior art to find ways of ensuring the compatibility of the technical components of a complex technical system.

The US Pat. No. 7,814,030 B2 describes a method and apparatus for managing corporate IT support data. Here, the data for the individual IT components are stored, maintained and evaluated in a central database. This information includes information about the specific versions of the IT applications, the enterprise IT architecture, the business processes, and the company's products.

The data is conventionally assigned directly to the individual IT applications by entering them into text fields, number fields and reference fields. Software agents can use this to read and process maps of the corporate architecture. In addition to the actual state, numerous variants of later desired states can be determined and visualized in an interactive form and compared with one another.

The DE 102 43 281 A1 describes a method and system for reducing complexity. Complexity reduction is achieved by classifying the elements of a system, hierarchically classifying the elements in a tree structure using attributes. The data is entered and maintained centrally and managed via version and variant management. About the classification and a given, unique attribution of attributes there is a compulsion to the clear and correct description of the elements.

This uniquely describes existing elements, allowing a structured overview of the existing or planned components, thereby limiting the complexity of the entire system.

The US Pat. No. 8,027,956 B1 deals with a system and method for scheduling or monitoring transitions in systems from one state to another. Here, too, the problem is recognized that conflicts in the availability of the subcomponents and the compatibility between the components can occur in a heterogeneous system. The solution found here consists essentially in that a transformation unit develops a multiplicity of data structures, wherein each data structure corresponds to a state of the system at a specific point in time of a possible transition scenario from the actual state to the desired state.

Disadvantages of the state of the art in all cited documents are that the assignment of the data results in a conventional manner in the form of direct attributes to the technical components. Although the evaluation of such data collections works in simple cases, only the direct dependencies play a role. However, in the multi-stage evaluation of dependencies, these tools quickly reach their limits, as the relationships can become confusing and so complicated that an evaluation becomes impossible.

Such a multi-stage dependency is given, for example, in an IT method if an application is dependent on the provision of a specific application server and a database system with certain types and possibly versions of these types, which in turn depends on the provision of frameworks which in turn depend on specific operating systems are. The operating systems may still have dependencies on the hardware or network components. If it is now necessary to evaluate which specific technical versions are compatible with each other at which point in time, the tools fail in the prior art, or the analysis becomes very complex, since there are a tremendous number of implementation possibilities, all of which must be checked.

The reason for this is that the data is not or is so little structured that structural relationships between the components are not or not sufficiently represented in the data structure. Such structural relationships must therefore be elaborately described and evaluated using tools such as additional attributes.

The DE 10 2010 007 967 A1 describes a method, a computer program product, and a computer-readable storage medium for automated management of an IT process with a complete environment of clients, servers, middleware components, applications, and network components that an end user needs to perform a specific IT-based business process.

Here, a structure tree is used to describe the topology of an IT process, with which it is possible to collect and manage all information required for the overall handling of an IT process in a defined structure, so that all relevant for the management of an IT process Collect operations from a data source and automate them.

The loop freedom of the structure tree is achieved by using an acyclically directed graph as the meta-structure.

The freedom from looping and the uniqueness of the elements create a structuring of the information contained in the IT process, which enables automated processing.

Each of the elements used in the structure tree is assigned a meta-element type in the meta-model. The meta-model describes which element types are allowed. The element types include all common generic IT components, such as server, middleware, storage, etc. Furthermore, it is determined which attributes are permitted and / or required for the element types and which relations with their associated attributes are permitted between the elements.

However, in this description of the element types of an IT method, the dependencies between any versions of the elements are not provided as to which combinations of the elements are compatible with each other so that they can be safely assembled into a functional IT system.

The object of the present invention is to provide a method with which it is possible to manage and evaluate the dependencies between the components of a technical system so efficiently that the functionality of the technical system with regard to its configuration in the context of an installation or removal components from planning to concrete implementation. It is also an object of the invention to provide a data carrier with data stored thereon or a signal sequence suitable for the transmission via a data network, with which it is possible to manage and evaluate the dependencies between the components of a technical system so efficiently in that the functionality of the technical system with regard to its configuration is ensured in the context of an installation or removal of components from planning to concrete implementation.

Furthermore, a computer program with program code is provided, which performs the method steps when the computer program is executed on a computer or a computer network. The program code can either be stored on a data carrier containing the method as a machine-readable and executable program or in a computer network such. As the Internet for client-server systems are provided, which are operated by means of the program.

Furthermore, a computer system is to be provided, which uses and executes the computer program.

These objects are achieved by the method according to the invention, a data carrier with data stored thereon or a signal sequence representing data suitable for transmission via a data network and a computer program with program code and a computer system according to the independent claims.

Advantageous developments are subject matters of the dependent claims.

The inventive method according to claim 1 describes a computer-implemented method for ensuring the functionality of a technical system with regard to a configuration of the technical system as part of an installation and / or removal of components of the technical system.

If components are to be installed or uninstalled in a technical system, the information is determined by a configuration automaton which dependencies exist between the components. These dependencies include, for example, compatibility and support dependencies of technical products, their variants and versions among themselves and with other products.

If technical components already exist, all dependencies between the technical components to be installed and the already existing components are recorded in the same way as the dependencies between the new components to be installed. If components are uninstalled, all dependencies between the components to be uninstalled and the remaining components are also captured. When both uninstalled and installed, all dependencies between the components to be uninstalled and those to be reinstalled are also captured.

The configuration automaton therefore has all the information at its disposal to be able to determine, by evaluating the ascertained and stored dependencies, which functional effects have the removal or addition of technical components to other components and thus to the overall system.

For the efficient use of the information about the dependencies between the components, the information is prepared accordingly by the configuration automaton.

For this purpose, the information obtained is converted at least into a compatibility matrix. In such a compatibility matrix, the data regarding the element type and element version of the interdependent and mutually compatible elements are strung together and ordered in a coherent manner. All possible combinations of compatible elements are considered. Due to the structuring of the data, it can be very efficiently determined from the structure tree which components in which versions are compatible with one another and thus ensure a functioning IT system. The compatibility matrix lists every conceivable combination of mutually compatible elements as a separate path. Different sequences of elements along a path are not considered as combinatorial possibilities.

The listing advantageously takes place in a hierarchical manner, so that an evaluation can not only be carried out by machine but is also very clear for a manual evaluation.

In order to ensure the functionality of the entire system, the analysis of the dependencies must show that the technical components in the intended configuration are compatible with each other and available. If this is the case, the configuration machine transfers the data in an appropriate form to an installation / de-installation machine, which analyzes the data in order of installation or deinstallation steps to be performed, from the actual to the desired state reach. The installer / uninstaller will then create a plan that contains the appropriate order of installation / uninstallation steps. Based on this planning, the installation or deinstallation of the components can then be implemented automatically.

If the configuration automaton recognizes in the evaluation of the dependency data that There are dependencies that are not met in the required manner, so that the predetermined range of functions is not achieved, the alarm system is issued by the configuration machine to the user of the technical system.

This alarm message lists the determined critical dependencies that prevent the specified range of functions from being reached. This can significantly improve the planning of installation / uninstallation measures. At the same time, it is guaranteed with a high degree of certainty that a planning evaluated as feasible by the configuration machine will actually bring about the desired success.

It is advantageous for the evaluation of the data if a systematics is already contained in the structure of the dependency data that can be used for the evaluation by the configuration automat to reduce the complexity.

According to the invention, the structure of the technical system is modeled in a structure tree. The structure tree starts with a so-called root element, under which all components of the technical system are arranged hierarchically as elements of the structure tree in a parent-child relationship. The formalism of the structure tree allows only unique and loop-free togological relationships between the elements by using an acyclic directed graph. An acyclically directed graph starts with a so-called root element, under which all elements are arranged in parent-child relationships. Kindelelemente arrange themselves under their respective parent elements. The child elements may themselves be parent elements of further child elements, but with the restriction that they may not have child elements, which in turn belong to their own parent elements. This structure prevents child elements from being assigned to a parent element, which in turn are already created as their parent element. This considerably reduces the complexity in the evaluation of the structure tree and prevents evaluation algorithms which analyze the data structure from getting stuck in data loops.

Due to the hierarchical tree structure in the acyclic graph and the resulting uniqueness of the elements, a structuring of the information contained in the IT process is created, which already contains so much information in its structure that an automated evaluation of the information requires considerably less effort than would be required in an analysis of any or only roughly structured data. This is possible only because the number of possible combinations of the technical components to be considered by the data structure chosen according to the invention is significantly reduced in comparison to the prior art.

Starting from the root element, the technical components are recorded hierarchically, whereby child elements are created by an abstract generic term of the technical component, which can be differentiated technically. In a parent-child line then the concrete implementation options, ie. H. captures the versions of the technical component that can be split arbitrarily. Children's children, d. H. Child elements of children of a parent element represent sub-versions of versions of the technical component.

An element description is only definable if an approved parent description has been made.

A further reduction in the complexity of the data in the evaluation by the configuration machine is advantageously achieved by also the allocation of direct dependencies using directed information structures.

For this, primary relations and secondary relations between parent and child elements are defined.

A primary relation is defined by the fact that a description of a child element can only be defined if an approved parent description of a parent element has taken place.

A child element can not be provided with a primary relation without an approved parent element exists.

Furthermore, deletion of a parent element concurrently deletes all child and child child elements of the parent element assigned to primary relations, unless secondary relationships refer to the elements.

Primary relations describe the child elements as versions of the technical components in relation to the parent elements as the overriding of the technical components.

Starting from the parent element that describes a specific technical component, the versions of this technical component are created as child and child child elements, etc., using the primary relations. For example, for the generic term "technical component X", there is a primary relation to the child elements "Version 1" and "Version 2", for example. from Element "Version 1", there may be a subversion 1.1 created as the primary child element under "Version 1". Another subversion 1.1.1 would therefore be created as the primary child element of "Version 1.1", while a "Version 1.2" would be created as a further primary child element to "Version 1".

Secondary relations are defined by the fact that they can only lead to child elements already created with a primary relation. Therefore, if a child element has not already been assigned to a parent element using at least one primary relation, it can not be assigned a secondary relation from any other element. Furthermore, child elements to which a secondary relation has been assigned can only be deleted if the secondary relation was previously deleted.

Secondary relations describe the dependencies with regard to the functionality of the technical components connected by them in their interaction with each other. These dependencies represent the technical prerequisites that must be met for a technical component to function. They therefore always lead from a technical component to lower-lying architectural layers. This directionality of the information has an important influence on the complexity reduction of the evaluation algorithms.

Since elements to which a secondary relation refers can not be deleted, the data structure alone already ensures that prerequisites for operating a technical component can not be inadvertently removed. It is therefore not necessary to elaborately read out attributes of all other elements and to analyze whether they have entries regarding their unconditional necessity for the component to be removed.

Advantageous is an embodiment of the invention in which attributes can also be assigned to the elements and the primary and secondary relations. For example, elements that describe versions of technical components can receive information on their availability or validity in the form of attributes.

For example, attributes in the relations can be used to assign names to the relations.

Using the attributes, evaluation rules can be used to analyze the structure tree. Attributes in the relations thus create further possibilities for recognizing information on the basis of the structure, without having to carry out costly comparisons of countless components among one another.

A further advantageous embodiment of the invention uses further elements in the structure tree which describe realizable properties of a technical component. With their help, it becomes possible to define multiple AND / OR conditions in the dependencies between the components.

The additional property elements are created in so-called Metaareas. Metaareas are separate areas within the structure tree that describe different architectural levels of the complex technical system. In IT procedures, for example, architecture levels with regard to infrastructure, hardware, operating system, etc. are conceivable. In such a meta tree of the structure tree, an element describing the respective properties of the associated technical component is assigned as a child element of a component group representing the component by means of at least one primary relation. Here several properties can be combined into a property group. This is done by means of a parent element that represents the property group and that is linked to the respective properties via corresponding primary relations.

If certain properties or whole groups of properties are required as conditions to be fulfilled for the functioning of the technical component, this can be done with the help of secondary relations. The technical components that require the fulfillment of the properties are linked to the corresponding property elements in the structure tree via secondary relations.

In the evaluation of dependencies by the configuration machine, it is also advantageous if certain rules for reading the relations are defined. Thus, the number of secondary relations to be created can be reduced if a secondary relation pointing to a parent element which also has child elements is read so that the secondary relation also points to all child elements and child element elements of the parent element.

This means that the functionality of the technical component that gives rise to the secondary relation takes into account all the technical prerequisites that are described by the parent element and its subordinate child elements.

The interpretation of assignments of technical prerequisites via secondary relations is In principle, it should be understood that the dependencies between the secondary relations are read in the sense of a logical "or" conjunction if the target elements of the secondary relations have a common parent element, ie represent expressions of the same parent element. Accordingly, it is sufficient for the functional capability of the technical component if only one prerequisite of the elements to which the secondary relations refer is valid.

This also applies to the parented secondary relations on parent elements with child and child element elements.

If several secondary relations point from one element to other elements whose parent elements belong to different subareas of the structure tree, the dependencies between the secondary relations are read in the sense of a logical "and" link.

This means that the functionality of the technical component from which the secondary relations are based must meet all the technical requirements described by the elements connected by means of the secondary relations, if the elements belong to different subareas. Such subareas can be represented, for example, by different instance areas in the structure tree of an IT process. All elements of an instance area describe the same technical element in different forms, such as: For example, the instance area Linux, which describes different Linux versions.

Finally, another read-out rule should also be used to effectively read out the relations that are given their own names using attributes. If, starting from an element, several secondary relations with at least two different names point to elements, these should be interpreted individually as described above. In addition, the dependencies to be considered in each case between secondary relations of different names are to be read in the sense of a logical "or" link. For this, at least two differently named secondary relations must start from one element. This reading rule means that the secondary relations of different names emanating from the element do not have to be fulfilled simultaneously. It is sufficient if at least the technical requirements described by the elements connected by means of the secondary relations of a name are fulfilled for the technical component to function.

An embodiment of the invention in which the data structure and the readout rules are also applied to the availability of the versions of technical components is particularly advantageous.

The versions of a component are hierarchically recorded as child and child children elements of the component element.

As attributes, the data required for determining the validity periods (E) of the elements are entered. For this it is necessary to have at least one validity period with associated start and end time available for several, interdependent elements. It can now be automatically analyzed whether the generally different validity periods of the interdependent elements overlap. Only in the periods in which the validity periods overlap, the interdependent components are available simultaneously. The functionality of the system is thus available only in the desired period if the validity periods overlap at least in the desired period.

• • Beginn der Marktverfügbarkeit (Beginn externe Verfügbarkeit)
• • Start der Bereitstellung (Beginn interne Verfügbarkeit)
• • Ende Bereitstellung (Komponente nicht mehr neu bestellbar)
• • Ende Support (Ende der regulären Supportzeit)
• • Ende extended Support (Ende des erweiterten Supports mit speziellem Supportvertrag)

Advantageously, the following date values are used for each version:

• • Start of market availability (start of external availability)
• • Start of deployment (start internal availability)
• • End of provisioning (component can no longer be ordered)
• • End of Support (end of regular support time)
• • End extended support (end of extended support with a special support contract)

These times do not pay attention to the dependencies between the element and other components. For example, the manufacturer of a software may make the specification that its product is executable on a particular Java version, so that the availability of the product is dependent on the availability of a suitable Java version.

The effective validity period now derives from the required validity periods (E) of the product and Java, when the product is actually usable.

• • Der effektive Gültigkeitszeitraum, innerhalb dessen ein Element in wenigstens einer Version verfügbar ist, stellt die technische Bereitstellbarkeit an sich dar, ohne die Abhängigkeiten der Komponente von der Bereitstellung anderer Elemente zu betrachten und wird mit „LC” bezeichnet (Local Child).
• • Der effektive Gültigkeitszeitraum, innerhalb dessen die weiteren Komponenten verfügbar sind, von denen die Funktionsfähigkeit des Elements abhängig ist, wird „ED” bezeichnet (Effective Direct). Er berücksichtigt nicht die tatsächliche technische Bereitstellbarkeit des Elements, sondern berücksichtigt nur die vom Produktmanagement geplante Bereitstellbarkeit, mit Betrachtung der Abhängigkeiten zwischen den Elementen.
• • Die Verknüpfung von LC und ED wird mit „EC” bezeichnet (Effective Child). Sie stellt die tatsächliche Bereitstellbarkeit unter Beachtung aller Vorgaben des Produktmanagements und der technischen Bereitstellbarkeit dar.

There are 3 different effective validity periods:

• • The effective validity period within which an element is available in at least one version represents the technical deliverability per se, without considering the dependencies of the component on the provision of other elements, and is referred to as "LC" (Local Child).
• • The effective validity period, within which the other components are available, on which the functionality of the element depends, is called "ED" (Effective Direct). It does not take into account the actual technical availability of the item, but only considers the deliverability planned by the product management, considering the dependencies between the items.
• • The combination of LC and ED is called "EC" (Effective Child). It represents the actual availability in compliance with all requirements of product management and technical availability.

To calculate the LC validity period, the validity periods of the direct children and children's children of an element within an instance area are evaluated. The item is available as long as at least one of its versions is available.

To calculate the ED validity period, all dependencies of the versions of an element with other elements from other instance areas are evaluated. Thus it is determined, at which times an element can be meaningfully used, because also the elements are available, on which the element is dependent.

To calculate the EC validity period, the LC and ED validity periods are combined. Thus, it is determined at which times an element is not only available, but can also be used meaningfully, because also the elements are available, on which the element is dependent.

These validity periods can be recorded and displayed in the compatibility matrix. Thus, in particular for each path, the associated useful life of the path can be specified.

One possible embodiment of the invention extends to hardware and software products as a technical system, such. B. IT procedures, computer systems and IT services. Such systems consist of hardware and / or software as technical components, which are pronounced as different releases, versions of different compatibility with each other and different availability. Given the large number of different availabilities and dependencies of the components among each other, the functionality of the entire system can only be guaranteed if the overall structure of the system is recorded and the interdependencies are meaningfully evaluated.

Claim 13 describes a computer program with program code for performing method steps described above, when the computer program is executed on a computer or a computer network.

According to claim 14, a computer system is set up so that it carries out a computer program which fulfills the properties described above and thus ensures the functionality of a technical system in the context of an installation or removal of components of the technical system. To avoid repetition, reference is made here to the previous statements, which set out the characteristics of the computer-implemented method. The program data are stored on a data carrier or are represented by a signal sequence suitable for transmission via a data network.

The computer system is thus by using a data carrier or via a data network such. B. the Internet or a local network transmitted signal sequence in a state in which it performs the program as described above.

Commercially available single-user computers, such as PCs, as well as individually or possibly distributed cooperating servers (in data centers, etc.) are suitable as computer systems.

However, the invention is not limited only to use in such IT systems. Rather, it can be used in any complex technical system composed of numerous components that can be hierarchically related to each other, such as control and safety systems, machinery, vehicles, etc.

The invention will be explained in more detail below with reference to exemplary embodiments, which are illustrated by a plurality of figures.

The examples relate to the configuration of IT systems, but can easily be adapted directly to other technical areas.

Due to the high complexity of today's IT processes, it is no longer possible for a single system owner to know and maintain all relevant dependencies of the hardware and software components centrally.

The management of these dependencies is a very complex task, which is hardly feasible without suitable tools.

In daily practice, these dependencies are managed by product managers and service providers. Often mistakes occur because, for. For example, a product manager may not be aware of certain technical dependencies.

In a given IT process, hardware or software components must be constantly removed or added. In order to ensure the functionality of the entire system, it is therefore necessary to identify in advance which components are available and how they harmonize with the other components of the system.

For example, the application V1 is to be added to an existing IT system. This application requires a JBOSS version V5.1, V5.2 or V5.3.2 as application server. However, the application does not run on a JBOSS version 5.3.1. At the same time, the Linux application SLES 10 is absolutely necessary for the new application.

In addition, it will be investigated whether the currently installed on the system version V5.1 of JBOSS can be removed and replaced by a higher version.

The actual state of the topology of the IT system is depicted in this example in a suitable data structure, as described in the DE 10 2010 007 967 A1 is described.

In order to ensure the functionality of the IT system after installing the new application and uninstalling the old JBOSS version, a user computer is used on the basis of which a computer program is executed. The user computer is a commercial PC that is connected to the Internet, through which it receives the signal sequence.

An essential component of the computer program is a configuration automaton which determines the interdependencies from all the data relating to the components used in the system by means of the evaluation rules and the data structure of the structure tree.

These dependencies are displayed clearly in a compatibility matrix.

Using the compatibility matrix, the configuration engine can now analyze the effects of the planned changes on the topology of the IT system by also accessing the data from the topology description.

This means, on the one hand, that the configuration machine will check whether any existing component or application will be affected if JBOSS version V5.1 is removed. On the other hand, the configuration machine checks whether the prerequisites for installing the new application are met and which JBOSS version can be used.

To do this, the configuration automaton accesses the information from the topology of the IT system and determines where a JBOSS 5.1 exists. Using the compatibility matrix, the configuration engine analyzes that JBOSS version 5.3.2 is suitable for replacing JBOSS 5.1.

Since in our example the evaluation shows that the uninstallation of JBOSS version V5.1 does not adversely affect the functionality of the entire system and that the prerequisites for installing the new software are fulfilled by the existing components (Linux SLES10 and JBOSS V5.3.2) the configuration machine to the conclusion that both actions can be performed. He then plans the steps so that first the JBOSS version V5.1 is uninstalled from the system and then the new application is installed. If JBOSS version V5.3.2 were not available on the system, the configuration machine would detect that after removing the other two versions of JBOSS the application to be newly installed would not be able to run and would generate an alarm message to the system planner in which this conflict occurred is shown.

This procedure can also be used already in the planning phase of a new IT procedure.

Information retrieval is possible on simple systems using databases or spreadsheets. However, as soon as complex IT processes are in place, the number of interactions and dependencies to consider increases rapidly. The required computational effort can quickly exceed the limits of a data processing system. Depending on the complexity of the system or the preparation of the data structure, it may even be that an evaluation becomes impossible.

According to the invention, therefore, a data structure is used in which all data relevant for the management of the dependencies of the components are structured in such a way that an analysis of indirect dependencies can be carried out without great computational effort. As a result, the system resources of the data management can be significantly reduced, or an evaluation of the data in terms of functionality, ie the availability and the Compatibility of the components with each other in the first place.

For this purpose, the data is entered hierarchically in a structure tree. The data structure is based on an acyclically directed graph. The structure tree starts with a root element. All elements of the structure tree are now arranged hierarchically in parent-child relationships under the root element. The formalism of the data structure prevents child elements from being assigned to a parent element, which in turn are already created as their parent element. This is a prerequisite for being able to evaluate the data later. When going through the evaluation, it is impossible to get into endless loops. The enforced stringency of the hierarchy, in itself, already constitutes much of the information that can be efficiently extracted from the data. Relationships between data records already disclosed in this way by the structure do not have to be laboriously queried and compared with other data records, but can instead be read in a directional manner.

The collection of data can be decentralized, in the sense that each service provider and each product or component manager enters and manages the data on the components he is responsible for in the data structure. Thus, each component owner only has to record the known direct technical dependencies of his components. The component owner does not have to manage any indirect dependencies. For example, it manages the indication that an application depends on the provision of the application server JBOSS (possibly in version 3.5 and higher). However, he does not manage the information that JBOSS is compatible only with certain Java and operating system versions. This indirect information is provided in the specification tree by the component manager for JBOSS.

Furthermore, only two types of relationships between parent and child elements are allowed in the data structure. When the elements are created, a decision is made as to whether the parent-child relationship is a primary relation or a secondary relation. So, when a child element is newly added to the specification tree, it must be assigned to at least one parent element via a primary relation. Only then can the child element also be assigned to further parent elements via secondary relations. This means that secondary relations may only lead to elements already created in the structure tree. So if a child element has no primary relation, it is not possible to assign a secondary relation to it.

Versions of an element are represented as their child elements using primary relations. Sub versions of the versions are correspondingly assigned as child children elements using primary relations to a child element of the element.

Cross references between the areas define what dependencies exist between the elements. The dependencies are assigned using secondary relations.

The direction of the secondary relation always means that the element from which the secondary relation emanates requires the element to function, to which the secondary relation points. For better differentiation of primary and secondary relations in graphical representations, secondary relations are shown as curved directed compounds in the examples.

1 shows by way of example how the previously described dependencies between the application V1 to be newly installed, the Linux versions and the JBOSS versions are recorded hierarchically using the data structure according to the invention. Starting from the root element root, the different areas are assigned to the root element by primary relations; In this example we restrict ourselves to the description of the areas operating system (Linux), application server (Appserver) and the new application.

In the Linux section of the specification tree, SLES is assigned as a Linux-based operating system using a primary relation to the parent Linux element. The version SLES10 is assigned as version by means of a primary relation to the element SLES and thus results as a child child element of the Linux element.

In the application server area, JBOSS is assigned as the primary child element of the Appserver element. There are numerous subversions to the version V5 of the JBOSS considered here. Versions V5.1, V5.2 and V5.3 are all created directly under V5 as primary children. For version V5.3, there are still the minor versions V5.3.1 and V5.3.2, which are assigned accordingly as primary children of version V5.3.

The dependencies of the new application to be installed already described above are correspondingly represented as secondary relations. This directionality of the information makes it possible to evaluate the structure tree efficiently, since it maps the real structure of the system. The most basic level is the operating system on which the application servers are based, on which in turn the applications run. By the corresponding Subtrees that are arranged from left to right in this consecutive form, the technical structure of the system relevant for assessing the dependencies is considered so efficiently in the data structure that the analysis effort is significantly reduced. The subtrees, within which a technical element is described in different versions, are also called instance areas.

The following rules are used for evaluating the data structure and thus for detecting the dependencies between the elements:
Secondary relations from any parent to multiple members that belong to the same instance area are interpreted as alternatives to each other. Ie. these conditions expressed by the secondary relations are evaluated with an OR condition to each other. In 1 this means that the application V1, which assigns secondary relations to the JBOSS versions JBOSS V5.1, V5.2, V5.3.2 in the AppServer instance area, only JBOSS V5.1 or JBOSS V5.2 or JBOSS V5.3.2 needed to be able to run.

Secondary relations from any parent to elements in different instance aras are each interpreted as additive conditions. Ie. these conditions expressed by the secondary relations are evaluated with an AND condition to each other. In 1 this means that the application V1, which assigns secondary relations to the JBOSS versions of the JBOSS instance area and to SLES10 of the Linux instance area, also requires both elements. The application thus only runs if one of the assigned JBOSS and simultaneously also SLES10 is available for the application V1.

The restrictions on deleting the relations prevent, without further great effort, the deletion of elements that are needed by other elements for their functionality.

In this example, versions V5.1 and V5.2 of the JBOSS could be deleted as desired, as long as JBOSS V5.3.2 is present. The element SLES10 could not be uninstalled without first deleting the secondary relation to the application V1. But that would mean that the application V1 would no longer be able to run, which is why an alarm message would be output immediately.

The configuration automaton now accesses all this information by evaluating the data structure according to the rules. With such simple structures, it would not even be necessary to include attributes of the elements in the evaluation.

Another example is to describe a somewhat more complicated data structure that also involves multiple dependencies and indirect dependencies. Here, it is exploited that attributes can also be assigned to the relations. The attributes are used to assign labels to the relations. For this case, further evaluation rules must be used.

All secondary relations with the same name are first evaluated with the previously described rules. Only in the next step, the results from these evaluations are then evaluated with each other in an OR condition.

In 2 the same dependencies are modeled for the two applications V1 and V2. For "My App V2", however, with the relation names A and B shown. If these dependencies are evaluated, in this example the app V1 can be installed in conjunction with a JBOSS 5.1 or JBOSS 5.2. The application must be installed on RHEL. The JBOSS can be installed in both version 5.1 and 5.2 either on SLES or on RHEL. In contrast to App V2. Here, it is first ensured via relations A that the provision can only be made if JBOSS 5.1 and RHEL are available at the same time. Relation B then describes that alternatively the provision can be made via JBOSS 5.2.

The next example shows a system where there are multiple AND / OR dependencies between the elements.

For this purpose one uses so-called property elements E *. Property elements are each defined within a region of the structure tree r. First, the abstract property is defined as the primary child in an area of the structure tree. Then this property can be referenced secondarily by technical elements T * of the region, as well as by all elements (T *, E *, F *, ...) to the right of the region, i. H. to be requested as the condition to be fulfilled. Several properties can be grouped into a property group (F *). The property groups are optional primary parents to the properties E * of an area. If a property group F * is referenced, this means that all the properties of a property group must be fulfilled. Properties can now be used to build more complex AND / OR conditions. For example, an application should be built either with JBOSS on Linux or with Weblogic on Solaris, although both application servers JBOSS and Weblogic are available on both operating systems.

3 shows the modeling for this case.

First, two properties are defined here: "JBOSS_und_Linux" and "Weblogic_und_Solaris". These two properties become the conditions, i. H. given the secondary relations to JBOSS, Weblogic, Linux and Solaris. About this then z. For example, the property "JBOSS_und_Linux" ensures the common condition that both JBOSS and Linux are available. Then the application "My App" will refer to it. Since the two formulated properties should be considered as alternatives, but belong to the same instancearea, the secondary relations of "My_App" to the two properties "JBOSS_und_Linux" and "Weblogic_und_Solaris" must be named differently. The designation with "A" and "B" ensures that the two relations are interpreted as an OR condition.

• • Beginn der Marktverfügbarkeit (Beginn externe Verfügbarkeit)
• • Start der Bereitstellung (Beginn interne Verfügbarkeit)
• • Ende Bereitstellung (Komponente nicht mehr neu bestellbar)
• • Ende Support (Ende der regulären Supportzeit)
• • Ende extended Support (Ende des erweiterten Supports mit speziellem Supportvertrag).

In another example, the availability of the system components is ensured by recording the validity periods as attributes for each element. The following data are required for this:

• • Start of market availability (start of external availability)
• • Start of deployment (start internal availability)
• • End of provisioning (component can no longer be ordered)
• • End of Support (end of regular support time)
• • End extended support (end of extended support with a special support contract).

These data are provided by the manufacturer, supplier, product manager or component manager.

Where the data exists, it is assigned as attributes to the corresponding elements.

To calculate the LC validity period, the validity periods of the direct children and children's children of an element within an instance area are evaluated. The item is available as long as at least one of its versions is available.

To calculate the ED validity period, all dependencies of the versions of an element with other elements from other instance areas are evaluated. Thus it is determined, at which times an element can be meaningfully used, because also the elements are available, on which the element is dependent.

To calculate the EC validity period, the LC and ED validity periods are combined. Thus, it is determined at which times an element is not only available, but can also be used meaningfully, because also the elements are available, on which the element is dependent.

In 4 is shown as an example of the structure tree of an IT system whose different versions of the operating system (SUSE Linux) and the application server based thereon (JBOSS) are stored in the attributes of the elements.

5 shows how this information can be used to determine the actual availability EC.

The effective-child validity of the JBOSS element (timeline with the number 12 in 5 ) results on the one hand from the period in which at least one of the children JBOSS 7.0 or JBOSS 7.1 (paragraphs 2 and 3) is available and on the other hand by the fact that the product Suse Linux is technically available. This in turn is available as long as at least one of his children SLES 10 or SLES 11 (paragraphs 8 and 7) is available.

The configuration automaton uses the evaluation rules and the data structure of the structure tree to determine these validity periods, so that it is always possible to detect whether or not a technical system is feasible and functional in the desired form.

The in 5 JBOSS 7's LC validity period, marked 4, begins with the beginning of the timeline shown in 1 above and ends with the end of the timeline shown in 3, which limits the presence of the latest child element. The ED validity period of JBOSS 7 (Section 5) takes into account the dependency of the JBOSS on Suse Linux. It therefore begins with the required provision of Suse Linux (beginning point 6) and ends with the required provision of JBOSS (end point 1). The technical usability of Suse Linux is determined by the LC validity period (point 9), which begins with the beginning of the timeline at 8 and ends at the end of the timeline with 7. Since there are no other dependencies for Suse Linux, the associated ED validity period (number 10) is identical to the time bar with number 6. The EC period for Suse Linux (paragraph 11) therefore starts with the time bar with digit 8 and ends with the time bar with figure 7.

When planning the system or installing or uninstalling individual technical components of the system, all relevant relationships, dependencies and deployment periods can be determined and explained become. Whole systems or their changes can be planned with the help of the configuration machine and checked for their functionality. Furthermore, these data can be forwarded from the configuration machine to an installation / uninstallation machine which uninstalls or installs components in a suitable order, at any time ensuring the system's functionality.

In 6a An exemplary one-line structure compatibility matrix is shown.

It records for each element in a separate line of which element types and their respective element type versions it depends. This is done hierarchically, d. that is, starting from the element type and its version number in one direction of the row in the next column, the element type Eletype 1 is listed on which the element depends, then in the next column in the same row the version of the Eletype 1, Subsequently, the element type Eletyp 2 is listed, of which the element of the Eletype 1 in the specified version in turn depends, etc.

Starting from the end element of the dependency cascade, e.g. For example, if the element type JBOSS is in version number 5.3, all dependencies that occur along the path in a single line can be determined hierarchically. Here is an example that shows that JBOSS 5.3 depends on Eletypl Java version 1.5. Java 1.5 is again dependent on Eletyp2 Linux in the version SLES. The whole dependency row is uniquely assigned the compatibility ID 1.

In line 2 the compatibility ID 2 describes a further possibility of the realization of the element JBOSS 5.3, namely the existence of the elements Java 1.5 on Linux RHEL.

Since each element, which in some way depends on a number of other elements, is assigned its own line and thus its own compatibility ID, all dependencies of the components of the technical system can be recorded in a single matrix.

Any combinatorics between working, d. H. Compatible elements are listed in a separate path. Paths that differ only by a different order of the elements are not considered as their own combinatorial possibilities. The paths therefore always differ in at least one version of a component.

Technically, such a flat table can be created unattractive, since theoretically one can describe any number of dependencies in a row, ie. H. must be able to define any number of columns.

Therefore, in this example, the one-line records are placed in the 6b ) has been wrapped with 2 tables of 3 columns each.

In both tables, one column contains the compatibility ID, while the other two columns contain the item type or version number of the item.

Table A contains all the elements that depend on other elements, each with its compatibility ID, its element type, and its element version. Each element is listed in its own three-column line.

Table B contains in each row exactly one element with element type and its element version on which an element from table A depends. The Compatibility ID column lists the compatibility ID of the item from Table A that the item depends on. Using the compatibility IDs, all dependencies can now be recognized and evaluated in a hierarchical way. This can be done manually or automatically.

7 FIG. 12 shows a schematic overview of an exemplary use of the invention in conjunction with a suitable and machine-evaluable modeling of the topology of the IT system, which is listed in the upper part of the figure.

The master data represented by the computer-implemented method according to the invention, or a data carrier with data stored thereon, or a signal sequence which is suitable for transmission via a data network to ensure the functionality of a technical system, describe the availabilities and dependencies of technical components and products. From this, the effective validity periods (LC, EC, ED) are determined, and a compatibility matrix is created, which contains all the complete compatibility paths, that is, the information about which versions match in which time period.

The master data, along with the technical description of the topology of the IT system, is used by the configuration machine to analyze, properly plan, and automate and / or manually perform the installation and uninstallation operations of software components of the IT system.

Beginning with the technical modeling of the description of the order, the quality assurance and validation will check whether the order is feasible. The configuration machine creates the master data and analyzes the data available from the topology description to determine whether, in which time frame and with which components the order can be realized. After selecting the concrete implementation, the appropriate installation / de-installation order of the components to be changed is determined in conjunction with the topology data. Then the corresponding work tasks are created. The work tasks are now carried out automatically, semi-automatically or manually, so that ultimately the IT system is realized in the desired form.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• US 7814030 B2 [0011]
• DE 10243281 A1 [0013]
• US8027956 B1 [0015]
• DE 102010007967 A1 [0019, 0093]

Claims (14)

Computer-implemented method for ensuring the functionality of a technical system with regard to a configuration of the technical system in the context of installation and / or removal of components of the technical system, characterized in that a. the information is determined by a configuration automaton, which dependencies exist between the components, wherein besides the possibly already existing components also the components to be removed and / or the components to be installed are taken into consideration, b. at least one compatibility matrix is created by the configuration automaton for the analysis of the ascertained information, wherein in the compatibility matrix the data relating to element type and element version of interdependent and compatible elements are strung together, whereby each combinatorial possible compilation of compatible elements is strung in a separate path, and this compatibility matrix is automatically and / or manually analyzed. A method for ensuring the functionality of a technical system according to at least one of the aforementioned claims, wherein the information determined by the configuration machine is analyzed and evaluated whether after a removal or installation of a component, the overall technical system will be available in a predetermined range of functions, and a. if the analysis of the determined information regarding the dependencies between the components shows that the predetermined range of functions is achieved, the deinstallation and / or installation steps are carried out automatically and / or manually taking into account the determined dependencies, b. if the analysis of the determined information regarding the dependencies between the components shows that the predetermined range of functions is not reached, the configuration machine issues an alarm message to the user of the technical system, listing the determined critical dependencies that prevent the predetermined Scope of functions is achieved. Method for ensuring the functionality of a technical system according to at least one of the aforementioned claims, wherein the data of the components to be removed and / or installed are transferred from the configuration machine to an installation / uninstalling machine from which the uninstalling and / or installation steps are carried out Considering the determined dependencies in a suitable order planned and if necessary carried out Method for ensuring the functionality of a technical system according to at least one of the preceding claims, wherein the configuration automaton determines the direct and indirect dependencies between all existing and planned components by modeling the structure of the technical system in a structure tree, the structure tree having a root element and all components of the technical system are hierarchically arranged as elements of the structure tree in a parent-child relationship under the root element, whereby only formal and loop-free togological relationships between the elements are allowed by the formalism of the structure tree by using an acyclic directed graph which starts at the root element and arranges all child elements under their respective parent elements, the child elements again being allowed to be parent elements only for those elements which are not themselves to the parent count elements of these child elements. Method for ensuring the functionality of a technical system according to at least one of the preceding claims, wherein a. Primary relations between parent and child elements are defined, wherein a description of a child element is definable only if an approved parent description of a parent element has occurred, and deleting a parent element at the same time deletes all child and child element elements of the parent element, with versions and minor versions of technical components as primary child and child child elements in relation to the parent elements are described hierarchically as the topical terms of the technical components, b. Secondary relationships between parent and child elements are defined, which describe the dependencies with regard to the functionality of the technical components connected by the secondary relation in their interaction with each other, secondary relations may only lead to already created with a primary relation child elements, and child elements in a secondary relation only can then be deleted if the secondary relation was previously deleted. Method for ensuring the functionality of a technical system according to claim 3, wherein the elements and secondary relations attributes can be assigned. Method for ensuring the functionality of a technical system according to at least one of the preceding claims, wherein describe further elements in the structure tree the realizable properties of a technical component, where a. first assigning an element describing the properties within the structure tree as a child element of an element group representing the associated technical component by means of at least one primary relation, b. from elements representing the technical components, refer to the associated elements by means of secondary relations, which describe the properties when these properties are required as a condition to be fulfilled for the functioning of the technical component, c. You can group multiple properties into one property group by using a parent element connected to a property using a primary relation. Method for ensuring the functionality of a technical system according to at least one of the aforementioned claims, wherein the technical dependencies contained in the structure tree are interpreted by a configuration automaton in such a way that a. If a secondary relation points to a parent element, the secondary relation is also read pointing to all child elements and child element elements of the parent element, b. If, starting from one element, several secondary relations point to other elements which have a common parent element in a common subarea of the structure tree, the dependencies between the secondary relations are read in the sense of a logical "or" link, c. If, starting from one element, several secondary relations point to other elements whose parent elements belong to different subareas of the structure tree, the dependencies between the secondary relations are read in the sense of a logical "and" -link, d. If, starting from an element, several secondary relations with at least two different names point to elements, in addition to the logical connections mentioned under a) to c) the dependencies to be considered in each case between secondary relations of different names are read in the sense of a logical "or" link. A method for ensuring the functionality of a technical system according to at least one of the preceding claims, wherein the availability of the system components is ensured by at least one validity period is detected for each element with start and end time as an attribute, and it is analyzed whether the validity periods of interdependent Elements overlap at least so far that the elements required for a desired function are available within the intended period of use. A method for ensuring the functionality of a technical system according to claim 10, wherein the availability of the system components is ensured by the following validity periods are recorded as attributes for each element: • Start of market availability (start of external availability) • Start of deployment (start internal availability) • End of provisioning (component can no longer be ordered) • End of Support (end of regular support time) • End extended support (end of extended support with a special support contract) and these validity periods are analyzed by the configuration automaton determining in which period of time LC an element is available in at least one version, in which period ED the further components planned are available on which the functionality of the element depends, and then the period EC in which both at least one version of the element and at least one version of all dependent elements in a valid overall combinatorics are simultaneously available. Method for ensuring the functionality of a technical system according to at least one of the aforementioned claims, wherein the technical system is an IT method and / or a computer system and / or an IT service, wherein the technical components consist of hardware and / or software , which are pronounced as different releases, versions of different compatibility with each other and different availability. Data carrier with data stored thereon or signal sequence representative of the transmission over a data network, the data being a program for ensuring the functioning of a technical system with regard to a configuration of the technical system in the context of installation and / or removal of components of the technical System, characterized in that the program is designed so that a. the information is determined by a configuration automaton, which dependencies exist between the components, wherein besides the possibly already existing components also the components to be removed and / or the components to be installed are taken into consideration, b. from the configuration machine the determined information is analyzed and evaluated, whether after a removal or installation of a component, the overall technical system in a given range of functions will be available. Computer program with program code for carrying out all method steps according to at least one of claims 1 to 12, when the computer program is executed on a computer or a computer network. Computer system for ensuring the functionality of a technical system with regard to a configuration of the technical system in the context of installation and / or removal of components of the technical system, characterized in that the computer system is set up so that it has a data carrier with stored data or a used for the transmission over a data network, suitable signal representing data sequence, wherein the data represent a computer program with program code according to claim 13, and the computer system executes the computer program.

Images