System and method for compensating for failures of components

Abstract

The invention relates to a system (S) for compensating for failures of components (A, B, C, D), the system (S) comprising a plurality of components (A, B, C, D), each of the plurality of components (A, B, C, D) being designed to perform at least one task, and the components (A, B, C, D) also being designed to exchange messages (E, E1, E2, E3) with one another in order to perform tasks that form part of a process. The system (S) also comprises: a monitoring unit (UE) which is designed to monitor the exchange of messages (E, E1, E2, E3) between the plurality of components (A, B, C, D) for executing processes; and a compensation unit (KE) which is designed to create a process model of the system (S) based on the exchange of messages (E, E1, E2, E3), to detect a failure of a component (A, B, C, D) during execution of a process, and, based on the failure of the component (A, B, C, D), to inform one or more other components (A, B, C, D) of the system (S) that are involved in the same process about the failed component (A, B, C, D) in order to compensate for the failure of the component (A, B, C, D).

Description

[0001] 202414040 Foreign version

[0002] 1

[0003] Description

[0004] System and method for compensating for component failures

[0005] The present invention relates to a system for compensating for component failures. Furthermore, the present invention relates to a method for compensating for component failures. Finally, the present invention relates to a computer program product that, on a program-controlled device, initiates the execution of the method for compensating for component failures.

[0006] A distributed computer system can comprise a number of components, each implementing specific functionality and performing corresponding tasks. If the distributed computer system is an event-based system, the components communicate with each other by exchanging events. An event is a special type of message that has a specific type, a unique ID, and some application-specific payload. The component that creates and sends the event is also called the event creator or event sender, while the component that receives the event is also called the event consumer or event receiver. An event messaging system transmits messages or events between sending and receiving components.

[0007] Such event-based systems enable the execution of complex processes or workflows. Each component of the workflow is triggered by an event, then performs a specific task, and finally sends another event or message once the task is complete.

[0008] However, workflows in event-driven systems are often defined implicitly. In other words, no workflow model is created in advance. Instead, each component has a very limited local view and only knows which events it receives and which other events it sends in response to a received event and the completion of the associated task.

[0009] Since existing systems lack a central coordinator and workflows are only implicitly defined, failing components can lead to incomplete workflows that become permanently stuck. In such situations, it is unclear which tasks need to be compensated for in which components and how the 202414040 foreign version

[0010] 2

[0011] The initiator of the workflow, for example, the initial component or a user, should be notified of the faulty result. To ensure a secure or at least transparent process, it is necessary to inform the initiator of the failure as quickly as possible.

[0012] Against this background, one object of the present invention is to provide a way to increase the response time of event-based workflows in the event of failures, so that users or dependent systems can resume normal operation as quickly as possible after failures occur.

[0013] Accordingly, a system for compensating for component failures is proposed, wherein the system has several components, each of which is trained to perform at least one task, and wherein the components are further trained to exchange messages with other components in order to perform the respective tasks, each of which is part of a process.

[0014] The system in question is, in particular, a distributed computing system, such as a cloud system or a software system with distributed containers, comprising multiple components or nodes. These components can perform individual tasks, which interact to form a workflow or process. As explained above, the components can exchange messages or events to execute their respective tasks.

[0015] In order to be able to react to the failure of a component, in contrast to previous systems, even if the workflows or processes are only implicitly known, the system proposed here provides for the creation of a process model based on the communication between the components, and for compensating for the failure of a component using the process model.

[0016] For this purpose, the system comprises a monitoring unit and a compensation unit. The respective unit, for example, the monitoring unit, can be implemented in hardware and / or software. In a hardware implementation, the respective unit can be a device or part of a device, for example, a computer, a microprocessor, or a control unit on a server, a host system, or similar. In a software implementation, the respective unit can be [202414040 Foreign Version]

[0017] 3

[0018] A computer program product can be designed as a function, a routine, part of program code, or an executable object.

