Industrielle Datenplattformen auf Microsoft Azure: Ein Entscheidungsleitfaden für die Fertigung – Teil 2: Von der Architektur zur Umsetzung und die teuersten Missverständnisse in der Praxis

Vom Azure-Stack zur tragfähigen Architektur

Im ersten Teil dieses Artikels haben wir typische Fertigungsszenarien – von KPI-Reporting über OEE-Monitoring bis zu Predictive Maintenance – auf konkrete Azure-Stacks übersetzt. Wir haben Azure-Bausteine nach Aufgabenclustern strukturiert und für drei exemplarische Stack-Kombinationen gezeigt, wie Ingestion, Speicherung, Verarbeitung und Nutzung ineinandergereifen.

Doch eine Plattform steht und fällt nicht allein mit der Tool-Auswahl. In diesem zweiten Teil widmen wir uns den Fragen, die tiefer gehen: Wann ist Edge-Verarbeitung notwendig, und wann reicht reine Cloud-Ingestion? Wo endet das, was Azure oder Microsoft Fabric bereits mitbringen, und wo beginnt die projektspezifische Entwicklung? Welche Entwicklungspraktiken sorgen dafür, dass die Plattform langfristig wartbar bleibt? Und welche Entscheidungsmuster führen immer wieder zu unnötiger Komplexität oder vermeidbaren Kosten?

Edge vs. Cloud: Die zentrale Architekturfrage

Wann reicht reine Cloud-Ingestion, wann brauchen wir Edge? Die Antwort hängt von Latenz, Netzwerkstabilität und OT-Sicherheitszonen ab. Bei täglichen Berichten, stabiler Netzanbindung und IT-seitigen Datenquellen können Sie direkt in die Cloud gehen. Aber bei strengen Latenzanforderungen, instabilen Internet-Verbindungen, harten OT-Sicherheitszonen oder hohem Datenvolumen ist Edge die bessere Wahl. Für echte Regelkreise im Millisekundenbereich bleibt die Automatisierungsebene zuständig; die Datenplattform unterstützt hier vor allem Monitoring, Auswertung und Koordination. In unserer Arbeit mit Fertigungsunternehmen erleben wir diese Entscheidung regelmäßig: Sie ist selten rein technisch, sondern berührt Sicherheitsrichtlinien, Betriebskonzepte und organisatorische Grenzen.

Für die Edge-Umsetzung gibt es im Microsoft-Ökosystem heute zwei vergleichbare Ansätze mit unterschiedlichen Schwerpunkten. Azure IoT Edge eignet sich besonders, wenn containerisierte Logik auf einzelnen Geräten oder Gateways laufen soll, etwa für lokale Vorverarbeitung, Filterung, Inferenz oder Offline-Pufferung. Azure IoT Operations ist stärker, wenn Sie auf Azure Arc und Kubernetes eine standardisierte industrielle Edge-Datenebene mit MQTT-Broker, OPC-UA-Anbindung und Datenflüssen zu Zielen wie Azure Event Hubs, Azure Data Lake Storage (ADLS) Gen2, Microsoft Fabric OneLake oder Azure Data Explorer aufbauen wollen. Was Microsoft Ihnen in beiden Fällen nicht abnimmt: die Auswahl der Protokolle, die Filterlogik, das Failover-Verhalten und die OT-Integration. Hier müssen OT, IT und Datenteam zusammenarbeiten: OT definiert Latenz- und Sicherheitsanforderungen, IT betreibt die Edge-Infrastruktur, und das Datenteam entwickelt die Verarbeitungslogik.

3D‑Grafik mit zwei gestapelten Blöcken als Vergleich von Edge- und Cloud-Szenarien: links Edge mit Beschriftungen „Millisekunden / Echtzeit“, „Instabil / Offline-Phasen“, „Strenge OT-Zonen“ und „Massen-Rohdaten“, rechts Cloud mit „Täglich / Stündlich“, „Stabil & Permanent“, „Standard IT-Netz“ und „Aggregierte KPIs“.
Abbildung 1: Gegenüberstellung wichtiger Parameter der Edge- und Cloud-Architektur 

Wo Azure schlüsselfertig ist und wo die Projektarbeit beginnt

Azure ist kein schlüsselfertiges „Industrie 4.0-Produkt“, sondern ein mächtiges Ökosystem von Bausteinen. Im PaaS-Ansatz liefert Microsoft starke Unterstützung für die Infrastruktur: Azure IoT Hub verwaltet den Gerätelebenszyklus, Azure Data Factory bringt Hunderte Standard-Konnektoren mit, ADLS Gen2 und offene Tabellenformate wie Apache Iceberg oder Delta Lake bilden ein solides Lakehouse-Fundament, Azure Data Explorer deckt interaktive Zeitreihen- und Telemetrieanalyse ab, Power BI integriert nahtlos, und Azure Monitor überwacht alles zentral. Im stärker integrierten Weg mit Microsoft Fabric übernimmt OneLake die gemeinsame Speicherbasis, Fabric Data Factory die Datenintegration, Lakehouse die Verarbeitung und Power BI die Nutzung in derselben Plattform.

Doch OT-spezifische Konnektoren brauchen oft Partner oder Individualentwicklung. Die Semantik – was bedeutet „Maschinenstatus“, welche Tags, welche Einheiten? – ist reine Projektarbeit. Das Bronze/Silver/Gold-Design, Datenverträge, Datenqualitätsprüfungen und domänenspezifische Anwendungen entwickeln Sie selbst. Microsoft nimmt Ihnen Infrastrukturarbeit ab, aber fachliche Architektur, Datenmodellierung und Governance bleiben Ihre Verantwortung.

Moderne Softwareentwicklung: Nicht optional, sondern Pflicht

Ein oft unterschätzter Aspekt: Eine industrielle Datenplattform ist Software und muss auch so behandelt werden. Ohne moderne Entwicklungspraktiken wird sie schnell unbeherrschbar. Bei ZEISS Digital Innovation vereinen wir bewusst Software-Engineering-Praktiken mit der Welt der industriellen Daten – nicht als Selbstzweck, sondern um Projekte langfristig wartbar und skalierbar zu halten.

Blau-weiße Infografik mit einem kreisförmigen Ablaufdiagramm, das verschiedene Phasen der modernen Softwareentwicklung zeigt. Im Zentrum steht der Text 'Production environment Stable and scalable'. Die Phasen sind durch Pfeile verbunden und lauten im Uhrzeigersinn: 'Code & Infrastructure as Code (IaC)', 'Test & Build', 'Staging', 'Produktion', 'Observability & FinOps', 'Feedback in der Entwicklung'. Unterhalb des Kreises sind drei verbundene Rechtecke mit den Beschriftungen 'IT-Team', 'OT Fachbereich' und 'Data & Dev-Team' angeordnet, die durch Pfeile mit dem Produktionsschritt verbunden sind.
Abbildung 2: Prinzipien der modernen Softwareentwicklung

Der Grundstein dafür ist die Automatisierung von Infrastruktur und Deployments. Statt Azure-Ressourcen manuell zusammenzuklicken, wird die gesamte Umgebung als Infrastructure as Code (IaC) (z. B. mit Bicep oder Terraform) beschrieben. So lassen sich selbst komplexe Setups für mehrere Werke konsistent und versioniert ausrollen. Hand in Hand damit geht Continuous Integration and Continuous Delivery (CI/CD) für Daten-Pipelines: Azure Data Factory Pipelines oder Azure Databricks Notebooks werden wie klassischer Code behandelt, durchlaufen automatisierte Unit- und Integrationstests mit realistischen Testdaten und wandern über saubere Staging-Umgebungen in die Produktion. Fehlerhafte Versionen lassen sich so in Minuten zurückrollen, bevor sie unbemerkt Schaden anrichten.

Sobald die Plattform produktiv läuft, schließt Observability den Kreis, und zwar in technischer wie wirtschaftlicher Hinsicht. Tools wie Azure Monitor und Azure Log Analytics überwachen nicht nur, ob Pipelines fehlerfrei laufen und Latenzen im Rahmen bleiben, sondern prüfen auch kontinuierlich die Datenqualität. Proaktive Warnungen melden Probleme, bevor Nutzer sie bemerken. Eng damit verzahnt ist die Kostenüberwachung: Azure Cost Management verfolgt Ausgaben nicht nur pauschal, sondern bricht sie mithilfe von Cost-Allocation-Tags auf Anwendungsfälle, Werke oder Fachbereiche herunter. Nur durch diese Transparenz lässt sich fundiert entscheiden, welcher Anwendungsfall wirtschaftlich sinnvoll ist und wo Optimierungen lohnen. Kostenbewusstsein wird so zum integralen Bestandteil der Plattform-Governance.

Die Rollen sind dabei klar verteilt: Die IT verantwortet Landing Zones, IaC und CI/CD-Setup. Data- und Dev-Teams entwickeln Pipelines und ML-Modelle, während die OT die Anforderungen liefert und in der Staging-Umgebung testet. Nur in diesem Zusammenspiel entsteht eine zuverlässig wartbare Plattform.

Data Governance: Kein nachgelagertes Extra

Data Governance verdient einen eigenen Artikel, aber die Kernbotschaft ist klar: Governance muss von Anfang an mitgedacht werden. Es geht um Datenhoheit (Wer ist verantwortlich?), Datenqualität (Welche Standards gelten?), Zugriffskontrolle (Wer darf was sehen?) und Compliance (DSGVO, Audit-Anforderungen).

