WO2014180458A2

WO2014180458A2 - Computer-implemented, entity-related, time-based system status documentation

Info

Publication number: WO2014180458A2
Application number: PCT/DE2014/000216
Authority: WO
Inventors: André ALISCH; Andreas Keil; Simon HAGENBÄUMER
Original assignee: Arvato Systems Gmbh
Priority date: 2013-05-08
Filing date: 2014-04-24
Publication date: 2014-11-13
Also published as: WO2014180458A3; DE102013007891A1

Abstract

The invention relates to computer-implemented, entity-related, time-based system status documentation, which has - a computer-implemented method for assigning entity-relevant data statuses of a database (DB) to a time in an entity-related chronological sequence and storing said entity-relevant data statuses (7), and - an associated computer-implemented method for retrieving a current entity-relevant data status (7) from a memory (103), in which entity-relevant data statuses are stored using the above-mentioned method according to the present invention, by an entity (6, 18) at a retrieval time, and - a further associated computer-implemented method for retrieving historical entity-relevant data statuses from a memory (103), in which likewise entity-relevant data statuses are stored using the method according to the present invention mentioned at the start, from a documentation period in the entity-related historical chronological sequence of the entity-relevant data statuses for a specified documentation entity (6, 18).

Description

Title: Computer-implemented entity-related, time-based system state documentation

Applicant: arvato Systems GmbH, An der Autobahn 200, D - 33333 Gütersloh

The present invention relates to a computer-implemented entity-specific time-based system state documentation, wherein on the one hand a computer-implemented method for assignment of entity-relevant data states of a database at a time in an entity-related temporal sequence and storage and on the other hand, a computer-implemented Method for retrieving these data states, which have been previously stored by means of the first method for allocation and storage.

The automated system state documentation is known in the field of fault reporting and monitoring systems in many ways.

Thus, for example, industrial plants (eg core coffee plants), buildings (eg by access control systems, intrusion monitoring systems or even fire alarm systems) or complex machines (eg rolling stands, transport systems, elevators, high-bay warehouses), but also information processing systems (IT systems) including their software components, are developed by such systems monitored and their respective state - for example by fault displays, schematic plant overviews, alarm displays or warning and alarm messages - displayed. The purpose of such a monitoring mechanism independent of the system to be monitored is, in principle, to make the error monitoring as little as possible dependent on the errors occurring in the system to be monitored, since this could at least partially blind the monitoring system.

EP 2 407 917 A1 shows a system which, for example, serves to monitor IT systems, namely so-called ERP systems (enterprise resource planning systems) as a particular manifestation of IT systems, in which In particular, the systems of SAP AG are particularly well-known in this area

CONFIRMATION COPY Therefore, the EP 2 407 917 AI probably also referenced in particular. Systems such as that according to EP 2 407 917 A1 have as rules-based systems a reservoir of technical rules which can be configured as a rule by the user and which define control authorities related to the IT system. Such a control is technically realized, for example, as an SQL expression, a JAVA or ABAP program, or the like, and may preferably be provided with variables or parameters that determine how the control behaves in detail. The application of the rules is done, for example, by a so-called rule machine, which triggers the respective control to be carried out, for example, based on the occurrence of certain - preferably also configurable - conditions. In the case of EP 2 407 917 A1, events (events) which result from the system to be monitored (cf., for example, FIG. 7 of EP 2 407 917 A1, reference numerals 263 and 264) and to the monitoring system (cf. Reference number 271 in FIG. 7 of EP 2 407 917 A1) (see, for example, "transmit evenf in FIG. 7 of EP 2 407 917 A1) plays an important role as such conditions. However, this also implies a certain weakness of the system according to EP 2 407 917 AI: namely, it depends on the generation of such events in the system to be monitored itself and therefore is not functionally independent of this, which is problematic for a control and monitoring system, In this way it may even be undermined in this way by manipulative interventions in the system to be monitored by, for example, preventing or manipulating the triggering of an event, for example by utilizing bypass possibilities in the execution processes of the system to be monitored.

On the other hand, EP 0 645 684 A1, which relates to a method for monitoring material flow processes in production, attempts to avoid this problem by "the automatic error of the system communicating

passively tracked ¹ and based on such to some extent used as measurements of the monitored system system data for own independent of the system to be monitored analyzes used (see Sp. 1, Z. 40ff of EP 0 645 684 AI).

However, all known systems for (largely) independent monitoring of other systems have in common that they control point-related states of the respective system to be monitored. The monitored states are usually processed in a processing layer of the monitoring system and stored in a database. On Based on the data thus stored, these are then displayed for the user of the monitoring system. This display usually takes place in an application layer in which the system states previously stored in the database are either graphically processed, for example in the form of a traffic light or tachometer representations based on real instruments or also processed in tabular form. It is difficult here to transfer the transaction-oriented data streams from the monitored system into an abstracted view that is understandable for the user and at the same time copes with the usually very high data volumes owing to the transaction orientation with high complexity of the information processing for producing the aforementioned understandable abstract user view come.

Against this background, it is therefore not surprising, even from a technical point of view, if these systems offer only very limited possibilities for secure documentation of the monitoring process itself: Systems according to the state of the art at best record actions that are carried out in the monitoring system. For example, changes to values that a user makes are logged, such as changes to certain system states. There is also a documentation of the respective authentication methods (such as the login and logoff of users to the system by storing these processes, such as date, time and respective user ID).

A technically secure and complete user-oriented time-based documentation, which documents for a respective person in historical order, which of their relevant system states edited by her or even retrieved only from her from the database at what time, is due to the already shown here occurring mass of data and the complexity of their processing in monitoring systems according to the prior art. Rather, apart from the rather marginal exceptions already mentioned, these systems are limited to the monitoring, processing and presentation of the current status of the system being monitored, although it is of the utmost interest in the case of a surveillance system, including an exact one to receive temporal and user-oriented documentation of the processes on the monitoring system itself, so as to be able to accurately understand - which in a case of damage occurred - which user of the system which state messages took note and where appropriate, which state changes and notes he vorgenom when - has men. However, such documentation fails in the prior art in systems with large data movements, such as ERP systems already at the data volumes occurring here.

On the basis of this prior art, it is therefore an object of the present invention to provide a method for assigning user-relevant or more generally entity-relevant data states of a database at a time in a user or entity-related time sequence with storage of these entity-relevant data states specify that also a user or entity-related retrieval of this previously stored by such a method for the allocation and storage data state history in secure, preferably (also) the integrity and / or authenticity as possible while ensuring a historical data reconstruction and at the same time - in view of Moving volumes - also effectively still processable and storable way, so the volume of data greatly reducing, specify in order to create the technical conditions to enable safe documentation in surveillance systems to the effect which entities (ie users) have processed which system states (or those that are relevant to them) at what time, or have even retrieved them from the underlying database.

This object is achieved by a method for the assignment of entity-relevant data states of a database at a time in an entity-related time sequence and storage of these entity-relevant data states according to claim 1 and an associated method for retrieving a current entity-relevant data state A store by an entity at a retrieval time according to claim 19, and another associated method for retrieving historical entity-relevant data states from a memory at a documentation time in an entity-related historical time series of the entity-relevant data states for a specified documentation entity solved according to claim 23.

Advantageous embodiments result from the subclaims. The present invention initially proposes a computer-implemented method for the assignment of entity-relevant data states of a database at a time in an entity-related time sequence and storage of these entity-relevant data states, in which

Documentation events associated with an entity are defined which, when they occur, trigger a storage of the entity-relevant data state of the database existing at the time of entry of the documentation event as the time of entry and the entity, whereby an entity - for example a user (also called user) is created ) or a so-called daemon process or the like - one or more documentation events are assigned whose respective entry causes a time-related documentation of the data state relevant to this entity, thus freezing this data state relevant to the entity at that time in a memory causes, as documentation events, for example, calling a screen mask, which retrieves (for the user) relevant data states (visible) or their processing or the expression of such data states or the like come into question what enable a later retrievable data state history selectively for a particular selectable entity - such as a particular user of the surveillance system - in a secure, preferably (also) data integrity and authenticity guarantying manner,