[0019] The monitoring unit is designed to monitor the exchange of messages between the various components of the system for the execution of processes. For this purpose, the monitoring unit can, for example, be interposed in the communication paths between the components. It is also possible for all messages exchanged between components to be transmitted to the monitoring unit.

[0020] The compensation unit is then trained to create a process model of the system based on the exchange of messages, to detect a component failure during the execution of a process, and, based on the component failure, to inform one or more other components of the system involved in the same process about the failed component in order to compensate for the failure. In this context, compensation can be understood as either the use of other components to process the process, taking over the tasks of the failed component, or the notification of other components or an initiator about the component failure so that appropriate steps can be taken.In any case, the compensation unit is able to detect a component failure and, based on the created process model, initiate compensation for the failure of a component, even for implicit processes whose steps are not predetermined.

[0021] The system therefore solves two sub-problems:

[0022] 1. Unknown, implicit processes are transformed into explicit processes by creating the process model. In this way, possible task execution sequences of the components can be derived, even if these are not explicitly known at the beginning of the system's operation.

[0023] 2. Based on the derived process models, component failures can be detected during system runtime. The system can therefore react to the failure of a component in an active process, i.e., a process currently being executed by the components.

[0024] As explained above, the compensation unit is trained to create a process model or workflow model of the system. For this purpose, Process Mining (202414040 Foreign Version) can be used, for example.

[0025] 4 or similar methods can be used. These can detect events generated in the system and relate them to one another. The relationships between the different event types are then used to learn models of the system's underlying workflows, i.e., the sequences in which tasks and their components are invoked. This can be done offline, for example, based on log files, but can also be done online, i.e., in real time, by monitoring event data. In both scenarios, online and offline, the accuracy of the derived workflow or process models depends on the size of the log files or the number of events that have been collected and analyzed. This means that the more data is available and can be processed, the more accurate the process model created by the compensation unit.

[0026] Unlike previous systems, the compensation unit used here is now able, using the process model, not only to detect a component failure but also to compensate for it. In particular, the compensation unit is also capable of compensating for a complete component failure that is no longer able to perform its own error handling and compensation. This also safeguards against failures where components do not fail properly, i.e., are unable to send compensation events to the workflow or process themselves.

[0027] In a previously used approach, a central transaction coordinator treated a process as distributed transactions. Here, each component would only prepare the necessary changes for a process in an initial phase, and only when the central coordinator is aware of all successfully prepared tasks are the transactions released and the corresponding changes made permanent. However, this approach no longer works if the components perform interdependent tasks that are only executed if the preceding task has actually been completed and not merely prepared. In contrast, the compensation unit described here provides secure and reliable process monitoring and compensation in case of failures, even with interdependent component tasks.

[0028] According to one embodiment, the compensation unit is designed to detect when a message is not received by a sending component within a predefined period. 202414040 Foreign version

[0029] 5 is transmitted to a receiving component, and this is detected as a failure of the sending component. In this way, the compensation unit can easily detect a failure without any action required from the failed component itself. Only monitoring the timing of events is necessary. For example, if an event or message is sent from a first component to a second component, and this second component does not send another message to a third component within a predefined period, as specified in the process model, the compensation unit can interpret the absence of this further message as a failure of the third component.

[0030] Thus, the compensation unit can intercept and compensate for the complete failure of a component. In previous systems, it was possible to reverse any transaction with a compensating transaction. However, this required a failed local transaction to actively send a special compensation event, received by the previous task / component, to trigger the compensation transaction. If, however, a component in such a system fails completely and is unable to initiate compensation by issuing a compensation event, no compensation is possible. This problem is solved by the system proposed here, in which the compensation unit does not require active information from a failed component, as described above.

[0031] According to a further embodiment, the compensation unit is configured to inform the components upstream of the failed component in the process model of the component's failure when a failure is detected. In particular, the compensation unit is configured to cause the upstream components to reverse the corresponding process involving the failed component. To this end, the compensation unit can sequentially instruct the upstream components to undo their respective tasks. This can be done, in particular, using the process model in which the steps or the sequence of events / tasks are defined.

