DE102021125887A1 - Computerimplementiertes Regelsystem zur adaptiven, regelbasierten Entscheidungsunterstützung für modular aufgebaute, industrielle Fertigungsumgebungen - Google Patents

Abstract

Die Erfindung betrifft ein computerimplementiertes Regelsystem zur adaptiven, regelbasierten Entscheidungsunterstützung für modular aufgebaute, industrielle Fertigungsumgebungen sowie ein Verfahren, welches das erfindungsgemäße Regelsystem nutzt. Die Aufgabe ein System anzugeben, welches durch dynamisch veränderbare Parameter zur Beschreibung des Zustandes seiner Systemkomponenten, Fähigkeiten generiert, die es ermöglichen, autonom noch effektivere Fertigungsabläufe zu finden, wird dadurch gelöst, dass das Regelsystem einen zentralen OPC UA Server und n-OPC UA Clients sowie eine zentrale Datenbank als Bestandteil einer Verwaltungsschale i. S. d. RAMI 4.0 umfasst. Die Datenbank bildet aktuelle Regeln sowie eine Struktur einer aus Modulen und Assets umfassenden Fertigungsumgebung ab, wobei die Zustandsdaten aller Assets in die Regeln einfließen, wobei ein OPC UA Client die Zustandsdaten aller Assets eines Moduls der Fertigungsumgebung an die Verwaltungsschale propagiert und der OPC UA Server auf die Zustandsdaten aller Assets in der Verwaltungsschale zugreifen, diese ändern, überschreiben und hinzufügen kann und bei Zustandsänderungen oder zeitbasiert die betroffenen Regeln evaluiert und daraus ein Ergebnis ableitet, welches als Fähigkeiten in der Verwaltungsschale abgebildet wird und das Ergebnis über die OPC UA Clients zurück an die jeweiligen Module gewiesen wird.

Description

