Beispielimplementation eines Austauschs von Digitalen Zwillingen mit dem Konzept der Asset Administration Shell 

Die Asset Administration Shell (AAS) ist ein aufstrebendes Konzept im Zusammenhang mit der Datenhaltung eines Digitalen Zwillings. Es handelt sich dabei um eine virtuelle Repräsentation einer physischen oder logischen Einheit, wie beispielsweise einer Maschine oder eines Produkts. Die AAS ermöglicht es, relevante Informationen über diese Einheit zu sammeln, zu verarbeiten und zu nutzen, um eine effiziente und intelligente Produktion zu gewährleisten. Die Architekturstandardisierung der AAS ermöglicht die Kommunikationen zwischen digitalen Systemen und ist damit die Grundlage für Cyber Physical Systems (CPS). Die Herleitung des Bedarfs eines Digitalen Zwillings in der Industrie finden Sie hier: ZEISS Digital Innovation Blog – Der digitale Zwilling als eine Säule von Industrie 4.0 

Dieser Artikel beschäftigt sich mit der konkreten Implementierung eines Beispiels. In einem Szenario wollen wir mit Hilfe einer Referenzimplementierung des Fraunhofer-Institut für Experimentelles Software Engineering IESE (BaSyx Implementierung der AAS v3) einen Austausch von Informationen zwischen zwei beteiligten Partnern herstellen. Beide Beteiligten sind dabei einfachheitshalber innerhalb eines Unternehmens angesiedelt und teilen sich die Infrastruktur. 

Hinweis: Auch über Unternehmensgrenzen hinweg kann diese Anwendung verteilt werden. Die dabei zu berücksichtigenden sicherheitskritischen Aspekte sind nicht Teil dieses Szenarios. 

Szenario 

Werk A ist Hersteller von Messkopfzubehör und stellt u. a. Taster her. 

Werk B stellt Messköpfe her und möchte Taster von Werk A an ihrem Messkopf verbauen. 

Zusätzlich zur physischen Weitergabe des Tasters müssen Informationen ausgetauscht werden. Die Verkaufsabteilung von Werk A stellt Kontaktinformationen zur Verfügung, damit der technische Einkauf von Werk B Preise sehen und verhandeln kann. Weiterhin muss Werk A z. B. ebenfalls eine Dokumentation zur Verfügung stellen. 

Für diesen Austausch der beiden Informationen: 

  • Kontaktdaten und 
  • Dokumentation 

soll das Konzept der AAS zum Einsatz kommen. 

Infrastruktur 

Für unser Szenario wollen wir den Typ 2 der Asset Administration Shell verwenden. Dabei wird die AAS auf Servern zur Verfügung gestellt und es findet nicht ein Austausch von AASX-Dateien statt, sondern eine Kommunikation zwischen den unterschiedlichen Services via REST-Schnittstellen. 

In unserem Szenario laufen die unterschiedlichen Services innerhalb eines Kubernetes Clusters in Docker Containern. 

Services 

Wir nehmen die BaSyx Implementierung her, um die AAS zur Verfügung zu stellen. Genauer gesagt, folgende Komponenten: 

  • AAS Repository, 
  • Submodel Repository, 
  • ConceptDescription Repository, 
  • Discovery Service, 
  • AAS Registry sowie 
  • eine Submodel Registry. 

AAS Repository, Submodel Repository und ConceptDescription Repository werden dabei innerhalb eines Containers zur Verfügung gestellt – dem AAS environment

Technische Umsetzung 

Die Kommunikation erfolgt dabei nur mittels API-Aufrufen an die entsprechenden REST-Schnittstellen der Services. 

Wir werden dabei einfache Python-Skripte nutzen, um eine Kommunikation darzustellen, bei dem das Herstellerwerk B Informationen zu einem Produkt (hier: ein Taster für einen Sensor) des Komponentenwerks A erhalten will. 

Ablauf 

Werk B kennt nur eine Asset ID von einem Taster, aber weiß sonst nichts über diese Komponente. 

  1. Werk B fragt mit der Asset ID den Discovery Service an, um an eine AAS ID zu gelangen. 
  1. Mit dieser AAS ID wird die zentrale AAS Registry angefragt, die den AAS Repository Endpunkt des Werk A zur Verfügung stellt. 
  1. Über diesen Endpunkt und die AAS ID erhält Werk B die komplette Asset Administration Shell inkl. der relevanten Submodel-IDs. 
  1. Mit diesen Submodel-IDs (u.a. für Kontaktinformationen und Dokumentation) fragt B die Submodel Registry von A an und erhält die Submodel Repository Endpunkte. 
  1. B fragt die Submodel-Endpunkte an und erhält die kompletten Submodel-Daten. Zu diesen Daten gehört die gewünschte KontaktiInformation für den Einkäufer und eine komplette Dokumentation zu dem Taster-Asset. 

Im Folgenden wird der Ablauf noch einmal im Detail mittels UML-Sequenz-Diagrammen dargestellt. 

UML-Sequenz: Erstellung Registrierung AAS im Komponenten-Werk A 

Das Werk A ist für die Registrierung ihrer eigenen Komponente zuständig. 

Abbildung 1: UML-Sequenz: Erstellung Registrierung AAS im Komponentenwerk A 

UML-Sequenz: Anfordern der Komponentendaten 

Das Werk B benötigt Daten zu der Komponente und fragt entsprechend in der AAS-Infrastruktur an. Hierbei steht dem Werk B ggf. nur die Asset ID der Komponente zur Verfügung, in unserem Fall die des Tasters. 

Abbildung 2: UML-Sequenz: Anfordern der Komponentendaten 

Implementierung 

Damit der oben beschriebene Ablauf funktioniert, müssen zum einen die erwähnten Services zur Verfügung gestellt werden. Zum anderen müssen Shells und Submodelle angelegt werden und zusätzlich in den Registries hinterlegt werden.  

Bereitstellung der Services 

Die Bereitstellung erfolgt via Docker Container, die innerhalb eines Kubernetes Clusters laufen. Hierbei bekommt jedes BaSyx Image ein Kubernetes Deployment welches via Kubernetes Replica-Sets die entsprechenden Pods starten.  
Mittels z. B. Port-Forwarding werden die entsprechenden Ports vom Host erreichbar gemacht. Dieses ist notwendig um die APIs entsprechend von den Beispiel-Python-Skripten anzusprechen. 

Die Kubernetes Deployment Konfiguration schaut folgendermaßen aus und ist dabei relativ einfach gehalten. Es existieren vier Deployments mit jeweils einem Replica-Set. 

Abbildung 3: Kubernetes-Deployment-Konfiguration 

Erzeugen der AAS von Werk A 

Werk A möchte z. B. die Kontaktinformationen zu seiner Taster-Komponente zur Verfügung stellen. 

Dazu werden Submodelle im AAS Repository erzeugt (hier: im AAS-Environment) und in der Submodel Registry registriert. 

Danach wird die Asset Administration Shell im AAS Repository erzeugt und der AAS Registry registriert. 

Anschließend wird im AAS Repository die Referenz der Shell hinzugefügt. 

Hiermit ist der Registrierungs-Prozess vom Komponentenwerk abgeschlossen. 