- And being used as a database system such that records the transactions in the database in chronological order in at least one database journal and the storage of the entity-relevant data state is done so that one key information or more key information is or will be stored for unambiguous identification of the entity-relevant data state at the respective time of entry of the documentation event in the database journal is or are, whereby the method according to the present invention at all becomes technically manageable, since this procedure of the entity-related, the entire history triggered documentation events of each Entity documenting storage The data volume required for this purpose is reduced to a technically justifiable level by using, on the one hand, a journal-oriented database, the transactions in the database, that is to say changes of data states of the database in chronological order in a database journal or even in several database journals chronological sequence, preferably with the respective use of a timestamp, thereby allowing data states of the database to be determined at a historical time within the historical logging time frame and thus providing the basis for storing and also storing the entity-relevant data states in that only one key information or a plurality of key information is or will be stored in the event of the occurrence of a documentation event defined for the entity (that is to say the user, for example), which contains the associated entity-relevant data state to the respective time of entry of the documentation event in the database journal uniquely identify, which is preferably about (also) a timestamp used and so at the same time - given the volumes to be moved - the entity-related historical documentation of the data states only in more effective on a computer system yet processable and in storage technically acceptable magnitude still storable manner is possible. If the data state relevant to the entity is defined from the database as a more complex data structure, such as a tree or more generally a graph, then this more complex data structure may be one or more corresponding (additional) key information (s) entering the database - For example, to the there also in time sequence as a journal deposited data structure information refer, for example to the time of the documentation for the entity respectively valid root node of a tree - are mapped, which further reduces the data volume to be stored in these cases.

Further, the present invention as claimed in claim 19 teaches a computer-implemented method of retrieving a current entity-relevant data state from a memory in which Entity-relevant data states are stored by means of the above-described inventive method, by an entity at a retrieval time, wherein

the entity-relevant data state belonging to the entity in the entity-related historical temporal sequence of the entity-relevant data states, which is temporally the last prior to the retrieval time, is retrieved from the memory as the current entity-relevant data state, which is stored by storing data-relevant data states by means of the method already mentioned above for the assignment of entity-relevant data states of a database at a time in an entity-related time sequence and storage of these entity-relevant data states according to the present invention, it is technically easily possible, since the corresponding data states in the entity stored temporal sequence and so only the last time before the retrieval time for the retrieving entity deposited entity-relevant data state must be retrieved from the memory.

Finally, the present invention according to claim 23 shows a computer-implemented method for retrieving historical entity-relevant data states from a memory in which entity-relevant data states are stored by means of the method according to the invention presented above, from a documentation period in the entity-related historical temporal Sequence of the entity-relevant data states for a specified documentation entity, where

the respective entity-relevant data states are retrieved on the basis of the documentation entity and the documentation period in that all entity-relevant data states belonging to the documentation entity whose time of occurrence of their respective documentation event temporally within the documentation period in the entity-related historical temporal sequence of the entity Relevant data states are preferably retrieved in their time sequence, which is achieved by the method mentioned above for the assignment of entity-relevant data states of a database at a time in an entity-related temporal sequence and storage of these entity-relevant data states according to the present invention The invention is technically easily possible since this has stored the corresponding data states in the entity-related temporal sequence for the respective entry time of a documentation event defined for the entity and so only all stored for the specified documentation entity documentation times must be traversed within the documentation period, in which case in each case the entity-relevant data states stored for the specified documentation entity are retrieved.

The above-mentioned principle of comprehensible and thus data integrity and data authenticity at each historical documentation time ensuring, but at the same time data volume reduced storage, so a - even more simple - later data retrieval - in a sense seen through the historical glasses of the entity, such as the user at the time - allows, thereby drawing the present invention. Of course, an entity-related - preferably user-related access rights control system, for example by means of user IDs (user identifiers)) and passwords, but better provided by means of ID cards or the like, which ensures that activities on the system only can be performed by appropriately authenticated users.

The inventive method for assigning entity-relevant data states of a database at a time in an entity-related time sequence and storage of these entity-relevant data states can be designed so that the documentation event that causes the respective documentation of the entity-relevant data state by the Entity, so about the user is triggered itself, such as in a program routine that the user performs for a specific purpose - such as to display data states from the database - a call is made to the provided for this event documentation routine. Alternatively or additionally, however, such a documentation event can also be accessed from outside the entity-that is, not by the user himself, whose relevant data states are to be historically documented-but, for example, by the user. be triggered by a third party or by an automatically - preferably parallel - running program routine.

In the present inventive method for the assignment of entity-relevant data states of a database at a time in an entity-related temporal depreciation Following the storage and storage of these entity-relevant data states, the database can use status information in the form of a status or several states (in the present text, the term states is used in the sense of states - that is, as a plural of state), this being based on the substantiated participle Passive Passive of Latin stare (standing), which is in the singular status (the confessional as a synonym to state) and in the plural stati (as a synonym to the confessed), which in contrast to the use of the corresponding nouns (which both in the singular, as well as in the plural Status are written) leads to different spellings in singular and plural and thus - as in computer science obvious - confusion of singular and plural prevents.) Of the system to be monitored or part of it at any given time, with this status or these states each as a discrete state of the system to be monitored or a part thereof - that is, as a status such as OK, not OK or RED / YELLOW / GREEN or the like - may be present. Also, the states of the system or part thereof to be monitored may satisfy one ordering relation in relation to each other. Particularly preferably, the respective status of the system to be monitored or a part thereof is present as a discrete status in three stages, namely red, yellow and green, which satisfy the order relationship red <yellow, red <green and yellow <green.

