CH703073B1

CH703073B1 - Vergleich von Modellen eines komplexen Systems.

Info

Publication number: CH703073B1
Application number: CH00450/03A
Authority: CH
Inventors: Roland Pulfer
Original assignee: Roland Pulfer
Priority date: 2003-03-19
Filing date: 2003-03-19
Publication date: 2011-11-15
Also published as: US20100036874A1; WO2004083983A3; US7620639B2; WO2004083983A2; US8195709B2; US20070162496A1

Abstract

Zum Vergleich von computerbasierten und datenverarbeitenden Modellen eines komplexen Systems, wobei ein erstes Modell und ein zweites Modell des Systems vorliegen, und die Modelle jeweils ein Systemverhalten mittels vordefinierter Objekte modellieren, welche Aktivitäten und Einheiten innerhalb des Systems repräsentieren, werden die folgenden Schritte ausgeführt: Vergleich der Modelle und Bestimmung von jeweils einander zugeordneten vordefinierten Objekten des ersten und des zweiten Modells, Bestimmung von Unterschieden in Attributen von einander zugeordneten vordefinierten Objekten, und Ausgabe der Unterschiede an einen Benutzer. Durch die Verwendung von vordefinierten Objekten, also Objekten, die zu einer bekannten Menge von Typen gehören, kann der Modellvergleich effizienter durchgeführt werden als bei unstrukturierten Modellen.

Description

[0001] Die Erfindung betrifft die Modellierung komplexer Systeme und insbesondere den Vergleich von Modellen eines komplexen Systems. Ein System beliebiger Art, beispielsweise eine prozesstechnische oder fertigungstechnische Anlage, weist eine Vielzahl von interagierenden und gegenseitig abhängigen Einheiten auf, die durch ihr Zusammenwirken ein gewünschtes Ergebnis erzeugen, beispielsweise ein physisches Produkt. Gleiches gilt für ein System, welches auch oder vorwiegend menschliche Aktoren oder Handlungsträger aufweist und ein physisches Produkt und/oder eine Dienstleistung erzeugt. Die Erfindung ist ferner gerichtet auf das Gebiet der Datenerfassung, Datenorganisation, Datenauswertung und der Verwendung von in solcher Weise prozessierter Daten für die Steuerung und Überwachung von komplexen Systemen. Eine verwandte Anmeldung ist WO 03/027 916 deren Inhalt hiermit in seiner Gesamtheit mit aufgenommen wird.

[0002] Bei komplexen Systemen, die eine Vielzahl von miteinander verknüpften Prozessen aufweisen, ist es sehr schwierig, den Einfluss von Veränderungen einzelner Verknüpfungen und Parameter auf ein Verhalten des Gesamtsystems vorherzusagen. Beispielsweise stellt bei der Herstellung von hochkomplexen Gütern mit entsprechenden Produktionsabläufen und ebenfalls entsprechender Organisation die Umsetzung von Zielen, die Überwachung der Ausführung und die Entscheidungsfindung und Steuerung ein grosses Problem dar. Da die Anzahl der Einflussgrössen mit der Grösse eines Herstellungsprozesses, eines Unternehmens oder eines Projektes exponentiell zunimmt, können diese nicht mehr gesamtheitlich überblickt werden. Deshalb ist es sehr schwierig, relevante von nichtrelevanten Grössen, d.h. Parameter und Messwerte, zu unterscheiden, zu gewichten und im richtigen Kontext auszuwerten und/oder anzuwenden. Entscheidungen bei der Steuerung technischer und organisatorischer Prozesse werden deshalb häufig willkürlich getroffen.

[0003] Die Abbildung solcher Prozesse geschieht in der Regel mit spezialisierten Modellierungs- oder Verwaltungsprogrammen für ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), SCM (Supply Chain Management), etc. und massgeschneiderter Produktionssteuerungssoftware.

[0004] Dabei sind die Modelle auf einen bestimmten, aktuellen Systemzustand ausgerichtet, unterstützen diesen und erlauben beispielsweise eine Bestimmung von aktuellen oder vergangenen Kennzahlen zur Beurteilung einer Systemperformance. Es besteht jedoch nicht die Möglichkeit, unterschiedliche Systeme miteinander zu vergleichen.

[0005] Es ist deshalb eine Aufgabe der Erfindung, ein Verfahren zum Betrieb einer digitalen Datenverarbeitungseinheit zum Vergleich von computerbasierten und datenverarbeitenden Modellen eines komplexen Systems zu schaffen, welche eine adäquate Repräsentation des Systems und ein Vergleichen verschiedener Systeme erlaubt sowie eine Umsetzung von derart ermittelten Änderungen im System.

[0006] Diese Aufgabe wird durch den Gegenstand des unabhängigen Anspruchs gelöst. Die abhängigen Ansprüche betreffen vorteilhafte Ausgestaltungen der Erfindung.

[0007] Es werden also beim Vergleich von Modellen eines komplexen Systems, wobei ein erstes Modell und ein zweites Modell des Systems vorliegen, und die Modelle jeweils ein Systemverhalten mittels vordefinierter Objekte modellieren, welche Aktivitäten und Einheiten innerhalb des Systems repräsentieren, die folgenden Schritte ausgeführt: Vergleich der Modelle und Bestimmung von jeweils einander zugeordneten vordefinierten Objekten des ersten und des zweiten Modells, Bestimmung von Unterschieden in Attributen von einander zugeordneten vordefinierten Objekten, und Ausgabe der Unterschiede an einen Benutzer.

[0008] Durch die Verwendung von vordefinierten Objekten, also Objekten, die zu einer bekannten Menge von Typen gehören, kann der Modellvergleich effizienter durchgeführt werden als bei unstrukturierten Modellen. Es ist beispielsweise möglich, Modelle mit mehreren Tausenden von Objekten zu vergleichen. Das Vergleichsverfahren fängt sich auch bei grösseren Differenzen wieder auf, da Objekte über ihre Typen und vorzugsweise über weitere Identifikationsmittel wie Identifikatoren oder Namen einander zugeordnet werden können. Die Ausgabe an den Benutzer geschieht mittels Ausdruck oder bekannter Anzeigegeräte.

[0009] Es werden also zwei Modelle desselben Systems verwendet. Ein Modell repräsentiert das System in einem ersten, beispielsweise einem Ist-Zustand, das andere Modell repräsentiert das System in einem zweiten, beispielsweise einem Soll-Zustand. In einer bevorzugten Variante der Erfindung werden mittels eines automatischen Vergleichsalgorithmus Unterschiede zwischen den beiden Zuständen ermittelt, und es werden Handlungen definiert, die das System schrittweise vom ersten in den zweiten Zustand überführen. Dabei werden vorzugsweise vorgegebene Handlungsmuster und entsprechende Metriken verwendet. Ein Handlungsmuster beschreibt ein Vorgehen zur Erreichung einer bestimmten Änderung, die Metrik beschreibt Erfahrungswerte für einen Aufwand an Kosten, Zeit und Ressourcen. Beispielsweise beschreibt ein Handlungsmuster eine Neu- oder Umkonfiguration einer bestimmten Maschine auf eine Produktvariante oder das physische und organisatorische Einrichten einer Geschäftsfiliale oder eines bestimmten Verwaltungsprozesses. Es kann also automatisch ein Portfolio an Aktivitäten erzeugt werden, und mit einer logischen Aufteilung, z.B. in technische, logistische und organisatorische Aktivitäten in Projektvorgaben zur Projektplanung, und dank den Metriken auch zur Ausführungskontrolle umgesetzt werden.

[0010] Durch die Verwendung eines begrenzten Satzes von gemeinsamen Grundtypen für die gesamte Modellierung ist es möglich, den Vergleichsverfahren bis auf das tiefste Niveau, entsprechend den Grundtypen, nach denselben Prinzipen arbeiten zu lassen. Dies erhöht die Flexibilität und Effizienz des Vergleichsverfahrens. Ebenso wird möglich, Modelle verschiedener Art und Herkunft miteinander zu vergleichen, da sie auf denselben Objekten und Grundtypen basieren.

[0011] In einer bevorzugten Variante der Erfindung geschieht die Modellierung in beiden Modellen jeweils auf verschiedenen Modellierungsebenen mit unterschiedlichen Abstraktionsgraden, deren Objekte zueinander in Beziehung stehen. Bei einer Löschung oder Veränderung eines Objektes in einer Modellierungsebene wirkt sich die Änderung unter Umständen auch auf Objekte der anderen Modellierungsebene aus und bewirkt so indirekte Änderungen, die ebenfalls durch das Vergleichsverfahren gefunden werden.

[0012] Zum besseren Verständnis der Erfindung werden einige weitere Begriffe definiert: Ein System besteht aus einer Menge von zusammenwirkenden Einheiten, dessen Verhalten als Ganzes nachgebildet, untersucht und modifiziert und vorzugsweise auch überwacht werden soll. Vorzugsweise ist ein System eine technische Anlage, eine Maschine, ein Produktionsprozess oder ein Arbeitsprozess, wobei ein System auch mehrere dieser Aspekte beinhalten kann.

[0013] Die zusammenwirkenden Einheiten sind vorzugsweise elektromechanische, verfahrenstechnische und/oder informationsverarbeitende oder informationstragende Subsysteme oder Elemente, oder auch organisatorische Untereinheiten und Stellen einer Organisation. Beispielsweise sind als Einheit betrachtbar: eine Maschine als Teil einer Anlage, ein Prozessor als Teil einer Maschine, eine autonome Fertigungszelle, ein Produkt oder eine Produktkomponente, eine Computeranlage, eine Datenbank, ein Softwareobjekt, eine maschinenlesbare Datei, eine Abteilung einer Firma, eine Person, eine Funktion oder Rolle in einer Organisation, etc...

[0014] Der Begriff Modellierung betrifft sowohl eine erstmalige Bildung einer abstrakten, insbesondere einer maschinenlesbaren Repräsentation des Systems als auch eine Nachführung dieser Repräsentation an einen tatsächlichen, realen Zustand des Systems. Letztere wird insbesondere bei einer Online-Prozessanalyse («Monitoring») und/oder bei einer Steuerung des Systems durch im Modell bestimmte Steuerbefehle verwendet. Diese Repräsentation des Systems wird auch Modell genannt und weist eine Modellstruktur sowie Modellparameter auf. Die Modellstruktur stellt Beziehungen zwischen modellierten Einheiten dar, währenddem die Modellparameter numerische und/oder textuelle Charakterisierungen von Eigenschaften der Einheiten oder Beziehungen sind. Das Modell weist Mechanismen und Regeln zur Verknüpfung und Verarbeitung von Daten, die Aspekte des Systems repräsentieren, auf. Das Modell ist also nicht nur ein Daten enthaltendes, sondern auch Daten verarbeitendes Modell.

[0015] Die Modellierung geschieht auf einer untersten Beschreibungsebene mit einem begrenzten Satz von Grundtypen zur Repräsentation der Einheiten und zur Beschreibung ihres Zusammenwirkens. Die Grundtypen weisen Ein- und Ausgänge zur Übernahme und Weitergabe von Daten auf. Die Grundtypen sind: Ein Grundtyp «Weiterleiten», welcher eine Weiterleitung von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten durchleitet und einen Eingang sowie einen Ausgang aufweist. Ein Grundtyp «Verschmelzen», welcher ein Kombinieren von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten miteinander verknüpft und zwei Eingänge sowie einen Ausgang für die verknüpften Daten aufweist. Ein Grundtyp «Aufteilen», welcher eine Auftrennung von Einheiten repräsentiert, Daten zur Charakterisierung von Einheiten, die aus einer Auftrennung hervorgehen, aus Daten einer aufzutrennenden Einheit ermittelt und einen Eingang sowie zwei Ausgänge aufweist.

[0016] Die Erfindung hat den Vorteil, dass alle Vorgänge zwischen Einheiten auf jeder Detaillierungsstufe und Betrachtungsstufe auf diese Grundtypen zurückführbar sind. Dadurch ist der Modellierungsaufwand begrenzt, schematisierbar und zumindest teilweise automatisierbar. Ein weiterer Vorteil ist, dass auch verschiedene Analysen des Modells in vergleichsweise einfacher Weise standardisierbar und automatisierbar sind, da immer dieselben Grundtypen verarbeitet werden müssen, was eine Formalisierung und Programmierung der Analyse vereinfacht. Dadurch, dass immer die gleichen Grundtypen zur Systemdefinition angewendet werden, erhöhen sich auch die Vergleichsmöglichkeiten zwischen Systemen. Dies ist unabhängig davon, ob ein Vergleich automatisch oder manuell geschieht und ob artverwandte oder nicht artverwandte Systeme verglichen werden. Ebenfalls wird eine Transparenz der Modelle auch bei hoher Komplexität erhöht.

[0017] Die Verwendung der Grundtypen entspricht in der Denkweise einer Verwendung von Schaltelementen in der Elektrotechnik: mit einem begrenzten Satz von Schaltelementen wie Transistoren, Widerständen, Induktivitäten und Kondensatoren lässt sich eine immense Vielfalt von Schaltungen erstellen. Ähnliches gilt für die Logik von integrierten Schaltungen, wo alle denkbaren logischen Verknüpfungen nur durch NAND-Gatter realisierbar sind.

[0018] Die Grundtypen finden ihren Ausdruck vorzugsweise in einer Klassenhierarchie einer objektorientierten Darstellung von Softwareobjekten, aus denen das Modell aufgebaut ist. Es sind also alle übrigen wesentlichen Softwareobjekte anhand dieser Grundtypen definiert und weisen darüber hinaus natürlich weitere Attribute und Methoden auf.

[0019] In einer bevorzugten Variante der Erfindung werden, basierend auf dem Grundtyp «weiterleiten», zwei weitere Grundtypen definiert und verwendet: Ein Grundtyp «Aufbewahren», welcher eine Speicherung von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten speichert und einen Eingang sowie einen Ausgang aufweist. Ein Grundtyp «Erzeugen», welcher eine Quelle von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten erzeugt und einen Ausgang aufweist.

[0020] In einer bevorzugten Variante der Erfindung weist jeder Grundtyp eine Historien- oder Protokollfunktion auf, mit welcher er verarbeitete oder durchgeleitete Daten sowie den Zeitpunkt der Verarbeitung oder Durchleitung speichert. Damit wird das Erstellen von Statistiken und Analysen sowie eine spätere Rückverfolgung von Vorgängen möglich.

[0021] In einer weiteren bevorzugten Variante der Erfindung werden die Grundtypen auf einer höheren Hierarchiestufe zu sogenannten Objekten zusammengefasst. Von den Ein- und Ausgängen der zusammengefassten Grundtypen bleibt eine Anzahl innerhalb des Objektes, wird also nicht ausserhalb des Objektes sichtbar. Andere Ein- und Ausgänge werden als Ein- und Ausgänge oder Schnittstellen des Objekts nach aussen sichtbar. In der Regel weist ein Objekt einen oder mehrere Eingänge und einen oder mehrere Ausgänge auf. Ein Objekt kann aber beispielsweise keine Eingänge respektive keine Ausgänge aufweisen, wenn es am Anfang respektive am Ende einer Ereigniskette steht. Der Begriff «Objekt», wie er in dieser Anmeldung verwendet wird, ist enger gefasst als der Begriff «Software-Objekt im Sinne der objektorientierten Programmierung»: Objekte wie auch Grundtypen sind Software-Objekte. Objekte bestehen aus einer Menge von Grundtypen und verfügen über definierte Eigenschaften und Verhalten. Objekte werden später auch als «vordefinierte Objekte» bezeichnet, der Kürze halber aber in der Regel nur als Objekte.

[0022] Dies erlaubt eine strukturierte und systematische Modellbildung und auch die Zuordnung von Informationen oder Eigenschaften zu einem Objekt als Ganzem. Ferner wird auch eine Wiederverwertung von häufig auftretenden Strukturen von Grundtypen als vordefinierte Objekte möglich, was wiederum eine effiziente Modellbildung ermöglicht.

[0023] Vorzugsweise weisen Objekte unterschiedliche Ausgestaltungen auf, das heisst, sie repräsentieren unterschiedliche Aspekte der Realität. Gemäss allgemein bekannten Prinzipien der objektorientierten Programmierung werden Objekte zur Darstellung von beispielsweise Produkten, Abläufen, Handlungsträgern, Produktionsmitteln etc. definiert, welche Eigenschaften und Methoden eines allgemeinen Objektes erben und diesen spezifische Eigenschaften und Methoden zufügen. Alle Objekte weisen jedoch mindestens einen der fünf Grundtypen auf.

[0024] Zur weiteren Erklärung der Erfindung sind noch einige zusätzliche Definitionen erforderlich: Das System und sein Verhalten werden auf drei Betrachtungsebenen, genannt «Prozessebene», «Elementebene» und «Informations- und Funktionsebene», betrachtet.

