Architekturmuster für App-basierte Maschinenüberwachung

Tulip bietet Flexibilität bei der Strukturierung von Apps rund um Maschinen. Das richtige Muster hängt von der technischen Reife Ihres Teams, der Prozessstandardisierung und Ihrem Budget ab.

Muster 1: Kombinierbare Maschinen-Apps (1:1-Modell)

Struktur: Eine Maschine → Eine App → Eine Station → Ein Terminal

Architekturdiagramm:

Anwendungsfälle

• Einsteiger unter den Citizen-Developern, die ihre ersten Maschinenüberwachungs-Apps entwickeln
• Schnelle Proof-of-Concept -Bereitstellungen, bei denen Einfachheit Vorrang vor Effizienz hat
• Maßgeschneiderte manuelle Prozesse pro Maschineninstanz (z. B. erfordert Maschine 1 spezifische Prüfschritte, die für Maschine 2 nicht gelten)
• Betriebsorientierte Entwicklung, bei der Entwickler mehrere Rollen übernehmen und nur über begrenzte Zeit verfügen

Warum dies wichtig ist

Dieses Muster ordnet Software physisch 1:1 der Hardware zu und eliminiert so Abstraktionen. Entwickler können eine Maschine in der Fertigung identifizieren und ihr eine eigene App zuordnen. Diese Klarheit reduziert den kognitiven Aufwand und macht die Fehlerbehebung intuitiv.

Beispiel

Szenario: Ein Lebensmittel- und Getränkehersteller verfügt über drei Verpackungslinien. Jede Linie weist spezifische Ausfallursachen, Teilekonfigurationen und Arbeitsabläufe für das Bedienpersonal auf.

Implementierung

• Maschinentyp erstellen: „Verpackungslinie“
• 3 Maschinen anlegen: „Linie A“, „Linie B“, „Linie C“
• Erstellen Sie 3 Apps: „Terminal Linie A“, „Terminal Linie B“, „Terminal Linie C“
• Weisen Sie jeder App eine eigene Station mit einem festen Terminal zu

Vorteile

• Eine klare Datenisolierung verhindert maschinenübergreifende Datenbeschädigungen
• Einfache Anpassung der Workflows pro Maschine
• Einfache Fehlerbehebung (das Problem liegt immer in einer in sich geschlossenen App)

Einschränkungen

• Erfordert ein physisches Terminal pro Maschine (Hardwarekosten)
• Globale Änderungen an der App erfordern die Aktualisierung von 3 separaten Apps
• Nicht skalierbar über etwa 10 Maschinen hinaus

Muster 2: Zuordnung von Maschinen zur Stations-App

Struktur: Ein Maschinentyp → Eine App → Mehrere Stationen (Maschine wird dynamisch über Stationszuordnung zugewiesen)

Architekturdiagramm:

Anwendungsfälle

• Standardisierte Prozesse über identische Maschinentypen hinweg
• Vollzeit-Citizen-Developer, die mit Abstraktion und Triggerlogik vertraut sind
• Horizontale Skalierung erforderlich (10+ Maschinen desselben Typs)
• Die zentralisierte App-Wartung hat Priorität

So funktioniert es

1. Weisen Sie jede Maschine unter „Fertigungsbereich > Maschinen“ (Registerkarte „Konfiguration“) einer Station zu
2. Verwenden Sie in der App die Triggerbedingungen „an dieser Station“, um dynamisch auf den zugewiesenen Rechner zu verweisen
3. Wenn die App auf Station 1 ausgeführt wird, interagiert sie mit Maschine 1. Wenn sie auf Station 2 ausgeführt wird, interagiert sie mit Maschine 2

Beispiel für einen App-Trigger

Wenn: Maschine an diesem Arbeitsplatz gibteinen Statuswechsel ausWenn: Maschinenausgabe / Statuswechsel =Aus Dann: Datensatz in der Tabelle „Statusverlauf“ erstellen.

Beispiel

Szenario: Ein Tier-1-Zulieferer der Automobilindustrie verfügt über 15 identische CNC-Fräsmaschinen, auf denen derselbe Produktionsprozess abläuft.

Implementierung