In the aforementioned embodiments of the method for associating entity-relevant data states of a database at a time in an entity-related time sequence and storage of these entity-relevant data states according to the present invention, where the database status information in the form of one or more statuses of Thus, the suitability of the present invention for the already mentioned system monitoring is in the foreground: Here states (stati) - preferably discrete states of the system to be monitored are stored in the database to then entitäts -related - preferably so user-related - historically securely hold depending on the corresponding documentation events in order to retrieve them then possibly for a particular entity - preferably a user - time related. This is - as already mentioned at the beginning of the prior art - in a monitoring system of the utmost interest because it allows an exact temporal user-oriented documentation of the processes on the monitoring system - such as a case of damage - to understand exactly which entity - preferably which Users - of the system, for example, which states took note of or confirmed or changed or did something like this, such as the or to avoid wrong practices in the future, for example in avoiding or remedying problems. This documentation, which already fails according to the prior art to the data volume occurring in this case, is now possible by the present invention.

A preferred embodiment of the inventive method for assigning entity-relevant data states of a database at a time in an entity-related time sequence and storing these entity-relevant data states is characterized in that at least one monitoring procedure is provided for the system to be monitored, which, in its execution, determines an actual state of the system or a part thereof to be monitored and checks for fulfillment of at least one desired state of the system to be monitored or a part thereof and at least one elementary state of the system depending on the result of this test or these tests monitoring system or a part thereof stored in the database, preferably at least one of the monitoring procedures at least once comes to execution. Under target state is not just a static state to understand how it can be determined by a simple comparison with the current state, but also about a state that is characterized in that it meets certain conditions, ie For example, it fulfills certain rules which can be checked procedurally, preferably by the monitoring procedure.

By such automatic Ermitdung of elementary states of the system to be monitored, the reliability of the database used and thus the data integrity is further increased. It lends itself to all systems to be monitored, which enable a connection via an automatically queriable interface and can be triggered by the entity itself but also by another entity, such as a designated Scheduler - such as event-driven or scheduled-triggered, which the Reliability of monitoring and thus the data integrity further increased.

A monitoring using the method for the assignment of entity-relevant data states of a database at a time in an entity-related time sequence and storage of these entity-relevant data states comes - as already mentioned in another context - preferably for systems such as industrial plants or (complex) Machines, but not least for information technology systems such as ERP systems, preferential wise SAP systems in question, where by means of the present invention audit-proof internal control systems - also called ICS or compliance systems - can be realized.

Also, at least one status change procedure can be provided which, when it is triggered (ie execution) by the entity, preferably a user, allows the elementary status or the elementary states of the system to be monitored or a part thereof in the database explicitly - also independently of the monitoring procedure (s) - to be changed and stored in the database, the entity - preferably the user - at least one status change documentation event is assigned, which occurs in the event of initiation of the status change procedure and the storage of existing at this time entry entity relevant-preferably user-relevant-data state of the database as the entry time and the entity - preferably the user - triggers associated, thus ensuring that such changes by an entity - preferably a user - also by the present invention underlying mechanism even in the entity-related - preferably user-related - temporal sequence of the entity relevant - preferably user-relevant - data states are automatically documented, what the data security, in particular the data integrity and authenticity but also the reconstructability of the data particularly useful is.

The status change procedure is preferably designed in such a way that, when it is triggered by the entity, it allows an additional information associated with the status change to be stored, preferably a comment, which can also be done particularly preferably in the database. This can also be configured so that a change in status requires an additional information assigned to it-preferably a comment.

Once in the memory of a computer entity-relevant data states have been deposited by means of the inventive method for assigning entity-relevant data states of a database at a time in an entity-related temporal sequence and storage of these entity-relevant data states, so the current entity Relevant data state from a memory on the basis of the entity and the retrieval time - as already explained above - also retrieved easily by the temporally last in the entity belonging entity-relevant data state before the current retrieval time in the entity-related historical temporal Sequence of entity-relevant data states lying Data state is retrieved as current data state at the time of retrieval, this current data state for the case that elementary states of a monitored system have been deposited as the current entity-relevant data state of the current elementary status or the current elementary states of the system to be monitored or a part thereof be retrieved from the memory.

In addition, it may be advantageous to form so-called aggregated statuses from such elementary states, for example to build up a status hierarchy or even a status network (that is to say a status graph) in which an aggregated status is formed from other statuses by aggre- gation , The states which are aggregated to form an aggregated status can themselves be aggregated states or elementary states, whereby of course it must be ensured that all aggregated states can ultimately be aggregated from elementary states and not into circles (also called hops) ) comes in the aggregation structure. However, such compasses can be easily avoided in constructing the aggregation structure by using, for example, well-known graph theory methods for circular recognition or choosing an aggregation structure, such as a hierarchical tree, which does not allow such compasses and has elementary states on their leaves.

If a status is aggregated from a single status, this is preferably done so that the status of the single status to be aggregated is simply taken over for the aggregated status. However, the aggregation can also take place in such a way that the aggregated status from at least two other states is determined by minimum determination of the at least two other states in accordance with the order relation which satisfies the stored states.

If one chooses, for example, as possible states ROT, YELLOW and GREEN, ie a traffic light system with the order relation ROT <YELLOW <GREEN, then the one which corresponds to the smallest state to be aggregated is preferably determined as the aggregated state. Thus, if all the states to be aggregated are GREEN, the aggregate state is GREEN. If at least one of the states to be aggregated is RED, then the state to be aggregated is also RED. If at least one of the states to be aggregated is YELLOW and none of the states to be aggregated is RED, then the aggregated state is YELLOW.

Against the above-explained background of the method according to the invention for retrieving a current entity-relevant data state from the memory in which entity-relevant data access is provided. It should be noted that, in a particularly preferred embodiment of this method for assigning entity-related data states of a database at one time to an entity-related time sequence and storing these entity-relevant data states. At least the execution of the method for retrieving the current entity-relevant data state from the memory by the entity itself at the time of retrieval is defined, which then stores the entity-relevant data state of the entity at the time of retrieval as the occurrence of this documentation event Database as this entry time and the entity associated triggers. The retrieval of the current data state itself thus represents a documentation event that documentation of the data state valid for this retrieval time point for the respective entity-preferably the respective user who initiates the retrieval directly or indirectly-triggers. As a result, the present invention enables a highly secure historical progress documentation of the entity-relevant data states in their user-related temporal sequence. A surveillance system using the present invention is thus capable of complete and audit-proof time-dependent documentation of the entity, preferably user view, of all the entities preferably called by the user, unlike the prior art, with reasonable effort for the storage space required for this purpose to ensure relevant data states; an invaluable advantage for data security to be ensured, preferably data integrity and / or data authenticity, but also possible historical data reconstruction, which is desirable, for example, but not only, in monitoring systems.