[0025] Die Prozessebene weist Prozesse auf. Das System wird als Gruppierung von Prozessen betrachtet. Dabei ist ein Prozess eine Gesamtheit von Aufgaben, Abläufen und Entscheidungen. Prozesse sind beispielsweise Produktionsprozesse oder Arbeitsprozesse wie «Fertigung», «Endmontage», «Energieerzeugung», «Druckmaschinenstrasse», «Acetylensynthese», «Lagerverwaltung», «Einkauf», «Personalverwaltung», etc. Ein Prozess erhält von anderen Objekttypen, beispielsweise anderen Prozessen oder externen Agenten (siehe unten), über seine Eingänge Eingaben oder Input und produziert für die anderen Objekttypen Ausgaben oder Output. Ein Prozess kann in Subprozesse unterteilt werden.

[0026] Eine bestimmte Aufgabe eines Prozesses wird durch einen bestimmten Ablauf von Aktivitäten und einen entsprechenden Informationsfluss gelöst. Dieser Ablauf wird Ereigniskette genannt. Ereignisketten sind beispielsweise «Airbus A320 herstellen», «50 Tonnen Schwefelsäure herstellen», «Teil XY aus Hochregallager bereitstellen», «Druckmaschine konfigurieren», «Computerarbeitsplatz einrichten», «Mitarbeiter einstellen». Der Begriff Prozess beschreibt also eine Einheit, die bestimmte Aufgaben zu erfüllen in der Lage ist, währenddem der Begriff Ereigniskette einen bestimmten Ablauf in einem Prozess oder über mehrere Prozesse beschreibt. Ein Prozess wird typischerweise von mehreren Ereignisketten benutzt.

[0027] Zur Modellierung von Abläufen werden vorzugsweise Aktivitätsdiagramme verwendet, die auf einem oberen Darstellungsniveau den bekannten Flussdiagrammen entsprechen. Ein Aktivitätsdiagramm beschreibt sequentiell und/oder verzweigt ablaufende Aktivitäten. Einzelne Aktivitäten, Verzweigungspunkte und Entscheidungspunkte eines Aktivitätsdiagramms sind Objekte und sind somit aus den Grundtypen aufgebaut. Beispielsweise wird ein Verzweigungspunkt durch einen Grundtypen «Aufteilen» mit entsprechenden inneren Regeln dargestellt. Eine Aktivität kann aus einer Menge von beliebig zusammengeschalteten Grundtypen oder aus einem separaten Aktivitätendiagramm aufgebaut sein. Ein Ablauf innerhalb eines Prozesses kann also einerseits direkt durch Grundtypen modelliert werden, andererseits auch durch Aktivitäten, welche wiederum aus Grundtypen bestehen.

[0028] Externe Agenten sind Modellteile, die einen Aspekt der Realität repräsentieren, der im Modell oder von einem Teil des Modells aus gesehen nicht detailliert modelliert wird oder eine Aggregation von Objekten bestehend aus Grundtypen darstellt. Ein externer Agent stellt im Wesentlichen eine Schnittstelle, das heisst Ein- und Ausgänge, zur Verfügung und weist optional eine vereinfachte Modellierung eines an sich komplexeren internen Verhaltens auf, dessen Details aber nicht von Interesse sind.

[0029] Die Elementebene weist Elemente auf. Ein Element repräsentiert eine reale physische Einheit aus den Kategorien Informationstechnologie (IT), Organisation, Werkzeuge und mechanisch-elektronische Module. Ein Element unterstützt einen Prozess oder eine Aktivität eines Prozesses. Elemente sind beispielsweise Computer, eine IT-Abteilung, eine Person respektive ein Funktionsträger, eine Bearbeitungsmaschine, ein elektromechanisches Produkt oder dessen Einzelteile.

[0030] Die Informations- und Funktionsebene weist Informationen und Funktionen auf. Diese repräsentieren insbesondere informationstechnische Einheiten wie Datenbanktabellen oder -attribute, Variablen, respektive deren Werte, sowie Prozeduren, Programme, Messwerte und Parameter.

[0031] Die fünf Grundtypen sind auf jeder der Betrachtungsebenen verwendbar. Das System wird also auf jeder der Betrachtungsebenen mit denselben Grundtypen modelliert, wobei die Einheiten, deren Repräsentation durch die Grundtypen dargestellt oder verarbeitet wird, je nach Betrachtungsebene unterschiedlicher Art sind. Zweckmässigerweise werden auch Objekte und vordefinierte Objekte auf allen Betrachtungsebenen verwendet.

[0032] Um Beziehungen zwischen Grundtypen, Objekten und untereinander zu repräsentieren, werden vorzugsweise verschieden geartete Beziehungstypen verwendet. Im Folgenden werden der Einfachheit wegen nur Objekte genannt, wobei Grundtypen als einfachste Formen von Objekten mitgemeint sind. Diese Beziehungstypen sind gruppiert als permanente Beziehungen, Interaktionsbeziehungen, Flussbeziehungen und Differenzbeziehungen.

[0033] Permanente Beziehungen stellen eine einfache Referenz von einem Objekt zu einem anderen dar, oder die Tatsache, dass ein Objekt in einer anderen Betrachtungsebene einem anderen Objekt entspricht. Beispielsweise entspricht ein Prozess «Lagerverwaltung» einer Menge von mehreren Aktivitäten «Einlagern», «Auslagern», «Inventar erstellen», etc. Dies wird durch eine Menge von entsprechenden permanenten Beziehungen zwischen dem Prozess und den einzelnen Aktivitäten dargestellt.

[0034] Interaktionsbeziehungen oder Wechselwirkungen stellen eine Einflussnahme eines Objektes auf ein anderes dar. Dabei ist die Art der Einflussnahme oder Wechselwirkung zum Zeitpunkt der Modellbildung bekannt und wird durch die Art der Interaktionsbeziehung repräsentiert. Beispielsweise ist eine Systemausfallrate eines Produktes aus Ausfallraten von Produktkomponenten bestimmbar, wobei Abhängigkeiten des Systemausfalls von Ausfällen einzelner Komponenten durch jeweilige Wechselwirkungsbeziehungen dargestellt werden. In einem anderen Beispiel wird für eine Ereigniskette «Motor herstellen» durch zwei Wechselwirkungsbeziehungen festgehalten, dass dazu auf der Elementebene in einem bestimmten Zeitraum eine Werkzeugmaschine zu 70% und eine bestimmte Fertigungszelle zu 50% ausgelastet ist. In wieder einem anderen Beispiel drückt eine Wechselwirkungsbeziehung aus, dass ein bestimmter charakteristischer Wert, der beispielsweise ein Risiko, einen Erfüllungsgrad, Kosten, Zeitaufwand, Materialverbrauch, Energieverbrauch etc. repräsentiert, von einem ersten Objekt an ein zweites Objekt übermittelt wird. Im zweiten Objekt wird der Wert mit Werten von anderen Objekten verrechnet und wird ein charakteristischer Wert für das zweite Objekt berechnet. In einem weiteren Beispiel repräsentiert eine Wechselwirkungsbeziehung, dass ein erstes Objekt einem zweiten Objekt unter bestimmten Bedingungen eine Ereignisbotschaft sendet, welche im zweiten Objekt gegebenenfalls Änderungen oder Berechnungen auslöst.

[0035] Flussbeziehungen stellen eine Übermittlung von Informationen oder Inhalten von einem Objekt zu einem zweiten Objekt dar. Im Gegensatz zu einer Interaktionsbeziehung ist dabei die Art der daraus eventuell resultierenden Einflussnahme auf das zweite Objekt zum Zeitpunkt der Modellbildung nicht bekannt. Beispielsweise wird entsprechend einer Flussbeziehung eine Datei übertragen, die im zweiten Objekt gemäss vorgegebenen Regeln oder Algorithmen analysiert wird und gegebenenfalls zu bestimmten Aktivitäten des zweiten Objekts führt. In einem anderen Beispiel wird entsprechend einer Flussbeziehung ein Ereignis oder ein Befehl übertragen, wobei die Verarbeitung des Ereignisses und eine allfällige Reaktion durch das empfangende Objekt bestimmt wird.

[0036] Differenzbeziehungen stellen Unterschiede zwischen gleichartigen Objekten dar, welche sich in einem unterschiedlichen Zustand befinden. Eine Differenzbeziehung erfasst alle diese Unterschiede und kann damit, entsprechend der Komplexität der Objekte, sehr umfangreich sein.

[0037] In einer bevorzugten Variante der Erfindung wird anhand von solchen Beziehungen bestimmt, wie sehr Ressourcen ausgelastet sind und/oder bis zu welchem Grad ein vorgegebenes Ziel des Systems erreicht wird. Beispielsweise besteht eine Ereigniskette auf der Prozessebene aus verschiedenen Einzelschritten oder Prozessschritten. Jeder Einzelschritt wird durch ein oder mehrere Elemente aus der Elementebene unterstützt, was durch entsprechende Beziehungen zwischen Prozessen und Elementen modelliert wird. Vorzugsweise sind solche Unterstützungsbeziehungen mit einem oder mehreren numerischen Werten assoziiert, die beispielsweise ausdrücken, wie sehr ein bestimmtes Element einen bestimmten Prozess unterstützt. Durch diese Art der Modellierung ist einerseits bestimmbar, dass ausreichend Unterstützung für eine oder mehrere bestimmte Ereignisketten besteht, und andererseits lässt sich eine Auslastung der unterstützenden Elemente bestimmen.

[0038] In einer weiteren bevorzugten Ausführungsform der Erfindung werden verschiedene Aspekte eines Systems, respektive seiner Prozesse und Ereignisketten, auf mindestens zwei der Betrachtungsebenen modelliert, und es werden Beziehungen zwischen den dazu verwendeten Objekten modelliert. Durch diese Art der Modellierung, das heisst durch eine Vernetzung verschiedener Modellelemente, wird eine Kontrolle der Qualität des Modells ermöglicht. Beispielsweise ist prüfbar, ob das Modell nicht nur syntaktisch korrekt, sondern auch vollständig und konsistent über die unterschiedlichen Betrachtungsebenen ist. Resultate der Analysen werden durch Ausdruck oder Anzeigegeräte an einen Benutzer ausgegeben. Aufgrund der ausgegebenen Resultate wird vorzugsweise das Modell iterativ angepasst, d.h. korrigiert und/oder der Realität des modellierten Systems nachgeführt.

[0039] Das Modell oder Teile des Modells werden entweder manuell oder automatisch erzeugt. Für die manuelle Erzeugung wird vorzugsweise ein graphischer Editor verwendet. Mit diesem werden beispielsweise Objekte und Beziehungen auf einem Anzeigemittel wie einem Bildschirm als Flächen respektive Verbindungslinien dargestellt und mit Hilfe eines Zeigemittels wie einer Computermaus positioniert und miteinander verbunden. Parameter von Objekten respektive Beziehungen werden beispielsweise über zugeordnete Darstellungs- und Eingabemasken dargestellt und geändert. Zur Änderung eines Parameters wird ein entsprechender Text eingegeben, oder es erscheint beim Anklicken eines zugeordneten Bildschirmelementes eine Liste oder ein Dialog zur Definition des Parameters nach Massgabe von bereits eingegebenen Modellelementen.

[0040] Für die automatische Erzeugung von Modellteilen werden vorzugsweise Programmeinheiten in ein bestehendes Datenverarbeitungssystem eingesetzt, welche automatisch Einheiten wie Verarbeitungseinheiten, Datenflüsse und Aufrufstrukturen des Datenverarbeitungssystems erfassen, analysieren, und im Modell entsprechende Objekte und Beziehungen zur Abbildung dieser Einheiten erzeugen.

[0041] In einer weiteren bevorzugten Variante der Erfindung werden zu einem Modell, dessen Struktur bekannt ist, Parameter ebenfalls durch in einem Datenverarbeitungssystem verteilte Programmeinheiten automatisch bestimmt und als Teil des Modells gespeichert.

[0042] In einer weiteren Ausführungsform der Erfindung erlaubt sie die Analyse, Überwachung und Steuerung eines realen Systems. Dazu werden Messwerte aus dem System automatisch oder manuell dem Modell übermittelt und wird das Modell gemäss verschiedenen Verfahren aufdatiert und analysiert. Aufgrund der Verwendung einheitlicher Grundtypen und Beziehungstypen sind diese Verfahren, beispielsweise ein automatischer Vergleich verschiedener Modelle des gleichen Systems, auf verschiedenen Systemebenen und in verschiedenen Zusammenhängen anwendbar. Weitere Verfahren bestimmen beispielsweise Risiken, Qualität, Performance, Stabilität oder die Robustheit eines Systems und ihre Zusammenhänge. Dies geschieht durchgängig durch das gesamte Modell, dank der allem zugrundeliegenden Modellierung durch Grundtypen. Dies gilt auch für eine Modellierung und Analyse mittels der vordefinierten Objekte, die auf den Grundtypen basieren. Das Vorhandensein von Regeln und Ausnahmebedingungen in den Grundtypen erlaubt eine höchst flexible Überwachung des Systems, da Kontrollbedingungen und/oder Steuerverfahren an jedes Objekt und an jede Beziehung geknüpft werden können.

[0043] Die Erfindung hat unter anderem den Vorteil, dass eine Systemstruktur umfassend darstellbar ist und wichtige Kenngrössen eines Systems objektiv erfassbar sind. Bei traditionellen Ansätzen führt die Systemkomplexität aufgrund von Vernetzungen und dauernden Veränderungen dazu, dass solche Kenngrössen unterschiedlich eingeschätzt und interpretiert werden. Ein standardisiertes Erfassen der relevanten System- bzw. Prozessgrundlagen, deren Qualifizierung und Auswertung ist damit praktisch nicht möglich oder mit sehr hohem Zeitaufwand und Ressourcenverbrauch verbunden. Die Erfindung erlaubt eine – unter bestimmten Umständen automatische – Erfassung einer Vielzahl von Messungen und ihre Auswertung im Kontext eines Modells, welches die relevanten Aspekte der Realität in zweckmässiger Weise abbildet. Einheiten, Abläufe und Vorgänge im betrachteten System werden mit ihren Parametern abgebildet und miteinander in Beziehung gesetzt und dann entsprechend der Vernetzung analysiert. Durch das Verwenden von standardisierten Abläufen und Algorithmen bei der Modellbildung und deren Verifizierung durch Vergleich unterschiedlicher Modellaspekte resultieren qualitativ hochstehende Modelle. Als Resultat der Auswertung kann das reale System gesteuert werden und/oder das Modell dem realen System nachgeführt werden.

[0044] Die Erfindung eignet sich insbesondere zur Modellierung komplexer, multidimensionaler vernetzter Systeme. Diese real existierenden Systemeigenschaften sind durch die verschiedenen vordefinierten Objekte wie Betrachtungsebenen und -segmente, Ereignisketten, Prozesse, Produkt etc. erfassbar und können zueinander in Beziehung gebracht werden. Die Ausdrucksfähigkeit der Modellierung bei gleichzeitig einheitlicher Grundlage ermöglicht eine umfassende Repräsentation des Systems im Modell, die für verschiedene automatische Analyseverfahren verwendbar ist.

[0045] Die Erfindung ist vorzugsweise in Form von einem oder mehreren Computerprogrammen implementiert. Das Datenverarbeitungssystem gemäss der Erfindung weist Speichermittel mit darin gespeicherten Computerprogrammcodemitteln auf, welche ein Computerprogramm beschreiben, und Datenverarbeitungsmittel zur Ausführung des Computerprogramms, wobei die Ausführung des Computerprogramms zur Durchführung des Verfahrens gemäss der Erfindung führt.

[0046] Das Computerprogramm gemäss der Erfindung ist in einen internen Speicher einer digitalen Datenverarbeitungseinheit ladbar und weist Computerprogrammcodemittel auf, welche, wenn sie in einer digitalen Datenverarbeitungseinheit ausgeführt werden, diese zur Ausführung des erfindungsgemässen Verfahrens bringen. In einer bevorzugten Ausführungsform der Erfindung weist ein Computerprogrammprodukt ein computerlesbares Medium, einen Datenträger, auf, auf welchem die Computerprogrammcodemittel gespeichert sind.

[0047] In einer bevorzugten Ausführungsform der Erfindung werden separate Teile des Computerprogramms in separaten Rechnern ausgeführt, beispielsweise gemäss einer bekannten Client/Server-Architektur und/oder unter Verwendung von über einem Netzwerk verteilten Datenbanken. Zur Alarmierung und Benachrichtigung von Bedienpersonen oder Benutzern besteht eine Verbindung zu Nachrichtenverteilsystemen wie E-Mail, SMS (short message System), etc.

Kurze Beschreibung der Figuren

