Anforderungen an die Netzwerkstabilität und Datenintegrität für Tulip-Cloud-Bereitstellungen

Übersicht

Für Tulip-Cloud-Bereitstellungen ist eine hochwertige, stabile Netzwerkverbindung erforderlich, um die Echtzeitleistung und die Datenintegrität aufrechtzuerhalten. Dieser Artikel definiert die quantifizierbaren Netzwerkanforderungen – Bandbreite, Latenz, Jitter und Paketverlust –, die eine Tulip-Bereitstellung erfüllen muss, erläutert die technischen Risiken einer Netzwerkinstabilität (einschließlich Datenverlust in der Trigger-Warteschlange und Verstöße gegen die ALCOA-Konformität) und gibt Empfehlungen auf physikalischer, logischer und Anwendungsebene zur Minderung dieser Risiken.

Stabilität ist wichtiger als reine Geschwindigkeit: Eine instabile Verbindung mit hohem Jitter oder zeitweiligen Paketverlusten kann selbst bei Verbindungen mit hoher Bandbreite zu unbemerktem, dauerhaftem Datenverlust führen. Um die in diesem Artikel genannten Anforderungen zu erfüllen, ist ein zweigleisiger Ansatz erforderlich – eine robuste IT-/Netzwerkinfrastruktur und eine ausfallsichere Anwendungsarchitektur –, die zusammenwirken.

Eine Liste der spezifischen Domänen und IP-Adressen, die Sie für Ihre Tulip-Cloud-Instanz auf die Whitelist setzen sollten, finden Sie unter „Netzwerkanforderungen für die Tulip-Cloud-Bereitstellung“.

Für wen ist dieser Artikel gedacht?

Dieser Artikel ist vor allem für fortgeschrittene Tulip-Anwender nützlich, die Tulip in groß angelegten Umgebungen bereitstellen. Wenn Sie Tulip gerade erst in Ihrem Unternehmen einführen oder sich derzeit in einer Testphase befinden, gehen diese Informationen wahrscheinlich über Ihre aktuellen Anforderungen hinaus.

Nutzen Sie die Links auf der rechten Seite, um zum Inhalt des gewünschten Themas zu gelangen.

Zusammenfassung

Dieses Dokument beschreibt die wesentlichen Netzwerkanforderungen zur Gewährleistung der Leistung, Stabilität und Datenintegrität einer Tulip Cloud-Bereitstellung.

Wichtige Erkenntnisse

Stabilität ist wichtiger als Geschwindigkeit: Eine stabile kabelgebundene Verbindung mit 15 Mbit/s ist einer instabilen Verbindung mit über 100 Mbit/s, die unter hohem Jitter oder Paketverlust leidet, bei weitem überlegen.

Netzwerkinstabilität führt zu Datenverlust: Unterbrochene Verbindungen, hohe Latenz oder Paketverluste verursachen nicht nur „Langsamkeit“. Sie führen dazu, dass die Trigger-Warteschlange verstopft und Ereignisse verworfen werden, was zu dauerhaftem Datenverlust und kritischen Verstößen gegen die Datenintegrität (ALCOA) führt.

Zur Abhilfe ist eine zweiteilige Lösung erforderlich: Eine robuste IT-Infrastruktur (die die unten aufgeführten Anforderungen erfüllt) und eine ausfallsichere Anwendungsarchitektur (z. B. Entkopplung der Logik durch Automatisierungen) sind gleichermaßen notwendig.

Richtlinien für kritische Infrastrukturen

Standardmäßig kabelgebundenes Ethernet: Alle stationären Tulip-Player müssenüber ein kabelgebundenes, abgeschirmtes Ethernet verbunden sein.

Konfiguration und Überwachung von Proxys und Firewalls: Alle in der Allowlist aufgeführten Tulip-Domänen müssen für SSL/TLS-Pass-Through konfiguriert sein (siehe Allowlist). Deep Packet Inspection (DPI) sollte auf ein Minimum reduziert werden, die Leistung von Firewalls und Proxys sollte proaktiv überwacht werden.

Checkliste zur Netzwerkbereitschaft pro Station