Anfragen von Kontakt-Informationen vom Werk B 

Werk B möchten die Kontakt-Informationen erhalten und fragt entsprechend dem oben beschriebenen Workflow die unterschiedlichen AAS-Services an. Am Ende wird der Submodel-Datensatz abgerufen, der die gewünschten Werte enthält und kann dann z. B. innerhalb eines User-Interfaces zur Verfügung gestellt werden. 

Fazit 

Die Asset Administration Shell vom Typ 2 ist ein verteiltes System, welches auf die entsprechenden Repositories, Registries und den Discovery Service baut. In unserem Beispiel haben wir nur ein einfaches Submodel-Template für Kontaktdaten verwendet. Allerdings stehen weitaus mehr Templates für viele Anwendungsfälle zur Verfügung. 

Die Kommunikation zwischen den Services zur Bereitstellung und zum Abruf der Daten ist relativ unkompliziert möglich, wobei in diesem Szenario Aspekte wie z. B. Sicherheit nicht im Fokus waren. 

Die in diesem Artikel beschriebene Beispielimplementierung lässt das enorme Potential des AAS-Konzepts erahnen und regt dazu an, konkrete Umsetzungen zu starten. 

Dieser Beitrag wurde verfasst von:

Daniel Brügge

Daniel Brügge arbeitet als Softwareentwickler bei ZEISS Digital Innovation mit dem Fokus auf Cloud-Entwicklung und verteilte Anwendungen.

Datenplattformen für die Fabrik 4.0 – Make or Buy? Das Fundament für die smarte Produktion

Alle modernen Digitaltechnologien zur Produktionsoptimierung wie Digitale Zwillinge und Künstliche Intelligenz oder klassische Verfahrensweisen wie Prozessdaten-Monitoring und Alarmierung haben eines gemeinsam: Sie können nur implementiert werden, wenn die Prozessdaten in einer hohen Qualität zur Verfügung stehen. Ist das nicht der Fall, kann mit modernen Digitaltechnologien nicht gearbeitet werden.

Bevor also z. B. mit KI im Unternehmen gestartet werden kann, gilt es sich mit der Bereitstellung der Daten zu beschäftigen. Um für unterschiedlichste spätere Anwendungsfälle nicht jedes Mal neu anfangen zu müssen, bietet es sich an, einen allgemeinen, generischen Ansatz für das Sammeln und Bereitstellen von Daten zu wählen. Es handelt sich dabei um eine Art von Middleware, die wir an dieser Stelle als Datenplattform bezeichnen.

Die erste Aufgabe einer Datenplattform ist es, die Daten aus unterschiedlichsten Datensilos zu sammeln und gemeinsam bereitzustellen. In einer diskret arbeitenden Fabrik sind das in erster Linie Maschinendaten (z. B. Prozessdaten über die Zeit, Alarmmeldungen, Zustandsmeldungen), Auftragsdaten aus dem ERP-System (z. B. Arbeitsaufträge, Arbeitsgänge, Stücklisten, Chargennummer, Teile- und Baugruppennummern), MES-Daten (z. B. Lagerorte, Zwischenlagerzeiten, Maschinenbelegungen) und verschiedenste Daten aus Drittsystemen je nach Branchenausprägung, wie z. B. aus CAD und CAQ-Systemen. Diese Daten sind in modernen Produktionsumgebungen stets vorhanden, können aber ohne eine Datenplattform nicht in Beziehung zueinander gestellt und auswertbar gemacht werden.

Wie jede andere Software auch, kann eine Datenplattform in zwei Wegen realisiert werden: Als Standardsoftware oder als Individualsoftware, zugeschnitten auf genau einen Kunden. Im Folgenden wollen wir die Vor- und Nachteile der verschiedenen Lösungsmöglichkeiten betrachten.

Datenplattform als Standardprodukt

Seit einigen Monaten bringen mehr und mehr Hersteller verschiedenste Standardprodukte auf den Markt. Sie sind teils universal verwendbar, teils stark auf eine bestimmte Branche zugeschnitten. Der Vorteil von standardisierter Software liegt auf der Hand: Sie ist im Idealfall sehr schnell verfügbar und einsatzbereit. Außerdem bringt sie in den meisten Fällen auch sofort Business-Applikationen mit, mit deren Hilfe aktuelle Problem- und Fragestellungen gelöst werden können. In einigen Fällen können die Business-Applikationen sogar durch nicht-IT-Fachkräfte bedient werden und es bedarf keinem Data-Engineer.

Aber bringt dieser Out-of -the-box Gedanke wirklich einen Mehrwert im Zuge der digitalen Transformation einer Fabrik? Das Kernproblem der digitalen Transformation ist das notwendige Umdenken von Mitarbeitenden hinsichtlich datengetriebener Produktion. Oft sind Anforderungen und Wünsche an eine Datenplattform noch nicht ausgeprägt oder vorhanden, da die meisten Mitarbeitenden mit dieser Art von Software noch nicht in Berührung gekommen sind. Ein objektiver, systematischer Vergleich zwischen mehreren Produkten verschiedener Hersteller ist schwierig oder gar unmöglich. So kann es dazu kommen, dass hohe Investitions- und Lizenzkosten für ein suboptimales Produkt gezahlt werden oder erst sehr spät festgestellt wird, dass das Produkt nicht geeignet ist. Bei kleinen und mittelständigen Softwareherstellern ist der Investitionsschutz nur bedingt vorhanden, da diese auch dynamisch auf den Markt reagieren müssen. Im Zweifel kann das bedeuten, dass das Produkt von heute auf morgen nicht mehr gepflegt wird.

Cloud-native Individuallösung

Um den sich ständig ändernden Anforderungen aus dem Prozess der digitalen Transformation des Unternehmens gerecht zu werden, bietet sich eine individuelle Softwarelösung für die Datenplattform an. Als Technologie der Wahl haben sich in den letzten Jahren die Cloud-nativen Services der großen Hyperscaler Microsoft Azure und Amazon Web Services (AWS) herausgebildet. Diese haben einen entscheidenden Vorteil: Durch die Wahl moderner Technologie-Services, welche als Platform as a Service (PaaS) bereitstehen, ist die potenzielle Lösung der Datenplattform hoch performant, kostengünstig und nachhaltig im Sinne der Langlebigkeit des Softwarecodes. Dies wirkt sich in Form eines sehr hohen Investitionsschutzes aus. Die Programmierung der Datenplattform erfolgt stets durch einen Integrator wie z. B. ZEISS Digital Innovation unter Verwendung der Services eines Hyperscalers. Diese Kombination bringt weitere Vorteile mit sich. Im Gegensatz zu einem Standardprodukt eines konkreten Herstellers kann die individuelle Lösung nach der Fertigstellung auch durch den Kunden selbst betrieben werden. Wenn erforderlich, ist der Betrieb sogar durch dritte Parteien möglich. Das reduziert die Abhängigkeit von Integratoren, was für geplante Laufzeiten der Datenplattform von schätzungsweise zehn bis 20 Jahren oder mehr enorm wichtig ist. Die Abhängigkeit von den Hyperscalern ist ein untergeordnetes Thema. Bei der Wahl der PaaS-Technologien kann der Integrator solche nutzen, die bei mehr als einem Hyperscaler zur Verfügung stehen. Ein Umzug von Microsoft zu AWS oder umgekehrt ist zwar mit Arbeit verbunden aber absolut möglich. Dieser Schritt ermöglicht es dem Kunden, auf zukünftige Betriebskostenerhöhungen der Hyperscaler zu reagieren.