The present invention also makes it possible, as already mentioned at the outset, by depositing the entity-relevant data states in the memory of a computer by means of the inventive method for assigning entity-relevant data states of a database at a time in an entity-related time sequence and storage of these entity-relevant data states, now also the retrieval of historical entity-relevant data states from a documentation period in the entity-related historical temporal sequence of the entity-relevant data states for a specified documentation entity from the memory. The stored historical entity-relevant data states can then namely from memory on the basis of the documentation entity, preferably for a user - such as a user or user ID 's - and the desired documentation period from the past - as already described above - Are also easily retrieved by all the documentation time stored for the specified documentation entities are traversed within the documentation period, then in each case for the specified documentation entity deposited at the respective documentation time points entity-relevant Datenenzustände- preferably in ascending or descending chronological order - be retrieved.

In the event that elementary states of a system to be monitored have been deposited as the data state, the particular elementary status or the respective elementary states of the system to be monitored or of a part thereof is then retrieved from the memory as a respective entity-relevant data state.

Again, it may be advantageous to form so-called aggregated states in the already described Weiuse from such elementary states, for example to build up a status hierarchy - or even a status network (ie a status graph) - in which an aggregated status from other states is formed by aggregation. Because of the relevant details, reference is made to what has already been said.

In the above description of the present invention is their preferably given suitability for purposes of system monitoring, ie about that of industrial machinery or IT systems including their software systems - such as ERP systems (eg SAP systems) - and their secure historical documentation in focus However, it also has other important advantages that should not be left unmentioned here.

Thus, in a more general context, the present invention also lends itself to much more far-reaching goals. For example, it is also used to implement a file system (which then performs the operations on the dataset to be managed as transactions in chronological order in one (or more) database journal (en) logging a corresponding database), which provides a retrospectively retrievable, user-selective historical view of the state of the file system, the temporal resolution of the subsequently available data state changes along the respective user-selective time axis then depends on the selected definition of the documentation events associated with the users. However, it should be noted that the granularity of such documentation events can indeed be adapted to the performance of the available hardware and the data volume to be handled, whereby the inventive methods also offer the advantage of scalability.

The above described methods of the present invention may be practiced in all embodiments on an appropriately configured computer system, which computer system may also be a distributed computer system, but which includes at least one computer.

The computer system further comprises at least one processor (CPU) and a memory such as a main memory and / or mass storage. It is important to know that in the case of a distributed computer system with several computers, the data to be processed according to the invention can not necessarily be allocated to the memory of a computer, but rather can also be distributed.

For the inventive method can also be a computer program, such as on a disk, such as a DVD, a Blue-Ray Disc, a CD, a SSD (SolidStateDisk) disk, preferably a USB stick or a data cloud mass storage Composite) or an electronic carrier signal, such as for download, such that when executed on a computer system - for which it has corresponding program code means (instructions) - the respective method according to the present invention is executed.

In the following non-limiting exemplary embodiments will be discussed with reference to the drawings. In this show:

Fig. 1 is a schematic overview representation, as the present invention for

Monitoring an external system can be used

2 shows a schematic representation in which a system driven by an internal combustion engine driven uninterruptible power supply (UPS) is used as the system to be monitored, a schematic representation of a retrieval operation in which a user A retrieves his user-relevant current data state, also a schematic representation of another subsequent retrieval operation, in turn, the user A his user-relevant current data state at this later time, namely at 11:00 Clock retrieves, another schematic representation of an even later change process, in turn, the user A the most recently retrieved at 11:00 clock and it still available without recalling user-relevant current data state at this later time, namely at 11:11 Clock changes, also a schematic representation of another subsequent retrieval process in which now another user B retrieves his user-relevant current data state at this later time, namely at 12:00 clock, now a report for user A, as a result of a call all documented for him relevant Data states for the historical period of interest from 10:00 am to 6:00 pm, the corresponding report for user B, also as a result of a retrieval of all relevant documented data states for the relevant historical period from 10:00 am to 6:00 pm , A schematic representation in which the system to be monitored, an ERP system, among other things, for the processing of customer orders, preferably a part of an SAP system is used,

10 is a schematic representation of a retrieval operation in which a user A retrieves his user-relevant current data state. 11 likewise shows a schematic representation of a further, later retrieval process in which, in turn, user A retrieves his user-relevant current data state at this later time, namely at 11:00 o'clock,

FIG. 12 shows a further schematic illustration of an even later change procedure in which user A in turn retrieves the user-relevant current data state last accessed at 11:00 o'clock and which is still available to him without a recall, at this later time, namely at 11 : 11 clock changes,

FIG. 13 likewise shows a schematic representation of a further later retrieval process in which a further user B now retrieves his user-relevant current data state at this later time, namely at 12:00,

14 now shows a report for user A, as a result of a retrieval of all documented data states relevant to him for the historical period of interest 10:00 to 18:00, and

FIG. 15 shows the corresponding report for user B, also as a result of retrieving all of the relevant documented data states for the historical period of interest 10:00 to 18:00.

1 shows a schematic overview of how the present invention can be used to monitor an external system 1.

Here, a method for assigning entity-relevant - preferably user-relevant - data states of a database DB at a time in an entity-related time sequence and storing those entity-relevant data states on a computer system 101 - here as a single computer is present - operated, this purpose, a processor (CPU) 102, which performs the method and a memory 103 (main memory and / or mass storage), in which the necessary program code and the data pending for processing is stored, where an entity - preferably a user - associated documentation events are defined - which may be done for example by a deposit of these definitions in the memory 103, for example, in the database DB itself - which then, when they occur, a storage

preferably in the memory 103, triggering the entity-relevant data state of the database DB existing at the time of entry of the documentation event as the entry time and entity, using as the database system DB such that transactions on the database DB are arranged in chronological order in at least one database Journal and wherein the storage of the entity-relevant data state - preferably in the memory 103 - done so that while a key information or a plurality of key information is stored or will be used to uniquely identify the entity-relevant data state at the respective time of entry of the documentation event in the database Journal of database DB is suitable or are. The documentation event can be from the entity

- Preferably the user - be triggered itself, such as when an entity-relevant, preferably user-relevant data state from the database DB by the entity - such as the user itself - is retrieved.

Here, the database DB contains status information in the form of a status or several statuses of a system 1 to be monitored or of a part thereof at specific points in time, which may be present, for example, as a discrete status of the system 1 to be monitored or a part thereof.

Furthermore, monitoring procedures CT are provided, which are preferably stored in the memory 103 of the computer 101 and are preferably executed by its processor (CPU) 102, these monitoring procedures CT serving to monitor the system 1 to be monitored and at least one actual state during its execution IS of the system to be monitored 1 or a part thereof and check for fulfillment of at least one target state of the monitored system or a part thereof and depending on the result of this test or these tests at least one elementary status ES of the system to be monitored 1 or Save part of it in database DB. Also, status change procedures can be provided which, when triggered by the entity (preferably a user), allow the elementary status or the elementary states ES of the system 1 to be monitored or a part thereof in the database DB explicitly - also independently from the monitoring procedures CT - to change and store in the database DB, wherein the entity - preferably the user - at least one status change documentation event is assigned, which occurs in the case of triggering the status change procedure and the storage of existing at this time entry entity relevant Data state of the database DB as the entry time and the entity - preferably the user - triggers associated. Preferably, with such a change in status, additional information associated with this change, for example a comment on the change in the database DB, can be stored by the entity, preferably the user, which makes it comprehensible why the status has been changed. Also, such additional information may be mandatory, so that a change is even possible.

