DE102010004192A1

DE102010004192A1 - Verfahren zur Konstruktion industrieller Anlagen

Info

Publication number: DE102010004192A1
Application number: DE102010004192A
Authority: DE
Inventors: Rupert 91330 Maier
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2010-01-08
Filing date: 2010-01-08
Publication date: 2011-07-14
Also published as: US20110173043A1

Abstract

Verfahren und Engineeringsystem zur Konstruktion industrieller Anlagen auf der Basis anlagenunabhängiger, regelbasierter, konfigurierbarer, inkrementeller Workflow-Objekte, wobei aus den generell Workflow-Objekten mittels funktionaler Dekompensation ein Baum von relevanten Workflow-Objekten generiert wird, der den zur Erzeugung der Engineeringdokumente der zu konstruierenden Zielanlage abzuarbeitenden Workflow repräsentiert, und wobei aus den identifizierten Anlagenobjekten ein Anlagenlayout generiert wird, und durch eine Workflow-Engine mittels Interpretation der Daten, Objekte und Regeln der im Baumvorhandenen Workflow-Objekte diese abgearbeitet werden, und wobei durch Dokumentgeneratoren die für die zu konstruierende Anlage erforderliche Engineeringdokumentation in Form von resultierenden maschinenlesbaren Engineeringdokumenten generiert wird. Neben Anlagenobjekten und Engineeringobjekten wird vor allem das sukzessive angesammelte und standardisiert abgelegte Engineeringwissen wiederverwendet.

Description

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Konstruktion industrieller Anlagen auf der Basis anlagenunabhängiger, regelbasierter, konfigurierbarer Workflow-Objekte. Die Erfindung betrifft ferner ein Computerprogramm-Produkt und ein computerlesbares Medium, jeweils geeignet zur Durchführung des Verfahrens.
Die projektübergreifende Wiederverwendung von Engineeringdaten und -entscheidungen bei der Konstruktion industrieller Anlagen ist zu selten und daher das Engineering in Summe zu teuer. Dies kommt daher, dass einerseits die Kunden an einzelnen Stellen individuelle Teillösungen erwarten und andererseits in der Regel einzelne identische Teillösungen anderer Projekte schwer herauslösbar sind und daher oft nicht automatisch in ein neues Engineeringprojekt integriert werden können. Weiterhin beruhen viele Engineeringentscheidungen auf nicht nachvollziehbaren bzw. nicht reproduzierbaren Argumenten oder Regeln und sind oft vom Erfahrungshintergrund der involvierten Personen abhängig. Diese individuellen Einzelentscheidungen führen zu individuellen, wenig standardisierten Lösungen.
Ein Lösungsansatz liegt in der Identifikation und Verwendung sogenannter „Mechatronischer Objekte”. Ziel ist hierbei das Engineering durch Verschaltung möglichst großer, manuell identifizierter und vorab definierter wiederverwendbarer Objekte zu vereinfachen. Dabei sollen möglichst Gewerkegrenzen entfallen und die Gesamtanlage durch Modellierung aus den einzelnen mechatronischen Objekten entstehen. Diesem Ansatz liegt die Annahme zugrunde, dass große, flexible, wiederverwendbare Komponenten in Form von mechatronischen Objekten definierbar sind. In der Praxis ist die Definition solcher Objekte jedoch häufig relativ schwierig, da die verschiedenen Einsatzformen bei der Definition solcher Objekte oft nicht überschaut werden können bzw. noch unbekannt sind. Aufgrund der darin gekapselten, vorab definierten Beschreibung eines Anlagenteils stellen sich „Mechatronische Objekte” sehr schnell als relativ starke Einschränkung heraus. Auf die individuellen Wünsche der Kunden kann damit nur bedingt eingegangen werden.
In der US Patentschrift US 6,119,125 ist ein computerimplementiertes System zur Erstellung von Applikationen für die Gebäudeautomatisierung basierend auf vordefinierten, verschaltbaren Standardobjekten offenbart.
Die Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zur Konstruktion industrieller Anlagen auf der Basis anlagenunabhängiger, regelbasierter, konfigurierbarer Workflow-Objekte bereitzustellen, bei dem das Engineering industrieller Anlagen durch automatisierte Wissensansammlung und Verwendung inkrementeller Anlagenobjekte sukzessive vereinfacht wird.
Die Aufgabe wird gelöst durch ein Verfahren zur Konstruktion industrieller Anlagen auf der Basis anlagenunabhängiger, regelbasierter, konfigurierbarer Workflow-Objekte, wobei ein Workflow-Objekt umfasst:

– eine standardisierte maschinenlesbare Beschreibung einer inkrementellen Engineeringaufgabe,
– eine standardisierte maschinenlesbare Beschreibung von Daten und Objekten, die bei der Ausführung der Engineeringaufgabe konsumiert und/oder erzeugt werden,
– standardisierte maschinenlesbare Regeln, nach denen die Engineeringaufgabe auszuführen ist,