• Die Erfindung betrifft ein computerimplementiertes Regelsystem zur adaptiven, regelbasierten Entscheidungsunterstützung für modular aufgebaute, industrielle Fertigungsumgebungen sowie ein Verfahren, welches das erfindungsgemäße Regelsystem nutzt.
• Die produzierende Industrie befindet sich im Übergang zum digitalen Zeitalter. Die fortschreitende Entwicklung und immer höhere Leistungsfähigkeit von Netzwerktechnik („Internet-of-Things“) und gemeinsame Plattformen wie die Industrie 4.0 ermöglichen die Digitalisierung des gesamten Produktlebenszyklus über alle Organisationsstufen eines Unternehmens. Ziel ist die Steigerung der Produktivität durch optimale Ressourcennutzung und gleichzeitig die Entlastung von Mitarbeitern in Bezug auf körperlich schwere und eintönige Tätigkeiten. Mit dem Referenzarchitekturmodell, kurz RAMI 4.0 (1), und der Industrie 4.0-Komponente haben sich deutsche Verbände auf ein gemeinsames Konzept geeinigt, um die komplexen Aufgaben der vollständigen Digitalisierung Herstellerübergreifend zu standardisieren.
• Teil dieser Konzepte ist eine sogenannte Verwaltungsschale, welche die Produktion über digitale Abbilder der einzelnen Ausgangsstoffe, Werkzeuge und Produkte sowie digitale Informationssysteme, die unter dem Begriff „Assets“ zusammengefasst werden, aggregiert. Wichtige Voraussetzungen sind Messdaten von Sensoren, die den Zustand und das Geschehen an einer Fertigungsstraße in einer Fertigungsumgebung in Echtzeit digitalisieren, also zum Beispiel die Geschwindigkeit, Auslastung und Präzision einer bestimmten Maschine erfassen und in die höher gelegene Hierarchieebene melden. Die Informationen werden über eine eigens entwickelte Semantik der RAMI 4.0 kommuniziert, siehe 2.
• Nach dem Stand der Technik werden bisher die Abläufe einer Produktion vorprogrammiert und nur in einer Ebene über dem realen Gerät autonom gesteuert. So kann zum Beispiel ein Controller anfragen, welches Gerät Kapazität zum Bohren von Material A hat und schickt ein entsprechendes Werkstück dort hin. Hat keines der gefragten Geräte mit der Meldung „Verfügbarkeit ja‟ geantwortet, entsteht Leerlauf oder die Notwendigkeit von menschlichem Eingreifen, obwohl stattdessen vielleicht Kapazität zum Bohren von Material B zur Verfügung stehen würde.
• Neuere Entwicklungen in der Prozessindustrie beschäftigen sich mit modularen Anlagenkonzepten, wobei dabei jedes Anlagenmodul seine verfahrenstechnische und produktionstechnische Funktion als Dienst einer übergeordneten Prozessführungsebene (PFE) zur Verfügung stellt. In der DE 10 2016 201 075 A1 wird ein Modul mit einer Steuerung zur Durchführung eines technischen Teilprozesses einer technischen Anlage beschrieben, wobei die Steuerung eine Außenschnittstelle mit einer Verwaltungsschale aufweist. Die Verwaltungsschale veröffentlicht, welchen Dienst oder welche Dienste das jeweilige Modul bezüglich eines Ausgangsproduktes durchführen kann. Auf diese Weise sind die Module in der Lage, selbstständig über ihre Verwaltungsschale miteinander zu kommunizieren und sich gegenseitig Dienste anzubieten und anzufragen.
• In der EP 3 070 548 A2 wird ein Konzept einer Cloudbasierten Steuerung vorgeschlagen. Ein Cloud-basierter industrieller Controller steuert Geräte, Prozesse und andere Ressourcen eines industriellen Automatisierungssystems über Steueralgorithmen, die auf einer Cloud-Plattform ausgeführt werden. Eine Cloud-basierte Erfassungskomponente sammelt Informationen aus dem industriellen Automatisierungssystem über Cloud-Gateways, die dem industriellen Automatisierungssystem oder externen Datenquellen zugeordnet sind. Die Cloud-basierte industrielle Steuerung kann die Informationen überwachen und analysieren, Steueranweisungen basierend auf den Analyseergebnissen generieren und die Steueranweisungen an die Geräte, Prozesse und / oder andere Assets des industriellen Automatisierungssystems kommunizieren, um den Betrieb der industriellen Automatisierung zu steuern. Die Menge an Daten, die außerhalb der Anlage transferiert und verarbeitet werden müssen, ist sehr hoch, was bei Echtzeitauswertungen zu ungewünschten Verzögerungen führen kann. Auf ähnliche Art und Weise wird auch in der US 10 416 660 B2 die Nutzung von Edge Geräten vorgeschlagen, um autonome Steuerprozesse mit den Daten aus der Anlage in einer Cloud umzusetzen.
• In der WO 2016 165 923 A1 wird ein Verfahren und eine Vorrichtung zum Betreiben eines Automatisierungssystems beschrieben. Dafür wird ein lernbasiertes Vorhersagemodell bereitgestellt, welches durch Prozessdaten, die den Kontext des Automatisierungsprozesses umfassen, trainiert wird.
• Sobald eine Konzeptdrift, d. h. eine Abweichung zwischen dem aktuellen Kontext des Automatisierungsprozesses und den erhaltenen Prozessdaten stattfindet, erfolgt eine Umschulung des Modells. Damit erfolgt eine Art Neu-Parametrisierung des Automatisierungssystems, um den Prozess in seinen Soll-Wert zu halten.
• In der DE 10 2017 201 949 A1 wird eine Robotersteuerung zur Steuerung eines Betriebsmittels zur Herstellung und / oder Montage von Werkstücken beschrieben, wobei das Betriebsmittel mit einer elektrischen Auswerte- und Steuereinheit über eine Schnittstelle für den Austausch von Steuerdaten für den Betrieb des Betriebsmittels und / oder die Eingabe von Sensorsignalen verbunden ist. In der elektrischen Auswerte- und Steuereinheit ist ein Speicher integriert, in dem einzelne Programmabläufe für die Durchführung vorgegebener Arbeitsaufgaben gespeichert sind. Die Programmabläufe entsprechen einzelnen Arbeits- und / oder Montageabläufen, die für die Fertigung des Werkstückes notwendig sind. Aus den gespeicherten Programmabläufen wird jeweils ein passender ausgewählt, z. B. anhand verfügbarer Betriebsmittel.
• In der D 10 304 706 A1 werden für die Optimierung eines Programmablaufes historische Prozessdaten berücksichtigt. Ein Echtzeit-Informationsserver erfasst, archiviert und übermittelt bestimmte historische Prozessdaten der Anlage an einen Datenstrom-Controller zum flexiblen Wiedergeben archivierter Prozessdaten an wenigstens eine speicherprogrammierbare Steuerung (SPS). Dabei werden aufgezeichnete Prozesse nicht nur wiederholt abgerufen, sondern auch zur Optimierung von Fertigungsabläufen eingesetzt.
• Im bisher bekannten Stand der Technik sind keine Systeme bekannt, die in der Lage sind, ihren IST-Zustand fortlaufend selbstständig zu beschreiben, an weitere Systemkomponenten weiterzuleiten und daraus selbstständig zu lernen, Abläufe zu optimieren.
• Es ist daher eine Aufgabe der vorliegenden Erfindung ein computerimplementiertes System anzugeben, welches in der Lage ist, durch dynamisch veränderbare Parameter zur Beschreibung des Zustandes seiner Systemkomponenten, Fähigkeiten zu generieren, die an die nächst höhere Kontrollebene weitergegeben werden können. Mittels derartiger Fähigkeiten, die als Zusammenfassung verschiedener Prozessschritte, deren Voraussetzungen, Parameter, Ergebnisse und Rahmenbedingungen verstanden werden, soll es möglich werden, dass Systeme autonom noch effektivere Abläufe finden können.
• Diese Aufgabe wird durch ein computerimplementiertes Regelsystem gemäß dem unabhängigen Anspruch 1 gelöst.
• Das computerimplementierte Regelsystem umfasst einen zentralen OPC UA Server und n-OPC UA Clients mit n als natürliche Zahl größer 1 sowie eine zentrale Datenbank als Bestandteil einer Verwaltungsschale i. S. d. RAMI 4.0. Die Datenbank kann aus jeder beliebigen SQL oder NoSQL Datenbank implementiert werden und bildet aktuelle Regeln sowie eine Struktur einer aus Modulen aufgebauten, industriellen Fertigungsumgebung ab, wobei ein Modul aus wenigstens einem Asset gebildet ist und wobei die Regeln in der Datenbank Funktionen und Platzhalter umfassen, die Zustandsdaten aller Assets aus der Fertigungsumgebung repräsentieren, wobei ein OPC UA Client die Zustandsdaten aller Assets eines Moduls der Fertigungsumgebung an die Verwaltungsschale propagiert und der OPC UA Server auf die Zustandsdaten aller Assets in der Verwaltungsschale zugreifen, Einträge ändern, überschreiben und hinzufügen kann und bei Zustandsänderungen oder zeitbasiert die betroffenen Regeln evaluiert und daraus ein Ergebnis ableitet, welches als eine Fähigkeit oder kombinierte Fähigkeit in der Verwaltungsschale abgebildet wird und das Ergebnis über die OPC UA Clients an die jeweiligen Module zurückgewiesen wird. Die „Regeln repräsentieren die Zustandsdaten aller Assets“ ist derart zu verstehen, dass die Zustandsdaten aller Assets via konkreter Endpunkte in die Regeln einfließen können, ebenso wie Teilergebnisse aus anderen Regeln oder historischen Daten, welche zuvor durch eine Log-Funktionalität erhoben wurden, die später noch erläutert wird.
• Durch das erfindungsgemäße computerimplementierte Regelsystem können im Umfeld einer modular aufgebauten, industriellen Fertigung Maschinen-, Anlagen-, Linien- und Produktionsfähigkeiten beschrieben und abgebildet werden, wobei mit einer entsprechenden Konfiguration und Infrastruktur dies sogar standortübergreifend erfolgen kann.
• Voraussetzung ist die Nutzung eines geeigneten Frameworks, d. h. Regelsystems, das alle relevanten Fertigungs-, Prozess- und Zustandsdaten an einen zentralen Ort zusammenfasst - wie dies mit der oben definierten Verwaltungsschale möglich wird. Eine Neuerung des erfindungsgemäßen computerimplementierten Regelsystems ist die Konfiguration über eine Multiuser-Datenbank. Die Formulierung der Regeln obliegt dem Nutzer oder einem separaten, nicht zur Erfindung zugehörigem, computergestützten System, z. B. die Nutzung von künstlicher Intelligenz oder einem maschinellen Lernverfahren.
• Ein wichtiger Bestandteil der Verwaltungsschale ist die zentrale Datenbank, die beispielsweise mit MySQL oder mit jeder beliebigen SQL oder aber auch NoSQL Datenbank umgesetzt und implementiert werden kann, in der unter anderem die Struktur des Unternehmens wie die Fertigungslinien, -zellen und -geräte sowie die relevanten Komponenten abgebildet werden. Die relevanten Komponenten sind vom Anwendungsfall abhängig. Jede Information, die sich maschinenlesbar abbilden lässt, kann dabei einbezogen werden. Die Informationen reichen von Ressourcen, beispielsweise Mitarbeiter, Rohstoffe, Energie, Kapital, Liefertermine, usw. bis hin zu alle dem, was einen Fertigungsprozess beeinflussen oder eine Auswirkung auf ihn hat. Weitere wichtige Bestandteile sind der zentrale OPC UA Server, in welchem die Zustandsinformationen aus der Fertigung gebündelt werden (kurz Verwaltungsschale) sowie die n-Clients, die über eine Schnittstelle zum Datenaustausch verfügen, wobei beliebige Schnittstellen zum Datenaustausch verwendet werden können, z. B. OPC UA, MQTT, REST u. a. Die Clients abonnieren oder erfassen zyklisch die Zustandswerte der hinterlegten Endpunkte eines Gerätes, um die Zustandsänderungen auf die Verwaltungsschale zu spiegeln. Unter den Endpunkten eines Gerätes werden Variablen verstanden, die ein einzelnes Datum oder ein un- bzw. strukturiertes Set aus Daten repräsentieren. Eine Eingrenzung auf bestimmte Datentypen findet dabei nicht statt. Somit überwacht ein OPC UA-Client die Zustände von Komponenten innerhalb der Verwaltungsschale und evaluiert bei Zustandsänderungen die betroffenen Regeln. Das Ergebnis einer Regel kann beliebig vielen Endpunkten bzw. Assets eines Moduls der Fertigungsanlage, z. B. als Teilergebnis, als Fähigkeit oder kombinierte Fähigkeit zugewiesen werden.
• Bei Bedarf kann beim Eintreten eines bestimmten Zustandes auch das Auslösen beliebig vieler, im Datenbanksystem hinterlegter Aktionen ausgeführt werden.
• In einer Variante des erfindungsgemäßen computerimplementierten Regelsystems verfügt jedes Asset über eine Kommunikationsschnittstelle und kommuniziert seine Zustandsdaten an den OPC UA Client. Jedes einzelne Asset, bzw. jede Zelle verfügt über eine speicherprogrammierbare Steuerung (SPS) und weist eine geeignete Schnittstelle auf, über die Zustandsänderungen nach außen gegeben werden können. Eine Schnittstelle zum Datenaustausch können z. B. OPC UA, MQTT, REST u.a. sein. Die SPS stellt die Endpunkte bereit.
• In einer weiteren Variante des erfindungsgemäßen computerimplementierten Regelsystems sind die Regeln in der Datenbank, die durch einen Nutzer oder ein computergestütztes System konfigurierbar sind, dynamisch an eine Auswertestrategie anpassbar und steuerbar, wobei die Regeln in der Datenbank persistiert und dynamisch verwaltet werden. Das Regelsystem ermöglicht es die Auswertestrategie adaptiv und dynamisch zu gestalten, indem die Regeln in einer Datenbank persistiert und verwaltet werden. Es ist somit möglich jede vom Nutzer umsetzbare, computergestützte ausführbare Funktion aufrufen zu lassen, sofern ein zuvor definierter Zustand eingetreten ist. Dadurch lassen sich u. a. wiederkehrende Vorgänge automatisieren, bzw. Warnungen bei erkannten Anomalien generieren. Anomalien können in einem Produktionsablauf auftreten. Im einfachsten Fall kann das z. B. ein erhöhter Energiebedarf, eine gestiegene Ausschussquote oder längere Bearbeitungszeiten bei der Produktion sein. Diese Abweichungen vom erwarteten Verhalten können Hinweise auf einen vorzeitigen Verschleiß von Maschinenkomponenten oder Werkzeugen sein, auch bekannt und benannt als „predictive Maintenance“. Über das erfindungsgemäße Regelsystem können Regeln formuliert werden, welche z. B. die relative Abweichung ermitteln. Ein konkretes Fallbeispiel wäre: Der Energiebedarf der letzten 5 Zyklen wird mit den vergangenen 1000 Zyklen verglichen. Sofern eine relative Abweichung von mehr als 5% auftritt, werden Aktionen ausgeführt oder eine Warnung gesetzt, um dieser Abweichung entgegenwirken zu können.
• In einer anderen Variante des erfindungsgemäßen computerimplementierten Regelsystems werden die Regeln in der Datenbank zyklisch oder eventbasiert mit Ist-Daten einer laufenden Produktion in der Fertigungsumgebung sowie mit historischen, gelernten Abläufen abgeglichen, um die Regeln zu evaluieren und an zur Verfügung stehende Zustände der Assets anzupassen. Regeländerungen innerhalb der Datenbank werden zyklisch von einem Softwarebaustein abgerufen, der zugleich als OPC UA Client eine Verbindung zum OPC UA Server der Verwaltungsschale besitzt. Von diesem Softwarebaustein wird ebenfalls die Evaluierung der Regeln vorgenommen. Bei Zustandsänderungen innerhalb der Verwaltungsschale - welche die Datengrundlage bildet - wird überprüft, welche Regeln von dieser Änderung betroffen sind und erneut evaluiert werden müssen. Das Regelsystem gleicht die vom Nutzer in der Datenbank vorgegebenen Abläufe mit den Ist-Daten der laufenden Produktion sowie historischen, gelernten Abläufen ab und kann aus den sich gegenseitig bedingenden Zustandswerten die bestehende Regel evaluieren und anpassen. Es ist auch möglich neue Regeln aus den o. g. Daten/Werten abzuleiten. Das Besondere daran ist die Möglichkeit, ständig angepasste Regeln in der Datenbank zu hinterlegen und zu überschreiben. Daher werden nicht nur in der Planung erdachte Abläufe, sondern auch flexible Anpassungen an die jeweilige Situation ermöglicht. Eine Änderung einer Regel erfolgt durch Ersatz der in der Verwaltungsschale indizierten Parameter mit aktuellen Zustandswerten.
• In einer anderen vorteilhaften Variante des erfindungsgemäßen computerimplementierten Regelsystems erfolgen die Regeländerungen zur Laufzeit der Verwaltungsschale. D. h. in einem zweiten Schritt wird der Ausdruck der zuvor stattfindenden Parameteränderungsüberprüfung ausgewertet und das Ergebnis zur Evaluation der Regel verwendet. So wird eine ständige Anpassung von Abläufen während der Laufzeit ermöglicht (Entscheidungsunterstützung). Die Änderung wird durch das Ausführen eines SQL-Queries, unabhängig von der gewählten Schnittstelle, wirksam. Zur Veranschaulichung wurden in 2 die beiden relevanten Achsen der RAMI 4.0 Matrix aufgespannt, um den Datenfluss sinnbildlich darzustellen und einzuordnen. Die grundsätzliche Idee dahinter ist ein Aufbau von „unten nach oben“, also auf der Basis der tatsächlich aufgezeichneten Vorgänge, nicht durch (von außen vorgegebene) Modelle oder bereits programmierte Abläufe. So wird hier nicht nur eine Dienstleistung, sondern auch die zusätzlichen Rahmenbedingungen kommuniziert.
• In einer Variante des erfindungsgemäßen computerimplementierten Regelsystems ist also jeder OPC UA Client mit dem OPC UA Server verbunden.
• In einer anderen Variante des erfindungsgemäßen computerimplementierten Regelsystems wird jede in der Verwaltungsschale gehaltene Prozess- oder Fertigungsinformation durch einen Univerally Unique Identifer (UUID) beschrieben, wobei der UUID von beliebig vielen Regeln referenziert werden kann. Technisch umgesetzt wird dies durch eine Relation zwischen den Regeln und den Maschinen- bzw. Anlagenkomponenten, d.h. Modulen und Assets. Bei der Evaluation von Regeln werden in einem ersten Schritt die verwendeten UUID Platzhalter durch die aktuellen Zustandswerte aus der Verwaltungsschale ersetzt. In einem zweiten Schritt erfolgt dann die Auswertung des Ausdrucks. Als Platzhalter können alle von OPC UA unterstützten Datentypen verwendet werden. Das Ergebnis der Regel kann, in Abhängigkeit davon wie die Verknüpfung zwischen den Komponenten, bzw. Endpunkten oder Teilergebnissen umgesetzt wurde, als Aggregation von Informationen beziehungsweise als Fähigkeit angesehen werden. Diese Fähigkeiten wiederum lassen sich, in Abhängigkeit von der konfigurierten Hierarchie, einer Station, Linie, etc. zuordnen.
• In einer weiteren Variante des erfindungsgemäßen computerimplementierten Regelsystems stellen Fähigkeiten, die in anderen Regeln verwendet werden, kombinierte Fähigkeiten dar. Es ist auch möglich die Ergebnisse von Regeln, also die Fähigkeiten, in anderen Regeln zu verwenden, dann handelt es sich um sogenannte kombinierte Fähigkeiten. Mit der Verwaltungsschale als Grundlage kann das erfindungsgemäße Regelsystem als Steuerung über allen Steuerungen betrachtet werden. Durch die beliebige Verknüpfung von Fertigungsinformationen lassen sich individuell Maschinen- und Anlagenfähigkeiten beschreiben.
• In einer bevorzugten Variante des erfindungsgemäßen computerimplementierten Regelsystems werden Zustandsänderungen eines Moduls und deren Assets der Fertigungsumgebung geloggt (Log-Funktion).
• In einer anderen bevorzugten Variante des erfindungsgemäßen Regelsystems werden Zustandsänderungen an den Fähigkeiten und kombinierten Fähigkeiten, welche einem Asset auf dem OPC UA Server der Verwaltungsschale zugeordnet werden, geloggt. Sowohl die Zustandsänderungen der Assets eines Moduls der Fertigungsumgebung als Eingänge auf die Verwaltungsschale als auch die Ergebnisse der Regeln, also Fähigkeiten und / oder die kombinierten Fähigkeiten als Ausgänge bzw. Ergebnis der Regelauswertung des erfindungsgemäßen Regelsystems werden in der Verwaltungsschale gehalten und können geloggt werden. Damit können historische Daten in das Regelsystem mit einbezogen werden. Die statistischen Auswertungen über Produktionsdaten, wie Mittelwert, Median, Standardabweichung, Varianz, etc. werden genutzt, um historische Bedingungen in die Fähigkeitsbeschreibung einzubeziehen. Das Ziel ist die Möglichkeit, bestimmte (Ausschluss-)Kriterien definieren zu können, die sich aus dem aktuellen Produktionsablauf definieren. Zum Beispiel sollte die Nutzung weißer Farbe nicht direkt nach der Nutzung schwarzer Farbe im selben Sprühgerät erfolgen. Durch eine Messung der Helligkeit des letzten Produktes kann nach dem Einsatz einer helleren Farbe wieder der Einsatz weißer Farbe freigeschalten werden. Dazu wird die Datenbank um Funktionen und Funktionsparameter erweitert, wie es in einem Ausführungsbeispiel näher erläutert wird.
• In einer weiteren bevorzugten Variante des erfindungsgemäßen computerimplementierten Regelsystems, wird ein anderer weiterer Univerally Unique Identifer (UUID) als Platzhalter zum Abbilden auf eine Funktion genutzt, die eine Reihenfolge möglicher geloggter und / oder gegenwärtiger Zustandswerte oder statischer Werte sowie deren Typ vorgibt. Dabei werden auch im Regelsystem zu Anfang die obligatorischen Parameter, im Anschluss die optionalen Parameter als Bestandteile eines Funktionsaufrufs angegeben.
• Die Aufgabe wird ebenfalls durch ein erfindungsgemäßes Verfahren gemäß dem unabhängigen Verfahrensanspruchs 11 gelöst, wobei das Verfahren das erfindungsgemäße Regelsystem nutzt.
• Das erfindungsgemäße Verfahren weist folgende Schritte auf:
• - Überwachen von Assets der Fertigungsumgebung und ersetzen von Platzhaltern mit aktuellen Zustandswerten aus der Verwaltungsschale;
• - Registrieren einer Zustandsänderung an mindestens einem Asset der Fertigungsumgebung;
• - Evaluieren aller für das mindestens eine Asset relevanter Regeln durch Abgleichen der Zustandswerte mit Vorgaben und gegebenenfalls Anpassung einer Regel durch eine externe Software;
• - Speichern von Randbedingungen und Aggregieren der Zustandswerte der Assets der Fertigungsumgebung in einer Fähigkeit;
• - kontinuierliche Verbesserung der Fähigkeit und Sammeln neuer Fähigkeiten in einer Datenbank;
• - Abrufen der Zustandswerte aus der Verwaltungsschale zu einer Fähigkeit und Bereitstellen aktueller Kapazitäten in Form von Fähigkeiten an eine nächst höhere Hierarchieebene.
• Mit dem erfindungsgemäßen Verfahren, welches mittels des erfindungsgemäßen computerimplementierten Regelsystems ausgeführt wird, wird eine Möglichkeit zur Verfügung gestellt, eine Auswertestrategie einer komplexen Fertigungsumgebung dynamisch anzupassen. Mit dem erfindungsgemäßen Regelsystem ist es möglich Maschinenfähigkeiten der Fertigungsumgebung abzubilden, Aktionen auszuführen, wenn ein bestimmter Zustand eingetreten ist und historische Daten einzubeziehen. Die dynamischen Änderungen des Verhaltens der Fertigungsumgebung können genutzt werden, weil Regeln nicht statisch programmiert sind, sondern in einer Datenbank gehalten werden.
• Bei Bedarf können dem Verfahren auch folgende Schritte zwischengeschaltet werden: Es können ein oder mehrere Zustände und das Auslösen bestimmter, in der Datenbank hinterlegter, Aktionen bei Erreichen eines definierten Zustands überwacht werden. Des Weiteren kann eine kontinuierliche Ermittlung eines statistischen Wertes aus den Zustandswerten erfolgen, um ein definiertes Ausschlusskriterium zu überwachen, z. B. Fehlertoleranz, und danach Auslösen einer bestimmten Aktion, z. B. Fähigkeit X wird nicht mehr angeboten.
• Zusammenfassend weisen das erfindungsgemäße computerimplementierte Regelsystem und das Verfahren folgende Vorteile gegenüber bisher bekannten Produktionsüberwachungssystemen auf: Das Regelsystem erlaubt eine Übersicht über den aktuellen Zustand der Produktionsumgebung (durch Aggregation) und ermöglicht damit eine objektive Entscheidungsfindung, die ein effektiveres Arbeiten ermöglicht. Das erfindungsgemäße Regelsystem bietet die Grundlage für eine linien- und standortübergreifende Fertigungsplanung. Durch die Verwendung einer Verwaltungsschale, die jedes Asset einer Produktions- bzw. Fertigungsumgebung als Kommunikationsschnittstelle zu jedem anderen Asset derselben oder einer anderen Produktionsumgebung aufweist, besteht lediglich eine lose an die Produktionsumgebung gekoppelte Verbindung, so dass das erfindungsgemäße Regelsystem Plattform- und Herstellerunabhängig einsetzbar ist. Änderungen an der Konfiguration des Frameworks, d. h. der Fertigungsumgebung und an den Regeln sind jederzeit möglich und werden wirksam, ohne dass die Produktion oder das Reverssystem gestoppt oder erneut gestartet werden muss. Dadurch wird eine Entlastung der Maschinenbediener durch automatisierbare Aktionen erreicht.
• Die Erfindung soll nachfolgend an einem Ausführungsbeispiel näher erläutert werden.
• Die Zeichnungen zeigen
• 1 Referenzarchitekturmodell Industrie 4.0 (RAMI 4.0);
• 2 RAMI 4.0 Matrix;
• 3 Darstellung des erfindungsgemäßen computerimplementierten Regelsystems in einer RAMI 4.0 Matrix;
• 4 Beispiel für eine Regel für das erfindungsgemäße Regelsystem.
• 5 Darstellung einer beispielhaften Produktionsumgebung;
• 6 Erfindungsgemäßes computerimplementiertes Regelsystem.
• In einem Ausführungsbeispiel soll die Einbeziehung historischer Daten veranschaulicht werden, so dass damit eine statische Auswertung erfolgen kann.
• Durch die Einbeziehung historischer Daten in das erfindungsgemäße computerimplementierte Regelsystem ist es möglich, statistische Produktionsdaten, wie Mittelwert, Median, Standardabweichung, Varianz, etc., in der Fähigkeitsbeschreibung zu verwenden. Dafür wird ein anderer weiterer Universally Unique Identifier (UUID) als Platzhalter konzipiert, der auf eine vom Regelsystem bereitgestellte Funktion abbildet. Jede Funktion gibt die Reihenfolge der möglichen Parameter, sowie deren Typ vor. Analog zu etablierten Programmiersprachen, werden auch im Regelsystem zu Anfang die obligatorischen Parameter, im Anschluss die optionalen Parameter angegeben. In der Datenbank wird dies über die Relationen Funktion und Funktionsparameter abgebildet. Die Tabelle Funktionsparameter referenziert auf eine Funktion mittels foreign key, des Weiteren besitzt sie die Spalte Ordnung, welche die Position, an dem der Parameter erwartet wird, angibt [Int]; die Spalte Obligatorisch zeigt an, ob der Parameter obligatorisch oder optional ist [Bool] und die Spalte Typ zeigt den Datentyp an, den der Funktionsparameter besitzen muss [String]. Bei der Auswertung der Regel reicht es nicht mehr nur die Platzhalter zu ersetzten, sondern die Regel muss geparst werden. Es muss dabei geprüft werden, ob die Regel wohlgeformt und valide ist. Wohlgeformt meint in diesem Kontext, dass in der Regel auf jede öffnende Klammer - ({[ - eine schließende Klammer - ]}) - folgen muss und das zwischen zwei Platzhaltern beziehungsweise Funktionen eine Vergleichsoperation angegeben sein muss. Valide bedeutet, dass die referenzierten UUIDs und Funktionen auch in der Datenbank hinterlegt sein müssen, dass die verwendeten Funktionen mit allen obligatorischen Parametern versehen und diese vom richtigen Typ sind, sowie das nur unterstützte Vergleichsoperatoren verwendet werden dürfen und das die Vergleichsoperatoren zum Datentyp des zu vergleichenden Objekts passen. Die Konzeption definiert, dass der Beginn eines Funktionsparameters mit einem eindeutigen Zeichen zu kennzeichnen ist, dass sonst in keinem UUID oder Funktionsnamen vorkommen darf. Das Zeichen kann im Regelsystem konfiguriert werden. Standardmäßig wurde dies auf das Doppelkreuz - # - gesetzt. Um das Parsen zu vereinfachen werden die Funktionen mit ihren zugehörigen Parametern in geschweiften Klammern - {} - geschrieben. Es ist auch möglich andere Funktionen als Parameter zu referenzieren.
• Ein Beispiel für eine Regel, welche eine Funktion verwendet, kann wie folgt aussehen:

 (
  (

   (Liniel.Stationl0.KomponenteMaterial3 AND
      Linie1.Station10.KomponenteWerkzeug1) OR
   (Liniel.Stationl0.KomponenteMaterial3 AND
      Linie.Station10.KomponenteWerkzeug2)
 )  AND

 ({F.StatMittelwert#1000 #Linie1.Station10.AusschussProdukt1}
   <0,05)
)

Erläuterung des Beispiels:

Die Komponenten KomponenteMaterial3, KomponenteWerkzeugl, KomponenteWerkzeug2 gehören der Station10 an, die der Liniel zugeordnet ist. In Abhängigkeit von der Unternehmenshierarchie ist an dieser Stelle auch eine weitere Unterteilung, zum Beispiel in Abteilung und Standort möglich. Sowohl die Komponenten bzw. Assets, als auch das Ergebnis der Regel sind in diesem Fall vom Typ [Bool]. Die Funktion F.StatMittelwert berechnet den statistischen Mittelwert einer Komponente. Die obligatorischen Parameter sind in diesem Fall vom Typ #[Int], #[String] und beschreiben die Anzahl der zu betrachtenden, geloggten Informationen und die eigentliche Komponente/Asset, die/das es zu betrachten gilt. Anstelle der Komponente kann auch jede andere geloggte Information aus der Verwaltungsschale referenziert werden. Die Umsetzung der Funktion ist dabei so konzipiert, dass sofern weniger Logs vorhanden sind - als durch den Parameter gefordert werden - alle vorhandenen Logs zu einer Komponente betrachtet werden. Die Funktion lädt aus der Datenbank die geforderte Anzahl der Logs und berechnet nach mathematischer Vorschrift - im Fall des Mittelwertes siehe Formell - den Funktionswert. $$F.StatMittelwert=\frac{1}{n}{\displaystyle \sum {}_{i=1}^n{x}_i}$$

Der Typ der Funktion ist in der zugehörigen Relation definiert - in diesem Fall ist der Typ [Double]. Wird die Regel evaluiert, werden wie bisher zunächst die Platzhalter ersetzt. Der UUID Platzhalter der Funktion (F.StatMittelwert) sowie die nachfolgenden Parameter in den geschweiften Klammern - {} - werden durch den Funktionswert ersetzt. Wie in der 4 dargestellt, werden nach der Ersetzung Schrittweise die Klammern aufgelöst. Dabei steht eine gestrichelte Kennzeichnung für den Booleschen Wert TRUE und eine gepunktete Kennzeichnung für FALSE. Das Ergebnis des angegebenen Beispiels ist TRUE.

In 5 ist eine beispielhafte Produktionsumgebung 6 dargestellt. Diese besteht aus einem oder mehreren Modulen 7, z. B. Fertigungszellen oder betrieblichen Informationssystemen. Jedes Modul 7 weist seinerseits ein oder mehrere Assets 8 auf.

Die Produktionsumgebung 6 der 5 kommuniziert 9 mit dem computerimplementierten Regelsystem 1. Dies ist schematisch in 6 dargestellt. Das computerimplementierte Regelsystem 1 bzw. Framework besteht aus der Verwaltungsschale 2, wenigstens einem OPC UA Client 3, einer Regelevaluation 4 sowie einem Datenhaltungsmodul 5. Optionale Komponenten 10, wie beispielsweise eine grafische Benutzeroberfläche zur Verwaltung können ebenfalls vom erfindungsgemäßen Regelsystem 1 umfasst sein. Jedes Modul 7 bzw. deren Assets 8 der Produktions- bzw. Fertigungsumgebung 6 melden ihre jeweiligen Zustandswerte über eine industrielle Schnittstelle 9 an einen OPC UA Client 3. Dieser Client kommuniziert mit dem OPC UA Server 2 (Verwaltungsschale) sowie dem Datenhaltungsmodul 5, welches die Log-Daten (historischen Daten) enthält. Die Regelevaluation 4 prüft zeit- und eventbasiert, ob Zustandsänderungen aus der Produktionsumgebung 6, welche über die Clients 3 an die Verwaltungsschale übermittelt wurden, eine Änderung am jeweiligen Regelergebnis nach sich zieht. Das aktuelle Regelergebnis J kann in - Abhängigkeit der vorgenommenen Konfiguration -wieder an die Module 7 bzw. Assets 8 der Produktionsumgebung 6 übermittelt werden.

Bezugszeichenliste

1

computerimplementiertes Regelsystem

2

OPC UA Server

3

OPC UA Client

4

Regelevaluation

5

Datenhaltungsmodul, Datenbank

6

Fertigungsumgebung, Produktionsumgebung

7

Modul

8

Asset

9

Schnittstelle

10

Optionale Komponenten des Regelsystems

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

• DE 102016201075 A1 [0005]
• EP 3070548 A2 [0006]
• US 10416660 B2 [0006]
• WO 2016165923 A1 [0007]
• DE 102017201949 A1 [0009]

Claims (13)

1. Computerimplementiertes Regelsystem (1) umfassend einen zentralen OPC UA Server (2) und n-OPC UA Clients (3) mit n als natürliche Zahl größer 1 sowie eine zentrale Datenbank (5) als Bestandteil einer Verwaltungsschale i. S. d. RAMI 4.0, wobei die Datenbank aus jeder beliebigen SQL oder NoSQL Datenbank implementiert werden kann und aktuelle Regeln sowie eine Struktur einer aus Modulen (7) aufgebauten, industriellen Fertigungsumgebung (6) abbildet, wobei ein Modul (7) aus wenigstens einem Asset (8) gebildet ist, wobei die Regeln in der Datenbank (5) Funktionen und Platzhalter umfassen, die Zustandsdaten aller Assets (8) aus der Fertigungsumgebung (6) repräsentieren, wobei ein OPC UA Client (3) die Zustandsdaten aller Assets (8) eines Moduls (7) der Fertigungsumgebung (6) an die Verwaltungsschale propagiert und der OPC UA Server (2) auf die Zustandsdaten aller Assets (8) in der Verwaltungsschale zugreifen, Einträge ändern, überschreiben und hinzufügen kann und bei Zustandsänderungen oder zeitbasiert die betroffenen Regeln evaluiert (4) und daraus ein Ergebnis ableitet, welches in einer Fähigkeit oder kombinierten Fähigkeit in der Verwaltungsschale abgebildet wird und das Ergebnis über die OPC UA Clients (3) zurück an die jeweiligen Module (7) gewiesen wird.
2. Computerimplementiertes Regelsystem (1) nach Anspruch 1, wobei jedes Asset (8) über eine Kommunikationsschnittstelle (9) verfügt und seine Zustandsdaten an den OPC UA Client (3) kommuniziert.
3. Computerimplementiertes Regelsystem (1) nach Anspruch 1, wobei die Regeln in der Datenbank (5), die durch einen Nutzer oder ein computergestütztes System konfigurierbar sind, dynamisch an eine Auswertestrategie anpassbar und steuerbar sind, wobei die Regeln in der Datenbank (5) persistiert und dynamisch verwaltet werden.
4. Computerimplementiertes Regelsystem (1) nach Anspruch 1, wobei die Regeln in der Datenbank (5) zyklisch oder eventbasiert mit Ist-Daten einer laufenden Produktion in der Fertigungsumgebung (6) sowie mit historischen (5), gelernten Abläufen abgeglichen werden, um die Regeln zu evaluieren (4) und an zur Verfügung stehende Zustände der Assets (8) anzupassen.
5. Computerimplementiertes Regelsystem (1) nach einem der Ansprüche 1 oder 4, wobei Regeländerungen zur Laufzeit der Verwaltungsschale erfolgen.
6. Computerimplementiertes Regelsystem (1) nach Anspruch 1, wobei jeder OPC UA Client (3) mit dem OPC UA Server (2) verbunden ist.
7. Computerimplementiertes Regelsystem (1) nach Anspruch 1, wobei jede in der Verwaltungsschale gehaltene Prozess- oder Fertigungsinformation durch einen Univerally Unique Identifer (UUID) beschrieben wird, wobei der UUID von beliebig vielen Regeln referenziert werden kann.
8. Computerimplementiertes Regelsystem (1) nach Anspruch 1, wobei Fähigkeiten, die in anderen Regeln verwenden werden, kombinierte Fähigkeiten darstellen.
9. Computerimplementiertes Regelsystem (1) nach Anspruch 1, wobei Zustandsänderungen eines Moduls (7) und deren Assets (8) der Fertigungsumgebung (6) geloggt (5) werden.
10. Computerimplementiertes Regelsystem (1) nach Anspruch 1, wobei Zustandsänderungen an den Fähigkeiten und kombinierten Fähigkeiten, welche einem Asset (8) auf dem OPC UA Server (2) der Verwaltungsschale zugeordnet werden, geloggt (5) werden.
11. Computerimplementiertes Regelsystem (1) nach Anspruch 10, wobei ein anderer weiterer Univerally Unique Identifer (UUID) als Platzhalter zum Abbilden auf eine Funktion genutzt wird, die eine Reihenfolge möglicher geloggter und / oder gegenwärtiger Zustandswerte oder statischer Werte sowie deren Typ vorgibt.
12. Ein Verfahren welches das computerimplementierte Regelsystem (1) nach den Ansprüchen 1 bis 11 nutzt, wobei das Verfahren folgende Schritte aufweist: - Überwachen von Assets (8) der Fertigungsumgebung (6) und Ersetzen von Platzhaltern mit aktuellen Zustandswerten aus der Verwaltungsschale; - Registrieren einer Zustandsänderung an mindestens einem Asset (8) der Fertigungsumgebung (6); - Evaluieren aller für das mindestens eine Asset (8) relevanter Regeln durch Abgleichen der Zustandswerte mit Vorgaben und gegebenenfalls Anpassung einer Regel durch eine externe Software; - Speichern von Randbedingungen und Aggregieren der Zustandswerte der Assets der Fertigungsumgebung in einer Fähigkeit; - kontinuierliche Verbesserung der Fähigkeiten und Sammeln neuer Fähigkeiten in einer Datenbank (5); - Abrufen der Zustandswerte aus der Verwaltungsschale zu einer Fähigkeit und Bereitstellen aktueller Kapazitäten in Form von Fähigkeiten an eine nächst höhere Hierarchieebene.
13. Ein Verfahren nach Anspruch 12, wobei das Verfahren zusätzliche Zwischenschritte aufweist: - Überwachen eines Zustandes oder mehrerer Zustände und Auslösen bestimmter, in der Datenbank hinterlegter, Aktionen bei Erreichen eines definierten Zustands; - kontinuierliches Ermitteln eines statistischen Wertes aus den Zuständen, um ein definiertes Ausschlusskriterium zu überwachen.

Images