In the exemplary embodiment of the present invention shown here, at least one of the monitoring procedures CT is not initiated by the entity itself, but rather triggered by a so-called scheduler SC in an event-controlled or timed-controlled manner.

As system 1 to be monitored, an industrial plant or machine or an information technology system, in particular also the software components of an information technology system, that is to say an ERP system, for example an SAP system, may be provided.

The entity-preferably the user-by means of the inventive method for retrieving a current entity-relevant data state from a memory 103, which preferably also runs on the computer 101 and stored approximately in its memory 103 and about preferably by a program on the Processor 102 of the computer 101 is executed, retrieve entity-relevant data states from the memory 103, which were stored by means of the aforementioned method in the memory 103. The entity-preferably the user-preferably uses a monitor software module MO, which contains the program code for executing the aforementioned retrieval method. By means of one or more accesses to the memory 103, preferably (also) to the database DB lying in this memory 103, becomes at a certain retrieval time the time-relevant prior to this retrieval time, the entity preferably to the user associated entity-relevant data state stored in the memory 103 entity-related historical time sequence of the entity-relevant data states as the current entity-relevant data state from the memory 103th retrieved and displayed on a display device 108 - preferably a screen. The current entity-relevant data state, which is thus retrieved from the memory 103, preferably has a current elementary status ES or the current elementary states ES of the system 1 to be monitored or of a part thereof. When retrieving, however, it is also possible to aggregate states in such a way that the aggregation of an aggregated status from at least one other status, which is an elementary status ES or even an aggregated status, is determined. If several states are to be aggregated, then preferably the aggregated status can be determined from at least two other states by minimum determination of the at least two other states according to an order relation, whereby hierarchical tree structures for monitoring can be realized whose higher-order nodes are the state of the subordinate ones Subtrees up to the elementary states ES of the monitored system 1 reflect.

With regard to the above-described method for retrieving a current entity-relevant data state from the memory 103, in the entity-relevant data states by means of the method according to the invention for the assignment of entity-relevant data states of a database at a time in an entity-related time sequence and storage of these In addition, in a particularly preferred embodiment of this method for assigning entity-relevant data states, a documentation event associated with the entity, preferably the user, is at least the execution of the method for retrieving the current entity status. relevant data state from the memory 103 by the entity - preferably the user - itself is defined at the time of retrieval, whereby then the storage of the time of retrieval as the occurrence of this documentation event existing n entity-relevant data state of the database is triggered as this entry time and the entity - preferably the user - associated. The retrieval of the current entity-relevant data state thus constitutes a documentation event that documentation of the data state valid for this retrieval time point for the respective entity-preferably the respective user who initiates the retrieval directly or indirectly-triggers. This ensures a secure historical progress documentation of the entity-relevant data states in their entity (user) achieved temporal sequence. The monitoring system shown here, which uses the present invention, is thus able-with reasonable effort for the space required for this purpose-to ensure complete and auditable time-dependent documentation of the entity, preferably user, view of all relevant data states retrieved by the entity, preferably the user. which is of great advantage for the operational safety of the system 1 to be monitored, it is possible in the event of a malfunction to reconstruct all relevant events on the part of the monitoring system in relation to the entity - that is, preferably user-related. An entity-related is a matter of course in this case, of course - preferably user-bezogenes- access control system, for example by means of user-ID ^'s (Benutzerkennungfen]) and passwords better, but by means of ID cards or the like provided that ensures that activities on the system can only be performed by appropriately authenticated users.

In order to actually perform the aforementioned data state reconstruction, the present invention may also retrieve historical entity-relevant data states from a documentation period in the entity-related historical temporal sequence of the entity-relevant data states for a specified documentation entity from memory 103 are used.

For this purpose, it provides a method for retrieving historical entity-relevant data states from a memory 103, which is preferably implemented as a program for execution on a computer 101 - preferably on its processor (CPU) 102 - in its memory 103 it also approximately can be deposited. Particularly preferably, this program is also part of the monitor software module MO. Such a retrieval is possible because in the memory 103 the entity-relevant data states are stored by means of the method according to the present invention mentioned at the outset: all the data relevant to the documentation entity-preferably to the user to be documented-are simply relevant to the entity. their time of occurrence of their respective documentation event in time in the documentation period in the entity-related historical temporal sequence of the entity-relevant data states lie- preferably in their time sequence (ascending or descending) - retrieved. Because of the storage according to the invention, the stored historical entity-relevant data states can be retrieved from the memory 103 quite simply on the basis of the documentation entity, preferably thus for a specific purpose. users - for example, by means of an entity ID ^' s, user or user ID ^' s - and the desired documentation period from the past retrieved by all the documentation stored for the specified documentation entity documentation times are traversed within the documentation period, then In each case, the entity-relevant data states stored (for example state by state) for the specified documentation entity at the respective stored documentation times are retrieved from the memory 103, preferably in ascending or descending chronological order. The result is then output, preferably in the form of a report on a display device 109, preferably a printer. In the event that elementary states ES of a system 1 to be monitored have been deposited as the data state, the respective elementary state ES or the respective elementary states ES of the system 1 to be monitored or of a part thereof is then output from the memory as a respective entity-relevant data state 103 retrieved. As already mentioned, it may be advantageous to use such elementary states. ES to form so-called aggregated states in the manner already described, such as to build a status hierarchy in which or an aggregated status of one or more other states is formed by aggregation. Because of the relevant details, reference is made to what has already been said.

Fig. 2 shows a schematic representation in which is used as a system to be monitored 1, driven by an internal combustion engine uninterruptible power supply (UPS).

It is schematically illustrated in a diagram for the uninterruptible power supply 1, how the cooling water level and the fuel level of the aforementioned uninterruptible power supply 1 in a period of 10:00 clock to 11: 00 o'clock in the course of time in parts of hundred (%) the respective level.

A first monitoring procedure 4 retrieves the actual state of the cooling water level at 10:10 o'clock and determines by testing based on a desired state of the elementary status of the cooling water level at this time. Since the target state for the cooling water is a minimum of 70%, the status thus determined by the first monitoring procedure is GREEN and is stored in the database in a first database journal 5 for the time 10:10. The same happens by means of the second monitoring procedure 3 for the fuel level at 10:11, wherein the desired state here requires a minimum level of 35%.

At 10:40 clock in turn, a run of the first monitoring procedure 4, which in turn determines the desired state sufficient cooling water level and enters into the first database journal 5 accordingly.