Co-Innovationen durch Barrierefreiheit

Die bisherigen Erkenntnisse der startenden digitalen Transformation von Unternehmen im Zuge der vierten industriellen Revolution belegen einen zwingenden Bedarf von Co-Innovation. Damit ist die enge Zusammenarbeit von mehreren industriellen Partnern gemeint, die ihr hochspezialisiertes Wissen nutzen, um einen höheren gemeinsamen Mehrwert für Kunden zu schaffen, als einzelne Unternehmen in der Lage wären.

Die Cloud-native Individuallösung bietet genau diesen Vorteil der barrierefreien Zusammenarbeit von mehreren Unternehmen auf der Datenplattform. Im Kontext der PaaS-Lösungen eines Hyperscalers kann man sich von dritten Firmen genau die Business-Applikationen kaufen oder programmieren lassen, die exakt auf den Anwendungsfall passen, den es im eigenen Unternehmen zu lösen gilt. Diese Basis ermöglicht es dann, stets auf modernste Technologien wie KI oder digitale Zwillinge aufzusetzen, damit Vorreiter in der eigenen Branche zu werden und einen Wettbewerbsvorteil zu generieren.

Cyber-physikalische Systeme als eine Säule von Industrie 4.0

Was ist das?

Ein Cyber-physikalisches System (CPS) steuert einen physikalisch-technischen Prozess und vereint dazu Elektronik, komplexe Software und Netzwerkkommunikation z.B. über das Internet. Charakteristisch ist, dass alle Elemente einen untrennbaren Beitrag zur Funktionsweise des Systems leisten. Daher wäre es falsch, jedes Gerät mit etwas Software und einem Netzwerkanschluss zu einem CPS zu erklären.

Gerade im Fertigungsumfeld sind CPS oft mechatronische Systeme, z.B. vernetzte Roboter. Embedded Systems stehen im Kern dieser Systeme, werden durch Netzwerke miteinander verbunden und durch zentrale Softwaresysteme z.B. in der Cloud ergänzt.

Cyber-physikalische Systeme sind durch ihre Vernetzung in der Lage, auch Infrastrukturen automatisch zu steuern, die über größere Entfernungen oder viele Orte verteilt sind. In der Vergangenheit waren diese nur begrenzt automatisierbar. Beispiele dafür sind dezentral gesteuerte Stromnetze, Logistikabläufe und verteilte Produktionsprozesse.

Im Fertigungsumfeld ermöglichen CPS durch ihre Automatisierung, Digitalisierung und Vernetzung eine hohe Flexibilität und Autonomie der Produktion. Dadurch werden z.B. Matrix-Produktionssysteme möglich, die hohe Variantenvielfalt für große und kleine Stückzahlen unterstützen [1].

Es hat sich bisher keine einheitliche Definition durchgesetzt, da der Begriff breite und unspezifische Anwendung findet und manchmal auch utopisch-futuristische Konzepte damit vermarktet werden [2].

Woher kommt der Begriff?

Innovationen im Bereich der IT, Netzwerktechnik, Elektronik etc. ermöglichten in den vergangenen Jahren komplexe, automatisierte und vernetzte Steuerungssysteme. Akademische Disziplinen wie die Steuerungs- und Regeltechnik sowie die Informationstechnik boten kein passendes Konzept für den neuen Mix aus technischen Prozessen, komplexen Daten und Software. Daher wurde ein neues Konzept mit einem passenden Namen nötig.

Der Begriff steht in enger Verwandtschaft zum Internet of Things (IoT). Außerdem bilden Cyber-physikalische Systeme den technischen Kern für viele Innovationen, die das Label „smart“ im Namen tragen: Smart Home, Smart City, Smart Grid etc.

Übrigens wird der deutsche Begriff nicht einheitlich verwendet, die alternative Schreibweise Cyber-physische Systeme wird z.B. durch den Verein Deutscher Ingenieure (VDI) in seinen Normen propagiert. In der Fachliteratur hat sich diese Schreibweise aber bisher nicht durchgesetzt.

Merkmale von CPS

Wie bereits erwähnt gibt es keine allgemein anerkannte Definition. Aus der Vielzahl von Definitionen lassen sich aber folgende Merkmale destillieren:

  • Im Kern steht ein physikalischer oder technischer Prozess.
  • Es gibt Sensoren und Modelle, um den Zustand des Prozesses digital zu erfassen.
  • Es gibt komplexe Software, um auf Basis des Zustands eine (teil-)automatische Entscheidung zu treffen. Dabei ist ein menschlicher Eingriff möglich, aber nicht zwingend nötig.
  • Es gibt technische Mittel, um die getroffene Entscheidung umzusetzen.
  • Alle Elemente des Systems sind vernetzt, um Informationen auszutauschen.

Ein Modell für den Aufbau eines CPS ist das Schichtenmodell nach [2]

Abbildung 1: Schichtenmodell für den inneren Aufbau von Cyber-physikalischen Systemen

Beispiele von Cyber-physikalischen Systemen

  • Selbststeuernde Fertigungsmaschinen und -prozesse (Smart Factory)
  • Dezentrale Steuerung von Stromerzeugung und -verbrauch (Smart Grids)
  • Gebäudeautomatisierung im Haushalt (Smart Home)
  • Verkehrssteuerung in Echtzeit, durch zentrale oder dezentrale Steuerung mit Verkehrsleitsystemen oder Apps (Element der Smart City)

Beispiel für ein Cyber-physikalisches System in der Industrie

In diesem Beispiel wird eine Fertigungsmaschine vorgestellt, die durch Software und Vernetzung weitgehend autonom agieren kann und dabei Leerlauf- Ausfall- und Wartungszeiten minimiert. Für unser Beispiel nehmen wir an, dass es sich um eine Werkzeugmaschine für die Zerspanung handelt.

Vernetzte Elemente des Systems:

  • Werkzeugmaschine mit
    • QR-Code-Kamera zur Werkstück-Identifikation
    • RFID-Leser zur Werkzeug-Identifikation
    • Automatische Vorratsüberwachung
    • Verschleißerkennung und Wartungsvorhersage
  • Zentrales IT-System für Konstruktionsdaten und Werkzeugparameter (CAM)
  • MES/ERP-System

Die Fertigungsmaschine in unserem Beispiel ist in der Lage, das Werkstück und das Werkzeug zu identifizieren. Dafür können die gängigen Technologien RFID oder QR-Code verwendet werden. Ein zentrales IT-System verwaltet Konstruktions- und Vorgabedaten, z.B. bei CNC-Maschinen ein Computer-aided Manufacturing-System (CAM). Die Fertigungsmaschine ruft mit der ID von Werkstück und Werkzeug alle Daten aus dem zentralen System ab, die für die Bearbeitung nötig sind. Damit entfällt die manuelle Eingabe von Parametern, die Daten werden durchgängig digital verarbeitet. Die Identifikation ermöglicht die Verbindung von physikalischer Schicht und Datenschicht eines Cyber-physikalischen Systems.