Überprüfen Sie für jeden Tulip-Player-Arbeitsplatz:* [ ] Verbindungstyp: Stationäre Player verwenden kabelgebundenes, abgeschirmtes Ethernet (STP, Cat6a oder besser).* [ ] Bandbreite: Mindestens 15 Mbit/s im Downstream und Upstream verfügbar; niemals unter 10 Mbit/s pro aktiver Station oder unter dem berechneten Minimum (siehe Quantifizierbare Netzwerkanforderungen)* [ ] Latenz: Die durchschnittliche Round-Trip-Latenz (RTT) zu your-instance.tulip.co beträgt < 80 ms; die maximale RTT beträgt < 100 ms*[ ] Jitter: Der Jitter ($RTT_{max}-RTT_{avg}$) beträgt < 10 ms (und immer < 30 ms)* [ ] Paketverlust: Der gemessene Paketverlust beträgt im Normalbetrieb 0 % und < 0,1 % in Worst-Case-Tests.* [ ] Verfügbarkeit: Der Pfad vom Player zur Tulip Cloud ist nicht auf unzuverlässige Verbindungen angewiesen (Ad-hoc-WLAN, Gastnetzwerke, VPNs mit häufigen Verbindungsabbrüchen usw.)* [ ] Proxys / Firewalls: Alle Tulip-Domains in der Whitelist sind für SSL/TLS-Pass-Through konfiguriert, ohne SSL-Abfang, Protokollumschreibung, Manipulation oder Zwischenspeicherung und vorzugsweise ohne DPI.* [ ] WebSockets: Proxys und Firewalls lassen langlebige WebSocket-Verbindungen über Port 443 zu, ohne dass es zu Problemen mit Inaktivitäts-Timeouts oder Verbindungsabbrüchen kommt.
[ ] Prozessaktivität*: Geräte (insbesondere mobile) sind so konfiguriert, dass* aggressive Hintergrundprozess-Ruhezustände*, Akkuoptimierung oder Betriebssystemrichtlinien* vermieden werden*, die den Tulip Player aussetzen oder Netzwerkanfragen, TCP-Verbindungen oder WebSocket-Verbindungen während der Nutzung drosseln.* [ ]* Ausfallsichere Apps*: Kritische Apps auf dieser Station folgen den* Musternder Architektur für ausfallsichere Apps*(Minimierung der Ereignisrate und der API-Aufrufe in kritischen Triggerpfaden während des Bediener-Workflows, Priorisierung von Tulip-Tabellen und Minimierung lang laufender Konnektoren).

Risiken durch Instabilität und Datenintegrität

In diesem Abschnitt wird erläutert, warum eine stabile Verbindung entscheidend ist und welche technischen Risiken die Leistung und die Datenintegrität beeinträchtigen.

Über einfache Nachrichtenverzögerungen hinaus können zeitweise Verbindungsunterbrechungen oder Paketverluste zu zwei Hauptproblemen führen: 1. Ausbleiben von Ereignissen und Datenverlust: Wenndas Netzwerk instabil oder offline ist, erzeugen Bedieneraktionen (wie Tastendrücke, Geräteeingaben oder Barcode-Scans) weiterhin Ereignisse. Diese Ereignisse stauen sich in einer Warteschlange an. Da diese Warteschlange eine begrenzte Kapazität hat (standardmäßig 100 Ereignisse), werden alle neu eingehenden Ereignisse verworfen und gehen dauerhaft verloren, wenn diese Grenze während des Wartens auf die Wiederherstellung der Netzwerkverbindung überschritten wird. 2. Systemüberlastung und Verzögerungen durch „Nachholprozess“: Wenndie Verbindung nach einem Ausfall wiederhergestellt wird, wird versucht, den gesamten Rückstau an Ereignissen in der Warteschlange (bis zu 100) in schneller Folge auszuführen. Dies kann zu einer plötzlichen, massiven Belastung der Tulip-Plattform und aller angeschlossenen Systeme von Drittanbietern (über Connector Functions) führen. Dies gilt insbesondere, wenn mehrere Stationen aufgrund eines gemeinsamen Netzwerkproblems gleichzeitig die Verbindung wiederherstellen. Diese „Nachhol“-Flut kann zu erheblichen Verzögerungen und Überlastungen führen und zudem eine Drosselung der API (HTTP-429-Fehler) sowie weitere Ausfälle zur Folge haben.

Wie Netzwerkprobleme zu Datenverlusten in der Trigger-Warteschlange führen

Um dieses Risiko zu verstehen, ist es wichtig zu wissen, wie Trigger ausgeführt werden. Weitere Informationen finden Sie unter „Trigger “.* Single-Thread-Warteschlange: Die Trigger-Laufzeitumgebung von Tulip arbeitet mit einer sequenziellen Single-Thread-Warteschlange. Jedes Trigger-Ereignis (z. B. „Schaltfläche gedrückt“) wird dieser Warteschlange hinzugefügt und muss alle seine Aktionen abschließen, bevor das nächste Ereignis in der Warteschlange überhaupt beginnen kann.* Netzwerk-„Stau“: Ein Netzwerkausfall oder starke Instabilität führt dazu, dass Aktionen innerhalb eines Triggers (wie „Tabelleneintrag erstellen“ oder „ Connector Function “ ausführen) hängen bleiben oder in einen langwierigen Wiederholungszustand geraten. Beispielsweise wird ab LTS15 eine fehlgeschlagene Tabellenaktion bis zu 2 Minuten lang wiederholt.* Der Engpass: Dieser einzelne, langsame Trigger blockiert die gesamte Warteschlange. Während dieser Blockade füllen nachfolgende Bedieneraktionen (z. B. 99 weitere Tastendrücke) die Warteschlange.* Verlorene Ereignisse: Sobald das Warteschlangenlimit erreicht ist (standardmäßig 100 Ereignisse), werden alle weiteren Ereignisse abgebrochen und verworfen. Das bedeutet: Wenn ein Bediener während des Netzwerkausfalls den 101. Artikel scannt, geht dieses Ereignis für immer verloren und wird nach Wiederherstellung der Netzwerkverbindung nicht mehr verarbeitet.

Selbst wenn die Warteschlange nicht voll ist, kann allgemeine Netzwerkinstabilität dazu führen, dass einzelne API-Aufrufe ( Connector Functions ) fehlschlagen. Diese Aktionen werden nicht erneut versucht (im Gegensatz zu Tabellenaktionen in LTS15) und können zu stillen Datenausfällen und Integritätsproblemen führen.