Also runs the second monitoring procedure 3 for the Krafistoffstand at 10:45, where the target state here no longer corresponds to the Miriimalfüllstand of 35% for the elementary status GREEN, but in the monitoring procedure already to an elementary status that corresponds to a warning, namely YELLOW leads. This is also entered into the database in a first database journal 5.

Fig ,. 3 shows a schematic representation of a retrieval process 2 in which a user A 6 retrieves its user-relevant current data state 7.

First, it is determined which data represents a user-relevant data state for the user A 6. In the present case, this can be deduced from the fact that the access (defined implicitly via an access profile assigned to the user A or more generally to an entity) leads to a specific entry point into an aggregation hierarchy table 20, which for the status stored therein contains the aggregated status The term aggregation UPS contains information about the associated states to be aggregated - here the elementary states coolant level and fuel level - in which the associated aggregated state is noted for each of the states to be aggregated.

In the present case, this aggregation hierarchy table 20 is static in nature, that is, does not change over time during operation for purposes of illustration. However, it is readily possible to provide for a change of this aggregation hierarchy table 20 during operation. In this case, the aggregation hierarchy table 20 is then preferably also run as a further database journal in chronological order and then also makes it possible to reconstruct the aggregation hierarchy at the historical time in question.

After access 21 to the aggregation hierarchy table 20 via the aggregated status aggregation UPS it is now clear which user-relevant data state is to be displayed namely, the aggregated state called aggregates UPS and the two elementary states cooling water level and

Now, the corresponding elementary states cooling water level and fuel level are retrieved from the first database journal 5 13, where the last entries of these states are determined before the retrieval time 10:15, where as the key information determined over the retrieval time and the name serve the respective elementary status.

In the present case, however, this is not sufficient since a database is used here which comprises two database journals 5, 9 with chronologically recorded sequence, namely a second database journal 9 in addition to the already mentioned first database journal 5 for storing the elementary states Storing any changes made to the elementary states by any users (more generally entities).

Therefore, it must now be looked up whether there are newer entries in this second database journal 9 for storing the changes made to elementary states than in the first database journal 5 for the elementary states currently to be retrieved. In this case, these newer entries from the second database journal 9, instead of those from the first database journal 5, are to be used as the current data state for the retrieval 19.

In the present case, several database journals 5, 9 are thus used in the database in order to build up a thematically ordered data structure in the database (one table for the originally recorded elementary states and another for the subsequently made changes). This principle can be further expanded by further thematic divisions of other database journals on other tables, then possibly different key information for different database journals are used for access, such keys in the form of a primary, a secondary, a tertiary, etc. key can happen. However, this is not necessary: Basically, it is sufficient to have a database journal in the database, which records transactions in the database in chronological order in this one database journal and stores the entity-relevant data status in such a way that a key information or a plurality of key information is or will be stored, which is or are suitable for uniquely identifying the entity-relevant data state at the respective time of occurrence of the documentation event in the database journal. In the present case, however, there are no later changes to the elementary states in the second database journal 9.

The data now retrieved from the first database journal 5 are now made available to the user A 6 as the current user-relevant data state 7 and are displayed by the latter.

It is important to mention that the retrieval process described above itself as a documentation event 10 - here about in a third database journal 8 - later retrievable with the time of the occurrence of this documentation event 10 in a memory here the user A 6 held -festgehalten becomes 12.

Fig ,. 4 likewise shows a schematic representation of a further later retrieval operation 2, in which the user A 6 in turn retrieves his user-relevant current data state 7 at this later time, namely at 11:00 o'clock.

Fig ,. FIG. 5 shows a further schematic representation of an even later change process 24 in which the user A 6 in turn retrieves the user-relevant current data state 7 last retrieved at 11:00 o'clock and which is still available to him without recalling, at this later time, namely at 11 : 11 am changes what causes a corresponding entry in the second database journal 9 and in the third database journal 8 16, the latter because this change also represents a documentation event 14 whose result is documented. When the change was made, user 6 had the opportunity to comment on the change, which he did by saying "tanker order".

Fig ,. 6 likewise shows a schematic representation of a further, later retrieval process 2 in which a further user B 18 now retrieves its user-relevant current data state 7 at this later time, namely at 12:00 o'clock. It is noteworthy that this additional user B 18 now retrieves as its user-relevant current data state 7 those resulting from the change made by user A 6 according to FIG. 5, but then immediately triggers a documentation event defined for user B 18, which - again here in the third database journal 8 - later retrievable with the time of the occurrence of this documentation event 10 held in a memory - now the user B 18 associated - is stored 12. Preferably, for example by displaying details Information on an information line - not shown here - user B 18 sees for the elementary status of the fuel status for the local status GREEN also the remark "Order tanker", which was previously specified by user A 6.

Fig. 7 now shows a report for user A, as a result of a retrieval of all relevant for him documented data states for the interest here historical period 10:00 clock to 18:00 clock.

FIG. 8 shows the corresponding report for user B, also as a result of retrieving all of the relevant documented data states for the historical period of interest, 10:00 am to 6:00 pm, of interest here.

Fig ,. FIG. 9 shows a schematic representation in which the system 1 to be monitored uses an ERP system, inter alia, for processing customer orders, preferably a part of an SAP system.

The system for processing customer orders 1 contains an order transaction journal 22 and a table with customer data 23. In the order transaction journal 22, order numbers, customer identifications, order value of the respective order, and the payment method are recorded. The customer data also shows the customer identification, the number of previous order processes and the previous sales with the customer.

A first monitoring procedure 4 retrieves the actual status of the order transactions of the payment method invoice at 10:10 am and, by checking on the basis of a target status, determines the elementary status for the order number 4711 which is to be invoiced at this time. Since the debit status for orders of the payment type invoice results with the aid of the customer data, which, in view of the already 12 orders placed with a total turnover of € 12,323.00, appears to have justified a delivery on account of the rules in the first monitoring procedure 4 The status determined by the first monitoring procedure 4 for the order No. 4711 is GREEN and is stored in the database in a first database journal 5 at 10:10.

The same happens by means of the second monitoring procedure 3 for the order no. 4712 at 10:11 am, which is therefore classified as justified by the second monitoring procedure 3 responsible for ordering the payment method credit card, because of this amount are guaranteed and can not cause any payment defaults. The corresponding determined elementary status is therefore also here for the order No. 4712 GREEN.

At 10:40 o'clock in turn takes place a run of the first monitoring procedure 4, which is responsible for ordering the payment method invoice. It records the order no. 4713, which has since been received, but states that this order is not prohibited for a new customer with no sales yet as a delivery on account, but is nevertheless to be classified as critical, since such risks increase even with smaller order values considerable risks. The first monitoring procedure 4 therefore determines the elementary status YELLOW (for a warning note) for the order No. 4713 according to the rules used in it and enters this into the first database joumal 5 at 10:40.

Fig ,. 10 shows a schematic representation of a retrieval operation 2 in which a user A 6 retrieves its user-relevant current data state 7.