[0048] Im Folgenden wird der Erfindungsgegenstand anhand von bevorzugten Ausführungsbeispielen, welche in den beiliegenden Zeichnungen dargestellt sind, näher erläutert. Es zeigen schematisch <tb>Fig. 1<sep>Grundtypen; <tb>Fig. 2<sep>eine Aufspaltung eines Objekts in Grundtypen; <tb>Fig. 3<sep>ein Prozessmodell; <tb>Fig. 4<sep>ein Prozessmodell, aufgeteilt in Subprozesse; <tb>Fig. 5<sep>Ereignisketten durch Prozesse und mit Unterstützung durch Elemente; <tb>Fig. 6<sep>eine Übersichtsdarstellung; <tb>Fig. 7<sep>ein einfaches Beispiel mit vordefinierten Objekten «Prozess» und «Externer Vertreter»; <tb>Fig. 8<sep>eine Darstellung eines Prozesses durch Aktivitäten; <tb>Fig. 9<sep>ein vordefiniertes Objekt «Aktivität» in einem Aktivitätendiagramm; <tb>Fig. 10<sep>ein vordefiniertes Objekt «Arbeitsmittel»; <tb>Fig. 11<sep>ein vordefiniertes Objekt «Ereigniskette»; <tb>Fig. 12<sep>Betrachtungsebenen zur Validierung und Qualitätskontrolle; <tb>Fig. 13<sep>ein Beispiel für eine Modellvalidierung; <tb>Fig. 14<sep>Unterstützungsbeziehungen und Kostenverteilung; <tb>Fig. 15<sep>unterschiedliche Kostenverteilungsarten; und <tb>Fig. 16<sep>einen Modellvergleich.

[0049] Grundsätzlich sind in den Figuren gleiche oder gleichgeartete Teile mit gleichen Bezugszeichen versehen.

Wege zur Ausführung der Erfindung

[0050] In der Folge werden zuerst gemäss der Erfindung verwendete Information und Strukturen beschrieben, und anschliessend darauf aufbauende Verfahren.

[0051] Ein System besteht aus einer Menge von zusammenwirkenden Einheiten, dessen Verhalten als Ganzes nachgebildet, untersucht und modifiziert werden soll. Vorzugsweise ist ein System eine technische Anlage, eine Maschine, ein Produktionsprozess oder ein Arbeitsprozess, wobei ein System auch mehrere dieser Aspekte beinhalten kann. Ein Produktionsprozess dient beispielsweise einer Erzeugung von physischen Produkten, oder Energie. Als grundlegender «Bausatz» für die Modellierung dient eine Menge von Grundtypen:

Grundtypen

[0052] Fig. 1 zeigt schematisch Grundtypen, die einen Kanon für die Modellbildung zur Darstellung eines Systems bilden. Die Grundtypen werden bezeichnet mit: <tb>1.<sep>«Erzeugen» oder «Source», mit keinem Eingang und einem Ausgang; <tb>2.<sep>«Weiterleiten» oder «Straight», mit einem Eingang und einem Ausgang; <tb>3.<sep>«Verschmelzen» oder «Merge», mit zwei Eingängen und einem Ausgang; <tb>4.<sep>«Aufteilen» oder «Split», mit einem Eingang und zwei Ausgängen; und <tb>5.<sep>«Aufbewahren» oder «Store», mit einem Eingang und einem Ausgang.

[0053] Grundsätzlich sind die Grundtypen «Erzeugen» und «Aufbewahren» durch den Grundtyp «Weiterleiten» darstellbar, so dass drei Grundtypen zur Modellierung ausreichen. Die beiden zusätzlichen Grundtypen sind für eine einfachere Darstellung zweckmässig.

[0054] Die erwähnten Eingänge und Ausgänge entsprechen einer Übernahme respektive einer Übergabe von Daten. Insbesondere kann ein Eingang und Ausgang ein einfaches Ereignis respektive Auslöser oder «trigger» sein, und/oder einen Inhalt oder «content» tragen. Die Eingänge und Ausgänge werden beim Aufbau eines Modells mit jenen von anderen Grundtypen verknüpft. Dadurch sind aus Grundtypen Netze beliebiger Art und Komplexität bildbar. Grundtypen weisen einen Zustand auf (wie «ein», «in Gebrauch», «gelöscht», «suspendiert», «verkauft», «bearbeitet», etc.), der sich verändern kann, Attribute, die Eigenschaften eines Grundtyps definieren, sowie Funktionen oder «Descriptions», die ein sequentielles Verhalten des Grundtyps als prozessualen Ablauf beschreiben; Vorbedingungen oder «Preconditions» zur Beschreibung einer Startsituation, welche vorliegen muss, damit das Verhalten resp. die Funktion des Grundtyps auslösbar ist; und Nachbedingungen oder «Postconditions» zur Beschreibung einer Endsituation, welche nach Ablaufen eines entsprechenden Verhaltens respektive einer Funktion des Grundtyps herrscht.

[0055] Während des Ablaufs einer Funktion werden beispielsweise Regeln oder «Rules» und mathematische Operationen, die ein Verhalten beschreiben, ausgeführt, und werden Zustände, die vorgegebenen Ausnahmebedingungen oder «Exceptions» entsprechen, speziell behandelt.

[0056] Beispielhaft wird in der folgenden Art ein Arbeitsprozess beschrieben. Eine Handlungsvorschrift für beispielsweise eine Maschinensteuerung wird in analoger Weise ausgedrückt und in einer geeigneten Syntax programmiert.

[0057] Vorbedingung: Eine Anmeldung trifft via Telefon, Fax, E-Mail ein.

Funktionen:

[0058] <tb>10<sep>Sämtliche Anmeldungen werden in ein Einheitsformular eingetragen. <tb>20<sep>Die Anmeldungen werden registriert. <tb>30<sep>Die individuellen Einladungen werden aufgearbeitet. <tb>40<sep>Die Teilnehmerliste wird vervollständigt. <tb>50<sep>Die Einladungen werden zum Versand aufbereitet.

[0059] Nachbedingungen: E-Mail-Einladungen, Papier-Einladungen.

Regeln: zu 20

[0060] Betrifft die Anmeldung ein Mitglied: zur Einladung Rechnung über Fr. 50.– beilegen. Betrifft die Anmeldung nicht ein Mitglied: zur Einladung Rechnung über Fr. 250.– beilegen. Betrifft die Anmeldung VIP: zur Einladung keine Rechnung beilegen.

Ausnahmebedingung: zu 30

[0061] Ist die Adresse unvollständig: eine telefonische Rückfrage wird durchgeführt und die Adresse vervollständigt.

[0062] Die verschiedenen Grundtypen sind wie folgt charakterisiert: Der Grundtyp Erzeugen oder «Source» erzeugt basierend auf einem Ereignis einen bestimmten Inhalt und stellt diesen an seinem Ausgang einem anderen Grundtyp zur Verfügung. Der Grundtyp selber protokolliert mittels einer Gedächnis- oder Protokollfunktion seine Aktionen. Er weiss dadurch später, welchen Inhalt er aufgrund von welchem Ereignis und zu welchem Zeitpunkt erzeugt hat. Das Ereignis zum Aktivieren eines Ausganges respektive zum Erzeugen eines Inhaltes muss nicht zwingend von aussen kommen, sondern wird beispielsweise durch einen internen Zeitauslöser generiert.

[0063] Der Grundtyp Weiterleiten oder «Straight» stellt einen Inhalt, welchen er am Eingang erhalten hat mit oder ohne Veränderung an seinem Ausgang einem anderen Grundtyp zur Verfügung. Der Grundtyp selber weiss immer, welchen Inhalt er zu welchem Zeitpunkt weitergeleitet hat.

[0064] Der Grundtyp Verschmelzen oder «Merge» vereinigt die Inhalte, die er an seinen zwei Eingängen empfangen hat, und erzeugt gemäss seinen Regeln einen neuen Inhalt. Diesen Inhalt stellt er an seinem Ausgang anderen Grundtypen zur Verfügung. Der Grundtyp selber weiss immer, welche Inhalte er zu welchem Zeitpunkt wie zusammengeführt hat.

[0065] Der Grundtyp Aufteilen oder «Split» teilt den Inhalt, den er am Eingang empfangen, hat und erzeugt gemäss seinen Regeln neue Inhalte. Diese Inhalte stellt er an seinen Ausgängen anderen Grundtypen zur Verfügung. Der Grundtyp selber weiss immer, welche Inhalte er zu welchem Zeitpunkt wie aufgeteilt hat.

[0066] Der Grundtyp Aufbewahren oder «Store» speichert den Inhalt, den er am Eingang empfängt, und kann an seinem Ausgang für andere Grundtypen ein entsprechendes Ereignis zur Verfügung stellen. Das Ereignis beinhaltet beispielsweise die Information «Eine Information vom Typ X wurde zum Zeitpunkt Y gespeichert» oder nur einen Zähler «Es wurde bisher eine Anzahl Z Mal die Information X erhalten». Der Grundtyp selber weiss immer, welchen Inhalt er zu welchem Zeitpunkt gespeichert hat.

[0067] Als Beispiel für Grundtypen ist beispielsweise eine Darstellung von Prozessen in Fig. 7, von Aktivitäten in Fig. 9und von Ereignisketten in Fig. 13 gezeigt und weiter unten beschrieben.

Objekte

[0068] Zur Darstellung eines komplexeren Verhaltens werden mehrere Grundtypen über ihre Ein- und Ausgänge verknüpft und wird die Menge dieser verknüpften Grundtypen als Einheit betrachtet. Eine solche Kombination von Grundtypen wird Objekt genannt. Ein- und Ausgänge einer Untermenge der Grundtypen sind auch Ein- respektive Ausgänge des Objektes, währenddem andere Ein- und Ausgänge innerhalb des Objekts bleiben. Vorzugsweise wird die Vielfalt von solchen Objekten begrenzt, indem eine beschränkte Anzahl von vordefinierten Objekten mit fixer innerer Struktur und entsprechend eingeschränktem, aber dafür bewährtem Verhalten verwendet wird, die wiederum miteinander kombinierbar sind.

[0069] Fig. 2 zeigt eine Bildung eines Objektes 1 aus einer Menge 2 von mehreren Grundtypen. An Schnittstellen 3 des Objektes werden entsprechende Schnittstellen 4 der Grundtypen sichtbar, übrige Schnittstellen der Grundtypen bleiben im Objekt verborgen. Vorbedingungen für das Objekt sind gleich den Vorbedingungen desjenigen Grundtyps, dessen Eingang den Eingang des Objekts bildet. Nachbedingungen für die beiden Ausgänge des Objekts sind gleich den Nachbedingungen der entsprechenden Grundtypen, deren Ausgänge die Ausgänge des Objekts bilden. Regeln des Objektes sind eine logisch herleitbare Kombination von Regeln der Grundtypen. Umgekehrt lassen sich eine Struktur von Grundtypen und Regeln dieser Grundtypen automatisch aus vorgegebenen Regeln des Objektes herleiten. Anstelle von den ausserhalb des Objektes liegenden Grundtypen können natürlich andere Objekte wie Externe Vertreter treten.

[0070] Wird ein Objekt zu komplex, um auf nur einer Ebene von Grundtypen effizient dargestellt werden zu können, so kann es in Objekte aufgeteilt werden, welche wiederum rekursiv aus Objekten oder Grundtypen bestehen. Durch diese Aufteilung, die in der Tiefe nicht limitiert ist, können auch sehr komplexe Zusammenhänge transparent dargestellt werden.

[0071] Gemäss allgemein bekannten Prinzipien der objektorientierten Programmierung und Modellierung werden spezielle Objekte definiert und verwendet. Jedes solche Objekt erbt die bisher vorgestellten und weitere allgemeine Objekteigenschaften und weist darüber hinaus spezifische Eigenschaften auf. Es benutzt also einen Teil oder alle Definitionen eines allgemeinen Objektes. Weitere allgemeine Objekteigenschaften sind Attribute oder Funktionen zur Speicherung von Änderungen des Objekts selber; Erfassung und Integration von Daten aus dem modellierten realen Prozess; Darstellung von Notizen, Arbeitsanweisungen, Vorlagen, Checklisten und/oder Bewertungen, die das Objekt betreffen; Darstellung einer inhaltlichen Qualität des Objekts, beispielsweise Ergebnisse von automatischen Analysen der Vollständigkeit und Konsistenz der Objektbeschreibung. zur Darstellung von Risiko, Messung, Kosten, Kostenart, Metriken etc.

[0072] Jede dieser Definitionen stellt in sich selber ein Objekt dar, welches aus den Grundlagentypen konstruiert wurde. Beispielsweise sind im Objekt «Risiko» die Grundtypen in folgender Weise verwendbar:

[0073] Grundtyp Verschmelzen: für jede Relation von einem anderen Risiko hält der Grundtyp eine entsprechende Abhängigkeit fest, nimmt inhaltliche Informationen von diesem anderen Risiko entgegen und bestimmt daraus beispielsweise ein modifiziertes Risiko.

[0074] Grundtyp Aufteilen: für jede Relation zu einem anderen Objekt, welches ein Risiko besitzt, hält der Grundtyp eine Abhängigkeit fest und leitet entsprechende inhaltliche Informationen an dieses andere Objekt respektive an dessen Risikoobjekt weiter.

[0075] Grundtyp Weiterleiten oder Erzeugen: für jedes Attribut stellt der Grundtyp eine Attributeigenschaft wie eine Tendenz, einen aktuellen Wert, eine Wahrscheinlichkeit, eine Gewichtung, Kosten, etc. dar. In der Regel wird ein Grundtyp pro Attribut verwendet, ausser wenn mehrere Attribute in einer Analyse nicht unabhängig ausgewertet werden müssen.

[0076] Der Grundtyp kann auch die Funktion eines Frühwarnsystems oder Monitors wahrnehmen, der mittels seiner Regeln und/oder Ausnahmebedingungen einen Wert überwacht und dabei einen Wert oder ein Signal bestimmt, das zur Beschreibung eines Risikos benötigt wird, andere Risiken interessieren könnte oder bei einer automatischen Analyse ausgewertet wird.

[0077] Eine zum Risiko gehörende Wechselwirkungsart Effekt, die einen gegenseitigen Einfluss oder eine Interdependenz ausdrückt, wird durch den Grundtyp Weiterleiten oder Erzeugen modelliert. Damit wird eine Richtung und eine Stärke des Effekts eines veränderten Risikos auf ein anderes Objekt modelliert.

Betrachtungsebenen

[0078] Das Modell respektive das modellierte System wird vorzugsweise auf mehreren Ebenen betrachtet, auf denen die vordefinierten Objekte liegen: Das System wird insbesondere in drei Betrachtungsebenen, genannt Prozessebene, Elementebene, und Informations- und Funktionsebene, unterteilt.

[0079] Die Prozessebene bildet eine oberste Abstraktion, die Aufgaben und Abläufe sowie deren Zusammenhänge untereinander und zu Partnersystemen darstellt. Die Elementebene repräsentiert die Unterstützung der Prozesse durch technische und/oder organisatorische Einheiten respektive Elemente. Somit wird auf dieser Ebene die gesamte Infrastruktur und Organisation des Systems abgebildet. Auf der dritten und zugleich untersten Ebene, der Informations- und Funktionsebene, werden Funktionen und Informationen der einzelnen Elemente im Detail repräsentiert.

[0080] Beispielsweise sei in einem administrativen System eine Ereigniskette «Mitarbeitereinführung» modelliert. Die Ereigniskette durchlaufe in einem Prozess «Personalverwaltung» einen Schritt respektive eine Aktivität «Mitarbeiter-Einführungsgespräch», der eine Datenerfassung beinhaltet. Auf der Prozessebene wird, was diesen Schritt betrifft, nur dargestellt, dass ein Gesprächsprotokoll erstellt wird. Auf der Elementebene ist die Ereigniskette ebenfalls beschrieben, jedoch mit Bezug auf benutzte Elemente, in diesem Fall Softwareapplikationen. Diese Beschreibung besagt beispielsweise, dass das Gesprächsprotokoll mit einer Textverarbeitungssoftware X erstellt, in einem Datenbanksystem Y abgespeichert und mit einem Mailsystem Z an bestimmte Personen übermittelt wird. Eine Repräsentation derselben Ereigniskette auf der Informations- und Funktionsebene beschreibt einen Dateityp und eine vorgegebene innere Struktur des Gesprächsprotokolls, sowie Regeln zur Namensgebung und Ablage der Datei.

[0081] In einem anderen Beispiel sei ein Prozess «Druckmaschinenanlage» definiert. In einer realen Druckanlage sind verschiedene Druckstationen, Falz- und Schneidemaschinen auf verschiedene Arten miteinander kombinierbar. Ein einzelner konkreter Druckauftrag «Glückspost herstellen» entspricht einer bestimmten Konfiguration der Anlage und einem bestimmten Papierfluss durch die Anlage und wird durch eine Ereigniskette repräsentiert. Der konkrete Druckauftrag beansprucht ganz bestimmte Einzelmaschinen, die durch Elemente repräsentiert werden. Eine bestimmte Maschine wiederum wird nach Massgabe von Maschinenparametern und Regelfunktionen gesteuert, welche auf der Informations- und Funktionsebene modelliert werden.

[0082] In einem weiteren Beispiel werde eine Produktkomponente modelliert. Auf Prozessebene wird sie beispielsweise durch ein Objekt als Produkt «Komponentenlieferung» modelliert, auf der Elementebene durch ein Objekt als Produkt «Autotüre links», und auf der Informations- und Funktionsebene hält ein entsprechendes Objekt fest, wo und wie Daten zur Beschreibung der Autotüre gespeichert sind.