Die digitalisierten Daten für Werkstücke, Maschinen und weitere Elemente einer Fertigung können unter dem Begriff Digitaler Zwilling zusammengefasst werden, der im Blogartikel „Der digitale Zwilling als eine Säule von Industrie 4.0“ von Marco Grafe vorgestellt wurde.

Basierend auf den Konstruktions- und Vorgabedaten werden die eingerüsteten Werkzeuge und die in der Maschine vorhandenen Material- und Ressourcenvorräte überprüft. Bei Bedarf benachrichtigt die Maschine das Personal. Durch diese Validierung vor Bearbeitungsbeginn kann Ausschuss vermieden und die Auslastung erhöht werden.

Die Maschine überwacht ihren Zustand (in Betrieb, Leerlauf, Störung) und meldet diesen digital an ein zentrales System, mit dem Auslastung und weitere Betriebskennzahlen erfasst werden. Solche Funktionen zur Zustandsüberwachungen sind typischerweise in ein Manufacturing Execution System (MES) integriert und mittlerweile weit verbreitet. Für eine höhere Autonomie ist die Maschine in unserem Beispiel zusätzlich in der Lage, den eigenen Verschleiß zu messen, daraus Wartungsbedarf vorherzusagen und zu melden. Diese Funktionen sind unter dem Stichwort Predictive Maintenance bekannt. Diese Maßnahmen erhöhen die Maschinenverfügbarkeit und erleichtern Wartung und Arbeitsplanung.

Durch den Einsatz von Elektronik und Software ist unser fiktive Fertigungsmaschine in der Lage, weitgehend autonom zu arbeiten. Die Rolle des Menschen wird auf Beschickung, Rüsten, Entstörung und Wartung reduziert, er unterstützt damit nur noch die Maschine im Fertigungsprozess.

Literatur

[1] Forschungsbeirat Industrie 4.0, „Expertise: Umsetzung von cyber-physischen Matrixproduktionssystemen,“ acatech – Deutsche Akademie der Technikwissenschaften, München, 2022.

[2] P. H. J. Nardelli, Cyber-physical systems: theory, methodology, and applications, Hoboken, New Jersey: Wiley, 2022.

[3] P. V. Krishna, V. Saritha und H. P. Sultana, Challenges, Opportunities, and Dimensions of Cyber-Physical Systems, Hershey, Pennsylvania: IGI Global, 2015.

[4] P. Marwedel, Eingebettete Systeme: Grundlagen Eingebetteter Systeme in Cyber-Physikalischen Systemen, Wiesbaden: Springer Vieweg, 2021.

Datengetriebene Prozessregelung – Teil 3: Regelung von Systemverhalten

Dieser dritte und letzte Teil der Artikelserie zur datengetriebenen Prozessregelung liefert eine Einführung in Ansätze zur Regelung von Systemen. Im Mittelpunkt steht dabei das klassische „Model-Predictive-Control“ Schema, welches mit den Ergebnissen zur Systemmodellierung aus dem zweiten Artikel zu einer rein datengetriebenen Regelungsstrategie kombiniert wird.

Für die Regelung von Systemen existieren zahlreiche theoretische wie praktische Ansätze. Eine der einfachsten stellen sogenannte PID Regler dar, die in Anwendungen wie Motor- und Temperaturreglungen, Laderegelungen für Solaranlagen oder Reglern für Leistungselektronik zum Einsatz kommen.

Wir wollen uns allerdings mit einer fortgeschritteneren Regelungsstrategie für ein breiteres Anwendungsspektrum befassen, dem „Model Predictive Control (MPC)“ (siehe [3] und [4]). Wie aus der Bezeichnung zu entnehmen ist, setzt diese Strategie die Fähigkeit zur Vorhersage des Systemverhaltens voraus. Eine Anforderung, die durch Modellbildung im Sinne des vorangegangenen Abschnittes aber auch durch den vorgestellten databasierten Ansatz erfüllt werden kann.

Gegenstand der Regelungsstrategie ist die Steuerung der Ausgangszielgrößen durch Modifikation der Eingriffsgrößen, so dass erstere in einem durch Referenzdaten bestimmten Korridor verbleiben.

Abbildung 1: Das Model Predictive Control (MPC) Schema

Die MPC Strategie stellt einen iterativen Prozess dar, der aus den drei folgenden Phasen besteht (siehe auch Abbildung 1).

  1. Ausgangspunkt bilden historische Daten des zu regelnden Systems. Diese bestehen zum einen aus den Werten der Eingriffsparameter in zurückliegenden Regelschritten und zum anderen aus den zugehörigen, vom System gelieferten Ausgabedaten. Da auch die Referenzdaten sich mit der Zeit verändern können, stellen auch sie einen Teil der historischen Daten dar. Diese Datenbasis repräsentiert also den Status quo des betrachteten Systems. Jede Vorhersage des Systemverhaltens muss sich nahtlos an diese Historie anfügen.
  2. Ausgehend vom bestehenden Systemzustand wird das Modell des Systems dazu verwendet, eine optimale Vorhersage von zukünftigen Eingriffsgrößen und zugehörigen Ausgaben zu berechnen. Das entscheidende Optimierungskriterium stellt dabei die Forderung dar, dass sich die Ausgabe des Systems im betrachteten Vorhersagezeitraum bestmöglich den gewünschten Referenzwerten annähert (siehe „Mathematischer Hintergrund“). Dabei gilt es zusätzlich, die technischen Rand- und Grenzbedingungen der Eingriffsparameter zu berücksichtigen.
  3. Der dritte und letzte Schritt besteht in der Anwendung der berechneten Eingriffsgrößen im System selbst. Dies entspricht einem Praxistest des zur Vorhersage verwendeten Modells. Darüber hinaus werden die vorhergesagten Eingriffsgrößen nicht über den gesamten festgelegten Vorhersagehorizont angewendet sondern nur für einige wenige Schritte. Dies erfolgt in dem Wissen, dass vom Modell unberücksichtigte Einflüsse das Feedback verfälschen und damit die Genauigkeit der Vorhersagen einschränken. Gleichzeitig sichert das Feedback die Stabilität der Strategie, da die neu gewonnenen Daten in die Datenhistorie eingehen und so die aktualisierte Basis für die nächste Vorhersage bilden.

Diese drei beschriebenen Phasen werden zyklisch durchlaufen. Die Frequenz dieses Prozesses hängt unmittelbar von den Erfordernissen des jeweiligen Anwendungsfalles ab. Insbesondere bei der Regelung von Echtzeitsystemen wie Fahr- und Flugzeugen sind hier Frequenzen von einigen 10Hz notwendig.

Mathematischer Hintergrund

Das „Model Predictive Control“ Schema beinhaltet als zentrales Element die Vorhersage der
zukünftigen Eingabeparameter u_f und Ausgabegrößen y_f, welche den Abstand zu einer Referenztrajektorie
w_r = (u_r, y_r) im Vorhersagezeithoriziont T_f minimieren. Zusätzlich sind historische Daten in Form einer Anfangstrajektorie w_\text{ini} = (u_\text{ini}, y_\text{ini}) der Länge T_\text{ini} gegeben, welche durch die gesuchte Trajektorie w_f = (u_f, y_f) fortzusetzen ist.