Azure unterstützt mit Microsoft Purview für Datenkataloge und Lineage, mit Azure RBAC (Role-Based Access Control) und Microsoft Entra ID für fein granulare Zugriffssteuerung, mit Landing Zones für klare Domänen-Verantwortung und mit Azure Policy für erzwungene Standards. Gerade im Bereich industrieller Daten ist Governance kritisch: Produktionsdaten können reguliert sein (Pharma, Automotive), OT-Daten dürfen nicht in falsche Hände, und ohne Vertrauen in die Datenqualität nutzt niemand die Plattform. Azure und Microsoft Fabric liefern die Werkzeuge, aber die Governance-Strategie – Rollen, Prozesse, Standards – müssen Sie selbst definieren.

Typische Fehlentscheidungen – und was man daraus lernt

Grafik mit typischen Missverständnissen und passenden Lösungen für industrielle Datenplattformen: Links Aussagen wie „Alles in Echtzeit!“, „Wir suchen DAS Tool“, „OT & IT entscheiden getrennt“, „Azure ist nur ein Speicher“, „Governance kommt später“, „Alles für immer in Hot Storage“ und „Bloß keine Cloud-Abhängigkeit“; rechts die Gegenüberstellung der Lösungen „Batch-First Ansatz“, „Anwendungsfälle & Architektur vor Toolwahl“, „Teamwork ist entscheidend“, „Medallion & Governance“, „Governance ab Tag 1“, „Storage Tiering“ sowie „Managed Services & offene Datenformate“.

Abbildung 2: Prinzipien der modernen Softwareentwicklung

In der Zusammenarbeit mit unseren Kunden begegnen uns immer wieder ähnliche Herausforderungen. Diese zu kennen und frühzeitig anzusprechen, gehört zu unserer Rolle als Partner.

„Wir machen alles in Echtzeit“ ist ein Klassiker. Jedes Dashboard soll sofort aktualisiert sein, auch wenn tägliche Updates völlig ausreichen würden. Das Ergebnis: unnötige Komplexität, höhere Kosten, längere Entwicklungszeit. Die entscheidende Frage lautet: Welche Entscheidungen werden tatsächlich in Echtzeit getroffen? Oft ist ein Minimum Viable Product (MVP) mit Batch-Verarbeitung der bessere Start.

„Wir suchen das eine Azure-Produkt, das alles löst“ offenbart ein Missverständnis. Es gibt kein „Produkt“, sondern ein Ökosystem von Bausteinen. Eine Plattform entsteht durch Architektur, nicht durch Tool-Auswahl. Definieren Sie zuerst Anwendungsfälle und Architektur, dann wählen Sie passende Bausteine.

„OT und IT entscheiden getrennt“ führt zu Insellösungen. OT beschafft Edge-Gateways, IT baut die Cloud-Plattform, das Datenteam erfährt nichts – bis die Systeme inkompatibel sind. Industrielle Datenverarbeitung ist Teamarbeit. Gemeinsame Kickoffs, gemeinsame Architektur-Vision und klare End-to-End-Verantwortung sind essenziell.

„Azure ist nur ein Speicher“ ist der sichere Weg zum Datensumpf. Wenn Daten „irgendwie“ in ADLS Gen2 landen ohne Struktur, Transformation oder Governance, findet niemand mehr etwas. Die Medaillon-Struktur, Datenqualitätsprüfungen und ein Katalog, etwa mit Microsoft Purview, sind keine Extras, sondern Grundvoraussetzungen.

„Governance kommt später“ ist eine Illusion. Nachträgliche Governance ist deutlich schwerer als Governance von Anfang an. Definieren Sie grundlegende Rollen, Zugriffskontrollen und Benennungskonventionen vom ersten Tag an.

„Alle Daten für immer in Hot Storage“ ist eine klassische Kostenfalle. ADLS Gen2 bietet verschiedene Storage-Tiers – Hot, Cool und Archive – mit deutlich unterschiedlichen Kostenstrukturen. Wer alle historischen Daten dauerhaft im Hot-Tier speichert, verursacht unnötig hohe Speicherkosten. Definieren Sie von Anfang an: Welche Daten brauchen schnellen Zugriff, welche werden selten gebraucht, welche dienen nur der Langzeitarchivierung? Azure Lifecycle Management automatisiert dieses Tiering. Gleiches gilt für die Datenauflösung: Nicht jede historische Zeitreihe muss mit voller Auflösung gespeichert werden, Downsampling alter Daten spart Speichervolumen und damit Kosten.

„Wir wollen keine Cloud-Abhängigkeit“ klingt nach Vorsicht, führt aber oft zu teurem Mehraufwand. Wer nur VMs und Open-Source-Komponenten nutzt, verzichtet auf verwaltete Dienste und muss alles selbst betreiben – Patching, Skalierung und Monitoring. Die bessere Frage: Können wir Daten in Standardformaten halten und trotzdem von verwalteten Diensten profitieren?

Fazit: Von der Architektur zur Umsetzung

Eine industrielle Datenplattform auf Azure bedeutet nicht, ein Produkt zu kaufen, sondern eine Architektur zu entwerfen und umzusetzen. Microsoft bietet ein ausgereiftes Ökosystem von Bausteinen, das viel Infrastruktur- und Plattformarbeit abnimmt. Die Herausforderung: die richtigen Bausteine auszuwählen, sinnvoll zu kombinieren und nachhaltige Governance zu schaffen.

Die wichtigsten Prinzipien: Starten Sie vom Anwendungsfall, nicht von der Technologie. Denken Sie in Aufgabenclustern, nicht in Produktlisten. Ein PaaS-Ansatz mit einzelnen Azure-Diensten und ein integrierter SaaS-Ansatz mit Microsoft Fabric sind zwei valide Wege mit unterschiedlichen Stärken. Edge versus Cloud ist eine Architekturentscheidung, keine Tool-Frage. Microsoft liefert die Infrastruktur, nicht Fachlogik. Domänenmodell, Transformationen und Governance bleiben Ihre Verantwortung. Moderne Softwareentwicklung mit IaC, CI/CD und Tests ist Pflicht, kein Extra. Und vor allem: OT, IT und Datenteam müssen zusammenarbeiten. Industrielle Daten sind eine Gemeinschaftsaufgabe.

Genau hier setzen wir als ZEISS Digital Innovation an: Als Partner, der sowohl die Fertigungswelt als auch moderne Cloud-Architekturen versteht. Wir übersetzen zwischen OT, IT und Data, stellen die richtigen Fragen, schaffen klare Architekturen und entwickeln gemeinsam mit unseren Kunden Lösungen, die in der Praxis funktionieren und langfristig wartbar bleiben. Von den Anforderungen über die Implementierung bis zum Betrieb begleiten wir Sie auf dem Weg zu einer skalierbaren, zukunftsfähigen Datenplattform.

Industrielle Datenplattformen auf Microsoft Azure: Ein Entscheidungsleitfaden für die Fertigung – Teil 1: Vom Anwendungsfall zum Azure-Stack

Vom Konzept zur Umsetzung

In den vorangegangenen Artikeln haben wir über Architekturkonzepte für industrielle Datenplattformen gesprochen: Brownfield-Herausforderungen, Latenzklassen, Batch versus Streaming, die Medaillon-Architektur und die Frage nach Edge versus Cloud. Doch all diese Konzepte bleiben abstrakt, solange sie nicht in konkrete Technologieentscheidungen münden.

Dieser Artikel dient als Leitfaden, um die richtige technologische Basis für Ihre Fertigung zu finden. Wie übersetzen wir Architekturideen in sinnvolle Entscheidungen auf Microsoft Azure, und zwar aus der Perspektive von OT-, IT- und Datenteams? Auf Azure führen diese Fragen heute häufig zu zwei Grundrichtungen: entweder Platform as a Service (PaaS) mit einem aus Azure-Bausteinen zusammengesetzten Stack oder zu einer stärker integrierten Lösung als Software as a Service (SaaS) mit Microsoft Fabric. Keine dieser Richtungen ist per se überlegen; entscheidend sind Anwendungsfall, Betriebsmodell und vorhandene Kompetenzen. Als ZEISS Digital Innovation begleiten wir Fertigungsunternehmen genau bei dieser Transformation. Dieser Artikel ist bewusst kein Produktkatalog, sondern eine Entscheidungshilfe, die auf unseren Erfahrungen aus realen Projekten basiert. Wir starten vom konkreten Anwendungsfall, stellen die richtigen Fragen und zeigen, in welche Richtung die Antworten auf Azure führen. Dabei wird eines klar werden: Verwaltete Dienste nehmen viel Infrastrukturarbeit ab, aber die fachliche Architektur und Governance bleiben projektspezifische Aufgaben.

Ein wesentlicher Aspekt ist von Anfang an mitzudenken: die Kostenstruktur im täglichen Betrieb. Falsche Architekturentscheidungen – etwa Streaming statt Batch, fehlende Storage-Lifecycle-Policies oder unnötige Datenredundanz – führen schnell zu unerwartet hohen Cloud-Kosten. Aus unserer Projekterfahrung wissen wir: Wirtschaftlich tragfähige Architekturen entstehen, wenn Kosten von Beginn an mitgedacht und sorgfältig im Kontext des Betriebsmodell abgewogen werden.

Kurzer Rückblick: Die Grundprinzipien