[0083] Die Zusammenhänge zwischen den einzelnen Ebenen, also der Sachverhalt, dass ein Prozess oder eine Ereigniskette durch bestimmte Einzelmaschinen unterstützt wird, und dass diese wiederum bestimmte Informationen und Funktionen benötigen, wird durch Unterstützungsbeziehungen modelliert. Dadurch sind beispielsweise Steuerparameter einer Maschine über die Maschine mit einem Druckauftrag assoziiert. Somit können Steuerparameter für einzelne Druckaufträge individuell spezifiziert werden. Entsprechend kann, ausgehend von beispielsweise einer Prozesssicht, durch Verfolgen der Beziehungen, ermittelt werden, welches konkrete Parameter sind und können diese geändert werden. Dies ergibt eine «drill-down»-Funktionalität, das heisst, dass bei Bedarf, von einer allgemeinen Übersichtsdarstellung ausgehend, auf beliebig detaillierte Informationen des Systems zugegriffen werden kann.

Betrachtungssegmente

[0084] Orthogonal zu den Betrachtungsebenen sind Betrachtungssegmente definiert. Diese sind als «Führungsebene», «Wertschöpfungsebene» und «Unterstützungsebene» bezeichnet. Jedes dieser Segmente kann Objekte der Prozessebene, Elementebene und der Informations- und Funktionsebene enthalten.

[0085] Die Wertschöpfungsebene beinhaltet Prozesse, Elemente etc., die zur Wertschöpfung einer Organisation oder einer Anlage beitragen, also direkt an der Erzeugung oder Bearbeitung eines Produkts beteiligt sind. Dies sind also Fabrikationsstrassen, Maschinen, Aussendienstabteilungen etc. mit zugeordneten Prozessen, Daten und Verfahren.

[0086] Die Unterstützungsebene beinhaltet Prozesse, Elemente etc., die zur Unterstützung der Abläufe auf der Wertschöpfungs- und Führungsebene dienen. Diese gehören beispielsweise zu einer Informatikabteilung, einer Personalverwaltung, einem Hochregallager, einer Rohstoffbeschaffung etc.

[0087] Die Führungsebene beinhaltet Prozesse, Elemente etc., die zur Führung der Wertschöpfungs- und Unterstützungsebene dienen. Dies sind insbesondere Managementfunktionen wie Betriebsführung, Controlling mit entsprechenden Organisationen, Informatikmitteln etc.

[0088] Durch die Aufteilung in diese Betrachtungssegmente und durch die Zuordnung von Kosten und Unterstützungsgraden lässt sich ermitteln, welche Einheiten in welchem Grade und mit welchem Aufwand zu einem Produkt und gegebenenfalls einem Profit beitragen.

[0089] Fig. 3 zeigt eine Darstellung eines Systems mit Modellelementen auf einer obersten Modellierungsebene oder Abstraktionsebene, beispielsweise auf der Prozessebene. Es sind einzelne Prozesse P1 ... P6 auf den drei Ebenen wie auch die Beziehungen zwischen den einzelnen Prozessen dargestellt. Mit EA1...EA6 sind sogenannte «Externe Vertreter» bezeichnet. Die Prozesse P1, P2 liegen in der Führungsebene, die Prozesse P3, P4 und P5 in der Wertschöpfungsebene und der Prozess P6 in der Unterstützungsebene. Im Folgenden werden Prozesse und Externe Vertreter beschrieben:

Prozesse

[0090] Ein Prozess ist eine zusammenfassende Darstellung einer definierten Gesamtheit von Aufgaben und Aktivitäten oder Abläufen und Entscheidungen. Ein Prozess hat bestimmte Eigenschaften und ein Verhalten und weist eine Anzahl von Grundlagentypen auf, die individuell zu einem Objekt kombiniert werden. Ein Prozess kann in Subprozesse aufgeteilt sein. Ein Prozess ist immer ein Bestandteil eines Prozessmodells und bildet auf jeder der drei Betrachtungsebenen eine oberste Abstraktionsstufe zur Beschreibung der Betrachtungsebenen. Ein Prozess erhält Input respektive Daten von anderen Objekttypen wie Prozessen oder Externen Vertretern und produziert Output respektive Daten für solche Objekttypen. Dieser Input und Output bilden eine Charakterisierung des Prozesses und von Qualität, Performance und Zusatznutzen («Added Value») des Prozesses. Jeder Prozess weist Attribute zur Beschreibung von Kosten, Risiken, Messkennzahlen, Nutzen, Qualität, Anweisungen, Erfahrungswerten etc. auf. Alternativ dazu sind solche Informationen durch jeweils spezielle Beschreibungsobjekte anstelle von Attributen beschrieben.

[0091] Eine Beschreibung der von einem Prozess ausgetauschten Daten, das heisst Input und Output des Prozesses, wird als «Service Level Agreement» (SLA) oder Prozessschnittstellenbeschreibung bezeichnet. Das SLA ist ein Arbeitsmittel, das zwischen zwei vordefinierten Objekten transportiert wird und somit der Beschreibung einer Schnittstelle entspricht und diese definiert.

[0092] Beziehungen eines Prozesses zu anderen Modellentitäten beschreiben beispielsweise wechselseitige Abhängigkeiten von Risiken, Kosten, Beanspruchung oder Unterstützung, sowie Zusammenhänge mit einem Projekt, einer Ereigniskette, Planungszielen etc.

[0093] Zur semantisch und syntaktisch korrekten und vollständigen Beschreibung eines Prozesses wird vorzugsweise ein vordefiniertes Objekt Aktivität verwendet. Auch eine Aktivität ist eine erweiterte Instanz eines allgemeinen Objekts, mit einer Untermenge der allgemeinen Objekteigenschaften und mit spezifischen Eigenschaften. Einem Prozess sind eine oder mehrere Aktivitäten zugeordnet...

[0094] Auf der rechten Seite der Fig. 8ist eine solche Beschreibung mittels eines Aktivitätendiagramms beispielhaft mit verschiedenen Typen von Aktivitäten Sequenz, Einzelschritt, Aufteilung, Verzweigung, dargestellt. Die Darstellung beschreibt, in aus der Computertechnik bekannter Weise, einen Ablauf oder Kontrollfluss innerhalb eines Prozesses oder einer Ereigniskette.

Externe Vertreter

[0095] Liegt ein Objekt ausserhalb eines Betrachtungsrahmens respektive ausserhalb eines bestimmten Prozessmodells, so wird dieses Objekt «Externer Vertreter» oder auch Partnerobjekt oder Fremdkomponente genannt. Ein Externer Vertreter ist wie ein Prozess eine Instanz eines Objektes mit allgemeinen sowie spezifischen Eigenschaften und Verhalten. Wird ein Prozess aufgeteilt und dadurch in Subprozesse zerlegt, so entstehen damit neue, vom Standpunkt des Subprozesses aus gesehene Externe Vertreter. Eine derartige Zerlegung 5 ist in Fig. 3 verkleinert gezeigt und in der Fig. 4 vergrössert dargestellt: P3 ist aufgeteilt in P3.1 bis P3.4, und aus den Prozessen P2, P4 und P6, die auf der höheren Ebene gemäss der Ansicht von Fig. 3noch Prozesse waren, sind aus Sicht der Subprozesse von P3 Externe Agenten entstanden. Externe Agenten können also je nach Kontext andere vordefinierte Objekte repräsentieren.

[0096] In einer weiteren Anwendung von Externen Agenten repräsentiert ein Externer Agent in einem ersten Modell ein komplettes anderes, zweites Modell. Dies bedeutet, er vereinigt alle Eigenschaften und Verhalten eines Modells. Der externe Agent kann somit ein Repräsentant für viele verschiedene Objekte oder Objektmengen sein. Zum Beispiel: Ein Externer Agent «Markt» stellt einen Platzhalter für eine weiter nicht modellierte Entität dar. Ein Externer Agent «Partner» repräsentiert einen modellierten Prozess, durch welchen der «Partner» eine Rolle durch Outsourcing übernommen hat und direkt in eine Prozesskette eingebunden wird. Ein Externer Agent «Abteilung» entspricht einem kompletten Teil eines Gesamtsystems, das in einem bestimmten Zusammenhang nicht im Detail interessiert.

[0097] Der Externe Agent wird als Repräsentant anschliessend normalerweise mittels Flussbeziehung mit einem Objekt innerhalb einer Modellgrenze verbunden.

Ereigniskette

[0098] Eine Ereigniskette repräsentiert einen wiederkehrenden Handlungsablauf innerhalb des Systems. Je nach Kontext werden Ereignisketten auch als Geschäftsvorfall, als «Use-Case» bezeichnet, als Wertschöpfungskette oder als «Business Value Chain».

[0099] Die einzelnen Schritte in einer Ereigniskette sind Aufgaben und Prozessschritte, die in einer Reihenfolge und mit gewissen Ausprägungen, ablaufen. Ein Datenfluss eines Geschäftsvorfalles beschreibt immer, woher und wohin eine bestimmte Information fliesst. Neben den grundlegenden Objektdefinitionen besitzt ein Objekt Ereigniskette die Besonderheit, dass es eine Kante und nicht einen Knoten eines Netzwerks darstellt. Entlang dieser Kante oder Kette wird beispielsweise ein Produkt verarbeitet oder gefertigt. Allgemein betrachtet, entsteht entlang einer Ereigniskette ein Mehrwert. Zur Darstellung von dabei ablaufenden Veränderungen wird die Ereigniskette in Teilflüsse oder Teilketten unterteilt, gemäss welchen einzelne Produkte oder Arbeitsmittel manipuliert werden. Die einzelnen Teilflüsse sind Prozessen und/oder Aktivitäten zugeordnet. Die Ereigniskette ist mittels Aktivitäten darstellbar respektive definierbar.

[0100] Zusammengefasst gesagt stellt ein Prozess einen Teil eines Systems dar, der in allgemeiner Weise zu verschiedenen Handlungen fähig ist, währenddem eine Ereigniskette oder eine Aktivität einmalig ausgeführte Handlungen bezogen auf einen konkreten Vorfall darstellen.

[0101] In der Fig. 5 sind mehrere Modellaspekte überlagert dargestellt: Prozesse sind durch Ovale, Aktivitäten durch horizontale abgerundete Rechtecke, und Ereignisketten durch dicke Pfeile symbolisiert. Vertikale abgerundete Rechtecke repräsentieren Elemente, die weiter unten erklärt werden.

[0102] Fig. 5 zeigt also zwei Ereignisketten, deren einzelne Teilflüsse immer mit einem Prozess oder mit einer Aktivität innerhalb eines Prozesses korrelieren. Es können dabei auch mehrere Teilflüsse einer Kette demselben Prozess oder derselben Aktivität zugeordnet sein. Elemente können mehrere Prozesse unterstützen, und ein Prozess kann durch mehrere Elemente unterstützt sein. Dies entspricht dem Sachverhalt, dass beispielsweise eine Fertigungszelle für mehrere Herstellungsprozesse verwendet werden kann, und umgekehrt. Weiter ist sichtbar, wie gewisse Teilflüsse einer Ereigniskette vollständig innerhalb eines Prozesses ablaufen und andere nur Verbindungen zwischen Prozessen repräsentieren.

Elementebene

[0103] Ein weiteres spezielles vordefiniertes Objekt stellt das Element dar. Ein Element stellt dar, wie ein Prozess oder eine Aktivität durch reale Entitäten unterstützt wird, Vorzugsweise werden vier Typen von Elementen verwendet: 1. Informationstechnologie (IT), 2. Organisation, 3. Werkzeuge, und 4. mechanisch-elektronische Module.

[0104] In der Fig. 5 wird diese Unterstützung von Prozessen und Aktivitäten durch ein oder mehrere Elemente (vertikale abgerundete Rechtecke) dargestellt. Indirekt wird also auch eine Ereigniskette durch ein oder mehrere Elemente indirekt unterstützt. Dabei muss die Ereigniskette auf der Prozessebene und diejenige auf der Elementebene nicht gleich unterteilt sein und müssen auch nicht die gleichen Arbeitsmittel dabei verwendet werden. Wesentlich ist aber, dass all die erwähnten Objekte in einer definierten Beziehung zueinander stehen, das heisst, dass durch entsprechende Beziehungen dargestellt wird, dass eine bestimmte Ereigniskette aus bestimmten Aktivitäten besteht und diese wiederum bestimmten Prozessen und Elementen zugeordnet sind...

Informations- und Funktionsebene

[0105] Die Informations- und Funktionsebene modelliert Einheiten, welche die Elemente unterstützen. Dies sind insbesondere informationstechnische Einheiten wie Daten und Verfahren, und zwar sowohl Daten, welche die Realität im System abbilden, als auch Metainformation über diese Daten. Daten sind beispielsweise Werte von in Datenbanken oder Programmen gespeicherten Attributen oder Variablen, sowie Messwerte und Steuerparameter von Anlagen und Maschinen. Metainformationen beschreiben eine Bedeutung von Daten, Datenstrukturen, Datenbankstrukturen, Ablageinformationen, logische Zusammenhänge oder Berechnungsvorschriften zur Umwandlung von Daten. Verfahren beschreiben Prozeduren oder Programme zur Datenverarbeitung und/oder Maschinensteuerung.

Beziehungstypen

[0106] Grundtypen und Objekte werden untereinander in Beziehung gesetzt. Dabei verwendete Beziehungstypen definieren ein Verhalten von zwei in Beziehung stehenden Objekten respektive Grundtypen. Beziehungstypen werden selber auch als Objekte modelliert. Es werden dabei vier Beziehungstypen unterschieden, die anschliessend detailliert beschrieben werden: <tb>a)<sep>Stehen zwei Objekte dauernd in Beziehung, so wird der Beziehungstyp Beständig oder «Permanent» zur Beschreibung verwendet. Diese Beziehung entspricht einer gegenseitigen Referenz gleichzusetzen. <tb>b)<sep>Löst ein Objekt bei einem anderen Objekt eine Reaktion aus, so wird der Beziehungstyp Wechselwirkung oder «Interaction» verwendet. Hiermit können definierte Wirkungen bei einem andern Objekt erzielt werden. <tb>c)<sep>Zur Darstellung einer dynamischen Situation wird der Beziehungstyp Fluss oder «Flow» verwendet. Hiermit wird dargestellt, dass nicht nur eine Wirkung, sondern auch Inhalte zwischen Objekten in einem bestimmten Zustand verschoben werden. <tb>d)<sep>Wird bei einer Verbindung zweier Objekte eine jeweilige Funktionalität dieser Objekte zueinander in Beziehung gesetzt, so wird der Beziehungstyp Differenz oder «Gap» definiert.

Der Beziehungstyp «Beständig»:

[0107] Es werden zwei beständige Beziehungstypen unterschieden, eine statische- und eine Umwandlungsbeziehung.

[0108] Eine statische Beziehung oder «Static» stellt eine ständige gegenseitige Beziehung zwischen zwei Objekten dar. Beispielsweise wird eine gegenseitige Referenz zweier Objekte durch eine statische Beziehung repräsentiert. Dabei werden in beiden Objekten Zeiger auf das andere Objekt beispielsweise als navigierbarer Link instanziert und beispielsweise mit dem Namen des anderen Objektes verknüpft. Diese gleiche Art Beziehung wird auch verwendet, wenn ein Objekt mit einem anderen Objekt in einer statischen Korrelation oder «Correlation» steht und diese Tatsache beständig aufgezeigt werden soll.

[0109] Die Umwandlungsbeziehung oder «Exchange» stellt eine Beziehung zwischen zwei unterschiedlichen vordefinierten Objekten dar, die festen Regeln, gemäss beispielsweise einer Typenwandlung, folgt. Es wird dabei ein Objekt umgewandelt in ein oder mehrere Objekte eines anderen vordefinierten Typs. In welchem Verhältnis und unter Anwendung welcher Regeln die Objekte zueinander stehen, wird in den jeweiligen betroffenen Objekten festgehalten. Über diese Beziehung kann nach der Instanzierung navigiert werden, und die in Beziehung stehenden Objekte kennen die Art der Umwandlung sowie die Details des jeweils anderen Objekts.

[0110] Beispielsweise stellen Umwandlungsbeziehungen dar, dass ein bestimmter Prozess mehrere bestimmte Aktivitäten aufweist. Ein Prozess «Fertigung» weist beispielsweise eine Menge von Aktivitäten wie «Produkt A fertigen», «Zwischenprodukt beschaffen» etc. auf. Diese wiederum sind jeweils einer oder mehreren Ereignisketten zugeordnet, was ebenfalls durch Umwandlungsbeziehungen dargestellt wird. Ein Prozess «Personalverwaltung» weist beispielsweise Aktivitäten «Mitarbeiter einstellen», «Beurteilen», «Entlassen».

[0111] Andere Umwandlungsbeziehungen stellen beispielsweise einen Zusammenhang zwischen einem Produkt und zwischen Serviceleistungen dar, die als Produkt betrachtbar sind.