[0032] According to one embodiment, the monitoring unit is configured to determine and store the time of a message and the sending component. Furthermore, the monitoring unit can be configured to determine and store the receiving component for the message. In addition, 202414040 foreign version

[0033] 6. The monitoring unit must be configured to determine and store the message type. This information can be stored, for example, in a table. This provides a comprehensive overview of the messages sent by the components within the system, thus forming a comprehensive process model of the system.

[0034] According to another embodiment, the monitoring unit is configured to correlate messages from multiple components based on causality and to store a unique message identification number and a causality identification number for each message. The causality identification number indicates which message the message is correlated with due to a causality. A causality between messages indicates the causal relationship in which two messages occur. In particular, the causal relationship can also be a temporal one. For example, the monitoring unit can determine that when a message occurs, a specific other message always occurs next, and these two messages are therefore correlated. The causality identification number then indicates which other message a message is correlated with.This causal relationship allows the compensation unit to recognize which component must be active next, i.e., which component must output a message or event when a specific message occurs. If this message then fails to occur, the compensation unit can detect a failure of the corresponding component, as described above.

[0035] According to another embodiment, the monitoring unit is configured to detect the frequency of message occurrences within the exchanged messages and transmit this information to the compensation unit for the creation of the process model. The process model can thus also indicate the frequency, and therefore the probability, of a second message being sent to a specific component after a first message. These probabilities cover the possibility that, for example, a second message follows a first message to a first component, with a first probability of being sent to a second component and a second probability of being sent to a third component. The process model can therefore also represent that the same components are not always required sequentially, but that other sequences of components are possible within a workflow or process.202414040 Foreign version.

[0036] 7

[0037] According to another embodiment, the compensation unit is configured to consider messages over a predefined period in order to create the process model. In particular, the compensation unit can be configured to determine the period based on a selected prediction accuracy. If a more accurate prediction is required, the compensation unit can consider a longer period. In this way, small deviations in the message flow are not affected by the larger overall data volume. Furthermore, the compensation unit can disregard messages older than a predefined threshold. This allows older messages, which may be outdated due to system changes, for example, to be ignored when creating the process model.This makes the process model more reliable and the detection and compensation of failed components more accurate.

[0038] According to another aspect, a method for compensating for component failures in a system is proposed, wherein the system has multiple components, each of which performs at least one task, and wherein the components exchange messages with other components to execute their respective tasks, which are part of a process. The method comprises the following steps:

[0039] - Monitoring the exchange of messages between the multiple components for the execution of processes,

[0040] - Creating a process model based on the exchange of messages,

[0041] - Detecting a component failure during the execution of a process,

[0042] - Informing one or more other components of the system involved in the same process about the failed component based on the component failure, and

[0043] - Compensating for the component failure.

[0044] The embodiments and features described for the proposed system apply accordingly to the proposed method. Furthermore, it should be noted that the method steps can be carried out in the specified order, in a different order, or at least partially simultaneously.

[0045] Furthermore, a computer program product is proposed which, on a program-controlled device, initiates the execution of the procedure described above. 202414040 Foreign version

[0046] 8

[0047] A computer program product, such as a computer program tool, can be provided or delivered from a server on a network, for example, as a storage medium such as a memory card, USB stick, CD-ROM, DVD, or as a downloadable file. This can be done, for example, in a wireless communication network by transmitting the corresponding file containing the computer program product or tool.

[0048] Other possible implementations of the invention also include combinations of features or embodiments described previously or subsequently with regard to the exemplary embodiments, even if not explicitly mentioned. In such cases, the person skilled in the art will also add individual aspects as improvements or additions to the respective basic form of the invention.

[0049] Further advantageous embodiments and aspects of the invention are the subject of the dependent claims and the exemplary embodiments of the invention described below. The invention will be explained in more detail below with reference to preferred embodiments and the accompanying figures.

[0050] Fig. 1 shows a schematic block diagram of a system for compensating for component failures;