Risikofaktoren für Datenverlust

Das Risiko eines Datenverlusts bei schlechter Netzwerkverbindung ist nicht einheitlich. Es wird durch App-Architekturen, die „ereignisintensiv“ sind, erheblich erhöht. Erfahren Sie hier mehr über Best Practices für diese Apps.

Sie sind einem deutlich höheren Risiko ausgesetzt, wenn Ihre Apps folgende Merkmale aufweisen:* Eine hohe Ereignisrate: Apps, die in kurzer Zeit viele Ereignisse generieren. Dazu gehören schnelles Scannen von Barcodes, häufige Geräteeingaben oder Timer-Auslöser, die in kurzen Intervallen (z. B. alle 30 Sekunden) ausgelöst werden.* Komplexe Trigger: Trigger, die viele aufeinanderfolgende Aktionen ausführen, insbesondere mehrere API-Aufrufe (Connector Functions) oder Tabellenschreibvorgänge. Jede netzwerkabhängige Aktion trägt zur potenziellen „Verzögerungszeit“ während eines Ausfalls bei.* Abhängigkeit von „ Connector Functions “: Verwendung von „ Connector Functions “ zur Erfassung kritischer Daten. Ein fehlgeschlagener „ Connector Function “ aufgrund einer Netzwerkstörung wird nicht erneut versucht und führt zum Fehlschlagen des Triggers, was den Prozess zum Stillstand bringen oder zu Datenverlust führen kann. Verwenden Sie nach Möglichkeit Automatisierungen (und/oder Funktionen).

ALCOA-Konformität für die Life-Sciences-Branche

Für Kunden aus dem Bereich Life Sciences und anderen GxP-regulierten Umgebungen sind diese Netzwerkrisiken nicht nur Leistungsprobleme, sondern direkte Bedrohungen für die Datenintegrität und die Compliance.

Die oben beschriebenen technischen Risiken lassen sich direkt den ALCOA-Prinzipien zuordnen:* Ungenau und unvollständig: Wenn während eines Ausfalls das Limit der Trigger-Warteschlange erreicht wird, werden alle nachfolgenden Ereignisse dauerhaft verworfen. Scannt ein Bediener einen 101. Artikel, geht dieses Ereignis für immer verloren. Die daraus resultierende Chargenprotokollierung ist grundsätzlich ungenau und unvollständig.* Nicht zeitnah: Wenn die Verbindung wiederhergestellt ist, führt die „Nachhol“-Flut einen Rückstau an in der Warteschlange befindlichen Ereignissen aus, oft Minuten nachdem der Bediener die Aktion durchgeführt hat. Ein Auditor, der eine Gruppe von Zeitstempeln überprüft, die deutlich vom tatsächlichen Prozess verzögert sind, würde die zeitliche Integrität der Aufzeichnung in Frage stellen.* Ungenau (systemübergreifend): Connector Functions (API-Aufrufe) verfügen über keine integrierten Wiederholungsversuche. Eine kurzzeitige Netzwerkstörung kann dazu führen, dass ein Trigger zwar erfolgreich in eine Tulip-Tabelle (den ursprünglichen Datensatz) schreibt, die Aktualisierung eines externen MES oder QMS jedoch fehlschlägt. Dies führt zu einem ungenauen und nicht synchronisierten Datenstatus in Ihren validierten Systemen.

Die Befolgung der architektonischen Empfehlungen im nächsten Abschnitt ist unerlässlich für den Aufbau eines robusten, validierbaren Prozesses, der vor Verletzungen der Datenintegrität schützt.

Quantifizierbare Netzwerkanforderungen

Um die zuvor beschriebenen Blockaden der Trigger-Warteschlange, verlorene Ereignisse und Datenintegritätsfehler zu verhindern, muss jede Tulip-Player-Station eine hochwertige, dauerhafte Verbindung aufrechterhalten. Die folgenden vier Dimensionen definieren diese Anforderung.

Bandbreite (Durchsatz)

Dies ist die „Größe“ der Verbindung, die eine Überlastung verhindert. Obwohl Anwendungsdaten oft nur einen geringen Datenumfang haben, führt unzureichende Bandbreite zu Latenz und Paketverlusten, was wiederum die Trigger-Warteschlange blockiert.

• Empfehlung: 15 Mbit/s pro aktiver Station.
• Absolutes Minimum: 10 Mbit/s pro aktiver Station oder die berechnete erforderliche Bandbreite, je nachdem, welcher Wert höher ist.
• Quantifizierbare Grenze: Die Mindestbandbreite muss die Basisdatenrate (BDR) der Anwendung übersteigen, multipliziert mit einem Headroom-Faktor ($H$) von mindestens 2,0 (100 %), um Netzwerk-Overhead und Wiederholungsübertragungen zu berücksichtigen.
  • $R_{peak}$ = Spitzenereignisrate (Ereignisse pro Sekunde)
  • $S_{event}$ = durchschnittliche Datenlast pro Ereignis (Bytes, einschließlich aller vom Trigger gesendeten und empfangenen Daten)
  • $H$ = Headroom-Faktor (dimensionslos), wobei $H > 2,0$ empfohlen wird