Der Beziehungstyp «Wechselwirkung»:

[0112] Bei einer Wechselwirkungsbeziehung nimmt ein Objekt auf ein anderes in irgendeiner Form Einfluss oder steht in einer Abhängigkeit von diesem. Es entsteht aber nicht ein eigentlicher Fluss von Inhalten zwischen diesen Objekten, sondern die Beziehung selber beschreibt eine bestimmte, bekannte Art der Einflussnahme. Das eine Objekt nimmt aufgrund seiner Eigenschaften und seines Verhaltens Einfluss auf das andere. Vorzugsweise werden fünf verschiedene Arten von Wechselwirkung unterschieden:

[0113] Eine Wechselwirkungsart Einfluss oder «Influence» stellt eine prozentuale Abhängigkeit zwischen zwei Objekten dar, insbesondere einen prozentualen Verteilschlüssel oder Abhängigkeitsschlüssel. Beispielsweise hält eine Einflussbeziehung fest, dass ein bestimmtes Leistungs- oder Produktionsziel wie «weniger als 2% Ausschuss» oder «weniger als 5% Fluktuation» einem Prozess, beispielsweise der «Fertigungsabteilung», zugeordnet wird. Die Zuordnung geschieht durch beispielsweise ein Strategieobjekt. Ein Strategieobjekt verteilt also Ziele an andere Objekte, zwecks späterer Kontrolle der Zielerreichung.

[0114] Eine Wechselwirkungsart Unterstützung oder «Support» stellt eine prozentuale Abhängigkeit oder einen Verteilungsschlüssel mit vorgegebenen Regeln und Definitionen zwischen Eigenschaften zweier Objekte dar. Dieser Beziehungstyp ist speziell interessant, wenn sich vordefinierte Objekte auf unterschiedlichen Betrachtungsebenen befinden. Dann ist eine mehr oder weniger starke Abhängigkeit oder Kopplung der Ebenen darstellbar oder sichtbar. Beispielsweise stellen Unterstützungsbeziehungen dar, dass 60% von total verfügbaren Informatikmitteln oder -Services und 50% der Arbeitsleistung eines Verwalters zur Unterstützung einer bestimmten Produktionsabteilung notwendig sind. In einem anderen Beispiel stellen sie dar, dass ein Fertigungsprozess 30% einer NC-Maschine und 40% einer bestimmten Fertigungszelle benötigt.

[0115] Eine Wechselwirkungsart Effekt oder «Effect» stellt eine Wirkung durch Auslösen einer Reaktion basierend auf festen Regeln und Definitionen dar. Ein Verfahren oder ein Algorithmus zur Bestimmung der Reaktion ist in dem Objekt definiert, in welchem die Wirkung stattfindet. Die Wirkung findet bedingungslos statt, die Reaktion je nach Ergebnis dieses Verfahrens. Beispielsweise wirkt ein erstes Objekt durch Vermittlung von Werten für Risiko, Performance, Kosten, Qualität, Erfüllungsgrad etc. auf ein zweites. Das zweite Objekt bestimmt gemäss ihm eigenen Verfahren beispielsweise ein Gesamtrisiko oder ein Prozessrisiko etc.

[0116] Die Beziehung ist einseitig, in dem Sinne, dass die Wirkung nur in einem Objekt stattfindet und das auslösende Objekt nicht tangiert wird. Demzufolge muss zur Modellierung einer gegenseitigen Wirkung eine zweite Beziehung in entgegengesetzter Richtung instanziert werden.

[0117] Eine Wechselwirkungsart Wechsel oder «Change» stellt eine Wirkung dar, mit der eine Veränderung nach frei oder fest definierbaren Regeln erfolgt. Dabei weiss ein Objekt, welches eine Botschaft übermittelt, nicht, ob und wie diese Botschaft beim empfangenden Objekt verarbeitet wird. Die Art der Botschaft (»Messdaten», «Fehlerparameter» etc.) ist jedoch im Voraus bekannt. Beispielsweise werden mit dieser Wechselwirkungsart dargestellt: eine Übermittlung von Messwerten an einen Regler; nach Auslösen eines Fertigungsauftrags für ein Produkt werden mehrere betroffene Fertigungseinheiten angestossen; eine optische Fehlererkennung respektive das zugeordnete Modellobjekt übermittelt Fehlerdaten an eine Fertigungsstrasse, je nach Fehlerart werden Teile nachbearbeitet, wenn zu viele Fehler auftreten, wird eine betroffene Maschine justiert; eine Anzahl demotivierter Mitarbeiter wird übermittelt. Wenn ein bestimmter Anteil von Mitarbeitenden demotiviert ist, werden Stelleninserate ausgelöst; bei Einstellung eines neuen Mitarbeiters wird entsprechende Wechselinformation an verschiedene Objekte gesendet, welche darauf beispielsweise automatisch ein Stellenprofil erzeugen, ein E-Mail-Konto einrichten, ein Eintrittsgespräch veranlassen etc.

[0118] Eine Wechselwirkungsart Verbinden oder «Join» stellt eine Vermittlung von Zielen oder Leistungsmerkmalen wie Risiko, Kosten und verschiedene messbare Grössen dar. Die Ziele werden von einem übergeordneten Objekt mittels dieser Wechselwirkungsart auf mehrere untergeordnete Objekte heruntergebrochen oder verteilt, d.h., jedes der untergeordneten Objekte erhält dadurch ein eigenes Teilziel, das es zu erfüllen hat und das zur Beurteilung mit tatsächlichen Ergebnissen verwendbar ist.

Der Beziehungstyp «Fluss»:

[0119] Bis jetzt wurden nur statische Beziehung definiert, über welche Abhängigkeiten oder Berechnungen erstellt werden können. Die Art der Beziehung und der vermittelten Information war immer im Voraus bekannt. Die nachfolgenden zwei Definitionen definieren Abhängigkeiten, bei denen ein Fluss dargestellt werden soll, wobei der wesentliche Unterschied zum Bisherigen darin liegt, dass zwischen zwei vordefinierten Objekten ein Inhalt verschoben wird, dessen Verarbeitung etwas Unvorhergesehenes auslösen kann. Dieser Inhalt entspricht wieder einem vordefinierten Objekt. Mittels dieser Flussbeziehungen lassen sich dynamische und inhaltliche Abhängigkeiten darstellen.

[0120] Eine Abhängigkeitsart Inhalt oder «Content» stellt eine inhaltliche Beziehung zwischen zwei vordefinierten Objekten dar, wobei ein übermittelter Inhalt, beispielsweise eine Datei, je nach Interpretation durch das empfangende Objekt eine Reaktion auslöst. Die Inhaltsbeziehung stellt also eine dynamische Verbindung auf unterschiedlichen Detaillierungsebenen dar.

[0121] Bei einer Abhängigkeitsart Ereignis oder «Event» stellt der Inhalt nur einen Auslöser dar. Im Gegensatz zu einer Wechselbeziehung ist jedoch der Inhalt durch das empfangende Objekt definiert und vorgegeben.

Der Beziehungstyp «Differenz»:

[0122] Eine Differenzbeziehung stellt Unterschiede zwischen zwei vordefinierten Objekten dar und macht sie nachvollziehbar. Beispielsweise stellen die beiden Objekte einen Ist-Zustand und einen Soll-Zustand eines Systems dar, die Differenzbeziehung die Unterschiede zwischen den beiden Zuständen.

[0123] Als Übersicht ist im Folgenden für die verschiedenen Beziehungstypen angegeben, zwischen welchen Objekten sie vorzugsweise verwendet werden. Wichtige Beziehungstypen sind insbesondere die statische Beziehung, Einflussbeziehung und Inhaltsbeziehung. <tb>Beziehungstyp<sep>Beteiligte Objekte <tb>Beständig<sep> <tb>– Statisch<sep>alle Typen <tb>– Umwandlung<sep>Prozess – Aktivität, Element – Interface, Interface – Service, Service – Parameter <tb>Wechselwirkung<sep> <tb>– Einfluss<sep>Strategie – Objekt, Anforderung – Objekt <tb>– Unterstützung<sep>Prozess – Element, Prozess – Ereigniskette, Aktivität – Ereigniskette <tb>– Effekt<sep>Interdependenz Risiko, Personelles, Kosten, andere <tb>– Wechsel<sep>Target – Risk, Target – Measurement <tb>– Verbinden<sep>Risiko, Messung, Anbindung <tb>Fluss<sep> <tb>– Inhalt<sep>Prozess – Externer Agent, Prozess – Prozess, Ereigniskette – Objekt; wenn Inhalt transportiert wird <tb>– Ereignis<sep>Prozess – Externer Agent, Prozess – Prozess, Ereigniskette – Objekt; wenn nur Auslöser definiert wird <tb>Differenz<sep>alle Typen, über Compare & Merge – Verbindungen

Produkt

[0124] Es werden zwischen drei Arten von Produkten unterschieden, die alle einen oder mehrere Zustände einnehmen können: Ein Produkt selbst, als höchste Abstraktion, sowie ein Arbeitsmittel und ein Ergebnis. Das Arbeitsmittel repräsentiert alle Arten von Inhalten, die in Zusammenhang mit der Unternehmensentwicklung und Prozessführung verwendet werden. Das Arbeitsmittel stellt auch die kleinste Einheit eines Produktes dar. Arbeitsmittel können isoliert oder in verschiedenen anderen Kombinationen vorkommen und können in unterschiedlichen Ebenen und verschiedenen Kombinationen entstehen. Ein Arbeitsmittel kann also beispielsweise ein physischer Teil eines Produktes sein, aber auch eine computerlesbare Datei respektive die darin enthaltene Information. Eine Menge von Arbeitsmitteln definiert ein Elementarprodukt. Das Elementarprodukt kann mit anderen Elementarprodukten zu einem (zusammengesetzten) Produkt oder «Composite Product» kombiniert werden. Ein Objekt «Produkt» repräsentiert eine zusammenfassende und/oder wechselnde Sicht auf mehrere Arbeitsmittel. Beispielsweise ist dies die Tatsache, dass ein Gegenstand aus einer Menge von Komponenten besteht respektive hergestellt wird, oder dass eine chemische Verarbeitung von Eingangsstoffen einen Ausgangsstoff ergibt, oder dass eine Aufstellung über Hard- und Softwarekosten auf einer anderen Betrachtungsebene als Gemeinkosten und wieder einer anderen Ebene als Investitionen betrachtet werden.

Zusammenfassung

[0125] Die bisher definierten Objekte stehen in einem Modell in verschiedenen Abhängigkeiten zueinander. Diese Abhängigkeiten sind in der Fig. 6 in einer Übersicht für ein beispielhaftes Modell dargestellt. Ein Prozessmodell besteht aus Prozessen P1–P6, die mittels Flussbeziehungen miteinander verbunden sind. Besteht eine Beziehung über die Modellgrenze hinaus, erfolgt diese zu einem Externen Vertreter EA1–EA6. Über diese Beziehungen fliessen Arbeitsmittel oder Produkte in einem definierten Zustand. Alle diese Objekte können aufgeteilt (Prozess in Subprozess) oder mittels eines anderen Objekttyps beschrieben werden (Prozess durch Aktivität), was durch entsprechende Beziehungen darstellbar ist. Die Prozesse P1–P6, Externen Vertreter EA1–EA6 sowie Aktivitäten werden durch Elemente eines vordefinierten Typs unterstützt. Mit Prozessmodellen werden Aufgaben und Abläufe sowie Zusammenhänge charakterisiert, mit dem Elementmodell die Infrastruktur- und Organisationsunterstützung, und mit dem Informations- und Funktionenmodell spezifische Details. Diese drei Modelle bilden zugleich auch Betrachtungsebenen. Eine dreidimensionale Darstellung 9 visualisiert das Vorhandensein von Betrachtungssegmenten als auch Betrachtungsebenen, Um konkrete Anwendungsfälle und deren Wertveränderungen zu dokumentieren, können Ereignisketten 6 auf Stufe Prozess, Aktivität oder auf Stufe Element definiert werden. Die einzelnen Teilflüsse der Ereigniskette 6 werden mit den entsprechenden Objekten einer bestimmten Betrachtungsebene verbunden respektive in Beziehung gebracht. Das vordefinierte Objekt Ereigniskette stellt also spezifische Abläufe dar und kann auf allen Betrachtungsebenen verwendet werden. Es wird im Detail beispielsweise durch ein Aktivitätendiagramm 7 dargestellt. Aktivitätendiagramme sind auch zur Darstellung von Abläufen 8 innerhalb von Prozessen verwendbar. Ereignisketten bilden zusätzlich zu den Modellen eine zusätzliche Dimension und verknüpfen Objekte und Ebenen. Dadurch werden verschiedene Analysen und Berechnungen vereinfacht oder überhaupt ermöglicht. Ferner wird das Produktmodell verwendet und das Projektmodell, welches sämtliche Veränderungen zwischen zwei Zeitpunkten abbildet.

[0126] Die Modellierungsprinzipien sind im Folgenden anhand eines sehr einfachen Beispiels dargestellt:

[0127] Fig. 7 zeigt vordefinierte Objekte Externer Vertreter EA und Prozesse PA, PB, sowie als Pfeile dargestellte gerichtete Beziehungen, und Arbeitsmittel 10, die für die Definition der Beziehungen relevant sind. Ferner ist eine Verwendung der Grundtypen in einer detaillierteren Darstellung des Externen Vertreters EA und in den Prozessen PA, PB abgebildet. Abhängig von der Instanzierung und den Eigenschaften ist die Komplexität grösser oder kleiner. Dies ist im Externen Vertreter EA durch die Verwendung von nur gerade zwei Grundtypen ausgedrückt. Würde ein gewisses Mass an Komplexität überschritten, so würden anstelle dieser Grundtypen verschiedene vordefinierte Objekte verwendet.

[0128] In der Fig. 8 wird Prozess PB alternativ zu der Darstellung durch Grundtypen durch ein Aktivitätendiagramm definiert. Da es sich bei Aktivitäten wiederum um vordefinierte Objekte handelt, weisen sie auch eine definierte Menge von Grundtypen auf, respektive sind durch diese ausgedrückt. Fig. 9zeigt eine vergrösserte Version des Aktivitätendiagramms, mit Verzweigungen, parallelen Pfaden, Sequenzen etc. und beispielhaft eine Darstellung einer einzelnen Aktivität durch eine Menge von Grundtypen.

[0129] In der Fig. 10 sind die Arbeitsmittel 10, die über die Beziehungen verschoben werden, detailliert dargestellt. Ein Produkt 10 respektive ein Arbeitsmittel 10 kann wiederum aus mehreren anderen Arbeitsmitteln 11 bestehen, was über eine entsprechende objektorientierte Softwaredefinition darstellbar ist. Aus dieser Abbildung ist ebenfalls ersichtlich, dass die Arbeitsmittel zugleich auf der einen Seite den Output und auf der andern Seite den Input von Prozessen darstellen.

[0130] Bis zu diesem Punkt sind im Beispiel noch keine konkreten Anwendungsfälle definiert worden, sondern nur das ganze System, welches ein Potenzial zur Bearbeitung von Anwendungsfällen aufweist. Mit Ereignisketten werden konkrete Anwendungsfälle dargestellt, die in der Praxis auftreten können und einen kleineren oder grösseren Teil des Systems beanspruchen. In der Fig. 11 ist eine solche Ereigniskette durch gestrichelte Pfeile dargestellt. Daraus ist ersichtlich, dass oft nur ein Teil der Systemdefinition, also beispielsweise der Prozesse und Aktivitäten, in einer bestimmten Ereigniskette Verwendung findet.

[0131] Basierend auf den eingeführten Modellelementen und -zusammenhängen aufgrund der vordefinierten Objekte können die im Folgenden beschriebenen weiteren Verfahren, Analysen und Berechnungen durchgeführt werden. Es wird dabei im Folgenden eingegangen auf Automatische Modellgenerierung und -aufdatierung; Qualitätsprüfung von Modellen; Risikoanalysen Analyse von Kosten und deren Beziehungen; Performancebewertung; Vergleich von Modellen respektive dargestellten Systemen; Prozessteuerung; und Benutzerschnittstellen.

Manuelle und automatische Modellbildung

[0132] Um ein konkretes System, also ein Fabrikationssystem oder ein Unternehmen oder eine Organisation, darzustellen, werden verschiedene Informationen erhoben und als Instanzwerte vordefinierter Objekte abgebildet und werden Zusammenhänge der Objekte ebenfalls im Modell dargestellt. Diese Informationserfassung geschieht manuell und/oder automatisch.

[0133] Bei der manuellen Erfassung werden vorzugsweise Ikonen, welche die Objekte darstellen, durch bekannte Zeigemittel wie eine Computermaus auf einem Bildschirm platziert. Beziehungen werden durch Verbinden der Ikonen eingegeben. Zur Spezifikation respektive Instanzierung von Attributen sind beispielsweise zu jedem Objekt Eingabemasken darstellbar, welche Textfelder, Menülisten und andere bekannte Eingabehilfsmittel aufweisen. In einer bevorzugten Ausführungsform der Erfindung werden Objekte in einer Baumstruktur dargestellt und manipuliert.

