-
Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Gestaltung einer technischen Anlage.
-
Die Erfindung liegt insbesondere auf dem Gebiet des Engineering industrieller Anlagen. Eine Domäne umfasst hierbei die von einer Engineeringabteilung oder –Firma bearbeiteten Anlagentypen ähnlichen Charakters und Basistechnologie. Beispiele für Domänen mit unterschiedlichen aber ähnlichen Anlagentypen sind Produktionsanlagen, energieerzeugende Anlagen, Walzwerke, Papierfabriken, Abfüllanlagen, Wasseraufbereitungsanlagen. Es ist jedoch auch die Gestaltung bzw. das Engineering von Systemen, wie Zügen oder Autos, denkbar.
-
Das Engineering bzw. die Gestaltung einer industriellen Anlage erfolgt in der Regel auf Basis geeigneter Werkzeuge und Methoden. Diese DV-technisch unterstützenden Werkzeuge bzw. Methoden beziehen sich in der Regel auf Beschreibungen und Daten zur Erstellung oder Modernisierung industrieller Anlagen, wobei die Gestaltung, Planung und Erstellung einer solchen Anlage jeweils zu einem Projekt zusammengefasst wird.
-
Sogenannte Engineering-Daten zur Gestaltung der industriellen Anlagen können beispielsweise jeweils Anforderungen (Requirements) z.B. hinsichtlich Emission und einzuhaltende Standards sowie Daten zu den Projektverantwortlichen umfassen. Ein solches Projekt kann desweiteren beispielsweise Module bzw. Anlagenkomponenten umfassen, die wieder in Submodule hierarchisch geordnet sein können. Die Engineering-Daten dienen beispielsweise der Spezifikation von Modulen und können auf Basis der Begriffe einer Taxonomie oder Ontologie adressiert werden. Unter Ontologie wird häufig eine (formal) geordnete Darstellung einer Menge von Begriffen und deren zwischen ihnen stehenden Beziehungen in einem bestimmten Gegenstandsbereich verstanden (eine Taxonomie kann als Spezialfall einer Ontologie angesehen werden). Der Gegenstandsbereich kann hierbei ein Projekt bzw. eine spezifische industrielle Anlage sein.
-
Anlagenobjekte sind hierbei programm- bzw. software- und/oder firmware- und/oder hardwaretechnisch Implementierungsbausteine, die beispielsweise einen Materialfluss oder auch Vorgänge beim Öffnen und Schließen einer Auto- bzw. Zugtüre steuern können. Ein Anlagenobjekt weist in der Regel viele Eigenschaften und/oder Funktionen verfahrenstechnischer Art auf, die projektspezifische bzw. anlagenspezifische Ausprägungen annehmen. Beispiele sind der Signalfluss (z.B. Stromlaufplan), der Materialfluss (z.B. der Rohrleitungsplanung), die zeitliche Reihenfolge, etc.
-
Eine der größten Herausforderungen im Engineering bzw. der Planung solcher Anlagen ist, die oben genannten Anlagenobjekte projektübergreifend zu definieren und so zu gestalten, dass sie in möglichst vielen unterschiedlichen Projekten ohne manuelle Anpassungen wiederverwendet werden können. Beispielsweise kann ein sogenanntes RFID-Modul so als ein wiederverwendbares Anlagenobjekte definiert sein, dass es durch Konfiguration beispielsweise in Autos, LKW oder auch Zügen eingesetzt werden kann. Das Einlesen/Ausgeben von Daten und auch deren Verarbeitung kann anhand von standardisierten Schnittstellen erfolgen und so das RFID-Modul wiederverwendbar machen.
-
Allerdings sind in der Zwischenzeit weitestgehend die Grenzen erreicht, mittels dieser Art von Wiederverwendung weitere nennenswerte Rationalisierungs- und Optimierungseffekte zu erzielen. Auch ist diese Vorgehensweise nicht in jedem Fall zielführend, da einerseits der technologische Fortschritt ständig neue, noch bessere technische Lösungen hervorbringt und andererseits häufig Rücksicht auf die bereits installierte technischen Gegebenheiten genommen werden muss, oder spezifische Randbedingungen beim Auftraggeber der Verwendung der vordefinierten Anlagenobjekte entgegensprechen.
-
Das Engineering solcher Anlagen entspricht derzeit der Abarbeitung sehr arbeitsaufwändiger, ggf. manueller Arbeitsabläufe. Daher zielt ein weiterer Ansatz darauf ab, diese Arbeitsabläufe (Workflows) besser zu organisieren und zu unterstützen.
-
Derzeitig mögliche Systemlandschaften, die diesen Ansatz unterstützen, definieren, kreieren und verwalten das Ausführen von Arbeitsabläufen, in dem Softwarebausteine eingesetzt werden. Die Softwarebausteine laufen auf Workflow-Maschinen ab, die die Prozessdefinition interpretieren, mit Workflowteilnehmern interagieren und, wenn erforderlich, das eine oder andere DV-Werkzeug bzw. entsprechende Anwendungen aufrufen.
-
Diese Workflow-Systeme basieren auf vormodellierten Arbeitsabläufen sind aufwändig zu etablieren und zu warten, da sie an die jeweiligen Projekte ständig angepasst werden müssen.
-
Ein weiterer Ansatz wäre der Aufbau und die Nutzung einer gemeinsamen Wissensdatenbank bzw. eines Repository zu den Eigenschaften eingesetzter Anlagenkomponenten der Anlagentypen einer Domäne. Doch liegen zwischen den Anlagenbauern uneinheitliche Prozesse, Systemlandschaften und Strategien vor. Auch möchte kein Anlagenbauer sein Wissen ohne weiteres preisgeben.
-
Aufgrund der zentralen Bedeutung der jeweils verwendeten Systemlandschaft und der Größe der damit umgesetzten Anlagenengineeringprojekte, stellt jede Umstellung der Systemlandschaft ein großes, schwer kalkulierbares Risiko dar. Da aus diesem Grund die Bereitschaft zu fundamentalen Änderungen i.d.R. nicht gegeben ist, müssen Umstellungen und Verbesserungen darauf abzielen, die möglichst nahtlose Migration vom Status Quo hin zu einem künftigen Projektabwicklungs-System zu unterstützen. Die neuen Systemanteile sollten idealerweise die bestehende Systemlandschaft zunächst lediglich unterstützen und ergänzen, nicht ersetzen.
-
Aufgrund dieser Probleme konzentriert sich Standardisierung derzeit noch immer auf die oben erwähnten (technologischen) Anlagenobjekte. Diese unterliegen jedoch permanenter Innovation und werden auch durch Kundenanforderungen beeinflusst. Wünschenswert wäre hingegen, die Standardisierung, Ablage und Wiederverwendung von Wissen, das sich auf technologische Zusammenhänge, Entscheidungswege und abwicklungsspezifische Abläufe bezieht und Engineeringaufgaben automatisiert.
-
Jede der bislang bekannten Vorgehensweisen/Methoden stellt keine Lösung der aktuell anstehenden, oben beschriebenen Problematik dar.
-
Es ist Aufgabe der Erfindung, diese Probleme 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 Verfahren zur Gestaltung einer aus Anlagenkomponenten bestehenden, technischen Anlage für eine Domäne,
wobei ein oder mehrere Teile der zur Gestaltung erforderlichen Engineering-Aufgaben durch sogenannte Engineering-Automatisierungs-Objekte (EAOx) ausgeführt werden, aufweisend folgende Schritte:
- – Erzeugen eines projektunabhängigen, domänenspezifischen virtuellen Adressierungsschemas zur Adressierung von für die Gestaltung erforderlichen Projektdaten,
- – Erzeugen mindestens eines Engineering-Automatisierungsobjekts (EAOx) – im Folgenden auch als Automatisierungs-Objekt bezeichnet –, welches Eigenschaften, Regeln und Algorithmen zur Abarbeitung von Engineering-Aufgaben umfasst,
- – Auflisten der von dem mindestens einen Automatisierungsobjekts verwendeten Adressen des virtuellen Adressierungsschemas,
- – Automatisiertes Ausführen von Engineering-Aufgaben mittels Aufruf einer oder mehrerer Engineering-Automatisierungsobjekte, sobald mindestens eine Ausführungsvoraussetzung in Form einer Regel erfüllt ist,
- – Zuweisen der aufgelisteten, verwendeten Adressen zu projektspezifischen Absolutadressen mit dem Zweck auf die an den Absolutadressen hinterlegten, erforderlichen Projektdaten zur Laufzeit der Automatisierungsobjekte zugreifen zu können.
-
Sowohl die modulübergreifenden Engineeringdaten als auch die zu den Modulen gehörenden Daten können mittels eines hierarchischen Adressierungsschemas adressiert werden.
-
Das projektunabhängige Adressierungsschema kann Platzhalter für ein oder mehrere Absolutadressen umfassen.
-
Die von einem oder mehreren Automatisierungs-Objekten zur Adressierung verwendeten Platzhalter können zur Laufzeit interpretiert werden und damit die zugehörigen Absolutadressen angesprochen werden können.
-
Das Zuweisen der aufgelisteten, verwendeten Adressen zu projektspezifischen Absolutadressen kann dadurch erfolgen, dass unter Verwendung einer Zugriffseinheit der Zugriff auf die Projektdaten zugelassen wird. Zu einzelnen Adressen können zugehörige Absolutadressinformationen hinterlegt werden und daraus die Absolutadressen abgeleitet werden. Aufgrund von Vererbungs- und Typinformationen können die Absolutadressen abgeleitet werden.
-
Das Adressierungsschema ist aktualisierbar und/oder erweiterbar.
-
Die Automatisierungs-Objekte können zur Laufzeit projektspezifische Erweiterungen des verwendeten Adressierungsschemas vornehmen.
-
Das Adressierungsschema kann in Form einer Taxonomie oder Ontologie bereitgestellt werden.
-
Der aufgespannte Adressbereich, auf dem sich die von der Erfindung automatisierten Aufgaben befinden können, ist individuell durch Implementierung entsprechender, domänenspezifischer Taxonomien bzw. Ontologien erweiterbar.
-
Beim Ausführen der Engineering-Automatisierungsobjekten kann neben der automatisierten Abarbeitung von Engineering-Aufgaben auch der Status überprüft werden, aktuelle Problemstellen erkannt und kenntlich gemacht werden, eine Leistungsverrechnung erfolgen und/oder eine Historie-Logdatei angelegt werden.
-
Die Ausführung des einen oder der mehreren Automatisierungs-Objekten kann abhängig von vorgebbaren Rollen und Zugriffsrechten sein.
-
Die Erfindung bringt den Vorteil mit sich, dass für deren Nutzung keine explizite Modellierung der Zusammenhänge zwischen den einzelnen Engineeringaufgaben, den einzelnen Analgenkomponenten oder den der Erfindung zugrunde liegenden Engineering-Automatisierungsobjekten notwendig ist.
-
Die eingesetzten Engineering-Automatisierungsobjekte (EAOs) können wiederverwendbar, autark und projektübergreifend einsetzbar ausgebildet sein.
-
Damit resultieren aus dem Einsatz wiederverwendbarer Engineering-Automatisierungsobjekte identische Regeln bei der Erzeugung von Engineeringdaten. Auf diese Weise wird ein standardisiertes Gestalten von Anlagen sichergestellt, das sukzessive verbessert werden kann.
-
Die von den Engineering-Automatisierungsobjekten (EAOs) verwendeten oder erzeugten Engineeringdaten können verteilt in bereits ohnehin existierenden Datenbeständen und konventionellen Engineeringwerkzeugen vorliegen.
-
Je nachdem auf welche Weise die Ausführungsvoraussetzungen definiert wurden, wird auch die vorläufige Abarbeitung von Arbeitsschritten auf Basis unvollständiger Daten ermöglicht.
-
Eine Domäne beschreibt einen bestimmten Typ einer industriellen Anlage wie z.B. eine Produktionsanlage, generelle Automatisierungsanlage oder Energieerzeugungsanlage.
-
Ein weiterer Aspekt der Erfindung ist eine Vorrichtung zur Gestaltung einer aus Anlagenkomponenten bestehenden, technischen Anlage für eine Domäne, wobei ein oder mehrere Teile der zur Gestaltung erforderlichen Engineering-Aufgaben durch sogenannte Engineering-Automatisierungs-Objekte ausführbar sind, aufweisend:
- – Mittel zum Erzeugen eines projektunabhängigen, domänenspezifischen virtuellen Adressierungsschemas zur Adressierung von für die Gestaltung erforderlichen Projektdaten,
- – Mittel zum Erzeugen mindestens eines Engineering-Automatisierungsobjekts (EAOx), welches Eigenschaften, Regeln und Algorithmen zur Abarbeitung von Engineering-Aufgaben umfasst,
- – Mittel zum Auflisten der von dem mindestens einen Automatisierungsobjekts verwendeten Adressen des virtuellen Adressierungsschemas,
- – Mittel zum automatisierten Ausführen von Engineering-Aufgaben mittels Aufruf einer oder mehrerer Engineering-Automatisierungsobjekte, sobald mindestens eine Ausführungsvoraussetzung in Form einer Regel erfüllt ist,
- – Mittel zum Zuweisen der aufgelisteten, verwendeten Adressen zu projektspezifischen Absolutadressen mit dem Zweck auf die an den Absolutadressen hinterlegten, erforderlichen Projektdaten zur Laufzeit der Automatisierungsobjekte zugreifen zu können.
-
Die Vorrichtung kann wie das oben beschriebene Verfahren entsprechend weitergebildet werden.
-
Ein weiterer Aspekt der Erfindung sieht ein Computerprogrammprodukt mit Mitteln zur Durchführung des Verfahrens, wenn das Computerprogrammprodukt auf der genannten Vorrichtung zur Ausführung gebracht wird.
-
Die Vorrichtung sieht Mittel/Einheiten bzw. Module 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.
-
Weitere Vorteile, Einzelheiten und Weiterbildungen der Erfindung ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen in Verbindung mit den Zeichnungen.
-
Es zeigen:
-
die 1 schematisch eine Umgebung, in der die erfindungsgemäße Vorrichtung bzw. das erfindungsgemäße Verfahren eingesetzt werden können,
-
die 2 einen Taxonomiebaum zu einem Engineeringprojekt z.B. „Autobau“, und
-
die 3 einen möglichen Statusbericht zu den Engineering Automatisierungsobjekten.
-
Das in der 1 links dargestellte konventionelles Engineering kann manuell über eine Benutzerschnittstelle z.B. einem Eingabegerät bzw. über einen Dialog 12 durch eine Person erfolgen. Die erforderlichen Engineeringdaten werden durch diese Person, einen Anlagen-Experten beispielsweise mit Hilfe von Softwarewerkzeugen 1 erzeugt. Die bisherigen Rationalisierungs- und Standardisierungsbemühungen führten an vielen Stellen zu Bibliotheken 2 mit vorab standardisiert beschriebenen und auswählbaren Komponenten, die im Engineering der Anlage verbaut werden können. Dabei kann es sich entweder um ggf. käufliche Einzelkomponenten oder um zusammengesetzte und vorkonfigurierte Komponentenansammlungen handeln, die als Ganzes auswählbar und integrierbar sind und eine bestimmte, immer wieder benötigte Funktion bei der Erstellung einer Anlage des jeweiligen Typs implementieren. Idealerweise verwenden diese Softwarewerkzeuge ein gemeinsames Repository 3 in Form einer Datenbank oder eines gemeinsamen Ablageformates, über das die erzeugten Engineeringdaten abgelegt werden. Oft werden die Daten lediglich isoliert in applikationsspezifischen Formaten z.B. in eigenen Datenbanken oder Dateien abgespeichert. Generell wäre es sinnvoll, dass alle erforderlichen projektspezifischen Daten (beispielsweise die Daten der Ausschreibung, der Angebotserstellung, der Anforderungs-, System- und Teilsystemarchitekturspezifikationen, des Engineerings, des Tests und der Abnahme) in einem gemeinsamen, standardisierten Format abgelegt werden. Dieses Format hätte den Vorteil, dass es damit den eingesetzten Werkzeugen möglich wäre, auf eine einheitliche, standardisierte Weise auf die Daten zuzugreifen und damit die Bedeutung aller Einzeldaten zu lesen und deren Bedeutung zu verstehen. Demgegenüber funktioniert das erfindungsgemäße AddOn zu den bereits eingesetzten Werkzeugen auch bei verteilt vorliegenden Daten, indem es Schnittstellen besitzt, um auf diese Datenbestände zugreifen zu können. Ein AddOn ist typischerweise eine Erweiterung bzw. Zusatzprogramm bzw. eine Zusatzkomponente zu einem Basisprogramm bzw. einer Basishardware. Das in der 1 rechts dargestellte AddOn verwendet standardisierte, sich über Ontologien selbst beschreibende Begriffe 4. In 4 wird eine Taxonomie verwendet.
-
Um die im konventionellen Engineering vorliegenden, nicht einheitlich standardisiert abgelegten Daten auf die Daten des AddOns abbilden zu können, ist erfindungsgemäß eine Zugriffseinheit – im Beispiel eine Zugriffsbibliothek 5 – vorgesehen, die Funktionalitäten bereitstellt. Diese Funktionalitäten ermöglichen den lesenden und schreibenden Zugriff auf die vielfältigen, verteilt vorliegenden Daten unterschiedlichsten Formats. Diese Zugriffseinheit bzw. -bibliothek ist in der Lage, aus einzelnen Adressen zugehörige Absolutadressen abzuleiten und die in den EAOs verwendeten Zugriffsbefehle in individuelle Befehle zum Zugriff auf die heterogenen Bestände der Projektdaten abzubilden und diese auszuführen.
-
Über einen geeigneten Benutzerdialog, der in der 1 mit 12 gekennzeichnet ist und dessen Interaktion mit anderen Einheiten bzw. Komponenten des AddOns bzw. des konventionellen Anlagenengineeringssystem mit gestrichelten Linien angedeutet ist, kann das erfinderische System bzw. Vorrichtung Einstellungen 6 auf die spezifischen Einsatz- bzw. Verwendungsbedingungen vornehmen. Hierbei werden beispielhaft Benutzer und deren Zugangsrechte eingerichtet, generelle Aufgaben des AddOns festgelegt, aber auch die benötigten Adressen und Abbildungsvorschriften bzw. Algorithmen für den Zugriff auf die erforderlichen Daten des konventionellen Engineerings definiert.
-
Aus Sicherheitsgründen, kann die erfinderische Systemerweiterung mit einem Login 7 versehen werden, sodass lediglich berechtigte Personen oder Personengruppen das AddOn nutzen können.
-
Das erfindungsgemäße AddOn umfasst Engineering-Automatisierungsobjekten (abgekürzt mit EAOs), gekennzeichnet mit Bezugszeichen EAOx (x = unbestimmte Anzahl), die in einer Bibliothek 8 verwaltet werden. Die Engineering-Automatisierungsobjekte EAOx dieser Bibliothek können mit standardisierten Entwicklungswerkzeugen (wie beispielsweise dem Visual Studio von Microsoft) erzeugt bzw. aktualisiert bzw. erweitert werden. Je Domäne in der die vorliegende Erfindung zum Einsatz kommt, ist eine individuelle EAO-Bibliothek zu implementieren.
-
Auch wenn die EAOs der Automatisierung von Arbeitsabläufen dient, benötigen sie keine vorgefertigte Ablaufdefinitionen oder Prozesse. Dies wird dadurch erreicht, indem die verfügbaren EAOs einmalig oder immer wieder zyklisch bzw. in regelmäßigen Abständen mittels eines Schedulers 9 aufgerufen werden. Damit werden die von den EAOs ausgeführten Engineeringaufgaben je nach Einsatzfall einmalig oder zyklisch wiederkehrend automatisiert bearbeitet und so die davon betroffenen Engineeringdaten erzeugt, bzw. aktuell gehalten. Alle EAOs besitzen einen einheitlichen Aufbau, der in der 1 mit 10 gekennzeichnet, veranschaulicht wird. Dabei enthält jedes EAOs zunächst einen Satz an individuellen "Voraussetzungen", die erfüllt sein müssen, damit die Ausführung des Automatisierungsobjektes erfolgen kann und damit Engineeringdaten erzeugt oder aktualisiert werden können. Diese individuellen Voraussetzungen sind wahlweise in Form von Regeln beschreibbar (Einsatz von Regelbeschreibungssprachen wie Drools) und/oder aber auch mittels konventioneller Programmierung (etablierte Programmiersprachen wie C++, JAVA oder auch Visual Basic) in Form entsprechender Algorithmen implementierbar. Im Beispiel findet das standardisierte Vokabular (also die domänenspezifische Ontologie siehe 4) Anwendung. Drools steht in diesem Zusammenhang als Platzhalter für ein Business-Regelmanagementsystem (BRMS) mit einer vorwärts und rückwärts verketteten Schlussfolgerung-basierten Regelmaschine (Inferenzengine). Darüber hinaus besitzt jedes EAO einen Satz an Adressen, welche die vom jeweiligen EAO verwendeten Ein- und Ausgangsdaten beschreibt. Um eine redundante Datenablage zu vermeiden, werden die dabei adressierten Daten in der Regel nicht durch das AddOn selbst persistiert. Vielmehr sind diese Daten unverändert Teil der Datenbestände des konventionellen Engineerings. Um die EAOs wiederverwendbar einsetzen zu können, basiert die Definition dieser Adressen auf die vorab jeweils definierte, domänenspezifische Ontologie bzw. Taxonomie. Die Abbildung dieser Adressen auf die zugehörigen Daten der projektspezifischen Datenbestände erfolgt in mehreren Stufen. Zunächst erfolgt vor Abarbeitung der EAOs die projektspezifische Zuweisung absoluter Adressinformationen. Auf Basis von Vererbungsinformationen der eingesetzten Taxonomie bzw. Ontologie werden daraus weitere Informationen zu den jeweiligen Absolutadressen erzeugt und daraus schließlich zur Laufzeit des jeweiligen EAOs (unter Verwendung evtl. Wildcards) die benötigten Absolutadressen generiert. Auf Basis dieser Absolutadressen und unter Verwendung der passenden Zugriffs-Bibliothek 5 erfolgt schließlich der Zugriff auf die eigentlichen projektspezifischen Daten. So können die Eingangsgrößen des Engineeringsobjekts eingelesen, mit eventuell doch im EAO persistierten Daten verglichen, und die, der jeweiligen Engineeringaufgabe entsprechenden, Ergebnisdaten auf die Datenbestände des konventionellen Engineerings zurückgeschrieben werden. Zu diesem Zweck werden unter Beachtung der im jeweiligen Objekt enthaltenen Regeln und unter Abarbeitung der enthaltenen Abbildungsalgorithmen Werte für die Ausgangsgrößen erzeugt. Da die bei der Implementierung des jeweiligen EAO verwendeten Variablen und Konstanten auf Basis standardisierter, domänenspezifischer Vokabeln bzw. Schlüsselwörter definiert werden und auch projektübergreifende, domänenspezifische Adressen zum Einsatz kommen, sind EAO vollständig entkoppelt vom jeweiligen Einsatzfall und daher flexibel einsetzbar und wiederverwendbar.
-
Die durch ein EAO erzeugten Ausgangsgrößen können völlig unterschiedlicher Natur sein. Einerseits sind dies Engineeringdaten, die gegebenenfalls konvertiert und dann mittels Zugriffsbibliothek auf die Daten des konventionellen Engineerings zurückgeschrieben werden, anderseits gibt es auch die Möglichkeit, Daten zu generieren, die direkt weiterverwendet werden können (z.B. Versenden von Emails), ohne dass eine Ablage in den Datenbeständen des konventionellen Engineerings notwendig wäre.
-
Ein weiteres Beispiel hierfür ist die Leistungsverrechnung 11a der Bausteinnutzung, im Falle, dass das erfindungsgemäße AddOn als Dienst – sogenannte Software-As-A-Service – zum Einsatz kommt. Weitere Beispiele sind eine Liste an Vorschlägen 11b, welche Engineeringdaten idealerweise als nächstes durch die Experten erarbeitet werden sollten, um den Projektfortschritt zu beschleunigen. Hinweise auf aktuelle Problemstellen 11c und ggf. Inkonsistenzen, der Projektstatus 11d oder eine Historie-Logdatei 11e können aus der Historie der automatisiert abgearbeiteten Aufgaben aber auch aus weiteren Informationen hervorgehen.
-
Durch Auswertung solcher Informationen, können Rückschlüsse gezogen werden, ob noch Unzulänglichkeiten oder Fehler in den existierenden EAOs bestehen, sowie ob neue Automatisierungs-Objekte benötigt werden.
-
In einem weiteren Schritt wäre es sogar denkbar, dass ein Implementierungsbaustein-Generierungssystem automatisch aus diesen Informationen neue EAO-Bausteine erstellt.
-
2 zeigt als einen möglichen Dialog 12 einen Editor E. Beispielhaft wird ein Taxonomiebaum T zu einer Engineeringdomäne D z.B. „Autobau“ angezeigt. Auf sie setzen die Arbeiten zur Gestaltung eines neuen Autos (Projekt P) auf.
-
Eine Taxonomie ist ein Klassifikationsschema, welches ein einheitliches Verfahren oder Modell darstellt, mit dem Engineeringdaten und Einzelkomponenten nach bestimmten Kriterien klassifiziert, das heißt in Kategorien oder Klassen (auch Taxa genannt) eingeordnet werden.
-
Folgendes sehr vereinfacht dargestelltes Beispiel ist im Zusammenhang mit einem Anlagentyp „Autobau bzw. -konstruktion“ vorstellbar, ohne die Erfindung darauf zu beschränken:
Anlagenkomponenten eines Autobau-Projekts können sein:
- – Bordelektronik
– Bedienelemente
– Regeln
– Steuern
– [Gerät]
– Temperatur
• Minimal (Wert)
• Maximal (Wert)
– Durchfluss
– Getriebe
– Antrieb
- – Architektur
-
Alle Projektdaten, also sowohl Engineeringdaten als auch die zu den physikalischen Komponenten (Modulen) gehörenden Daten, können mittels eines hierarchischen Adressierungsschema adressiert werden.
-
Der in der 2 in [] bezeichnete Platzhalter G, auch als Wildcard bezeichnet, repräsentiert alle, seiner Position innerhalb der Taxonomie entsprechenden, zur Laufzeit interpretierbaren oder auffindbaren Absolut-Adressen zum Zugriff auf die zur Anlagengestaltung erforderlichen Projektdaten.
-
Der hier beispielhaft verwendete Platzhalter könnte dann unter anderem für ein „Gebläse“ stehen. Die oben dargestellten Eigenschaften z.B. Temperatur, Regeln und Algorithmen können unter Verwendung der Begriffe der bereitgestellten, domänenspezifischen Taxonomie oder Ontologie adressiert werden. Zu diesem Zweck kann durch Aneinanderreihung aller Begriffe des Pfades von der Wurzel bis hin zu dem Blatt mit der gerade betrachteten Eigenschaft eine Adresse gebildet werden. Der in der 2 dargestellte Taxonomiebaum wird hierbei als eine Art virtueller Adressraum verwendet, aus dem über diese Pfade wiederverwendbare Adressen A hervorgehen, denen jeweils Absolutadressen zugeordnet werden können, hinter denen wiederum die eigentlichen Modul- und Engineeringdaten abgelegt sind. So kann beispielsweise eine Datei bzw. ein Feld in einer Datei adressiert sein.
-
Im Beispiel könnte der Taxonomieebene „Bordelektronik“ die Absolutadresse eines Laufwerkspfades zugewiesen worden sein. Darauf aufsetzend könnte dann die unterlagerte Ebene „Steuern“ einer Datei in diesem Laufwerkspfad entsprechen. In dieser Datei könnte je vorhandenem Gerät (entspricht Wildcard „[Gerät]“) eine Rubrik (Tabellenblatt oder Kapitel) existieren, die den Namen des Gerätes trägt. In jeder Rubrik dieser Datei wären schließlich Angaben zur minimalen und maximalen Betriebstemperatur des zugehörigen Gerätes zu finden.
-
Im vorliegenden Beispiel zum Editor E wurde „der absolute Adresstyp“ (in Englisch: Absolute Address Type) ausgewählt. Dies führt dazu, dass in der Taxonomie (links) alle Blätter beispielsweise farblich markiert werden, die entsprechend ihrer Typ-Definition die Zuordnung einer Absolutadresse erwarten. Zu den unter diesen Umständen nicht eingefärbten unterlagerten Blättern der Taxonomie wird die jeweilige Gesamtabsolutadresse aus den Absolutadressen der übergeordneten markierten Blätter und den individuellen Angaben zum jeweiligen Adressoffest abgeleitet.
-
Wie oben bereits ausgeführt, besitzen alle EAOs eine individuelle Beschreibung aus der hervorgeht, mittels welcher Rollen sie verwendbar sind und auf welchen Adressen, gebildet aus dem Adressraum der Taxonomie, sie lesend oder schreibend zugreifen. So sind beispielsweise folgende Zugriffsbefehle möglich:
Lese("Project.Engineering.Anforderungen.Emmissionen.Abgase. Titel");
Kopiere("Project.Templates.Modules.Steuern.[Gerät]", "Project.Modules.Bordelektronik.Steuern.[Gerät]");
Schreibe("Project.Modules.Bordelektronik.Steuern.Klimagerät. Temperatur.Minimal.Value", -20).
-
Aus diesen Informationen, kann ein Editor E ableiten, welche EAOs für die aktuell eingeloggte Rolle von Bedeutung sind. Diese aktuell relevanten EAOs kann der Editor weiterhin auswerten und analysieren, ob die von diesen EAOs verwendeten Adressen in der Taxonomie existieren und ob zu entsprechenden virtuellen Adressen auch wirklich bereits aller erforderlichen Angaben zur Ermittlung der zugehörigen individuellen Absolutadressen vorliegen.
-
Unter „Current Exceptions (relevant for EAOs)“ wird aufgelistet, welche Adressen diesbezüglich Mängel aufweisen. Demnach kann an der mit X gekennzeichneten Stelle im Editor E entnommen werden, dass in einem relevanten EAO die virtuelle Adresse „Project.Engineering.Architektur“ zum Einsatz kommt, die sich aus den Begriffen des betroffenen Pfades „Project“, „Engineering“ und „Archtektur“ zusammensetzt, diese virtuelle Adresse befindet sich jedoch nicht in der Taxonomie. Hier befindet sich lediglich die ähnliche Adresse „Project.Engineering.Architectures“. Solche Problemstellen, die in 1 mit 11c gekennzeichnet sind, können beispielsweise im Editor der 2 unter X aufgelistet und ggf. in der Taxonomie T farblich markiert sein.
-
Die aufgelisteten EAOs können mittels geeigneter Regeln und Algorithmen in der Lage sein, zu erkennen, ob die Voraussetzungen zu Abarbeitung einer Engineeringaufgabe erfüllt sind. Zu diesem Zweck wird bei Bedarf auf die entsprechenden Engineeringdaten der ohnehin vorhandenen, konventionellen Datenbestände zugegegriffen. Sind diese Voraussetzungen erfüllt, können die EAOs die von ihnen adressierte Engineeringaufgabe selbständig abarbeiten und so die Engineeringdaten modifizieren.
-
Im aufgeführten Beispiel könnte dies beispielsweise darauf hinauslaufen, dass ein EAO zyklisch (bei jedem Aufruf) überwacht, ob im Laufwerkspfad zur Taxonomieebene „Bordelektronik“ eine Datei existiert, die der unterlagerten Ebene „Steuern“ entspricht. Sobald eine solche Datei gefunden wird, könnte das EAO analysieren, welche Rubriken innerhalb der Datei vorliegen und ob die einzelnen Rubriken (z.B. Tabellenblätter oder Kapitel) jeweils einem „Gerät“ entsprechen. Nun werden die bereits vorliegenden Daten der jeweiligen Rubrik und damit der zugehörigen Geräte analysiert. Wenn dabei beispielsweise ein Gerätetyp „manuelle Klimaanlage“ gefunden wird, so kann das EAO die Werte für minimale und maximale Temperatur selbständig beschreiben und das Beschreiben dieser Daten in einer entsprechenden Log-Datei (siehe 11e in 1) vermerken. Sobald das EAO bei einem späteren Aufruf relevante Änderungen in den Eingangsdaten erkennt (z.B. der hier beispielhaft angesprochene Gerätetyp wurde von anderer Stelle auf „geregelte Klimaanlage“ geändert, kann das EAO die zugehörigen Temperaturen anpassen und erneut einen entsprechenden Log-Eintrag vornehmen.
-
Die 3 stellt einen beispielhaften Editor dar, der auflistet, welche EAOs für die aktuell eingewählte Rolle zulässig sind. Aus dieser Liste kann der Benutzer auswählen, welche EAOs aktuell aktiviert sein sollen und ob die aktiven EAOs gerade ausgeführt werden sollen oder nicht. Dabei kann initiiert werden, dass EAOs wahlweise einmalig oder zyklisch wiederkehrend ausgeführt werden.
-
Zu diesem Zweck sind im unteren Bereich dieses Editors zwei Auswahlknöpfe B1 und B2 sichtbar. Bei Drücken von B1 wird ein einzelnes ausgewähltes EAO einmalig gestartet. Beim Drücken von B2 werden alle für die aktuelle Rolle relevanten und aktivierten EAOs zyklisch immer wieder gestartet. Dies kontrolliert bei Bedarf ein Scheduler 9.
-
Darüber hinaus können hier Statusinformationen ausgegeben und in einem entsprechenden Statusbericht (siehe 11d in 1) zusammengefasst werden. Beispiele für solche Informationen ist die Anzahl der Aufrufe jedes einzelnen EAOs im aktuellen Projekt, aufgetretene Fehler oder der aktuelle Status jedes einzelnen EAOs.
-
Da die bei der Implementierung des jeweiligen EAO verwendeten Variablen und Konstanten auf Basis standardisierter, domänenspezifischer Adressen definiert werden und eine standardisierte Beschreibungssprache (z.B. Drools oder Visual Basic) zum Einsatz kommt, sind EAOx vollständig entkoppelt vom jeweiligen Einsatzfall und daher flexibel einsetzbar und wiederverwendbar. Die Instanziierung erfolgt lediglich aufgrund der Anbindung der Projektdaten an die vordefinierten Variablen des jeweiligen EAO z.B. mithilfe der absoluten Adresse A an die oben genannten virtuelle Adresse VT. Jedes EAO enthält zunächst einen Satz an individuellen "Voraussetzungen", die erfüllt sein müssen, damit die Abarbeitung erfolgen kann.
-
Die Algorithmen/Regeln der EAOs werden unter Zuhilfenahme weniger, einfacher Zugriffsbefehlen (s.o.) aufgebaut, die maschinenlesbar sind und die lediglich Adressen (s.o.) der Taxonomie verwenden. Dies gewährleistet die leichte Wartbarkeit und Wiederverwendbarkeit.
-
Die eigentliche Komplexität des Zugriffes auf die Projektdaten wird über die Zugriffseinheit implementiert und bleibt dem Erzeuger eines EAOs verborgen. Somit können auch computerprogrammtechnisch weniger versierte Anlagenexperten EAOs entwerfen und erzeugen.
-
Das AddOn zum konventionellen Engineering ist einfach und ohne maßgebliche Änderungen des Bestehendem integrierbar, flexibel einsetzbar und nicht auf bestimmte Anwendungsbereiche, Toollandschaften oder dem Anlagenengineering beschränkt. Das AddOn kommt ohne Prozess- oder Workflowbeschreibung aus, obwohl es der (Teil-)Automatisierung von Engineeringworkflows dient. Auch die Möglichkeit, die Automatisierungsobjekte bei Bedarf um Benutzerdialoge zu ergänzen, erweitert ihre Einsetzbarkeit. Um die manuelle Abarbeitung von Engineeringaufgaben zu beschleunigen und zu verringern, verrichtet das AddOn auf Basis der EAOs eine sukzessiv erweiterbare Menge an Arbeitsschritten selbstständig und automatisch.
-
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.
-
Die Implementierung der vorstehend beschriebenen Prozesse oder Verfahrensabläufe kann anhand von Instruktionen erfolgen, die auf computerlesbaren Speichermedien oder in flüchtigen Computerspeichern (im Folgenden zusammenfassend als computerlesbare Speicher bezeichnet) vorliegen. Computerlesbare Speicher sind beispielsweise flüchtige Speicher wie Caches, Puffer oder RAM sowie nichtflüchtige Speicher wie Wechseldatenträger, Festplatten, usw.
-
Die vorstehend beschriebenen Funktionen oder Schritte können dabei in Form zumindest eines Instruktionssatzes in/auf einem computerlesbaren Speicher vorliegen. Die Funktionen oder Schritte sind dabei nicht an einen bestimmten Instruktionssatz oder an eine bestimmte Form von Instruktionssätzen oder an ein bestimmtes Speichermedium oder an einen bestimmten Prozessor oder an bestimmte Ausführungsschemata gebunden und können durch Software, Firmware, Microcode, Hardware, Prozessoren, integrierte Schaltungen usw. im Alleinbetrieb oder in beliebiger Kombination ausgeführt werden. Dabei können verschiedenste Verarbeitungsstrategien zum Einsatz kommen, beispielsweise serielle Verarbeitung durch einen einzelnen Prozessor oder Multiprocessing oder Multitasking oder Parallelverarbeitung usw.
-
Die Instruktionen können in lokalen Speichern abgelegt sein, es ist aber auch möglich, die Instruktionen auf einem entfernten System abzulegen und darauf via Netzwerk zuzugreifen.
-
Der Begriff "Prozessor", "zentrale Signalverarbeitung", "Steuereinheit" oder "Datenauswertemittel", wie hier verwendet, umfasst Verarbeitungsmittel im weitesten Sinne, also beispielsweise Server, Universalprozessoren, Grafikprozessoren, digitale Signalprozessoren, anwendungsspezifische integrierte Schaltungen (ASICs), programmierbare Logikschaltungen wie FPGAs, diskrete analoge oder digitale Schaltungen und beliebige Kombinationen davon, einschließlich aller anderen dem Fachmann bekannten oder in Zukunft entwickelten Verarbeitungsmittel. Prozessoren können dabei aus einer oder mehreren Vorrichtungen bzw. Einrichtungen bzw. Einheiten bestehen. Besteht ein Prozessor aus mehreren Vorrichtungen, können diese zur parallelen oder sequentiellen Verarbeitung bzw. Ausführung von Instruktionen ausgelegt bzw. konfiguriert sein.
