---
title: "Headless- vs. App-basierte Architektur"
slug: "machine-monitoring-headless-vs-app-based-architecture"
status: "new"
updated: 2026-10-22T10:46:57Z
published: 2026-10-22T10:46:57Z
canonical: "support.tulip.co/machine-monitoring-headless-vs-app-based-architecture"
---

> ## 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.

# Headless- vs. App-basierte Architektur

Eine entscheidende architektonische Entscheidung betrifft **den Ort, an dem die Maschinenlogik ausgeführt wird**: headless (Cloud/Edge) oder app-basiert (Endgerät).

## Abwägungsmatrix

Die folgende Tabelle erläutert verschiedene Methoden der Logikausführung.

| Methode | Headless | Kosten | Ideale Anwendungsfälle | Einschränkungen |
| --- | --- | --- | --- | --- |
| **Maschinelle Auslöser** | Ja | In der Tulip-Maschinenlizenz enthalten | OEE Tracking, Zustandsverwaltung, einfache Stückzählung | Eingeschränkte Aktionen (nur Zustandsänderungen und Aktivitätsfelder), **kein Ausdruckseditor**, keine Aufrufmöglichkeit von Connector-Funktionen |
| **Automatisierungen** | Ja | Preisgestaltung pro Aufgabe | Komplexe Workflows, Tabelleneinträge, Connector-Funktionen, Integration externer Systeme | Kosten skalieren mit der Nutzung, **keine Abschlussdatensätze** |
| **App-Trigger** | Nein | Enthalten | Mensch-Maschine-Workflows, umfangreiche UI-Interaktionen, komplexe Logik mit Ausdrücken | **Erfordert den Betrieb der App auf einem Terminal**, nicht geeignet für eine 24/7-Überwachung |
| **DataOps Plattform** (z. B. Litmus, High Byte) | Ja | Kontaktieren Sie den DataOps-Anbieter | Erweiterte Datennormalisierung, Zeitreihendatenbank, Aggregation über mehrere Protokolle | Zusätzliche zu verwaltende Plattform, höhere Gesamtkosten, komplexe Integration |
| **Edge-Gerät + Node-RED** | Ja | Einmalige Hardwarekosten | Hochgradig angepasste Logik, kundeneigene Infrastruktur | Geringere Zuverlässigkeit (**kein Failover/kein Multithreading**), schwierigere Skalierbarkeit, hoher Wartungsaufwand |

## Entscheidungskriterien

### Maschinenauslöser

**Verwenden Sie Maschinenauslöser, wenn:**

- Sie eine grundlegende OEE-Erfassung benötigen (Status, Stückzahl, Fehler)
- Die Logik aus einfachen bedingten Prüfungen besteht (z. B. „Wenn Attribut > 10, Status auf ‚In Betrieb‘ setzen“)
- die Kostenoptimierung entscheidend ist (in Tulip enthalten)

### Automatisierungen

**Verwenden Sie Automatisierungen, wenn:**

- Sie Maschinendaten in Tulip-Tabellen schreiben müssen
- eine Integration mit externen Systemen über Connector-Funktionen erforderlich ist
- Ein Headless-Betrieb vorgeschrieben ist und Ihr Budget eine Abrechnung pro Aufgabe zulässt

**Beispiel**: „Wenn Maschine 5 einen Fehlercode ausgibt, einen Datensatz in der Tabelle ‚Quality Issue‘ erstellen UND eine Slack-Benachrichtigung senden“

### App-Trigger

**Verwenden Sie App-Trigger, wenn:**

- menschliche Bediener aktiv in den Workflow eingebunden sind
- Sie den Ausdruckseditor für komplexe Berechnungen benötigen
- Der Workflow umfasst UI-Interaktionen (Schaltflächen, Formulare, Scans)

**Beispiel**: „Der Bediener klickt auf ‚Lauf abschließen‘, die App berechnet die OEE anhand der Maschinendaten und zeigt das Ergebnis auf dem Bildschirm an“

### DataOps-Plattform

**Verwenden Sie die DataOps-Plattform, wenn:**

- Sie eine Datenauflösung im Subsekundenbereich (<1 Hz) benötigen
- Sie Daten aus Protokollen aggregieren müssen, die nicht von Tulip unterstützt werden
- Eine Zeitreihendatenbank für erweiterte Analysen erforderlich ist
- Der Kunde hat bereits in die Plattform investiert

### Edge-Gerät

**Verwenden Sie ein Edge-Gerät + Node-RED, wenn:**

- Sie ein Proof-of-Concept oder ein Pilotprojekt durchführen
- Der Kunde verfügt über fundiertes Fachwissen im Bereich eingebetteter Systeme
- Regulatorische Anforderungen verhindern die Ausführung von Logik in der Cloud
- Budgetbeschränkungen den Einsatz von Abonnement-Software ausschließen

## Weiterführende Literatur

- [Architekturmuster für App-basierte Maschinenüberwachung](/r230/docs/machine-monitoring-app-based-architecture-patterns)
- [Erstellen Sie Ihren ersten Maschinen-Trigger](/r230/docs/create-your-first-machine-trigger)
- [Automatisierungen](/r230/docs/automations-1)
- [Edge-IO](/r230/docs/edge-io)
- [Node-RED](/r230/docs/node-red)

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

**OEE (Overall Equipment Effectiveness)**

A key performance indicator (KPI) that measures manufacturing productivity by calculating the percentage of planned production time that is truly productive. **OEE** combines three factors: **Availability** (uptime), **Performance** (speed), and **Quality** (good parts produced).

**Formula:** OEE = Availability × Performance × Quality

**Scale:** Expressed as a percentage, where 100% represents perfect production (manufacturing only good parts, as fast as possible, with no downtime).

**DataOps platforms**

DataOps refers to integrated software solutions that streamline the collection, transformation, contextualization, and delivery of industrial data across operational technology (OT) and information technology (IT) systems.

Key characteristics:

- Edge-to-cloud data pipeline management: Orchestrate data flow from factory floor devices to enterprise systems and cloud platforms
- Protocol translation: Convert between industrial protocols (Modbus, OPC-UA, Ethernet/IP) and modern IT standards (REST APIs, MQTT)
- Real-time data processing: Apply filtering, aggregation, and transformation at the edge to reduce bandwidth and latency
- Contextualization: Add metadata and business context to raw sensor data for meaningful analysis