The invention relates to the modelling of complex systems. A system of any type, for example an installation relating to process technology or manufacturing technology comprises a multitude of interacting and mutually dependent units, which due to their cooperation, produce a desired result, for example a physical product. The same also applies to a system which also or chiefly comprises human actuators or handlers and produces a physical product and/or a service. The invention is furthermore directed to the field of data acquisition, data organisation, data evaluation and the use of data processed in such a manner, for the control and monitoring of complex systems. A related application is PCT/CH02/00516, whose content is herewith incorporated in its entirety here.
With complex systems which have a multitude of processes which are linked to one another, it is very difficult to predict the influence of changes of individual links and parameters on a behaviour of the complete system. For example, with the manufacture of highly complex products with corresponding processing sequences and likewise a corresponding organisation, the implementation of goals, the monitoring of the execution and the decision-making and control represent a large problem. Since the number of influencing variables increases with the size of a manufacturing process, of a company or of a project in an exponential manner, one may not have an overview of these with regard to their entirety. For this reason it is not easy to distinguish relevant from non-relevant variables, i.e. parameters and readings, to weight them and to evaluate and/or use them in the correct context. Decisions with the control of technical and organisational process are therefore often made in an arbitrary manner.
The reproduction of such processes as a rule is effected with specialised modelling or administration programs for ERP (enterprise resource planning), CRM (customer relation management), SCM (supply chain management), etc., and with tailor-made production control software.
With this, the models are directed to a certain, current system condition, support this and for example permit an evaluation of current or past characteristic values for assessing the system performance. However there exists no possibility of comparing different systems with one another.
It is therefore an object of the invention to provide a method, a data-processing system and a computer program for the comparison of models of a complex system, which permit an adequate representation of the system and a comparison of various systems.
This object is achieved by the subject-matter of the independent claims. The dependent claims relate to advantageous formations of the invention.
Thus with the comparison of models of a complex system, wherein a first model and a second model of the system are present, and the models in each case model a system behaviour by way of predefined objects which represent activities and units within the system, the following steps are carried out: comparison of the models and determining predefined objects of the first and the second model, said objects being associated with one another, determining differences in attributes of predefined objects which are associated with one another, and issuing the differences to a user.
By way of the use of predefined objects, thus objects which belong to a known quantity of types, the model comparison may be carried out in a much more efficient manner than with unstructured models. It is possible for example to compare models with several thousands of objects. The comparison method captures itself also given greater differences, since objects may be associated with one another via their types and preferably via further identification means such as identifiers or names. The issuing to the user is effected via print-out or known display apparatus.
Thus two models of the same system are used. One model represents the system in a first, for example actual condition, the other model represents the system in a second, for example a nominal condition. In a preferred variant of the invention, differences between the two conditions are determined by way of an automatic comparison algorithm, and actions are defined which convey the system in steps from the first into the second condition. With this, preferably defined action patterns and corresponding metrics are used. One action pattern describes a procedure for achieving a certain change, the metrics describe experience values for the expense with regard to costs, time and resources. One action pattern for example describes a new configuration or a re-configuration of a certain machine to a product variant or to the physical and organisatory set-up of a company branch or of a certain administration process. Thus one may automatically produce a portfolio of activities, and with a logical apportionment, e.g. into technical, logistical and organisatory activities, may be applied in project settings for project planning, and thanks to the metrics also in implementation control.
By way of the use of a limited set of common basic types for the complete modelling, it is possible to let the comparison method operate according to the same principle down to the lowest level, according to the basic types. This increases the flexibility and efficiency of the comparison method. It is likewise possible to compare models of various type and origin with one another since they are based on the same objects and basic types.
In a preferred variant of the invention, the modelling in both models is effected in each case on different modelling levels with different degrees of abstraction, whose objects are in a relation to one another. With a deletion or change of an object in a modelling level, under certain circumstances the change also has an effect on objects of other modelling level and thus effects indirect changes which are likewise ascertained by the comparison method.
A few further terms are defined for an improved understanding of the invention:
A system consists of a quantity of interacting units whose behaviour as a whole is to be modelled, examined and modified and preferably also monitored. Preferably a system is a technical installation, a machine, a production process or a working process, wherein a system may also contain several of these aspects.
The interacting units are preferably electromechanical, method/processing technological and/or information-processing or information-carrying subsystems or elements, or also organisatory subunits and locations of an organisation. As a unit one may for example consider: a machine as part of an installation, a processor as part of a machine, an autonomous manufacturing cell, a product or product component, a computer installation, a data bank, a software object, a machine-readable file, a department of a company, a person, a function or role in an organisation, etc.
The term modelling relates to the first-time formation of an abstract, in particular machine-readable representation of the system, as well as a tracking of this representation to an actual, real condition of the system. The latter in particular is used with an online process analysis (“monitoring”) and/or with a control of the system by way of control commands determined in the model. This representation of the system is also called model, and comprises a model structure as well as model parameters. The model structure represents relations between modelled units, whilst the model parameters are numeric and/or textual characterisations of properties of the units or relations. The model comprises mechanisms and rules for linking and processing data which represent the aspects of the system. The model is thus not only a model containing data, but also one which processes data.
The modelling is thus effected on a lowermost description level with a limited set of basic types for the representation of the units and for the description of their interaction. The basic types have inputs and outputs for receiving and for the transfer of data. The basic types are: a basic type “transfer”(straight), which represents a transfer of units, leads through data for characterisation of these units and comprises one input as well as one output, a basic type “merge”, which represents a combining of units, links data for the characterisation of these units to one another, and comprises two inputs as well as one output for the linked data, a basic type “split”, which represents a dividing-up of units, determines data for characterisation which originate from a dividing-up, from the data of a unit to be divided up, and comprises one input as well as two outputs.
The invention has the advantage that all procedures between the units at each detailing and observation step may be traced back to these basic types. The modelling effort is reduced, may be schematised and at least partly automated by way of this. A further advantage is the fact that also different analyses of the model may be standardised and automated in a comparatively simple manner, since it is always the same basic types which must be processed, which simplifies a formalisation and programming of the analysis. By way of the fact that it is always the same basic types which are used for system definition, the comparison possibilities between systems are increased. This is independent of whether a comparison is effected automatically or manually, and whether type-related and non-type-related systems are compared. A transparency of the models is increased even with a higher complexity.
The use of basic types in its concept corresponds to a use of switch elements in electronics technology: with a limited set of switch elements such as transistors, resistances, inductances and capacitors one may create an immense variety of circuits. This is similar to the logic of integrated circuits where all conceivable logic logical links may be realised only by way of NAND gates.
The basic types are expressed preferably in a class hierarchy of an object-orientated representation of software objects from which the model is built up. Thus all other essential software objects are defined by way of these basic types, and furthermore of course have further attributes and methods.
In a preferred variant of the invention, based on the basic type “transfer”, two further basic types are defined and used: a basic type “store”, which represents a storing of units, stores data for the characterisation of these units and comprises one input as well one output. A basic type “source”, which represents a source of units, produces data for the characterisation of this units and comprises one output.
In a preferred variant of the invention, each basic type has a history function or protocol function with which it stores processed or led-through data as well as the point in time of the processing or leading-through. With this, it becomes possible to set up statistics and analyses as well as a later follow-up of procedures.
In a further preferred variant of the invention, the basic types are summarised into so-called objects on a higher hierarchy step. Of the inputs and outputs of the summarised basic types, a number remain within the object, thus is not visible outside the object. Other inputs and outputs become visible to the outside as inputs and outputs or interfaces of the object. As a rule, an object comprises one or more inputs and one or more outputs. An object may however comprise no inputs or no outputs when it is at the beginning or at the end of an event chain respectively. The term “object”, as is used in this application is more restrictive than the term “software-object within the context of the object-orientated programming”. Objects as well as basic types are software objects. Objects consist of a quantity of basic types and have defined properties and behaviour at their disposal. Objects are later also called “predefined objects”, but for the sake of brevity as a rule are only called objects.
This permits a structured and systematic model formation and also the association of information and properties with an object as a whole. Furthermore a recycling of commonly occurring structures of basic types as predefined objects is possible, which in turn renders an efficient model formation possible.
Objects preferably have different forms, which is to say that they represent different aspects of reality. According to generally known principles of object-orientated programming, objects are defined for representing for example products, sequences (procedures), action carriers, production means etc., which inherit properties and methods of a general object and add specific properties and methods to these. All objects however comprise at least one of the five basic types.
A few further additional definitions are required for a further explanation of the invention. The system and its behaviour are observed on three observation levels called “process level”, “element level” and “information and function level”.
The process level comprises processes. The system is considered as a grouping of processes. With this, a process is an entirety of tasks, sequences and decisions. Processes for example are production processes or working processes such as “manufacture”, “end assembly”, “energy production”, “print machine line”, “acetylene synthesis”, “store administration”, “procurement”, “personnel administration”, etc. A process, from other object types, for example other processes or external agents (see below), via its inputs obtains entries or input, and produces issuings or outputs for other object types. A process may be divided into sub processes.
A certain task of a process is solved by a certain sequence of activities and a suitable flow of information. This course is called an event chain. Event chains are for example “manufacture Airbus A320”, “manufacture 50 tonnes of sulphuric acid”, “make part XY available from the shelf store system”, “configure print machine”, “set up computer workplace”, “employ workers”. The term process thus describes a unit which is in the position of fulfilling certain tasks, whilst the term event chain describes a certain sequence (procedure) in a process or over several processes. Several event chains typically use a process.
For modelling sequences (procedures), one preferably uses activity diagrams which on an upper representation level represent known flow diagrams. An activity diagram describes activities which take their course sequentially and/or in a branched manner. Individual activities, branching points and decision points of an activity diagram are objects and are thus built up of the basic types. For example a basic type “split” with corresponding inner rules represents a branching point. An activity may be constructed from a quantity of infinitely connected basic types or of a separate activities diagram. A sequence (procedure) within a process thus on the one hand may be modelled by basic types and on the other hand also by way of activities which in turn consist of basic types.
External agents are model parts which represent one aspect of reality which seen in the model or by part of the model is not modelled in a detailed manner, or an aggregation of objects consisting of basic types. An external agent essentially provides an interface, that is to say inputs and outputs, and optionally comprises a simplified modelling of an internal behaviour which per se is more complex, but whose details are of no interest.
The element level comprises elements. An element represents a real physical unit from the categories of information technology (IT), organization, tools and mechanical-electronic modules. An element supports a process or an activity of a process. Elements are for example computers, an IT-department, a person or a function carrier, a processing machine, an electromechanical product or its individual parts.
The information and function level comprises information and functions. These in particular represent information-technological units such as data bank tables or data bank attributes, variables or their values, as well as procedures, programs, readings and parameters.
The five basic types may be applied on each of the observation levels. The system is thus modelled on each of the observation levels with the same basic types, wherein the units whose representation is represented or processed by way of the basic types, are of a different type, depending on the observation level. Usefully also objects and predefined objects are used on all observation levels
In order to represent relations between basic types, objects and amongst one another, preferably differently natured relation types are used. For the sake of simplicity, in the following only objects are mentioned, wherein basic types, as the simplest forms of objects, are also meant. These relation types are grouped as permanent relations, interactive relations, flow relations and difference relations.
Permanent relations represent a simple reference of one object to another, or the fact that an object in another observation level corresponds to another object. For example a process “store administration” represents a quantity of several activities “dislocating”, “place in stock”, “create inventory”, etc. This is represented by a quantity of accordingly permanent relations between the process and the individual activities.
Interactive relations or interactions represent an influence of one object on another. With this, the type of influence or interaction at the point in time of model formation is known and is represented by the type of interactive relation. For example, a system rejection rate of product components may be determined by rejection rates of product components, wherein dependencies of the system failure on failure of individual components are represented by respective interactive relations. In another example, for an event chain “manufacture motor”, by way of two interactive relations one sets that for this, on the element level in a certain space of time, a machine tool is used to a 70% capacity and a certain manufacturing cell to a 50% capacity. Again, in another example the interactive relation expresses the fact that a certain characteristic value which for example represents a risk, a degree of accomplishment, costs, time expense, material consumption, energy consumption etc. is transferred from a first object to a second object. In the second object, the value is computed with values of other objects, and a characteristic value for the second object is computed. In a further example, an interactive relation represents the fact that a first object sends an event message to a second object under certain conditions, and this message, as the case may be, activates changes or computations in the second object.
Flow relations represent a transfer of information or contents of one object to a second object. With this however, in contrast to an interactive relation, the type of the influence on the second object which possibly results from this is not known at the point in time of model formation. For example, a file is transmitted according to a flow relation, and this file is analysed in the second object according to predefined rules or algorithms and, as the case may be, leads to certain activities of the second object. In another example, an event or a command is transmitted according to a flow relation, wherein the processing of the event and any reaction is determined by the receiving object.
Difference relations represent differences between similar type objects which find themselves in a different condition. A difference relation encompasses all these differences and with this may be very extensive, according to the complexity of the objects.
In a preferred variant of the invention, by way of such relations, one determines as to how much the resources are used to capacity and/or to which extent a predefined target of a system (goal) has been achieved. For example an event chain on the process level consists of individual steps and process steps. Each individual step is supported by one or more elements from the element level, which is modelled by way of corresponding relations between processes and elements. Preferably such supporting relations are associated with one or more numerical values, which for example express how much a certain element supports a certain process. By way of this type of modelling, on the one hand one may determine that an adequate support for one or more certain event chains exists, and one the other hand one may determine a utilisation of the supporting elements.
In a further preferred embodiment of the invention, various aspects of a system, or its processes and event chains are modelled on at least two of the observation levels, and relations between the objects used for this are modelled. By way of this type of modelling, that is to say by way of linking various model elements, a control of the quality of the model is rendered possible. For example one may check as to whether the model is not only syntactically correct, but also complete and consistent over the different observation levels. Results of the analyses are issued to the user by way of print-out or display apparatus. The model is preferably iteratively adapted on account of the issued results, i.e. corrected and/or tracked to the reality of the modelled system.
The model or parts of the model are either produced manually or automatically. For the manual production one preferably uses a graphic editor. With this for example, objects and relations are represented on display means such as a screen as areas or connection lines, and with the help of a display means such as a computer mouse are positioned and connected to one another. Parameters of objects or relations are for example represented and changed via associated representation and input masks. A suitable text is inputted for changing a parameter, or a list or a dialog for definition of the parameter in accordance with already inputted model elements appears on clicking on an assigned screen element.
For the automatic production of model parts, preferably program units are applied into an existing data processing system which automatically detects, and analyses automatic units such as processing units, data flows and request structures of the data processing system, and in the model produce corresponding objects and relations for imaging these units.
In a further preferred variant of the invention, for a model whose structure is known, parameters are automatically determined by way of program units distributed in a data processing system and are stored as part of the model.
In a further embodiment of the invention it permits the analysis, monitoring and control of a real system. For this, readings from the system are conveyed automatically or manually to the model, and the model is updated and analysed according to different methods. On account of the use of uniform basic types and relation types, these methods, for example an automatic comparison of various models of the same system, may be applied to different system levels and in various interrelations. Further methods for example determine risks, quality, performance, stability or the robustness of a system and their interrelations. This is effected continuously through the complete model thanks to the modelling by basic types based on everything. This also applies to a modelling and analysis by way of predefined objects which are based on the basic types. The presence of rules and exceptions in the basic types permits a highly flexible monitoring of the system since control conditions and/or control methods may be linked to each object and to each relation.
Amongst other things, the invention has the advantage that a system structure may be represented in a comprehensive manner and important parameters of a system may be detected in an objective manner. With traditional concepts, the complexity of the system on account of [inter]linking and constant changes leads to the fact that such parameters are estimated and interpreted differently. A standardised detection of basic factors of the system or process, their qualification and evaluation is thus not possible in practise, or entails a very great expense with regard to time and use of resources. The invention permits—under certain circumstances—and automatic detection of a multitude of measurements and their evaluation in the context of a model which images the relevant aspects of the reality in a useful manner. Units, sequences and procedures in the observed system are imaged with their parameters and set into relation with one another, and then analysed according to the interlinking. Models with a high quality result by way of the use of standardised sequences and algorithms on model formation and their verification by way of comparison of different model aspects. The real system may be controlled and/or the model may be tracked to the real system as a result of the evaluation.
The invention is particularly suitable for the modelling of complex, multidimensional interlinked systems. These real existing system properties by way of the various predefined objects such as observation levels and segments, event chains, processes, product, etc. may be detected/acquired and may be brought into relation with one another. The expressive capability of the modelling with a simultaneously unified basis permits a comprehensive representation of the system in the model, which may be applied to various automatic analysis methods.
The invention is preferably implemented in the form of one or more computer programs.
The data processing system according to the invention comprises storage means with computer program code means stored therein which describe a computer program, and data processing means for executing the computer program, wherein the execution of the computer program leads to the implementation of the method according to the invention.
The computer program according to the invention may be loaded into an internal memory of a digital data processing unit and comprises computer programming code means which when they are carried out in a digital data processing unit, cause this unit to carry out the method according to the invention. In a preferred embodiment of the invention, a computer program product comprises a computer-readable medium on which the computer program code means are stored.
In a preferred embodiment of the invention, separate parts of the computer program are carried out in separate computers, for example according to known client/server architecture and/or amid the use of data banks distributed over a network. A connection to information distribution systems such as e-mail, SMS (short message system) exists for alerting and informing operating personnel or users.
BRIEF DESCRIPTION OF THE DRAWINGSThe subject-matter of the invention is hereinafter explained in more detail by way of preferred embodiment examples which are represented in the accompanying drawings. Schematically, there are shown in:
Equal or the same types of parts are basically provided with the same reference numerals in the figures.
WAYS OF CARRYING OUT THE INVENTIONIn the following, information used according to the invention and structures are described first, and subsequently the method which is built up from these.
A system consists of a quantity of interacting units whose behaviour as a whole is to be modelled, examined and modified. Preferably a system is a technical installation, a machine, a production process or a working process, wherein a system may also contain several of these aspects. A production process for examples serves for producing physical products or energy. A quantity of basic types serves as a basic “kit” for modelling.
Basic Types
1. “source”, with no input and one output;
2. “transfer” (straight), with one input and one output;
3. “merge”, with two inputs and one output;
4. “split”, with one input and two outputs; and
5. “store”, with one input and one output.
Basically the basic types “source” and “store” may be represented by the basic type “transfer”, so that three basic types are sufficient for modelling. The two additional basic types are useful for a simpler representation.
The mentioned inputs and outputs represent the acceptance or handing-over of data respectively. In particular, an input and output may be a simple event or trigger, and/or carry a content. The inputs and outputs are linked to those of other basic types on construction of the model. One may form networks of an infinite type and complexity from the basic types on account of this. Basic types have a condition (such as “on”, “in use”, “deleted”, “suspended”, “sold”, “processed”, etc.), which may change, attributes, which define characteristics of a basic type, as well as Descriptions or functions which describe a sequential behaviour of the basic type as process-related sequence; preconditions for describing a start situation which must be present so that the behaviour or description or function of the basic type may be triggered; and postconditions for describing an end situation which prevails after sequences of a corresponding behaviour or a description or function of the basic type.
During the sequence of a function, for example rules and mathematical operations which describe a behaviour are carried out, and conditions which correspond to predefined exceptions are treated in a special manner.
In the following manner a working process is described by way of example. An action regulation for a machine control for example is expressed in an analogous manner and is programmed in a suitable syntax.
Precondition: a notification arrives via telephone, fax, e-mail.
Descriptions:
10 all notifications are entered into a uniform form.
20 the notifications are registered.
30 the individual invitations are finished off.
40 the participant list is completed.
50 the invitations are prepared for dispatch.
Postconditions: e-mail invitations, paper invitations.
Rules: with regard to 20 If the notification concerns a member: attach a bill for Fr. 50 to the invitation. If the invitation concerns a non-member: attach a bill for Fr. 250 to the invitation. If the invitation concerns a VIP, attach no bill to the invitation.
Exception: with regard to 30 If the address is incomplete, an inquiry by telephone is carried out and the address is made complete.
The various basic types are characterised as follows:
The basic type source based on an event produces a certain content and makes this available at its output to another basic type. The basic type itself protocols its actions by way of a memory or protocol function. By way of this it is later known which content it has produced on account of which event and at which point in time. The event for activating an output or for producing a content does not necessarily need to come from the outside, but for example is generated by an internal time trigger.
The basic type transfer or straight makes available a content which it has obtained at the input with or without change at its output, to another basic type. The basic type itself always knows which content it has passed on and at which point in time.
The basic type merge unifies the contents which it has received at two inputs and produces a new content according to its rules. It provides these contents at its outputs to other basic types. The basic type itself always knows which contents it has merged and at which point in time.
The basic type split splits the content which it has received at the input and produces new contents according to its rules. It makes these contents available to other basic types at its outputs. The basic type itself always which contents it has split and at which point in time.
The basic type store stores the contents which it receives at the input and may at its output make a corresponding event available to other basic types. The event for example contains the information “a piece of information of type X was stored at the point in time Y” or only a counter “until now the information X was received a number of times Z”. The basic type itself always knows which content it has stored and at which point in time.
A representation of processes is shown in
For representing a more complex behaviour, several basic types are linked via their inputs and outputs and the quantity of these linked basic types are observed as a unit. Such a combination of basic types is called an object. Inputs and outputs of a sub-quantity of the basic types are also inputs and outputs respectively of the object, whilst other inputs and outputs remain within the object. Preferably the variety of such objects is limited in that a limited number of predefined objects with a fixed inner structure and accordingly limited, but instead of this, established behaviour is used, which in turn may be combined with one another.
If an object becomes too complex in order to be able to be represented efficiently on only one level of basic types, then it may be split into objects which again consist recursively of objects or basic types. By way of this splitting which is not limited in depth, one may also represent very complex interrelations in a transparent manner.
Special objects are defined and used according to generally known principles of object-orientated programming and modelling. Each such object inherits the previously introduced and further general object characteristics and furthermore comprises further specific characteristics. It thus uses a part or all definitions of a general object. Further general object characteristics are attributes or functions for storing changes of the object itself, the acquisition and interaction of data from the modelled real process; the representation of notes, operating instructions, settings, checklists and/or assessments, which relate to the object; the representation of the content-related quality of the object, for example result of automatic analyses of the completeness and consistency of the object description. The representation of the risk, measurement, costs, cost type, metrics, etc.
Each of these definitions per se itself represents an object which was conceived from the basic types. For example in the object “risk” one may use the basic types in the following manner:
Basic type merge: for each relation of another risk, the basic type makes a note of corresponding dependencies, accepts content-related information from this other risk and from this for example determines a modified risk.
Basic type split: for each relation to another object which has a risk, the basic type makes note of a dependency and passes on corresponding content-related information to this other object or to its risk object.
Basic type transfer (straight) or source: for each attribute, the basic type represents an attribute characteristic such as a tendency, a current value, a probability, a weighting, costs, etc. As a rule one basic type is used per attribute, except for when several attributes do not need to be evaluated independently in an analysis.
The basic type may also assume the function of an early warning system or monitor, which by way of its rules and/or exceptions monitors a value and at the same time determines a value or a signal which is required for describing a risk, may be of interest to other risks or is evaluated with an automatic analysis.
An interactive manner effect belonging to the risk and expressing a mutual influence or an interdependency is modelled by the basic type transfer(straight) or source. A direction and an intensity of the effect of a changed risk on another object are modelled with this.
Observation LevelsThe model or the modelled system is preferably observed on several observation levels on which predefined objects lie. The system is in particular subdivided into three observation levels, called process level, element level and information and function level.
The process level forms an uppermost abstraction, which represents tasks and sequences as well as their interrelations amongst one another and to partner systems. The element level represents the support of the processes by way of technical and/or organisatory units or elements. Thus the complete infrastructure and organisation of the system is imaged on this level. On the third and at the same time lowermost level, the information- and function level, functions and information of the individual elements are represented in detail.
For example an event chain “employee introduction” is to be modelled in an administrative system. The event chain in a process “personnel administration” would run through a step or an activity “employee introduction discussion/interview”, which contains a data acquisition. On the processing level which relates to this step, it is only shown that a discussion protocol has been set up. The event chain is likewise described on the element level, but with reference to used elements, in this case software applications. This description for example states that a discussion protocol is created with a text processing software X, is stored in a data bank system Y and is passed on to a certain person with a mail system Z. A representation of the same event chain on the information and function level describes a file type and a predefined inner structure of the discussion protocol, as well as rules for naming and filing/depositing the file.
In another example, a process of a “print machine installation” is defined. In a real printing installation one may combine various print stations, folding and cutting machines with one another in various manners. An individual specific printing contract/order “create Saturday Morning Post” corresponds to a certain configuration of the installation and to a defined flow of paper through the installation, and is represented by an event chain. The specific printing contract demands very defined individual machines which are represented by elements. A certain machine in turn is controlled in accordance with machine parameters and [closed-loop] control functions which are modelled on the information and function level.
In a further example a product component is modelled. On the process level it is for example modelled by an object as a product “component delivery”, on the element level by an object as the product “car door, left” and on the information and function level a corresponding object makes a note of where and how data for the description of the car doors is stored.
The interrelations between the individual levels, thus the subject matter that a process or an event chain is supported by certain individual machines and that these in turn require certain information and functions, is modelled by way of support relations. By way of this, for example control parameters of a machine may be associated with the printing contract via the machine. Thus control parameters for individual printing contracts may be individually specified. Accordingly, proceeding for example from a process layer, by way of following the relations, one may determine which are specific parameters and these may be changed. This results in a “drill-down” functionality, which means to say that when required, proceeding from a general overview representation, one may access infinitely detailed information of the system.
Observation SegmentsObservation segments are defined orthognally to the observation levels. These are indicated as a “guide level”, “business value level” and “support level”. Each of these segments may contain objects of the process level, element level and the information and function level.
The business value level contains processes, elements etc., which contribute to the business value of an organisation or an installation, thus take a direct part in the production or processing of a product. These are therefore manufacturing lines, machines, outside work departments, etc. with associated processes, data and methods.
The support level contains processes, elements etc., which serve for supporting the sequences on the business value and guide level. These belong for example to information technology department, personnel administration, a shelf store system, procurement of raw material, etc.
The guide level contains processes, elements etc. which serve for the guiding of the business value and support levels. These in particular are management functions such as management, controlling with corresponding organisations, information technology means, etc.
By way of the splitting into these observation segments and by way of the association of costs and degrees of support, one may determine which units to which extent and with how much effort, contribute to a product and as the case may be to a profit.
A process is a summarising representation of a defined entirety of tasks and activities or sequences and decisions. A process has certain characteristics and a behaviour and comprises a number of basic types which individually are combined into an object. A process may be split into sub-processes. A process is always a constituent of a process model and on each of the three observation levels forms an uppermost abstraction step for describing the observation levels. A process obtains input or data from other object types such as process or external representatives and produces output or data for such object types. This input and output form a characterisation of the process and of quality, performance and added value of the process. Each process comprises attributes for describing costs, risks, measurement parameters, uses, quality, instructions, experience values, etc. Alternatively to this, such information is described in each case by special description objects instead of attributes.
A description of data exchanged by a process, that is to say input and output of the process is indicated as “Service Level Agreement” (SLA) or process interface description. The SLA is a working means which is transported between two predefined objects and thus corresponds to the description of the interface and defines this.
Relations of a process to other model entities for example describe reciprocal dependencies on risks, costs, utilisation/loading or support, as well as interrelations with a project, with an event chain, with planning goals, etc.
Preferably a predefined object activity is used for a semantically and syntactically correct and complete description of a process. An activity is also an extended instance of a general object, with a sub-quantity of the general object properties and with specific characteristics. One or more activities are assigned to a process.
Such a description is represented on the right side of
If an object lies outside an observation framework or outside a certain process model, then this object is called an “external representative” or also a partner object or foreign component. An external representative like a process, is an instance of an object with general as well as specific characteristics and behaviour. If a process is split and by way of this is broken down into sub-processes, then with this, new, and seen from the point of view of the sub-process, external representatives arise. Such a break-up 5 is shown reduced in size in
In a further application of external agents, an external agent in a first model represents a completely different second model. This means it unifies all characteristics and behaviour of a model. The external agent may thus be a representative for many various objects or object quantities. For example: an external agent “market” represents a place-keeper for a further entity which is not modelled, an external agent “partner” represents a modelled process by way of which the “partner” has assumed a role by way of outsourcing and is directly integrated into the process chain, an external agent “department” corresponds to a complete part of an entire system which not interested in detail in a certain interrelation.
The external agent as a representative is subsequently normally connected to an object within a model limit by way of a flow relation.
Event ChainAn event chain represents a recurring action sequence within the system. Depending of the context, event chains are also indicated as “use-case”, or as “business value chain”.
The individual steps in an event chain are tasks and process steps which take their course in a sequence and with certain peculiarities. A data flow of a use-case always describes from where and to where a certain piece of information flows. Apart from the basic object definitions, an object event chain has the particularity that it represents an edge and not a node of a network. For example a product is processed or manufactured along this edge or chain. Observed generally, a multiple value arises along an event chain. To represent changes which take their course with this, the event chain is subdivided into part flows or part chains according to which individual products or working means are manipulated. The individual part flows are assigned to processes and/or activities. The event chain may be represented or defined by way of activities.
Concluding, a process represents a part of a system which in a general manner is capable of certain actions, whilst an event chain or an activity represent actions carried out once with regard to a specific occurrence.
Several model aspects are represented in
A further special predefined object is represented by the element. An element represents how a process or an activity is supported by real entities. Preferably four types of elements are used: 1 information technology (IT), 2. organisation, 3. tools, and 4. mechanical-electronic modules.
This support of processes and activities is represented in
The information and function level models units, which support the elements. These in particular are information-technology units such as data and methods, and specifically data which image the reality in the system as well as metainformation on this data. The data is typically values of attributes or variables, which are stored in data banks or programs, as well as readings and control parameters of installations and machines. Metainformation describes a significance of data, data structures, data bank structures, file information, logical interrelations or computation rules for converting data. Methods describe procedures or programs for data processing and/or machine control.
Relation TypesBasic types and objects are brought into relation amongst one another. Relation types thereby define a behaviour of two objects or basic types which are in a relation to one another. Relation types themselves are also modelled as objects. With this, one differentiates between four relation types which are hereinafter described in more detail:
a) If two objects are permanently in a relation then the relation type permanent is used for the description. This relation corresponds to a mutual reference.
b) If one object triggers a reaction with another object, then the relation type interaction is used. With this, defined effects with another object may be achieved.
c) For representing a dynamic situation, the relation type flow is used. With this, one represents that not only an effect, but also contents between objects in a certain condition are displaced.
d) If with a connection of two object, one sets a respective functionality of these objects in relation to one another, one then defines the relation type gap.
The relation type “permanent”:
One differentiates between two permanent relation types, a static and an exchange relation.
A static relation represents a permanent mutual relation between two objects. For example, a mutual reference of two objects is represented by a static relation. With this, in both objects, pointers to the other object, for example as a navigatable link are instanced and for example linked with the name of the other object. This same type of relation is also used if an object is in a static correlation with another object and this fact is to be constantly displayed.
The exchange relation represents a relation between two different, predefined objects which follow fixed rules, for example according to a type conversion. With this, an object is exchanged into one or more objects of another predefined type. As to which relation, and under application of which rules the objects are to have with one another is fixed in the respective objects concerned. After the instancing one may navigate via this relation, and the objects being in relation recognise the type of exchange as well as the details or the respective other object.
For example exchange relations represent that a certain process comprises several activities. A process “manufacture” for example comprises a quantity of activities such as “manufacture product A”, “obtain intermediate product” etc. These in turn are each assigned to one or more event chains, which is likewise represented by exchange relations. A process “personnel administration” for example comprises the activities “employ employee”, “assess”, “dismiss”.
Other exchange relations for example represent an interrelation (connection) between a product and between services which may be observed as a product.
The relation type “interaction”:
With an interaction relation, one object has an influence on another one in any form or has a dependency on this. However an actual flow of contents between these objects does not arise, but the relation itself describes a certain, known type of influencing. The one object on account of its characteristics and its behaviour has an influence on the other one. Preferably five different types of interaction are to be differentiated:
An interaction type influence represents a percentage dependency between two objects, in particular a percentage distribution key or dependency key. For example if an influence relation states that a certain output or production target, such as “less than 2% rejects” or “less than 5% fluctuation”, is assigned to a process, for example the “manufacturing department”. The association is effected for example by way of a strategy object. A strategy object thus distributes goals to other objects for the purpose of a later control of the goal achievement.
An interaction type support represents a percentage dependency or a distribution key with defined rules and definitions between characteristics of two objects. This relation type is of special interest if predefined objects are located on different observation levels. One may then represent and see a dependency or coupling of the levels, which is to a greater or lesser degree. For example support relations represent that 60% of total available information technology means or services and 50% of the work output of an administrator are necessary for supporting a certain production department. In another example they represent the fact that a manufacturing process requires 30% of an NC-machine and 40% of a certain manufacturing cell.
An interaction effect represents an effect by way of triggering a reaction based on fixed rules and definitions. A method or an algorithm for determining the reaction is defined
