-
Die Erfindung betrifft ein Verfahren sowie ein zugehöriges Computerprogramm(-produkt) und eine Vorrichtung zum Bereitstellen einer Menge von Modultypen, wobei mindestens ein Modultyp aus der Menge zur Gestaltung einer oder mehrerer technischen Anlagen genutzt wird.
-
Außerdem betrifft die Erfindung ein Computerprogramm bzw. ein Computerprogrammprodukt und ein computerlesbares Medium.
-
Die Erfindung liegt auf dem Gebiet der Anlagentechnik, z.B. in Planung von Zugmaschinen bzw. Zugfahrzeuge z.B. für Lastzüge bzw. Sattelzüge oder Güterbahnzüge. Es sind jedoch auch andere Anwendungen bzw. Anlagentypen wie z.B. Photovoltaik-, Betriebseinrichtungen für Flugzeuge und Fahrzeuge und Chipsatzplanungen möglich. So sind beispielsweise bei einer Zugmaschine- bzw. -fahrzeugs z.B. die Teile Tank, Kühler, Radaufhängung, Radachsen etc. in Teilgebiete des Zugfahrzeugs, die jeweils z.B. in drei Teilgebiete durch zwei Hauptträger entlang der Unterseite des Zugfahrzeugs horizontal begrenzt und z.B. vertikal in Teilgebiete innerhalb der Fahrzeugkabine und außerhalb der Fahrzeugkabine ggf. um den Sattelaufleger herum aufgeteilt sind, platziert werden sollen.
-
Auf Kunden zugeschnittene Anlagenplanungen sind eine große Herausforderung. (Groß-)Anlagenplanung bzw. -gestaltung erfordern viele komplexe Entscheidungsprozesse, die ineinander greifen müssen, um sich ein Gesamtbild über die zu planende Anlage machen zu können. So eine Anlagenplanung wird in der Regel Software-Tool-unterstützt durchgeführt. Jedoch werden mit den Software-Tools in der Regel nur Teilaspekte einer Anlage betrachtet. Ein Gesamtbild fehlt häufig, da die Schnittstellen zwischen den Software-Tools(-Werkzeugen) oft nicht einheitlich definiert sind und jedes Werkzeug eine eigene beschreibende Darstellung von Anlagenkomponenten aufweist.
-
Es sind bereits (Software-)Module zur projektübergreifenden Wiederverwendung in Gestaltungs- bzw. Planungsvorhaben, auch Engineering-Projekten genannt, möglich.
-
Ein Modul im folgenden Kontext ist eine funktionale Einheit einer Software, wobei Mischformen des Moduls vorstellbar sind, in denen Software-, Firmware- und Hardwareanteile die Funktionalität eines Moduls ausmachen.
-
Aus Wikipedia entnommen werden folgende Definitionen verwendet:
Inhalt eines Moduls ist häufig eine wiederkehrende Berechnung oder Bearbeitung von Daten, die mehrfach durchgeführt werden soll.
-
Ein solches Modul dient meist zur Funktionsstrukturierung. Es kann sowohl zur Wiederverwendung über unterschiedliche Projekte hinweg oder aber auch zur einmaligen Verwendung innerhalb eines Projektes geschaffen werden. Ein Modul zur Wiederverwendung entspricht dabei z.B. einer Klasse in der objektorientierten Software-Entwicklung.
-
Eine Klassifizierung ist im Allgemeinen eine Einschränkung/Vereinfachung der realen Welt in einem ganz speziellen Kontext. Während beispielsweise eine Klasse „Auto“ im Kontext eines Autobauers möglicherweise Attribute wie Räder und Farbe und Hubraum des Motors sowie die Fahrzeug-Bauteile besitzen wird, hat eine Klasse „Auto“ im Kontext eines Händlers Attribute wie Produktnummer, Preis, Kraftstoffverbrauch und Hubraum des Motors sowie Erstzulassungsdatum. Im Kontext einer Zulassungsstelle wird es Attribute wie Kennzeichen, zulässiges Maximalgewicht, Hubraum des Motors und den Halter geben.
-
Klassen sind sozusagen Vorlagen, aus deren konkreten Ausprägungen Objekte, auch Instanzen genannt, zur Laufzeit erzeugt werden.
-
Im Kontext der Anlagenplanung entsprechen im Folgenden die Modultypen den oben genannten Klassen, während ein Modul zur Laufzeit einer Modulinstanz entspricht
-
Diese Modultypen werden z.B. entweder durch den Engineering-Software-Lieferanten, durch Organisationen, die Modulbibliotheken pflegen, oder in der Engineering-Organisation bereitgestellt. Diesen Modultypen ist gemeinsam, dass sie einmalig entworfen und anschließend im Falle notwendiger Anpassungen manuell geändert werden – z.B. durch die Organisation, die ursprünglich den Modultyp entworfen hat, einen Modultyp-Bibliotheksverantwortlichen oder ggf. auch durch die Nutzer der Modultypen selbst. Dies erfordert tiefgehendes Wissen über die Modultypen und die Konsequenzen von vorgenommenen Änderungen sowie den erneuten Test der geänderten Modultypen, die Aktualisierung in der Bibliothek etc.
-
Zum Teil können Änderungen bereits während der Modultypentwicklung vorausgesehen werden und bereits entsprechende Anpassungsmöglichkeiten vorgesehen werden, so dass Modultypen durch den Nutzer konfiguriert und nicht mehr in ihren internen Strukturen geändert werden. Konkrete Ausprägungen eines Modultyps bilden sich aus den vom Nutzer eingestellten bzw. voreingestellten Konfigurationen bzw. Anwendungsdaten. Einstellungen vom Nutzer bewirken eine Anpassung des Modultyps für ein bestimmtes Vorhaben. Konfigurationen betreffen neben Anwendungsdaten auch die Methoden, für die die Parameter festgelegt werden können bzw. für die festgelegt wird, ob eine Methode in dem Kontext anwendbar ist oder nicht. Anwendungsdaten umfassen in der Regel die Werte für die Attribute bzw. für die Parameter. So legt beispielsweise ein Nutzer im Kontext des oben genannten Autobauers den Hubraum des Motors mit den Wert „1,2 Liter“ fest, das eine konkrete Ausprägung des Modultyps „Auto“ darstellt. Computertechnisch gesehen wird damit während der Laufzeit eine Instanz des Modultyps erzeugt.
-
Jedoch setzt solch eine manuelle Anpassung mit dem entsprechenden Aufwand durch den Nutzer oder durch einen Administrator explizites Wissen über die Anpassungsmöglichkeiten der Modultypen und über die Konsequenzen dieser Anpassungen voraus. Da der Modultyp in seinen internen Strukturen und Funktionen (Methoden) selbst jedoch nicht geändert werden muss, entfällt hierbei ein erneuter Test des Moduls. Auch das benötigte Wissen beschränkt sich bereits auf die bereitgestellte Schnittstelle zur Konfiguration. Jedoch können diese Schnittstellen sehr umfangreich sein und sind häufig schwer zu überblicken. Z.B. können einzelne Module (in diesem Falle Funktionsbausteintypen) in der Automatisierungssoftware deutlich über Hundert parametrierbare Eingänge besitzen.
-
Es ist Aufgabe der Erfindung, die eingangs erwähnten Probleme bei der Nutzung von Modultypen bzw. deren Ausprägungen bei der Gestaltung einer technischen Anlage zu überwinden.
-
Diese Aufgabe wird durch die unabhängigen Ansprüche gelöst. Vorteilhafte Weiterbildungen sind Gegenstand der abhängigen Ansprüche.
-
Die Erfindung beansprucht ein System zum Bereitstellen einer Menge von Modultypen zur Verwendung in wenigstens einem Vorhaben zur Gestaltung einer oder mehrerer technischer Anlagen, aufweisend:
- a) eine Aufnahmeeinheit zur Aufnahme von Anwendungsdaten, wobei diese Anwendungsdaten Ausprägungen der in einem Vorhaben verwendeten Modultypen umfassen,
- b) Analyseeinheit zur Analyse der Anwendungsdaten und zum Bestimmen von Anpassungen in den Ausprägungen der verwendeten Modultypen anhand der Analyse,
wobei die Analyseeinheit Konfigurationsdaten (K) hinsichtlich der bestimmten Anpassungen in den Ausprägungen der Modultypen, die in wenigstens denselben oder in wenigstens einem anderen Vorhaben verwendet werden sollen, bereitstellt.
-
Die bereitgestellten Konfigurationsdaten können in einer zentralen Datenbasis, insbesondere in einer Modultyp-Bibliothek hinterlegt werden/sein.
-
Das System kann in ein Engineering-System, mit dem das/die Vorhaben zur Anlagengestaltung durchgeführt werden, oder in die Datenbasis integriert sein. Das System kann auch separat zum Engineering-System angeordnet sein. Dann fließen die bereitgestellten Konfigurationsdaten in die Datenbasis und/oder in die Anwendung der entsprechenden Modultypen ein.
-
Die Erfindung bewirkt eine intelligente Anpassungsmöglichkeit der Modultypen an deren tatsächliche Verwendung bzw. Anwendung, die sich jeweils in einer anwendungsbezogenen Ausprägung des Modultyps wiederspiegelt. Die Bereitstellung der Modultypen in einer Datenbasis, vorzugsweise einer Modultyp-Bibliothek bzw. die Bereitstellung von unterschiedlichen Anwendungsdaten und/oder Konfigurationen bzw. Einstellungen für einen Modultyp in der Modultyp-Bibliothek ermöglichen deren Wiederverwendung im denselben Vorhaben bzw. Projekt mit einer anderen Nutzergruppe und/oder in einem anderen Vorhaben bzw. Projekt mit derselben und/oder einer anderen Nutzergruppe.
-
Eine Weiterbildung der Erfindung sieht vor, dass die Konfigurationsdaten in Cluster unterteilt werden können, wobei ein Cluster eine Nutzergruppe mit nutzerspezifischen Ausprägungen der Modultypen repräsentiert.
-
Eine Weiterbildung der Erfindung sieht vor, dass die Cluster in einen ersten Untercluster mit für eine Mehrzahl an Nutzergruppen spezifischen Ausprägungen und in gegebenenfalls mehrere weitere Untercluster unterteilbar sind, wobei die weiteren Untercluster jeweils die für eine Nutzergruppe spezifischen Ausprägungen umfassen.
-
Eine Ausprägung eines Modultyps zur Verwendung in einem oder mehreren Vorhaben kann wie folgt beschrieben werden:
- – eindeutig identifizierende Bezeichnung des Modultyps und/oder
- – Versionsnummer des Modultyps und/oder
- – Art der Anpassung und/oder
- – Status oder Wert vor der Anpassung und/oder
- – Status oder Wert durch die Anpassung und/oder
- – durch die Anpassung betroffene Modultypelemente und/oder
- – Zeitpunkt der Anpassung und/oder
- – Nutzeridentifikation des Modultyps und/oder
- – Bezeichnung des Vorhabens zur Gestaltung einer Anlage.
-
Diese Beschreibung liegt eher auf der Metaebene. Ein Modultyp soll auch eine Funktion implementieren.
-
Mit dieser Beschreibung können die Änderungen in den Instanzen des Modultyps beschrieben und für die Anpassung des Modultyps verwendet werden.
-
Dieses System kann als Software-Agent ausgestaltet sein, das in die Datenbasis integriert oder integrierbar ist. Der Software-Agent kann hierbei selbstlernend ausgebildet sein. Die Analyseeinheit kann dazu ausgelegt sein, folgende Schritte auszuführen:
- a) Prüfen, ob eine Ausprägung eines Modultyps geändert worden ist,
- b) Prüfen, ob die Ausprägung das erste Mal verwendet worden ist,
- c) Wenn die Prüfung a) und b) positiv ausfällt, dann Hinterlegen der Ausprägung in der Datenbasis
- d) Wenn die Prüfung b) negativ ausfällt, dann analysieren, ob diese Änderung in der gleichen Art wie bei einer vorgebbaren Anzahl von früheren Verwendungen im selben oder in einem anderen Vorhaben durchgeführt worden ist,
- e) Wenn die Analyse die gleiche Art der Änderung ergibt, dann Übernahme der Änderung der in der Datenbasis hinterlegten Ausprägung,
- f) ansonsten Abbruch der Durchführung der Schritte.
-
Die oben genannte Anzahl von früheren Verwendungen kann vom Nutzer vorgegeben werden. Mit anderen Worten ausgedrückt: Es wird geprüft, ob diese Ausprägung des Modultyps in der gleichen Art bereits bei der letzten Verwendung oder den letzten x Verwendungen oder häufig im Vergleich zu anderen Verwendungen oder auch in anderen Projekten etc. angepasst wurde.
-
Es kann somit analysiert werden, ob andere Änderungen häufiger durchgeführt wurden und zu welchem Zeitpunkt dies geschehen ist. D.h. die Durchführung der Änderungen wird dann entsprechend ihres Zeitpunktes bewertet (je länger eine Änderung her ist, desto weniger Gewicht hat sie, die aktuelleren Änderungen sind höher zu gewichten).
-
Die genannten Schritte a) bis f) können iterativ wiederholt werden, bis eine Abbruchbedingung, z.B. eine Ergebnisgüte und/oder zeitliche Begrenzung und/oder Anzahl an Iterationen erfüllt ist.
-
Ein weiterer Aspekt der Erfindung ist ein Verfahren zum Bereitstellen einer Menge von Modultypen zur Verwendung in wenigstens einem Vorhaben zur Gestaltung einer oder mehrerer technischen Anlagen, aufweisend folgende Schritte:
- a) Aufnahme von Anwendungsdaten, wobei diese Anwendungsdaten Ausprägungen der in einem Vorhaben verwendeten Modultypen umfassen,
- b) Analyse der Anwendungsdaten und Bestimmen von Anpassungen in den Ausprägungen der verwendeten Modultypen anhand der Analyse,
wobei Konfigurationsdaten hinsichtlich der bestimmten Anpassungen in den Ausprägungen der Modultypen, die in wenigstens denselben oder in wenigstens einem anderen Vorhaben verwendet werden sollen, bereitgestellt werden.
-
Das Verfahren kann wie das oben beschriebene System, das als Vorrichtung ausgestaltet sein kann, entsprechend weitergebildet werden und weist dieselben Vorteile auf.
-
Ein weiterer Aspekt der Erfindung ist eine technische Anlage, die statisch ausgebildet sein und mindestens eine der folgenden Komponenten umfassen kann:
- – eine Automatisierungsanlage,
- – eine Produktionsanlage,
- – eine Energieanlage,
- – eine Photovoltaikanlage
- – eine Maschine.
-
Die Anlage kann auch beweglich ausgebildet sein und mindestens eine der folgenden Komponenten umfassen:
- – ein Fahrzeug,
- – eine fahrbare Maschine,
- – ein Flugzeug.
-
Diese genannten Komponenten können somit den Anlagentyp spezifizieren. Das oben beschriebene System bzw. Verfahren ist zur Gestaltung bzw. Planung einer technischen Anlage der vorstehend genannten Art vorgesehen.
-
Das System/die Vorrichtung sieht Mittel bzw. Einheiten zur Durchführung des oben genannten Verfahrens vor, die jeweils hardwaremäßig und/oder firmwaremäßig und/oder softwaremäßig bzw. als Computerprogramm bzw. Computerprogrammprodukt ausgeprägt sein können.
-
Ein weiterer Aspekt der Erfindung ist ein Computerprogrammprodukt bzw. ein Computerprogramm mit Mitteln zur Durchführung des oben genannten Verfahrens, wenn das Computerprogramm(produkt) in einem oben genannten System oder in Mitteln des Systems zur Ausführung gebracht wird. Das Computerprogramm bzw. -produkt kann auf einem computerlesbaren Medium gespeichert sein. Das Computerprogramm bzw. -produkt kann in einer üblichen Programmiersprache (z.B. C++, Java) erstellt sein. Die Verarbeitungseinrichtung kann einen marktüblichen Computer oder Server mit entsprechenden Eingabe-, Ausgabe- und Speichermitteln umfassen. Diese Verarbeitungseinrichtung kann in dem System oder in deren Mitteln integriert sein.
-
Die Erfindung weist weiterhin folgende Vorteile auf:
-
Eine Nutzergruppe bzw. ein Nutzer findet für ihre/seine Anwendung bereits sinnvoll vorkonfigurierte Modultypen vor. Daraus ergeben sich die folgenden Konsequenzen:
- – geringer Aufwand für die Anpassung der Ausprägungen der Modultypen im Projekt und damit kürzere Projektlaufzeiten und geringere Kosten im Engineering,
- – Fehlerreduktion, wenn die Konfigurationen nicht manuell immer wieder wiederholt werden müssen,
- – Wiederverwendbarkeit von vorhandenem Wissen über die Konfiguration der Ausprägungen der verwendeten Modultypen und Wiederverwendung auch durch andere / neue Nutzer und damit Vermeidung von Doppelarbeit.
-
Weitere Vorteile, Einzelheiten und Weiterbildungen der Erfindung ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen in Verbindung mit den Zeichnungen.
-
Es zeigen:
-
1 schematisch ein Modul-Konfigurationssystem zur Anpassung der Module und
-
2 schematisch einen selbstlernenden Modultyp.
-
Es sollen Schnittmengen der verschiedenen Ausprägungen der Modultypen allen Nutzergruppen möglichst automatisch zur Verfügung gestellt werden, ohne dass diese manuell ihre Konfigurationen anpassen müssen. Spezielle auf die Nutzergruppe zugeschnittene Ausprägungen sollen ebenfalls möglichst einheitlich und/oder zentral bereitgestellt werden.
-
Ein Modul kann auch in sehr ähnlichen Kontexten eingesetzt werden. Die Instanz kann trotzdem unterschiedlich angepasst werden. Dies kann beispielsweise daran liegen, dass der Nutzer in einem Projekt andere Anforderungen als ein anderer Nutzer in einem ähnlichen Projekt hat. Beispielsweise kann einfach die Farbgebung eines Bedienelementes im Operator View anders sei. Auch kann der Nutzer der Instanz eigene Vorstellungen haben (z.B. Vorbelegung von Standardwerten, Anzeige bestimmter Werte im Testmodus, etc.). Es können auch immer dieselben Attribute parametriert werden, die aber zunächst standardmäßig ausgeblendet sind und dazu erst eingeblendet werden müssen. Z.B. bei Automatisierungsbausteinen wird dies umgesetzt, da deren Eingänge sehr umfangreich sein können), d.h. es sind bisher sozusagen die „falschen“ Attribute ausgeblendet worden. Dies soll nun so geändert werden, dass diese eingeblendet bleiben.
-
Es wird ein System bereitgestellt, das die Informationen aus der Verwendung der Engineering-Modultypen erhält und diese Informationen zur Anpassung von Ausprägungen bzw. Instanzen der Modultypen in einer Modultyp-Bibliothek eines Engineering-Systems nutzt. Wie eingangs bereits erwähnt sind die Anpassungen bzw. Änderungen in der Regel umfangreicher, da Anlagenprojekte bzw. -vorhaben sehr komplex sind. In 1 ist ein solches System als Modul-Konfigurationssystem KS zur Anpassung der Modultypen gezeigt. Die Modultypen werden entsprechend ihrer Verwendung angepasst und stehen für die nächste Verwendung optimiert in der Modultyp-Bibliothek B zur Verfügung. Das Modul-Konfigurationssystem KS kann entweder direkt in das Engineering-System E integriert sein oder als separates System mit dem Engineering-System E verbunden sein. In beiden Fällen wird das Modul-Konfigurationssystem mit Anwendungsdaten A über die Anwendung der Modultypen in Projekten P versorgt. Diese Anwendungsdaten werden in einer Datenbasis MA des Systems KS gespeichert und mit Hilfe einer Verarbeitungseinheit D analysiert. Daraus wird eine oder mehrere Modultypanpassungen bestimmt, wobei das System KS Modultyp-Konfigurationsdaten K entsprechend der bestimmten Modultypanpassungen an das Engineering-System E übergibt, um daraus die Modultypen in Ihrer Ausprägung anzupassen und die angepassten Modultypausprägungen in einer Modultyp-Bibliothek B in Form einer Datenbasis zu hinterlegen.
-
Eine weitere Möglichkeit ist die Realisierung von intelligenten Modultypen, die selbstlernend sich selbst optimieren und dafür auf Anwendungen ihrer Ausprägungen in Projekten P zurückgreifen. In 2 ist ein solcher selbstlernender Modultyp M schematisch angedeutet. D.h. in diesem Fall ist das Modul-Konfigurationssystem KS bzw. das Wissen über die Konfiguration des Moduls ein integraler Teil des Moduls und auch die Instanzen bzw. Ausprägungen des Modultyps in Projekten können selbständige Objekte sein, die Anwendungsdaten an die Modultyp-Bibliothek B weitergeben können. Das Modul-Konfigurationssystem kann somit als Software-Agent agieren. Laut Wikipedia ist ein Software-Agent ein Computerprogramm, das zu gewissem eigenständigem und eigendynamischem (autonomem) Verhalten fähig ist. Das bedeutet, dass abhängig von verschiedenen Zuständen (Status) ein bestimmter Verarbeitungsvorgang abläuft, ohne dass von außen ein weiteres Startsignal gegeben wird oder während des Vorgangs ein äußerer Steuerungseingriff erfolgt.
-
Anwendungsdaten eines Moduls umfassen beispielsweise die Werte für die Parameter, auch die Parametrierung genannt, der Module. Das Hinzufügen weiterer Informationen zu dem Modul (z.B. auch durch bereits vorgedachte Ergänzungsmöglichkeiten), die Vorauswahl bzw. Vorgabe von Varianten eines Moduls („Standardvariante“) und/oder die Verwendung des Moduls in unterschiedlichen Engineering-Ergebnissen, die beispielsweise in Mensch-Maschine-Schnittstellen-Bildern, Funktionsplänen, Hardwarekonfiguration darstellbar sind. Diese Informationen können entweder direkt über die Aktionen des Nutzers und des Engineering-Systems im Engineering-System E gesammelt und direkt oder zeitverzögert und ggf. konsolidiert weitergegeben werden (z.B. unter Berücksichtigung von Korrekturen, die durch den Nutzer vorgenommen wurden). Es können bereits vorliegende und ggf. abgeschlossene Engineering-Projekte durch das Modul-Konfigurationssystem analysiert werden oder diese Informationen bereits aufbereitet an das Engineering-System übergeben werden.
-
Das Engineering-System E nutzt diese Informationen, um die Modultypen in der Modultyp-Bibliothek B für ihre nächste Verwendung in einem Projekt möglichst optimal vorzubereiten bzw. bei der Verwendung des Modultyps diese Instanz beispielsweise gleich in die erforderliche Umgebung zu integrieren (z.B. Darstellung zur weiteren Bearbeitung oder Ausblenden des Moduls im Mensch-Maschine-Schnittstellen-Bild, im Funktionsplan etc. – je nach vorheriger Nutzung). Dazu ist ggf. auch eine Historie unterschiedlicher Anwendungen des Modultyps in Projekten sinnvoll. Durch die Analyse der vergangenen Verwendungen kann beispielsweise eine vom Standard abweichende, einmalige „Sonderanwendung“ erkannt werden und eine Anpassung des Moduls erst dann erfolgen, wenn regelmäßige gleichartige Anpassungen durch den Nutzer durchgeführt werden bzw. es können die Anpassungen im Modultyp durchgeführt werden, die tatsächlich am häufigsten vom Nutzer ausgeführt wurden.
-
Folgender Algorithmus wird ausgeführt, der systemspezifisch oder kontextspezifisch angepasst werden kann:
- 1. Eintrag der Anpassung des Moduls in die Historie (ggf. in die Historie des Modultyps),
- 2. Analyse der Anpassung des Modultyps: Prüfen, ob eine Ausprägung des Modultyps verändert wurde.
- 3. Prüfen, ob die Ausprägung das erste Mal verwendet und gleichzeitig geändert worden ist,
- 4. Wenn Ja, dann Übernahme der Anpassung in die Modultyp-Bibliothek (falls möglich)
- 5. Wenn Nein: Wurde dieser Modultyp in der gleichen Art bereits bei der letzten Verwendung oder den früheren x Verwendungen oder häufig im Vergleich zu anderen Verwendungen auch in anderen Projekten angepasst?
- 6. Wenn ja, dann Übernahme der Anpassung in die Modultyp-Bibliothek (falls möglich),
- 7. Wenn nein, dann keine Anpassung.
-
Zur Analyse der Anpassung des Modultyps ist eine Beschreibungssprache sinnvoll, die einerseits die Anpassungen bzw. Änderungen bzw. Veränderung im Modultyp dokumentiert und andererseits durch die Systeme E und KS interpretiert werden kann. Die Beschreibungssprache soll u.a. die folgenden Attribute für eine Änderung umfassen:
- – Eindeutige Modultypbezeichnung
- – Version des Modultyps
- – Art der Änderung
- – Geändertes Modultypelement (Eigenschaft oder Parameter für Methode)
- – Vorhergehender Wert
- – neuer Wert nach der Änderung
- – Zeitpunkt der Änderung
- – Nutzeridentifikation
- – Eindeutige Projektbezeichnung bzw. eindeutige Bezeichnung des Vorhabens
-
Sinnvoll ist eine Historie pro Modultyp (ggf. direkt im Modul geführt) oder eine Historie, die nach Modultyp geordnet werden kann. Falls die Modultypen in einer zentralen Modultyp-Bibliothek verwaltet werden, die von mehreren Nutzern genutzt wird, so sind folgende Szenarien möglich:
- 1. Es gibt einen Modultyp in einer zentral bereitgestellten Modultyp-Bibliothek, der entsprechend der Anpassungen aller Nutzer bzw. Nutzergruppen optimiert wird. Dies erfordert eine Erkennung von einmaligen Sonderanwendungen, wenn z.B. ein Nutzer das Modul grundsätzlich anders nutzt als alle anderen, dann sollte dieser Nutzer die Konfiguration des Modultyps nicht beeinflussen können, da ansonsten der Anpassungsaufwand insgesamt steigt. Konfigurationsdaten für solche nutzerspezifischen Sonderanwendungen können jeweils in ein weiteres Cluster einsortiert werden.
- 2. Die Konfiguration des Modultyps wird für jeden Nutzer getrennt ermittelt und das in der zentralen Bibliothek enthaltene Modul wird bei der Verwendung durch einen Nutzer gemäß seiner spezifischen Konfiguration angepasst. D.h. das Modul-Konfigurationssystem verwaltet sogenannte Cluster von Konfigurationsdaten pro Nutzer bzw. Nutzergruppe für jeden Modultyp. Dieses Szenario ist vor allem dann sinnvoll, wenn die Verwendung der Modultypen sich von Nutzer zu Nutzer stark unterscheidet.
-
Ein weiteres Szenario ist möglich, wenn ein Modultyp immer wieder in bestimmten, unterschiedlichen Ausprägungen eingesetzt wird: In diesem Fall können mehrere Konfigurationen für einen Modultyp verwaltet werden.
-
Je weitreichender die Konfigurationsmöglichkeiten der Modultypen sind, desto stärker kann die Anpassung der Modultypen an den Kontext und/oder an die Nutzergruppe und/oder den Nutzer erfolgen.
-
Obwohl die Erfindung im Detail durch das bevorzugte Ausführungsbeispiel näher illustriert und beschrieben wurde, so ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt und andere Variationen können vom Fachmann hieraus abgeleitet werden, ohne den Schutzumfang der Erfindung zu verlassen.