Moderne Fertigungsunternehmen kämpfen mit Hunderten bis Tausenden Datenquellen in Silos. Eine industrielle Datenplattform schafft eine zentrale Infrastruktur, um diese Daten zu sammeln, zu verarbeiten und nutzbar zu machen. Dabei haben wir gelernt, dass nicht jeder Anwendungsfall Echtzeitdaten benötigt. Die Spanne reicht von Millisekunden für Prozesssteuerung bis zu Tagen für Management-Reports. Echte Regelkreise im Millisekundenbereich bleiben dabei in der Automatisierungsebene oder am Edge; die zentrale Datenplattform unterstützt vor allem Monitoring, Analyse und Koordination. Die richtige Einordnung spart Kosten und Komplexität.

Die Medaillon-Architektur strukturiert den Datenfluss: Bronze für Rohdaten, Silver für bereinigte Daten, Gold für aggregierte Business-Sichten. Und je nach Latenzanforderung und Netzwerkbedingungen entscheiden wir, ob Batch-Ingestion ausreicht oder Streaming nötig ist, ob wir am Edge vorverarbeiten oder direkt in die Cloud gehen. Mit diesem Grundverständnis können wir nun konkret werden: Wie übersetzen sich diese Prinzipien in konkrete Technologie? Für das Microsoft-Ökosystem bedeutet dies eine gezielte Auswahl passender Dienste.

Von Anwendungsfällen zu Technologieentscheidungen

Starten wir aber nicht mit Technologie, sondern mit typischen Anwendungsfällen aus der Fertigung. Die drei folgenden Szenarien sind als Ausbaustufen mit steigender Komplexität zu verstehen: von einfachem Reporting über laufendes Monitoring bis zu maschinellem Lernen (ML). In der Praxis wächst eine industrielle Datenplattform oft genau in dieser Reihenfolge. Für jeden Fall skizzieren wir zunächst den Lösungsansatz und leiten daraus später passende Technologiepfade ab.

Drei blaue, würfelförmige Infografik-Elemente stehen nebeneinander. Jedes Element ist mit einer Überschrift versehen: links 'KPI-Reporting & Management-Dashboard', mittig 'OEE-Monitoring & Live-Dashboards', rechts 'Predictive Maintenance'. Die Würfel sind in mehrere horizontale Ebenen unterteilt, die jeweils mit weißer Schrift beschriftet sind. Links lauten die Ebenen von oben nach unten: 'Dashboard', 'Historische Daten', 'Zentraler Data Lake', 'Batch-Ingestion', 'MES / ERP - Daten'. In der Mitte: 'Live-Dashboard', 'Live-Daten', 'Stream-Verarbeitung', 'Streaming-Ingestion', 'Maschinendaten'. Rechts: 'Wartungsaufträge', 'Historische + Live Daten', 'Integrierter Data Lake + ML Model Storage', 'Hybride Ingestion', 'Sensordaten'. Auf den Würfeln sind weiße Symbole abgebildet, die jeweils einen Bildschirm, ein Dashboard und ein Zahnrad darstellen. Der Hintergrund ist weiß.
Abbildung 1: Datenbasierte Anwendungsfälle aus der Fertigung 

Szenario 1: KPI-Reporting und Management-Dashboards

Zunächst betrachten wir den klassischen Fall: Mitarbeitende der Fertigung und Führungskräfte möchten tägliche oder wöchentliche Berichte über Produktionszahlen, Ausschuss und Energieverbrauch sehen. Die Datenquellen sind überschaubar, die Netzanbindung ist stabil, und eine Aktualisierung im Stunden- oder Tagesrhythmus reicht aus. Hier genügt ein klarer Batch-Ansatz: Daten werden per Batch-Ingestion übernommen, in Bronze, Silver und Gold strukturiert und anschließend für Dashboards bereitgestellt. Der Hauptaufwand liegt weniger in der Technik als in Datenmodellierung, Definition der Key Performance Indicators (KPIs) und Governance.

Szenario 2: OEE-Monitoring und Live-Dashboards

Jetzt wird es anspruchsvoller: Der Mitarbeitende im Leitstand braucht sekunden- bis minutengenaue Anzeigen von Maschinenstatus und Gesamtanlageneffektivität (Overall Equipment Effectiveness, OEE) über mehrere Produktionslinien hinweg. Hier wird Streaming relevant. Maschinendaten werden per Streaming-Ingestion aufgenommen, nahezu in Echtzeit verarbeitet und parallel für historische Analysen abgelegt. Bei instabilen Netzen oder harten OT-Sicherheitszonen empfiehlt sich zusätzliche Edge-Verarbeitung am Shopfloor. Technisch ist das beherrschbar, organisatorisch aber nur erfolgreich, wenn OT, IT und Datenteam den Ende-zu-Ende-Pfad gemeinsam verantworten.

Szenario 3: Predictive Maintenance

Predictive Maintenance vereint das Beste und Anspruchsvollste aus beiden Welten. Sie brauchen Jahre historischer Zeitreihendaten zum Modelltraining und gleichzeitig aktuelle Streams für Vorhersagen, die zurück ins Tagesgeschäft fließen, etwa als Wartungsaufträge im Computerized Maintenance Management System (CMMS). Der passende Ansatz ist hybrid: Streaming-Ingestion für aktuelle Sensordaten, historisierte Zeitreihen im Lakehouse und eine Machine-Learning-Umgebung für Training und Inferenz. Gerade hier zeigt sich der Unterschied zwischen Plattform-Bausteinen und Projektarbeit besonders deutlich: Microsoft liefert Werkzeuge, aber Modellauswahl, Merkmalsbildung und Integration ins CMMS bleiben projektspezifisch.

Azure-Bausteine: Nicht als Produktliste, sondern als Werkzeugkasten

Statt eine endlose Produktliste abzuspulen, schauen wir uns Azure-Dienste nach Aufgabenfeldern an. Das hilft, die richtige Technologie für die jeweilige Herausforderung zu finden.

Grundsätzlich ergeben sich dabei zwei gut begründbare Wege: ein PaaS-Ansatz, bei dem Sie einzelne Dienste je Aufgabenfeld kombinieren, oder ein stärker integrierter Ansatz mit Microsoft Fabric, bei dem einzelne Funktionen enger verzahnt sind. Keiner der Wege ist automatisch besser. Entscheidend sind die gewünschte Integrationsdichte, das Betriebsmodell und die Frage, wie viel Plattformkomposition Ihr Team selbst übernehmen will.

Anbindung von Datenquellen und Datenaufnahme

Wie gelangen Daten von Maschinen und Sensoren ebenso wie Daten aus Datenbanken, Dateien oder Application Programming Interfaces (APIs) in die Plattform?

Tabelle 1: Azure-Bausteine für die Anbindung von Datenquellen und die Datenaufnahme

ServiceWofür geeignet?Typische Einordnung
Azure IoT HubBidirektionale Kommunikation mit Geräten, Geräteidentitäten und GerätelebenszyklusNear-Real-Time
Azure Event HubsHochskalierendes Streaming für Millionen Events pro Sekunde, keine GeräteidentitätNear-Real-Time
Azure Event GridEvent-basierte Architekturen, MQTT-Unterstützung, Pub/SubNear-Real-Time
Azure IoT EdgeContainerisierte Logik auf Geräten oder Gateways, lokale Vorverarbeitung, Offline-FähigkeitEdge-nahe Verarbeitung
Azure IoT OperationsEdge-Datenebene auf Azure Arc/Kubernetes mit MQTT-Broker, OPC-UA-Anbindung und StreamingEdge-nahe Verarbeitung
Azure Data FactoryAnbindung von Datenbanken, Datei- und API-Quellen, auch aus On-Premises-UmgebungenHauptsächlich Batch
Partner-Lösungen (z. B. OPC UA Gateways)Protokoll-Übersetzung und Maschinenanbindung im BrownfieldAbhängig vom Setup

Für kontinuierliche Datenströme von Maschinen und Sensoren sind Azure IoT Hub, Azure Event Hubs, Azure Event Grid sowie die Edge-Dienste die naheliegenden Bausteine. Azure IoT Hub eignet sich, wenn Sie Geräteidentitäten, sichere Kommunikation und den Gerätelebenszyklus mitdenken müssen. Azure Event Hubs ist dagegen für reines Hochvolumen-Streaming ohne Geräteverwaltung gedacht. Azure Event Grid passt besonders zu MQTT- oder eventgetriebenen Architekturen. Für Edge-Szenarien gibt es heute zwei gleichwertige Wege: Azure IoT Edge passt gut zu containerisierter Logik auf einzelnen Geräten oder Gateways, Azure IoT Operations ist stärker, wenn Sie auf Azure Arc/Kubernetes standardisierte industrielle Datenflüsse mit MQTT, OPC UA und vordefinierten Cloud-Zielen aufbauen möchten.

Für die Batch-Ingestion aus Systemen wie MES, ERP, SQL-Datenbanken, Dateifreigaben, SFTP oder APIs ist dagegen Azure Data Factory meist der passendere Baustein. Mit seinen vielen Konnektoren und einer Self-Hosted Integration Runtime lassen sich auch On-Premises-Quellen in die Plattform einbinden. Damit wird deutlich: Datenaufnahme in die Plattform ist breiter als reine Gerätekommunikation. Die passende Azure-Lösung hängt von Quelle, Latenzklasse und Betriebsmodell ab.

Datenspeicherung und Aufbereitung

Wie speichern wir Daten strukturiert, versionieren sie, historisieren sie und bereiten sie für Analysen vor?