[0134] Vorzugsweise wird dabei folgendermassen vorgegangen: Als Erstes werden Prozessmodelle erstellt, anschliessend werden Ereignisketten auf die Prozessebene gelegt und werden diese Ketten durch Aktivitäten spezifiziert. In analoger Weise wird auch die Spezifikation der Prozesskontrollflüsse erstellt. Parallel zu diesen Prozessarbeiten werden auch Produktdefinitionen erstellt. Die Produktdefinitionen werden speziell bei Beziehungen zwischen zwei Objekten verwendet. Ist die Prozessebene vervollständigt, wird die Elementebene kreiert. Die benötigten Elementtypen werden erzeugt und in die korrekte Abhängigkeit zu den Prozessen und zueinander gestellt.

[0135] Mit diesen Schritten wird ein konkretes Elementmodell erzeugt. Die einzelnen Elemente werden anschliessend mit den Objekten auf der Prozessebene verknüpft. Anschliessend werden die Ereignisketten auf der Elementebene erfasst. Als letzte Ebene wird die Informations- und Funktionsebene kreiert und mittels spezieller vordefinierter Objekte beschrieben. Diese Objekte sind vorzugsweise speziell auf die Darstellung von Informatikgrundlagen respektive Daten und Funktionsbeschreibungen ausgerichtet. Sie beschreiben also beispielsweise Datenstrukturen, Zugriffsbeziehungen, Einzeldaten und ihre Bedeutung, Schnittstellen etc.

[0136] Die automatische Erfassung erfolgt durch spezielle Analyseprogramme, welche eine bestehende informationsverarbeitende Struktur oder Anlage durchsuchen, Zusammenhänge zwischen datenverarbeitenden und/oder datenspeichernden Einheiten ermitteln und verschiedene Arten von Objekten und Beziehungen zur Abbildung dieser Daten und Zusammenhänge im Modell erstellen. In einer bevorzugten Variante der Erfindung wird dabei das folgende Verfahren verwendet: Eine Informatiklandschaft oder ein Softwaresystem weise mehrere Verarbeitungseinheiten, das heisst Programme und/oder Datenbanken auf, wobei die Programme durch Aufrufe miteinander und den Datenbanken verknüpft sind.

[0137] Das Verfahren liest systematisch den Code aller Programme, beispielsweise einen COBOL-Quellcode, und hält in jedem Programm fest, welche anderen Programme mit welchen Übergabeparametern und welchen Resultaten aufgerufen werden. Ebenso wird festgehalten, auf welche Datenbanken und gegebenenfalls auf welche Tabellen der Datenbanken mit welchen Abfragen und Resultaten zugegriffen wird. Ebenso werden innere Verknüpfungen der Datenbanken erfasst. Das Verfahren wird rekursiv auf jedes Programm und jede Datenbank angewendet, bis alle durchlaufen sind und damit alle existierenden Verknüpfungen durch Aufrufe respektive Abfragen erfasst sind. Während der Erfassung werden in einem Modell automatisch Objekte zur Darstellung der jeweils gefundenen Programme, Datenbanken und Verknüpfungen erzeugt. Dafür werden vorzugsweise die vordefinierten Objekte Element, Interface und Arbeitsprodukt verwendet. Je nach Objekttyp wird der Scanner konfiguriert und füllt alle Objekte und Beziehungen zwischen den Objekten gemäss Definition ab. Beispielsweise werden ein reales Programm und eine Datenbank je durch Objekte dargestellt, Datenbankabfragen durch Beziehungstypen, und Resultate von Datenbankabfragen durch Arbeitsprodukte.

[0138] Die gefundenen Elemente und Verknüpfungen definieren einen Graphen. Dieser wird visuell, beispielsweise als Graph mit Knoten und Kanten, oder als Verknüpfungsmatrix dargestellt. Damit entsteht eine anschauliche Darstellung der Abhängigkeiten, die insbesondere kritische Komponenten des Informatiksystems erkennen lässt. Solche sind beispielsweise eine Datenbank oder eine Tabelle, auf die von einer grossen Anzahl anderer Programme zugegriffen wird. Eine Änderung einer Schnittstelle zu einer solchen Komponente würde somit einen grösseren Aufwand bedingen. Umgekehrt werden auch wenig oder gar nicht genutzte Komponenten ermittelt.

[0139] Modellteile sind alternativ dazu auch aus Daten von bekannten Management-Werkzeugen erzeugbar. Durch Konversionsprogramme werden solche Daten aus Datenbanken oder Exportdateien gelesen und Objekte zur Darstellung der relevanten Modellteile automatisch erzeugt. Umgekehrt lassen sich Modellinformationen zur Verwendung und/oder visuellen Darstellung in anderen Programmen exportieren.

[0140] Die oben betrachteten Modellierungsverfahren betreffen primär eine Modellierung von Strukturen und in zweiter Linie auch eine Erfassung von Modellparametern respektive von Attributen von Objekten, die in diese Strukturen eingebettet sind. Ist eine Struktur im Wesentlichen bekannt, so lassen sich Parameter automatisch ermitteln. Dazu werden mehrere physikalische Sensoren, oder aber Hilfsprogramme, die zur Extraktion von Daten aus einem laufenden System dienen, eingesetzt. Im Folgenden werden auch diese Hilfsprogramme als Sensoren bezeichnet. Von Sensoren erfasste Werte stammen also aus realen Komponenten des Systems und bewirken einen Abgleich des Modells mit dem real ablaufenden System. Die Werte werden entsprechenden Objekten im Modell zugeführt, welche diese Komponenten modellieren. Gemäss den im Modell enthaltenen objekt- und benutzerspezifischen Regeln werden die Werte weiterverarbeitet, beispielsweise durch Speicherung im Objekt, Aufdatierung des Modells mit aktuellen Werten oder durch statistische Analysen der Werte, Regelung oder Steuerung des Systems, etc.

[0141] Bei der Modellbildung wird in einer bevorzugten Variante der Erfindung über ein Interface-Engine, welche ein Schema für die Objekterzeugung realisiert, eine Objekterzeugungs-Engine mit Befehlen zur Objektmanipulation angesteuert. Durch einen versierten Benutzer kann auch direkt auf die Objekterzeugungs-Engine zugegriffen werden. Die Objekterzeugungs-Engine greift auf ein Framework zu, welches die Grundtypen mit den vordefinierten Objekten in Beziehung setzt, und erzeugt respektive instanziert die benötigten Objekte, Verknüpfungen zwischen ihren Ein- und Ausgängen, und weitere Beziehungen zwischen den Objekten.

Modellverifikation, Qualitätsprüfung

[0142] Nachdem ein Modell teilweise oder vollständig kreiert worden ist, wird es durch verschiedene Analysen auf die korrekte Verwendung einzelner Objekte und deren Beziehungen hin untersucht. Dies geschieht beispielsweise mit den folgenden Überprüfungsverfahren, die zusammengefasst auch als Prüfungen der Modellqualität bezeichnet werden:

[0143] Eine Modellüberprüfung kontrolliert, ob ein externer Agent, ein Prozess, ein Arbeitsprodukt und eine Prozessschnittstellenbeschreibung definiert wurden, und ob die Objekte gemäss ihrer Definitionen korrekt und vollständig mit anderen Objekten in Beziehung stehen, ob keine offenen Beziehungen definiert sind und ob Objekte nicht in einem undefinierten Zustand verwendet werden.

[0144] Eine Vollständigkeitsprüfung kontrolliert, ob ein Prozess korrekt durch Elemente und Aktivitäten unterstützt wird und ob ein Prozess in einer Ereigniskette verwendet wird.

[0145] Eine Konsistenzprüfung auf Objektebene kontrolliert, ob ein Objekt nicht unbenutzt und völlig ohne Beziehungen durch Referenzen oder Flussbeziehungen ist, ob es nichtexistierende Objekte referenziert.

[0146] Eine Transparenzprüfung kontrolliert, ob Objekte ein Ziel und eine Beschreibung aufweisen. Konkret entspricht dies beispielsweise einer Prüfung, ob bestimmte Textfelder einer Maske zur Objektbeschreibung ausgefüllt worden sind, also einen Inhalt aufweisen.

[0147] Eine Qualitätsdefinitionsprüfung kontrolliert, ob Qualitätsvorgaben an einzelne Objekte mittels einer Metrik definiert sind. Nur wenn diese vorliegen, ist eine spätere Beurteilung einer Qualität eines Prozesses oder einer Ereigniskette etc. möglich. Konkret entspricht dies beispielsweise einer Prüfung, ob Qualitätsvorgaben enthaltende Felder einer Maske zur Objektbeschreibung einen Inhalt aufweisen, und dieser Inhalt gegebenenfalls bestimmten Konventionen entspricht. Bei der Qualitätsbeurteilung werden unter Anwendung von Metriken Zusammenhänge, Beziehungen und Inhalte verifiziert und mittels Aussagen zur Qualität quantifiziert.

[0148] Die Qualitätsvorgaben und Qualitätsmerkmale von Objekten sind zu unterscheiden von der hier betrachteten Prüfung der Qualität des Modelles selber!

[0149] Warnungen werden erzeugt, wenn ein Prozess nur einen eintretenden oder nur einen austretenden Fluss aufweist. Die erwähnten Analysen können durch Plug-ins und unter Anwendung benutzerspezifischer Regeln erweitert werden.

[0150] Die bisher genannten Prüfungen der Modellqualität betreffen also Konsistenz, Richtigkeit und Vollständigkeit des Modells.

[0151] Eine weitergehende Konsistenzprüfung wird durchgeführt, indem festgestellt wird, ob unterschiedliche Modellaspekte desselben Sachverhalts oder Aspekts der Realität miteinander übereinstimmen. Wenn somit das gleiche Objekt in zwei unterschiedlichen Modellen mit unterschiedlichem Detaillierungsgrad oder mit unterschiedlicher Sicht auf die Anwendung verwendet wird, kann eine Aussage zur Richtigkeit gemacht werden. Insbesondere werden Ereignisketten mit Prozessschnittstellenbeschreibungen verglichen.

[0152] Fig. 12 zeigt schematisch eine Grundlage für Validierungsverfahren. Unter Validieren wird das Prüfen von Zuständen, Abläufen und Modellen mittels mindestens eines weiteren Modells oder eines anderen Modellaspekts verstanden. Teilmodelle auf Prozessebene 13, Element- oder Unterstützungsebene 14 und auf Informations- und Funktionsebene 15, sowie Ereignisketten BVC und Modelle Externer Agenten 12 auf jeder dieser Ebenen und Produktedefinitionen 16 bilden jeweils verschiedene Aspekte des Systems im Modell ab. Diese Teilmodelle überschneiden einander in bestimmten Bereichen und müssen, falls das Modell korrekt sein soll, in diesen Bereichen konsistent sein. Wenn also beispielsweise die Ereignisketten respektive Geschäftsvorfälle mit dem Prozessmodell und deren Definition verglichen werden, kann eine Aussage zur Qualität des Prozessmodells und der Geschäftsvorfallmodelle gemacht werden. Die Ausweisung der Qualität kann einerseits als Kennzahl oder mittels Detailinformationen über Widersprüche und Übereinstimmungen erfolgen.

[0153] Fig. 13 illustriert ein konkretes Beispiel. In einem oberen Teil der Figur sind zwei Prozesse P1, P2 und ein Externer Vertreter EA1 dargestellt. Zwischen P1 und EA1 sowie zwischen P2 und EA1 sind Prozessschnittstellenbeschreibungen definiert.

[0154] Diese beschreiben, welche Arbeitsmittel über die jeweilige Schnittstelle verschoben werden. In einem technischen System sind dies beispielsweise Produkte, Einzelteile, Fertigungsparameter, Bestelldaten, Maschinensteuerdaten, Messergebnisse etc. In einem administrativen Prozess sind dies beispielsweise Produkte, Quittungen, Zahlungen, Bestellungen etc.

[0155] In einem unteren Teil der Fig. 13ist eine Ereigniskette dargestellt, welche die erwähnten Prozesse P1, P2 und den Externen Vertreter EA1 durchläuft. Die Ereigniskette wird vorzugsweise separat von den Prozessschnittstellenbeschreibungen definiert. Sie beschreibt eine systematische Aneinanderreihung von Ereignissen und Aktionen, sowie das Verschieben von Arbeitsmitteln respektive Produkten. Die Qualitätsüberprüfung hat zur Grundlage, dass jeder Input und jeder Output eines Prozesses im Rahmen eines Geschäftsvorfalls erzeugt wird. In einer in der Fig. 13 dargestellten Matrix werden Zeilen entsprechend Prozessen, die Arbeitsmittel abgeben (Output) bezeichnet, und Spalten entsprechend denselben Prozessen, aber als Empfänger von Arbeitsmitteln (Input). In den Feldern der Matrix werden etwaige Arbeitsmittel eingetragen, die von einem Prozess zum anderen verschoben werden. Dadurch erhält man eine Übersicht über sämtliche Schnittstellen zwischen Objekten. Dieselbe Matrix wird verwendet, um darauf die Arbeitsmittel einzutragen, die durch einen Geschäftsvorfall verwendet werden. Nun kann festgestellt werden, ob eine Überdeckung vorliegt, das heisst, dass ein Arbeitsprodukt in beiden Definitionen auftritt. Bei einem Arbeitsmittel, das keine Überdeckung aufweist, ist entweder die Prozessdefinition oder die Definition des Geschäftsvorfalls unvollständig. In der Beispielmatrix sind Arbeitsprodukte, die nur in der Prozessschnittstellenbeschreibung verwendet wurden, in Normalschrift, jene, die nur in einer Ereigniskette verwendet wurden, in Kursivschrift, und in Fettschrift jene, die in beiden Beschreibungen auftreten.

[0156] In der Fig. 13 ist ferner dargestellt, wie Arbeitsmittel erzeugt («Create») und gespeichert («Store») und Ereignisse übermittelt werden («Send Event»).

[0157] Dasselbe Prinzip wird auch für andere vordefinierte Objekte und andere Arten von Zusammenhängen angewendet: Vorzugsweise wird dabei die Konsistenz von Beschreibungen einer Ereigniskette auf verschiedenen Betrachtungsebenen überprüft. Beispielsweise werden eine Ereigniskette auf Stufe Prozess und die gleiche Ereigniskette auf Stufe Element miteinander verglichen. Bei dieser Betrachtung, unter Berücksichtigung, dass Prozesse und ihre unterstützenden Element durch Beziehungen miteinander verbunden sind, kann eine Validierung und eine Qualitätsaussage über Objekte auf verschiedenen Ebenen gemacht werden. Dies im Gegensatz zu Fig. 13, wo nur eine Ebene, aber eine Beschreibung mittels zweier verschiedener Objekte vorliegt.

[0158] Vorzugsweise wird dazu, wo einer ersten Schnittstelle zwischen Objekten auf einer ersten Modellierungsebene eine zweite Schnittstelle zwischen Objekten auf einer zweiten Modellierungsebene zugeordnet ist, zur Bildung einer Konsistenzaussage überprüft, ob ein Arbeitsmittel, welches über die erste Schnittstelle übergeben wird, und ein Arbeitsmittel, welches über die zweite Schnittstelle übergeben wird, einander zugeordnet sind respektive einander entsprechen. Für mehrere Schnittstellen, die zu jeweiligen Ereignisketten auf den beiden Modellierungsebenen gehören, wird analog verfahren: es werden also die Schnittstellen in beiden Modellierungsebenen über die ganze Ereigniskette hinweg miteinander verglichen.

Risikoanalyse

[0159] Für die Berechnung und das Propagieren von Risiken gelten die folgenden Prinzipien: Grundsätzlich kann jedem Objekt ein Risiko-Objekt zugeordnet sein. Insbesondere ist dies zweckmässig für Prozesse, Elemente, Arbeitsmittel, Ereignisketten u.a. Ein Risiko-Objekt weist auf eine numerische Repräsentation eines Risikos des Objekts, sowie Regeln oder Berechnungsvorschriften zur Bestimmung des Risikos anhand von Risiken und von sonstigen Attributen anderer Objekte, insbesondere von Messwerten von Grössen des Systems. Das Risiko ist ein Mass für die Wahrscheinlichkeit, dass das betreffende Objekt seine Funktion nicht erfüllt oder dass bestimmte seiner Eigenschaften nicht korrekt sind.

[0160] Das Risiko wird beispielsweise auf einer Skala zwischen 0 und 100 dargestellt. Zur graphischen Darstellung sind einzelnen Bereichen dieser Skala unterschiedliche Farben (Grün/Gelb/Rot) zugeordnet und werden, den Objekten zugeordnet, in Tabellen, Matrixdarstellungen oder Diagrammen einem Benutzer oder Systemüberwacher dargestellt.

