Comparison of models of a complex system.

[0001] The invention concerns the modelling of complex systems and in particular the comparison of models of a complex system. A system of arbitrary kind, for example a process-technical or technical plant, exhibits a multiplicity of interacting and mutually dependent units, which produce a desired result by their cooperation, for example a physical product. Same is valid for a system, whatever exhibits or predominantly human actuators or action carriers and a physical product and/or a service produces. Furthermore the invention is directed toward the area of the data acquisition, data organization, data evaluation and the use of in such way of prozessierter data for the control and Uberwachung of complex Systemen.

Relatives a registration is WHERE 03/027 916 their contents hereby in its whole with taken up wird.

With complex systems, which exhibit a multiplicity of linked with one another processes, it is very difficult to predict the influence of changes of individual linkages and parameters on a behavior of the overall system. For example decision making and control represents a large problem with the production of high-complex goods with appropriate production flows and likewise appropriate organization the conversion of goals, the monitoring of the execution and. Since the number of measured variables with the size of a production process, an enterprise or a project increases exponentially, cannot this any longer collectively grasps to become. Therefore it is very difficult, relevant of not-relevant sizes to evaluate and/or use i.e. parameters and measured values to differentiate to weights and in the correct context. Decisions with the controlling of technical and organizational processes become therefore frequently arbitrary getroffen.

The illustration of such processes usually happens with specialized Modellierungsoder management programs for ERP (Enterprise resource Planning), CRM (Customer Relationship management), SCM (Supply chain management), etc. and custom-made Produktionssteuerungssoftware.

The models are aligned to a certain, current supervisor state, support this and permit for example a regulation from current or past characteristic numbers to the evaluation of a system performance. There is not however the possibility, different systems too with one another vergleichen.

It is therefore a task of the invention to create a procedure for the enterprise of a digital data processing unit for the comparison of computer-based and dataprocessing models of a complex system which an adequate representation of the system and comparing different systems permitted as well as a conversion of in such a manner determined changes in the System.

This task is solved by the subject of the independent requirement. The dependent requirements concern favourable arrangements of the Erfindung.

Becomes thus with the comparison of models of a complex system, whereby a first model and a second model of the system are present, and the models in each case a system performance by means of pre-defined objects to model, which activities and units represent within the system, the following steps implemented:

- Comparison of the models and regulation of each other in each case assigned pre-defined objects first and the second model, - regulation pre-defined objects assigned each other by differences in attributes of, and - expenditure of the differences to a Benutzer.

By the use of pre-defined objects, thus objects, which belong to a well-known quantity of types, the model comparison can be accomplished more efficiently than with unstructured models. It is for example possible to compare models with several thousands of objects. Settlement proceedings are caught even with larger differences, since objects can be preferably assigned over their types and over further identification means such as Identifikatoren or names each other. The expenditure to the user happens by means of expression or well-known Anzeigegeräte.

Two models of the same system are thus used. A model represents the system in first, for example an actual condition, the other model represents the system in second, for example a specified condition. In a preferential variant of the invention by means of an automatic comparison algorithm differences between the two conditions are determined, and actions are defined, which transfer the system gradually from first into the second condition. Preferably given action patterns and appropriate Metriken are used. An action pattern describes a procedure for the reaching of a certain change, the Metrik describes empirical values for an expenditure of costs, time and resources. For example an action pattern describes a Neuoder Umkonfiguration of a certain machine on a Produktvariante or the physical and organizational setting-up of a business branch or a certain administrative process. Thus automatically a portfolio at activities, and with a logical allocation, e.g. into technical, can be produced Iogisti and organizational activities in project defaults for the project planning, and owing to the Metriken also for the execution supervision converted werden.

By the use of a limited sentence of common Grundtypen for the entire modelling it is possible, for settlement proceedings up to the deepest level, according to the Grundtypen to let work after the same Prinzipen. This increases the flexibility and efficiency of settlement proceedings. Just as will possible to compare models of different kind and origin with one another there it on the same objects and Grundtypen basieren.

In a preferential variant of the invention the modelling in both models happens in each case on different modelling levels with different degrees of abstraction, whose objects stand to each other in relationship. In the case of a deletion or a change of an object in one modelling level the change affects perhaps also objects of the other modelling level and causes so indirect changes, those likewise by settlement proceedings found werden.

To assist in the understanding of the invention some further terms are defined:

A system consists of a quantity of cooperating units, whose behavior as a whole copied, examined and preferably also supervised is to be modified. Preferably a system is a technical plant, a machine, a production process or a working process, whereby also several of these aspects contain a system kann.

The cooperating units are preferably electromechanical, process engineering and/or information-processing or information-carrying subsystems or elements, or also organizational subunits and places of an organization. For example are considerationable as unit: a machine as part of a plant, a processor as part of a machine, an autonomous manufacturing cell, a product or a product component, a computer system, a data base, a software object, a machine-readable file, a department of a company, a person, a function or role in an organization, etc.…

The term modelling concerns both a first education of an abstract, in particular a machine-readable representation of the system and an adjusting of this representation to an actual, material condition of the system. The latter becomes in particular with an on-line process analysis (“monitoring”) and/or with a controlling of the system through in the model determined control instructions uses. This representation of the system is called also model and exhibits a model structure as well as model parameter. The model structure represents relations between modelled units, to during that the model parameters numeric and/or textuelle characterisations of characteristics of the units or relations is. The model exhibits mechanisms and rules for linkage and processing of data, which represent aspects of the system. The model is thus not only data containing, but also data a processing Modell.

The modelling happens on a lowest description level with a limited sentence of G round types at the representation of the units and at the description of its cooperation. The Grundtypen exhibit Einund of exits to the Ubernahme and passing on of data. The Grundtypen are:

- A Grundtyp “passing on”, which represents a forwarding of units, data for the characterisation of these units through-leads and an entrance as well as an exit aufweist.

- A Grundtyp “merging”, which represents a combining of units, data for the characterisation of these units with one another links and two entrances as well as an exit for the linked data aufweist.

- A Grundtyp “dividing”, which represents an isolating of units, data for the characterisation of units, which follow from an isolating, from data of a unit which can be isolated determines and one entrance as well as two exits aufweist.

The invention has the advantage that all procedures between units on each detailing stage and view stage are reducible on these Grundtypen. Thus the modelling expenditure is limited, schematizable and at least partly automatable. A further advantage is that also different analyses of the model are in comparatively simple way standardizable and automatable, since the same Grundtypen must be always processed, which simplifies a formalisation and a programming of the analysis. Because the same Grundtypen are always used for system definition, increases also the Vergleichsmöglichkeiten between systems. This is independent of whether a comparison happens automatically or manually and whether cognate or cognate systems are not compared. Likewise a transparency of the models becomes also with high complexity erhöht.

The use of the Grundtypen corresponds to a use of logic elements in electro-technology in the way of thinking: provide themselves with a limited sentence of logic elements such as transistors, resistances, inductances and condensers Iässt immense variety of circuits. Something similar is valid for the logic of integrated circuits, where all conceivable logic functions only by NAND gates realizable sind.

The Grundtypen preferably find their expression in a class hierarchy of an object-oriented representation of software objects, of which the model is composed. Thus all remaining substantial software objects are defined on the basis these Grundtypen and point beyond that naturally further attributes and methods auf.

In a preferential variant of the invention, based on the Grundtyp “pass on”, two further Grundtypen defined and used:

- A Grundtyp “keeping”, which represents a storage of units, data for the characterisation of these units stores and an entrance as well as an exit aufweist.

- A Grundtyp “producing”, which represents a source of units, data for the characterisation of these units produces and an exit aufweist.

In a preferential variant of the invention each Grundtyp exhibits a Historienoder minutes function, with which it finished or stores through-led data as well as the time of the processing or transmission. Thus providing statistics and analyses as well as a later backtracing become procedures möglich.

In a further preferential variant of the invention the Grundtypen on a higher hierarchic level are combined into so-called objects. Of Einund exits of the summarized Grundtypen a number remains within the object, does not become visible thus not outside of the object. Other Einund of exits becomes outward visible than Einund of exits or interfaces of the object. Usually an object exhibits one or more entrances and one or more exits. An object can however for example no entrances respectively no exits exhibit, if it at the beginning respectively at the end of an event chain stands. The term “object”, how it is used in this registration, is more closely calm than the term “software object in the sense of object-oriented programming”: Objects like also Grundtypen are software objects. Objects consist of a quantity of Grundtypen and have defined characteristics and behavior. Objects are designated later also than “pre-defined objects”, for the sake of the shortness however usually only than Objekte.

This permits a structured and systematic concept and also the allocation from information or characteristics to an object as whole one. Furthermore also a recycling of frequently arising structures of Grundtypen becomes as pre-defined objects possible, which again an efficient concept ermöglicht.

Preferably objects exhibit different arrangements, i.e., they represent different aspects of the reality. In accordance with well-known principles of object-oriented programming objects are defined for the representation by for example products, expirations, action carriers, means of production etc., which characteristics and methods of a general object to inherit and this specific characteristics and methods to cause. All objects point one of the five Grundtypen however at least auf.