Abbildung 2: Vorhersage im Model Predictive Control Schema

Da die algebraische Repräsentation H_L des zeitbeschränkten Verhaltens B_L es erlaubt, für jedes w \in B_L einen Vektor g zu bestimmen, für den H_L \, g = w gilt, können wir folgendes restringierte Optimierungsproblem für w_f aufstellen

    \[\begin{aligned} &\underset{g}{\text{minimize}} \quad \| H_{T_f} \ g - w_r \|^2_2 & \\[1.0em] &\text{subject to} \quad H_{T_\text{ini}} \ g = w_\text{ini}, & \end{aligned}\]

unter Verwendung der Zerlegung

    \[H_L \, g = w \quad \Longleftrightarrow \quad \begin{bmatrix} H_{T_\text{ini}} \\[0.5em] H_{T_f} \end{bmatrix} \, g= \begin{bmatrix} w_\text{ini} \\[0.5em] w_f \end{bmatrix}\]

Die Nebenbedingung sichert dabei die Einhaltung der Anfangsbedingung und die Verwendung von H_{T_f} \ g im Minimierungfunktional erzwingt, dass die ermittelte zukünftige Trajektorie w_f = H_{T_f} \ g zulässig ist für das System S. Zusätzlich können Nebenbedingungen an w_f formuliert werden, was aus Gründen der Übersichtlichkeit hier nicht erfolgte. Weitere Details sind in [2] und [7] ausgeführt.

Die Robustheit dieses Schemas gegenüber Störungen in Form nicht modellierten Systemverhaltens kann mathematisch nachgewiesen werden. Insbesondere ist gesichert, dass das im Schritt 2 gestellte Optimierungsproblem in jedem folgenden Zyklus lösbar bleibt, sofern es im ersten lösbar war. Damit ist die unbeschränkte Ausführbarkeit des Verfahrens gesichert (siehe [5] und [6]).

Zusammenfassung

Die Regelung von physikalischen Systemen erfordert a-priori Wissen, welches durch Systemmodelle
in die Regelungsaufgabe eingeführt wird. Die üblichen Ansätze zur Modellbildung stoßen dabei auf
prinzipielle Grenzen mit wachsender Komplexität des Systems. Sie liefern allerdings während ihrer Erstellung
wesentliche theoretische Einblicke in die Struktur des Systems und benötigen nur wenig experimentelles Vorwissen.

Der vorgestellte datenbasierte Ansatz hingegen generiert eine Systemrepräsentation aus einer einzigen
Beobachtungsreihe, zu deren Gewinnung das System einer spezifischen Anregung ausgesetzt wird.
Die Vollständigkeit der erzeugten Systemrepräsentation kann anhand der bereits gewonnenen Daten
geprüft werden, was eine für ein Lernverfahren bemerkenswerte Eigenschaft darstellt.
Durch dieses Vorgehen unterliegt das Verfahren keinerlei prinzipiellen Einschränkungen hinsichtlich der Systemkomplexität, benötigt stattdessen aber spezielle empirische Daten zur Systembeschreibung.

Obwohl der neue Ansatz kein Modell im eigentlichen Sinne liefert, ist es mit der von ihm erzeugten
Systemrepräsentation möglich, spezifische Vorhersagen zum Systemverhalten zu treffen. Dabei wird nicht nur die Konvergenz gegen einen gewünschten Zielzustand realisiert, sondern werden gleichzeitig eingabe- wie ausgabeseitig technische und physikalische Restriktionen umsetzt. Dies stellt einen signifikanten Vorteil gegenüber anderen Lernverfahren dar und ermöglicht sicherheitskritische Anwendungen im Zusammenspiel mit etablierten Regelungsstrategien wie dem „Model Predictive Control“.

Ausblick

Die Darstellung des neuen datenbasierten Ansatzes hat die Behandlung zweier wesentlicher Probleme ausgespart.

Der erste Aspekt betrifft die Anwendung auf nichtlineare Systeme. Den theoretischen Voraussetzungen nach ist der datenbasierte Ansatz auf lineare zeitinvariante Systeme beschränkt. Einerseits gibt es in jüngster Zeit Versuche wie in [1] oder [4], diese Einschränkung aufzuheben. Andererseits sind die Gründe für die beobachtete erfolgreiche Regelung nichtlinearer Systeme durch das datenbasierte Vorgehen bisher noch nicht verstanden und daher Gegenstand aktueller Forschung, siehe [2].

Der zweite Aspekt bezieht sich auf die Verwendung verrauschter Beobachtungsdaten bei der Rekonstruktion des Systemverhaltens. Auch hier sind bereits wesentliche Fortschritte zur Stabilisierung datenbasierter Ansätze erzielt worden, siehe [2]. Allerdings zeigen sich andere Ansätze zur Systemidentifikation noch als deutlich unempfindlicher gegenüber Rauscheinflüssen.

Insgesamt zeichnet sich das Bild ab, dass aktuelle datenbasierte Verfahren robust gegenüber Bias-Datenfehlern sind, also Daten aus nicht linearen Systemen, und anfälliger hinsichtlich Varianz-Datenfehlern, also Datenrauschen.

Literatur

[1] Ezzat Elokda, Jeremy Coulson, Paul N. Beuchat, John Lygeros, and Florian Dörfler, „Data-enabled predictive control for quadcopters“, International Journal of Robust and Nonlinear Control, 2021

[2] Florian Dörfler, Jeremy Coulson, and Ivan Markovsky, „Bridging direct and indirect data-driven control formulations via regularizations and relaxations“, IEEE Transactions on Automatic Control, 2022

[3] James B. Rawlings, David Q. Mayne, and Moritz M. Diehl, „Model predictive control – theory, computation, and design“, Nob Hill Publishing, 2022

[4] Julian Berberich, Johannes Köhler, Matthias A. Müller, and Frank Allgöwer, „Data-driven model predictive control – closed-loop guarantees and experimental results“, at-Automatisierungstechnik, 2021

[5] Joscha Bongard, Julian Berberich, Johannes Kohler, and Frank Allgower, „Robust stability analysis of a simple data-driven model predictive control approach“, IEEE Transactions on Automatic Control, 2022

[6] Julian Berberich, Johannes Köhler, Matthias A. Müller, and Frank Allgöwer, „Stability in data-driven MPC – an inherent robustness perspective“, IEEE Conference on Decision and Control, 2022

[7] Ivan Markovsky and Florian Dörfler, „Behavioral systems theory in data-driven analysis, signal processing, andcontrol“, Annual Reviews in Control, 2021

Datengetriebene Prozessregelung – Teil 2: Modellierung von Systemverhalten

Nachdem der erste Artikel der Serie sich mit den allgemeinen Grundbausteinen von Regelungssystemen beschäftigt hat, widmet sich der zweite Artikel der Modellierung des Verhaltens von Systemen. Dabei steht die Differenzierung verschiedener Modellierungsarten im Vordergrund. Den Hauptteil des Artikels bildet die Einführung eines speziellen datengetriebenen Ansatzes, der in jüngster Zeit wachsendes wissenschaftliches Interesse auf sich gezogen hat.