[0051] Fig. 2 shows a schematic flowchart of a method for compensating for component failures;

[0052] Fig. 3 shows a schematic diagram of a flow of messages in the system of Fig. 1;

[0053] Fig. 4 shows a model of message exchange in the system of Fig. 1; and

[0054] Fig. 5 shows a sequence of events with component failure for the system of Fig. 1.

[0055] In the figures, identical or functionally equivalent elements have been given the same reference symbols, unless otherwise indicated.

[0056] Fig. 1 shows a system S with several components A, B, C, D. System S can, for example, be a distributed computer system in which components A to D each perform tasks to execute different workflows. The tasks of the individual components A to D can interact and depend on each other, or run in parallel.

[0057] 9. For example, components A, B and C can execute a first workflow or process, and components A and D can execute a second workflow or process.

[0058] To perform their tasks, components A through D exchange messages, hereinafter also referred to as events E. This exchange of messages E takes place via an event messaging system (EMS). However, if one of the components, for example component C, fails, it was previously necessary for component C to issue a corresponding signal so that system S could detect and mitigate the failure. If component C fails completely and is no longer able to issue a corresponding signal, such a failure was not detected and mitigated in previous systems.

[0059] To ensure reliable compensation for component failures, the system S described here includes a monitoring unit (UE). This monitoring unit records when events or messages E are received by which component A to D. Based on this, a compensation unit (KE) determines a process model of the flow of messages or events E, E1-E3 between components A to D. For this purpose, the compensation unit (KE) can, for example, include an event analysis unit (EAU).

[0060] This Event Analysis Unit (EAU) can correlate messages or events E using causality information. This means that each event E has a system-wide unique ID and also carries a causality ID, i.e., the ID of the event E that caused the publication or execution of that event E.

[0061] In the process as carried out by system S, the exchange of messages or events E between the several components A to D is monitored in a first step S1 by the monitoring unit UE. Then, in step S2, the compensation unit KE creates the process model based on the exchange of messages E.

[0062] Based on the process model, the compensation unit KE can then detect a failure of component A to D during the execution of a process in step S3 and, in step S4, inform one or more other components A to D of the system S, which are involved in the same process, about the failed component. (In 202414040 Foreign version)

[0063] 10

[0064] In step S5, the failure of the component is finally compensated for, for example by reversing the process.

[0065] The S system is therefore based on the following units and parameters:

[0066] - Monitoring Unit UE: The Monitoring Unit UE collects statistics on the events E exchanged within the system S and aggregates them as they occur. The data collected by the Monitoring Unit UE can also be called tracking data and is gathered after a warm-up phase concerning events and their relationships within the system. The duration of this warm-up phase is a configurable parameter. Additionally, information about a single event occurring in the event-based system S can also be detected in real time by the Monitoring Unit UE.

[0067] - Compensation Unit KE: As explained above, the Compensation Unit KE creates an explicit workflow or process model based on the data from the Monitoring Unit UE. Furthermore, it monitors currently running workflow instances, detects failing components, and compensates for tasks in workflows affected by failing components.

[0068] - Event Analysis Unit (EAU): This can be part of the Compensation Unit (KE) and can represent logic within the Compensation Unit (KE) for building an explicit workflow model from the data of the Monitoring Unit (UE).

[0069] - Process Monitoring Unit (PUE): This can also be part of the Compensation Unit (KE) and represent logic within the Compensation Unit that tracks currently executed workflow instances to detect component failures, for example, based on timeouts or event timeouts. The Process Monitoring Unit (PUE) can also collect information from individual events from System S to detect, register, and monitor the status of new workflow instances.

[0070] - Event timeout: An event that was expected within a specific time period for a particular workflow instance, but did not occur.

[0071] - Process Compensation Unit PKSE: This can also be part of the Compensation Unit KE and represent logic within the Compensation Unit KE that sends compensation signals K(E1), K(E2) to system components A to D to call compensation tasks for specific workflow instances. In particular, it can determine from the monitoring state all predecessor tasks in the workflow that have already been executed and, based on this, generate the compensation signals K(E1), K(E2) and send them to the affected components. 202414040 Foreign Version