Tabelle 2: Azure-Bausteine für Datenspeicherung und Aufbereitung

ServiceWofür geeignet?Medaillon-Rolle
Azure Data Lake Storage Gen2Skalierbarer, günstiger Objektspeicher für strukturierte und unstrukturierte DatenBronze, Silver, Gold
Apache Iceberg oder Delta Lake  (z. B. auf Azure Databricks)ACID-Transaktionen, Zeitreisen, Schema-Evolution auf dem Data LakeSilver, Gold
Microsoft Fabric (OneLake und Lakehouse)Integrierte SaaS-Plattform für Speicherung, Aufbereitung, Nutzung und GovernanceBronze, Silver, Gold
Azure Data ExplorerHochperformante Analyse von Telemetrie-, Log- und ZeitreihendatenSilver, Gold
Azure SQL Database / Azure Cosmos DBRelationale oder NoSQL-Datenbanken für spezifische AnwendungsfälleGold (für Anwendungen)

Azure Data Lake Storage (ADLS) Gen2 ist der kosteneffiziente Standardspeicher für alle Daten. Ein Tabellenformat wie Apache Iceberg oder Delta Lake kommt hinzu, wenn Sie Transaktionen gemäß ACID-Prinzip (Atomicity, Consistency, Isolation, Durability) und Historisierung mit Schema-Evolution brauchen, typisch für Silver und Gold. Wenn Sie große Telemetrie- und Zeitreihendaten interaktiv analysieren wollen, ist Azure Data Explorer häufig die präzisere Wahl. Microsoft Fabric deckt diese Schicht integrierter ab: OneLake als zentrale Speicherbasis, Lakehouse für Aufbereitung und gemeinsame Datennutzung über mehrere Workloads hinweg. Das Medaillon-Modell mappt so: Bronze speichert Rohdaten unverändert, Silver bereinigt und harmonisiert in Tabellen, Gold aggregiert für Business-Sichten.

Orchestrierung und Verarbeitung

Wie steuern, transformieren und aggregieren wir Datenflüsse – im Batch oder Streaming?

Tabelle 3: Azure-Bausteine für Orchestrierung und Verarbeitung

ServiceWofür geeignet?Batch/Streaming
Azure Data FactoryOrchestrierung, ETL/ELT, viele Konnektoren, GUI-basiertHauptsächlich Batch
Azure DatabricksSpark-basiert, flexibel für Batch und Streaming, ML-WorkflowsBatch und Streaming
Azure Stream AnalyticsSQL-basiertes Streaming, einfach für einfache TransformationenStreaming
Microsoft Fabric mit Data Factory / Real-Time IntelligenceIntegrierte Orchestrierung, Eventstreams, Eventhouse und EchtzeitanalytikBatch und Streaming
Azure FunctionsServerless, ereignisgetrieben, für kleine VerarbeitungsschritteBatch und Streaming

Im PaaS-Ansatz eignet sich Azure Data Factory für klassische ETL-Jobs. Azure Databricks kommt bei komplexen Transformationen, großen Datenmengen und ML-Integration zum Einsatz. Azure Stream Analytics ist passend für einfache Streaming-Szenarien mit SQL, während Azure Functions kleine, ereignisgetriebene Aufgaben übernehmen. Beim Einsatz von Microsoft Fabric decken Data Factory und Real-Time Intelligence große Teile dieser Aufgaben in einer Plattform ab, von der Ingestion über Eventstreams bis zur Analyse in Eventhouse oder Power BI.

Nutzung und Integration

Wie machen wir Daten für Endnutzer und Anwendungen zugänglich?

Tabelle 4: Azure-Bausteine für Nutzung und Integration

ServiceWofür geeignet?
Power BIBusiness Intelligence, Dashboards, Reports, Datenanalyse in Fachbereichen
Azure API ManagementAPIs bereitstellen, absichern, monitoren, versionieren
Azure Digital TwinsDigitale Zwillinge für komplexe Anlagen, Raum- und Prozessmodelle
Azure App Service / Azure Container AppsWeb-Apps, individuelle Benutzeroberflächen, Microservices

Power BI ist oft die Standardwahl für Dashboards. Bei Microsoft Fabric ist es direkt in der Plattform eingebettet. Azure API Management eignet sich für das Bereitstellen von Daten und ML-Modellen als APIs. Azure Digital Twins ist sinnvoll, wenn Sie Anlagen, Räume oder Prozessbeziehungen semantisch modellieren wollen. Azure App Service oder Azure Container Apps kommen ins Spiel, wenn individuelle Anwendungen oder Microservices benötigt werden.

Technologie-Stack-Beispiele

Um die Theorie greifbar zu machen, folgen drei konkrete Stack-Beispiele zu den eingangs dargestellten Szenarien. Jedes Beispiel zeigt zunächst den PaaS-Ansatz und eine mögliche Alternative mit Microsoft Fabric.

Drei farbige, quaderförmige Stapel stehen nebeneinander. Jeder Stapel besteht aus mehreren unterschiedlich beschrifteten Ebenen, die verschiedene Software- und Cloud-Dienste benennen. Die linke Säule trägt die Überschrift 'KPI-Reporting & Management Dashboard' und enthält unter anderem 'Power BI', 'Azure Data Lake Storage Gen 2 (ADLS)', 'Synapse', 'Integration', 'Azure Data Factory'. Die mittlere Säule ist mit 'Near-RealTime OEE' überschrieben und zeigt unter anderem 'Power BI', 'Azure Stream Analytics / Databricks Structured Streaming', 'Azure IoT Hub oder Event Hubs'. Die rechte Säule trägt die Überschrift 'Predictive Maintenance' und listet unter anderem 'Azure API Management', 'Azure Functions / Stream Analytics', 'Azure Databricks / Azure Machine Learning', 'ADLS Gen 2', 'Azure IoT Hub' auf. Die Ebenen sind jeweils farblich abgesetzt. Die Grafik stellt eine Vergleichsübersicht verschiedener Cloud-Architekturen dar.
Abbildung 2: Beispiele für den Technologie-Stack typischer Anwendungsfälle aus der Fertigung

Beispiel 1: Minimaler Stack für Reporting

Anforderungen:

  • Tägliche KPI-Berichte für ein Werk
  • Datenquellen: MES-Datenbank (SQL), ein paar CSV-Exporte
  • Nutzer: Management, Controlling
  • Latenz: Tägliche Aktualisierung ausreichend

Azure-Stack:

  1. Ingestion: Azure Data Factory mit SQL-Konnektor und Blob-Konnektor, bei On-Premises-Quellen meist über Self-Hosted Integration Runtime
  2. Speicher: ADLS Gen2
    1. Bronze: Rohdaten aus SQL und CSV
    1. Silver: Bereinigte Daten (z. B. Zeitstempel normalisiert, Duplikate entfernt), Apache Iceberg als Tabellenformat
    1. Gold: Aggregierte KPIs (z. B. gefertigte Teile pro Linie, Ausschuss pro Produkt)
  3. Transformation: Azure Data Factory mit visuell entworfenen Datentransformationen (Mapping Data Flows) oder einfache Kopieraktivitäten
  4. Nutzung: Power BI liest direkt aus Gold-Layer

Alternative mit Microsoft Fabric: Fabric Data Factory lädt die Daten nach OneLake, ein Lakehouse bildet Bronze, Silver und Gold ab, und Power BI greift direkt auf dieselbe Plattform zu. Dieser Weg ist besonders dann attraktiv, wenn Datenintegration, Governance und BI möglichst eng in einer SaaS-Umgebung verzahnt sein sollen.

Hinweis: Dieser Stack ist nahezu schlüsselfertig. Der Hauptaufwand liegt in der Datenmodellierung, der Definition von KPIs und der Governance (Wer darf welche Daten sehen?).

Beispiel 2: Near-Real-Time OEE für mehrere Linien

Anforderungen:

  • Sekunden- bis minutenaktuelle Anzeige von Maschinenstatus und OEE
  • Mehrere Produktionslinien, unterschiedliche Maschinentypen
  • Anzeige im Leitstand auf großen Monitoren
  • Einfache Alarmierung bei Störungen

Azure-Stack:

  1. Ingestion: Azure IoT Hub oder Azure Event Hubs
    1. OPC UA Gateway sammelt Daten von Maschinen und sendet an Azure IoT Hub
  2. Edge (optional): Azure IoT Edge oder Azure IoT Operations
    1. Azure IoT Edge für lokale Vorverarbeitung, Filterung und Pufferung bei Netzwerkausfall
    1. Azure IoT Operations für standardisierte Datenflüsse auf Azure Arc/Kubernetes
  3. Streaming: Azure Stream Analytics oder Structured Streaming in Azure Databricks
    1. Berechnet OEE in nahezu Echtzeit, schreibt in ADLS Gen2 (Bronze/Silver)
  4. Speicher: ADLS Gen2 mit Apache Iceberg für Silver/Gold
  5. Nutzung: Power BI mit Echtzeitstreaming oder individuellen Dashboards (z. B. React App)

Alternative mit Microsoft Fabric: Real-Time Intelligence übernimmt Ingestion, Eventstreams und Echtzeitanalyse, während OneLake und Eventhouse die Datenbasis bilden. Power BI oder Real-Time-Dashboards visualisieren die Ergebnisse. Das ist besonders interessant, wenn Streaming, Analyse und Visualisierung in einer Plattform zusammengeführt werden sollen.