Berechnen Sie zunächst die Basisdatenrate (BDR) in Bit pro Sekunde:* $BDR (bps) = R_{peak} \times S_{event} \times 8$

Berechnen Sie anschließend die erforderliche Bandbreite: * $Erforderliche Bandbreite (bps) = BDR \times H = R_{peak} \times S_{event} \times 8 \times H$

In der Praxis sollten Sie, selbst wenn dieser berechnete Wert unter 10 Mbit/s liegt, dennoch mindestens 10 Mbit/s pro aktiver Station (und vorzugsweise 15 Mbit/s) bereitstellen, um für die Zukunft gerüstet zu sein, eine ausreichende Reserve zu gewährleisten und anderen Datenverkehr auf derselben Verbindung zu berücksichtigen.

Beispiel

Wenn die im ungünstigsten Fall auftretende Spitzenereignisrate Ihrer App $R_{peak}=2\text{ Ereignisse}/s$ beträgt und jedes Ereignis etwa $S_{event}=5.000\text{ Byte}$ sendet und empfängt, dann gilt:* $BDR = 2 \times 5.000 \times 8 = 80.000 bps$* $Erforderliche Bandbreite (H = 2,0) = 160.000 bps = 0,16 Mbit/s$

Auch wenn der berechnete Bedarf gering ist, stellen wir dennoch mindestens 10–15 Mbps pro Station bereit.

Latenz (Round-Trip-Zeit)

Dies ist die Verzögerung, die ein Paket benötigt, um zum Server und zurück zu gelangen. Eine hohe Latenz erhöht direkt die Ausführungszeit jeder netzwerkabhängigen Trigger-Aktion (wie z. B. ein Tabellenschreibvorgang oder „ connector function “), wodurch die gesamte Warteschlange anfällig für Blockaden wird.

• Empfehlung: < 80 ms
• Absolutes Maximum: 100 ms (zu Ihrer [instance].tulip.co-Domain).
• Quantifizierbare Grenze: Die Latenz bestimmt direkt, wie lange netzwerkabhängige Aktionen innerhalb eines Triggers dauern. Um zu verhindern, dass sich die Trigger-Warteschlange staut, muss die durch Netzwerkaktionen verursachte Gesamt-Trigger-Ausführungszeit deutlich kürzer sein als die Zeit zwischen den Ereignissen.

Sei:* $R_{peak}$ = Spitzenereignisrate (Ereignisse pro Sekunde)* $T_{between}$ = Zeit zwischen den Ereignissen (Sekunden).* $N_{net}$ = Anzahl aufeinanderfolgender Netzwerkaktionen im Trigger (z. B. Tabellenschreibvorgänge, Connector-Aufrufe)* $RTT_{avg}$ = durchschnittliche Round-Trip-Latenz (Sekunden)

Die Zeit zwischen den Ereignissen beträgt:* $T_{between}=\frac{1}{R_{peak}}$

Eine einfache Näherung für die durch die Netzwerklatenz bedingte Triggerzeit lautet:* $T_{trigger,net}=N_{net}\times RTT_{avg}$

Um eine gesunde Warteschlange aufrechtzuerhalten, muss die netzwerkbedingte Auslösezeit deutlich unter der Zeit zwischen den Ereignissen liegen.Eine praktische Faustregel lautet:* $N_{net}\times RTT_{avg}\leq 0,25\times T_{between}$* $N_{net}\times RTT_{avg}\leq \frac{0,25}{R_{peak}}$

Mit anderen Worten: Die Summe aller aufeinanderfolgenden Netzwerk-Roundtrips in einem Trigger sollte weniger als ein Viertel der erwarteten Zeit zwischen den Operator-Ereignissen bei Spitzenauslastung betragen. Wird diese Bedingung nicht erfüllt, staut sich die Warteschlange allmählich und erreicht schließlich die Grenze von 100 Ereignissen. Für eine möglichst zuverlässige Leistung sollten Sie darauf achten, dass $N_{net}\times RTT_{avg}\lt \lt \frac{0,1}{R_{peak}}$ gilt

Jitter (Latenzschwankung)

Dies ist die Schwankung der Latenz. Eine Verbindung mit hohem Jitter ist instabil; ein plötzlicher Latenzsprung bei einem einzelnen Paket kann einen Trigger genauso effektiv zum Stillstand bringen wie eine hohe durchschnittliche Latenz, wodurch die Warteschlange blockiert wird und es zu „zufälligen“ Verzögerungen und verlorenen Ereignissen kommt.

• Quantifizierbare Grenze: Jitter ist die Schwankung der Latenz im Zeitverlauf. Ein einzelner Latenzsprung kann einen Trigger genauso effektiv blockieren wie eine durchgehend hohe Latenz.

Sei:* $RTT_{avg}$ = durchschnittliche Round-Trip-Latenz über ein Abtastfenster (Sekunden)* $RTT_{max}$ = maximal beobachtete Round-Trip-Latenz über dasselbe Fenster (Sekunden)

Wir definieren:* $Jitter=RTT_{max}-RTT_{avg}$

Dieser Wert muss niedrig gehalten werden, um eine vorhersehbare Trigger-Leistung zu gewährleisten. Für Tulip-Bereitstellungen:* Empfehlung: $Jitter$ < 10 ms * Absolutes Maximum: $Jitter$ < 30 ms