For the further explanation of the invention still some additional definitions are necessary: The system and its behavior are mentioned &lt on three view levels; , Process level”, “element level” and “Informations-und function level”, betrachtet.

The process level exhibits processes. The system is regarded as grouping of processes. A process is a whole of tasks, expirations and decisions. Processes are for example production processes or working processes like “manufacturing”, “final assembly”, “energy production”, “printer road”, “acetylene synthesis”, “stock management”, “purchase”, “personnel administration”, etc. a process keep from other object types, for example different processes or external agents (see below), over its entrances inputs or inputs and produced for the other object types expenditures or outputs. A process can divided into Subprozesse werden.

A certain task of a process is solved by a certain operational sequence from activities and an appropriate information flow. This expiration is called event chain. Event chains are for example “airbus A320 manufacture”, “50 tons of sulfuric acid make”, “part of XY of automatic warehouse make available”, “printer configure”, “computer job furnish”, “coworkers adjust”. The term process describes thus a unit, which is certain tasks to fulfill able, during that the term event chain a certain operational sequence during a process or over several processes describes. A process becomes typically from several event chains benutzt.

For the modelling of expirations activity diagrams are preferably used, which correspond to the well-known flow charts on an upper representation level. An activity diagram describes sequentially and/or branches out activities running off. Individual activities, branchpoints and decision points of an activity diagram are objects and are thus from the Grundtypen developed. For example a branchpoint is represented by Grundtypen “dividing” with appropriate internal rules. An activity can be developed from a quantity of Grundtypen at will hooked up or from a separate activity diagram. An expiration within a process can be modelled thus on the one hand directly by Grundtypen, on the other hand also by activities, which again from Grundtypen bestehen.

External agents are model parts, which represent an aspect of the reality, which in the model or by a part of the model out or an aggregation of objects is seen not modelled in detail consisting of Grundtypen represents. An external agent essentially puts an interface, i.e. Einund of exits, at the disposal and exhibits optionally a simplified modelling of an actually more complex internal behavior, its to details however not from interest sind.

The element level exhibits elements. An element represents a material physical unit from the categories information technology (IT), organization, tools and mechanical-electronic modules. An element supports a process or an activity of a process. Elements are for example computer, a IT-department, a person respectively an official, a processing machine, an electromechanical product or its Einzelteile.

Informationsund function level exhibits information and functions. These represent in particular information-technical units such as data base tables or - attributes, variables, respectively their values, as well as procedures, programs, measured values and Parameter.

The five Grundtypen are usable on each of the view levels. The system is thus modelled on each of the view levels with the same Grundtypen, whereby the units, whose representation is represented or processed by the Grundtypen, are depending upon view level of different kind. Also objects and pre-defined objects on all view levels appropriately become verwendet.

In order to represent relations among themselves between Grundtypen, objects and, preferably differently constituted relations types are used. In the following the simplicity because of only objects is called, whereby Grundtypen are along-meant as simplest forms of objects. These relations types are grouped as permanent relations, interaction relations, river relations and Differenzbeziehungen.

Permanent relations represents a simple reference from an object to another, or the fact that an object in another view level corresponds to another object. For example a process corresponds to “stock management” of a quantity of several activities “storing”, “outsourcing”, “inventory provides”, etc.

This becomes by a quantity of appropriate permanent relations between the process and the individual activities dargestellt.

Interaction relations or reciprocal effects places an influencing control of an object on another dar.

The kind of the influencing control or reciprocal effect is at the time of the concept well-known and by the kind of the interaction relationship is represented. For example a system crash rate of a product of failure rates of product components is assignable, whereby dependence of the system crash on losses of individual components are represented by respective reciprocal effect relations. In another example for an event chain “engine is noted to manufacture” by two reciprocal effect relations that in addition on the element level in a certain period a machine tool to 70% and a certain manufacturing cell are working at full capacity to 50%. In again another example expresses reciprocal effect relationship that a certain characteristic value, which represents for example a risk, a degree of completion, costs, expenditure of time, materials consumption, energy consumption etc. is conveyed by a first object to a second object. Regarding the second object the value with values of other objects is charged and computed a characteristic value for the second object. In a further example a reciprocal effect relationship represents that a first object sends under certain conditions an event message, which in the second object if necessary changes or computations auslöst.

to a second object River relations represents a transmission of information or contents from an object to a second object. Contrary to an interaction relationship thereby the kind of the influencing control possibly resulting from it is not well-known on the second object at the time of the concept. For example according to a river relationship a file is transferred, which is analyzed in the second object in accordance with given rules or algorithms and to certain activities of the second object leads if necessary. In another example according to a river relationship an event will transfer or an instruction, whereby the processing of the event and a possible reaction determine by the receiving object wird.

Difference relations represents differences between homogenous objects, which are in a different condition. A difference relationship seizes all these differences and can thereby, according to the complexity of the objects, very extensively sein.

In a preferential variant of the invention on the basis of such relations one determines, how much resources are working at full capacity and/or are reached up to which degree a given goal of the system. For example an event chain consists on the process level of different single steps or process steps. Each single step is supported by one or more elements from the element level, which is modelled by appropriate relations between processes and elements. Preferably such support relations is associated with one or more numeric values, which express for example, an how very certain element supports a certain process. By this kind of the modelling it is on the one hand assignable that sufficiently support for, and on the other hand Iässt itself an extent of utilization of the supporting elements exists one or more certain event chains bestimmen.

In a further preferential execution form of the invention different aspects of a system become, respectively models its processes and event chains, on at least two of the view levels, and relations between the objects used for it is modelled. By this kind control of the quality of the model is made possible for the modelling, i.e. by a networking of different model elements. For example it is controllable whether the model is not only syntactically correctly, but also complete and consistent over the different view levels. Results of the analyses are spent by expression or indicators to a user. Due to the spent results the model is preferably adapted iterative, i.e. corrected and/or to the reality of the modelled system nachgeführt.

The model or parts of the model is produced either manually or automatically. For the manual production a graphic editor is preferably used. With this for example objects and relations on an indicator means like a screen as surfaces respectively connecting lines are represented and with the help of a showing means like a computer mouse positioned and interconnected. Parameters of objects respectively relations for example over assigned Darstellungsund input masks are represented and changed. For the change of a parameter an appropriate text is entered, or a list or a dialogue appears for the definition of the parameter in accordance with condition from Modellelementen.

already entered when clicking an assigned screen element For the automatic production of model parts program units are preferably used into an existing data processing system, which units analyze such as processing units, data flows and call structures of the data processing system to seize automatically, and in the model corresponding objects and relations with the illustration of these units erzeugen.

In a further preferential variant of the invention to a model, whose structure admits is, parameters are determined automatically likewise through in a data processing system distributed program units and than part of the model gespeichert.

In a further execution form it permits the analysis, monitoring and controlling of a material system to the invention. In addition measured values from the system are conveyed automatically or to the model manually and up-dated and analyzed the model in accordance with different procedures. Due to the use of uniform Grundtypen and relations types these procedures, for example an automatic comparison of different models of the same system, are to different system levels and applicable in different connections. Further procedures determine for example risks, quality, performance, stability or the robustness of a system and their connections. This is done constantly via the entire model, owing to that all underlying modelling with Grundtypen. This is valid also for a modelling and an analysis by means of the pre-defined objects, which are based on the Grundtypen. The presence of rules and exceptional conditions in the Grundtypen permits to be attached a most flexible monitoring of the system, there control conditions and/or tax procedures to each object and to each relationship können.

The invention has among other things the advantage that a system structure is comprehensively representable and is objectively detectable important characteristics of a system. With traditional beginnings the system complexity leads due to networking and continuing changes to the fact that such characteristics are differently estimated and interpreted. Standardised seizing relevant Systembzw. Is practically not possible for process bases, their qualification and evaluation thereby or with very high expenditure of time and resources consumption verbunden.

The invention permits one - under certain circumstances automatic - to collection of a multiplicity of measurements and their evaluation in the context of a model, which the relevant aspects of the reality in appropriate way abbildet.

Units, expirations and procedures in the regarded system are illustrated with their parameters and set with one another in relationship and analyzed then according to the networking. By using standardised operational sequence and algorithms during the concept and their verification by comparison of different aspects of model qualitatively high-standing models result. As result of the evaluation the material system can be steered and/or the model the material system adjusted werden.

The invention is suitable in particular for the modelling of complex, multi-dimensional interlaced systems. These material existing system characteristics are detectable and can to each other in relationship brought by the different pre-defined objects such as view levels and - segments, event chains, processes, product etc. werden.

The expression ability of the modelling with at the same time uniform basis makes a comprehensive representation possible of the system in the model, those for different automatic methods of analysis usable ist.

The invention is preferably implemented in the form of one or more computer programmes. The data processing system in accordance with the invention exhibits memory means with computer programme code means stored therein which describe a computer programme, and data processing means for the execution of the computer programme, whereby the execution of the computer programme for the execution of the procedure in accordance with the invention führt.