[0072] 11

[0073] - Compensation signal K(E1), K(E2): A special message sent by the process compensation unit PKE to a series of components A to D to compensate for the respective task executions in the context of a specific workflow instance.

[0074] The events mentioned above can be considered a triplet of<Ereignistyp, Ereignis-ID, Ursachen-ID> The event type a, ß, y, 8 is an identifier for the type of message, the event ID 1 to 5 is a system-wide unique ID for the event, and the cause ID 1, 2 is the ID of the event that caused component A to D to publish the corresponding event.

[0075] The following describes an example of a process, as shown in particular in Figures 3 to 5.

[0076] Component A completes its processing and sends the event with ID=2 of type=ß. Since A was previously triggered by the event with ID=1, the event with ID=2 is assigned clD=1.

[0077] - When the event with ID=2 is received by component B, this is reported to the monitoring unit UE, which records the time, the reporting component and the event itself.

[0078] - Component B then processes the event by performing the appropriate task.

[0079] - As a result of executing her task, B sends a new event with type=y, ID=5 and clD=2.

[0080] This process repeats for each event processed by any of the components A through D within system S. The communication flows between components A through D can be described based on these individual events. The start of a workflow or process (i.e., a sequence of events) is usually triggered by something outside of system S. These triggers do not have an ID that can be used as a cause ID, and therefore this field remains empty.

[0081] In the monitoring unit UE, events or messages can be stored in a table (see Table 1). Each row in this table represents an event that originates from event E.<cp, id,cid> together with its receiver and the timestamp of when it was received by the receiving component. This table itself represents the data of the monitoring unit UE, which is learned during a warm-up phase of the system S 202414040 foreign version and made available to the compensation unit KE via an interface. In addition, the monitoring unit UE also provides an interface for observing events in real time.

[0082] Table 1

[0083] To derive an explicit process model from this data, the compensation unit KE can execute the following algorithm:

[0084] - Mapping the above Table 1, TD, with the schema (timestamp, receiver / receiving component, event type, event ID, cause ID) into a Table 2, SR, (see below), which maps the sender-receiver, with the schema (sender, event type, receiver)

[0085] - For each event ID = i in TD: o Receives = TD[Event ID = i], Receiver o Event Type R = TD[Event ID = i], Event Type o Sender R = TD[Event ID = TD[Event ID = i], Cause ID] o Add new row (Sender R, Event Type R, Receiver R) to SR

[0086] - Constructing the explicit process model from sender-receiver table 2, see Fig. 4: o Let S be the set of distinct sending components in SR o Let R be the set of distinct receiving components in SR o V = S u R oee E = {s, r, f}, for

[0087] ■ s, event type, r) E SR, a series in SR

[0088] ■ f = \(s, event type, r) \ E SR, the frequency of a series in SR 202414040 Foreign version

[0089] As explained above, Fig. 3 shows components A to D of Fig. 1 with the logical communication taking place between them. Using the event triples and Table 1, the sequence in the communication process, along with its tracing, can be described. In the example shown in Fig. 3, the sequence is as follows:

[0090] (1) Component A completes its processing and releases an event of type ß. This event is assigned the system-wide unique ID 2. Since component A was previously triggered by the event E(a,1,-) with ID 1, the event is assigned the cause ID 1, thus generating E(ß, 2,1).

[0091] (2) When the event E(β, 2,1) is received by component B, this is reported to the monitoring unit UE. The monitoring unit UE records the time, the reporting component, and of course the event E(β, 2, 1) itself.

[0092] (3) Component B processes the event in a task (not shown further).

[0093] (4) As a result of the processing of component B, a new event is published. This event now has type y, ID 5, and cause ID 2 (since this was the event that triggered component B); therefore, E(y, 5, 2) is generated.