Wenn der gemessene Jitter 30 ms erreicht oder überschreitet, kommt es zu „zufälligen“ Verzögerungen, und Trigger können so lange im laufenden Zustand verbleiben, dass sie die Warteschlange blockieren.

Zuverlässigkeit (Paketverlust und Verfügbarkeit)

Dies ist der entscheidende Faktor für die Datenintegrität. Paketverluste erzwingen erneute Übertragungen, was einen Trigger für Sekunden lang blockieren und zu schwerwiegenden Staus in der Warteschlange führen kann. Verbindungsabbrüche (Ausfälle der Verfügbarkeit) sind katastrophal, da sie zu einer vollen Warteschlange (100 Ereignisse) und dem dauerhaften Verlust aller nachfolgenden Daten führen, was unvollständige Datensätze zur Folge hat.

• Empfehlung: 0 % Paketverlust und kontinuierliche Verfügbarkeit.
• Absolutes Maximum: < 0,1 % Paketverlust.
• **Quantifizierbare Grenze:**Die Trigger-Warteschlange kann nur eine begrenzte Anzahl von Ereignissen aufnehmen. Wenn das Netzwerk ausfällt, erzeugen die Aktionen des Betreibers weiterhin Ereignisse, bis die Warteschlange voll ist. Sobald die Warteschlange ihre Grenze erreicht, werden alle nachfolgenden Ereignisse verworfen und gehen dauerhaft verloren.

Sei:* $Q_{max}$ = maximale Warteschlangengröße (Ereignisse). Derzeit beträgt $Q_{max}=100$ standardmäßig.* $R_{peak}$ = Spitzenereignisrate während eines Ausfalls (Ereignisse pro Sekunde).

Die maximal tolerierbare Ausfalldauer, bevor Ereignisse verworfen werden, beträgt:* $T_{outage,max}=\frac{Q_{max}}{R_{peak}}$

Beispiel: Für eine App mit einer hohen Ereignisrate von $R_{peak}=2$ Ereignissen/Sek. (z. B. schnelle Drehmomentwerte):* $T_{outage,max}=\frac{100}{2}=50$ Sekunden

In diesem Beispiel führt jeder ununterbrochene Netzwerkausfall, der länger als 50 Sekunden dauert, zu Datenverlust: Jedes Ereignis nach den ersten 100 wird verworfen und niemals verarbeitet, selbst wenn das Netzwerk wiederhergestellt wird.

Dieser einfache Zusammenhang ist für die Risikobewertung entscheidend: Apps mit hoher Ereignisrate tolerieren nur sehr kurze Ausfälle, bevor die Datenintegrität beeinträchtigt wird.

Empfehlungen zur physischen Infrastruktur

Die Erfüllung der quantifizierbaren Netzwerkanforderungen hängt nicht nur von Ihrem Internetdienstanbieter ab, sondern in hohem Maße auch von der internen physischen Netzwerkinfrastruktur Ihrer Einrichtung.

Standardempfehlung: kabelgebundenes Ethernet

Um die im vorherigen Abschnitt definierten Kennzahlen für Stabilität, Zuverlässigkeit und niedrige Latenz zu erreichen, ist eine kabelgebundene Ethernet-Verbindung die dringende Standardempfehlung für alle stationären Tulip-Player-Stationen.

Dies ist jedoch keine Lösung nach dem Motto „Einmal einrichten und dann vergessen“. Die physikalische Ebene ist eine häufige und oft übersehene Fehlerquelle, die zu zeitweiligen, schwer zu diagnostizierenden Paketverlusten führen kann.

• Integrität der physischen Kabel: IT- und Betriebsteams müssen diese Infrastruktur proaktiv verwalten. Überprüfen Sie die Kabel regelmäßig auf Defekte, Ausfransungen oder lose Verbindungen. Eine häufige Fehlerquelle ist ein Wagen, der wiederholt über ein ungeschirmtes oder schlecht verlegtes Kabel rollt.
• Elektromagnetische Störungen (EMI): In einer Fabrikhalle können stark vibrierende Maschinen, Motoren oder Hochspannungsgeräte erhebliche Störungen verursachen. Verwenden Sie in diesen Umgebungen abgeschirmte Ethernet-Kabel (z. B. STP, Cat6a oder höher), um eine Signalverschlechterung zu verhindern.

Überlegungen zu WLAN und mobilen Geräten

Wir sind uns bewusst, dass viele Kunden mobile Geräte (Tablets, Smartphones) oder mobile Wagen nutzen, bei denen eine kabelgebundene Verbindung nicht möglich ist. In diesen Fällen ist eine stabile WLAN-Verbindung eine Grundvoraussetzung für die Datenintegrität.