The computer programme in accordance with the invention is loadable into an internal memory of a digital data processing unit and exhibits computer programme code means, which, if they are implemented in a digital data processing unit, this brings to the execution of the procedure according to invention. In a preferential execution form of the invention a computer programme product exhibits a computer-readable medium, a data medium, on which the Compuferprogrammcodemittel stored sind.

In a preferential execution form of the invention separate parts of the computer programme in separate computers are implemented, for example in accordance with a well-known Client/server architecture and/or using data bases distributed over a network. For the alerting and notification of control persons or users a connection to message distribution systems exists such as email, SMS (message system short), etc.

Short description of the figures in the following becomes the invention article on the basis of preferential remark examples, which are represented in the enclosed designs, more near describes. Schematically Fig show. 1 Grundtypen; Fig. 2 Fig. 3 Fig. 4 Fig.

Fig. 6 Fig. 7 Fig. 8 Fig. 9 Fig.

Fig. 11 Fig. 12 Fig. 13 Fig. 14 Fig.

Fig. 16 a fragmentation of an object in Grundtypen; a processing concept; a processing concept, divided in Subprozesse; Event chains by processes and with support by elements; a summary presentation; a simple example with pre-defined objects “process” and “external representative”; a representation of a process by activities; a pre-defined object “activity” in an activity diagram; a pre-defined object “medium”; a pre-defined object “event chain”; View levels to the validation and quality control; an example of a model validation; Support relations and post distribution; different kinds of cost allocation; and a Modellvergleich.

Same or constituted parts with same reference symbols are fundamental versehen.

in the figures Ways to the execution of the invention in the consequence are described first in accordance with the invention used information and structures, and afterwards Verfahren.

based on it A system consists of a quantity of cooperating units, whose behavior is to be copied, examined and modified as a whole. Preferably a system is a technical plant, a machine, a production process or a working process, whereby a system can contain also several of these aspects. A production process serves for example a production of physical products, or energy. As more fundamentally “kit” for the modelling a quantity of Grundtypen serves:

Grundtypen Fig. 1 points schematically Grundtypen, some canon for the concept to the representation of a system bilden.

The Grundtypen designation with:

1, 2.

3.

4.

5.

“Producing” or “Sourceù, with no entrance and an exit; “Passing on” or “Straight”, with an entrance and an exit; “Merging” or “Merge”, with two entrances and an exit; “Dividing” or “Split”, with one entrance and two exits; and “keeping” or “net curtain”, with an entrance and a Ausgang.

In principle the Grundtypen “Erzeugenund “are pass on representable keep by the Grundtyp “, so that three Grundtypen are sufficient for modelling. The two additional Grundtypen are for a simpler representation zweckmässig.

The mentioned entrances and exits correspond to an assumption respectively a delivery of data. In particular an entrance and an exit can a simple event respectively causes or “triggers” be, and/or contents or a “content” carry. The entrances and exits are linked with the structure of a model with those by other Grundtypen. Thus nets of arbitrary kind and complexity are picturable from Grundtypen. Grundtypen point a condition to (how “”, “in use”, “deleted”, “suspended”, “sold”, etc. “works on”), which change can, attributes, which define characteristics of a Grundtyps, as well as - functions or “Descriptions”, which describe a sequential behavior of the Grundtyps as prozessualen operational sequence; - Preconditions or “Preconditions” for the description of a starting situation, which must be present, so that the behavior is releasable respectable the function of the Grundtyps; and - Nachbedingungen or “post office conditions” for the description of a final situation, which after running off an appropriate behavior respectively a function of the Grundtyps herrscht.

Implemented during the expiration of a function for example rules or “Rules” and mathematical operations, which describe a behavior, and will become conditions, which correspond to given exceptional conditions or “exception”, particularly behandelt.

Exemplarily in the following kind a working process is described. An action regulation for example a press control is expressed in similar way and in a suitable syntax programmiert.

Precondition: A registration meets via telephone, fax, email ein.

Functions:

All registrations become into a standard form eingetragen.

The registrations become registriert.

The individual invitations become aufgearbeitet.

The list of subscribers becomes vervollständigt.

The invitations become the dispatch aufbereitet.

Nachbedingungen: E-MaiI-invitations, Papier-Einladungen.

Rules: too the registration concerns a member: to the invitation calculation over Fr. 50. - beilegen.

The registration does not concern a member: to the invitation calculation over Fr. 250. - beilegen.

The registration concerns VIP: to the invitation no calculation beilegen.

Exceptional condition: too the address is incomplete: a telephone further inquiry is accomplished and the address vervollständigt.

The different Grundtypen are characterized as follows:

The Grundtyp producing or “SOURCE” produced based on an event certain contents and puts these at its exit to another Grundtyp at the disposal. The Grundtyp logs its actions by means of a Gedächnisoder minutes function. He knows thereby later, he produced which contents due to which event and for which time. The event for activating an exit respectively for producing contents must come not compellingly from the outside, but becomes for example by an internal Zeitauslöser generiert.

The Grundtyp passing on or “Straight” places contents, which it received at the entrance with or without change in its exit another Grundtyp for the order. The Grundtyp always knows, which contents of it at which time passed on hat.

The Grundtyp merging or “Merge” combines contents, which it received at its two entrances, and produces in accordance with its rules new contents. This contents makes it at its exit other Grundtypen available. The Grundtyp always knows, which contents of it at which time as united hat.

The Grundtyp dividing or “Split” divides contents, which it at the entrance receive, has and produced in accordance with its rules new contents. These contents makes it at its exits other Grundtypen available. The Grundtyp always knows, which contents of it at which time as divided hat.

The Grundtyp keeping or “net curtain” stores contents, which it receives at the entrance, and can at its exit for other Grundtypen an appropriate event available make. The event contained for example the information “information of the type X was kept stored at the time Y” or only one counter “it so far a number of Z mark the information X”. The Grundtyp always knows, which contents of it at which time stored hat.

As example of Grundtypen for example a representation of processes is in Fig. 7, of activities in Fig. 9 and of event chains in Fig. 13 shown and further down beschrieben.

Objects to the representation of a more complex behavior are linked several Grundtypen over their Einund of exits and regarded the quantity of these linked Grundtypen than unit. Such a combination of Grundtypen is called object. Einund of exits of a subset of the Grundtypen are also a respectively exits of the object, during that other Einund of exits within the object remain. Preferably those is limited variety by such objects, as a limited number of pre-defined objects with fixer of internal structure and according to reduced, but behavior proven for it is used, those combinably again with one another sind.

Fig. an education of an object 1 from a quantity of 2 of several Grundtypen shows 2. At interfaces 3 of the object appropriate interfaces 4 of the Grundtypen visibly, remaining interfaces of the Grundtypen remain hidden in the object. Preconditions for the object are equal to the preconditions of that Grundtyps, whose entrance forms the entrance of the object. Nachbedingungen for the two exits of the object are equal to the Nachbedingungen of the appropriate Grundtypen, whose exits form the exits of the object. Rules of the object are a logically derivable combination of rules of the Grundtypen. A structure rules of the object given by Grundtypen and rules of these Grundtypen can turned around be deduced automatically from. In place of the Grundtypen lying outside of the object naturally different objects can like external representatives treten.

Will an object too complex, in order to be able to be represented on only one level by Grundtypen efficiently, then it can be divided into objects, which consist again recursively of objects or Grundtypen. By this allocation, which is not limited in the depth, also very complex connections transparency can represented werden.

In accordance with generally well-known principles of object-oriented programming and modelling special objects are defined and used. Everyone such object inherits and the further general object characteristics presented so far and exhibits beyond that specific characteristics. It uses thus a part or all definitions of a general object. Further general object characteristics are attributes or functions for - the storage of changes of the object; - Collection and integration the material process modelled by data from; - Representation of notes, work instructions, collecting mains, check lists and/or evaluations, which concern the object; - Representation of a contentwise quality of the object, for example results of automatic analyses of the completeness and consistency of the Objektbeschreibung.

- to the representation of risk, measurement, costs, cost category, Metriken etc.

Each of these definitions represents an object, which designs from the basic types wurde.

in itself For example the Grundtypen are usable in the following way in the object “risk”:

Grundtyp merging: for each relation of another risk the Grundtyp records an appropriate dependence, receives contentwise information from this other risk and determines from it for example a modified Risiko.

Grundtyp dividing: for each relation to another object, which possesses a risk, the Grundtyp records a dependence and leads appropriate contentwise information to this other object respectively at its risk object weiter.

Grundtyp passing on or producing: for each attribute the Grundtyp represents an attribute characteristic like a tendency, a current value, a probability, a weighting, costs, etc. Usually a Grundtyp per attribute will be used, will not be evaluated independently except if several attributes in an analysis müssen.

The Grundtyp can notice also the function of an early warning system or a monitor, which could interest a value by means of his rules and/or exceptional conditions supervised and a value or a signal determined, which is needed for the description of a risk, other risks or with an automatic analysis evaluated wird.

A kind of reciprocal effect effect, which expresses a mutual influence or a I nterdependenz, belonging to the risk, is modelled by the Grundtyp passing on or producing. Thus a direction and a strength of the effect of a changed risk become toward another object modelliert.

View levels the model respectively the modelled system preferably on several levels one regards, on which the pre-defined objects are: The system is called in particular in three view levels, process level, element level, and Informationsund function level, unterteilt.

