---
title: "Architekturmuster für App-basierte Maschinenüberwachung"
slug: "machine-monitoring-app-based-architecture-patterns"
status: "new"
updated: 2026-10-22T10:48:06Z
published: 2026-10-22T10:48:06Z
canonical: "support.tulip.co/machine-monitoring-app-based-architecture-patterns"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.tulip.co/llms.txt
> Use this file to discover all available pages before exploring further.

# 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**:![Machine Terminal App Pattern 1 - Composable Machine Apps.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Machine%20Terminal%20App%20Pattern%201%20-%20Composable%20Machine%20Apps(1).png)

### 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**:![Machine Terminal App Pattern 2 - Machine Assigned Station.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Machine%20Terminal%20App%20Pattern%202%20-%20Machine%20Assigned%20Station.png)

### 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 gibt**einen Statuswechsel** aus**Wenn**: Maschinenausgabe / Statuswechsel =**Aus Dann**: Datensatz in der Tabelle „Statusverlauf“ erstellen.

![Log to Status History when Machine Stopped](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Log%20to%20Status%20History%20when%20Machine%20Stopped.png)

### 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**:![Machine Terminal App Pattern 3 - Machine Variable.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Machine%20Terminal%20App%20Pattern%203%20-%20Machine%20Variable.png)

### 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} aus**Dann**: Letzte Maschinenausgabe in Variable speichern

![Store Machine Variable Output to Variable](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Store%20Machine%20Variable%20Output%20to%20Variable.png)

### 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:![Machine Terminal App Pattern Architect Options v2.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Machine%20Terminal%20App%20Pattern%20Architect%20Options%20v2.png)

## Weiterführende Literatur

- [Maschinenüberwachung – Headless- vs. App-basierte Architektur](/r230/docs/machine-monitoring-headless-vs-app-based-architecture)
- [Variablen](/r230/docs/variables)

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