Die Kenntnis des Systemverhaltens, d. h. das Wissen um die quantitative Veränderung der Ausgaben bei Veränderung der Eingaben des Systems, ist eine Grundvoraussetzung für die Systemregelung. Dieses Wissen wird durch Verhaltensmodelle repräsentiert, deren Entwicklung wir in diesem Artikel näher untersuchen wollen.

Ein physikalisches Bespielsystem

Als einfaches physikalisches Beispiel betrachten wir ein sogenanntes ideales ebenes Pendel. Die Pendelmasse wird als punktförmig und an einem masselosen Seil aufgehängt angenommen, alle Reibungskräfte bleiben unberücksichtigt. Die einzige auf die Masse wirkende Kraft ist die Gravitationskraft der Erde (siehe Abbildung 3).

Abbildung 3: Das ideale Pendel

An diesem Beispiel werden wir drei grundlegende Modellierungsarten beschreiben.

Whitebox Modellierung

Bei dieser Art der Modellierung wird das Systemverhalten durch Differentialgleichungen repräsentiert, deren Parameter vollständig bekannt sind. Der Ansatz ist hochgradig anwendungsfallspezifisch und erfordert ein hohes Maß an Detailwissen zum betrachteten System. Die Komplexität realer Systeme setzt der Anwendung dieses Ansatzes natürlicherweise Grenzen. Zusätzlich ist die Herangehensweise schwer automatisierbar und die erhaltenen Modelle sind nur mit großem Aufwand an veränderte Anforderungen anpassbar.

Beispiel – Whitebox Modellierung des Pendelsystems

Ausgangspunkt bilden das zweite Newtonsche Gesetz F = m \, a sowie das Gravitationsgesetz Newtons spezialisiert für Körper nahe der Erdoberfläche F = m \, g \, [\, 0, -1 \,]^T.

Für die Bewegung des Pendels ist lediglich die tangential an die Pendelmasse angreifende Kraft F_T zu betrachten, da die radiale Komponente durch das Seil kompensiert wird. Aus dem gleichen Grund ist lediglich die Tangentialbeschleunigung a_T relevant. Unter Verwendung des zeitabhängigen Ablenkungswinkels \theta(t) und der Winkelbeschleunigung \ddot{\theta}(t) (siehe Abbildung 3) sind die Größen F_T und a_T gegeben als

    \[F_T = -m \ g \sin \theta(t) \quad \text{und} \quad a_T(t) = l \, \ddot{\theta}(t)\]

mit der Länge l des Pendelseils und g \approx 9.81 \frac{m}{s^2} als der Fallbeschleunigung auf der Erde. Damit ergibt sich aus m \ a_T = F_T folgende Differentialgleichung für den Ablenkungswinkel \theta:

\ddot{\theta} (t) = - \frac{g}{l} \ \sin \theta(t)

Wenn wir zusätzlich den Winkel \theta als klein annehmen, erhalten wir als weitere Vereinfachung

\ddot{\theta} (t) = - \frac{g}{l} \ \theta(t)

Diese Differentialgleichung kann dazu verwendet werden, das Verhalten des Pendels für jeden Anfangswinkel \theta_0 \ll 1 und jede Anfangsgeschwindigkeit \dot{\theta}_0 vorherzusagen.

Grey- and Blackbox Modellierung

Dieser Modellierungszugang führt ebenfalls auf Differential- oder Differenzengleichungen, die allerdings lediglich die grundlegende Struktur des Systems vorgeben und daher freie Parameter enthalten. Fließt in das Systemmodell Vorwissen, z. B. in Form von physikalischen Prinzipien ein, so handelt es sich um ein Grey-Box Model, anderenfalls wird von einem Black-Box Model gesprochen.

Die freien Parameter des Modells werden in einem Adaptionsschritt aus Beobachtungsdaten des Systems bestimmt, wobei dieser Schritt der Modellbildung weitgehend automatisiert werden kann. Die Auswahl der Modellstruktur hingegen erweist sich als kritisch für die Qualität des Modells, erfordert aufgrund seiner Komplexität ein hohes Maß an Erfahrung und kann daher nur bedingt automatisiert werden. Darüber hinaus können Grey- und Blackbox Modelling im Gegensatz zum White-Box Ansatz auf beliebig komplexe Systeme angewendet werden.

Daten basierte Modellierung

Dieser neue Ansatz zieht seit einigen Jahren zunehmend Aufmerksamkeit auf sich. Ausgangspunkt ist der Gedanke, ein System ausschließlich mit seinem von außen verifizierbaren Verhalten zu identifizieren. Eine ausführliche Darstellung des systemtheoretischen Hintergrundes für diesen Ansatz findet sich in [1]. Mit der zunehmenden Verfügbarkeit von Prozessdaten technischer Systeme wandelte sich die Sicht auf diese datengetriebene Betrachtungsweise. Es wurde erkannt, dass die Beschreibung des Systemverhaltens rein auf der Basis von Beobachtungen die Tür zu neuen Modellen und Algorithmen öffnete (siehe [2] und [3]). Diese Entwicklung ist vergleichbar mit den Entwicklungen bei der Anwendung von neuronalen Netzen in den vergangenen Jahren.

Da es sich um ein nicht-überwachtes Lernverfahren für nicht-parametrische Modelle handelt, wird im Gegensatz zum White-, Grey- und Black-Box Modelling kein Modell des Systems konstruiert. Damit unterliegt die Anwendbarkeit dieser Herangehensweise weder einer komplexitätsbedingten Einschränkung, noch verhindert die Notwendigkeit einer Strukturentscheidung seine Automatisierung. Allerdings ist es dem Ansatz nach zunächst auf sogenannte lineare und zeitinvariante Systeme beschränkt (siehe „Mathematischer Hintergrund“).

Beispiel – Datenbasierte Modellierung des Pendelsystems

Um eine datenbasierte Repräsentation für das Pendelsystem zu erhalten, benötigen wir lediglich zwei Experimente. Unter Verwendung der Bezeichnung x(t) = [\, \theta(t), \dot{\theta}(t) \, ]^T mit dem Ablenkungswinkel \theta(t) und der Winkelgeschwindigkeit \dot{\theta}(t) können die Anfangsbedingungen für die beiden Experimente angesetzt werden zu

    \[  x_1(0) =    \left[   \begin{array}{c}      1 \\      0   \end{array}   \right]   \quad \text{und} \quad   x_2(0) =    \left[   \begin{array}{c}      0 \\      1      \end{array}   \right]\]

Das erste Experiment zeichnet die Bewegung x_1(t) des Pendels zum Startwinkel 1^{\circ} und verschwindender Startgeschwindigkeit zu diskreten Zeitpunkten \{ t_i \}_{i=1}^n auf. Das zweite Experiment verwendet für die Aufzeichung von x_2(t) das dazu inverse Setting.

Aus den Aufzeichnungen der beiden Experimente kann dann jede andere Pendelbewegung x(t) zu den Anfangsbedingungen x(0) = [\, \theta_0, \dot{\theta}_0 \,]^T mittels der Beziehung

    \[x(t) = \theta_0 \ x_1(t) + \dot{\theta}_0 \ x_2(t)\]