The process level forms a highest abstraction, which represents tasks and expirations as well as their connections among themselves and to partner systems. The element level represents the support of the processes by technical and/or organizational units respectively elements. Thus on this level the entire infrastructure and organization of the system are illustrated. On the third and at the same time lowest level, Informationsund function level, functions and information of the individual elements in the detail become repräsentiert.

For example an event chain “coworker introduction” is modelled in an administrative system. The event chain goes through during a process “personnel administration” a step respectively an activity “coworker introduction discussion”, which a data acquisition contains. On the process level, which concerns this step, it is only represented that discussion minutes are provided. On the element level the event chain is likewise descriptive, however with reference to used elements, in this case software applications. This description means for example that discussion minutes with a text processing software provide X, in a data base system Y is stored and with a Mailsysteem Z at certain persons conveyed. A representation the same event chain on Informationsund function level describes a type of file and a given internal structure of discussion minutes, as well as rules for the naming and file of the Datei.

In another example a process “printer plant” is defined. In a material printing plant different printing stations, Falzund cutters are combinable with one another in different kinds. Individual concrete printing order “luck post office manufacture” corresponds to a certain configuration of the plant and a certain paper river by the plant and by an event chain one represents. The concrete printing order stresses completely determined individual machines, which are represented by elements. A certain machine again is controlled in accordance with condition by machine parameters and rule functions, which models on Informationsund function level werden.

In a further example a product component one model. On process level it is modelled for example by an object as product “component supply”, on the element level by an object as product “Autotüre left”, and on Informationsund function level an appropriate object holds, where and how data for the description of the Autotüre stored sind.

The connections between the individual levels, thus circumstances that a process or an event chain is supported by certain individual machines it is modelled, and that these information and functions again determined need, by support relations. Thus for example control parameters of a machine are associated over the machine with a printing order. Thus control parameters for individual printing orders can be individually specified. Accordingly can be determined, on the basis of for example a process view, by pursuing the relations, which concrete parameter are and can these are changed. This results in one “twisting down” - functionality, i.e. that if necessary, from a general summary presentation outgoing, on information of the system at will detailed are accessed kann.

View segments Orthogonal to the view levels are defined view segments. These are called “leadership level”, “creation of value level” and “support level”. Each of these segments knows objects of the process level, element level and Informationsund function level enthalten.

The creation of value level contains processes, elements etc., which contribute to the creation of value of an organization or a plant, thus directly in the production or treatment of a product is involved. These are thus production roads, machines, outer service departments etc. with assigned processes, data and Verfahren.

The support level contains processes, elements etc., which serve for the support of the expirations on Wertschöpfungsund leadership level. These belong for example to a computer science department, to a personnel administration, an automatic warehouse, a raw material procurement etc.

The leadership level contains processes, elements etc., which serve support level for the guidance Wertschöpfungsund. These are in particular management functions such as management, Controlling with appropriate organizations, computer science means etc.

By the allocation into these view segments and by the allocation of costs and support degrees Iässt determine themselves, which units into which degrees and at which expenditure to a product and if necessary a profit beitragen.

Fig. a representation of a system with model elements shows 3 to a highest modelling level or abstraction level, for example on the process level. Individual processes P1… P6 on the three levels are represented like also the relations between the individual processes. With EA1… EA6 are characteristic so-called “external representatives”. The processes P1, P2 lie in the leadership level, the processes P3, P4 and P5 in the creation of value level and the process P6 in the support level. In the following processes and external representatives are described:

Processes a process is a recapitulatory representation of a defined whole of tasks and activities or expirations and decisions. A process has certain characteristics and a behavior and exhibits a number of basic types, which are combined individually to an object. A process can be divided in Subprozesse. A process is always a component of a processing concept and forms on everyone of the three view levels a highest abstraction step for the description of the view levels. A process receives to inputs respectively data from other object types such as processes or external representatives and produces outputs respectively data for such Objekttypen.

This input and output form a characterisation of the process and from quality, performance and auxiliary use (< , Added VALUE”) of the process. Each process exhibits attributes for the description of costs, risks, measuring characteristic numbers, use, quality, instructions, empirical values etc. To it such information is alternative by special in each case description objects in place of attributes beschrieben.

A description of the data, i.e. inputs and outputs of the process exchanged by a process, becomes as “service level Agreement” (SLA) or process interface description designated. The SLA is a medium, that between two pre-defined objects is transported and thus the description of an interface corresponds and these definiert.

Relations of a process with other Modellentitäten describes for example mutual dependence on risks, costs, demand or support, as well as connections with a project, an event chain, planning objectives etc.

For semantic and syntactically correct and complete description of a process a pre-defined object activity is preferably used. Also an activity is an extended instance of a general object, with a subset of the general object characteristics and with specific characteristics. One or more activities are assigned to a process…

On the right side of the Fig. such a description is represented to 8 by means of an activity diagram exemplarily with different types by activities sequence, single step, allocation, bypass. The representation describes, in from the computer technology well-known way, an expiration or supervisory data flow within a process or a Ereigniskette.

External representatives an object lies outside of a view framework respectively outside of a certain processing concept, then this object “external representative” or also partner object or Fremdkomponente is called. An external representative is like a process an instance of an object with general as well as specific characteristics and behavior. If a process is divided and divided thus into Subprozesse, then thereby new, out external representatives seen by the point of view of the Subprozesses develop. A such dismantling 5 is in Fig. 3 makes smaller shown and in the Fig. 4 increases represented: P3 is divided in P3.1 to P3.4, and from the processes P2, P4 and P6, those on the higher level in accordance with the opinion of Fig. 3 still processes was, from view of the Subprozesse of P3 external agents developed. External agents know thus depending upon context other pre-defined objects repräsentieren.

In a further use of external agents an external agent in a first model represents complete a different one, second model. This meant, it combines all characteristics and behavior of a model. The external agent can be thus a representative for many different objects or object quantities. For example:

- An external agent “market” places a substitute symbol for a far not modelled Entität dar.

- An external agent “partner” represents a modelled process, by which the “partner” transferred a role by outsourcing and directly to a process chain merged wird.

- &lt an external agent; , Department” corresponds to a complete part of an overall system, that in a certain connection not in the detail interessiert.

The external agent afterwards normally becomes as a representative by means of river relationship with an object within a model border verbunden.

Event chain an event chain represents a recurring course of action within the system. Depending upon context event chains become also as business transaction, when “Use Case” designates, as added value chain or as “Businesses VALUE chain”.

The individual steps in an event chain are tasks and process steps, which run off in an order and with certain developments. A data flow of a business transaction always describes, from where and where certain information flows. Apart from the fundamental object definitions an object event chain possesses the characteristic that it represents an edge and not a knot of a network. Along this edge or chain for example a product is processed or manufactured. Generally regarded, an increase in value develops along an event chain. For the representation of changes running off thereby the event chain is divided into partial rivers or substrings, in accordance with which individual products or media are manipulated. The individual partial rivers are assigned to processes and/or activities. The event chain is by means of activities representably respectively definierbar.

Summarized said a process represents a part of a system, which is capable of different actions in general way, to during that an event chain or an activity uniquely implemented actions related to a concrete incident darstellen.

In the Fig. 5 is overlaid represented several aspects of model: Processes are by ovals, activities by horizontal rounded off rectangles, and event chains by thick arrows symbolizes. Vertical rounded off rectangles represent elements, those further down explained werden.

Fig. 5 shows thus two event chains, whose always correlate individual partial rivers with a process or with an activity within a process. Thereby also several partial rivers of a chain the same process or the same activity can be assigned. Elements can support several processes, and a process can be supported by several elements. This corresponds to circumstances that for example a manufacturing cell for several production processes can be used, in reverse and. , Like certain partial rivers of an event chain completely within a process runs off and other one only connections between processes continues to be visible repräsentieren.

Element level a further special pre-defined object represents the element. An element represents, how a process or an activity is supported by material Entitäten, preferably four types by elements is used: 1. Information technology (IT), 2nd organization, 3rd tools, and 4th mechanical-electronic Module.

In the Fig. 5 this support is represented by processes and activities by one or more elements (vertical rounded off rectangles). Indirectly thus also an event chain is indirectly supported by one or more elements. The event chain on the process level and that do not have to be on the element level equivalent subdivided and not have also the same media thereby to be used. Substantial it is however that all the mentioned objects in a defined relationship to each other, i.e. that by appropriate relations is represented that a certain event chain consists of certain activities and this is assigned to processes and elements again determined…

Informationsund function level Informationsund function level models units, which support the elements. These are in particular information-technical units such as data and procedures, both data, which illustrate the reality in the system, and Metainformation over these data. Data are for example values of in data bases or programs stored attributes or variables, as well as measured values and control parameters of plants and Maschinen.

Metainformationen describe a meaning from data, data structures, data base structures, file information, logical connections or computation regulations to the transformation of data. Procedures describe procedures or programs for the data processing and/or Maschinensteuerung.