[0161] Regeln zur Risikoberechnung sind beispielsweise in textueller Form mit üblicher Syntax ausgedrückt, z.B. im Sinne von WENN «Risiko von Prozess A» > 60 UND «Ausschuss von Fertigungszelle X» > 10% DANN «Risiko von Unterbruch der Gesamtfertigung um 10% erhöhen»

[0162] Regeln zur Handlung aufgrund von Risiken drücken beispielsweise aus, dass beim Überschreiten bestimmter Risikoschwellwerte Nachrichten via E-Mails oder SMS (Short Message System) automatisch verschickt werden, Alarme ausgelöst werden oder in eine Produktionssteuerung eingegriffen wird. Letzteres geschieht beispielsweise durch Ausserbetriebnahme einer Maschine oder durch Anpassung von Steuerparametern, so dass langsamer, aber mit besserer Qualität gearbeitet wird. Dabei ist zweckmässig, dass die Risiken entsprechend von aktuellen Messwerten aus dem System berechnet und laufend aktualisiert werden.

[0163] Für jedes Objekt sind auch andere Risiken definierbar. Für jedes Risiko werden vorzugsweise eine Beschreibung und beschreibende Attribute wie Eintrittswahrscheinlichkeit, eine Tendenz, ein Frühwarnindikator, Netto- und Brutto-Risiko, Kosten, ein oder mehrere Aktionen zur Verhinderung des Risikos etc. definiert.

[0164] Will man das Risiko entlang einer Kette rechnen, zum Beispiel entlang einer Ereigniskette, so gilt das grösste entlang der Kette ermittelte Risiko als das Risiko der ganzen Kette, sofern die gegenseitige Beeinflussung der Risiken immer positiv ist und in der Flussrichtung erfolgt. Wirken auf eine Kette weitere Risiken als Einflussgrössen, wird, abhängig von der Risikowirkung und der Richtung, der Risikowert ermittelt.

[0165] In einer bevorzugten Ausführungsform der Erfindung wird mit einer Monte-Carlo-Simulation eine Variation von Risiken und deren Abhängigkeiten durchgespielt und bestimmt, welche Objekte besonders anfällig oder sensitiv sind. In einer anderen automatischen Analyse wird beim Vorliegen von Schlaufen in der Risikoberechnung durch mehrere Objekte detektiert, ob sich die Risiken aufschaukeln, in Extremwerte laufen, oder sich stabilisieren.

Beziehungsanalyse

[0166] Fig. 14 zeigt vereinfacht verschiedene Objekte eines Modells, die in Beziehung untereinander stehen. Ereignisketten respektive Geschäftsvorfälle BVC1–BVC4 auf der Prozessebene durchlaufen Prozesse P1–P3, wobei einzelne Geschäftsvorfälle auch einzelne Prozesse überspringen können. Auf der Elementebene entspricht den Ereignisketten BVC1–BVC3 die Ereigniskette BVC5, und der Ereigniskette BVC4 die Ereigniskette BVC6. Die Prozesse P1–P3 werden unterstützt durch Elemente E1–E4. Diese Unterstützungsbeziehungen werden in der Fig. 14durch Linien dargestellt. Beispielsweise unterstützt Element E2 die Prozesse P1 und P2. Ein Grad der Unterstützung ist in der Figur durch Prozentzahlen ausgedrückt. So zeigt die Linie zwischen P1 und E2 an, dass 10% des Bedarfes von Prozess P1 durch Element E2 abgedeckt wird, und 10% der Leistung von E2 durch P1 verbraucht werden. Bedarf respektive Leistung werden einerseits durch absolute Werte, beispielsweise in Arbeitsstunden, Kosten, Stückzahlen, etc. ausgedrückt. Andererseits werden die Werte bei Betrachtung eines Prozesses, eines Elements, einer Ereigniskette etc. auf einen jeweiligen Gesamtbedarf des Prozesses respektive auf eine Gesamtkapazität des Elements etc. bezogen und durch Prozentzahlen ausgedrückt. So wird sichtbar, wie mehrere Elemente anteilsmässig zu einem Prozess beitragen, und umgekehrt, wie sich die Leistung eines Elements auf mehrere Prozesse verteilt. In der Fig. 14 wird zur Vereinfachung der Darstellung angenommen, dass die Prozentzahlen bei allen Prozessen P1–P3 und Elementen E1–E4 auf denselben Wert bezogen sind. Prozess P1 wird nach dieser Analyse nicht vollständig unterstützt, Prozess P3 erfährt eine doppelt so grosse Unterstützung als eigentlich nötig wäre. Element E3 ist mit 130% überlastet, und Element E1 ist nur zu 70% ausgelastet.

[0167] Die Kosten eines Geschäftsvorfalles errechnen sich aus den prozentualen Anteilen der Prozesskosten: Ein Element unterstützt einen Prozess mit einem bestimmten Anteil der Elementkapazität, und der Prozess wird zu einem bestimmten Anteil seines Gesamtbedarfs durch das Element unterstützt. Daraus werden Gesamtkosten berechnet: Beispielsweise entfallen Kosten in BVC4 zu 40% auf den Prozess P1 und zu 60% auf den Prozess P3.

[0168] Von den Elementkosten werden so über die Prozesskosten die Gesamtkosten eines Geschäftsvorfalles berechnet. Unterstützt ein Element gar keinen Prozess, wie zum Beispiel E1, so werden seine Kosten über die Geschäftsvorfälle verteilt. Gesamtkosten für einen Geschäftsvorfall sind mit einem erzielten Preis aus dem Verkauf des entsprechenden Produktes A, B, C, D vergleichbar.

[0169] Die Kosten des gleichen Geschäftsvorfalls, aber auf Elementebene, also BVC6, entfallen zu 40% auf E2 und zu 60% auf E5. Element E1 trägt zwar zu 70% zu Prozess P1 bei, unterstützt aber keinen Prozess auf Elementebene.

[0170] Falls die Summe der Geschäftsvorfälle weniger als hundert Prozent eines Prozesses benötigt, erhält ein Wert für die Performance des Prozesses einen reduzierten Wert als Ausdruck einer ungenügenden Performance.

[0171] Basierend auf der erläuterten Modellierungsweise und Berechnungsprinzipien werden also wesentliche Aussagen über Prozesskosten und deren Entstehung gemacht.

[0172] Das anhand der Kosten dargestellte Vorgehen wird vorzugsweise auch für andere Eigenschaften angewendet, die als prozentuale Abhängigkeiten zwischen Objekten darstellbar sind, beispielsweise Risiken.

[0173] Eine Modellierung von Kosten geschieht oft über verschiedene Stufen einer Objekthierarchie. Beispielsweise beschreibt die Objekthierarchie ein Produkt und seine Zusammensetzung aus Teilprodukten, oder ein hierarchisch gegliedertes Sortiment von Produkten. Bei der Modellerzeugung und Modellparametrierung werden Kosten an verschiedenen Stellen erfasst. Diese Kosten müssen konsistent sein und erlauben, unter Umständen fehlende Informationen automatisch zu bestimmen.

[0174] Fig. 15 illustriert, wie dabei vorgegangen wird: Es sei eine Baumstruktur gegeben, in welcher ein Elternknoten 20 mehrere ihm zugeordnete Kindknoten 21 aufweist, und jeder Knoten 20, 21 mit einem Attribut versehen ist. Das Attribut repräsentiert einen bestimmten Ressourcenbedarf, beispielsweise Kosten, Stückzahlen, Zeit, Materialbedarf, etc., im Folgenden der Einfachheit halber «Kosten» genannt. In den Fig. 15aund 15bsind diese Kosten 620, 250, 300,0 und «nicht definiert», was durch <nil> bezeichnet ist. Für die Darstellung von Zusammenhängen und Propagationsregeln von diesen Kosten werden vorzugsweise die folgenden unterschiedlichen Arten von Objektbeziehungen mit dazugehörigen Berechnungsweisen verwendet: Aggregation, Vererbung und einfache Beziehung. Bei der Aggregation 22 ist die Summe der Kosten von Elternknoten 20 und Kindknoten 21 (in der Fig. 15a: 250, 300, 0, <nil>) gleich der einer dem Elternknoten 20 zugeordneten Kostensumme (620). Für Kosten des Elternobjektes alleine (70) verbleibt die Differenz zwischen dieser Kostensumme (620) und der Summe der Kosten der Kindknoten (250+300). In den Fig. 15aund 15bist dieser Zusammenhang mit dem Bezugszeichen 22 bezeichnet. Diese Berechnungsart ist beispielsweise für Kosten von Produkten, entsprechend Elternknoten 20, aus Komponenten, entsprechend Kindknoten 21, zweckmässig. Bei der Vererbung 23 erhält ein Kindknoten 21, falls seine Kosten undefiniert sind, die Kosten des Elternknotens 20 (620). Die Kostensumme (1790) ist gleich der Summe von den Kosten des Elternobjektes und den Kosten aller Kindknoten. Diese Berechnungsart ist beispielsweise für Kosten von verallgemeinerten Produkten in einem Produktekatalog, entsprechend Elternknoten 20, und spezifischen Produkten, entsprechend Kindknoten 21, zweckmässig. Bei der einfachen Beziehung 24 bleiben Kosten unverändert, undefinierte Kosten werden als null betrachtet. Die Kostensumme (1170) ist gleich der Summe von den Kosten des Elternobjektes und den Kosten aller Kindknoten.

[0175] Bei einer gegebenen Kapazität von beispielsweise 620 resultiert bei der Aggregation 22 eine Übereinstimmung mit den Kosten und bei den anderen beiden Berechnungsarten 23, 24 eine mehr oder weniger starke Unterdeckung. Fig. 15bzeigt dieselben Berechnungsmechanismen wie Fig. 15a, jedoch mit Kosten des Elternknotens 20 von 0 statt 620.

Performancebewertung

[0176] Kenngrössen von Objekten werden im Betrieb des realen Systems durch das dem System nachgeführte Modell anhand von Messgrössen ermittelt. Anforderungen an solche Kenngrössen, die beispielsweise Leistungen, Stückzahlen, Geldbeträge, Produktequalität, Maschinenauslastung etc. repräsentieren, werden in einem Strategieobjekt zusammengefasst. Dies geschieht in einer hierarchischen Form: Anforderungen an Kenngrössen werden als Ziele («Goals») bezeichnet und zusammengefasst als «Thesen» bezeichnet. Innerhalb einer These sind die Ziele prozentual gewichtet, d.h., ihre Gewichte ergeben 100%. Thesen sind gleichermassen gewichtet zu Thesen auf einer höheren Stufe zusammenfassbar. Auf einer obersten Stufe wird eine Zusammenfassung aller Thesen als Strategie bezeichnet. Die Ziele einer These sind definiert, qualifiziert, quantifiziert, stehen in einer Reihenfolge, sind priorisiert und können untereinander in Beziehung stehen. Die einzelnen Zielsetzungen oder Thesen können mit anderen vordefinierten Objekten mittels einer Interaktionsbeziehung verknüpft werden. Diese Verknüpfung kann zu einem Externen Vertreter, Prozess, Element, einem Arbeitsmittel, einer Anforderung usw. erstellt werden. Mit diesen Verknüpfungen wird beispielsweise definiert, zu wie viel Prozent ein Objekt von dieser Strategie respektive These betroffen sowie zu wie viel Prozent eine These vom Objekt abhängig ist oder abgedeckt wird. Diese Verknüpfungen sind für Abhängigkeitsanalysen verwendbar.

[0177] In einer bevorzugten Variante der Erfindung, bei welcher das Modell anhand von Messungen am realen System nachgeführt wird, wird ein Erfüllungsgrad der verschiedenen Ziele entsprechend den jeweiligen Anforderungen berechnet. Durch die Hierarchie der Thesen und anhand der Gewichtungen wird die Erfüllung der Thesen und der Strategie berechnet. Damit liegt laufend ein Wert vor, der eine Aussage über die Leistungsfähigkeit respektive den aktuellen Stand des Systems bezüglich Zielerreichung macht. Bei Bedarf kann interaktiv durch Navigation durch Thesenobjekte und ihre Abhängigkeitsbeziehungen festgestellt werden, wer oder was in welchem Mass zur Zielerreichung beiträgt.

Modellvergleich

[0178] Zum Vergleich eines Systems zu verschiedenen Zeitpunkten oder in verschiedenen Zuständen liegen mindestens zwei Modelle des Systems entsprechend den unterschiedlichen Zuständen vor, auch Betrachtungsräume genannt. Je nach Zusammenhang werden solche Zustände auch Ist-Zustand und Soll-Zustand genannt.

[0179] Beispielsweise entspricht ein Soll-Zustand einem gewünschten System oder Referenzzustand nach Einführung einer neuen Betriebssoftware, nach einer Reorganisation von Strukturen und Abläufen, oder nach Installation einer neuen Maschine. Unterschiede zwischen den Modellen liegen einerseits in der Modellstruktur, also der Struktur von Beziehungen zwischen den Objekten, und andererseits in Werten von Parametern respektive Attributen von einander zugeordneten Objekten.

[0180] Durch die durchgehende Modellierung auf Basis der Grundtypen ist ein Vergleich unterschiedlicher Modelle letztlich auf einen Vergleich einer Struktur der Grundtypen zurückführbar. Dadurch lässt sich der Vergleich effizienter implementieren als bei Verwendung mehrerer verschiedener Modellierungsparadigmen für verschiedene Modellaspekte.

[0181] Um einen Zustand in einen anderen zu überführen, ist eine Menge von Handlungen respektive Änderungen des Systems respektive des Modells, meist über einen bestimmten Zeitbereich verteilt, notwendig. Diese Menge von Handlungen wird Projektportfolio genannt und weist mehrere Untermengen, Projekt genannt, auf. Das Projektportfolio wird vorzugsweise selber als ein eigenes Modell dargestellt, in welchem die Änderungen zwischen den betrachteten zwei Modellen zur Überprüfung durch Annehmen respektive Verwerfen aufbereitet werden. Die Bestimmung der Handlungen geschieht durch Vergleich einer Objekthierarchie der im Modell instanzierten Objekte mit sogenannten Compare&Merge-Algorithmen.

[0182] Fig. 16 zeigt schematisch einen solchen Modellvergleich. Jeweils ein erster und zweiter Modellteil zur Beschreibung eines Prozessmodells 13, eines Elementmodells 14 und eines Modells einer Informations- und Funktionsebene 15 werden miteinander verglichen. Der Vergleich ergibt eine Aufstellung von Änderungen der jeweiligen Betrachtungsebenen. Die entsprechenden Handlungen sind in Projekten 18,19 im Projektportfolio 17 zusammengefasst.

[0183] Dabei wird im Detail wie folgt vorgegangen: Die Objekte bilden, unter Berücksichtigung aller Beziehungstypen, ein Netz respektive einen Graphen. Unter Berücksichtigung aller Beziehungstypen einschliesslich Aggregation, Relation, Vererbung, bilden Objekte zur Darstellung von Prozessen einen Baum. Die Wurzel des Baumes bildet ein übergeordnetes Prozessobjekt oder ein Objekt «Modell». Knoten und Blätter des Baums sind untergeordnete Prozessobjekte. Analog wird ein Baum mit Elementen und gegebenenfalls ein Baum mit Einheiten der Informations- und Funktionsebene gebildet.

[0184] Ein Vergleichsalgorithmus vergleicht einen Objektbaum eines ersten Modells («Master»-Modell) mit einem Objektbaum eines zweiten Modells («Changed»-Modell). Ein Vergleich erzeugt aus zwei Quellmodellen ein Differenzmodell, das die Vereinigungsmenge der beiden Quellmodelle, angereichert um Differenzinformationen, darstellt. Der Vergleich von M1 = {A, B} und M2 = {B, C} resultiert in M3 = {A-, B, C+}. M1 ist Master-Modell, M2 ist Changed-Modell. «A-» bedeutet «aus Master gelöscht», «C+» bedeutet «in Master» eingefügt.

[0185] Der Vergleich geschieht rekursiv: Für jeweils zwei Objekte, die einander entsprechen, das heisst in beiden Modellen existieren, wird untersucht, ob und wie weit sich ihre untergeordneten respektive Kind-Objekte entsprechen. Dafür existieren folgenden Möglichkeiten: Objekt existiert nur im Master, nicht im Changed: [o-] Objekt existiert nicht im Master, nur im Changed: [-o] Objekt existiert beiderorts, aber ist verändert: [!] Objekt ist unverändert, aber Container von Differenzen: [...], das heisst, es enthält veränderte Kind-Objekte.

[0186] Zur Bestimmung, ob zwei Objekte einander entsprechen, werden die folgenden Objekteigenschaften verwendet:

[0187] Objekte weisen in diesem Zusammenhang eine «GUID» (Globally Unique ID), die für jedes Objekt einmalig ist, einen «Identifikator», der ein Objekt aus Sicht des Benutzers identifiziert, und einen Namen, anhand dessen ein Benutzer ein Objekt erkennt. Ein Objekt kann damit unter seinem Namen erkannt werden, aber muss noch nicht beispielsweise als Prozess identifiziert worden sein.