Hinweis: Azure bringt Streaming- und Visualisierungsbausteine mit, aber die Edge-Architektur (Filterlogik, Offline-Handling) und die OEE-Berechnungslogik sind projektspezifisch. OT muss Maschinen anbinden, IT muss Edge-Infrastruktur betreiben, das Datenteam muss die Streaming-Logik entwickeln.

Beispiel 3: Predictive Maintenance mit ML

Anforderungen:

  • Vorhersage von Lagerausfällen basierend auf Vibrationsdaten
  • Historische Daten über 2 Jahre nötig für Modelltraining
  • Aktuelle Streaming-Daten für Vorhersagen
  • Vorhersagen sollen ins CMMS fließen

Azure-Stack:

  1. Ingestion: Azure IoT Hub für Vibrationssensoren
  2. Speicher: ADLS Gen2 mit Apache Iceberg
    1. Bronze: Rohdaten (Vibration, Temperatur, etc.)
    1. Silver: Bereinigte Zeitreihen, Merkmalsbildung für ML
    1. Gold: Aggregierte Features für ML-Training
  3. ML: Azure Databricks oder Azure Machine Learning
    1. Modelltraining mit historischen Daten (Silver/Gold)
    1. Modell-Deployment als REST-API (z. B. über Azure Machine Learning Endpoints oder Model Serving in Azure Databricks)
  4. Streaming für Inferenz: Azure Functions oder Azure Stream Analytics ruft Modell-API auf
  5. Integration: Azure API Management stellt Vorhersagen für CMMS bereit
  6. Optional: Azure IoT Edge oder Azure IoT Operations bringt Modell oder Vorverarbeitung lokal an die Anlage

Alternative mit Microsoft Fabric: Microsoft Fabric kombiniert OneLake, Data Engineering, Data Science und Power BI in einer Plattform. Für Streaming-nahe Analysen kann Real-Time Intelligence die aktuellen Daten aufnehmen, während Modelle auf den historischen Daten in OneLake trainiert und ausgewertet werden. Wenn Vorhersagen sehr nah an der Anlage entstehen müssen, bleibt der Edge-Teil weiterhin eine eigenständige Architekturentscheidung.

Hinweis: Hier wird der Unterschied zwischen Plattform-Bausteinen und individueller Entwicklung besonders deutlich. Azure liefert ML-Tools, APIs und Bereitstellungsmechanismen, aber das Modell selbst, die Auswahl passender Datenmerkmale, das Konzept zum erneuten Trainieren des Modells und die Integration ins CMMS sind reine Projektarbeit. Ein enger Austausch zwischen Data-Science-Fachleuten, OT und IT ist dabei essenziell.

Zwischenfazit: Vom Anwendungsfall zum Azure-Stack

Die drei Szenarien und der Azure-Werkzeugkasten verdeutlichen: Es gibt keine universelle Antwort auf die Frage, welcher Stack der Richtige ist. Entscheidend ist, konsequent in aktuellen und insbesondere zukünftigen Anwendungsfällen zu denken. Latenzanforderungen, Datenvolumen, Nutzergruppen und organisatorische Rahmenbedingungen bestimmen, welche Kombination aus Ingestion, Speicherung, Verarbeitung und Visualisierung sinnvoll ist.

Microsoft stellt dafür zwei belastbare Richtungen bereit: den komponierten Azure-PaaS-Weg mit Diensten wie Azure IoT Hub, Azure Event Hubs, Azure Data Factory, ADLS Gen2, Azure Data Explorer oder Power BI, und den stärker integrierten SaaS-Weg über Microsoft Fabric mit OneLake, Data Factory, Real-Time Intelligence und Power BI in einer Plattform. Die vorgestellten Stack-Beispiele zeigen typische Einstiegspunkte – vom minimalen Batch-Reporting bis zum ML-getriebenen Predictive-Maintenance-Setup.

Doch mit der Wahl des richtigen Stacks ist es nicht getan. Im zweiten Teil dieses Artikels gehen wir auf die Fragen ein, die über den reinen Tool-Einsatz hinausgehen: Wann brauchen Sie Edge-Verarbeitung, wann reicht die Cloud? Wo hören die verwalteten Dienste auf, und wo beginnt die eigentliche Projektarbeit? Wie gestalten Sie Governance, moderne Softwareentwicklung und Betrieb so, dass die Plattform langfristig tragfähig bleibt? Und welche Fehlentscheidungen sollten Sie von Anfang an vermeiden?



Rückschau zum Thin[gk]athon „Taking Virtual Shopfloor to the Next Level“

Wie bringt man eine physische Produktionshalle in die digitale Welt? Diese Frage stand im Mittelpunkt des Thin[gk]athons, mit ZEISS Digital Innovation und Volkswagen Sachsen als Challenge-Owner. Das Co-Innovations-Format des Smart Systems Hubs schafft den methodischen Rahmen, um hochaktuelle Herausforderungen gemeinschaftlich zu bewältigen. Diesmal lautete das Motto „Taking Virtual Shopfloor to the Next Level“ und lud ambitionierte Köpfe mit unterschiedlichem fachlichem Hintergrund ein, gemeinsam die Grenzen der Digitalisierung auszuloten. Das Ergebnis: interdisziplinäre Teams, in denen frische Perspektiven auf vielfältige Erfahrungen trafen, um innovative Lösungen zu entwickeln.

Die Herausforderung: Digitalisierung greifbar machen

Im Zentrum der Challenge stand die Aufgabe, reale Produktionsdaten in eine virtuelle 3D-Welt zu überführen – interaktiv, skalierbar und praxisnah. Die Teams mussten gescannte Produktionsumgebungen, die aus Punktwolken und Bildern bestanden, mit digitalen Produktpässen verknüpfen. Konkret bedeutete das: QR-Codes in den 3D-Scans autonom zu erkennen und mit Informationen aus der Asset Administration Shell (AAS) zu verbinden. Das Ziel war eine begehbare, interaktive 3D-Szene, die nicht nur die Umgebung visualisiert, sondern auch Daten bereitstellt und Prozesse optimiert. Um die Ergebnisse übertragbar zu machen, wurde ein generischer Ansatz gewählt.

26.06.2025, Dresden, Thin[gk]athon, ZEISS Digital Innovation, Smart Systems Hub, Volkswagen Sachsen

Teamwork als Innovationsmotor

Die Teams, bestehend aus Teilnehmenden mit unterschiedlichstem fachlichen Hintergrund, bewiesen, wie wertvoll das Format ist. Durch die Kombination von Wissen aus IT, Produktion, Design und Wissenschaft entstanden neue Ideen, die konventionelle Denkweisen durch frische Impulse ersetzten. Auch unsere Kollegen Pawel Adaszewski und Gergely Honti von ZEISS Digital Innovation unterstützten die Teams mit ihrer Expertise in Softwareentwicklung und ihren Erfahrungen auf dem Shopfloor. Am Ende präsentierten alle Teams innerhalb von nur drei Tagen praxistaugliche Konzepte und skizzierten mögliche nächste Schritte für den Aufbau eines interaktiven und skalierbaren digitalen Zwillings.

Technologischer Deep Dive: Eine Herausforderung in drei Dimensionen

Die wahre Komplexität der Challenge zeigte sich in den Rohdaten. Die Datensätze lagen als sogenannte 3D Gaussian Splats vor – eine moderne Methode, aus Fotos fotorealistische Szenen zu rendern. Das Resultat: eine riesige und oft unsaubere Punktwolke, die zuerst von Rauschen gefiltert werden musste.

Einige Teams versuchten, die Dichte der Punktwolke mit dem K-Nearest-Neighbors-Algorithmus (KNN) zu analysieren, mussten diesen Ansatz aber wegen der enormen Datenmenge schnell verwerfen. Erfolgreicher war eine boxbasierte Methode, die den Raum in ein Voxel-Gitter aufteilte – man kann sich dies wie eine Aufteilung in kleine Würfel vorstellen. Durch die Berechnung der Punktdichte in jedem Würfel konnten Maschinencluster schnell und effizient isoliert werden.

Die größte Hürde blieb die Detektion der QR-Codes. Die entscheidende Erkenntnis war, dass die 3D-Scans nur die Oberflächen der Objekte abbilden. Statt den gesamten 3D-Raum zu durchsuchen, konnten die Teams die gerenderte Oberfläche gezielt nach Bereichen mit hohem Schwarz-Weiß-Kontrast absuchen. Doch die praktische Umsetzung war steinig: Versuche, die gefundenen Kontrast-Hotspots mit Python-basierten 3D-Renderern zu visualisieren, scheiterten an Software-Konflikten und Bugs. Der Durchbruch gelang schließlich durch einen pragmatischen Wechsel zur Unity-Engine. Mittels WebGL-Rendering wurde die virtuelle Kamera an die berechneten Koordinaten bewegt, um die QR-Codes zu finden und auszulesen.

Nach der Vorverarbeitung wurde eine räumliche Beziehung zwischen den QR-Codes und den zugehörigen Maschinen hergestellt. Diese räumliche Beziehung wurde genutzt, um Daten aus der Asset Administration Shell (AAS) für den Nutzer zu beziehen und in einer interaktiven Nutzeroberfläche darzustellen. Ein mögliches Frontend erlaubte es den Nutzern, sich interaktiv in der Punktwolke zu bewegen und die relevanten Informationen zu erkunden.

Die Lösung des Gewinnerteams