Relations types Grundtypen and objects are set among themselves in relationship. Used relations types define a behavior of two objects in relationship respectively Grundtypen. Relations types are modelled also as objects. Thereby four relations types are differentiated which are described in detail afterwards:

a) b) c) d) if two objects stand continuously in relationship, then the type of relations steady or “permanent” is used for the description. This relationship corresponds to a mutual reference gleichzusetzen.

If an object releases a reaction with another object, then the type of relations reciprocal effect is used or “lnteraction”. Hereby defined effects can with another object obtained werden.

For the representation of a dynamic situation the type of relations river or “flow is used. Hereby it is represented that not only an effect, but also contents between objects in a certain condition shifted werden.

With a connection of two objects if a respective functionality of these objects is set to each other in relationship, then the type of relations becomes difference or “Gap” definiert.

The type of relations “steady”:

Two steady relations types are differentiated, one statischeund a Umwandlungsbeziehung.

A static relationship or “Static” places a constant mutual relationship between two objects dar.

For example a mutual reference of two objects is represented by a static relationship. In both objects pointers are more navigatable left instanziert on the other object for example than and linked for example with the name of the other object. This same kind relationship is also used, if an object with another object in a static correlation &lt or; , Correlation” stands and this fact to be pointed out steadily soll.

The transformation relationship or “Exchange” represents a relationship between two different pre-defined objects, which follows firm rules, in accordance with for example a type transformation. It thereby an object converted into one or more objects of another pre-defined type. In which relationship and under application of which rules the objects to each other stand, held in the respective objects concerned. Over this relationship can be navigated after the Instanzierung, and the objects in relationship know the kind of the transformation as well as the details in each case of the different Objekts.

For example transformation relations represents that a certain process exhibits several certain activities. A process “manufacturing” points for example a quantity of activities like “product A manufactures”, to “intermediate product constituted” etc. up. These again are assigned to one or more event chains in each case, which is likewise represented by transformation relations. A process “personnel administration” points for example to activities “coworkers adjusts”, “judging”, “dismissing”.

Other transformation relations represents for example a connection between a product and between service achievements, those than product considerationable sind.

The type of relations “reciprocal effect”:

During a reciprocal effect relationship an object exerts influence on another in any form or stands in a dependence on this. However its own river of contents between these objects does not develop, but the relationship describes a certain, well-known kind of the influencing control. An object exerts an influence on the other one due to its characteristics and his behavior. Preferably five different kinds are differentiated from reciprocal effect:

A kind of reciprocal effect influence or “Influence” represents a proportional dependence between two objects, in particular a proportional distribution key or dependence key. For example an influence relationship holds that a certain Leistungsoder a production goal is assigned like “less as 2% committee” or “less than 5% fluctuation” to a process, for example the “Fertigungsabteilung”. The allocation is done via for example a strategy object. A strategy object distributes thus goals to other objects, for later control of the Zielerreichung.

A kind of reciprocal effect support or “support” represents a proportional dependence or a distributor with given rules and definitions between characteristics of two objects. This type of relations is particularly interesting, if pre-defined itself objects on different view levels befinden.

Then a more or less strong dependence or coupling of the levels is representable or visible. For example support relations represents that 60% of totally available computer science means or - services and 50% of the work of a manager for the support of a certain production department are necessary. In another example they represent that a manufacturing process 30% of a numerical control machine and 40% of a certain manufacturing cell benötigt.

A kind of reciprocal effect effect or “Effect” represents an effect by releasing a reaction based on firm rules and definitions. A procedure or an algorithm for the determination of the reaction is defined in the object, in which the effect takes place. The effect unconditionally takes place, the reaction depending upon result of this procedure. For example a first object affects by switching of values for risk, performance, costs, quality, degree of completion etc. second. The second object determines a total risk or a process risk in accordance with it own procedures for example etc.

The relationship is one-sided, in the sense that the effect takes place only in an object and the releasing object is not affected. Therefore a second relationship in opposite direction must instanziert werden.

for the modelling of a mutual effect A kind of reciprocal effect change or “CHANGE” represents an effect, with which a change takes place after free or firmly definable rules. An object knows, which conveys a message, not whether and how this message is processed with the receiving object. The kind of the message (” measuring data”, “error parameter” etc.) is however in advance well-known. For example with this kind of reciprocal effect are represented:

- a transmission of measured values to an automatic controller; - after releasing a production order for a product several Fertigungseinheiten concerned are knocked against; - an optical error recognition respectively the assigned model object conveys error data to a production line, depending upon error parts worked over again, if too many errors arise, a machine concerned is adjusted; - a number of discouraged coworkers is conveyed. If a certain portion of cooperating is discouraged, Stelleninserate are released; - sent during attitude of a new coworker appropriate change information to different objects, which produce on it a place profile for example automatically, an email account to furnish to arrange an entrance discussion etc.

A kind of reciprocal effect connecting or “Join” represents a switching of goals or capability characteristics such as risk, costs and different measurable sizes. The goals are broken down several objects subordinated by a superordinate object by means of this kind of reciprocal effect on or distributed, are called each everyone subordinated objects receive their own partial goal of fulfilling it have and for evaluation with actual results usable ist.

The type of relations “river”:

Up to now only static relationship were defined, over which dependence or computations to be provided to be able. The kind of the relationship and the obtained information was always in advance well-known. The following two definitions define dependence, with which a river is to be represented, whereby the substantial difference to the past one lies in the fact that between two pre-defined objects contents are shifted, whose processing can release something unexpected. This contents correspond again to a pre-defined object. By means of these river relations dynamic and contentwise dependence leave themselves darstellen.

A kind of dependence contents or “content” represents a contentwise relationship between two pre-defined objects, whereby conveyed contents, for example, release a file depending upon interpretation by the receiving object a reaction. The contents relationship places thus a dynamic connection on different detailing levels dar.

With a kind of dependence contents represent event or “Event” only one cause. Contrary to an interrelation however contents are defined by the receiving object and vorgegeben.

The type of relations “difference”:

A difference relationship represents differences between two pre-defined objects and makes it comprehensible. For example the two objects represent an actual condition and a specified condition of a system, the difference relationship the differences between the two Zuständen.

As overview is indicated in the following for the different relations types, between which objects they are preferably used. Important relations types are in particular the static relationship, influence relationship and Inhaltsbeziehung.

Type of relations steady - static - transformation reciprocal effect - influence - support - effect - change - connecting river - contents - event difference took part objects all types process - activity, element - interface, interface - service, service - parameter strategy - object, requirement - object process - element, process - event chain, activity - event chain interdependence risk, personnel, costs, other target - Risk, target - Measurement risk, measurement, binding process-external agent, process process, event chain object; if contents are transported process - external agent, process - process, event chain - object; if only cause is defined all types, over Compare & Merge - connections product it are differentiated between three kinds from products, which can take all one or more conditions: A product even, as highest abstraction, as well as a medium and a result. The medium represents all kinds of contents, which are used in connection with the enterprise development and processing. The medium represents also the smallest unit of a product. Media can occur and be able in an isolated manner or in different other combinations in different levels and develop different combinations. A medium can be thus for example a physical part of a product, in addition, a computer-readable file respectively the information contained in it. A quantity of media defines a Elementarprodukt.

The elementary product can be combined with other elementary products to (compound) a product or a “Composite Product”. An object “product” represents a recapitulatory and/or changing view on several media. For example this is the fact the fact that an article consists of a quantity of components respectively is manufactured, or that a chemical processing of entrance materials results in a basic material, or that a list over Hardund regards software costs on another view level than overhead costs and again another level than investments werden.

The objects defined so far are located to summary to each other in a model in different dependence. These dependence are in the Fig. 6 in an overview for an exemplary model represented. A processing concept consists of processes P1-P6, which are connected by means of river relations. If a relationship exists beyond the model border, this takes place to an external representative EA1-EA6. Over these relations media or products flow in a defined condition. All these objects can be described divided (process in Subprozess) or by means of another type of object (process by activity), which by appropriate relations representably ist.

The processes P1-P6, external representative EA1-EA6 as well as activities are supported by elements of a pre-defined type. With processing concepts tasks and expirations as well as connections are characterized, with the element model Infrastrukturund organizational support, and with Informationsund function model specific details. These three models form at the same time also view levels. A three-dimensional representation 9 visualizes the presence of view segments and view levels, in order to document concrete applications and their value movements, can event chains 6 on stage process, activity or on stage element be defined. The individual partial rivers of the event chain 6 with the appropriate objects a certain view level connected respectively in relationship are brought. The pre-defined object event chain represents thus specific operational sequence and can on all view levels be used. It is represented in the detail for example by an activity diagram 7. Activity diagrams are usable also for the representation of expirations 8 within processes. Event chains form additionally to the models an additional dimension and link objects and levels. Thus different analyses and computations are simplified or made possible at all. Furthermore the product model is used and the project model, which all changes between two times abbildet.

The modelling principles are represented in the following on the basis a very simple example:

Fig. 7 pre-defined objects of external representatives I/O and processes Pa, PB, as well as arrows represented arranged relations, shows and Arbeitsmitte110, which are relevant for the definition of the relations. Furthermore a use of the Grundtypen is in a more detailed representation of the external representative I/O and in the processes Pa, PB abgebildet.