Eine erste vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Anforderungen in eine maschinenlesbare Form konvertiert werden, wenn diese noch nicht in einer maschinenlesbaren Form vorliegen. Durch das Konvertieren der Anforderungen in eine maschinenlesbare Form (z. B. in die Requirement Description Language RDL oder in CiNii) ist eine vollautomatische computergestützte Verarbeitung der Anforderungen möglich.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Workflow-Objekte in domänenspezifische bzw. disziplinspezifische und domänenunspezifische bzw. disziplinunspezifische klassifiziert werden. Dies erleichtert das Suchen geeigneter Objekte für das Anlagenengineering und erhöht ihre Wiederverwendung.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass unter der Menge aller projektspezifisch verwendeten Workflow-Objekte diejenigen Workflow-Objekte identifiziert werden, die manuell erstellt, modifiziert oder abgearbeitet wurden, und wobei diese Workflow-Objekte mit den dazugehörigen Daten, Objekten und Regeln in die Menge der maschinenlesbaren Workflow-Objekte überführt werden. Das erfindungsgemäße Verfahren besitzt somit eine Rückkopplungsschleife über die alle neuen oder abgewandelten Vorgehensweisen identifiziert und in das System als neue, künftig automatisiert durchführbare Engineeringschritte (in Form von Regeln) abgelegt werden. Auf diese Weise wächst das in den Datenbanken (Menge der Workflow-Objekte, Menge der Anlagenobjekte) enthaltene Engineeringwissen nach und nach an, sodass im Laufe der Zeit immer mehr Engineering-Aktivitäten automatisch abgearbeitet (interpretiert, adaptiert und verwendet) werden können. Bei der vorliegenden Erfindung handelt es sich somit um ein lernfähiges System, bei dem das Engineering industrieller Anlagen durch automatisierter Wissensansammlung und Verwendung sukzessive vereinfacht wird.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass vor der Überführung der Daten, Objekte und Regeln in die Menge der maschinenlesbaren Workflow-Objekte diese in domänenspezifische bzw. disziplinspezifische und domänenunspezifische bzw. disziplinunspezifische klassifiziert werden. Dies ermöglicht ein systematisches Erstellen wiederverwendbarer Workflow-Objekte.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass vor der Überführung der Daten, Objekten und Regeln in die Menge der maschinenlesbaren Workflow-Objekte diese hinsichtlich einer allgemeinen Einsetzbarkeit analysiert werden. Dadurch können domänenunspezifische bzw. disziplinunspezifische Workflow-Objekte erkannt und klassifiziert werden, wodurch die Wiederverwendbarkeit der Workflow-Objekte erhöht wird.
Die Aufgabe wird weiterhin gelöst durch eine Vorrichtung, insbesondere ein Engineeringsystem zur Modellierung technischer Anlagen, geeignet zur Durchführung eines der erfindungsgemäßen Verfahren. Beim Engineeringsystem kann es sich um einen handelsüblichen Computer (z. B. PC oder Workstation) handeln, mit entsprechender Software mit Modellierungswerkzeugen (z. B. UML-Arbeitsumgebung) zur Durchführung des Verfahrens. Je nach Anforderungen und Arbeitsumgebung, kann als Computer auch ein entsprechend ausgestatteter Industrie-PC verwendet werden.
Ferner wird die Aufgabe gelöst durch ein Computerprogramm-Produkt oder ein computerlesbares Medium, welche auf einer Programm gesteuerten Einrichtung die Durchführung des Verfahrens veranlassen. Dies erleichtert die Flexibilität des Einsatzes und auch die Verteilung und den kommerziellen Vertrieb des erfindungsgemäßen Verfahrens.
Ein Ausführungsbeispiel der Erfindung ist in der Zeichnung dargestellt und wird im Folgenden erläutert.
Dabei zeigen:
1 ein beispielhaftes schematisches Übersichtsbild für ein konventionelles Engineering,
2 ein beispielhaftes schematisches Übersichtsbild für ein Engineering mit Hilfe mechatronischer Objekte,
3 ein beispielhaftes schematisches Übersichtsbild für ein Engineering mit Hilfe regelbasierter Workflow-Objekte (RWO),
4 eine beispielhafte Wirkung eines regelbasierten Workflow Objektes (RWO),
5 einen beispielhaften RWO-Baum nach Dekomposition der originären und abgeleiteten Anforderungen,
6 ein schematisches beispielhaftes Übersichtsdiagramm zum Zusammenwirken von Komponenten zur Durchführung des erfindungsgemäßen Verfahrens, und
7 ein beispielhaftes Engineeringsystem zur Durchführung des erfindungsgemäßen Verfahrens.
1 zeigt ein beispielhaftes schematisches Übersichtsbild für ein konventionelles Anlagenengineering. 1 zeigt das Zusammenwirken und den Informationsfluss zwischen den Anforderungen bzw. den Requirement-Dokumenten RDok1, den Engineeringdaten E-Data1 und den Angebots-&Engineering-Dokumenten A&EDok1. Weiterhin klassifiziert 1 die Dokumente und Daten für das Anlagenengineering in einen lösungsspezifischen Bereich L-spez1 und einen lösungsübergreifenden Bereich L-unspez1. Bei den Engineeringdaten E-Data1 existieren somit spezifische Daten einer Anlage, die dediziert nur in einer spezifischen „Anlageninstanz” verwendet werden und „übergreifende Engineeringdaten”, die in mehreren Anlagen bzw. „Anlageninstanzen” Verwendung finden. Zu den übergreifenden Engineeringdaten zählen z. B. Lösungswissen, Typical-Datenbanken (mit z. B. Standardlösungen oder Standardobjekten) oder Komponenten-Datenbanken mit Standardkomponenten (z. B. Förderbänder, Öfen, Heizelementen). Auch disziplinspezifische Objekte und Standards und Normen zählen zu den übergreifenden Engineeringdaten. Bei den Angebots-&Engineering-Dokumenten A&EDok1 gehören zum lösungsspezifischen Bereich L-spez1 die Anlagen-Dokumente ADok1, die u. a. das Angebot, Stromlaufpläne, Produktblätter und die Steuerungssoftware umfassen.
Die Pfeile in 1 stellen den Workflow (Ablauf) zwischen den Dokumenten RDok1, A&EDok1 und Daten E-Data 1 dar. Durch die gestrichelten Pfeile wird die Kapselung von Informationen dargestellt (z. B. die Kapselung von Anforderungen/Requirements aus dem lösungsübergreifenden Bereich L-unspez1 der Requirement-Dokumente RDok1 in Standards und disziplinspezifische Objekte des Bereiches „übergreifende Engineeringdaten” der Engineering-Daten E-Data1). Ein einfacher durchgezogener Pfeil stellt eine Designentscheidung dar. Z. B. im lösungsspezifischen Bereich L-spez1 von den „Requirements zu einer Anlage” zum „Basic Design (Entwurf des Grundaufbaus)” der Engineeringdaten E-Data1. Ein fetter durchgezogener Pfeil stellt eine Generierung dar. Z. B. die Generierung von Anlagen-Dokumenten ADok1 aus „spezifischen mechatronischen Daten der Anlage”.
Beim konventionellen Anlagenengineering dominiert häufig ein manuelles „Copy&Modify” von Workflows und Teillösungen aus vorangegangenen Projekten mit folgenden Konsequenzen:

– Hoher manueller Aufwand die verwendbaren Teile zu identifizieren, sowie auf die jeweilige Zielanlage zu adaptieren.
– „Leichen” bleiben zurück
– Hohe Fehleranfälligkeit bei „leichten” Abweichungen in den Requirements.
– Zu geringe Toolunterstützung im Requirementmanagement, -Tracing und Claiming.