Das Siegerteam der Professur Informationsmanagement der HTW Dresden – bestehend aus Stefan Vogt, Robert Pampuch, Johannes Metzler, Felix Fritzsche und Paul Patolla  –  überzeugte mit einer funktionierenden Lösung, die zugleich den Wettbewerb für sich entschied. Für sie waren es drei intensive Tage voller Technologie, Austausch und praxisnaher Entwicklung.

„Diese Veranstaltung bringt die Herausforderungen der Wirtschaft und das Wissen aus der Forschung zusammen und zeigt, wie man in kurzer Zeit gemeinsam überzeugende Lösungen entwickeln kann.“ sagt Paul Patolla von der HTW Dresden.
Abbildung 1: Oberfläche in der Verwaltungsschale

Die technische Verarbeitung ihrer Lösung basierte auf mehreren Schritten. Zunächst wurden Videodateien in Einzelbilder zerlegt, um in jedem Frame QR-Codes mitsamt Positionsinformationen zu identifizieren. Hierfür setzten sie insbesondere die Python-Bibliothek OpenCV ein, die eine effiziente Bildaufbereitung und robuste QR-Code-Erkennung ermöglichte. Parallel dazu nutzte das Team das Verfahren des Gaussian Splatting, basierend auf der wissenschaftlichen Veröffentlichung von Kerbl et al., um aus den Bilddaten eine realitätsnahe Punktwolke zu erzeugen. Dies ermöglichte die präzise Verortung der QR-Codes in einem dreidimensionalen Kontext.

Zur Visualisierung wurde Babylon.js eingesetzt, wodurch die Ergebnisse als WebXR-Anwendung direkt im Browser (und optional in VR) erlebbar wurden. Ergänzend kam NVIDIA Omniverse zur Generierung von Texturen zum Einsatz, um die visuelle Qualität der Darstellung deutlich zu steigern. Auf diese Weise entstand eine durchgängige Lösung, die Datenanalyse und immersive 3D-Visualisierung intelligent verband und den klaren Bezug zur Praxis demonstrierte.

Abbildung 2: Screenshot der Lösung des Gewinnerteams

Fazit und Ausblick

Eine Fachjury aus Expertinnen und Experten von Industrie und Wissenschaft bewertete die Konzepte nach technischer Tiefe, Umsetzbarkeit und Teamarbeit. Die Teams setzten ein starkes Zeichen für gesellschaftliches Engagement, indem sie ihr Preisgeld von 2.000 € an gemeinnützige Organisationen spendeten.

Links: Gewinnerteam „Punkt Pioniere“, rechts: Teilnehmende und Jury v.l.n.r. Prof. Marius Brade (Fachhochschule Dresden), Dr. Stefan Feldmann (Zeiss), Dr. Dirk Thieme (Volkswagen Sachsen), Daniel Beltz (Sachsenmilch), Leonid Dendya (Volkswagen)

Der Thin[gk]athon hat einmal mehr bewiesen, dass die Digitalisierung der Produktion kein Selbstzweck ist, sondern ein wirksames Werkzeug. Sie ermöglicht effizientere Prozesse und datenbasierte Entscheidungen, die nachhaltige Mehrwerte für den Shopfloor schaffen. Der Schlüssel zum Erfolg liegt im strukturierten Data Enablement und dem gezielten Einsatz vorhandener Produktionsdaten.

Die entwickelten Konzepte zeigen eindrucksvoll, wie durch die Kombination aus Technologie, Teamgeist und methodischer Begleitung komplexe Herausforderungen gelöst werden können. Wir freuen uns darauf, Formate dieser Art fortzuführen und den Austausch gemeinsam weiter voranzutreiben.

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.

Alle Beiträge des Autors anzeigen

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.

Kinematische Simulation für Anfänger

Einleitung

Kundenindividuelle Massenproduktion, demografischer Wandel, Arbeitskräftemangel und Verlagerung von Produktionsstätten sind einige der globalen Herausforderungen, mit denen produzierende Unternehmen weltweit konfrontiert werden. Folglich verlangen Produktionsstandorte in Hochlohnländern nach hochautomatisierten und flexiblen Produktionssystemen, um wettbewerbsfähig zu bleiben. Industrieroboter und Sondermaschinen haben sich bei der Bewältigung einiger dieser Herausforderungen als wichtige Hilfsmittel und Wegbereiter erwiesen. Die flexible Programmierung solcher Fertigungssysteme ermöglicht es, Aufgaben wie Handhabung, Transport und verschiedene Produktionsprozesse automatisch mit hoher Präzision, Geschwindigkeit und Qualität durchzuführen.

Zwar wurden die Vorteile solcher Produktionssysteme vielfach nachgewiesen, es ist jedoch zu beachten, dass ein erheblicher Integrations- und Programmieraufwand erforderlich ist, bevor diese Systeme produktiv eingesetzt werden können. In den meisten Fällen erfordert die Softwareentwicklung für Produktionssysteme den Einsatz physischer Komponenten unter realen Bedingungen. Die Verfügbarkeit solcher Systeme ist jedoch häufig aus verschiedenen Gründen eingeschränkt, beispielsweise weil das System in Betrieb ist, parallel entwickelt wird oder im schlechtesten Falle überhaupt nicht existiert. Dieses Problem führt dazu, dass die Entwicklung der Software verzögert oder aufgeschoben wird, bis die erforderlichen physischen Komponenten verfügbar und integriert sind. Zudem gilt die Programmierung eines Industrieroboters als eine nicht gerade triviale Aufgabe, die qualifizierte Bedienende mit einem guten räumlichen Verständnis des Arbeitsbereichs und mit Fachkompetenz erfordert. Die Herausforderung besteht darin, eine Bewegungssequenz zu programmieren, die den Ablauf des Produktionsprozesses und die Prozessqualität sicherstellt und gleichzeitig Kollisionen vermeidet. Deshalb wird die Programmierung von Industrierobotern heutzutage häufig noch manuell durchgeführt und gilt als eine anspruchsvolle und ressourcenintensive Aufgabe.

Die Probleme der Roboterprogrammierung sind auf einer abstrakteren Ebene auch bei der Softwareentwicklung in anderen Bereichen anzutreffen. Es stellt sich also folgende Frage: Wie gehen Softwareentwickler mit diesen Problemen um, wenn es zum Beispiel keine Module oder Schnittstellen gibt? Die Antwort: Wir erstellen Mock-ups! In gewisser Weise sind Mock-ups nichts anderes als Modelle, die eine gewünschte Funktion simulieren. Allerdings klingt die Modellierung eines Roboters ein wenig komplizierter als die Implementation einer Datenbank oder einer Schnittstelle. Dieser Blogartikel soll das Gegenteil beweisen und zeigt in einem kurzen Tutorial, wie man kinematische Simulationsmodelle einfach und effizient erstellen kann, um die Programmierung solcher Fertigungssysteme zu erleichtern.

Dieser Blogbeitrag soll den Lesern Folgendes vermitteln:

  • Grundlegendes Verständnis von kinematischen Simulationsmodellen
  • Die Möglichkeit, ein einfaches kinematisches Modell eines Manipulators (z. B. Roboter, Drehtisch, Linearachsen) basierend auf freier und Open-Source-Software (FOSS) zu erstellen, das für Prototyping-, Entwicklungs- und Testzwecke verwendet werden kann

Kinematische Modellierung

Bezugssystem

Im Vorfeld der Simulation der Kinematik eines Robotersystems müssen zunächst einige grundlegende mathematische Konzepte und die im Zusammenhang mit der kinematischen Modellierung genutzte Terminologie verstanden werden. Zu diesem Zweck betrachten wir zunächst ein minimales System, das aus einem Drehgelenk \(j_1\) und eine Achse \(l_1\) besteht.

Die Achse ist starr mit dem Gelenk verbunden. Das bedeutet, wenn das Gelenk um seine z-Achse (Frame \(B_{j_1}\)) um einen Winkel von \(\phi_{j_1}\) rotiert, dreht sich die Achse \(l_1\) mit. Gehen wir hier davon aus, dass sich der Ursprungskoordinatenframe des Systems im Basiskoordinatenframe bei \(B_0\) befindet. Darüber hinaus beschreibt der Vektor \(p_0^w := (x, y, z, a^x, \beta^y, \phi^z)^T\) die Pose (Position und Rotation) der Achse im Arbeitsframe \(B_w\). Das kinematische 2D-Modell eines solchen Systems und seiner Komponenten ist links in Abbildung 1 dargestellt.

kinematisches Modell
Abbildung 1: Einfaches kinematisches Modell mit einem Drehgelenk und einer Achse

Kinematisches Modell

Wenn wir davon ausgehen, dass wir einige Bewegungen programmieren oder simulieren müssen, werden wir zwangsläufig mit mindestens einem der folgenden Probleme konfrontiert:

  • Inverskinematik-Problem: Welcher Winkel \(\phi_{j1}\) entspricht einer aktuellen Pose \(p_0^{w,act}\)?
  • Vorwärtskinematik-Problem: Welches ist die resultierende Pose \(p_0^w\) für einen gegebenen Gelenkwinkel \(\phi_{j1}^{act}\)?