Dependent on the Instanzierung and the characteristics is larger or smaller the complexity. This is expressed in the external representative I/O by the use of only straight two Grundtypen. If a certain measure of complexity was exceeded, then different pre-defined objects became verwendet.

in place of these Grundtypen In the Fig. 8 process PB is defined alternatively to the representation by Grundtypen by an activity diagram. Since it concerns with activities again pre-defined objects, they exhibit also a defined quantity of Grundtypen, respectively are expressed by these. Fig. an increased version of the activity diagram, with bypasses, shows 9 parallel paths, sequences etc. and exemplarily a representation of individual activity by a quantity of Grundtypen.

In the Fig. 10 is in detail represented the media 10, which are shifted over the relations. A product 10 respectively a medium 10 can again of several other media 11 consist, which over an appropriate object-oriented software definition is representable. From this illustration it is likewise evident that the media at the same time on the one side the outputs and on the other side the input of processes darstellen.

Up to this point in the example still no concrete applications were defined, but only the whole system, which exhibits a potential for the treatment of applications. With event chains concrete applications are represented, which can to arise in practice and stress a smaller or larger part of the system. In the Fig. such a event chain is represented 11 by broken arrows. From this it is evident that often only one part of the system definition, thus for example the processes and activities, in a certain event chain use findet.

Based in the imported model elements and - are connected due to the pre-defined objects can in the following the descriptive further procedures, analyses and computations be accomplished. It thereby in the following in detail up automatic generation of model and - up dating; - Quality inspection of models; - Risk analyses - analysis of costs and their relations; - Performance evaluation; - Comparison by models respectively represented systems; - Process price increase; and - Benutzerschnittstellen.

Manual and automatic concept around a concrete system, thus a production system or an enterprise or an organization to represent will become different information raised and as instance values of pre-defined objects illustrated and connections of the objects likewise in the model represented. This information collection happens manually and/or automatisch.

During the manual collection icons, which represent the objects, are preferably placed by well-known showing means like a computer mouse on a screen. Relations is entered by connecting the icons. For specification respectively Instanzierung of attributes are for example to each object input masks representable, which text fields, menu lists and other well-known input aids exhibit. In a preferential execution form of the invention objects in a tree structure are represented and manipuliert.

Preferably thereby one proceeds as follows: When first processing concepts become provided, afterwards event chains are put on the process level and specified these chains by activities. In similar way also the specification of the process control rivers is provided. Parallel to these process work also product definitions are provided. The product definitions become special with relations between two objects verwendet.

If the process level is completed, the element level is created. The necessary element types are produced and into correct dependence for the processes and to each other gestellt.

With these steps a concrete element model is produced. The individual elements are linked afterwards with the objects on the process level. The event chains on the element level become subsequently, erfasst.

As last level Informationsund is created function level and described by means of special pre-defined objects. These objects are preferably special to the representation of computer science bases respectively data and descriptions of function aligned. They describe thus for example data structures, access relations, single data and their meaning, interfaces etc.

The automatic collection effected via special analyzers, which scan an existing information-processing structure or plant, connections between dataprocessing and/or datastoring units determine and different kinds from objects and relations to the illustration of these data and connections in the model provide. In a preferential variant of the invention thereby the following procedure is used: A computer science landscape or a software system wise several processing units, i.e. programs and/or data bases up, whereby through calls with one another and the data bases links the programs sind.

The procedure reads systematically the code of all programs, for example a COBOL source code, and holds in each program, which other programs with which Ubergabeparametern and which results are called. Likewise one holds, which data bases and if necessary which tables of the data bases with which inquiries and results one accesses. Likewise internal linkages of the data bases become erfasst.

The procedure is applied recursively to each program and each data base, until all went through and so that all existing linkages through calls respectively inquiries are seized. During the collection in a model objects are produced automatically for the representation of the programs, data bases and linkages found in each case. But the pre-defined objects element, interface and work product are preferably used. Depending upon type of object the scanner one configures and fills up all objects and relations between the objects in accordance with definition. For example a material program and a data base are represented ever by objects, data base inquiries by relations types, and results of data base inquiries by Arbeitsprodukte.

The found elements and linkages define a graph. This is represented visually, for example as graph with knots and edges, or as linkage matrix. Thus a descriptive representation of dependence, in particular critical components of the computer science system develops recognizes Iässt. Such are for example a data base or a table, which by a large number of other programs one accesses. A change of an interface to such a component would cause thus a larger expenditure. Also little or not at all used components is turned around ermittelt.

Model parts are alternatively producible in addition also from data of well-known management tools. Such data are read from data bases or export files and produced by Konversionsprogramme automatically objects for the representation of the relevant model parts. Model information turned around for use and/or visual representation in other programs leave themselves exportieren.

The modelling procedures regarded above concern primarily a modelling of structures and in second line also a collection of model parameters respectively from attributes of objects, which are embedded into these structures. If a structure is essentially well-known, then parameter can be determined automatically. In addition several physical sensors, or however aid programmes, which serve for the extraction of data from a current system, are used. In the following also these aid programmes are called sensors. From sensors seized values originate thus from material components of the system and cause an alignment of the model with the system material running off. The values are supplied to appropriate objects in the model, which these components model. In accordance with objektund the user specific rules contained in the model the values are processed, for example by storage in the object, Aufdatierung of the model with current values or by statistic analyses of the values, regulation or controlling of the system, etc.

During the concept an interface engine, which realizes a pattern for the object production, becomes an object production engine with instructions the object manipulation angesteuert.

in a preferential variant of the invention over By an experienced user can be accessed also directly the object production engine. The object production engine accesses a Framework, which sets the Grundtypen with the pre-defined objects in relationship, and produces respectively instanziert the necessary objects, linkages between their Einund exits, and further relations between the Objekten.

Model verification, quality inspection after a model was partly or completely created, is examined it by different analyses for the correct use of individual objects and their relations. This happens for example with the following examination procedures, which are called in summary also examinations of the model quality:

A model examination checks whether an external agent, a process, a work product and a process interface description were defined, and whether the objects stand in accordance with their definitions correctly and completely with other objects in relationship, whether no open relations is defined and whether in an undefined condition does not use objects werden.

A check for completeness checks whether a process is supported correctly by elements and activities and whether a process in an event chain uses wird.

A Konsistenzprüfung on object level checks whether an object is not unused and complete without relations by references or river relations, whether it not-existing objects referenziert.

A transparency examination checks whether objects exhibit a goal and a description. This corresponds concretely for example to an examination, whether certain text fields of a mask were filled out for description of object, thus contents aufweisen.

A quality definition examination checks whether quality specifications are defined by means of a Metrik to individual objects. Only if these are present, is a later evaluation of a quality of a process or an event chain etc.

possible. This corresponds for example to an examination concretely whether quality specifications exhibit containing fields of a mask for description of object contents, and this contents certain conventions correspond if necessary. During the assessment of quality with use of Metriken connections, relations and contents are verified and by means of statements to the quality quantifiziert.

The quality specifications and quality criteria of objects are to differentiate of the examination of the quality of the model regarded here! Warnings are produced, if a process only an entering or only a withdrawing river aufweist.

The mentioned analyses can through Plug in and with application of user specific rules extended werden.

The examinations of the model quality specified so far concern thus consistency, correctness and completeness of the Modells.

A large Konsistenzprüfung is accomplished, as it is determined whether different aspects of model of the same circumstances or aspect of the reality agree with one another. If the same object in two different models with different degree of detail or with different view is thus used on application, a statement can be made the correctness. In particular event chains with process interface descriptions become verglichen.

Fig. schematically a basis for validation procedures shows 12. Under validating examining conditions, expirations and models becomes by means of at least further model or another aspect of model verstanden.

Partial models on process level 13, element or support level 14 and on Informations-und function level 15, as well as event chains BVC and models of external agents of 12 on everyone these levels and product definitions 16 illustrate different in each case aspects of the system in the model. These partial models overlap each other within certain ranges and must be consistent, if the model should be correct, in these ranges. If thus for example the event chains respectively business transactions with the processing concept and their definition to be compared, a statement can be made the quality of the processing concept and the business transaction models. The classification of the quality can on the one hand as characteristic number or by means of detailed information over contradictions and Ubereinstimmungen erfolgen.

Fig. a concrete example illustrates 13. In a top of the figure two processes P1, P2 and an external representative EA1 are represented. Between P1 and EA1 as well as between P2 and EA1 are process interface descriptions definiert.

These describe, which media are shifted over the respective interface. In a technical system these are for example products, individual parts, manufacturing parameter, order data, tax on machinery data, results of measurement etc. during an administrative process are this for example products, receipts, payments, orders etc.