• Netzwerkdesign: Sie müssen ein robustes, professionell konzipiertes WLAN-Netzwerk sicherstellen. Das Ziel ist eine lückenlose Abdeckung ohne Funklöcher (die zu Verbindungsabbrüchen führen) und mit minimaler Überlappung der Access Points (APs). Eine übermäßige Überlappung kann dazu führen, dass ein Gerät zwischen den APs „hin- und herwechselt“, was eine DHCP-Neuverhandlung erzwingt und einen Netzwerkstillstand verursacht, der die Trigger-Warteschlange blockiert.
• Störungen: WLAN ist zudem sehr anfällig für elektromagnetische Störungen (EMI) durch Maschinen. Ihr Netzwerkdesign muss dies berücksichtigen.
• Erhöhtes Risiko: Da eine drahtlose Verbindung von Natur aus weniger stabil ist als eine kabelgebundene, ist es für Anwendungen auf diesen Geräten umso wichtiger, die Empfehlungen der „Resilient App Architecture“ (wie z. B. die Entkopplung der Logik) zu befolgen, um sich vor den unvermeidlichen Netzwerkstörungen zu schützen.
• Mobile Betriebssysteme können Hintergrund-Apps aggressiv in den Ruhezustand versetzen oder drosseln, um Akku zu sparen. Der Tulip Player sollte während der Nutzung von solchen Richtlinien ausgenommen werden (bevorzugt wird der Kiosk-/Locked-App-Modus).

Checkliste für die physische Infrastruktur

Kabelgebundene Stationen

• [ ] Kabeltyp: Alle stationären Tulip Player verwenden in Bereichen mit hoher elektromagnetischer Störung (Motoren, Antriebe, Schweißgeräte usw.) abgeschirmtes Ethernet (STP, Cat6a oder besser).
• [ ] Kabelführung: Es verlaufen keine Kabel an Stellen, an denen Wagen, Gabelstapler oder Stühle regelmäßig darüber rollen; Kabel werden nach Möglichkeit durch Kabelrinnen, Kabelkanäle oder über Kopf verlegt.
• [ ] Kabelzustand: Es gibt einen dokumentierten Prüfplan (z. B. vierteljährlich), um die Kabel auf Ausfransungen, Knicke, gequetschte Ummantelungen und lose Verbindungen zu überprüfen.
• [ ] Anschlüsse: Alle Steckverbinder und Patchfelder sind ordnungsgemäß angeschlossen und zugentlastet; es werden keine „provisorischen“ Patchkabel als feste Verlegung verwendet.
• [ ] Switch-Ports: Die Player-Ports sind auf die entsprechende Geschwindigkeit/Duplex-Einstellung festgelegt und teilen sich keine überlasteten Uplinks, die regelmäßig ausgelastet sind.
• [ ] Stromversorgung / PoE: Bei Verwendung von PoE ist das Leistungsbudget des Switches nicht überbelegt; Spannungsabfälle oder Reset-Ereignisse werden überwacht und melden Alarm.
• [ ] Überwachung: Die grundlegende Switch-Überwachung (CPU, Speicher, Schnittstellenfehler und Auslastung) ist aktiviert und wird regelmäßig überprüft.

WLAN und mobile Geräte

• [ ] Professionelle Planung: Das WLAN-Netzwerk wurde für den Produktionsbereich, in dem Tulip-Geräte betrieben werden, professionell geplant (oder zumindest vermessen).
• [ ] Abdeckung: Die gemessene Signalstärke entlang der gesamten Bedienerroute („Walk-Route“) zeigt eine durchgehende Abdeckung ohne Funklöcher, die Verbindungsabbrüche oder Roaming-„Free-Falls“ verursachen.
• [ ] AP-Überlappung: Die Access Points sind so platziert, dass übermäßige Überlappungen minimiert werden; Clients „suchen“ im Stillstand nicht zwischen APs hin und her.
• [ ] Roaming-Verhalten: Roaming-Schwellenwerte und Band-Steering sind so abgestimmt, dass Geräte reibungslos zwischen APs wechseln, ohne dass es zu wiederholten DHCP-Neuverhandlungen oder kurzen Verbindungsabbrüchen kommt.
• [ ] Interferenzen: Bekannte Quellen elektromagnetischer Störungen (Maschinen, Schweißgeräte, große Motoren, Mikrowellenverbindungen usw.) wurden bei der Kanalplanung berücksichtigt.
• [ ] Segmentierung: Tulip-Geräte befinden sich in einem dedizierten SSID/VLAN für Produktionssysteme und werden nicht mit Gast-WLAN oder Verbrauchergeräten mit hoher Fluktuation gemischt.
• [ ] Backhaul: Die APs verfügen über zuverlässige, nicht überlastete Uplinks; das vom Controller oder über die Cloud verwaltete WLAN wird nicht nahe an seiner Kapazitätsgrenze betrieben.
• [ ] Ausfallsichere Apps: Apps, die auf WLAN-/Mobilgeräten laufen, halten sich strenger an die Architektur für ausfallsichere Apps, um dem von Natur aus höheren Risiko der drahtlosen Verbindung Rechnung zu tragen.

Test

Gehen Sie eine Route mit einem Player ab, auf dem „networkCheck“ und Ihre eigenen Diagnosetools laufen, und stellen Sie sicher, dass 10 Minuten lang keine Verbindungsabbrüche oder Spitzenwerte über dem Schwellenwert auftreten.

Logische und Sicherheitsinfrastruktur (Proxys, Firewalls und DPI)

Abgesehen von physischen Kabeln ist Ihre logische Netzwerksicherheitsinfrastruktur die häufigste Ursache für „rätselhafte“ Latenz, Jitter und Verbindungsausfälle.