[0094] In another variant, component A can publish the event of type ö, which has the ID 3 and the cause ID 1, thus generating E(ö, 3, 1), which in turn is reported to component D.

[0095] This process is repeated for each event that is processed by any of the components A to D within the system S.

[0096] The start of a workflow (i.e., a sequence of events or messages) is usually triggered by something outside of system S. These triggers do not have an ID that can be used as a cause ID, and therefore this field remains empty (see the initial event in Fig. 3).

[0097] As described above with reference to Fig. 1, the compensation unit KE can process the communication data collected by the monitoring unit UE and create a process model, as shown, for example, in Fig. 4. For each event type a, ß, 202414040 foreign version

[0098] 14 y, 6 aggregates the compensation unit KE the frequency of occurrence of subsequent events together with the components A to D that receive them.

[0099] In the example shown in Fig. 4, the event E The event was published ten times. In seven cases, the event E<ß> was published and processed by component B. In three cases, the event E<ö> was published and processed by component D. In the seven cases where B processed the event E<ß>, the event E <y>The sequence is generated seven times and processed by component C. The dashed lines after components C and D indicate that the subsequent sequence is no longer considered in this case.

[0100] New instances of the process can be detected when an event is received by the monitoring unit UE and forwarded to the process monitoring unit PUE, which has no explicit sender (see event E1 e).<a,667, -> (in Fig. 5). For each new process instance, the Process Monitoring Unit (PUE) creates a process instance representation to track the current state of that process. The state comprises an ordered list of all triggered components along with the corresponding triggering event. After receiving event E2 with ID=667, the current state would correspond to a list containing element (A, 667) in the example. Similarly, upon receiving event E2 e<ß,809,667>, the cause ID = 667 is used to correlate with the correct process instance, and the internal state of the process instance is augmented by (B, 809) (see Fig. 5).

[0101] The detection of errors or failures of a component (in this example, component B) is explained below. In the example shown in Fig. 5, the current state of the process instance after receiving the event E2 e<ß,809,667> is {(A, 667), (B, 809)}. Whenever the state progresses, the process monitoring unit (PUE) starts a timer set to an adjustable parameter (e.g., 1 minute). If the timer expires and none of the events predicted by the process model have been observed (in this example, an event of type y according to the process model in Fig. 4, corresponding to the transition from B to C in Fig. 4), an error in the process execution for this specific instance in component B has been detected. The information about the component error, along with the accumulated state of the process instance, is then passed to the process compensation unit (PKSE).

[0102] The process compensation unit PKSE receives the state of the process instance and then sends compensation signals K(E1), K(E2) for each entry in the corresponding 202414040 foreign version.

[0103] 15

[0104] The state list is generated. In the example described in Fig. 5, the list would include entries (A, 667) and (B, 809). Consequently, the compensation signals K(E1) and K(E2) are generated and sent to components B and A, respectively. Components B and A revert the corresponding changes in their local system state, thereby reverting and compensating the entire workflow or process for the failed instance. Finally, to notify the user who originally triggered the workflow about the cancellation and reversal, component A can send a suitable notification via a user-defined channel.

[0105] Unlike previous systems, this approach also works in scenarios where the failed component is no longer able to trigger the compensatory measures itself because it is already completely offline. At the same time, the approach also supports implicit workflow execution without central orchestration, since the explicit workflow models are derived at runtime.

[0106] Although the present invention has been described using exemplary embodiments, it can be modified in many ways.

[0107] Regardless of the grammatical gender of a particular term, persons with male, female or other gender identities are included.< / y>

Claims