In a lower part of the Fig. an event chain is represented 13, which goes through the mentioned processes P1, P2 and the external representative EA1. The event chain is defined preferably separately by the process interface descriptions. It describes a systematic lining up of events and actions, as well as a shifting of media respectively products. The quality inspection has to the basis that each input and each output of a process are produced in the context of a business transaction. In one in the Fig. 13 represented matrix becomes lines according to processes, which deliver media (outputs) designation, and columns according to the same processes, but as receivers of media (inputs). In the fields of the matrix any media are registered, which are on the other hand shifted by a process. Thus one receives a Ubersicht over all interfaces between objects. The same matrix is used, in order to register on the media which are used by a business transaction. Now it can be stated, whether a cover is present, i.e. that a work product in both definitions arises. With a medium, which does not exhibit Uberdeckung, either the process definition or the definition of the business transaction is incomplete. In the example matrix work products, which were used only in the process interface description, in normal script, those, are which were used only in an event chain, in italic writing, and in fat writing that one, those in both descriptions auftreten.

In the Fig. furthermore 13 is to be represented, like media produced (“Create”) and stored (“net curtain”) and events be conveyed (“send Event).

The same principle is used also for other pre-defined objects and other kinds by connections:

Preferably thereby the consistency is examined by descriptions of an event chain for different view levels. For example an event chain on stage process and the same event chain on stage element are compared with one another. During this view, with consideration that processes and their supporting element are connected by relations, it can be made a validation and a quality statement about objects on different levels. This contrary to Fig. 13, where only one level, but a description by means of two different objects vorliegt.

Preferably for it, where a second interface between objects on a second modelling level is assigned to a first interface between objects on a first modelling level it is examined, for the formation of a consistency statement whether a medium, which are handed over over the first interface and a medium, which are handed over over the second interface are each other assigned respectively each other correspond. For several interfaces, which belong to respective event chains on the two modelling levels, will similarly proceed: thus the interfaces in both modelling levels become over the whole event chain away with one another verglichen.

Risk analysis for the computation and publicising risks are valid the following principles: In principle each object a risk object can be assigned. In particular this is appropriately for processes, elements, medium, event chains a risk object points among other things to a numeric representation of a risk of the object, as well as rules or computation regulations for the determination of the risk on the basis of risks and of other attributes of other objects, in particular from measured values from sizes of the system. The risk is a measure for the probability the fact that the object concerned its function not fulfilled or that did not determine its characteristics correctly sind.

The risk is represented for example on a scale between 0 and 100. For diagram different colors (green/yellow/red) are assigned to individual ranges of this scale and, to the objects are assigned, in tables, matrix representations or diagrams a user or a system supervisor dargestellt.

Rules for risk computation are for example in textueller form with usual syntax expressed, e.g. in the sense of IF “risk of process A” > 60 AND “committee of manufacturing cell X” > 10% THEN “risk of interruption of the total manufacturing around 10%” rules increase for action due to risks express for example that with the exceeding of certain risk threshold values messages are sent away automatically via emails or SMS (Short Message system), alarms are released or in a production control are intervened. The latter is done for example with deactivation of a machine or via adjustment of control parameters, so that slower, but with better quality one works. It is appropriate that the risks accordingly of current measured values from the system computed and constantly updates werden.

For each object also different risks are definable. For each risk a description and describing attributes become preferably such as probability of entrance, a tendency, an early warning indicator, Nettound gross risk, costs, one or more actions the prevention of the risk etc. definiert.

If one wants to count the risk along a chain, for example along an event chain, then the largest risk determined along the chain is considered as the risk of the whole chain, if the mutual influence of the risks is always positive and taken place in the river direction. If further risks than measured variables affect a chain, on the risk effect and the direction, the risk value becomes dependent ermittelt.

In a preferential execution form of the invention with a Monte Carlo simulation a variation is played to the end and determined by risks and their dependence, which objects are particularly susceptible or sensitiv. In another automatic analysis when being present loops in the risk computation by several objects it is detected whether the risks up swings, into extreme values to run oneself, or itself stabilisieren.

Relations analysis Fig. 14 shows simplifies different objects of a model, which stand in relationship among themselves. Event chains respectively business transactions BVC1-BVC4 on the process level go through processes P1-P3, whereby individual business transactions can jump over also individual processes. On the element level the event chain BVC5, and the event chain BVC4 the event chain BVC6 corresponds to the event chains BVCl-BVC3. The processes P1-P3 supported by elements El-E4. These support relations becomes in the Fig. 14 represented by lines. For example element E2 supports the processes P1 and P2. A degree of the support is expressed in the figure by percentages. Thus the line indicates between P1 and E2 that 10% of the need are taken off by process P1 by element E2, and 10% of the achievement by E2 by P1 to be used. Need respectively achievement on the one hand by absolute values, for example in working hours, costs, numbers of items, etc. are expressed. On the other hand the values with view of a process, an element, an event chain etc. to a respective total requirement of the process respectively to an overall capacity of the element etc. are referred and by percentages expressed. So visibly, as several elements anteilsrnässig to a process contribute, and one turns around, as the achievement of an element distributes itself on several processes. In the Fig. 14 for the simplification of the representation it is accepted that the percentages are referred to the same value with all processes P1-P3 and elements El-E4. Process P1 is supported after this analysis not completely, process P3 experiences a twice as large support as actually necessary would be. Element E3 is overloaded with 130%, and element E1 is only to 70% ausgelastet.

The costs of a business transaction are calculated by the proportional portions of the process costs: An element supports a process with a certain portion of the element capacity, and that process is supported to a certain portion of its total requirement by the element. From this total costs are computed: For example costs are allotted in BVC4 to 40% to the process P1 and to 60% to the process P3.

From the element costs in such a way the total costs of a business transaction become berechnet.

over the process costs If an element supports no process, like for example El, then its costs are distributed over the business transactions. Total costs for a business transaction are with an obtained price from the sale of the appropriate product A, B, C, D vergleichbar.

The costs of the same business transaction, but on element level, thus BVC6, are allotted to 40% to E2 and to 60% to E5. Element E1 contributes to 70% to process P1, supports however no process on Elementebene.

If the sum of the business transactions needs less than hundred per cent of a process, a value for the performance of the process obtains a reduced value as a sign of a insufficient Performance.

On the described modelling way and computation principles thus substantial statements about process costs and their emergence become based gemacht.

The procedure preferably also for other characteristics, represented on the basis the costs, applied, which than proportional dependence between objects are representable, for example Risiken.

A modelling of costs often takes place over different stages of an object hierarchy. For example the object hierarchy describes a product and its composition from partial products, or a hierarchically arranged assortment of products. With the model production and Modellparametrierung costs in different places are seized. These costs must be and permit consistently, perhaps missing information automatically too bestimmen.

Fig. 15 illustrates, as is proceeded thereby: It is given a tree structure, in which a parents knot exhibits several it assigned child knot 21, and each knot 20, 21 is provided with an attribute. The attribute represents a certain resources need, for example costs, numbers of items, time, materials requirements, etc., in the following for the sake of simplicity “costs” mentioned. Into the Fig. 15a and 15b are “not defined” these costs 620, 250, 300.0 and, what &lt through; nil> is characteristic. For the representation of connections and Propagationsregeln of these costs the following different kinds are preferably used by object relations with pertinent methods of calculation: Aggregation, transmission and simple Beziehung.

- With the aggregation 22 is the sum of the costs of parents knot 20 and child knot 21 (in the Fig. 15a: 250,300, 0, < nil>) equal the parents knot 20 assigned cost sum (620). For costs of the parents object alone (70) the difference between this cost sum (620) and the sum of the costs of the child knots (250+300) remains.

Into the Fig. is characteristic 15a and 15b this connection with the reference symbol 22. This kind of computation is for example for costs of products, according to parents knots 20, from components, according to child knot 21, zweckmässig.

- With the transmission 23 a child knot 21, if its costs are undefined, receives the costs of the parents knot (620). The cost sum (1790) is equal to the sum of the costs of the parents object and the costs of all child knots. This kind of computation is for example for costs of generalized products in a product catalog, according to parents knot 20, and specific products, according to child knots 21, zweckmässig.

- With the simple relationship 24 costs remain unchanged, undefined costs as zero are regarded. The cost sum (1170) is equal to the sum of the costs of the parents object and the costs of all Kindknoten.

With a given capacity of for example 620 an agreement with the costs results and with the other two kinds of computation 23, 24 a more or less strong understocking with the aggregation 22. Fig. 15b shows the same computation mechanisms as Fig. 15a, however with costs of the parents knot 20 of 0 instead of 620.

Performance evaluation characteristics of objects are determined in the enterprise of the material system by that the system adjusted model on the basis of measured variables. Requirements of such characteristics, which represent for example achievements, numbers of items, money, product quality, machine utilization etc., are summarized in a strategy object. This happens in a hierarchical form: Requirements at characteristics are called goals (“Goals”) and called in summary “theses”. Within a thesis the goals are weighted proportionally, are called their weights result in 100%. Theses are equally weighted to theses on a higher stage zusammenfassbar.

On a highest stage a summary of all theses is called strategy. The goals of a thesis are defined, qualified, quantified, stand in an order, are priorisiert and can in relationship stand among themselves. The individual objectives or theses can be linked with other pre-defined objects by means of an interaction relationship. This linkage can be provided to a medium, a requirement etc. to an external representative, process, element. With these linkages for example, too like much per cent an object is defined on this strategy respectively thesis concerned as well as too like much per cent a thesis on the object is dependent or is taken off. These linkages are for dependence analyses verwendbar.

