-
GEBIET DER ERFINDUNG
-
Die Erfindung betrifft das Gebiet der Prozessorchestration für industrielle Prozesse, die von modularen Industrieanlagen ausgeführt werden.
-
STAND DER TECHNIK
-
Die Konzepte rund um MTP und modulare Automatisierungssysteme beschreiben, wie verfahrenstechnische Anlagen modularer aufgebaut und gestaltet werden können, mit dem Ziel, das Engineering von verfahrenstechnischen Anlagen und das Life Cycle Management in Zukunft zu vereinfachen. Diese Vorteile werden durch vorgefertigte und erprobte Module, so genannte PEAs (Process Equipment Assembly), realisiert, die einfach in verschiedenen Kombinationen zusammengesetzt werden können, so dass unterschiedliche Rezepte realisiert werden können.
-
Modulare Anlagen setzen sich immer mehr durch und die Community ist sich einig über die vielfältigen Vorteile, nicht nur in Bezug auf die Entwicklungskosten, sondern auch in Bezug auf den zeitlichen und materiellen Aufwand. Als standardisierte Methodik schafft der MTP-Ansatz daher den Rahmen für die Interoperabilität zwischen Modulen und Orchestrierungssystem.
-
Einige Funktionen, die der Bediener, ein Datenanalyst, ein Anlagenbetreiber oder jemand anderes benötigt, sind heute weniger gut in das Kernautomatisierungssystem integriert. Selbst wenn diese Funktionen integriert sind, sind die Technologie oder die Betriebsphilosophie unterschiedlich - es sind andere Werkzeuge erforderlich, es werden andere Schnittstellen verwendet und so weiter. Die Verbindung dieser Funktionen ist proprietär und folgt in der Regel keinem Standard. Darüber hinaus unterstützen viele aktuelle Module kein OPC AC oder Module, die mit PackML automatisiert werden, unterstützen keine HMI. Für eine gute Integration müssten diese Aspekte irgendwie zu diesen Modulen hinzugefügt werden.
-
Die
WO 2020/030 652 A1 offenbart ein Verfahren, mit dem ein Simulationsmodell für ein Prozessmodul erstellt und mit dem MTP für dieses Prozessmodul verlinkt oder anderweitig in dieses MTP integriert werden kann.
-
AUFGABE UND LÖSUNG
-
Es ist die Aufgabe der vorliegenden Erfindung, die für die Prozessorchestrierung zur Verfügung stehende Prozesslogik zu erweitern und dabei Eingriffe in die bereits bestehende Prozessorchestrierung zu minimieren.
-
Diese Aufgabe wird erfindungsgemäß gelöst durch ein computerimplementiertes Prozessmodul gemäß Hauptanspruch. Weitere vorteilhafte Ausgestaltungen ergeben sich aus den darauf rückbezogenen Unteransprüchen.
-
OFFENBARUNG DER ERFINDUNG
-
Die Erfindung stellt ein computerimplementiertes Prozessmodul für eine modulare Industrieanlage bereit. Diese modulare Industrieanlage kann beliebige Wirk-Prozessmodule beinhalten, die in Kombination bei der Ausführung eines industriellen Prozesses auf der modularen Industrieanlage zusammenwirken. Beispiele für modulare Industrieanlagen sind Produktionsanlagen, die in nur wenigen Wochen einen Jahresbedarf für ein hoch konzentriertes und zugleich nur zeitlich begrenzt lagerfähiges Produkt, wie etwa Medikamente oder Impfstoffe, herstellen können. Statt nach der Fertigung einer entsprechenden Charge die Anlage im Ganzen brachliegen zu lassen, kann sie wieder zerlegt werden, so dass die Module anschließend in neuer Zusammenstellung an einem neuen Produktionsprozess mitwirken können.
-
Das computerimplementierte Prozessmodul umfasst eine Prozesslogik zur Bereitstellung mindestens einer computerimplementierten Funktion in der modularen Industrieanlage. Weiterhin ist eine mit einer Prozessorchestrierungsschicht (POL, Process Orchestration Layer) der Industrieanlage verbindbare Schnittstelle vorgesehen. Diese Schnittstelle stellt eine bidirektionale Kommunikation zwischen der POL und der Prozesslogik bereit.
-
Weiterhin umfasst das computerimplementierte Prozessmodul ein von der POL interpretierbares Modulbeschreibungspaket, MTP. Dieses MTP enthält mindestens die den Informationen, die die POL in die Lage versetzen, das computerimplementierte Prozessmodul über die Schnittstelle in gleicher Weise anzusprechen wie mindestens ein Wirk-Prozessmodul. Das Wirk-Prozessmodul ist dazu ausgebildet, physikalisch auf einen von der modularen Industrieanlage ausgeführten Prozess einzuwirken.
-
Es wurde erkannt, dass auf diese Weise die zusätzliche Funktionalität der computerimplementierten Prozesslogik mit geringstmöglichem Aufwand in die modulare Industrieanlage integriert werden kann. Indem das Prozessmodul als eigenständiges Modul auftritt und seine Funktionalität (etwa Dienste) über das MTP der POL anbietet, müssen weder die POL noch ihre Verschaltung mit den bereits existierenden Modulen geändert werden. Es kann also Funktionalität rein additiv der modularen Industrieanlage hinzugefügt werden, ohne dass irgendwelche bereits vorhandene Funktionalität beeinträchtigt wird. Dies ist besonders vorteilhaft in Bezug auf modulare Industrieanlagen, für deren Betrieb eine Zertifizierung oder Genehmigung erforderlich ist, wie beispielsweise Anlagen zur Herstellung von Medikamenten oder Impfstoffen. Die Hinzufügung der weiteren Funktionalität macht dann die Zertifizierung bzw. Genehmigung nicht ungültig.
-
In einer besonders vorteilhaften Ausgestaltung beinhaltet die computerimplementierte Funktion, unter Nutzung von durch das Wirk-Prozessmodul gelieferten Daten eine Zusatzfunktion für das Wirk-Prozessmodul bereitzustellen. Diese Zusatzfunktion kann also gleichsam „huckepack“ auf das bereits bestehende Wirk-Prozessmodul aufgesetzt werden, ohne dass seine bisherige Funktionalität beeinträchtigt wird.
-
Hiermit kann insbesondere beispielsweise Funktionalität nachgerüstet werden, die eine höhere Rechenkapazität erfordert als im Wirk-Prozessmodul selbst vorhanden ist. Unter den in einem Wirk-Prozessmodul geltenden erhöhten Anforderungen hinsichtlich Zuverlässigkeit und Betriebssicherheit ist jede Einheit Rechenkapazität vergleichsweise teuer. Daher werden Wirk-Prozessmodule nur mit so viel Rechenkapazität ausgestattet wie zur Erfüllung ihrer vorgesehenen Funktion notwendig ist. Für die Betriebssicherheit nicht zwingend notwendige, sondern lediglich wünschenswerte („nice to have“) Funktionen können jedoch auf preiswerterer Standardhardware laufen.
-
Beispiele für „huckepack“ nachrüstbare Zusatzfunktionen sind
- • eine Erzeugung, Verarbeitung und/oder Weitergabe von Alarmen, die einen abnormalen Betriebszustand des Wirk-Prozessmoduls anzeigen,
- • eine automatisierte Auswertung und Anzeige von Betriebszuständen des Wirk-Prozessmoduls, sowie
- • eine die Wartung und/oder Optimierung des Wirk-Prozessmoduls ermöglichende oder unterstützende Funktion.
-
Die automatisierte Auswertung kann beispielsweise die Analyse von durch das Wirk-Prozessmodul gelieferten Daten mit mindestens einem Machine Learning-Modell umfassen.
-
Die Gerätebeschreibungen (MTP) können auch zur Beschreibung anderer Dienste eines Geräts verwendet werden, wie z. B. andere Aspekte der Alarmierung, Wartung oder Optimierung. Darüber hinaus könnten sie zur Beschreibung vollständig softwarebasierter Systeme verwendet werden, die nicht mit einer Hardware verbunden sind.
-
Das softwarebasierte System kann überall ausgeführt werden (SPS, Controller, Edge, Cloud, lokaler PC, Server), hat keine direkte Verbindung zu einem realen Modul, liefert aber Funktionen, die für die Anlage relevant sind. Die Software kann durch ihre Visualisierung sowie die von der MTP bereitgestellten Dienste beschrieben und somit in das POL importiert werden, genau wie reale Module.
-
Dienste werden durch virtuelle Dienste beschrieben. Diese Dienste können beliebiger Art sein, z. B. eine komplexe Berechnung durchführen, eine E-Mail versenden oder einen Datenbericht erstellen, usw. Wenn diese Dienste mit demselben Zustandsautomaten arbeiten wie die Prozessdienste der Einheit, können beide innerhalb des POL auf dieselbe Weise behandelt werden.
-
Das softwarebasierte System könnte den gesamten Code enthalten, der für die Ausführung seiner Funktion erforderlich ist. Es könnte auch Dienste für die Parametrisierung anderer Dienste enthalten, wie z. B. das Schreiben der E-Mail und das anschließende Versenden über einen anderen Dienst, wobei der Text der E-Mail der Parameterwert wäre. Zusätzliche Dienste könnten verwendet werden, um OPC-UA-Server miteinander zu verbinden. Das softwarebasierte System könnte für einen einfachen Weg zum sicheren Zertifikatsaustausch von OPC UA Servern genutzt werden.
-
Kurz gesagt, wir könnten eine Erweiterung des MTP-Standards für reine Software-Funktionsmodule zulassen, und zwar durch (einfaches) „Einwickeln“ eines Softwaremoduls (E/A, Schlüsselfunktionalität, Visualisierung, Dienste usw.) in das MTP-Format, so dass es von außen wie ein MTP nutzbar und zugänglich ist und von innen Vorgaben/Dummies oder genau die Funktionalitäten eines MTP (Dienste, HMI, Alarme, Kommunikation usw.) bietet.
-
Auf diese Weise konnte ein zusätzlicher Werkzeugkasten aufgebaut werden, der die Möglichkeiten des Automatisierungssystems erweitert, aber dennoch mit diesem kompatibel ist.
-
Einige Anwendungsfälle:
- • Hinzufügen fehlender Funktionen (z.B. Alarme, HMI...) in einem MTP-basierten Standardmodul. In diesem Fall wäre das Soft-Only-MTP von einer PEA abhängig und würde die Prozesswerte nutzen, die von dieser PEA kommen und im MTP der PEA beschrieben werden;
- • Implementierung eines komplexen Dienstes aus einem oder mehreren Modulen, der nicht von einem einzelnen Modul erbracht wird (oder werden kann);
- • Ermöglichen zusätzlicher Berechnungen, z. B. Korrelation oder Umrechnung mehrerer Eingaben aus früheren Modulen und darauf basierende Kombinationen;
- • Unterstützung von Verbindungsmodulen, die die Ausgänge eines Moduls prüfen und (korrigierte) Informationen, die auf bestimmte Kriterien hin geprüft wurden, an das nächste Modul weiterleiten, z. B. im einfachen Fall den Bereich eines Ausgangs auf die Grenzen des Eingangs des nächsten Moduls beschränken oder eine Anomalieerkennung durchführen.
-
Bei der vorliegenden Erfindung geht es darum, das MTP (Modultyp-Paket, Beschreibung einer Einheit) zur Beschreibung zusätzlicher Dienste oder Funktionen wie Alarmierung oder eine HMI eines Moduls in einem zusätzlichen, softwarebasierten Modul zu verwenden. Darüber hinaus könnte es zur Beschreibung vollständig softwarebasierter Einheiten verwendet werden, die nicht direkt mit Hardware verbunden sind und z. B. für die Erkennung von Anomalien oder die Optimierung verwendet werden könnten.
-
Diese softwarebasierten Funktionalitäten können auf verschiedenen Plattformen implementiert werden:
- • Auf einem Server: z. B. E-Mail-/Textdienst, der einen Betreiber/Wartungspersonal informiert;
- • In der POL: Aktuelles Problem/Feedback von ORCA: Problem bei der Verwendung eines PID-Reglers mit Modul-zu-Modul-Kommunikation, da PID-Regler nicht informiert wird, wenn PEA stoppt/offline geht (Wind-up-Probleme), im Falle von Soft-MTP kann der PID-Regler auf die gleiche Weise wie die andere PEA gesteuert werden (sollte gut mit Modul-Interlocks zusammenarbeiten;
- • Auf einer Edge: einige einfachere Berechnungen für dieses oder ein anderes System durchführen;
- • In der Cloud: Durchführung umfangreicher Optimierungsaufgaben, die nicht zeitkritisch sind, aber sofort wieder in die modulare Anlage eingespeist werden.
-
Neu ist die Beschreibung von softwarebasierten Systemen mit Hilfe der MTP. Eine weitere, damit verbundene Neuerung ist die Erweiterung einer PEA um Funktionalitäten, die in einem zusätzlichen MTP beschrieben werden.
-
Derzeit werden nur hardwarebasierte Systeme (die eigene Hardware wie Rohre, Ventile und Messumformer sowie ein Rechengerät enthalten) durch MTPs beschrieben. Dies führt dazu, dass sowohl hardware- als auch softwarebasierte Systeme durch ein MTP beschrieben werden können. Somit können für beide Systeme die gleichen Engineering- und Kommunikationsmechanismen verwendet werden. Dies erleichtert die Integration mit verschiedenen Systemen und/oder Funktionen und die Wiederverwendung von Entwicklungswerkzeugen und Know-how. Eine softwarebasierte MTP könnte einerPEA (die durch ihre eigene MTP beschrieben wird) Funktionen/Aspekte hinzufügen, denen diese Funktionen fehlen, z. B. eine HMI (oder eine spezialisierte HMI), Alarme oder ein anderer Aspekt, der in Zukunft standardisiert wird, z. B. Simulation.
-
Das Konzept der softwarebasierten MTPs würde es ermöglichen, Funktionen hinzuzufügen, die in einem MTP-basierten Standardmodul nicht vorhanden, aber wünschenswert sind. So könnte z. B. ein Modul, das keine Alarmierung unterstützt, durch ein reines Software-MTP erweitert werden, das die Alarmierungsaufgabe übernimmt. (Anwendungsfall: Unterstützung von UPC UA AC ist noch nicht für alle Steuerungen verfügbar, könnte aber damit hinzugefügt werden). Ein anderes Beispiel wäre PackML: Ein Modul hat hier keine HMI, aber eine HMI könnte von einem anderen softwarebasierten MTP hinzugefügt werden, das die Werte des realen Moduls liest und dem Bediener präsentiert. Ein anderes Beispiel wäre die Implementierung eines komplexen Dienstes von einem oder mehreren Modulen, der nicht von einem einzelnen Modul bereitgestellt wird (oder werden kann). Dies könnte das Engineering einfacher und schneller machen. Diese Idee unterstützt auch eine nur auf Software basierende Berechnung von z.B. Korrelationen oder Konvertierungen von mehreren Eingaben aus vorherigen Modulen und darauf basierenden Kombinationen. Ein weiterer Anwendungsfall wäre die Erkennung von Anomalien. Ein weiterer Anwendungsfall wäre ein Prüfmodul, das die Ausgaben eines Moduls prüft und nur auf bestimmte Kriterien geprüfte Informationen an das nächste Modul weiterleitet, z.B. im einfachen Fall den Bereich einer Ausgabe auf die Grenzen der Eingabe des nächsten Moduls beschränkt.
-
Ein computerimplementiertes Prozessmodul kann also zu einem realen PEA korrespondieren, aber die Dienste dieses PEA virtuell bereitstellen und optional noch erweitern:
- • Die softwarebasierte PEA kommuniziert auf dieselbe Weise wie die reale PEA kommuniziert. Sie hat die gleichen Schnittstellen und wird daher durch die gleiche MTP beschrieben. Es handelt sich um eine ausführbare Software, die einen eigenen OPC UA-Server für die Kommunikation implementiert oder in ein speziell für diese Software-PEAs geschaffenes Framework eingesteckt werden kann, so dass das Framework (einen Teil) der Kommunikationsaufgaben übernimmt. Darin ist die Logik einschließlich der Simulationslogik der PEA enthalten. Zusätzlich zu den normalen Schnittstellen, die in der MTP spezifiziert sind, könnte sie eine Schnittstelle benötigen, um die Simulation zu manipulieren, z. B. einen bestimmten Druck- oder Temperaturwert bereitzustellen oder eine Leckage oder einen Gerätebruch zu simulieren.
- • Anstatt die PEA abzubilden, könnte das softwarebasierte Modul stattdessen die Funktionalität der realen PEA erweitern.
-
Das computerimplementierte Prozessmodul kann aber auch ein Modul sein, dass keine Hardware enthält und nur Softwarefunktionen bereitstellt. Diese Funktionen können auf unterschiedliche Weise bereitgestellt werden:
- • Die Software-Funktionen sind Dienste dieser PEA und können in gleicher Weise wie Dienste normaler PEAs ausgeführt werden. Damit stellt die Software-PEA einen OPC-UA-Server nach dem aktuellen Standard der VDI/VDE/Namur 2658 zur Verfügung. Da keine Hardware simuliert werden muss, wäre auch keine Simulationslogik notwendig.
- • Die Softwarefunktionen werden in einem anderen Format realisiert. Dies kann entweder ausführbarer Code sein, der auf eine andere Weise als die normale PEA gesteuert wird. Z. B. eine Software-API wie eine DLL, die OPC UA nicht unterstützt. Anstelle von ausführbaren Funktionen können die Funktionen auch in einem Format vorliegen, das erst kompiliert oder interpretiert werden muss, bevor es ausgeführt werden kann.
-
Die Vorteile dieser Innovation sind: Alle Teile einer Anlage könnten als Einheiten beschrieben werden. Dies würde auch reine Software-Module einschließen. Funktionen, die in ein klassisches Automatisierungssystem nur schwer zu integrieren sind, wie z.B. umfangreiche Berechnungen oder das Versenden von Meldungen, sind nicht gut integriert und auf standardisierte Weise zugänglich. Ein weiterer Vorteil ist, dass die Module und sogar die gesamte Kette - also das Zusammenspiel der verschiedenen Module - so simuliert werden können.
-
In einer besonders vorteilhaften Ausgestaltung beinhaltet die computerimplementierte Funktion das Bereitstellen einer Kommunikationsverbindung zu mindestens einem OPC UA-Server. Die Prozesslogik des computerimplementierten Prozessmoduls kann in diesem Zusammenhang insbesondere beispielsweise das Aushandeln einer verschlüsselten Verbindung übernehmen, etwa durch Schlüsselaustausch auf der Basis von Zertifikaten und/oder Aufbau eines VPN-Tunnels. Die entsprechenden Zugangsdaten könnten dann in der Prozesslogik sicher verwahrt werden.
-
In einer weiteren besonders vorteilhaften Ausgestaltung umfasst die Schnittstelle, und/oder die Prozesslogik, einen von der POL ansprechbaren OPC UA Endpunkt. Das computerimplementierte Prozessmodul kann dann in der gleichen Weise angesprochen werden wie viele Wirk-Prozessmodule.
-
In einer weiteren vorteilhaften Ausgestaltung ist die Schnittstelle des computerimplementierten Prozessmoduls dazu ausgebildet, die Kommunikation zwischen dem POL und der Prozesslogik über ein Gateway zu führen, das dazu ausgebildet ist, zwischen OPC UA und einem von der Prozesslogik verwendeten Kommunikationsstandard zu vermitteln. Es kann dann insbesondere beispielsweise ein einziges Gateway die Kommunikation zu mehreren Prozesslogiken vermitteln. Die OPC UA-Funktionalität muss dann nicht in jeder Prozesslogik gesondert implementiert sein. Dies kann beispielsweise vorteilhaft sein, wenn die Prozesslogik nicht auf leistungsstarker Standard-Hardware läuft, sondern auf einem Embedded-System mit eng begrenzten Hardwareressourcen.
-
Die „normalen“ Module kommunizieren derzeit über eine standardisierte OPC-UA-Schnittstelle mit den PEAs. Diese kann auch in den reinen Software-Modulen implementiert werden. Hier benötigt jedes Modul einen eigenen OPC UA Endpunkt, damit es angesprochen werden kann. Das POL kennt keinen Unterschied zwischen einer PEA und diesem SW-Basismodul. Darüber hinaus können die softwarebasierten Module (SBM) auch in einer Sandbox innerhalb des POL laufen, so dass keine Cloud-Verbindung (oder Server oder Edge.. ) erforderlich ist.
-
Eine Alternative wäre die Verwendung eines Gateways für die Kommunikation mit dem POL. Hier merkt das POL immer noch keinen Unterschied zwischen den beiden Arten von Modulen (HW/SW- basiert). Das Gateway könnte sich entweder in der Cloud befinden und somit direkt mit den Modulen verbunden sein oder sich in der Nähe des POL befinden (innerhalb der POL-Grenzen oder sogar auf derselben Maschine, eine eigenständige Maschine/eine andere Cloud würde ebenfalls funktionieren). Auf diese Weise könnten mehrere Clouds verwendet werden, wobei jede ein eigenes Gateway hat. Da die Module, die sich dort befinden, denselben Namensraum nutzen, sollte darauf geachtet werden, dass die Module nicht denselben Namen verwenden. In diesem Fall müssen unterschiedliche Gateways verwendet werden, die identifiziert werden können. Das Gateway implementiert den OPC UA Server, so dass das POL wie gewohnt mit dem Modul kommunizieren kann. Gegenüber den Modulen könnte das Gateway eine API mit einer definierten Schnittstelle verwenden oder möglicherweise REST-Aufrufe oder Web-Sockets. Auch einige gemeinsam genutzte Ressourcen wären möglich. Auch hier können die Module innerhalb einer Sandbox im POL liegen, das dann über zusätzliche Funktionen zur Kommunikation mit den Modulen verfügt.
-
In einer weiteren vorteilhaften Ausgestaltung ist die Prozesslogik des computerimplementierten Prozessmoduls als auf einer Cloud-Plattform ausführbarer Container implementiert. Hierfür können beispielsweise Docker- oder Kubernetes-Container verwendet werden. Die Prozesslogik kann dann bei einer höheren quantitativen Beanspruchung des computerimplementierten Prozessmoduls besonders einfach skaliert werden.
-
Eine dritte Alternative wäre die Verwendung einer speziellen Kommunikationsschnittstelle innerhalb des POL. Dabei würde die Kommunikation nicht über OPC UA erfolgen, sondern über andere Mittel. Dazu könnte die MTP-Datei so erweitert werden, dass sie diese Kommunikationsinformationen speichern kann diese Kommunikationsinformationen speichern kann (derzeit ist nur OPC UA möglich). Es entspricht dem Standard, SystemUnitClasses abzuleiten, um eine andere Art der Kommunikation zu definieren. Bei der Erstellung der Anlage wird das POL so projektiert, dass diese Art der Kommunikation zusätzlich angelegt wird. Das POL ist dann in der Lage, diese Definitionen zu nutzen, um im Betrieb tatsächlich mit den Modulen zu kommunizieren.
-
Falls der Code noch nicht ausführbar ist, muss das POL erweitert werden oder benötigt Zugang zu einer Funktion, die den Code innerhalb des Moduls kompilieren oder interpretieren kann.
-
In einer weiteren vorteilhaften Ausgestaltung implementiert die Prozesslogik des computerimplementierten Prozessmoduls mindestens einen internen Status, der von einem oder mehreren durch das MTP gegenüber der POL angebotenen Diensten beeinflussbar ist. Auf diese Weise können insbesondere beispielsweise Wechselwirkungen zwischen diesen Diensten oder auch Änderungen, die durch mehrfache Ausführung eines einzigen Dienstes aufkumuliert werden, verwaltet werden.
-
Bei der Verwendung eines hardwarebasierten Moduls (normale PEA) wird das Modul durch die Hardware, aus der es zusammengesetzt ist, und einen Controller mit den implementierten Diensten definiert. Wenn nun ein softwarebasiertes Modul verwendet wird, ist das Modul als Rahmen nicht in allen Fällen sinnvoll.
-
Die Gruppierung von Diensten zu einem Modul ist meist sinnvoll (und sogar erforderlich), für den Fall, dass das Modul einige Zustände hat, die von den verschiedenen Diensten beeinflusst werden. Zum Beispiel könnte ein Dienst Daten sammeln, andere Dienste diese Daten manipulieren und wieder andere Dienste sind vielleicht in der Lage, verschiedene Visualisierungsmethoden anzuwenden oder die Daten an einen anderen Ort zu schreiben. Hier ist es wichtig, die Dienste in einem Modul zu haben. Das Modul hat also einen internen Zustand, der von verschiedenen Diensten beeinflusst werden kann. Dies ist vergleichbar mit einem hardwarebasierten Modul, das ebenfalls einen internen Zustand haben kann, der zwischen der Ausführung verschiedener Dienste beibehalten wird (z. B. Ventil ist offen oder geschlossen oder Flüssigkeit hat eine bestimmte Temperatur). Neben der Beeinflussung von Diensten über ein internes Zustandsmodell können sich die Dienste auch gegenseitig aufrufen, z. B. ruft ein komplexer Dienst einen oder mehrere einfachere Dienste auf und führt sie in einer bestimmten Reihenfolge aus. Ein anderes Beispiel wäre, dass ein spezieller Dienst existiert, der einen anderen Dienst mit bestimmten Parametern aufruft (wie Standardparameter oder Parameter, die für einen bestimmten Anwendungsfall gelten).
-
Wenn Dienste nicht mit anderen Diensten verbunden sind, beeinflussen sie sich nicht gegenseitig. Auch hier muss geprüft werden, ob der Dienst einen internen Zustand des Moduls beeinflusst (z. B. einen Zähler, zu dem ein Dienst beiträgt). Hier ist es wichtig, den internen Zustand im Auge zu behalten und daher eine Art von Speicher für diesen Zustand bereitzustellen. Hier können Module mit nur einem Dienst nützlich sein.
-
Man kann sich auch Dienste vorstellen, die nicht mit internem Speicher arbeiten und daher zustandslos sind (z.B. verschiedene Dienste zur Weiterleitung von Daten, z.B. zum Senden einer eMail, einer Textnachricht oder über eine REST-fül API oder Dienste zur Durchführung von Berechnungen, bei denen alle erforderlichen Eingaben an den Dienst übergeben werden). Hier könnte ein anderes Konzept als die Verwendung von Modulen zur Gruppierung der Dienste sinnvoll sein. Natürlich können die Dienste immer noch in Form eines Moduls gruppiert werden, um dem Benutzer eine Art Bibliothek zur Verfügung zu stellen (z. B. ein Modul zur Weiterleitung von Daten und ein weiteres Modul zur Durchführung verschiedener Berechnungen). Für die Dienste macht es keinen Unterschied, ob sie in einem Modul gruppiert sind oder nicht. Ein Vorteil der Gruppierung könnte darin bestehen, dass die Dienste dann in der Lage wären, sich gegenseitig aufzurufen, z. B. könnte ein komplexer Dienst verschiedene einfachere Dienste oder benutzerdefinierte Werte aufrufen. Dies ist jedoch nur möglich, wenn die anderen Dienste dem einen Dienst zur Verfügung stehen, d. h. sie müssen sich im selben Modul befinden. Es kann auch nur ein Dienst pro Modul sein, ohne dass sich die Logik unterscheidet. Hier kann das Modul als eine Art Bibliothek fungieren, um die Dienste in benutzerdefinierte Kategorien/Anforderungen zu gruppieren. Eine Alternative wäre eine Gruppierung, die unabhängig vom Modul ist, z. B. eine Bibliothek. Der Name der Bibliothek könnte als zusätzliche Eigenschaft in das MTP aufgenommen werden oder der Benutzer kann die MTPs oder Dienste beim Hinzufügen von Diensten manuell in eine Bibliotheksstruktur einordnen.
-
In einer weiteren vorteilhaften Ausgestaltung ist die Prozesslogik des computerimplementierten Prozessmoduls mindestens teilweise innerhalb des MTP implementiert, und/oder sie ist im Programmcode des MTP referenziert. Auf diese Weise kann insbesondere eine wenig umfangreiche Prozesslogik mit besonders geringem Aufwand zur Ausführung gebracht werden.
-
Der Hauptunterschied zwischen einem hardwarebasierten MTP, das mit jeder PEA geliefert wird, und einem softwarebasierten MTP besteht darin, dass die Software des hardwarebasierten MTP im Controller der PEA liegt. Hier ist sie gekapselt und somit für den Benutzer nicht sichtbar. Das MTP braucht sich darum nicht zu kümmern, da es nur die Schnittstelle zur PEA beschreibt, nicht aber die innere Logik. Zur Identifikation der richtigen MTP könnte eine PEA in Zukunft auf ihre korrekte MTP nach VDI 2658 Blatt 1 verweisen.
-
Da das MTP auf dem Format AutomationML basiert, kann man zusätzliche Teile hinzufügen, die in der VDI 2658 nicht standardisiert sind. Zum Beispiel könnte man PLCopen-Code zu einer MTP-Datei hinzufügen, in der die innere Logik dieses virtuellen Moduls definiert ist. Auch andere Codeformate wie C, C++, C#, Python sind denkbar, um in die MTP-Datei eingebettet zu werden. Neben dem Quellcode könnte auch Konfigurationslogik,.B. für Al (Artificial Intelligence), ML (Machine Learning) oder einen Docker-Container enthalten sein.
-
Es kann eine Engine entwickelt werden, die das softwarebasierte MTP liest und die hinzugefügte Logik kompiliert oder interpretiert (im Falle von Skriptsprachen). Dieser Kompilierungsschritt könnte für jedes MTP einmal durchgeführt werden und dann können die MTPs beliebig oft verwendet werden (beliebig oft instanziiert). Jede Instanz wird dann mit den gewünschten Parametern gefüttert, z.B. könnte ein Dienst zum Versenden von Daten per Email die Email-Adresse und die Daten als Parameter haben.
-
Der Vorteil dieses Ansatzes ist, dass die innere Logik dieses MTP für den Benutzer (und möglicherweise für andere Werkzeuge) transparent ist. Der Nachteil ist aber auch, dass die innere Logik (falls sie schwierig umzuprogrammieren ist) für den Benutzer sichtbar ist. Hier könnte man auch an ein Verschlüsselungsformat denken, das aber entweder direkt in das MTP eingebettet wird oder von dem MTP aus auf eine andere Datei verlinkt wird. Die Formation AutomationML erlaubt die Verknüpfung mit einer anderen Datei, so dass dies immer noch AutomationML-konform ist.
-
Die zusätzliche Logik kann stattdessen in einer separaten Datei enthalten sein. Diese Datei kann entweder von der MTP-Datei referenziert - was AutomationML-konform wäre und den Vorteil hätte, dass die Datei dem richtigen Modul/Service/Prozedur/Service-Status zugeordnet werden kann, zu dem sie gehört. Eine Alternative wäre z.B., die Datei entsprechend dem MTP-Dateinamen oder dem MTP-Namen (ggf. plus Version; beide sind im MTP enthalten) zu benennen.
-
Das Dateiformat könnte freier sein, da die Datei nicht in eine XML-Datei eingebettet werden muss. Hier könnte eine DLL oder ein Docker-Container oder ein anderes ausführbares Format gewählt werden, das die Logik als Bibliothek mit einer bestimmten Schnittstelle enthält. Auf diese Weise kann die Logik besser gekapselt werden, ohne dass die MTP-Datei „unordentlich“ aussieht (mit nicht lesbarem Material) oder riesig wird. Darüber hinaus könnten einige Zeichen für XML reserviert sein, so dass das Hinzufügen des Inhalts einer Binärdatei zu XML nicht möglich wäre. Und der binäre Inhalt müsste zur Ausführung ohnehin in eine andere Datei kopiert werden. Wir müssten dann wahrscheinlich auch dafür sorgen, dass unsere Entwicklungswerkzeuge nicht durch korrupte externe Softwaremodule angreifbar sind. Dies könnte einfacher zu handhaben sein, wenn wir einen eigenen Compiler/Interpreter (entwickelt) haben, wie oben für die Alternative „eingebetteter Logikcode“ vorgeschlagen (da wir einen verwendbaren Satz/Schema von Logikcode zulassen/einschränken könnten).
-
Unter Verwendung einer separaten Datei könnte man eine ausführbare Datei verwenden, die eine Kommunikationsschnittstelle enthält, die in der (aktuellen oder zukünftigen Version der) Norm VDI/VDE/NAMRU 2658 enthalten ist, z.B. über OPC UA. Hier wird auf die PEA über die OPC UA-Schnittstelle zugegriffen, so dass die Logik überhaupt nicht offengelegt werden muss. Daher können normale MTP-Dateien, POLs und Engineering-Workflows verwendet werden, wenn die nichtfunktionalen Anforderungen der Anwendung, wie z. B. die Verfügbarkeit, mit dieser Variante erfüllt werden können.
-
Das ideale Format, in dem die Logik gespeichert wird, hängt von mehreren Faktoren ab. Einer davon ist, ob die Logik in das XML eingebettet werden soll oder in einer separaten Datei enthalten ist. Ein weiteres Kriterium könnte die Leistung sein oder ob ein Compiler oder eine Skript-Engine verfügbar ist. Dieser Compiler muss nicht zwingend im Engineering-Tool der PEA selbst angesiedelt sein, sondern kann als zusätzlicher Dienst (hier sind nicht die Modul-Dienste gemeint) von einer anderen Software bereitgestellt werden. Skriptsprachen sind bekanntermaßen weniger performant. Ein weiteres Kriterium könnte sein, ob die Logik von anderen Anwendern, die das MTP weiterverwenden, editierbar sein sollte. Zusätzlich zu den aufgeführten Kriterien kann ein weiteres Kriterium die Portabilität sein. C# benötigt eine VM/CLR, um zu laufen, aber es läuft auf jeder CPU, die CLR unterstützt, während dlls und exes an eine CPU-Architektur und wahrscheinlich an die Betriebssystem-API, z. B. POSIX oder Windows, gebunden sind. Ein Docker-Container wäre auch eine gültige Datei, die die Logik enthält.
-
Das computerimplementierte Prozessmodul kann insbesondere beispielsweise in einem Computerprogramm verkörpert sein. Die Erfindung bezieht sich daher auch auf ein Computerprogramm mit maschinenlesbare Anweisungen, die, wenn sie auf einem der mehreren Computern, und/oder auf einer oder mehreren Compute-Instanzen, ausgeführt werden, den oder die Computer, und/oder die eine oder mehreren Computer-Instanzen, zu dem zuvor beschriebenen computerimplementierten Prozessmodul aufwerten. Als Compute-Instanzen können insbesondere beispielsweise Container, virtuelle Maschinen oder andere virtualisierte Ressourcen in einer Cloud verwendet werden.
-
Grundsätzlich ist der Engineering-Workflow für eine modulare Industrieanlage in zwei Teile unterteilt, das Modul-Typ-Engineering und das Anlagen-Engineering.
-
Innerhalb des Modultyp-Engineerings wird das gesamte Engineering für einen Modultyp durchgeführt, d.h.:
- • Instrumentierung, Elektrotechnik, Steuerungstechnik
- • Physikalische Anbindung der inneren Prozessausrüstung
- • E/A-Marshalling und Auswahl der Steuerungshardware und
- • Werksabnahmeprüfung.
-
Ein Modultyp ist nach seiner Erstellung bereit für den Einsatz in einer Anlage, da er über eine eigene Intelligenz und eine OPC UA Server-Schnittstelle verfügt, über die er gesteuert werden kann.
-
Die Schnittstelle eines jeden Modultyps wird als MTP nach IEC63280 ED1 ACD beschrieben. Das MTP wird später für den zweiten Schritt, das Anlagen-Engineering, verwendet, wo die MTPs der Modultypen importiert und Instanzen für die Modultypen erstellt werden.
-
Jeder Modultyp verwendet einen Dienst, um seine inneren Funktionen dem übergeordneten Kontrollsystem als Dienste zur Verfügung zu stellen. Es wird eine serviceorientierte Architektur verwendet. Hinter jedem Dienst wird ein definierter Zustandsautomat ausgeführt. Die Zustände werden ebenfalls offengelegt.
-
Für das Engineering eines Modultyps wird der im Folgenden dargestellte Engineering-Workflow verwendet. Zunächst wird die HMI des Modultyps definiert, was eher dem Engineering eines Rohrleitungs- und Instrumentierungsplans entspricht.
-
Von der HMI wird automatisch eine Tag-Liste abgeleitet. Die Tag-Liste enthält alle Tags, die innerhalb des Automatisierungssystems verwendet werden. In der Tag-Liste kann der Benutzer die Parameter der Tags ändern. Sowohl der Datenträgertyp als auch die Parameter sind konform mit IEC 63280 ED1 ACD.
-
Im dritten Schritt wird der Dienst für den Modultyp definiert. Dies beginnt mit dem Hinzufügen eines Dienstes und dem Hinzufügen der erforderlichen Dienstparameter, die auch dem übergeordneten Kontrollsystem mitgeteilt werden sollen. Service-Parameter können z.B. „Amount“ für einen Service „Fill“ sein, mit dem dem „Fill“-Service mitgeteilt wird, wie viel in das Modul gefüllt werden soll.
-
Nach der Definition des Dienstes wird der Zustand des zugrunde liegenden Zustandsautomaten mit Logik gefüllt. Die Logikdefinition ist noch nicht an ein Zielsystem gebunden, sondern wird später in Schritt 4 verwendet, um die zielsystemspezifischen Informationen zu erstellen.
-
In Schritt 4a wird die zielsystemspezifische Information erstellt und kann für die Automatisierung des Modultyps verwendet werden. Diese ist nun an das Zielsystem gebunden und das Zielsystem kann später bei der Anlagenplanung nicht mehr ausgetauscht werden.
-
In Schritt 4b wird ein zielsystemspezifisches MTP erstellt, das die Schnittstelle des Modultyps beschreibt.
-
Der Arbeitsablauf bei der Anlagenplanung ist im Folgenden dargestellt. Erfolgt ebenfalls einem vierstufigen Ansatz, wobei im ersten Schritt alle in der Anlage benötigten Modultypen einer Modulbibliothek hinzugefügt werden.
-
Nach dem Hinzufügen der Modultypen können diese verwendet werden, um eine Topologie der modularen Anlage zu erstellen, indem Modulinstanzen im Engineering-Tool angelegt und mittels Material- und Informationsfluss verbunden werden.
-
Im letzten Schritt können die Modulinstanzen dazu verwendet werden, um - basierend auf ihrer Leistung - Sequenzen zu definieren, die vom übergeordneten Leitsystem ausgeführt werden können. Das übergeordnete Leitsystem wird im letzten Schritt aus den Informationen des Engineering-Tools erstellt.
-
Beide Phasen des hier beschriebenen Arbeitsablaufs müssen für die Integration computerimplementierter Prozessmodule leicht angepasst werden. Während des Modultyp-Engineerings muss der Editor für die Modullogik möglicherweise aktualisiert werden, da die Logik komplexer sein und stärker variieren kann als bei traditionellen PEAs. Hier werden normale Programmiersprachen und/oder Skript-Sprachen erforderlich sein. Derzeit wird die Logik innerhalb jedes Zustands eines Dienstes einer PEA mit Hilfe eines erweiterten Ursache-Wirkungs-Diagramms entworfen. Eine Alternative könnte die Verwendung anderer Sprachen sein, wie sie in der IEC 61131-3 definiert sind, um die PEA-Logik zu implementieren. Dies könnte für das SW-Basismodul nicht ausreichend sein, da Funktionen wie der Zugriff auf eine Datenbank, das Senden einer Benachrichtigung/Textnachricht oder die Verwendung einer Bibliothek für eine Modell-prädiktive Steuerung / künstliche Intelligenz oder andere ausgefallene Dinge nicht enthalten sind. Je nach Dateiformat kann der Code außerhalb des Tools bearbeitet werden (da das Erstellen eines Editors ziemlich viel Arbeit ist) und einfach kopiert werden. Der Code könnte auch kompiliert werden, so dass der ausführbare Code mit dem resultierenden MTP verpackt wird.
-
Während des Anlagen-Engineerings müssen die Software-Module erstellt werden, z.B. in der Cloud. Eventuell muss weitere Infrastruktur eingerichtet oder konfiguriert werden, wie z.B. das OPC-UA-Gateway, falls es verwendet wird. Oder es muss ein OPC UA Server zusammen mit dem benutzerdefinierten Code kompiliert werden, um auf das Modul zugreifen zu können. Die softwarebasierten Module sind während dieses Orchestrierungs-Engineering-Schrittes wie alle anderen Module verwendbar. Sie stellen ebenfalls Dienste zur Verfügung und können auch Verfahrens- und Konfigurationsparameter wie andere PEAs bereitstellen. Auch während des Betriebs kann der Bediener die SW-basierten Module auf die gleiche Weise bedienen wie andere Module. Ein Unterschied könnte die Reaktionsfähigkeit sein. Falls sich die Module in der Cloud befinden, könnte die Kommunikation langsamer sein. Eine Lösung für zeitkritische Funktionen könnte darin bestehen, sie in einer lokalen Cloud/Server oder Edge zu platzieren.
-
SPEZIELLER BESCHREIBUNGSTEIL
-
Nachfolgend wird der Gegenstand der Erfindung anhand von Figuren erläutert, ohne dass der Gegenstand der Erfindung hierdurch beschränkt wird. Es ist gezeigt:
- 1: Direkte Anbindung computerimplementierter Prozessmodule 2, 2a, 2b an die POL 1a über OPC UA;
- 2: Anbindung eines computerimplementierten Prozessmoduls 2 an die POL 1a über ein Gateway 7;
- 3: Anbindung eines computerimplementierten Prozessmoduls 2 an die POL 1a mit einem von OPC UA verschiedenen Protokoll 1c.
-
1 zeigt ein Anwendungsbeispiel einer modularen Industrieanlage 1 mit einem ersten Wirk-Prozessmodul 6, 6a, einem zweiten Wirk-Prozessmodul 6, 6b, einem ersten computerimplementierten Prozessmodul 2, 2a sowie einem zweiten computerimplementierten Prozessmodul 2, 2b. Die Arbeit aller Prozessmodule 6a, 6b, 2a und 2b wird von einer Prozessorchestrierungsschicht, POL 1a, orchestriert.
-
Jedes der computerimplementierten Prozessmodule 2, 2a und 2, 2b umfasst eine Prozesslogik 3, eine Schnittstelle 4 zur Anbindung an die POL 1a sowie ein MTP 5. Indem die POL 1a das jeweilige MTP 5 verarbeitet, wird sie in die Lage versetzt, die jeweilige Schnittstelle 4 anzusprechen. Die Schnittstellen laufen innerhalb der POL 1a in einer Sandbox 1b.
-
Die Prozesslogiken 3 laufen in Containern 8a in einer Cloud 8. Sie kommunizieren jedoch in dem in 1 gezeigten Beispiel mit der POL 1a genauso über OPC UA wie die Wirk-Prozessmodule 6, 6a und 6, 6b.
-
2 zeigt eine Abwandlung des in 1 gezeigten Anwendungsbeispiels. Im Unterschied zu 1 werden die Prozesslogiken 3 nun über ein von OPC UA verschiedenes Protokoll 1c angesprochen. Die Vermittlung zwischen OPC UA und dem anderen Protokoll 1c übernimmt ein Gateway 7.
-
3 zeigt eine weitere Abwandlung des in 2 gezeigten Anwendungsbeispiels. Im Unterschied zu 2 spricht die jeweilige Schnittstelle 4 die jeweilige Prozesslogik 3 nun unmittelbar über das von OPC UA verschiedene Protokoll 1c an.
-
Bezugszeichenliste
-
- 1
- modulare Industrieanlage
- 1a
- Prozessorchestrierungsschicht, POL, in Anlage 1
- 1b
- Sandbox in POL 1a
- 1c
- von OPC UA verschiedenes Kommunikationsprotokoll
- 2, 2a, 2b
- computerimplementierte Prozessmodule
- 3
- Prozesslogik in Modul 2, 2a, 2b
- 4
- Schnittstelle des Moduls 2, 2a, 2b
- 5
- Modulbeschreibungspaket, MTP, des Moduls 2, 2a, 2b
- 6, 6a, 6b
- Wirk-Prozessmodule in Anlage 1
- 7
- Gateway für Umsetzung zwischen OPC UA und Protokoll 1c
- 8
- Cloud-Plattform
- 8a
- Container auf Cloud-Plattform 8
-
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
-