zu den Zeitpunkten \{ t_i \}_{i=1}^n berechnet werden, wofür die lineare Unabhängigkeit der Vektoren der beiden Anfangsbedingungen die Grundlage darstellt. In kompakter Form erhalten wir weiter die Darstellung

    \[B \, x(0) = x \quad \text{mit} \quad B = \begin{bmatrix} x_1(t_1) & x_2(t_1) \\ \vdots & \vdots \\ x_1(t_n) & x_2(t_n) \end{bmatrix} \quad \text{und} \quad x = \begin{bmatrix} x(t_1) \\ \vdots \\ x(t_n) \end{bmatrix}\]

Die Matrix B bezeichnen wir als algebraische Repräsentation des Pendelverhaltens.

Die Zielstellung, das vollständige Systemverhalten allein aus Beobachtungsdaten zu rekonstruieren, wirft drei wesentliche Fragen auf:

  • Welche Daten eignen sich zur Verhaltensrepräsentation?
  • Wie kann diese Eignung überprüft werden?
  • Welchen Umfang müssen die gesammelten Daten besitzen?

Die mathematische Theorie gibt hier eindeutige Antworten (siehe „Mathematischer Hintergrund“). Wir wollen uns an dieser Stelle auf die Feststellung beschränken, dass die erhobenen Daten eine mathematisch exakt definierte Unabhängigkeit besitzen müssen (siehe Beispiel – Datenbasierte Modellierung des Pendelsystems). Solche Daten lassen sich nur gewinnen, indem das System in systematischer Art und Weise angeregt wird, da physikalische Systeme natürlicherweise dazu tendieren, ohne solche Störungen nach einiger Zeit in einen Gleichgewichtszustand überzugehen.

Die notwendige Vorgehensweise besteht daher darin, im Beobachtungszeitraum das System mittels zufälliger Eingaben anzuregen und damit ein möglichst breit gefächertes Verhalten in den Ausgaben zu induzieren (siehe Abbildung 4). Dabei ist zu beachten, dass diese Systemanregung unter Einhaltung der technischen Rand- und Grenzbedingungen des Systems erfolgen muss, um eine Destabilisierung mit ggf. schwerwiegenden Konsequenzen zu vermeiden.

Abbildung 4: Zufällige Eingaben zur Exploration des Systemverhaltens

In regelmäßigen Abständen wird mittels eines Dimensionskriteriums geprüft, ob die gesammelten Daten die Gesamtheit der möglichen Systemreaktionen bereits erfassen. Diese Prüfung erfordert die Angabe der gewünschten bzw. vermuteten Systemkomplexität (siehe „Mathematischer Hintergrund“), was die Möglichkeit beinhaltet, diese auf ein gewünschtes Maß zu begrenzen. Besitzt die bisher gesammelte Datenmenge noch nicht die geforderte Komplexität, so werden erneut Zufallseingabedaten erzeugt und das Experiment wiederholt.

Im Ergebnis dieses Vorgehens wird aus den gesammelten Beobachtungsdaten eine Systemrepräsentation erzeugt. Neben der dynamischen Anpassbarkeit der Komplexität der Systemrepräsentation ist der entscheidende Vorteil dieses Verfahrens, dass der beschriebene Vorgang vollständig automatisiert und damit bei Bedarf autonom wiederholt werden kann.

Die gewonnene Repräsentation des Systemverhaltens kann nun analog zu dem im Beispiel „Datenbasierte Modellierung des Pendelsystems“ angedeuteten Vorgehen dazu verwendet werden, Vorhersagen zum Systemverhalten zu treffen. Ein Beispiel für die Anwendung des Verfahrens zur Lageregelung von Quadcoptern findet sich in [4].

Mathematischer Hintergrund

Der betrachtete Prozess wird als lineares und zeitinvariantes dynamisches System S beschrieben, welches m Eingabeparameter, p Ausgabegrößen und n innere Zustände besitzt und eine Differenzengleichung der Form

    \[\begin{aligned} x(k+1) &= A \, x(k) + B \, u(k) \\[0.5em] y(k) &= C \, x(k) + D \, u(k) \end{aligned}\]

mit x(k) \in \mathbb{R}^n, u(k) \in \mathbb{R}^m, and y(k) \in \mathbb{R}^p erfüllt.

Das Verhalten B des Systems ist definiert als die Menge aller Trajektorien w = (u, y), die zeitbeschränkte Version B_L, bestehend aus Trajektorien der Länge L, wird identifiziert mit einem endlich dimensionalen Vektorraum der Dimension

    \[\dim B_L = m L + n.\]

Im Rahmen des Identifikationsprozesses wird durch Beobachtung und Anregung des Systems S eine Matrix H_L gebildet, deren Spalten Trajektorien der Länge L entsprechen. Das Wissen um die Dimension von B_L ermöglicht die Einscheidung zum Stopp der Datenakquise
durch die Überprüfung, ob die bereits gesammelten Spalten von H_L einen hinreichend hochdimensionalen
Unterraum aufspannen.

Die Anzahl n der inneren Zustände des Systems S gilt als ein Komplexitätsmaß für das zu identifizierende
System und kann dazu verwendet werden, die Komplexiät der empirisch bestimmten Systemrepräsentation
H_L von B_L zu begrenzen, um die Genauigkeit der Approximation den Erfordernissen anzupassen.

Nachdem wir uns mit der Entwicklung von Systemmodellen insbesondere für den rein datengetriebenen Fall vertraut gemacht haben, werden wir uns im folgenden Artikel dem Thema Regelung zuwenden. Dabei wird speziell eine Strategie im Vordergrund stehen, die sich besonders für die Regelung hochkomplexer Systeme eignet, d. h. für Systeme mit einer großen Anzahl an Eingriffs- und Zielgrößen.

Literatur

[1] Jan C. Willems, „Paradigms and puzzles in the theory of dynamical systems“, IEEE Transactions on Automatic Control, 1991

[2] Ivan Markovsky, Linbin Huang, and Florian Dörfler, „Data driven control based on the behavioral approach – from theory to applications in power systems“, IEEE Control Systems, 2022

[3] Ivan Markovsky and Florian Dörfler, „Behavioral systems theory in data-driven analysis, signal processing, and control“, Annual Reviews in Control, 2021

[4] Ezzat Elokda, Jeremy Coulson, Paul N. Beuchat, John Lygeros, and Florian Dörfler, „Data-enabled predictive control for quadcopters“, International Journal of Robust and Nonlinear Control, 2021

Datengetriebene Prozessregelung – Teil 1

Die automatische Regelung von komplexen physikalischen Systemen stellt für Wissenschaftler und Ingenieure eine stetig wachsende theoretische wie technische Herausforderung dar. Dabei ist es zunächst unerheblich, ob diese Systeme biologische oder chemische Reaktoren, Windkraftanlagen, Stromnetze, Flugzeuge oder auch Fertigungssysteme sind. In allen diesen Anwendungsfällen treten ähnliche theoretische wie praktische Fragestellungen auf und wir wollen in diesem Artikel auf einige wesentliche näher eingehen. Bevor wir damit beginnen können, benötigen wir allerdings mehr Vorwissen.