202414040 Foreign version 16 Patent claims 1. System (S) for compensating for failures of components (A, B, C, D), wherein the system (S) comprises several components (A, B, C, D), each of the several components (A, B, C, D) being configured to perform at least one task, wherein the components (A, B, C, D) are further configured to exchange messages (E, E1, E2, E3) with other components (A, B, C, D) in order to perform the respective tasks which are part of a process, wherein the system (S) further comprises: - a monitoring unit (UE) that is trained to monitor the exchange of messages (E, E1, E2, E3) between the multiple components (A, B, C, D) for the execution of processes, and - a compensation unit (CU) trained to create a process model of the system (S) based on the exchange of messages (E, E1, E2, E3), to detect a failure of a component (A, B, C, D) during the execution of a process, and, based on the failure of component (A, B, C, D), to inform one or more other components (A, B, C, D) of the system (S) involved in the same process about the failed component (A, B, C, D) in order to compensate for the failure of component (A, B, C, D).

2. System according to claim 1, characterized in that the compensation unit (KE) is configured to detect when a message (E, E1, E2, E3) is not transmitted from a sending component (A, B, C, D) to a receiving component (A, B, C, D) within a predefined period of time, and to detect this as a failure of the sending component (A, B, C, D).

3. System according to claim 1 or 2, characterized in that the compensation unit (CU) is configured to inform the components (A, B, C, D) that are upstream of the failed component (A, B, C, D) in the process model about the failure of component (A, B, C, D) in the event of a detected failure of component (A, B, C, D).

4. System according to claim 3, characterized in that the compensation unit (KE) is configured to cause the components (A, B, C, D) that are upstream of the failed component (A, B, C, D) in the process model to reverse the corresponding process that includes the failed component (A, B, C, D). 202414040 Foreign version 17 5. System according to one of the preceding claims, characterized in that the monitoring unit (UE) is configured to determine and store a time of a message (E, E1 , E2, E3) and the sending component (A, B, C, D) for a message (E, E1 , E2, E3).

6. System according to claim 5, characterized in that the monitoring unit (UE) is configured to determine and store the receiving component (A, B, C, D) for the message (E, E1 , E2, E3).

7. System according to claim 5 or 6, characterized in that the monitoring unit (UE) is configured to determine and store a message type of the message (E, E1 , E2, E3).

8. System according to one of the preceding claims, characterized in that the monitoring unit (UE) is configured to correlate messages (E, E1 , E2, E3) from several components (A, B, C, D) based on causalities and to store for a message (E, E1 , E2, E3) a unique identification number of the message (E, E1 , E2, E3) and a causality identification number, wherein the causality identification number indicates with which message (E, E1 , E2, E3) the message (E, E1 , E2, E3) is correlated due to a causality.

9. System according to one of the preceding claims, characterized in that the monitoring unit (UE) is configured to detect the frequency of occurrence of messages (E, E1, E2, E3) within the exchanged messages (E, E1, E2, E3) and to transmit this to the compensation unit (KE) for the creation of the process model.

10. System according to one of the preceding claims, characterized in that the compensation unit (KE) is configured to take into account the messages (E, E1 , E2, E3) over a predefined period in order to create the process model.

11. System according to claim 10, characterized in that the compensation unit (CU) is configured to determine the period based on a selected accuracy of the process model.

12. Method for compensating for failures of components (A, B, C, D) in a system (S), wherein the system (S) has several components (A, B, C, D), each of which 202414040 Foreign version 18 several components (A, B, C, D) perform at least one task, wherein the components (A, B, C, D) exchange messages (E, E1 , E2, E3) with other components (A, B, C, D) to perform the respective tasks which are part of a process, wherein the procedure comprises the steps: - Monitoring (S1) the exchange of messages (E, E1 , E2, E3) between the multiple components (A, B, C, D) for the execution of processes, - Creating (S2) a process model based on the exchange of messages (E, E1 , E2, E3), - Detecting (S3) a failure of a component (A, B, C, D) during the execution of a process, - Inform (S4) one or more other components (A, B, C, D) of the system (S) that are involved in the same process about the failed component (A, B, C, D) based on the failure of component (A, B, C, D), and - Compensating (S5) for the failure of component (A, B, C, D).

13. Method according to claim 12, characterized in that the functional features of the system are effected according to any one of claims 2 to 11.

14. Computer program product which causes the execution of the method according to claim 12 or 13 on a program-controlled device.

Images