• Proxys und Firewalls als Engpass: Sicherheitsgeräte (Firewalls, Proxys, CASB usw.), die eine Deep Packet Inspection (DPI) oder SSL/TLS-Entschlüsselung für den gesamten Datenverkehr durchführen, sind eine Hauptursache für Instabilität. Dieser Überprüfungsprozess selbst fügt jeder einzelnen Netzwerkanfrage eine erhebliche, variable Latenz (Jitter) hinzu, wodurch die Anforderungen von <100 ms Latenz und <30 ms Jitter leicht überschritten werden können.
• Zustand der Geräte überwachen: Netzwerkteams müssen die CPU- und Speicherauslastung dieser Geräte überwachen. Eine überlastete Firewall oder ein überlasteter Proxy lässt Pakete fallen oder verursacht Latenz, was genau zu jener Instabilität führt, die Datenverluste zur Folge hat.
• Greifen Sie nicht in den Tulip-Datenverkehr ein: Die Client-zu-Cloud-Kommunikation von Tulip basiert auf spezifischen Webprotokollen, darunter sichere WebSockets, für die Datenübertragung in Echtzeit. Einige Sicherheitslösungen versuchen, diesen HTTPS-Datenverkehr abzufangen, umzuschreiben oder zu „manipulieren“. Dieses Abfangen kann die WebSocket-Verbindung unterbrechen oder Standard-API-Aufrufe fälschlicherweise als Cross-Origin-Requests (CORS) kennzeichnen, wodurch diese fehlschlagen.
• Anforderung: Alle Tulip-Domains (aufgeführt im Abschnitt „Allowlist“ ) müssen für SSL/TLS-Pass-Through konfiguriert sein. Der Datenverkehr sollte jeglicher DPI, Protokollprüfung oder Zwischenspeicherung umgangen werden.

Checkliste

• [ ] Tulip-Domains umgeleitet: Alle in der Whitelist aufgeführten Tulip-Domains sind für SSL/TLS-Pass-Through konfiguriert und von der SSL-Entschlüsselung bzw. -Abfangmaßnahmen ausgenommen.
• [ ] Keine DPI und keine Protokollumschreibung bevorzugt: Deep Packet Inspection (DPI), HTTP-Protokollumschreibung und Content-Caching sind für den Tulip-Datenverkehr deaktiviert, insbesondere für WebSockets.
• [ ] WebSocket-Unterstützung: Firewalls und Proxys erlauben langlebige WebSocket-Verbindungen über Port 443 ohne kurze Inaktivitäts-Timeouts oder erzwungene Neustarts.
• [ ] Kapazitätsüberwachung: CPU, Arbeitsspeicher und Durchsatz auf Sicherheitsgeräten werden überwacht; es sind Warnmeldungen für anhaltend hohe Auslastung eingerichtet, die zu Latenz oder Paketverlust führen könnte.
• [ ] Ausgangsregeln: Ausgangsregeln lassen Tulip-IP-Bereiche bzw. Hostnamen (pro „Garden“-Kennung) ausdrücklich zu, einschließlich Endpunkten für die Speicherung von Assets (S3/Blob).
• [ ] „Fail-Open“-Verhalten: Soweit möglich ist der Tulip-Datenverkehr so konfiguriert, dass er im „Fail-Open“-Modus arbeitet (oder klare, protokollierte Fehler ausgibt), anstatt Pakete stillschweigend zu verwerfen.
• [ ] Änderungskontrolle: Jede Änderung an der Firewall-/Proxy-Konfiguration, die sich auf Tulip auswirken könnte, wird nachverfolgt und im Idealfall während der Änderungsfenster anhand von „https://your-account.tulip.co/networkCheck“ getestet.

Ausfallsichere Anwendungsarchitektur

In diesem Abschnitt wird erläutert, wie Entwickler Infrastrukturrisiken mindern können.

Entwickler müssen Anwendungen so entwerfen, dass sie gegenüber zeitweiligen Netzwerkproblemen widerstandsfähig sind. Es ist entscheidend, Spielraum für Netzwerklatenz und geringfügige Leistungseinbußen der Plattform einzuplanen. Nutzen Sie Automatisierungen (und/oder Funktionen, wo möglich).

• Priorisieren Sie Tulip-Tabellenschreibvorgänge: Verwenden Sie für alle kritischen Datenerfassungen in Ihrem Trigger zunächst die nativen Tulip-Tabellenaktionen „Create Record“ oder „Store“. Diese Aktionen sind widerstandsfähiger gegenüber kurzzeitigen Netzwerkstörungen und verfügen über eine integrierte Wiederholungslogik (bis zu 2 Minuten in LTS15).
• Minimieren Sie die Ereignisrate: Überprüfen Sie Ihr App-Design. Wenn ein Bediener während eines 2-minütigen Netzwerkausfalls realistisch gesehen 100 Ereignisse (z. B. Scans) generieren kann, ist Ihre Architektur einem hohen Risiko ausgesetzt. Erwägen Sie, Eingaben zu bündeln oder den Workflow zu vereinfachen.
• Befolgen Sie die Best Practices für die Leistung: Halten Sie sich an die hier dokumentierten Leitlinien für leistungsstarke Apps. Eine Überlastung der Plattform durch hochfrequente Aufrufe verursacht interne Latenz, die eine schlechte Netzwerkverbindung vortäuscht.