Diese Fragen werden auf der rechten Seite von Abbildung 1 visualisiert und stellen die grundlegenden Probleme der kinematischen Modellierung dar, die als Inverskinematik- und Vorwärtskinematik-Probleme bezeichnet werden. Um diese Fragen zu beantworten, müssen zunächst alle räumlichen Beziehungen zwischen allen aufeinanderfolgenden[1] Frames des Systems abgeschätzt werden. Das heißt von der Basis \(B_0\) zum Gelenk \(B_{j1}\) und vom Gelenk \(B_{j1}\) zum Arbeitsframe \(B_w\). Die relativen räumlichen Beziehungen[2] zwischen zwei Frames werden durch die Translationskomponenten \(x_{\Delta}, y_{\Delta}\), und \(z_{\Delta}\) und die Rotationskomponenten \(\alpha_{\Delta}^x\), \(\beta_{\Delta}^y\), und \(\phi_{\Delta}^z\) modelliert. In Tabelle 1 sind die geometrischen Beziehungen für alle aufeinanderfolgenden Frames des kinematischen Systems von Abbildung 1 angegeben.

Base FrameReference FrameTranslationRotation
Basis \(B_0\)Gelenk \(B_{j_1}\)\(x_{\Delta}\) = 0, \(y_{\Delta}\) = 0, \(z_{\Delta}\) = \(d_0\)\(\alpha_{\Delta}^x\) = 0, \(\beta_{\Delta}^y\) = 0, \(\phi_{\Delta}^z\) = \(\phi_{j_1}\)
Gelenk \(B_{j_1}\)Arbeitsframe \(B_w\)\(x_{\Delta}\) = \(a_1\), \(y_{\Delta}\) = 0, \(z_{\Delta}\) = \(d_0\)\(\alpha_{\Delta}^x\) = -90°, \(\beta_{\Delta}^y\) = 0, \(\phi_{\Delta}^z\) = 0
Tabelle 1: Kinematische Beziehungen

Nachdem wir nun die geometrischen Beziehungen unseres Systems definiert haben, kann das kinematische Modell, mithilfe dessen die vorhergehenden Fragen beantwortet werden, beschrieben werden. Das Vorwärtskinematik-Model, dass die resultierende Pose für einen angeordneten Gelenkwinkel liefert, könnte beispielsweise mithilfe der in Abbildung 2 dargestellten trigonometrischen Beziehungen abgebildet werden.

Abbildung 2: Trigonometrische Beziehungen im Bezugssystem

\(x_0^w\) = \(a_1 \cos (\phi_{j1})\)

\(y_0^w\) = 0

\(z_0^w\) = \(d_0 + a_1 \sin (\phi_{j_1})\)

Obwohl diese geometrischen Funktionen die Kinematik unseres Bezugssystems ausreichend modellieren, ist hierbei zu beachten, dass die Beschreibung des kinematischen Modells auf diese Weise für komplexere Systeme mit mehreren Gelenken und Achsen nicht so einfach ist. Aus diesem Grund werden zur Berechnung von Mehrkoordinatentransformationen in der Regel andere mathematische Ansätze genutzt, z. B. homogene Matrizen oder Quaternionen. Die Beschreibung dieser Methoden würde den Rahmen dieses Blogbeitrags sprengen. Für den Rest des Artikels ist es ausreichend zu wissen, welche Eingaben und Ausgaben wir von einem kinematischen Modell erwarten können. Diese Modelle können als Black-Box-Komponenten angenommen werden, wie in Abbildung 3 dargestellt.

Vorwärtskinematik- und Inverskinematik
Abbildung 3: Vorwärtskinematik- und Inverskinematik-Black-Box-Modelle

Implementierung

Nach der Einführung der zentralen Konzepte der kinematischen Modellierung wird eine einfache Möglichkeit zur Implementierung kinematischer Ketten vorgestellt.

In der Industrie gibt es bereits eine Reihe von Spezifikationen und Formaten, die sich mit der Modellierung von kinematischen Ketten befassen, z. B. Collada, AutomationML, OPC UA Robotics. Unserer Erfahrung nach hat sich jedoch kein branchenweites Standardformat durchgesetzt. Dies stellt ein umfassenderes Problem auf dem Gebiet der Robotik dar, wo Programmiersprachen hauptsächlich herstellerspezifisch sind und es keine Standards für die Roboterprogrammierung oder -modellierung gibt. Dies ist einer der Gründe, weshalb das Robot Operating System (ROS) im Jahr 2010 ins Leben gerufen wurde. ROS ist eine FOSS-Robotik-Middleware, die verschiedene Bibliotheken (z. B. kinematische Modellierung, Wahrnehmung, Visualisierung, Bahnplanung) für die hardwareunabhängige Programmierung von Robotersystemen enthält. Diese Eigenschaften haben ROS zu einem Framework gemacht, das in der Robotikforschung als Stand der Technik gilt. Aufgrund der Beliebtheit und der Merkmale des ROS-Frameworks (z. B. Leistungsfähigkeit, Hardwareneutralität, FOSS, Modularität, Skalierbarkeit) haben Hersteller von Robotern und Feldgeräten (z. B. Greifer und Sensoren) sowie Drittanbieter von Software begonnen, Programmierschnittstellen für ROS anzubieten.

Im Rahmen der Entwicklung von ROS wurde das Unified Robot Description Format (URDF) zur Modellierung von kinematischen Ketten eingeführt. Beim URDF handelt es sich um ein offenes Standard-XML-Schema zur Beschreibung der geometrischen Beziehungen zwischen Gelenken und Achsen eines Roboters. Zusätzlich zur Modellierung kinematischer Ketten bietet das URDF die Möglichkeit, die physikalischen Eigenschaften von Gelenken zu modellieren (z. B. Trägheit, Dynamik und Achsenbegrenzungen) oder CAD-Dateien zur Modellierung der Volumeneigenschaften von Achsen zu verwenden, die für Kollisionstests genutzt werden können. Da das URDF einem XML-Schema folgt, können kinematische Modelle darüber hinaus einfach und lesbar dargestellt werden. So beschreibt der folgende Auszug in Abbildung 4 beispielsweise die kinematischen Beziehungen zwischen dem Gelenk j1 und der Achse l1 aus Tabelle 1.

Nachdem die geometrischen Beziehungen zwischen allen Achsen und Gelenken mithilfe einer URDF-Datei beschrieben wurden, kann das kinematische Modell visualisiert und zur Berechnung von Endeffektorpositionen oder erforderlichen Gelenkrotationen genutzt werden. ROS enthält eine Handvoll Pakete basierend auf Bibliotheken von Drittanbietern, die alle diese Funktionen implementieren. Die Verwendung dieser Bibliotheken ist in der ROS-Dokumentation beschrieben.

<!--Alle Achsen unseres Modells.-->
<!--Das Root-Frame in ROS wird base_link genannt und repräsentiert das Root-Frame (B_0) in unserem System. -->
<link name="base_link"/>
<!--Achse 1 unseres Modells. -->
<link name="link_1"/>
<!-- Der Arbeitsframe unseres Modells wird als Achse dargestellt.-->
<link name="work_frame"/>

<!--Alle Gelenke unseres Modells.-->
<!--Das Drehgelenk 1, das die Basisachse (parent-Achse) mit Achse 1 (child-Achse) verbindet, wird hier modelliert.
Das Gelenk befindet sich im Ursprung der child-Achse.-->
<joint name="joint_1" type="revolute">
	<parent link="base_link"/>
	<child link="link_1"/>
<!-- Auswahl der Rotationsachse, in unserem Fall um das Gelenk um die z-Achse in positiver Richtung.-->
	<axis xyz="0 0 1"/>
<!-- Hier wird die Transformation zwischen parent- und child-Achse angegeben.-->
<!-- Die Translationskomponenten (xyz) werden in Metern angegeben. -->
<!-- Die Rotation wird durch die Euler-Winkel (rpy) in Radianten ausgedrückt, und zwar nach folgender
 Notation (r)oll (x-Achsen-Rotation), (p)itch (y-Achsen-Rotation) und (y)aw (z-Achsen-Rotation). -->
	<origin xyz="0 0 0,4" rpy="1,57079632679 0,0 0,0"/>
<!-- Das Modell eines beweglichen Gelenks muss weitere physikalische Eigenschaften umfassen. -->
	<limit effort="100" lower="-0,175" upper="3,1416" velocity="0,5"/>
</joint>

Abbildung 4: URDF-Auszug zur Beschreibung der kinematischen Beziehung zwischen Gelenk \(j_1\) und Achse \(l_1\)

Erweitertes System

Nachdem die Grundlagen der kinematischen Modellierung und die Verwendung von URDF zur Implementierung eines kinematischen Modells verstanden wurde, steht der Beschreibung komplexerer kinematischer Ketten mit mehreren Gelenken, wie in Abbildung 5 dargestellt, nichts mehr im Wege.

Abbildung 5: Erweitertes kinematisches Modell unter Berücksichtigung eines Schub- und eines Drehgelenks

Die entsprechenden geometrischen Beziehungen sind in Tabelle 2 angegeben. Darüber hinaus ist das vollständige URDF im Anhang zu finden.

Base FrameReference FrameTranslationRotation
Basis \(B_0\)Gelenk \(B_{j_1}\)\(\Delta x\) = \(a_{j_1}\), \(\Delta y\) = 0, \(\Delta z\) = \(d_0\)\(\alpha_x\) = 0, \(\beta_y\) = 0, \(\phi_z = 0\)
Gelenk \(B_{j_1}\)Gelenk \(B_{j_2}\)\(\Delta\)x = \(a_2\), \(\Delta y\) = 0, \(\Delta z\) = 0\(\alpha_x\) = 90°, \(\beta_y\) = 0, \(\phi_z\) = 0
Gelenk \(B_{j_2}\)Arbeitsframe \(B_w\)\(\Delta\)x = \(a_3\), \(\Delta y\) = 0, \(\Delta z\) = 0\(\alpha_x\) = -90°, \(\beta_y\) = 0, \(\phi_z\) = 0
Tabelle 2: Kinematische Beziehungen im erweiterten System