First, it is determined which data represents a user-relevant data state for the user A 6. In the present case, this can be deduced from the fact that the access (defined implicitly via an access profile assigned to the user A or, more generally, to an entity) leads to a specific entry point into an aggregation hierarchy table 20 which, for the status stored there, includes the aggregated status The term Aggr. Orders information about the associated to be aggregated Stati- here the elementary statuses Best. Invoice and Best. Credit card- contains in there for each of the states to be aggregated the associated aggregated state is noted.

In the first place, this aggregation hierarchy table 20 is of a static nature in the interests of simplicity of presentation, that is to say that it does not change over time during operation. However, it is readily possible here as well to provide for a change of this aggregation hierarchy table 20 during operation. In this case, the aggregation hierarchy table 20 is again preferably also run as a further database journal in chronological order and then also makes it possible subsequently to reconstruct the aggregation hierarchy at the historical time point considered.

After access 21 to the aggregation hierarchy table 20 via the aggregated status Aggr. Orders, it is now clear which user-relevant data state will be displayed is supposed to, namely the aggregated state with the designation Aggr. Orders and the two elementary states Best. Invoice and Best credit card.

Now the corresponding elementary statuses Best. Invoice and Best credit card are retrieved from the first database journal 5 13, where the last entries of these statuses are determined there before the retrieval time 10:15, the key information being the information about the retrieval time Time, the order number and the description of the respective elementary status.

In the past, however, this is not sufficient since here a database is used which comprises two database journals 5, 9 with chronologically recorded sequence, namely a second database journal 9 in addition to the already mentioned first database journal 5 for storing the elementary states Storing any changes made to the elementary states by any users (more generally entities).

However, there are no later changes to the elementary states in the second database journal 9 here.

It is important to mention that the retrieval process described above itself as documentation event 10 - here about in a third database journal 8- later retrievable with the time of the occurrence of this documentation event 10 in a memory-here the user A 6 belonging -festgehalten becomes 12. Fig ,. 11 likewise shows a schematic representation of a further, later retrieval process 2, in which the user A 6 in turn retrieves his user-relevant current data state 7 at this later time, namely at 11:00 o'clock.

Fig ,. FIG. 12 shows a further schematic representation of an even later change process 24 in which the user A 6 in turn retrieves the user-relevant current data state 7, which was last retrieved at 11:00 o'clock and which is still available to him without recalling, at this later time, namely at 11 : 11 am changes what causes a corresponding entry in the second database journal 9 and in the third database journal 8 16, the latter because this change also represents a documentation event 14 whose result is documented. When changing the user 6 had the obligation to comment on the change of the basic status of the order No. 4713 with the payment method invoice, which he also did by the remark "Schufa OK".

Fig ,. 13 likewise shows a schematic representation of a further later retrieval operation 2 in which a further user B 18 now retrieves its user-relevant current data state 7 at this later time, namely at 12:00 o'clock. It is worth mentioning again that this additional user B 18 now retrieves as its user-relevant current data state 7 those resulting from the change made by user A 6 according to FIG. 12, but then immediately triggers a documentation event defined for user B 18 stored - here again in the third database journal 8- later retrievable with the time of the occurrence of this documentation event 10 in a memory - now the user B 18 - 12 is preferably stored, for example by displaying detailed information on an information line - not shown here - sees user B 18 for order No. 4713 to the local status GREEN also the remark "Schufa OK", which was previously specified by user A 6.

14 now shows a report for user A, as a result of a retrieval of all documented data states relevant to him for the historical period of interest 10:00 to 18:00.

FIG. 15 shows the corresponding report for user B, also as a result of retrieving all of the relevant documented data states for the historical period of interest, 10:00 am to 6:00 pm, of interest here.

Claims

Title: Computer-implemented entity-related, time-based system status documentation Applicant: arvato Systems GmbH, An der Autobahn 200, D - 33333 Gütersloh Patent claims

1. Computer-implemented method for assigning entity-relevant data states of a database (DB) at a time in an entity-related temporal sequence and storing these entity-relevant data states (7), characterized in that an entity (6, 18) assigned documentation events (10, 14) are defined, which, when they occur, store the entity-relevant data state (7) of the database (DB) existing at the time of occurrence of the documentation event (10, 14) as the time of entry and the entity (6, 18) associated, the database system used is one that logs transactions on the database (DB) in chronological order in at least one database journal (5, 8, 9) and the storage of the entity-relevant data state This is done in such a way that one or more key information is or are stored, which is or are suitable for the clear identification of the entity-relevant data state at the respective time of occurrence of the documentation event (10, 14) in the database journal (5, 8, 9). .

2. Computer-implemented method according to claim 1, characterized in that the documentation event (10, 14) is triggered by the entity (6, 18) itself.

3. Computer-implemented method according to claim 1 or 2, characterized in that the documentation event (10, 14) is not triggered by the entity (6, 18) itself.

4. Computer-implemented method according to one of claims 1 to 3, characterized in that the database (DB) contains status information in the form of a status or several statuses of a system (1) to be monitored or a part thereof at a specific time.

5. Computer-implemented method according to claim 4, characterized in that the status or states are each present as a discrete status of the system (1) to be monitored or a part thereof.

6. Computer-implemented method according to claim 4 or 5, characterized in that states of the system to be monitored (1) or the part thereof satisfy an ordering relationship in relation to one another.

7. Computer-implemented method according to claim 6, characterized in that the respective status of the system to be monitored (1) or a part thereof is present as a discrete status in three stages, namely red, yellow and green, which correspond to the order relation red <yellow, red < green and yellow < green are sufficient.

8. Computer-implemented method according to one of claims 4 to 7, characterized in that at least one monitoring procedure (CT, 3, 4) is provided for the system (1) to be monitored, which, when executed, has an actual state (IS) of the system to be monitored (1) or a part thereof and checks whether at least one target state of the system to be monitored (1) or a part thereof is fulfilled and, depending on the result of this test or these tests, at least an elementary status (ES) of the the system to be monitored (1) or part of it is stored in the database (DB).

9. Computer-implemented method according to one of claims 4 to 8, characterized in that a status change procedure is provided which, when triggered by the entity (6, 18), allows the elementary status (ES) or the elementary states (ES ) of the system to be monitored (1) or a part thereof in the database (DB) explicitly - also independently of the monitoring procedure or procedures (CT, 3, 4) - to change and store in the database (DB), whereby the entity (6, 18) is assigned at least one status change documentation event (14), which occurs in the event of the status change procedure being triggered and the storage of the entity-relevant existing at this time of entry Data state of the database (DB) as belonging to the entry time and the entity (6, 18).

10. Computer-implemented method according to claim 9, characterized in that the status change procedure is designed in such a way that when it is triggered by the entity (6, 18), it allows additional information associated with the status change - preferably a comment - to be saved.

11. Computer-implemented method according to claim 10, characterized in that the status change procedure is designed in such a way that when it is triggered by the entity (6, 18), it requires additional information associated with the status change - preferably a comment - to be saved.