Siehe auch: Ereignisbasierte App-Trigger über die „virtuelle“ Tulip-Maschine

Checkliste

• [ ] Tabellen zuerst: Alle kritischen Datenerfassungen (Scans, Bedienerentscheidungen, Messungen) werden zunächst in eine Tulip-Tabelle geschrieben.
• [ ] Keine lang andauernden API-Aufrufe in Bediener-Triggern: Bedienerorientierte Trigger enthalten keine lang andauernden „ Connector Functions “ oder komplexe externe API-Logik.
• [ ] Entkopplungsmuster: Für externe API-Aufrufe werden nach Möglichkeit Automatisierungen bevorzugt.
• [ ] Statusfelder: Verarbeitungstabellen verwenden eindeutige Statusfelder (ausstehend, in Bearbeitung, verarbeitet, Fehler), damit Fehler wiederholt oder untersucht werden können.
• [ ] Kontrollierte Ereignisrate: Das App-Design verhindert, dass Bediener anhaltende Ereignisraten erzeugen, die die Warteschlange während kurzer Ausfälle füllen würden (siehe Ausfallberechnung oben).
• [ ] Timer und Schleifen: Timer-Trigger und Schleifen werden nicht in unnötig kurzen Intervallen (z. B. alle 1–5 Sekunden) ausgelöst, es sei denn, dies ist absolut erforderlich und validiert.
• [ ] Fehlerbehandlung bei „ Connector Functions “: „ “, die aufgrund von Netzwerkproblemen fehlschlagen können, verfügen über Fehlerbehandlungs- und Wiederholungsmechanismen (vorzugsweise über Automationen, nicht über Bediener-Trigger).
• [ ] Best Practices für die Leistung: Apps halten sich an die Best Practices von Tulip für leistungsstarke Apps.

Technische Konfiguration und Fehlerbehebung

Falls Ihr Netzwerk die oben genannten quantifizierbaren Anforderungen nicht erfüllt oder falls Sie Leistungsprobleme haben, bei denen Sie vermuten, dass sie netzwerkbedingt sind, befolgen Sie bitte die Schritte in unserem ausführlichen Leitfaden. Dieser Leitfaden enthält ein nach Prioritäten geordnetes Flussdiagramm zur Diagnose und Behebung von Netzwerkleistungsproblemen, von grundlegenden Überprüfungen bis hin zur fortgeschrittenen Analyse auf Paketebene.

Den vollständigen Leitfaden zur Fehlerbehebung im Netzwerk finden Sie hier.

Netzwerk- und WebSocket-Testtool

Tulip nutzt in großem Umfang WebSockets, eine Art von dauerhafter Verbindung, um Echtzeit-Aktualisierungen zu ermöglichen. Diese WebSockets verwenden SSL-Verschlüsselung über Port 443. Einige Proxys unterstützen diese Verbindungen nicht, und bei manchen Netzwerkmonitoren müssen diese Verbindungen möglicherweise ausdrücklich zugelassen werden. Bitte überprüfen Sie den obigen Abschnitt hinsichtlich der Kompatibilität.

Es steht ein einfaches Dienstprogramm zur Verfügung, mit dem Sie die Latenz Ihrer Netzwerkverbindung und die WebSocket-Kompatibilität testen können:

• https://your-account.tulip.co/networkCheckOR
• https://your-account.dmgmori-tulip.com/networkCheckOR
• https://your-account.tulip-serendie.com/networkCheck

Checkliste für die Inbetriebnahme und laufende Überwachung

• [ ] Ersttest: Führen Sie für jede neue Station unter normaler Produktionsauslastung mindestens 10–15 Minuten lang https://your-account.tulip.co/networkCheck (oder die DMG MORI/Serendie-URL) sowie Ihre eigenen Diagnosetests durch.
• [ ] Metriken aufzeichnen: Erfassen Sie die durchschnittliche, minimale und maximale Latenz, den Jitter sowie etwaige beobachtete Paketverluste; überprüfen Sie, ob diese die in diesem Artikel genannten Schwellenwerte einhalten.
• [ ] Spitzenlasttest: Wiederholen Sie den Test während einer bekannten Spitzenlastphase im Werksnetzwerk (Schichtwechsel, Verarbeitung großer Chargen), um die Stabilität unter Belastung sicherzustellen.
• [ ] Regressionstests nach Änderungen: Führen Sie den Test nach jeder wesentlichen Änderung an der Netzwerk-, WLAN-, Firewall- oder Proxy-Konfiguration, die sich auf Tulip auswirkt, erneut durch.
• [ ] Speicherung der Basisdaten: Speichern Sie die Testergebnisse (Screenshots oder Exporte) als Teil Ihrer Validierungs- und Inbetriebnahmeprotokolle.
• [ ] Regelmäßige erneute Überprüfung: Planen Sie regelmäßige Wiederholungstests (z. B. vierteljährlich) für kritische Stationen ein oder wenn neue Anwendungen mit höheren Ereignisraten bereitgestellt werden.

Haben Sie gefunden, wonach Sie gesucht haben?

Sie können auch auf community.tulip.co vorbeischauen, um Ihre Frage zu stellen oder zu sehen, ob andere bereits mit einem ähnlichen Problem konfrontiert waren!