In a preferential variant of the invention, with which the model is adjusted on the basis of measurements of the material system, a degree of completion of the different goals is computed according to the respective requirements. By the hierarchy of the theses and on the basis the weightings the fulfillment of the theses and the strategy is computed. Thus constantly a value is present, which a statement about the efficiency respectively the current conditions of the system concerning achievement of objective makes. If necessary it can be determined interactively by navigation by thesis objects and its functional dependences who or which in which measure for achievement of objective beiträgt.

Model comparison for the comparison of a system to different times or in different conditions at least two models of the system are present according to the different conditions, also view areas mentioned. Depending upon connection such conditions become also actual condition and specified condition genannt.

For example a specified condition corresponds to a desired system or reference condition after introduction of a new system software, after a reorganization of structures and expirations, or after installation of a new machine. Differences between the models are appropriate on the one hand in the model structure, thus for the structure by relations between the objects, and on the other hand in values of parameters respectively attributes of each other assigned Objekten.

By the continuous modelling on basis of the Grundtypen a comparison of different models is in the long run reducible on a comparison of a structure of the Grundtypen. Thus Iässt the comparison more efficiently implement themselves than on use of several different modelling paradigms for different Modellaspekte.

In order to transfer a condition into another, a quantity of actions is respectively changes of the system respectively the model, usually over a certain time intervall distributed, necessarily. This quantity of actions is called Projektportfolio and exhibits several subsets, called project. The Projektportfolio is preferably represented as its own model, in which the Ãnderungen between the regarded two models to the Uberprüfung by accepting respectively rejecting to be prepared. The determination of the actions is done via comparison of an object hierarchy of the objects instanzierten in the model with so-called Compare& Merge-Algorithmen.

Fig. 16 shows schematically such a model comparison. In each case a first and second model part for the description of a processing concept 13, an element model 14 and a model Informationsund function level 15 are compared with one another. The comparison results in a list of changes of the respective view levels. The appropriate actions are in projects 18.19 in the Projektportfolio 17 zusammengefasst.

In the detail one proceeds as follows: The objects form, with consideration of all relations types, a net respectively a graph. With consideration of all relations types including aggregation, relation, transmission, objects form a Type the root of the tree for the representation of processes form a superordinate process object or an object “model”. Knots and sheets of the tree are subordinated process objects. A tree with elements and if necessary a tree with units Informationsund become similar function level gebildet.

A comparison algorithm compares an object tree of a first model (“master” - model) with an object tree of a second model (“Changed” - model). A comparison produces a difference model, which represents the set union of the two source models, enriched around difference information, from two source models. The comparison of M1 = {A, B} and M2 = {B, C} results to A, B, C+ in M3 = {}. M1 is master model, M2 is Changed model. “A” meant “from master deleted”, “C+” means “in master” eingefügt.

The comparison happens recursively: For in each case two objects, which correspond each other, i.e. in both models it exists, is examined whether and how far their subordinated respectively child objects correspond themselves. But the following possibilities exist:

- Object exists only in the master, not in the Changed: - object does not exist in the master, only in the Changed: [- o] - object existed both place, but is changed: I!] - Object is unchanged, but containers of differences: [...], i.e., it contains changed Kind-Objekte.

For the regulation, whether two objects correspond each other it is used, the following object characteristics:

Objects point in this connection a “GUID” (Globally Unique ID), which for each object are unique, one “ldentifikator”, the one object from view of the user identified, and a name, on the basis whose a user recognizes an object. An object can be recognized thereby under its name, but must not yet for example as process identified sein.

The GUID will used for the identification of objects in technical procedures, e.g. when reading files, dissolve from left in texts, identify by objects over network etc. a material object of the system can in the model by several objects with different GUID be represented. The GUID is not for a normal user usually sichtbar.

The Identifikator is used for the identification of an object in the run of its evolution. An object can be changed while maintaining a stable Identifikators its name, be shifted to another place, other attributes and associations exhibits etc. of the Identifikator functioned thus than absolute Identifikator.

With not far specified Identifikator is used the name for the identification. The process “stock management” is thus for the user and for the comparison the same process as of the same name, but with other GUID.

The name identifies an object within his name area, it functioned, in other words, as relative Identifikator. The name area is determined by a chain of the names of the superordinate objects, similarly as in a file structure of a file management system. For example an operation “memory” is in a class “customer” another object than the operation “memory” in a class “order”. The name chain as well as that object names results in a qualified name, e.g. “order” “memory”.

Preferably for organizing objects also files or “folders” are used. They group objects devoted likewise, name areas and do not point thereby not compellingly a physical correspondence in the material world auf.

Objects of the same name in different name areas become thus in principle as other objects betrachtet.

By means of a Identifikators it can be specified however that it itself around the same object in other place handelt.

It results from it that shifting an object results in a deletion in the old place and an insertion in the new place into a folder in the case of the comparison as difference, except if the object from a Identifikator characterized ist.

Before a comparison allocations between objects of the two models can be specified also manually! Two objects in models which can be compared correspond each other in accordance with the following rules arranged according to priority:

- Objects are each other manually assigned. The manual allocation has priority opposite the further Zuordnungsregeln.

- Objects with same Identifikatoren become each other zugeordnet.

- Objects without Identifikator, but with same name and with each other assigned superordinate objects, become each other zugeordnet.

- Objects without name (technical objects) become with objects of same type and/or same structure and/or corresponding values zugeordnet.

- Structures from objects become according to a common sample or full one each other zugeordnet.

Because pre-defined objects are used, an efficient comparison and an allocation are possible also if Identifikatoren and/or names do not agree. Because Grundtypen are used as basis of the modelling, leaves itself also models of different origin with one another vergleichen.

In a preferential variant of the invention according to a comparison the differences between the models are classified in particular as differences between objects, characteristics and relations. In accordance with condition of a user input changes klassenweise are accepted or rejected. This permits for example to control and accept less weighty Ãnderungen to accept for example from textuellen description fields and/or from parameter values overall and however structural changes separately or reject. In another preferential variant of the invention differences are classified, listed and worked on in accordance with the objects concerned. Appropriate classes are thus for example strategy differences, process differences, element differences. Further classification variants are made in accordance with the kind of the difference: Delete, inserting, shifting, change of text, numeric values, and characteristics of relations, as for example proportional Verteilung.

In the following examples of model structures (“master” and “Changed”) are, a united structure (“Merged”) and a characterisation of the differences (“delta”) angegeben.

Comparison on the basis of Identifikatoren, thus with absolutely identified objects:

Master Changed Merged delta A A A - --A B B - --B -- A --A from A to B shifted B --B --B shifted from A to B representation conventions are exemplarily explained on the basis the first column: The master model exhibits an object A with Identifikator A and an object B with Identifikator B. The object A with Identifikator A is superordinate an object A with Identifikator X1 and an object B with Identifikator X2. On the basis the Identifikatoren it can be recognized that A and B shifted wurden.

Comparison on the basis of names, which are thus relatively identified with name areas:

Master Changed Merged delta A A A - --A [A:: A] B --A [A:: A] exists only in master --B [A:: B] --A [B:: A] --B [A:: B] exists only in master B --B [B:: B] B - --A [B:: A] exists only in Changed --B [B:: B] existed only in Changed in a preferential variant of the invention are determined from the determined changes change actions, which transfer the system in accordance with the first model into the system in accordance with the second model. Information about time requirement and costs are determined for example due to empirical values for single activities. Empirical values are formed for example in accordance with the well-known “Function POINT” - methodology and nachgeführt.

For example the application of settlement proceedings permits to examine and in particular plan a change a fabrication plant for another product or a reorganization of operational operational sequence. Preferred also an automated Umkonfiguration is accomplished. For example an actual condition and a specified condition of a printer road, according to different products of printering, are modelled. From the model comparison the change actions are determined and umkonfiguriert accordingly printing, crease, cutters etc. Preferably also costs respectively an expenditure for a Umkonfiguration are computed. With several necessary Umkonfigurationen a sequence is determined in such a manner by Umkonfigurationen that the total expenditure is minimal. Similarly for example also one knows softwareund/or Umkonfiguration in terms of hardware planned by computer systems and - networks and at least partly automatically accomplished werden.

Process control to the system-monitoring device and - control in defined places in the system the sensors already mentioned are installed for data acquisition. In addition, these information collecting tanks function usually automatically, can be based on manual user inputs. Determined measured values of the sensors are charged regarding the model in accordance with condition of the processing defined in the model and combined with other data. With in such a manner again computed values the process is steered. If certain values cross given limit values, notifications or alerting are released. For example a SMS, a document dispatch via email, becomes a transfer of information onto mobile equipment or a language message via telephone übermittelt.

With the invention a pragmatic, but nevertheless complete basis is created for the modelling, control and monitoring of complex technical and organizational systems and operational sequence. It permits:

- Models always consistently to have transparency and gradate-fairly for different goal-public ready in particular around an automated or manual decision-making process maximally too unterstützen.

- At any time statements to quality, risks, costs, use, feasibility etc. too erhalten.

- To support and changes always up-to-date to control be able necessary analyses maximally.