• Maschinentyp anlegen: „5-Achsen-CNC-Fräsmaschine“
• 15 Maschinen anlegen (CNC-001 bis CNC-015)
• Eine App erstellen: „CNC-Bedienterminal“
• 15 Stationen anlegen, jeder Station eine Maschine zuweisen
• Die einzelne App auf allen 15 Stationen bereitstellen

Vorteile

• Nur eine App muss gewartet werden (globale Updates werden sofort übernommen)
• Verkürzte App-Entwicklungszeit für den Einsatz in Maschinenflotten
• Verwendet die Triggerlogik „an dieser Station“ (integrierte dynamische Rechnerreferenz)

Einschränkungen

• Es ist weiterhin ein Terminal pro Station erforderlich (Hardwarekosten bleiben bestehen)
• Alle Maschinen müssen vom gleichen Typ mit identischen Attributen sein
• Benutzerdefinierte maschinenbezogene Logik erfordert bedingte Verzweigungen (zusätzliche Komplexität)

Muster 3: Maschinenvariable-App (flexibles Terminal)

Struktur: Eine App → Mehrere Maschinentypen → Variablenbasierte Maschinenauswahl → Gemeinsames/flexibles Terminal

Architekturdiagramm:

Anwendungsfälle

• Budgetbeschränkungen: Begrenzte Anzahl verfügbarer Terminals
• Modell mit frei einsetzbarem Bediener: Ein Bediener wechselt mit einem gemeinsam genutzten iPad zwischen den Maschinen
• Die Maschinen erfordern keine kontinuierliche Überwachung: Die App muss nur während aktiver Vorgänge laufen

Kritische Einschränkung: Kein Headless-Betrieb

Dieses Muster unterstützt keine Überwachung im Hintergrund oder im Headless-Modus. Ist die App geschlossen, löst keine Maschine einen Alarm aus. Dieses Muster eignet sich nur für:

• Von Menschen initiierte Dateneingabe (Bediener protokolliert Fehler, zählt Teile)
• Ad-hoc-Maschineninspektionen
• Szenarien, in denen Maschinen keine Daten generieren, wenn die App nicht läuft

So funktioniert es

1. Erstellen Sie eine Maschinenvariable in der App (z. B. „selectedMachine“)
2. Fügen Sie ein Dropdown-Widget oder einen QR-Code-Scan hinzu, um „selectedMachine“ zur Laufzeit zu füllen
3. Verwenden Sie „selectedMachine“ in allen Trigger-Referenzen

Beispiel für einen App-Trigger

Wenn: Die Maschinenvariable „Ausgewählte Maschine“ gibt {Attribut} ausDann: Letzte Maschinenausgabe in Variable speichern

Beispiel

Szenario: Ein pharmazeutisches Labor verfügt über 5 Analysegeräte, die nur bei geplanten Tests laufen. Techniker verwenden ein gemeinsam genutztes iPad, um Testparameter und Ergebnisse zu protokollieren.

Umsetzung

• Erstellen Sie 5 Maschinen (HPLC-1, GC-MS-2 usw.)
• Erstellen Sie eine App: „Laborgeräteprotokoll“
• Fügen Sie ein Dropdown-Menü hinzu: „Gerät auswählen“ → füllt die Variable „selectedMachine“
• Der Techniker trägt das iPad zwischen den Geräten hin und her, wählt das aktive Gerät aus und erfasst die Daten

Vorteile

• Minimale Hardwarekosten (ein gemeinsames Terminal)
• Flexible Geräteauswahl zur Laufzeit
• Ideal für Ad-hoc- bzw. sporadische Arbeitsabläufe

Einschränkungen

• Nicht „headless“ – die App muss aktiv laufen, damit Logik ausgeführt werden kann
• Keine Hintergrundüberwachung, wenn die App geschlossen ist
• Komplexe Zustandsverwaltung (Welche Maschine ist derzeit aktiv?)
• Nicht geeignet für die OEE-Erfassung rund um die Uhr

Entscheidungsbaum für Architekturmuster

Verwenden Sie diesen Entscheidungsbaum, um das für Ihre Anforderungen am besten geeignete Muster auszuwählen:

Weiterführende Literatur

• Maschinenüberwachung – Headless- vs. App-basierte Architektur
• Variablen

{{snippet.Haben Sie gefunden, wonach Sie gesucht haben?}}