In den nachfolgenden Ausführungen werden wir die relevanten Aspekte zumeist in beschreibender oder grafischer Form diskutieren. In entsprechend abgesetzten Abschnitten erfolgt eine stark gekürzte, skizzenhafte mathematische Beschreibung, die zumindest einen kurzen Einblick in die zugehörigen theoretischen Hintergründe geben soll.

Ein fertigungstechnisches Beispiel

Als Beispiel für ein einfaches zu regelndes System soll eine idealisierte Werkstückbearbeitung auf einer Drehmaschinedienen, wie sie in Abbildung 1 dargestellt ist.

Abbildung 1: Werkstückbearbeitung auf einer Drehmaschine

Das zu bearbeitende, rotationssymmetrische Werkstück (1) führt eine Drehbewegung aus, die es ermöglicht, unter Verwendung des Werkzeugs (2) den Durchmesser D des Werkstücks durch Materialabtrag zu verringern. Der Vorschub des Werkzeugs wird gemäß CNC Programm derart gesteuert, dass dieser Abtrag bis zum gewünschten Durchmesser D erfolgt.

Das Werkzeug ist dabei auf einer Aufnahme (3) gelagert, die einen Abstand C vom Rotationszentrum besitzt. Dieser Abstand C kann zur Kompensation der Werkzeugabnutzung angepasst werden.
Wie wir im Folgenden sehen werden, genügt dieses einfache Beispiel, um die wesentlichen Komponenten einer automatischen Regelung im nächsten Abschnitt zu identifizieren.

Grundbausteine von Regelungssystemen

Eine automatische Regelung eines Systems erfordert vier zentrale Komponenten, die zur Lösung dieser Aufgabe zur Verfügung stehen müssen. Die erste Voraussetzung stellt die Definition und automatische Erfassung von Zielgrößen dar, die einer Regelung unterzogen werden sollen. Zum Zweiten muss das System Eingriffsgrößen aufweisen, die es erlauben, diese Zielgrößen zu manipulieren. Drittens ist die Kenntnis des quantitativen Zusammenhanges der Zielgrößen mit den Eingriffsgrößen des Systems erforderlich. Viertens muss eine Strategie zur Anpassung der Eingriffsgrößen vorliegen, welche in der Lage ist, die Zielgrößen in einen a-priori festgelegten Korridor zu steuern und dort zu halten.

Abbildung 2: Grundbausteine von Regelungssystemen

Die Abbildung 2 gibt einen Überblick über die für eine automatische Regelung benötigten Grundkomponenten, die wir nachfolgend näher betrachten werden.

  • Wahrnehmung

Seit einiger Zeit werden verstärkt Messsysteme direkt in die Fertigungsanlagen und Fertigungsmaschinenintegriert. Auf diese Weise können die im Fertigungsprozess entstehenden Qualitäts- und Prozessdaten in einer Frequenz und Dichte erfasst werden, wie sie für eine effektive Regelung erforderlich ist. Neueste Forschungen versuchen darüber hinaus, diese Messsysteme durch sogenannte virtuelle Messtechnik zu ergänzen bzw. zu ersetzen. Hierbei werden Qualitätsdaten mittels eines digitalen Zwillings des Fertigungsprozesses aus Prozessdaten gewonnen.

In unserem Beispielsystem ist der Durchmesser des Werkstücks nach der Fertigung automatisch, z. B. durcheinen Laserscanner, zu erfassen. In einer komplexeren Ausbaustufe kann eine dreidimensionale Digitalisierung der Werkstückoberfläche erfolgen.

  • Regelbarkeit

Die prinzipielle Regel- oder Steuerbarkeit von Fertigungssystemen ist aus praktischen Erwägungen heraus größtenteils gegeben. Es existieren damit für Bediener:innen bereits Eingriffsmöglichkeiten an Fertigungssysteme und -maschinen zur Steuerung qualitätsrelevanter Zielgrößen. Allerdings fehlt es vielfach noch an der Automatisierbarkeit der entsprechenden Eingriffe, da diese oftmals mit sicherheitskritischen Systemen interagieren oder dieser Aspekt schlicht nicht vorgesehen war.

In unserem Beispielsystem ist der Abstand C die notwendige Eingriffsgröße. Durch Änderung von C kann die im CNC Programm hinterlegte Vorschubstrecke an den Werkzeugverschleiß angepasst werden. In der Regel muss diese Änderung aber noch vom Maschinenbediener manuell vorgenommen werden.

  • Verhalten

Für die Regelung des Systems ist das Wissen darüber notwendig, wie sich die Zielgrößen des Systems verändern, wenn die Eingriffsgrößen des Systems manipuliert werden. Diese Zusammenhänge werden in Modellen des Systemverhaltens zusammengefasst und können extrem komplex sein, weshalb dieser Aspekt der Regelung eine zentrale Herausforderung darstellt.

In unserem Beispielsystem handelt es sich um den Zusammenhang zwischen dem Abstand C und dem realisierten Durchmesser D. Offenbar ist dieser Zusammenhang linear, da sich das Werkzeug in gleicher Höhe wie die Rotationsachse befindet. Wäre dies nicht der Fall, so würde es sich um einen nichtlinearen Zusammenhang handeln.

  • Strategie

Die Regelungsstrategie hat die Aufgabe, die Zielgrößen durch Anpassung der Eingriffsgrößen zu steuern. Der Zusammenhang zwischen diesen Größen wird dabei durch das verwendete Modell hergestellt. Für die Zielgrößenliegen dafür Referenzwerte und Toleranzbereiche vor, welche im Sinne der Qualitätssicherung einzuhalten sind.

Da das Systemmodell prinzipbedingt unvollständig ist, ist es notwendig dieses im Rahmen der Regelungsstrategie durch Feedback des Systems zu adaptieren und zu korrigieren. Zusätzlich muss die gewählte Strategie robust gegenüber Störungen des Systems in Form von Änderungen nicht modellierter externer und interner Einflussgrößen sein, um sicherzustellen, dass das Regelungsziel auch unter diesen Einflüssen erreicht wird.

Eine Regelungsstrategie für unser Beispielsystem liegt zunächst auf der Hand. Sobald die automatische Messung des Durchmessers D eine Abweichung vom gewünschten Durchmesser aufzeigt, wird der Abstand C um diese Abweichung mit umgekehrten Vorzeichen korrigiert. Allerdings vernachlässigt diese Vorgehensweise Aspekte wie systematische und zufällige Messfehler, was die Robustheit der Methode einschränkt.

Wie aus den obigen Erläuterungen hervorgeht, stellen die Aspekte Verhalten und Strategie eine besondere Herausforderung dar – sowohl in praktischer wie auch in theoretischer Hinsicht. In den beiden folgenden Artikeln werden wir daher diese beiden Themen in den Mittelpunkt stellen. Dabei beschäftigen wir uns im nächsten Artikel unter anderem mit der Möglichkeit einer automatischen Modellierung hochkomplexer technischer Systeme und im letzten Beitrag mit der Entwicklung zugehöriger robuster Regelungsstrategien.