[0188] Die GUID wird zur Identifikation von Objekten in technischen Vorgängen benutzt, z.B. beim Lesen von Files, auflösen von Links in Texten, identifizieren von Objekten über Netzwerk etc. Ein reales Objekt des Systems kann im Modell durch mehrere Objekte mit unterschiedlichen GUID repräsentiert werden. Die GUID ist für einen Normalbenutzer in der Regel nicht sichtbar.

[0189] Der Identifikator wird zur Identifizierung eines Objektes im Laufe seiner Evolution eingesetzt. Ein Objekt kann unter Beibehaltung eines stabilen Identifikators seinen Namen wechseln, an einen anderen Ort verschoben werden, andere Attribute und Assoziationen aufweisen etc. Der Identifikator fungiert also als absoluter Identifikator.

[0190] Bei nicht weiter spezifiziertem Identifikator wird der Name zur Identifikation benutzt. Der Prozess «Lagerverwaltung» ist also für den Benutzer und für den Vergleich derselbe Prozess wie ein gleichnamiger, aber mit anderer GUID.

[0191] Der Name identifiziert ein Objekt innerhalb seines Namensraumes, er fungiert, mit anderen Worten, als relativer Identifikator. Der Namensraum wird durch eine Kette der Namen der übergeordneten Objekte bestimmt, ähnlich wie in einer Ablagestruktur eines Dateiverwaltungssystems. Beispielsweise ist eine Operation «Speichern» in einer Klasse «Kunde» ein anderes Objekt als die Operation «Speichern» in einer Klasse «Auftrag». Die Namens-Kette zusammen mit dem Objektnamen ergibt einen qualifizierten Namen, z.B. «Auftrag» «Speichern».

[0192] Vorzugsweise werden zum Organisieren von Objekten auch Ordner oder «Folder» verwendet. Sie gruppieren Objekte, ergeben ebenfalls Namensräume und weisen dabei nicht zwingend eine physische Entsprechung in der realen Welt auf.

[0193] Gleichnamige Objekte in verschiedenen Namensräumen werden also grundsätzlich als andere Objekte betrachtet. Mittels eines Identifikators kann aber festgelegt werden, dass es sich um das gleiche Objekt an anderer Stelle handelt. Es ergibt sich daraus, dass das Verschieben eines Objektes in einen Folder beim Vergleich als Differenz eine Löschung an der alten Stelle und eine Einfügung an der neuen Stelle ergibt, ausser wenn das Objekt durch einen Identifikator gekennzeichnet ist.

[0194] Vor einem Vergleich können Zuordnungen zwischen Objekten der beiden Modelle auch manuell spezifiziert werden!

[0195] Zwei Objekte in zu vergleichenden Modellen entsprechen einander gemäss den folgenden, nach Priorität geordneten Regeln: Objekte sind einander manuell zugeordnet. Die manuelle Zuordnung hat Vorrang gegenüber den weiteren Zuordnungsregeln. Objekte mit gleichen Identifikatoren werden einander zugeordnet. Objekte ohne Identifikator, aber mit gleichem Namen und mit einander zugeordneten übergeordneten Objekten, werden einander zugeordnet. Objekte ohne Namen (technische Objekte) werden mit Objekten gleichen Typs und/oder gleicher Struktur und/oder korrespondierenden Werten zugeordnet. Strukturen von Objekten werden entsprechend einem gemeinsamen Muster oder Pattern einander zugeordnet.

[0196] Dadurch, dass vordefinierte Objekte verwendet werden, ist ein effizienter Vergleich und eine Zuordnung auch dann möglich, wenn Identifikatoren und/oder Namen nicht übereinstimmen. Dadurch, dass Grundtypen als Basis der Modellierung verwendet werden, lassen sich auch Modelle verschiedener Herkunft miteinander vergleichen.

[0197] In einer bevorzugten Variante der Erfindung werden nach einem Vergleich die Unterschiede zwischen den Modellen insbesondere als Unterschiede zwischen Objekten, Eigenschaften und Beziehungen klassifiziert. Nach Massgabe einer Benutzereingabe werden Änderungen klassenweise akzeptiert oder zurückgewiesen. Dies erlaubt beispielsweise, weniger gewichtige Änderungen, beispielsweise von textuellen Beschreibungsfeldern und/oder von Parameterwerten pauschal zu akzeptieren, und hingegen strukturelle Änderungen einzeln zu kontrollieren und zu akzeptieren oder abzulehnen. In einer anderen bevorzugten Variante der Erfindung werden Unterschiede gemäss den betroffenen Objekten klassifiziert, aufgelistet und bearbeitet. Entsprechende Klassen sind also beispielsweise Strategie-Differenzen, Prozess-Differenzen, Element-Differenzen. Weitere Klassifizierungsvarianten werden gemäss der Art der Differenz vorgenommen: Löschen, Einfügen, Verschieben, Textänderung, Numerische Werte, und Eigenschaften von Beziehungen, wie beispielsweise prozentuale Verteilung.

[0198] Im Folgenden sind Beispiele für Modellstrukturen («Master» und «Changed»), einer vereinigten Struktur («Merged») und einer Charakterisierung der Unterschiede («Delta») angegeben.

[0199] Vergleich anhand von Identifikatoren, also mit absolut identifizierten Objekten: <tb>Master<sep>Changed<sep>Merged<sep>Delta <tb>A[A]<sep>A[A]<sep>A[A]<sep>– <tb>--A[X1]<sep>B[B]<sep>B[B]<sep>– <tb>--B[X2]<sep>-- A[X1]<sep>--A[X1]<sep>von A nach B verschoben <tb>B[B]<sep>--B[X2]<sep>--B[X2]<sep>von A nach B verschoben

[0200] Darstellungskonventionen sind beispielhaft anhand der ersten Spalte erklärt: Das Master-Modell weist ein Objekt A mit Identifikator A und ein Objekt B mit Identifikator B auf. Das Objekt A mit Identifikator A ist einem Objekt A mit Identifikator X1 und einem Objekt B mit Identifikator X2 übergeordnet. Anhand der Identifikatoren ist feststellbar, dass A[X1] und B[X2] verschoben wurden.

[0201] Vergleich anhand von Namen, die mit Namensräumen, also relativ identifiziert sind: <tb>Master<sep>Changed<sep>Merged<sep>Delta <tb>A[A]<sep>A[A]<sep>A[A]<sep>– <tb>--A[A::A]<sep>B[B]<sep>--A[A::A]<sep>existiert nur in Master <tb>--B[A::B]<sep>--A[B::A]<sep>--B[A::B]<sep>existiert nur in Master <tb>B[B]<sep>--B[B::B]<sep>B[B]<sep>– <tb><sep><sep>--A[B::A]<sep>existiert nur in Changed <tb><sep><sep>--B[B::B]<sep>existiert nur in Changed

[0202] In einer bevorzugten Variante der Erfindung werden aus den ermittelten Änderungen Änderungshandlungen ermittelt, die das System gemäss dem ersten Modell in das System gemäss dem zweiten Modell überführen. Information über Zeitbedarf und Kosten werden beispielsweise aufgrund von Erfahrungswerten für Einzelaktivitäten ermittelt. Erfahrungswerte werden beispielsweise gemäss der bekannten «Function Point»-Methodologie gebildet und nachgeführt.

[0203] Beispielsweise erlaubt die Anwendung des Vergleichsverfahrens, einen Umbau einer Fabrikationsanlage auf ein anderes Produkt oder eine Umorganisation betrieblicher Abläufe zu untersuchen und insbesondere zu planen. Bevorzugt wird auch eine automatisierte Umkonfiguration durchgeführt. Beispielsweise werden ein Ist-Zustand und ein Soll-Zustand einer Druckmaschinenstrasse, entsprechend unterschiedlichen Druckereierzeugnissen, modelliert. Aus dem Modellvergleich werden die Änderungshandlungen ermittelt und werden Druck-, Falz-, Schneidemaschinen etc. entsprechend umkonfiguriert. Vorzugsweise werden auch Kosten respektive ein Aufwand für eine Umkonfiguration berechnet. Bei mehreren erforderlichen Umkonfigurationen wird eine Sequenz von Umkonfigurationen derart bestimmt, dass der Gesamtaufwand minimal ist. Analog kann beispielsweise auch eine software- und/oder hardwaremässige Umkonfiguration von Computersystemen und -netzwerken geplant und zumindest teilweise automatisch durchgeführt werden.

Prozesssteuerung

[0204] Zur Systemüberwachung und -steuerung werden an definierten Stellen im System die bereits erwähnten Sensoren zur Datenerfassung installiert. Diese Informationssammler funktionieren in der Regel automatisch, können aber auch auf manuellen Benutzereingaben basieren. Ermittelte Messwerte der Sensoren werden im Modell nach Massgabe der im Modell definierten Verarbeitung verrechnet und mit anderen Daten kombiniert. Mit derart neu berechneten Werten wird der Prozess gesteuert. Falls bestimmte Werte vorgegebene Grenzwerte überschreiten, werden Notifikationen oder Alarmierungen ausgelöst. Beispielsweise wird dazu eine SMS, ein Dokumentenversand via E-Mail, ein Transfer von Informationen auf ein Mobilgerät oder eine Sprachnachricht via Telefon übermittelt.

[0205] Mit der Erfindung wird eine pragmatische, aber trotzdem komplette Basis zur Modellierung, Steuerung und Überwachung von komplexen technischen und organisatorischen Systemen und Abläufen geschaffen. Sie erlaubt: Modelle immer konsistent, transparent und stufengerecht für verschiedene Zielpubliken bereit zu haben, insbesondere um einen automatisierten oder manuellen Entscheidungsprozess maximal zu unterstützen. Jederzeit Aussagen zu Qualität, Risiken, Kosten, Nutzen, Machbarkeit etc. zu erhalten. Notwendige Analysen maximal zu unterstützen und Veränderungen immer aktuell steuern zu können.

Claims

1. Verfahren zum Vergleich von computerbasierten und datenverarbeitenden Modellen eines komplexen Systems mit Hilfe einer digitalen Datenverarbeitungseinheit, wobei – ein erstes aus einer dem System zugehörenden Realität abgebildetes (entsprechendes) Modell als Ausgangsbasis (IST-Wert) und – ein zweites, die Realität zum ersten Modell zu veränderndes Modell (SOLL-Wert) vorliegt, wobei die Modelle jeweils ein Systemverhalten mittels vordefinierter realer Objekte modellieren, welche Aktivitäten und Einheiten innerhalb des Systems repräsentieren, und wobei ein Objekt ein in der digitalen Datenverarbeitungseinheit verarbeitetes und gespeichertes Software-Objekt ist, und das Verfahren die folgenden Schritte aufweist: – Vergleich der beiden Modelle und Bestimmung von jeweils einander zugeordneten vordefinierten Objekten des ersten und des zweiten Modells, – Bestimmung von Unterschieden in Attributen von einander zugeordneten vordefinierten Objekten, und – Ausgabe der bestimmten Zuordnungen und Unterschiede als Veränderungsgrössen an der dem ersten Modell zugrundeliegenden Realität, und Veränderung derselben.

2. Verfahren nach Anspruch 1, wobei das erste Modell einen ersten Zustand des Systems repräsentiert und das zweite Modell einen zweiten Zustand des Systems repräsentiert, und wobei aus den zwischen den beiden Modellen bestimmten Zuordnungen und Unterschieden in einem weiteren Schritt Änderungshandlungen bestimmt werden, die das System vom ersten Zustand in den zweiten Zustand überführen, und wobei die Änderungshandlungen durch Steuermittel zur Steuerung von Änderungen des Systems verwendet werden, wobei das System eine technische Einrichtung oder ein Produktionsprozess ist.

3. Verfahren gemäss Anspruch 1, wobei beim Vergleich des ersten und zweiten Modells die vordefinierten Objekte der Modelle bei Übereinstimmung von mindestens einem von – einem absoluten Identifikator der Objekte, – einem die Objekte unter Bezeichnung jeweils übergeordneter Objekte bezeichnenden definierenden qualifizierten Namen, und – einer Typenbezeichnung der vordefinierten Objekte einander zugeordnet werden.

4. Verfahren gemäss Anspruch 3, wobei eine Übereinstimmung eines Identifikators Vorrang vor einer Übereinstimmung von Namen hat.

5. Verfahren gemäss Anspruch 3 oder 4, wobei eine manuelle Zuordnung Vorrang vor der Übereinstimmung von Identifikatoren oder von Namen hat.

6. Verfahren gemäss einem der vorangehenden Ansprüche, wobei das erste und zweite Modell jeweils – mindestens eine erste und eine zweite Modellierungsebene aufweisen, auf welchen das System jeweils mit unterschiedlichen Abstraktionsgraden durch Definition von Objekten und von Verknüpfungen zwischen den Objekten repräsentiert wird, – und Zuordnungen respektive Beziehungen zwischen Objekten der ersten und der zweiten Modellierungsebene aufweisen.

7. Verfahren gemäss Anspruch 6, wobei die Verknüpfungen einen Austausch oder eine Übergabe von Arbeitsmitteln repräsentieren, wobei ein Arbeitsmittel eine physische Einheit oder eine Informationseinheit repräsentiert.

8. Verfahren gemäss einem der Ansprüche 6 bis 7, wobei die Zuordnungen zwischen den Objekten der ersten und der zweiten Modellierungsebene eine anteilsmässige Unterstützung der Objekte der ersten durch die Objekte der zweiten Modellierungsebene repräsentieren.

9. Verfahren gemäss einem der Ansprüche 6 bis 8, wobei mindestens einige Objekte auf der ersten Modellierungsebene Prozesse repräsentieren, wobei ein Prozess eine Gesamtheit von Aufgaben und Abläufen einer Organisations- oder Produktionseinheit ist, und wobei mindestens einige Objekte auf der zweiten Modellierungsebene Elemente repräsentieren, wobei ein Element eine reale physische oder logische Einheit ist, und wobei die Unterstützung eines Prozesses durch ein Element ausdrückt, dass der Prozess das Element benötigt, um funktionieren zu können.

10. Verfahren gemäss einem der Ansprüche 6 bis 8, wobei mindestens einige Objekte auf der ersten Modellierungsebene Elemente repräsentieren, wobei ein Element eine reale physische Einheit repräsentiert, und wobei mindestens einige Objekte auf der zweiten Modellierungsebene Informations- und Funktionseinheiten repräsentieren, wobei die Informations- und Funktionseinheiten Daten, Programme oder Regeln sind, und wobei die Unterstützung eines Elements durch eine Informations- und Funktionseinheit ausdrückt, dass das Element die Informations- und Funktionseinheit benötigt, um funktionieren zu können.

11. Verfahren gemäss einem der Ansprüche 1 bis 10, wobei mindestens zwei Modelle desselben Systems existieren, ein erstes Modell das System in einem ersten Zustand und ein zweites Modell das System in einem zweiten Zustand repräsentiert, und eine automatische Analyse zur Bestimmung von Handlungen zur Überführung des Systems vom ersten in den zweiten Zustand durchgeführt wird.

12. Verfahren gemäss einem der vorangehenden Ansprüche, wobei die Modellierung auf einer untersten Beschreibungsebene einen begrenzten Satz von Grundtypen zur Repräsentation der Einheiten und zur Beschreibung ihres Zusammenwirkens verwendet, wobei jeder Grundtyp Daten verarbeitet, welche Daten Werte von Eigenschaften der genannten Einheiten repräsentieren, und wobei dieser Satz von Grundtypen aufweist – einen Grundtyp «Weiterleiten» («Straight»), welcher eine Weiterleitung von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten durchleitet und einen Eingang sowie einen Ausgang aufweist, – einen Grundtyp «Verschmelzen» («Merge»), welcher ein Kombinieren von Einheiten repräsentiert, Daten zur Charakterisierung dieser Einheiten miteinander verknüpft und zwei Eingänge sowie einen Ausgang aufweist, – einen Grundtyp «Aufteilen» («Split»), welcher eine Auftrennung von Einheiten repräsentiert, Daten zur Charakterisierung von Einheiten, die aus einer Auftrennung hervorgehen, aus Daten einer aufzutrennenden Einheit ermittelt, und einen Eingang sowie zwei Ausgänge aufweist, wobei jeweils Eingänge zur Übernahme und Ausgänge zur Übergabe von Daten in den respektive aus dem jeweiligen Grundtyp dienen, und wobei computerbasierte datenverarbeitende Modelle des Systems gebildet werden durch Bildung einer Menge von Grundtypen und durch Verknüpfen von Ein- und Ausgängen dieser Grundtypen.

13. Verfahren gemäss einem der vorangehenden Ansprüche, wobei das erste Modell das System in einem ersten Zeitpunkt oder einem Ist-Zustand repräsentiert und das zweite Modell das System in einem zweiten Zeitpunkt oder einem Soll-Zustand repräsentiert.

14. Datenträger, enthaltend ein Computerprogramm zur Modellierung eines Systems, wobei das Computerprogramm auf einer digitalen Datenverarbeitungseinheit ladbar und ausführbar ist, und bei der Ausführung das Verfahren nach einem der Ansprüche 1 bis 13 ausführt.