Das URDF kann anschließend direkt in ROS zur Visualisierung und Positionierung von Gelenken verwendet werden, wie in Abbildung 6 dargestellt.

Gelenk1: \(a_{j_1}\) = -170mm, Gelenk2: \(\phi_{j_2}\) = -48°

Gelenk1: \(a_{j_1}\) = 80mm, Gelenk2: \(\phi_{j_2}\) = 52°

Abbildung 6: URDF-Visualisierung in ROS mit zwei verschiedenen Gelenkkonfigurationen und folgenden Werten: \(d_0\) = 300mm, \(a_2\) = 500mm, \(a_3\) = 200mm. Die Abbildung rechts zeigt auch die Integration von Oberflächenmodellen zur Modellierung der Volumeneigenschaften der Achsen.

Zusammenfassung und Ausblick

Die Programmierung eines Roboters ist eine komplexe und ressourcenintensive Aufgabe, die in den meisten Fällen auch die Nutzung des physikalischen Systems erfordert. Diese Hindernisse wirken sich direkt auf die Softwareentwicklung und Inbetriebnahme solcher Systeme aus. Ein kinematisches Modell (Mock-up) des Roboters hat das Potenzial, die Programmierung zu vereinfachen, ohne dabei das physische System zu benötigen, und gleichzeitig die Kosten zu senken. Allerdings gilt die Modellierung von Robotersystemen als eine nicht gerade triviale Aufgabe, die in einem ersten Schritt die Beschreibung ihres kinematischen Modells erfordert. Deshalb wurden in diesem Blogbeitrag zunächst die mathematischen Mindestgrundlagen zum Verständnis der kinematischen Modellierung vorgestellt. In einem weiteren Schritt haben wir anschließend gezeigt, wie kinematische Modelle mithilfe des Standardformats URDF nahtlos implementiert werden können.

Mit den Erkenntnissen in diesem Blogbeitrag sollten die Leser in der Lage sein, kinematische Modelle zu beschreiben, die als Mock-ups für Prototyping- oder Entwicklungszwecke eingesetzt werden können. Nachdem nun die erste Hürde der kinematischen Modellierung überwunden ist, können sich die Anwender solche Modelle mit folgenden Themen auseinandersetzen:

  • Bereitstellung kinematischer Modelle als Microservices für Entwicklungs-, Test- und Inbetriebnahmezwecke (weiterführende Literatur: Mocks in der Testumgebung)
  • Entwicklung anwenderfreundlicherer Programmier-Frameworks basierend auf kinematischen Simulationen unter Einsatz von VR (Virtual Reality) oder AR (Augmented Reality)

Minimales kinematisches Modell (URDF):

minimal_kinematic_model.urdf

Erweitertes kinematisches Modell (URDF):

extended_kinematic_model.urdf

[1] Aus diesem Grund werden diese Modelle im Allgemeinen als serielle kinematische Ketten bezeichnet. Es gibt auch parallele kinematische Modelle zur Darstellung von Delta-Robotern. Die kinematische Modellierung solcher Systeme wird im Rahmen dieses Blogbeitrags nicht behandelt.

[2] Auf dem Gebiet der Robotik wird die Transformation zwischen zwei Koordinatenframes häufig mit homogenen Transformationen und einer Gruppe von vier Parametern beschrieben, die die Translations- und Orientierungsverschiebung beschreiben. Diese Parameter werden als die Denavit-Hartenberg-Parameter bezeichnet.

Smart Manufacturing auf dem Büroschreibtisch

Schreibtisch auf dem eine Lernfabrik aus Lego aufgebaut ist, daneben arbeiten zwei Personen am Rechner
Abbildung 1: Überblick der Lernfabrik in Görlitz

Während immer mehr Startups, Mittelständler und Großkonzerne die Digitalisierung und Vernetzung für den Ausbau ihres Geschäfts nutzen und dabei auch völlig neuartige Geschäfts­modelle entwickeln, wächst der weltweite Bedarf an Standardisierung und Umsetzungs­kompetenz. So haben sich aus ehemaligen Worthülsen wie „Big Data“, „Internet of Things“ (IoT) und „Industrie 4.0“ längst konkrete Technologien entwickelt, die den digitalen Wandel vorantreiben und Unternehmen bei der Steigerung ihrer Produktivität, der Optimierung von Lieferketten und letztlich der Erhöhung von Rohertragsmargen unterstützen. Dabei profitieren sie vor allem von den wiederverwendbaren Diensten der sogenannten Hyperscaler wie Amazon, Microsoft, Google oder IBM, sind aber oft selbst nicht in der Lage, die Implementierung maßgeschneiderter Lösungen mit eigenem Personal zu stemmen. Die ZEISS Digital Innovation (ZDI) begleitet und unterstützt als Partner und Entwicklungsdienstleister ihre Kunden bei der digitalen Transformation.

Cloud-Lösungen hatten es lange Zeit vor allem im industriellen Umfeld schwer, da es weit verbreitete Vorbehalte in Bezug auf Daten-, IT- und Anlagensicherheit wie auch Entwicklungs- und Betriebs­kosten gab. Zudem erforderte die Anbindung und Aufrüstung unzähliger heterogener Bestands­systeme viel Fantasie. Inzwischen sind diese Grundsatzfragen weitgehend geklärt und Cloud-Anbieter werben mit spezifischen IoT-Diensten um neue Kunden aus dem produzierenden Gewerbe.

Um die typischen Chancen und Herausforderungen von IoT-Umgebungen möglichst praxisnah illustrieren zu können, wird ein interdisziplinäres ZDI-Team – bestehend aus erfahrenen Expertinnen und Experten aus den Bereichen Business-Analyse, Software-Architektur, Frontend- und Backend-Entwicklung, DevOps-Engineering sowie Test­management und Testautomatisierung – in bewährter agiler Vorgehensweise einen Demonstrator entwickeln, anhand dessen später auch kundenspezifische Anforderungen auf Umsetzbarkeit geprüft werden können.

Im Demonstrator wird eine vernetzte Produktionsumgebung mithilfe einer fischertechnik Lernfabrik simuliert und mit einer selbst entwickelten Cloud-Anwendung gesteuert. Die Lernfabrik enthält mit unterschiedlichen Sensoren, Kinematiken, Fördertechnik und insbesondere einer Siemens S7 Steuerung viele typische Elemente, wie sie auch in echten Industrieanlagen zum Einsatz kommen. Über etablierte Standards wie OPC UA und MQTT werden die Geräte an ein ebenfalls integriertes IoT-Gateway angebunden, das die gesammelten Daten seinerseits über eine einheitliche Schnittstelle den dafür optimierten Cloud-Diensten bereitstellt. Umgekehrt lässt das Gateway unter Berücksichtigung strenger Anforderungen an die IT- und Anlagensicherheit auch steuernde Zugriffe auf die Produktionsanlagen von außerhalb der Werksinfrastruktur zu.

Abbildung eines Teils der Lernfabrik
Abbildung 2: Greifarm mit blauem, NFC codiertem -Werkteil

Das Herstellen und Absichern der Konnektivität ist nach erfolgter Inbetriebnahme für die über alle ZDI-Standorte verteilt arbeitenden Kolleginnen und Kollegen einerseits ein organisatorisches Erfordernis, andererseits handelt es sich dabei bereits um eine Kernanforderung jeder praxistauglichen IoT-Lösung mit durchaus weitreichenden Konsequenzen für die Gesamtarchitektur. Technologisch wird sich das Team zunächst auf die Cloud-Services von Microsoft (Azure) und Amazon (AWS) konzentrieren und dabei umfangreiche Erfahrungen aus anspruchsvollen Kundenprojekten im IoT-Umfeld einbringen. Weiterhin stehen Architektur- und Technologie-Reviews sowie die Implemen­tierung erster Monitoring Use Cases im Fokus. Darauf aufbauend sind in der Folge auch komplexere Use Cases zur Taktzeitoptimierung, Maschineneffizienz, Qualitätssicherung oder Nachverfolgung (Track and Trace) geplant.

Besonders gut ist die ZDI auch im Bereich Testservices aufgestellt. Anders als in stark softwarelastigen Branchen wie z. B. der Logistik oder Finanzwirtschaft wurden die Testmanagerinnen und Testmanager in zahlreichen fertigungsnahen Use Cases jedoch immer wieder mit der Frage konfrontiert, wie Hardware, Software und insbesondere deren Zusammenspiel auf der Steuerungsebene möglichst vollumfänglich und vollautomatisch getestet werden können, ohne wertvolle Maschinen- und Anlagenzeit zu benötigen. In hyperkomplexen Produktionsumgebungen, wie sie ZEISS beispiels­weise in der Halbleiter- und Automotive-Industrie vorfindet, können die ansonsten weit verbreiteten digitalen Zwillinge aufgrund schwer modellierbarer Zusammenhänge und teilweise gänzlich unbekannter Einflussfaktoren nur noch bedingt Abhilfe leisten. Umso wichtiger ist die Konzeption einer geeigneten Testumgebung, mit der Fehler eingegrenzt, reproduziert und möglichst minimal­invasiv behoben werden können.

Wir werden auf diesem Blog regelmäßig über den Projektfortschritt berichten und unsere Erfahrungen teilen.