Viele Engineeringentscheidungen beruhen beim konventionellen Vorgehen oft auf nicht nachvollziehbaren bzw. nicht reproduzierbaren Argumenten oder Regeln und sind oft vom Erfahrungshintergrund der involvierten Personen abhängig. Diese individuellen Einzelentscheidungen führen zu individuellen, wenig standardisierten und oft suboptimalen Lösungen. Komplexe technologische Zusammenhänge bei denen einzelne, individuelle Sachverhalte zu komplett anderen Lösungsansätzen führen, behindern den flächendeckenden Einsatz großer vorgefertigter Typicals bzw. mechatronischer Objekte. Die Anlagen-Errichtungsdauer ist oft ein entscheidender Flaschenhals. Doch selbst triviale Engineeringentscheidungen werden nach wie vor manuell getroffen, obwohl diese i. d. R. den Löwenanteil der Engineeringarbeiten ausmachen.
Die projektübergreifende Wiederverwendung von Engineeringdaten und -entscheidungen ist beim konventionellen Vorgehen zu selten und daher das Engineering in Summe zu teuer. Dies kommt daher, daß einerseits die Kunden an einzelnen Stellen individuelle Teillösungen erwarten und andererseits in der Regel einzelne identische Teillösungen anderer Projekte schwer herauslösbar sind und daher oft nicht automatisch in ein neues Engineeringprojekt integriert werden können. Die Situation verschärft sich im Laufe der Zeit, da so statt Standards nach und nach mehrere ähnliche aber nicht identische Lösungen für die gleichen Teilaufgaben entstehen.
2 zeigt ein beispielhaftes schematisches Übersichtsbild für ein Engineering von Anlagen mit Hilfe mechatronischer Objekte. Der Begriff Mechatronik beschreibt das Zusammenspiel verschiedener Disziplinen wie – je nach Branche und Bedarf – Mechanik, Elektrik, Automatisierung sowie weiterer Informationen zu Aktivitäten, die das Engineering bzw. die Projektabwicklung auf verschiedene Art unterstützen (z. B.: Vertrieb, Kalkulation, Projektleitung etc.). All diese mechatronischen Informationen können auf die zum Einsatz kommenden technischen Komponenten bezogen werden. Dieses Zusammenspiel wird über eine digitale Repräsentation des Objektes beschrieben, das sogenannte mechatronische Objekt. Ein mechatronisches Objekt kann dabei verschiedene sogenannte Facetten beinhalten, zum Beispiel eine Facette für jede Disziplin. Die Facetten stellen die Daten einer jeweiligen Disziplin dar. Dadurch werden softwaretechnische Prinzipien, wie z. B. das Lokalitätsprinzip und die Datenkapselung (encapsulation) auf einfache Weise berücksichtigt.
Wie 1 zeigt auch 2 das Zusammenwirken und den Informationsfluss zwischen den Anforderungen bzw. den Requirement-Dokumenten RDok2, den Engineeringdaten E-Data2 und den Angebots-&Engineering-Dokumenten A&EDok2. Weiterhin klassifiziert 2 die Dokumente und Daten für das Anlagenengineering in einen lösungsspezifischen Bereich L-spez2 und einen lösungsübergreifenden Bereich L-unspez2. Bei den Engineeringdaten E-Data2 existieren somit spezifische Daten einer Anlage, die dediziert nur in einer spezifischen „Anlageninstanz” verwendet werden und „übergreifende Engineeringdaten”, die in mehreren Anlagen bzw. „Anlageninstanzen” Verwendung finden. Zu den übergreifenden Engineeringdaten zählen z. B. Lösungswissen, Typical-Datenbanken (mit z. B. Standardlösungen oder Standardobjekten) oder Komponenten-Datenbanken mit Standardkomponenten (z. B. Förderbänder, Öfen, Heizelementen). Auch mechatronische Objekthierarchien und wiederverwendbare mechatronische Objektklassen zählen zu den übergreifenden Engineeringdaten beim Anlagenengineering nach 2. Aus den mechatronischen Objekthierarchien und den wiederverwendbaren mechatronischen Objektklassen werden spezifische Instanzen von mechatronischen Objekten für die Verwendung in einer konkreten Anlage generiert. Diese spezifische Instanzen von mechatronischen Objekten zählen bei den Engineering-Daten E-Data2 zum lösungsspezifischen Bereich.
Beiden Angebots-&Engineering-Dokumenten A&EDok2 gehören zum lösungsspezifischen Bereich L-spez2 die Anlagen-Dokumente ADok2, die u. a. das Angebot, Inbetriebnahme- und Kundendokumente wie Stromlaufpläne, Produktblätter und die Steuerungssoftware umfassen.
Die Pfeile in 2 stellen den Workflow (Ablauf) zwischen den Dokumenten RDok2, A&EDok2 und Daten E-Data2 dar. Durch die gestrichelten Pfeile wird die Kapselung von Informationen dargestellt (z. B. die Kapselung von Anforderungen/Requirements aus dem lösungsübergreifenden Bereich L-unspez2 der Requirement-Dokumente RDok2 in die mechatronischen Objekthierarchien und die wiederverwendbaren mechatronischen Objektklassen der (übergreifenden) Engineering-Daten E-Data2). Ein einfacher durchgezogener Pfeil stellt eine Selektion als Designentscheidung dar. Z. B. die Selektion eines spezifischen mechatronischen Objektes (z. B. eines Objektes Förderband) aus der mechatronischen Objekthierarchie für eine spezifische Instanzierung in einer konkreten Anlage. Ein fetter durchgezogener Pfeil stellt eine Generierung dar. Z. B. die Generierung von Anlagen-Dokumenten ADok2 aus „spezifischen Instanzen der mechatronischen Objekte” für eine konkrete Anlage. Ein Doppelpfeil stellt eine Adaption dar. Z. B. Die Adaption der „Requirements zu einer Anlage” aus den lösungsspezifischen Requirement-Dokumenten RDok2 in die „spezifischen Daten einer Anlage” der Engineering-Daten E-Data2.
2 beschreibt das Vorgehen beim Anlagenengineering unter Verwendung sog. „Mechatronischer Objekte”. Ziel ist das Engineering durch Verschaltung möglichst großer, manuell identifizierter und vorab definierter wiederverwendbarer Objekte zu vereinfachen. Dabei sollen möglichst Gewerkegrenzen entfallen und die Gesamtanlage durch Modellierung aus den einzelnen mechatronischen Objekten entstehen. Diesem Ansatz liegt die Annahme zugrunde, dass große, flexible, wiederverwendbare Komponenten in Form von mechatronischen Objekten definierbar sind. In der Praxis ist die Definition solcher Objekte jedoch häufig relativ schwierig, da die verschiedenen Einsatzformen bei der Definition solcher Objekte oft nicht überschaut werden können bzw. noch unbekannt sind. Die größte Herausforderung ist es also, möglichst große, standardisierte, wiederverwendbare Anlagenteile in Form von Objekten (im Sinne der Objektorientierung) zu identifizieren bzw. zu definieren. Die Adaption der Objekte an die spezifische Engineeringaufgabe erfolgt manuell.
Konsequenzen:

– Bei diesem Ansatz verrichtet noch immer der Mensch einen großen Anteil der komplexen, unübersichtlichen Aufgaben, bei denen es darum geht, abzuwägen, welche Objekte die richtigen sind und zu erkennen wo ggf. punktuell modifiziert oder ergänzt werden muss. Das Wissen ist also noch immer zu einem großen Anteil im Kopf der entsprechenden, immer rarer werdenden, Experten. Die maschinelle Unterstützung bei dieser schwierigen Aufgabe ist noch immer gering. Auch ein Vorschlag zur Reihenfolge der Abarbeitung der erforderlichen manuellen Arbeiten ist daraus nicht ableitbar.
– Aufgrund der darin gekapselten, vorab definierten Beschreibung eines Anlagenteils stellen sich „Mechatronische Objekte” sehr schnell als relativ starke Einschränkung heraus. Auf die individuellen Wünsche der Kunden kann damit nur bedingt eingegangen werden.
– Auch die Möglichkeit zur Identifikation einer ”optimalen Lösung” nach bestimmten Kriterien (KPIs (Key Performance Indicator, Lifecycle- Betrachtungen, ...) wird verhindert, eingeschränkt oder zumindest kaum unterstützt. Selbst die ggf. dabei gewonnene Möglichkeit das künftige Anlagenverhalten zu simulieren, kann dieses Problem nur bedingt lösen, da die Verwendung großer, miteinander verschaltbarer Objekte die Freiheitsgrade im Design der Anlage stark einschränkt.

3 zeigt ein beispielhaftes schematisches Übersichtsbild für ein Anlagenengineering mit Hilfe regelbasierter Workflow-Objekte. 3 zeigt das Zusammenwirken und den Informationsfluss zwischen den Anforderungen bzw. den Requirement-Dokumenten RDok3, den Engineeringdaten E-Data3 und den Angebots-&Engineering-Dokumenten A&EDok3. Weiterhin klassifiziert 3 die Dokumente und Daten für das Anlagenengineering in einen lösungsspezifischen Bereich L-spez3 und einen lösungsübergreifenden Bereich L-unspez3. Bei den Engineeringdaten E-Data3 existieren somit spezifische Daten einer Anlage, die dediziert nur in einer spezifischen „Anlageninstanz” verwendet werden und „übergreifende Engineeringdaten”, die in mehreren Anlagen bzw. „Anlageninstanzen” Verwendung finden. Zu den übergreifenden Engineeringdaten zählen z. B. Lösungswissen, Standards-&Typical-Datenbanken (mit z. B. Standardlösungen oder Standardobjekten) oder Komponenten-/Produkt-Datenbanken mit Standardkomponenten (z. B. Förderbänder, Öfen, Heizelementen). Zu den übergreifenden Engineeringdaten beim Anlagenengineering basierend auf regelbasierten Workflow-Objekten zählen auch übergreifende Requirements-Regeln, sowie Anlagenprodukte (Produktraum), Regeln zum Workflow (Technologieraum und Information zur Engineeringabwicklung (Methodenraum). Zu den spezifischen Engineeringdaten einer Anlage gehören u. a. spezifische Requirementsregeln, Engineering Objekte bzw. Engineeringdaten der Anlage, sowie der spezifische Workflow.
Bei den Angebots-&Engineering-Dokumenten A&EDok3 gehören zum lösungsspezifischen Bereich L-spez3 die Anlagen-Dokumente ADok3, die u. a. das Angebot, Inbetriebnahme- und Kundendokumente wie Stromlaufpläne, Produktblätter und die Steuerungssoftware umfassen. Im lösungsübergreifenden Bereich L-unspez3 zählen zu den Angebots-&Engineering-Dokumenten A&EDok3 u. a. Dokumentvorlagen und Produktdokumentationen.
Die Pfeile in 3 stellen den Workflow (Ablauf) zwischen den Dokumenten RDok3, A&EDok3 und Daten E-Data 3 dar. Durch die gestrichelten Pfeile wird die Kapselung von Informationen dargestellt (z. B. die Kapselung von Anforderungen/Requirements aus dem lösungsübergreifenden Bereich L-unspez3 der Requirement-Dokumente RDok3 in die „übergreifenden Requirements-Regeln” der (übergreifenden) Engineering-Daten E-Data3). Ein einfacher durchgezogener Pfeil stellt eine Selektion als Designentscheidung dar. Z. B. die Selektion eines spezifischen Produktblattes aus der lösungsübergreifenden Produktdokumentation. Ein fetter durchgezogener Pfeil stellt eine Generierung dar. Z. B. die Generierung von Anlagen-Dokumenten ADok3 aus den Engineering Objekten bzw. Engineeringdaten für eine konkrete Anlage oder die Generierung von spezifische Requirementsregeln aus übergreifenden Requirements-Regeln. Ein Doppelpfeil stellt das Lernen dar. Das Lernen stellt eine Rückkopplungsschleife vom spezifischen Workflow für eine konkrete Anlage zu den allgemeinen Workflow-Regeln der übergreifenden Engineeringdaten dar.
Es handelt es sich somit um ein lernfähiges Verfahren bzw. System, bei dem das Engineering industrieller Anlagen durch automatisierter Wissensansammlung und Verwendung sukzessive vereinfacht wird. Im Gegensatz zu gängigen Methoden einzelne, möglichst große Anlagenteile und deren Engineeringdaten wiederzuverwenden und diese dann manuell zu adaptieren und zu integrieren, werden hier einzelnen elementare Verhaltensmuster und Verhaltensregeln und Abarbeitungsschritte (also das Engineeringwissen selbst) in elementaren Workflowobjekten gekapselt. Dabei wird charakterisiert, welche Engineeringvorgehensweise unter welchen Umständen (Requirements) eingesetzt werden kann.
Zur Abwicklung konkreter Engineeringprojekte werden schließlich die jeweiligen Requirements automatisiert interpretiert und darauf aufsetzend die passenden regelbasierten Workflowobjekte identifiziert, an die konkrete Aufgabenstellung adaptiert und zu einem Gesamtworkflow vereint.
Anschließend werden alle automatisierbaren Einzelaufgaben der Workflows automatisch abgewickelt, sodass nur die Aufgaben verbleiben, die tatsächlich neues, im System noch nicht vorhandenes Engineeringwissen, erfordern.
Das vorgestellte Verfahren bzw. System besitzt auch eine Rückkopplungsschleife (Doppelpfeil „Lernen”) über die alle neuen oder abgewandelten Vorgehensweisen identifiziert und in das System also neue, künftig automatisiert durchführbare Engineeringschritte (in Form von Regeln) abgelegt werden. Auf diese Weise wächst das in den Datenbanken enthaltene Engineeringwissen nach und nach an, sodass im Laufe der Zeit immer mehr Engineering-Aktivitäten automatisch abgearbeitet (interpretiert, adaptiert und verwendet) werden können.
Neben Objekten zu einzelnen Anlagenkomponenten und Engineeringobjekten wird bei dem erfindungsgemäßen Vorgehen vor allem das sukzessive angesammelte und standardisiert abgelegte Engineeringwissen wiederverwendet. Dies führt dazu, dass der Gesamtworkflow zur Abwicklung des Engineering einer industriellen Anlage aus vielen standardisierten Teilworkflows zusammengesetzt wird und die einzelnen Engineeringaufgaben dort wo es möglich ist (also wo das abgelegte Wissen ausreicht) automatisiert abgewickelt werden.
4 zeigt eine beispielhafte Wirkung eines regelbasierten Workflow Objektes RWO bei dessen Einsatz im Anlagenengineering. Ziel des Anlagenengineering ist die Planung und Auslegung von kompletten industriellen Anlagen (z. B. eine Fabrik), Teilanlagen (z. B. Materialflusssystem in einer Fabrik) oder Teilkomponenten (z. B. eine Maschine). Ein regelbasiertes Workflow Objekt RWO enthält im Wesentlichen eine Beschreibung unter welchen Umständen welche Sequenz an Engineeringaufgaben (Workflow) durchzuführen ist, welche Daten/Objekte dabei konsumiert und erzeugt werden und welche Variationsmöglichkeiten dabei existieren, um Anforderungen von übergeordneten Objekten zu erfüllen. Die Beschreibung erfolgt in Form von Regeln. Bei der Interpretation bzw. Abarbeitung dieser Regeln werden die ebenfalls im regelbasierten Workflow Objekt RWO hinterlegten Argumente beachtet. Über diese Argumente, aber auch die Einbettung in einen spezifischen RWO-Baum (siehe 5), kann das Verhalten eines regelbasierten Workflow Objektes RWO auf die jeweilige Situation adaptiert werden. Im Laufe der Abarbeitung des daraus abzuleitenden Workflows werden für jedes regelbasierte Workflow Objekt RWO alle dabei entstandenen Engineeringdaten und Engineeringobjekte hinterlegt (direkt oder in Form von Zeigern bzw. Links).
Die verwendeten Regeln sind maschinenlesbare Vorgaben zur Verwendungsmöglichkeit einzelner Objekte (z. B. regelbasiertes Workflow Objekt RWO) und enthalten Vorschriften (z. B. bzgl. Freiheitsgraden und Varianten, einzuhaltenden Normen, Nomenklaturen, zu verwendende Formate, ...) bei der Ausführung einzelner Teilaufgaben innerhalb den Workflow-Sequenzen. Zur Beschreibung solcher Regeln können regelbasierte Sprachen verwendet werden, wie z. B. RC++ als regelbasierte Erweiterung von C++, Business Rule Markup Language (BRML) oder Xcerpt.
5 zeigt einen beispielhaften Baum SRWOs von regelbasierten Workflow Objekten RWOx nach Dekomposition der originären und abgeleiteten Anforderungen an eine industrielle Anlage oder Teilanlage. Der Baum SRWOs von miteinander verknüpften regelbasierten Workflow Objekten RWOx, die auf die einzelnen, spezifischen Engineeringaufgaben adaptiert wurden und in Summe in der Lage sind, alle vorhandenen Anforderungen zum Engineering der spezifischen Anlage abzudecken, wird vom Builder (siehe 6) generiert. Dieser Baum stellt auch den abzuarbeitenden Gesamtworkflow für die Workflow-Engine des Workflow-Manager (siehe 6) dar, um das „Detailed Design (detaillierter Anlagenentwurf)” durchzuführen. Der Baum SRWOs wird generiert basierend auf der Menge aller originärer Anforderungen SOANFs an eine spezifische Anlage, beschrieben in einer standardisierten, machinenlesbaren Form und priorisiert nach Wichtigkeit und basierend auf der Menge aller abgeleiteten spezifischen Anforderungen SAANFs resultierend aus der Art der Lösung im Basic Design (Entwurf des Grundaufbaus einer industriellen Anlage) also dem Einsatz bestimmter regelbasierten Workflow Objekte samt seiner Merkmale und Freiheitsgrade.
6 zeigt ein schematisches beispielhaftes Übersichtsdiagramm zum Zusammenwirken von Komponenten und Teilsystemen zur Durchführung des erfindungsgemäßen Verfahrens. Der obere Bereich L-spez4 von 6 umfasst anlagenspezifische, adaptierte Daten, der untere Bereich L-unspez4 von 6 umfasst anlagenunabhängige vorgefertigte Objekte und Daten (z. B. Komponenten eines Anlagenbauers).
Beschreibung der Teilsysteme und deren Zusammenwirken:
Converter
Ist ein optionales Teilsystem des erfinderischen Systems. Der Converter ist ein Editor, der bei der teilautomatisierten Umsetzung nicht maschinenlesbarer Anforderungen (SDOANFs) in ein standardisiertes, maschinenlesbares Format unterstützt. Dieses Format kann beispielsweise auf einer maschinenlesbaren Beschreibungssprache beruhen. Beispiele für Sprachen zur Beschreibung von Anforderungen sind die „Requirement Description Language” (RDL) oder CiNii. Der Converter besitzt also Funktionalitäten um zusammengehörende Textpassagen einfach zu lokalisieren und in aufbereiteter strukturierter Form zu lesen. Weiterhin besitzt der Converter einen Editor der dabei unterstützt, diese Anforderungen mittels der verwendeten, maschinenlesbaren Sprache zu beschreiben (SOANFs). Liegt dieses maschinenlesbare Format bereits von Haus aus vor, so ist die Verwendung des Converters nicht nötig.
SDOANFs
Unformatierte Dokumente mit allen originären Anforderung (Kunde, Domäne, Umweltauflagen, ...) der spezifischen Anlage, deren Engineering durchzuführen ist.
SOANFs
Die Menge aller originären Anforderungen an eine spezifische Anlage, beschrieben in einer standardisierten, machinenlesbaren Form und priorisiert nach Wichtigkeit.
SANFs
Menge aller beim Engineering der konkreten Anlage zu berücksichtigenden spezifischen Anforderungen. Also die Summe aller Anforderungen, egal ob diese originärer Natur sind (SOANFs), oder aus einzelnen spezifischen Engineeringentscheidungen abgeleitet wurden (SAANFs).
Builder (Entwerfer)
Der Builder stellt das wichtigste Teilsystem der vorliegenden Erfindung dar. Er setzt auf anlagenunabhängigen, bereits vorhandenen Objekten (OANANFs, EOs, AOs und RWOs) und dem darin gekapselten Engineeringwissen auf und verwendet zusätzlich die Menge aller anlagenspezifischen Anforderungen (SANFs), um mittels automatisierter Dekompensation daraus einen Baum an regelbasierten, adaptierten Workflowobjekten (RWOs) zu generieren. Das Ergebnis kommt im bisher üblichen Engineering industrieller Anlagen dem sog. „Basic Design” gleich. Das Basic Design der resultierenden industriellen Anlage (also die Definition der funktionalen Konzepte und Anlagenarchitektur) kann dabei wahlweise, (punktuell oder insgesamt) manuell oder automatisiert erfolgen. Bei den Designentscheidungen berücksichtigt der Builder die Freiheitsgrade der einzelnen Objekte und die Art der Lösung vergleichbarer Anforderungen (egal ob im selben oder in vorhergehenden Engineeringprojekten). Neben der Interpretation der hinterlegten Regeln, werden auch die Argumente der einzelnen in Frage kommenden RWOs betrachtet (z. B.: Sind die im RWO eingesetzten Objekte Vorzugsvarianten? Wie oft wurden sie bereits eingesetzt? Dürfen Sie auch in diesem Projekt mit seinen spezifischen Anforderungen eingesetzt werden? ...). Bei mehreren möglichen Design-Alternativen identifiziert ein geeignetes Optimierungsverfahren die optimalen Technologien und Anlagenteile und erzeugt so eine Anlagentopologie, die einerseits konform zur erwarteten Kundenlösung und andererseits nach bestimmten Kriterien (Stichwort Key Performance Indicators KPIs) optimal ist. Es wird davon ausgegangen, dass die in SANFs vorliegenden Anforderungen in einer bestimmten Priorität abgelegt werden. Daher werden die Anforderungen auch in der entsprechenden Reihenfolge abgearbeitet. Dies stellt sicher, dass die wichtigsten Designentscheidungen am Anfang gefällt werden und alle nachfolgenden Designentscheidungen des Builders die bereits davor getroffenen Entscheidungen berücksichtigen.
Einzelne Designentscheidungen können zu neuen Anforderungen an allen anderen RWOs führen. Um deren Berücksichtigung sicherzustellen, werden diese sog. abgeleiteten Anforderungen (SAANFs) ebenso in die Liste der spezifischen Anforderungen (SANFs) aufgenommen.
In jedem RWO wird hinterlegt, welche Anforderungen damit korreliert sind, sodass ein einfaches Requirement-Tracing möglich ist. Aus den Schritt für Schritt getroffenen Entscheidungen wird ein Baum (SRWOs) an regelbasierten Workflowobjekten (RWOs) errichtet, wobei die einzelnen RWOs auf die jeweilige spezifische Aufgabe im Baum adaptiert werden (Aktivierung/Passivierung/Konkretisierung von enthaltenen Regeln, setzen von Attributen, Verknüpfen mit anderen Objekten, ...). Liegen nicht genügend aussagekräftige Informationen zum automatisierten Fällen der entsprechenden Designentscheidung vor, so identifiziert der Builder dies und ermöglicht das manuelle Fällen der Entscheidung mittels eines menschlichen Experten. Da der Builder sukzessive arbeitet und alle bisher getroffenen Design-Entscheidungen bei allen nachfolgenden Designentscheidungen berücksichtigt, erlaubt er auch ein „Rebuild” bzw. „Optimize” nachdem z. B. einzelne Designentscheidungen oder Requirements variiert wurden.
Argumente
Stellen Stellschrauben dar, die z. B. auf das prinzipielle Verhalten und die Freiheitsgrade der jeweiligen Objekte (z. B. RWOs) einwirken. Beispiele für diese Stellschrauben sind „Höhe der Sicherheitsanforderungen”, Anzahl der Projekte in der das Objekt bisher zum Einsatz kam, Art der Projekte für die das Objekt geeignet ist, Ausschluß oder Präferierung bestimmter Hersteller oder Varianten, landes- oder kundenspezifische Regelungen, ...). Argumente können sowohl anlagenunabhängig als auch anlagenspezifisch sein. Mögliche Informationen wie die Argumente einzelner Objekte wie EOs, AOs oder RWOs einzustellen sind, können von SANFs und OANANFs stammen. Ein Teil der Argumente kann auch über den Learner beeinflusst werden (z. B. stat. Information über die Häufigkeit der Nutzung, etc.).
SRWOs
Entpricht einem vom Builder errichteten Baum von miteinander verknüpften RWOs, die auf die einzelnen, spezifischen Engineeringaufgaben adaptierten wurden und in Summe in der Lage sind, alle vorhandenen Anforderungen zum Engineering der spezifischen Anlage abzudecken. Dieser Baum stellt auch den abzuarbeitenden Gesamtworkflows für die Workflow-Engine dar, um das „Detailed Design” durchzuführen.
Workflow Manager (Ablauforganisierer)
Der Workflow Manager enthält eine Workflow Engine, die den jeweils in SRWOs beschriebenen Workflow aufgreift und dabei unterstützt diesen abzuarbeiten (entspricht im konventionellen Engineering dem Detailed Design). Der resultierende Workflow geht aus der situationsbedingten Interpretation der im jeweiligen RWO hinterlegten Attribute und den enthaltenen Regeln hervor und kann bei Bedarf in eine entsprechende Workflow-Beschreibungsprache (Beispiel: „Workflow description Language” vom WWW Consortium oder Business Process Excecution Language) überführt und anschließend abgearbeitet werden. Die darin enthaltene Workflow Engine überwacht den Status der Abarbeitung der einzelnen Engineeringaufgaben. Auch werden alle Lücken und Defizite (nicht erfüllte Requirements, fehlende Komponenten, ...) transparent gemacht. Weiterhin identifiziert sie, welche Engineeringaufgaben aktuell von wem abgearbeitet werden können und welche unerledigten Aufgaben gerade besonders behindernd auf die Abarbeitung in den anderen Gewerken wirken. Eine statistische Auswertung ermittelt zu jeder Zeit ein Maß für den Arbeitsfortschritt (global und rollen- bzw. gewerkespezifisch). Ein Interface zur Terminplanung ermöglicht die automatische Ermittlung einer „optimalen” Abarbeitungsreihenfolge.
Additiv überprüft der sog. „Virtual Expert (virtueller Experte)” permanent, ob Teilaufgaben im Workflow vorhanden sind, die aufgrund der vorhandenen Informationen auch automatisch erledigt werden könnten. Ist dies der Fall so werden diese auf Wunsch umgehend vom „Virtual Expert” automatisch bearbeitet. Dabei werden neben den Requirements alle sonst noch vorhandenen Daten und Vorgaben berücksichtigt und daraus die entsprechenden Engineeringdaten abgeleitet und abgelegt. Bei bisher unbekannten, abgewandelten oder sehr komplexen Aufgabenstellungen sind manuelle Interaktionen erforderlich. Die Durchführung solcher Engineeringaufgaben wird durch das erfindungsgemäße System unterstützt, indem die jeweilige Teilaufgabe automatisch identifiziert und alle erforderlichen, bereits bekannten Daten (Requirements, Interfaces, ...) in den Gesamt-Workflow eingebettet und in der für die Aufgabe erforderlichen Art und Weise dargestellt werden (gewerke- und aufgabenartspezifische Sichten, Transfer der Daten an die entsprechenden Engineering-Werkzeuge). Additiv unterstützt das System, indem es nach verwandten Aufgabenstellungen sucht und dem Benutzer die dabei gefunden Lösungswege zur Verwendung und/oder Modifikation vorlegt. Bei der manuellen Abarbeitung einer Engineeringaufgabe wird der menschliche Experte angehalten, additive Angaben zu machen, warum er die entsprechende Aufgabe in der vorliegenden Art und Weise gelöst hat. Diese Information wird später (im Learner) dazu herangezogen, automatisch daraus weitere Regeln für das jeweilige RWO abzuleiten und so (wo möglich) die Engineeringaufgabe in Zukunft automatisch auszuführen oder zumindest die manuelle Abwicklung besser zu unterstützen. Losgelöst davon, ob eine manuelle oder automatische Abwicklung der jeweiligen Engineeringaufgabe vorliegt, werden die resultierenden Engineeringdaten in die Baumstruktur der SRWOs aufgenommen oder mit diesem verlinkt.
Generator
Ist ein Platzhalter für die Menge aller Dokumentgeneratoren die benötigt werden, um aus den in SRWOs enthaltenen Engineeringdaten alle Engineering-Dokumente (SEDs) zu erstellen, die zur Errichtung der industriellen Anlage erforderlich sind. Die resultierenden Dokumente (SEDs) sind je nachdem z. B. Computerprogramme die in die Industrielle Anlage integriert werden aber auch Inbetriebsetzungsdokumente oder an den Kunden auszuliefernde Dokumente, die gelesen werden und den jeweils gültigen Beschreibungsregeln entsprechen müssen. Als Austauschformat/-System könnte dabei „JT”, die „Document Structure Description” oder auch „DOCBOOK” verwendet werden.
Regel
Regeln sind maschinenlesbare Vorgaben zur Verwendungsmöglichkeit einzelner Objekte (z. B. RWOs) und enthalten Vorschriften (z. B. bzgl. Freiheitsgraden und Varianten, einzuhaltenden Normen, Nomenklaturen, zu verwendende Formate, ...) bei der Ausführung einzelner Teilaufgaben innerhalb den Workflow-Sequenzen. Zur. Beschreibung solcher Regeln können regelbasierte Sprachen dienen (Beispiele: RC++ verwendet für Sony WorkStation2, Business Rule Markup Language oder Xcerpt der UNI München).
RWO
Entspricht einem sog. Regelbasierten Workflow Objekt”. Solche Objekte enthalten im Wesentlichen eine Beschreibung unter welchen Umständen welche Sequenz an Engineeringaufgaben (Workflow) durchzuführen ist, welche Daten/Objekte dabei konsumiert und erzeugt werden und welche Variationsmöglichkeiten dabei existieren. Die Beschreibung erfolgt in Form von Regeln. Bei der Interpretation bzw. Abarbeitung dieser Regeln werden die ebenfalls im Objekt hinterlegten Argumente beachtet. Über diese Argumente, aber auch die Einbettung in den spezifischen RWO-Baum (SRWOs), kann das Verhalten eines RWOs auf die jeweilige Situation adaptiert werden. Im Laufe der Abarbeitung des daraus abzuleitenden Workflows werden jedem RWO alle dabei entstandenen Engineeringdaten und -objekte hinterlegt (direkt oder in Form von Links).
RWOs
Datenbank mit der Menge aller global verfügbaren, anlagenunspezifischen „Regelbasierten Workflow Objekte”. Diese Objekte enthalten Regeln zum Engineering verfügbarer Produkte, Produktvarianten, Teilsysteme oder unterlagerter RWOs.
EOs
Datenbank mit der Menge aller global verfügbaren, anlagenunspezifischen „Engineering Objekte” (Repräsentanten für Signallisten, Verdrahtungslisten, Schrankpläne, ...) die zur Erzeugung der benötigten Engineering Dokumente (SEDs) erforderlich sind.
AOs
Datenbank mit der Menge aller verfügbaren anlagenunspezifischen „Anlagen Objekte” (Repräsentanten für verfügbare physikalische Anlagenkomponenten, Typicals und Teilsysteme, die bei der Errichtung spezifischer Anlagen Verwendung finden können).
OANANFs
Originäre anlagenunspezifische Anforderung des Anlagenbauers (globale Regeln, akzeptierte/nicht akzeptierte Vorgehensweisen, etc.)
SAANFs
Menge aller abgeleiteten spezifischen Anforderungen resultierend aus der Art der Lösung im Basic Design also dem Einsatz bestimmter RWOs samt seiner Merkmale und Freiheitsgrade.
SEDs
Menge aller spezifischen Engineering-Dokumente zur Errichtung der konkreten Anlage (Stromlaufpläne, Verdrahtungspläne, Baupläne, ...)
Learner (Lernkomponente)
Der Learner identifiziert die Stellen im Workflow, wo ein manuelles Engineering stattfand. Dort analysiert der Learner im Nachhinein, welche Besonderheiten in den Anforderungen und welche Annahmen/Entscheidungen in der Lösungsfindung vorlagen und leitet daraus (soweit dies möglich ist) neue Regeln ab. Weiterhin wird auch die Häufigkeit registriert, mit der einzelne Technologien (Workflow- und Anlagenteile) eingesetzt werden (Statistik). Auf diesem Weg bilden sich automatisch Vorzugsvarianten für nachfolgende Projekte heraus. Der Einsatz geeigneter Plausibilitäts-Checks stellt sicher, dass nur verifiziertes Wissen in die Wissensdatenbank aufgenommen wird. Additiv können diese Regeln auch manuell verifiziert und korrigiert werden. Zu diesem Zweck werden diese über einen geeigneten Editor einen menschlichen Experten vorgelegt, bevor sie als neues Wissen (neue Regeln) in die anlagenunabhängigen Objekte (RWOs, AOs, EOs, OANANFs) übernommen werden.
Menschliche Experten können auch losgelöst von irgendwelchen konkreten Anlagenprojekten Regeln eingeben und so Engineeringwissen hinterlegen und dem erfinderischen System zugänglich machen. Zur Beschreibung der jeweiligen Regeln kann eine geeignete Regelsprache herangezogen werden
Generell stellt das erfinderische System bzw. Verfahren beim Engineering industrieller Anlagen die Wiederverwendung von Vorgehensweisen im Engineering in den Vordergrund. Diese Engineeringtechnologien entsprechen einer Kombination aus vorliegenden Regeln, dem Einsatz vorgefertigter Anlagen- und Engineeringkomponenten, sowie Regeln zur Ableitung von Workflow- Fragmenten zur Definition zugehöriger Engineeringdaten. Diese angesprochenen Technologien werden in Form von Anlagen-Abwicklungswissen in geeigneten Datenbanken abgelegt, nachdem sie weitgehend automatisch bei der Abwicklung von Engineering-Projekten identifiziert, verallgemeinert und erfasst wurden. Die Wiederverwendung von vorkonfigurierter oder in anderen Projekten verwendeten Lösungskomponenten (Anlagenkomponenten und deren zugehörigen Engineeringdaten) ist eine Folge aus dieser Vorgehensweise.
Bei der Abwicklung des Engineering einer neuen Anlage ermittelt das erfinderische Verfahren aus den spezifischen, maschinenlesbaren Kundenanforderungen, statistischen Größen vorhergehender Anlagen und den abgelegten Anlagenabwicklungswissen und Anlagenobjekten automatisch eine Vorschlag für die optimale Anlagenstruktur und den zum Engineering der Anlage erforderlichen Workflow. Weiterhin führt das erfindungsgemäße System, aufsetzend auf dem abgelegten Anlagenabwicklungswissen, alle automatisch durchführbaren Engineeringaufgaben selbsttätig durch, sodass nur noch die Aufgaben zurückbleiben, die bisher aufgrund fehlenden Wissens oder zu hoher Komplexität noch nicht automatisch abgewickelt werden können.
Das oben vorgestellte Engineeringverfahren bzw. -system bietet inbesondere folgende Vorteile:

– Minimierung des Anteils manueller Engineering-Aufgaben und des Kommunikationsaufwandes des involvierten Personals auf das erforderliche Maß durch automatischer Wiederverwendung von Engineeringentscheidungen. Automatische Abwicklung aller Engineeringaufgaben, für die das erforderliche Engineeringwissen bereits im erfinderischen System enthalten ist.
– Lösung des sich anbahnenden Facharbeitermangels auch beim Engineering industrieller Anlagen. Automatisierte Überführung veränderter oder neuer manueller Verhaltensmuster im Engineering in neues, automatisiert verwertbares Engineeringwissen. Dabei entstehen relativ geringe Anlaufkosten aufgrund sukzessiver automatisierter Wissensakquise.
– Höhere Flexibilität führt zu optimierteren Anlagen. Möglichkeit zur automatisierten Identifikation einer ”Optimalen Lösung” nach bestimmten Kriterien (KPIs). Einsatz vieler kleiner, automatisch selektierbarer und konfigurierbarer Objekte statt der Verwendung von nur wenigen, einegenden, unüberschauberen und manuell auszuwählenden und einzustellenden Mamutobjekten.
– Automatisches Sicherstellen, dass alle vorhandenen Requirements erfüllt werden.
– Flexible Adaptierbarkeit der Anlagenlösung an den individuellen Kundenwünsche und Randbedingungen (z. B. Einbinden bestehender Komponenten, Akzeptanz höherer Engineering-Aufwände um geringere Lifecycle-Kosten zu erreichen, ...)
– Schnellere und geführtere Abwicklung der manuellen Engineeringaufgaben. Rollen- und situationsspezifische Vorlage der anstehenden Aufgaben samt der bereits bekannten, dazu nötigen Informationen. Dabei ist sichergestellt, dass die verschiedenen Rollen konsequent ein gemeinsames Projektziel verfolgen, statt z. B. vieler herunter gebrochener Gewerkeziele.
– Wiederverwendbarkeit auch über die Grenzen spezifischer Anlagentypen und Gewerke.
– Keine Notwendigkeit zur manuellen Definition großer, künstlich geschaffener, schwer definierbarer und pflegbarer, ggf. inflexibler Engineeringeinheiten (wie z. B. mechatronischen Objekten).
– Tracebility (Nachvollziehbarkeit): Automatische Verlinkung der Requirements mit dem Lösungsartefakten
– Unterstützung in der Angebotsphase: Automatisierte Identifikation welche Requirements neu sind, also Unterschiede zu bisherigen Anlagenlösungen darstellen und daher Probleme bereiten könnten. → Konsequenzen sind transparenter Abwägen und Kalkulation erfolgt auf einer soliden Basis!
– Automatische Verfügbarkeit des akkumulierten Wissens aller bisher abgewickelten Anlagen (nicht nur der irgendwann als Standard definierten Objekte).
– Neue Win-Win-Situationen umsetzbar: Es sind Preisnachlässe möglich, wenn der Kunde die Requirements in der vorgegebenen maschinenlesbaren Form (Standard!) definiert auch findet eine engere Bindung zu Komponentenlieferanten satt, die Objekte bereit stellen, die konform zum vorliegenden Verfahren sind.
– Es ist vorteilhafter beide Schritte (Einführung mechatronischen Objekte und die wissensbasierte Anlagenabwicklung) gleichzeitig zu gehen als jeden Schritt einzelnen. Beispiel: Die ansonsten aufwändig zu definierenden mechatronischen Objekte würden dabei die Möglichkeiten des erfindungsgemäßen lernfähigen Ansatzes berücksichtigen und müssten daher nicht so komplex ausfallen und so hohen Ansprüchen genügen.
– Einbeziehbarkeit nicht funktionaler Anforderungen

7 zeigt eine beispielhafte Einrichtung ES (z. B. Engineeringsystem) zur Durchführung des erfindungsgemäßen Verfahrens. Das Verfahren wird durch Software (C, C++, Java etc.) realisiert und kann durch ein Computerprogramm-Produkt, welches auf einer programmgesteuerten Einrichtung C die Durchführung des Verfahrens veranlasst zur Ausführung gebracht werden. Weiterhin kann die Software auf einem computerlesbaren Medium gespeichert sein (z. B. Floppy Disk, CD, Smart Media Card, USB-Stick), umfassend Anweisungen, welche, wenn sie auf einem geeignetem Computer C ausgeführt werden, den Computer C dazu bringen, das Verfahren auszuführen. Die Einrichtung ES umfasst einen Bildschirm M zur grafischen Darstellung der Engineering- und Anlagenobjekte bzw. deren Verschaltung, Eingabemittel EA (z. B. Maus, Tastatur, Touch-Pen) zur Auswahl und Manipulation der Objekte, Speichermittel DB zur Archivierung erstellter Objekte bzw. Modelle sowie eine Verarbeitungseinheit C. Die Verarbeitungseinheit C kann ein marktüblicher Computer sein (z. B. Laptop, PC) aber auch einem vernetzten Client-Server Rechnersystem mit mehreren Benutzerzugängen (z. B. mehrere zentrale Server und auch mehrere Client-PCs) entsprechen. Das Verfahren ist prinzipiell auch durch verteilte Rechnerarchitekturen (Cluster, Cloud-Computing) oder webbasiert realisierbar.
Verfahren und Engineeringsystem zur Konstruktion industrieller Anlagen auf der Basis anlagenunabhängiger, regelbasierter, konfigurierbarer, inkrementeller Workflow-Objekte, wobei aus den Workflow-Objekten mittels funktionaler Dekompensation ein Baum von Workflow-Objekten generiert wird, der den zur Erzeugung der Engineeringdokumente der zu konstruierenden Zielanlage abzuarbeitenden Workflow repräsentiert, und wobei aus den identifizierten Anlagenobjekten ein Anlagenlayout generiert wird, und durch eine Workflow-Engine mittels Interpretation der Daten, Objekte und Regeln der im Baum vorhandenen Workflow-Objekte diese abgearbeitet werden, und dabei zielanlagenspezifische Engineeringdaten erzeugt werden und mittels Dokumentgeneratoren die für die zu konstruierende Anlage erforderliche Engineeringdokumentation in der jeweils erforderlichen Form generiert wird. Neben Anlagenobjekten und Engineeringobjekten wird vor allem das sukzessive angesammelte und standardisiert abgelegte Engineeringwissen wiederverwendet.
Bezugszeichenliste

RDok1–RDok3

Requirementdokumente

E-Data1–E-Data3

Engineeringdaten

A&EDok1–A&EDok3

Angebots-&Engineeringdokumente

ADok1–ADok3

Anlagendokumente

L-spez1–L-spez4

Lösungsspezifisch

L-unspez1–L-unspez4

Lösungsübergreifend

RWO, RWOx

Regelbasiertes Workflow Objekt

RWOs

Datenbank mit der Menge der verfügbaren, anlagenunspezifischen regelbasiertes Workflow Objekte

SRWOs

Baum von regelbasierten Workflow Objekten

R

Regel

SOANF1–SOANFn

Originäre Anforderung an eine spezifische Anlage

SOANFs

Menge der originären Anforderungen an eine spezifische Anlage

SAANF1–SAANFm

Abgeleitete spezifische Anforderung

SAANFs

Menge aller abgeleiteten spezifischen Anforderungen

SANFs

Menge aller beim Engineering der konkreten Anlage zu berücksichtigenden spezifischen Anforderungen

SDOANFs

Unformatierte Dokumente mit originären Anforderungen einer spezifischen Anlage

SEDs

Menge aller spezifischen Engineeringdokumente

OANANFs

Originäre anlagenunspezifische Anforderungen des Anlagenbauers

EOs

Datenbank mit den global verfügbaren, anlagenunspezifischen Engineering Objekten

AOs

Datenbank mit der Menge der verfügbaren, anlagenunspezifischen Anlagen Objekte

ES

Engineeringsystem

M

Monitor

C

Computersystem

DB

Datenbank

V

Verbindung

EM

Eingabemittel

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 6119125 [0004]

Claims

Verfahren zur Konstruktion industrieller Anlagen auf der Basis anlagenunabhängiger, regelbasierter, konfigurierbarer Workflow-Objekte (RWO, RWOx, RWOs), wobei ein Workflow-Objekt (RWO, RWOx, RWOs) umfasst: – eine standardisierte maschinenlesbare Beschreibung einer inkrementellen Engineeringaufgabe, – eine standardisierte maschinenlesbare Beschreibung von Daten (E-Data1–E-Data3) und Objekten (EOs), die bei der Ausführung der Engineeringaufgabe konsumiert und/oder erzeugt werden, – standardisierte maschinenlesbare Regeln (R), nach denen die Engineeringaufgabe auszuführen ist, wobei die Anforderungsspezifikation (RDok1–RDok3) der zu konstruierende Anlage auf Basis standardisierter maschinenlesbarer Anforderungen beschrieben ist, wobei aus einer Menge von Workflow-Objekten (RWO, RWOx, RWOs) und aus einer Menge von Anlagenobjekten (AOs), welche physikalische Anlagenkomponenten einer zu konstruierenden industriellen Anlage repräsentieren, die zur Generierung der durch die Anforderungsspezifikation (RDok1–RDok3) erforderlichen Engineeringaufgaben notwendigen Workflow-Objekte (RWO, RWOx, RWOs) und Anlagenobjekte identifiziert werden, und wobei aus den identifizierten Workflow-Objekten (RWO, RWOx, RWOs) mittels funktionaler Dekompensation ein Baum (SRWOs) von Workflow-Objekten (RWO, RWOx, RWOs) generiert wird, der den zur Erzeugung der Engineeringdokumente der zu konstruierenden Zielanlage abzuarbeitenden Workflow repräsentiert, und wobei aus den identifizierten Anlagenobjekten (AOs) ein Anlagenlayout generiert wird, und durch eine Workflow-Engine mittels Interpretation der Daten, Objekte und Regeln (R) der im Baum vorhandenen Workflow-Objekte (RWO, RWOx, RWOs) diese abgearbeitet werden, und wobei durch Dokumentgeneratoren die für die zu konstruierende Anlage erforderliche Engineeringdokumentation (A&EDok1–A&EDok3) in Form von resultierenden Engineeringdokumenten (SEDs) im jeweils erforderlichen Format generiert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass Anforderungen (RDok1–RDok3) in eine maschinenlesbare Form konvertiert werden, wenn diese noch nicht in einer maschinenlesbaren Form vorliegen.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Workflow-Objekte (RWO, RWOx, RWOs) in domänenspezifische bzw. disziplinspezifische und domänenunspezifische bzw. disziplinunspezifische klassifiziert werden.
Verfahren nach einem der vorstehenden Ansprüche, wobei unter der Menge aller projektspezifisch verwendeten Workflow-Objekte diejenigen Workflow-Objekte (RWO, RWOx, RWOs) identifiziert werden, die manuell erstellt, modifiziert oder abgearbeitet wurden, und wobei diese Workflow-Objekte mit den dazugehörigen Daten (E-Data1–E-Data3), Objekten (AOs, EOs) und Regeln (R) in die Menge der maschinenlesbaren Workflow-Objekte (RWO, RWOx, RWOs) überführt werden.
Verfahren nach Anspruch 4, wobei vor der Überführung der Daten (E-Data1–E-Data3), Objekte (AOs, EOs) und Regeln (R) in die Menge der maschinenlesbaren Workflow-Objekte (RWO, RWOx, RWOs) diese in domänenspezifische bzw. disziplinspezifische und domänenunspezifische bzw. disziplinunspezifische klassifiziert werden.
Verfahren nach Anspruch 4, wobei vor der Überführung der Daten, Objekten und Regeln in die Menge der maschinenlesbaren Workflow-Objekte (RWO, RWOx, RWOs) diese hinsichtlich einer allgemeinen Einsetzbarkeit analysiert werden.
Vorrichtung, insbesondere Engineeringsystem (ES), zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 6.
Computerprogramm-Produkt, welches auf einer programmgesteuerten Einrichtung die Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 6 veranlasst.
Computerlesbares Medium, umfassend Anweisungen, welche, wenn sie auf einem geeignetem Computersystem (C) ausgeführt werden, das Computersystem (C) dazu bringen, das Verfahren gemäß einem der Ansprüche 1 bis 6 auszuführen.