12. Computer-implemented method according to one of claims 8 to 11, characterized in that at least one of the monitoring procedures (CT, 3, 4) is triggered by the entity (6, 18) itself.

13. Computer-implemented method according to one of claims 8 to 11, characterized in that at least one of the monitoring procedures (CT, 3, 4) is not triggered by the entity (6, 18) itself.

14. Computer-implemented method according to claim 13, characterized in that at least one of the monitoring procedures (CT, 3, 4) is triggered by a scheduler (SC) in an event-controlled or schedule-controlled manner.

15. Computer-implemented method according to one of claims 8 to 14, characterized in that an industrial plant or machine serves as the system (1) to be monitored.

1 . Computer-implemented method according to one of claims 8 to 14, characterized in that an information technology system serves as the system (1) to be monitored.

17. Computer-implemented method according to claim 16, characterized in that an ERP system, preferably an SAP system, serves as the system (1) to be monitored.

18. Computer-implemented method according to one of claims 1 to 17, characterized in that the documentation event (10) assigned to the entity (6, 18) is at least the execution of the computer-implemented method for retrieving (2) a current entity-relevant data state is defined from a memory by the entity at a retrieval time according to one of claims 19 to 22, which then involves the storage of the entity-relevant data state (7) of the database (DB) existing at the retrieval time as the occurrence of this documentation event (10) as this entry time and belonging to the entity (6, 18).

19. Computer-implemented method for retrieving a current entity-relevant data state (7) from a memory (103) in which entity-relevant data states are stored using the method according to one of claims 1 to 18, by an entity (6, 18 ) at a retrieval time, characterized in that the entity-relevant data state belonging to the entity (6, 18), which is the last before the retrieval time, is in the entity-related historical temporal sequence of the entity-relevant data states as the current entity-relevant data state ( 7) is retrieved from the memory (103).

20. Computer-implemented method according to claim 19 for retrieving (2) the current entity-relevant data state (7) from the memory (103), in which entity-relevant data states are stored by means of a method according to claim 8 or one of claims 9 to 18 - insofar as these are related to claim 8 - are stored by the entity (6, 18) at the time of retrieval, characterized in that the current elementary status (ES) or the current elementary statuses (ES ) of the system to be monitored (1) or part thereof are retrieved from the memory (103).

21. Computer-implemented method according to claim 20 for retrieving (2) the current entity-relevant data state (7) from the memory (103), in which entity-relevant data states are stored by means of the method according to claim 8 or one of claims 9 to 18 - insofar as these are related to claim 8 - are stored by the entity (6, 18) at the time of retrieval, characterized in that during the retrieval (2) an aggregation of states de- Rarely, the aggregation of an aggregated status is determined from at least one other status, which is an elementary status (ES) or itself an aggregated status.

22. Computer-implemented method according to claim 21 for retrieving (2) the current entity-relevant data state from the memory (103), in which entity-relevant data states are stored by means of the method according to claim 8 - insofar as this is related to claim 6 - or a of claims 9 to 18 - insofar as these are related to claim 6 and claim 8 - are stored by the entity (6, 18) at the time of retrieval, characterized in that the aggregation takes place in such a way that the aggregated status consists of at least two other statuses is determined by determining the minimum of the at least two other states according to the order relation.

23. Computer-implemented method for retrieving historical entity-relevant data states from a memory (103), in which entity-relevant data states are stored using the method according to one of claims 1 to 18, from a documentation period in the entity-related historical temporal sequence of the entity-relevant data states for a specified documentation entity (6, 18), characterized in that the respective entity-relevant data states are retrieved based on the documentation entity (6, 18) and the documentation period in that all of the Entity-relevant data states belonging to the documentation entity (6, 18), the time of occurrence of their respective documentation event lying within the documentation period in the entity-related historical temporal sequence of the entity-relevant data states - preferably in their temporal sequence - are retrieved.

24. Computer-implemented method according to claim 23 for retrieving historical entity-relevant data states from the memory (103), in which entity-relevant data states by means of a method according to claim 8 or one of claims 9 to 18 - insofar as these are based on claim 8 are - are stored, from the documentation period in the entity-related historical chronological sequence of the entity-relevant data states for the specified documentation entity (6, 18), characterized in that the respective elementary status (ES) is the respective entity-relevant data state. or the respective elementary statuses (ES) of the system to be monitored (1) or a part thereof are retrieved from the database (DB).

25. Computer-implemented method according to claim 24 for retrieving historical entity-relevant data states from the memory (103), in which entity-relevant data states by means of a method according to claim 8 or one of claims 9 to 18 - insofar as these are based on claim 8 are - are stored, from the documentation period in the entity-related historical temporal sequence of the entity-relevant data states for the specified documentation entity (6, 18), characterized in that when the retrieval occurs, an aggregation of states takes place in such a way that the aggregation an aggregated status is determined from at least one other status, which is an elementary status (ES) or itself an aggregated status.

26. Computer-implemented method according to claim 24 for retrieving historical entity-relevant data states from the memory (103), in which entity-relevant data states by means of a method according to claim 8 or one of claims 9 to 18 - insofar as these are based on claim 6 and Claim 8 are referenced back - are stored from the documentation period in the entity-related historical chronological sequence of the entity-relevant data states for the specified documentation entity (6, 18), characterized in that the aggregation takes place in such a way that the aggregated status at least two other states are determined by minimum determination of the at least two other states according to the order relation.

27. Computer system (101) for assigning entity-relevant data states of a database (DB) at a time in an entity-related temporal sequence and storing these entity-relevant data states with at least one computer and with at least one processor (102) and at least one Computer system memory (103), characterized in that the computer system (101) is set up to operate by means of at least one processor (102) according to the method according to one of claims 1 to 18.

28. Computer system (101) for retrieving a current entity-relevant data state from a memory in which entity-relevant data states are stored using the method according to one of claims 1 to 18, by an entity at a retrieval time with at least, wherein the computer system ( 101) has at least one computer and at least one processor (102) and at least one computer system memory (103), thereby indicates that the computer system (101) is set up so that it works by means of at least one processor (102) according to the method according to one of claims 19 to 22.

29. Computer system (101) for retrieving historical entity-relevant data states from a memory in which entity-relevant data states are stored using the method according to one of claims 1 to 18, from a documentation period in the entity-related historical chronological sequence the entity-relevant data states for a specified documentation entity, the computer system (101) having at least computers and at least one processor (102) and at least one computer system memory (103), characterized in that the computer system (101) is set up in this way that it works by means of at least one processor (102) according to the method according to one of claims 23 to 26.

30. Computer program which has program code means which, when executed on a computer system, carry out the method according to one of claims 1 to 18.

31. Computer program that has program code means which, when executed on a computer system, carry out the method according to one of claims 19 to 22

32. Computer program that has program code means which, when executed on a computer system, carry out the method according to one of claims 23 to 26