Requisiti di stabilità della rete e integrità dei dati per le implementazioni cloud di Tulip

Panoramica

Per le implementazioni di Tulip Cloud è necessaria una connessione di rete stabile e di alta qualità per mantenere le prestazioni in tempo reale e l’integrità dei dati. Questo articolo definisce i requisiti di rete quantificabili — larghezza di banda, latenza, jitter e perdita di pacchetti — che un'implementazione di Tulip deve soddisfare, spiega i rischi tecnici legati all'instabilità della rete (tra cui la perdita di dati nella coda di trigger e i fallimenti di conformità ALCOA) e fornisce raccomandazioni a livello fisico, logico e applicativo per mitigare tali rischi.

La stabilità è più importante della velocità pura: una connessione instabile con jitter elevato o perdita intermittente di pacchetti può causare una perdita di dati silenziosa e permanente anche su collegamenti ad alta larghezza di banda. Il soddisfacimento dei requisiti descritti in questo articolo richiede un approccio in due parti — un’infrastruttura IT/di rete robusta e un’architettura applicativa resiliente — che operino in sinergia.

Per l’elenco dei domini e degli indirizzi IP specifici da inserire nella lista bianca per la vostra istanza Tulip Cloud, consultate i requisiti di rete per l’implementazione di Tulip Cloud.

A chi è rivolto questo articolo?

Questo articolo è particolarmente utile per gli utenti avanzati di Tulip che stanno effettuando implementazioni in ambienti su larga scala. Se state implementando Tulip per la prima volta nella vostra organizzazione o siete attualmente in fase di prova, queste informazioni potrebbero risultare più avanzate rispetto alle vostre esigenze attuali.

Utilizzate i link a destra per accedere ai contenuti relativi all’argomento desiderato.

Sintesi

Questo documento illustra i requisiti di rete fondamentali per garantire le prestazioni, la stabilità e l’integrità dei dati di una distribuzione di Tulip Cloud.

Punti chiave

La stabilità è più importante della velocità: una connessione cablata stabile a 15 Mbps è di gran lunga superiore a una connessione instabile a oltre 100 Mbps con jitter elevato o perdita di pacchetti.

L'instabilità della rete causa la perdita di dati: connessioni intermittenti, elevata latenza o perdita di pacchetti non causano solo "lentezza". Provocano l'intasamento della coda di trigger e la perdita di eventi, portando a una perdita permanente di dati e a gravi errori nell'integrità dei dati (ALCOA).

La mitigazione richiede una soluzione in due parti: sono necessarie sia un’infrastruttura IT robusta (che soddisfi i requisiti riportati di seguito) sia un’architettura applicativa resiliente (ad esempio, il disaccoppiamento della logica tramite automazioni).

Politiche relative alle infrastrutture critiche

Utilizzo predefinito di Ethernet cablata: tutti i Tulip Player fissi devono utilizzare una connessione Ethernet cablata e schermata.

Configurare e monitorare proxy e firewall: tutti i domini Tulip elencati nella Allowlist devono essere configurati per il pass-through SSL/TLS (vedere Allowlist). L'ispezione approfondita dei pacchetti (DPI) deve essere ridotta al minimo, mentre le prestazioni di firewall e proxy devono essere monitorate in modo proattivo.

Lista di controllo della prontezza di rete per ogni postazione

Per ogni postazione Tulip Player, verificare:* [ ] Tipo di connessione: i Player fissi utilizzano una connessione Ethernet cablata e schermata (STP, Cat6a o superiore).* [ ] Larghezza di banda: almeno 15 Mbps disponibili in downstream e in upstream; mai inferiori a 10 Mbps per postazione attiva o al minimo calcolato (vedere Requisiti di rete quantificabili)* [ ] Latenza: la latenza media di andata e ritorno (RTT) verso your-instance.tulip.co è < 80 ms; l’RTT massimo è < 100 ms*[ ] Jitter: Il jitter ($RTT_{max}-RTT_{avg}$) è < 10 ms (e sempre < 30 ms)* [ ] Perdita di pacchetti: la perdita di pacchetti misurata è pari allo 0% durante il normale funzionamento e < 0,1% nei test in condizioni estreme.* [ ] Tempo di attività: il percorso dal Player a Tulip Cloud non si basa su connessioni instabili (Wi-Fi ad hoc, reti ospiti, VPN con frequenti interruzioni, ecc.)* [ ] Proxy / firewall: Tutti i domini Tulip presenti nella lista bianca sono configurati per il pass-through SSL/TLS senza intercettazione SSL, riscrittura del protocollo, manomissione o memorizzazione nella cache e, preferibilmente, senza DPI.* [ ] WebSocket: i proxy e i firewall consentono connessioni WebSocket di lunga durata sulla porta 443 senza problemi di timeout di inattività o di reset della connessione.
[ ] Attività dei processi*: i dispositivi (soprattutto quelli mobili) sono configurati per* evitare un'ibernazione aggressiva dei processi in background*, l'ottimizzazione della batteria o politiche del sistema operativo che sospendano Tulip Player o limitino le richieste di rete, le connessioni TCP o le connessioni WebSocket durante l'uso.* [ ]* App resilienti*: le app critiche su questa stazione seguono i* modellidell’architettura delle app resilienti*(ridurre al minimo la frequenza degli eventi e le chiamate API nei percorsi di trigger critici durante il flusso di lavoro dell’operatore, dare priorità alle Tulip Tables e ridurre al minimo i connettori a esecuzione prolungata).

Rischi di instabilità e integrità dei dati

Questa sezione spiega perché una connessione stabile è fondamentale e quali sono i rischi tecnici che incidono sulle prestazioni e sull’integrità dei dati.

Oltre al semplice ritardo dei messaggi, la connettività intermittente o la perdita di pacchetti possono portare a due problemi principali: 1. Perdita di eventi e perdita di dati Quandola rete è instabile o offline, le azioni dell’operatore (come la pressione di pulsanti, gli input dei dispositivi o la scansione di codici a barre) continuano a generare eventi. Questi eventi si accumulano in una coda. Poiché questa coda ha un limite massimo (100 eventi per impostazione predefinita), se tale limite viene superato mentre si attende il ripristino della rete, tutti i nuovi eventi in arrivo vengono scartati e persi definitivamente. 2. Sovraccarico del sistema e rallentamenti dovuti al “recupero”: quandola connettività viene ripristinata dopo un’interruzione, l’intero arretrato di eventi in coda (fino a 100) tenterà di essere eseguito in rapida successione. Ciò può causare un carico improvviso e massiccio sulla piattaforma Tulip e su eventuali sistemi di terze parti collegati (tramite Connector Functions). Soprattutto quando il fenomeno è coordinato tra più stazioni che si riconnettono a causa di un problema di connettività di rete condiviso. Questo flusso di "recupero" può essere fonte di notevole rallentamento e sovraccarico, e può anche portare a limitazioni dell’API (errori HTTP 429) e ulteriori malfunzionamenti.

In che modo i problemi di rete causano la perdita di dati nella coda dei trigger

Per comprendere questo rischio, è essenziale sapere come vengono eseguiti i trigger. Vedere Trigger per i dettagli.* Coda a thread singolo: il runtime dei trigger di Tulip opera su una coda sequenziale a thread singolo. Ogni evento di trigger (ad es. “pulsante premuto”) viene aggiunto a questa coda e deve completare tutte le sue azioni prima che l’evento successivo nella coda possa anche solo iniziare.* "Intasamento" di rete: un'interruzione di rete o una grave instabilità fa sì che le azioni all’interno di un trigger (come “Crea record tabella” o “Esegui Connector Function ”) si blocchino o entrino in uno stato di riprova prolungato. Ad esempio, a partire dalla versione LTS15, un’azione sulla tabella che fallisce verrà riprovata per un massimo di 2 minuti.* Il collo di bottiglia: questo singolo trigger lento blocca l’intera coda. Mentre è bloccata, le azioni successive dell’operatore (ad es. altre 99 pressioni di pulsanti) riempiono la coda.* Eventi scartati: una volta raggiunto il limite della coda (100 eventi per impostazione predefinita), tutti gli eventi successivi vengono annullati e scartati. Ciò significa che se un operatore scansiona un 101° articolo durante l’interruzione di rete, quell’evento va perso per sempre e non verrà elaborato al ripristino della rete.

Anche al di fuori di una coda piena, l’instabilità generale della rete può causare il fallimento delle singole chiamate all’API ( Connector Functions ). Queste azioni non vengono riprovate (a differenza delle azioni sulle tabelle in LTS15) e possono portare a errori silenziosi nei dati e a problemi di integrità.

Fattori di rischio per la perdita di dati

Il rischio di perdita di dati in caso di scarsa connettività di rete non è uniforme. Esso aumenta notevolmente a causa delle architetture delle app caratterizzate da un elevato numero di eventi. Scopri qui le migliori pratiche per queste app.

Il rischio è molto più elevato se le tue app presentano:* Un’elevata frequenza di eventi: app che generano molti eventi in breve tempo. Ciò include la scansione rapida di codici a barre, input frequenti da parte dei dispositivi o trigger a tempo che si attivano a intervalli brevi (ad esempio, ogni 30 secondi).* Trigger complessi: trigger che eseguono molte azioni sequenziali, in particolare chiamate API multiple (Connector Functions) o scritture in tabelle. Ogni azione che dipende dalla rete contribuisce al potenziale tempo di “blocco” durante un’interruzione.* Dipendenza dall’ Connector Functions: utilizzo dell’ Connector Functions per l’acquisizione di dati critici. Un’ Connector Function fallita a causa di un’interruzione temporanea della rete non verrà riprovata e causerà il fallimento del trigger, il che può arrestare il processo o portare alla perdita di dati. Utilizzate automazioni (e/o funzioni) ove possibile.

Conformità ALCOA per il settore delle scienze della vita

Per i clienti del settore delle scienze della vita e di altri ambienti regolamentati da GxP, questi rischi di rete non sono solo problemi di prestazioni; sono minacce dirette all’integrità dei dati e alla conformità.

I rischi tecnici sopra descritti si ricollegano direttamente ai principi ALCOA:* Inaccuratezza e incompletezza: quando durante un’interruzione viene raggiunto il limite della coda di trigger, tutti gli eventi successivi vengono definitivamente scartati. Se un operatore scansiona il 101° elemento, quell’evento va perso per sempre. Il record di lotto risultante è fondamentalmente inaccurato e incompleto.* Mancanza di contemporaneità: Quando la connettività viene ripristinata, il flusso di “recupero” esegue un arretrato di eventi in coda, spesso minuti dopo che l’operatore ha eseguito l’azione. Un revisore che esamini un gruppo di timestamp chiaramente ritardati rispetto al processo reale metterebbe in discussione l’integrità di contemporaneità del record.* Inaccurato (tra i sistemi): Connector Functions (chiamate API) non dispongono di tentativi di riprova integrati. Un’interruzione temporanea della rete può far sì che un trigger riesca a scrivere correttamente in una tabella Tulip (il record originale), ma non riesca ad aggiornare un MES o un QMS esterno. Ciò comporta uno stato dei dati impreciso e non sincronizzato tra i sistemi convalidati.

Seguire le raccomandazioni architetturali riportate nella sezione successiva è essenziale per costruire un processo robusto e verificabile che protegga da errori di integrità dei dati.

Requisiti di rete quantificabili

Per prevenire i blocchi della coda di trigger, la perdita di eventi e le violazioni dell’integrità dei dati discussi in precedenza, ogni stazione Tulip Player deve mantenere una connessione persistente e di alta qualità. Le quattro dimensioni seguenti definiscono questo requisito.

Larghezza di banda (throughput)

Si tratta della "dimensione" della connessione, che impedisce la saturazione. Sebbene i payload dei dati delle applicazioni siano spesso di piccole dimensioni, una larghezza di banda insufficiente crea latenza e perdita di pacchetti, il che a sua volta blocca la coda dei trigger.

• Raccomandazione: 15 Mbps per ogni stazione attiva.
• Minimo assoluto: 10 Mbps per stazione attiva, oppure la larghezza di banda richiesta calcolata, a seconda di quale dei due valori sia maggiore.
• Limite quantificabile: la larghezza di banda minima deve superare la velocità di trasmissione dati di base (BDR) dell’applicazione, moltiplicata per un fattore di margine ($H$) di almeno 2,0 (100%) per tenere conto del sovraccarico di rete e delle ritrasmissioni.
  • $R_{peak}$ = Frequenza di picco degli eventi (eventi al secondo)
  • $S_{event}$ = carico utile medio dei dati per evento (byte, inclusi tutti i dati inviati e ricevuti dal trigger)
  • $H$ = fattore di margine (adimensionale), per cui si raccomanda $H > 2,0$

Calcolare innanzitutto la velocità di trasmissione dati di base (BDR) in bit al secondo:* $BDR (bps)=R_{peak}\times S_{event}\times 8$

Quindi calcolare la larghezza di banda richiesta: * $Larghezza di banda richiesta (bps) = BDR \times H = R_{peak} \times S_{event} \times 8 \times H$

In pratica, se questo valore calcolato è inferiore a 10 Mbps, è comunque consigliabile prevedere almeno 10 Mbps per ogni stazione attiva (e preferibilmente 15 Mbps) per garantire la compatibilità futura, fornire un ampio margine e tenere conto di altro traffico sullo stesso collegamento.

Esempio

Se la frequenza di picco degli eventi nel caso peggiore della propria app è $R_{peak}=2\text{ eventi}/s$ e ogni evento invia e riceve circa $S_{event}=5.000 byte$, allora:* $BDR=2\times 5.000\times 8=80.000 bps$* $Larghezza di banda richiesta (H=2,0)=160.000 bps=0,16 Mbps$

Sebbene il fabbisogno calcolato sia basso, prevediamo comunque almeno 10-15 Mbps per stazione.

Latenza (tempo di andata e ritorno)

Si tratta del ritardo che un pacchetto impiega per raggiungere il server e tornare indietro. Un’elevata latenza aumenta direttamente il tempo di esecuzione di ogni azione di trigger dipendente dalla rete (come una scrittura in tabella o un’ connector function), rendendo l’intera coda vulnerabile al blocco.

• Raccomandazione: < 80 ms
• Massimo assoluto: 100 ms (verso il proprio dominio [istanza].tulip.co).
• Limite quantificabile: la latenza determina direttamente la durata delle azioni dipendenti dalla rete all’interno di un trigger. Per evitare l’accumulo nella coda dei trigger, il tempo totale di esecuzione dei trigger determinato dalle azioni di rete deve essere significativamente inferiore al tempo tra gli eventi.

Siano:* $R_{peak}$ = frequenza di picco degli eventi (eventi al secondo)* $T_{between}$ = tempo tra gli eventi (secondi).* $N_{net}$ = numero di azioni di rete sequenziali nel trigger (ad es., scritture in tabella, chiamate al connettore)* $RTT_{avg}$ = latenza media di andata e ritorno (secondi)

L’intervallo di tempo tra gli eventi è:* $T_{between}=\frac{1}{R_{peak}}$

Una semplice approssimazione del tempo di attivazione dovuto alla latenza di rete è:* $T_{trigger,net}=N_{net}\times RTT_{avg}$

Per mantenere una coda in buone condizioni, è necessario che il tempo di attivazione determinato dalla rete sia ben al di sotto del tempo tra gli eventi.Una regola empirica pratica è:* $N_{net}\times RTT_{avg}\leq 0,25\times T_{between}$* $N_{net}\times RTT_{avg}\leq \frac{0,25}{R_{peak}}$

In altre parole: la somma di tutti i round-trip di rete sequenziali in un trigger dovrebbe essere inferiore a un quarto del tempo previsto tra gli eventi dell’operatore al picco di carico. Se questa condizione non viene soddisfatta, la coda si accumulerà gradualmente fino a raggiungere il limite di 100 eventi. Per ottenere prestazioni più affidabili, si consiglia di mantenere $N_{net}\times RTT_{avg}\lt \lt \frac{0,1}{R_{peak}}$

Jitter (variazione della latenza)

Si tratta della variazione della latenza. Una connessione con jitter elevato è instabile; un picco improvviso di latenza su un singolo pacchetto può bloccare un trigger con la stessa efficacia di una latenza media elevata, bloccando la coda e causando arresti «casuali» e perdita di eventi.

• Limite quantificabile: il jitter è la variazione della latenza nel tempo. Un singolo picco di latenza può bloccare un trigger con la stessa efficacia di una latenza costantemente elevata.

Siano:* $RTT_{avg}$ = latenza media di andata e ritorno in una finestra di campionamento (secondi)* $RTT_max$ = latenza massima osservata di andata e ritorno nella stessa finestra (secondi)

Definiamo:* $Jitter=RTT_{max}-RTT_{avg}$

Questo valore deve essere mantenuto basso per garantire prestazioni prevedibili dei trigger. Per le implementazioni Tulip:* Raccomandazione: $Jitter$ < 10 ms * Massimo assoluto: $Jitter$ < 30 ms

Se il jitter misurato si avvicina o supera i 30 ms, gli operatori noteranno blocchi “casuali” e i trigger potrebbero rimanere in esecuzione abbastanza a lungo da bloccare la coda.

Affidabilità (perdita di pacchetti e tempo di attività)

Questa è la dimensione più critica per l’integrità dei dati. La perdita di pacchetti costringe a ritrasmissioni, che possono bloccare un trigger per alcuni secondi, causando gravi intasamenti della coda. Le disconnessioni (interruzioni del tempo di attività) sono catastrofiche, portando a una coda piena (100 eventi) e alla perdita permanente di tutti i dati successivi, garantendo registrazioni incomplete.

• Raccomandazione: 0% di perdita di pacchetti e operatività costante.
• Massimo assoluto: < 0,1% di perdita di pacchetti.
• **Limite quantificabile:**la coda del trigger può contenere solo un numero limitato di eventi. Quando la rete è inattiva, le azioni dell’operatore continuano a generare eventi fino a quando la coda non è piena. Una volta che la coda raggiunge il suo limite, tutti gli eventi successivi vengono scartati e persi definitivamente.

Siano:* $Q_{max}$ = dimensione massima della coda (eventi). Attualmente $Q_{max}=100$ per impostazione predefinita.* $R_{peak}$ = frequenza di picco degli eventi durante un'interruzione (eventi al secondo).

La durata massima tollerabile dell’interruzione prima che gli eventi inizino a essere scartati è:* $T_{outage,max}=\frac{Q_{max}}{R_{peak}}$

Esempio: per un’app con un’elevata frequenza di eventi pari a $R_{peak}=2$ eventi/sec (ad es., valori di coppia in rapida variazione):* $T_{outage,max}=\frac{100}{2}=50$ secondi

In questo esempio, qualsiasi interruzione di rete continua superiore a 50 secondi causerà la perdita di dati: ogni evento successivo ai primi 100 verrà scartato e non verrà mai elaborato, anche dopo il ripristino della rete.

Questa semplice relazione è fondamentale per la valutazione del rischio: le app con un’elevata frequenza di eventi tollerano solo interruzioni molto brevi prima che l’integrità dei dati venga compromessa.

Raccomandazioni relative all’infrastruttura fisica

Il rispetto dei requisiti di rete quantificabili non riguarda solo il proprio ISP; dipende in larga misura dall’infrastruttura di rete fisica interna della propria struttura.

Raccomandazione predefinita: Ethernet cablata

Per ottenere la stabilità, l’affidabilità e i parametri di bassa latenza definiti nella sezione precedente, una connessione Ethernet cablata è la raccomandazione principale e predefinita per tutte le stazioni fisse di Tulip Player.

Tuttavia, questa non è una soluzione del tipo “imposta e dimentica”. Il livello fisico è un punto di guasto comune e spesso trascurato che può causare una perdita di pacchetti intermittente e difficile da diagnosticare.

• Integrità fisica dei cavi: i team IT e operativi devono gestire in modo proattivo questa infrastruttura. Ispezionare regolarmente i cavi per verificare la presenza di difetti, sfilacciature o connessioni allentate. Una causa comune di guasto è rappresentata da un carrello che passa ripetutamente sopra un cavo non schermato o posato in modo inadeguato.
• Interferenze elettromagnetiche (EMI): in un reparto di produzione, macchinari ad alta vibrazione, motori o apparecchiature ad alta tensione possono causare interferenze significative. In questi ambienti , utilizzare cavi Ethernet schermati (ad es. STP, Cat6a o superiori) per proteggersi dal degrado del segnale.

Considerazioni relative al Wi-Fi e ai dispositivi mobili

Siamo consapevoli che molti clienti utilizzano dispositivi mobili (tablet, telefoni) o carrelli mobili laddove non è possibile una connessione cablata. In questi scenari, una connessione Wi-Fi stabile è un prerequisito per l’integrità dei dati.

• Progettazione della rete: è necessario garantire una rete wireless robusta e progettata in modo professionale. L’obiettivo è una copertura senza soluzione di continuità, senza lacune di copertura (che causano disconnessioni) e con una sovrapposizione minima tra i punti di accesso (AP). Una sovrapposizione eccessiva può far sì che un dispositivo "passi da un AP all’altro", costringendo a una rinegoziazione DHCP e causando un blocco della rete che blocca la coda di trigger.
• Interferenze: il Wi-Fi è inoltre altamente suscettibile alle interferenze elettromagnetiche (EMI) provenienti dai macchinari. La progettazione della rete deve tenerne conto.
• Rischio maggiore: poiché una connessione wireless è intrinsecamente meno stabile di una cablata, è ancora più fondamentale che le applicazioni su questi dispositivi seguano le raccomandazioni della Resilient App Architecture (come la logica di disaccoppiamento) per proteggersi dagli inevitabili sbalzi di rete.
• I sistemi operativi mobili possono sospendere o limitare in modo aggressivo le app in background per risparmiare batteria. Tulip Player dovrebbe essere esentato da tali politiche mentre è in uso (è preferibile la modalità chiosco/app bloccata).

Lista di controllo dell’infrastruttura fisica

Stazioni cablate

• [ ] Tipo di cavo: tutti i Tulip Player fissi utilizzano cavi Ethernet schermati (STP, Cat6a o superiori) in aree ad alta interferenza elettromagnetica (motori, azionamenti, saldatrici, ecc.).
• [ ] Percorso dei cavi: nessun cavo passa dove carrelli, carrelli elevatori o sedie ci passano regolarmente sopra; i cavi vengono instradati attraverso canaline, condotti o in alto, ove possibile.
• [ ] Integrità dei cavi: esiste un programma di ispezione documentato (ad es. trimestrale) per verificare la presenza di sfilacciature, attorcigliamenti, guaine schiacciate e connessioni allentate.
• [ ] Terminazioni: tutti i connettori e i pannelli di permutazione sono correttamente terminati e dotati di sistemi di scarico della trazione; non vengono utilizzati cavi di collegamento “temporanei” come collegamenti permanenti.
• [ ] Porte degli switch: le porte dei player sono bloccate su velocità/duplex appropriate e non condividono uplink sovraccarichi che si saturano regolarmente.
• [ ] Alimentazione / PoE: se si utilizza il PoE, il budget di potenza dello switch non è sovraccarico; eventuali cali di tensione o eventi di reset vengono monitorati e segnalati tramite allarme.
• [ ] Monitoraggio: il monitoraggio di base degli switch (CPU, memoria, errori di interfaccia e utilizzo) è abilitato e viene verificato periodicamente.

WiFi e dispositivi mobili

• [ ] Progettazione professionale: la rete wireless è stata progettata (o almeno sottoposta a sopralluogo) in modo professionale per l’area di produzione in cui operano i dispositivi Tulip.
• [ ] Copertura: la potenza del segnale misurata lungo l’intero percorso dell’operatore (il “percorso a piedi”) mostra una copertura continua senza zone morte che causino disconnessioni o “cadute libere” durante il roaming.
• [ ] Sovrapposizione degli AP: gli access point sono posizionati in modo da ridurre al minimo un’eccessiva sovrapposizione; i client non “passano da un AP all’altro” mentre sono fermi.
• [ ] Comportamento di roaming: le soglie di roaming e il band steering sono ottimizzati in modo che i dispositivi cambino AP senza intoppi, senza ripetute rinegoziazioni DHCP o brevi interruzioni.
• [ ] Interferenze: nella pianificazione dei canali sono state prese in considerazione le fonti note di interferenze elettromagnetiche (macchinari, saldatrici, motori di grandi dimensioni, collegamenti a microonde, ecc.).
• [ ] Segmentazione: i dispositivi Tulip si trovano su un SSID/VLAN dedicato per i sistemi di produzione, non mescolati con il Wi-Fi per gli ospiti o con dispositivi consumer ad alto turnover.
• [ ] Backhaul: gli AP dispongono di uplink affidabili e non congestionati; il WiFi gestito da controller o dal cloud non opera al limite della capacità.
• [ ] App resilienti: le app in esecuzione su dispositivi Wi-Fi/mobili seguono in modo più rigoroso l’architettura delle app resilienti per tenere conto del rischio intrinsecamente più elevato della connettività wireless.

Test

Percorrere un itinerario con un Player su cui è in esecuzione networkCheck e i propri strumenti diagnostici, assicurandosi che non si verifichino disconnessioni o picchi oltre la soglia per 10 minuti.

Infrastruttura logica e di sicurezza (proxy, firewall e DPI)

Oltre ai cavi fisici, l’infrastruttura logica di sicurezza di rete è la fonte più comune di latenza “misteriosa”, jitter e errori di connessione.

• Proxy e firewall come colli di bottiglia: i dispositivi di sicurezza (firewall, proxy, CASB, ecc.) che eseguono l’ispezione approfondita dei pacchetti (DPI) o la decrittografia SSL/TLS su tutto il traffico sono una fonte primaria di instabilità. Questo processo di ispezione aggiunge di per sé una latenza significativa e variabile (jitter) a ogni singola richiesta di rete, il che può facilmente violare i requisiti di latenza <100 ms e jitter <30 ms.
• Monitorare lo stato di salute dei dispositivi: i team di rete devono monitorare l’utilizzo della CPU e della memoria di questi dispositivi. Un firewall o un proxy sovraccarico perderà pacchetti o introdurrà latenza, creando proprio quell’instabilità che porta alla perdita di dati.
• Non interferire con il traffico Tulip: la comunicazione client-cloud di Tulip si basa su protocolli web specifici, inclusi i WebSocket sicuri, per il trasferimento dei dati in tempo reale. Alcune soluzioni di sicurezza tentano di intercettare, riscrivere o “interferire” con questo traffico HTTPS. Tale intercettazione può interrompere la connessione WebSocket o contrassegnare erroneamente le chiamate API standard come richieste cross-origin (CORS), causandone il fallimento.
• Requisito: tutti i domini Tulip (elencati nella sezione Allowlist ) devono essere configurati per il pass-through SSL/TLS. Il traffico deve essere escluso da qualsiasi DPI, ispezione dei protocolli o caching.

Lista di controllo

• [ ] Domini Tulip bypassati: tutti i domini Tulip elencati nella lista bianca (Allowlist) sono configurati per il pass-through SSL/TLS e sono esclusi dalla decrittografia/intercettazione SSL.
• [ ] Preferire l’assenza di DPI e di riscrittura del protocollo: l’ispezione approfondita dei pacchetti (DPI), la riscrittura del protocollo HTTP e la memorizzazione nella cache dei contenuti sono disabilitate per il traffico Tulip, in particolare per i WebSocket.
• [ ] Supporto WebSocket: i firewall e i proxy consentono connessioni WebSocket di lunga durata sulla porta 443 senza timeout di inattività brevi o reset forzati.
• [ ] Monitoraggio della capacità: vengono monitorati CPU, memoria e throughput sugli apparecchi di sicurezza; sono attivi avvisi in caso di utilizzo elevato prolungato che potrebbe causare latenza o perdita di pacchetti.
• [ ] Regole di uscita: le regole in uscita consentono esplicitamente gli intervalli IP e i nomi host di Tulip (per identificatore di giardino), inclusi gli endpoint di archiviazione delle risorse (S3/Blob).
• [ ] Comportamento «fail-open»: ove possibile, il traffico Tulip è configurato per il comportamento «fail-open» (ovvero con errori chiari e registrati), anziché scartare i pacchetti in modo silenzioso.
• [ ] Controllo delle modifiche: qualsiasi modifica alla configurazione del firewall o del proxy che possa influire su Tulip viene tracciata e, idealmente, testata su https://your-account.tulip.co/networkCheck durante le finestre di modifica.

Architettura resiliente delle applicazioni

Questa sezione spiega come gli sviluppatori possono mitigare i rischi legati all’infrastruttura.

Gli sviluppatori devono progettare applicazioni resilienti a problemi di rete intermittenti. È fondamentale garantire un margine di tolleranza per la latenza di rete e il degrado minore della piattaforma. Utilizzare automazioni (e/o funzioni, ove possibile).

• Dare priorità alle operazioni di scrittura nelle tabelle Tulip: per tutte le acquisizioni di dati critici, utilizzare innanzitutto nel trigger le azioni native di Tulip Table "Create Record" o "Store". Queste azioni sono più resilienti ai cali di rete e dispongono di una logica di riprova integrata (fino a 2 minuti in LTS15).
• Ridurre al minimo la frequenza degli eventi: rivedere la progettazione dell’applicazione. Se un operatore può ragionevolmente generare 100 eventi (ad esempio, scansioni) durante un’interruzione di rete di 2 minuti, l’architettura è ad alto rischio. Valutare la possibilità di raggruppare gli input o semplificare il flusso di lavoro.
• Segui le best practice relative alle prestazioni: attieniti alle linee guida documentate per le app ad alte prestazioni disponibili qui. Sovraccaricare la piattaforma con chiamate ad alta frequenza crea una latenza interna che simula una rete scadente.

Vedi anche: Trigger delle app basati sugli eventi tramite la macchina «virtuale» Tulip

Lista di controllo

• [ ] Prima le tabelle: tutti i dati critici acquisiti (scansioni, decisioni degli operatori, misurazioni) vengono scritti innanzitutto in una tabella Tulip.
• [ ] Nessuna chiamata API di lunga durata nei trigger per gli operatori: i trigger destinati agli operatori non contengono logiche API esterne complesse né operazioni di elaborazione in background ( Connector Functions ) di lunga durata.
• [ ] Modello di disaccoppiamento: ove possibile, si preferiscono le automazioni per effettuare chiamate alle API esterne.
• [ ] Campi di stato: le tabelle di elaborazione utilizzano campi di stato chiari (in sospeso, in elaborazione, elaborato, errore) in modo che gli errori possano essere riprovati o analizzati.
• [ ] Frequenza degli eventi controllata: la progettazione dell’app non consente agli operatori di generare frequenze di eventi sostenute che riempirebbero la coda durante brevi interruzioni di servizio (vedere il calcolo delle interruzioni sopra).
• [ ] Timer e cicli: i trigger dei timer e i cicli non vengono attivati a intervalli inutilmente brevi (ad es. ogni 1-5 secondi) a meno che non siano assolutamente necessari e convalidati.
• [ ] Gestione degli errori dei connettori: i connettori ( Connector Functions ) che possono fallire a causa di problemi di rete dispongono di meccanismi di gestione degli errori e di riprova (preferibilmente tramite Automazioni, non tramite trigger degli operatori).
• [ ] Best practice sulle prestazioni: le app rispettano le best practice di Tulip per le app ad alte prestazioni.

Configurazione tecnica e risoluzione dei problemi

Se la vostra rete non soddisfa i requisiti quantificabili sopra indicati, o se riscontrate problemi di prestazioni che sospettate siano legati alla rete, seguite i passaggi indicati nella nostra guida dettagliata. Questa guida fornisce un diagramma di flusso con ordine di priorità per la diagnosi e la risoluzione dei problemi di prestazioni di rete, dai controlli di base all’analisi avanzata a livello di pacchetti.

Consulta qui la guida completa alla risoluzione dei problemi di rete.

Utilità di test di rete e WebSocket

Tulip fa ampio uso dei WebSocket, un tipo di connessione a lunga durata, per consentire aggiornamenti in tempo reale. Questi WebSocket utilizzano la crittografia SSL sulla porta 443. Alcuni proxy non supportano queste connessioni e alcuni monitor di rete potrebbero doverle autorizzare esplicitamente. Si prega di consultare la sezione precedente per verificare la compatibilità.

È disponibile una semplice utility che consente di testare la latenza della connessione di rete e la compatibilità con i WebSocket:

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

Lista di controllo per la messa in servizio e il monitoraggio continuo

• [ ] Test iniziale: per ogni nuova stazione, esegui https://your-account.tulip.co/networkCheck (o l'URL di DMG MORI / Serendie) e le tue verifiche diagnostiche per almeno 10-15 minuti durante il normale carico di produzione.
• [ ] Registrazione delle metriche: rilevare la latenza media, minima e massima, il jitter e qualsiasi perdita di pacchetti osservata; verificare che rispettino le soglie indicate in questo articolo.
• [ ] Test a carico di picco: ripetere il test durante un periodo noto di carico di picco sulla rete dello stabilimento (cambio turno, elaborazione di lotti di grandi dimensioni) per garantire la stabilità in condizioni di stress.
• [ ] Test di regressione dopo le modifiche: rieseguire il test dopo qualsiasi modifica significativa alla configurazione di rete, Wi-Fi, firewall o proxy che influisca su Tulip.
• [ ] Archiviazione dei dati di riferimento: archiviare i risultati dei test (screenshot o esportazioni) come parte della documentazione di convalida/messa in servizio.
• [ ] Verifica periodica: pianificare ripetizioni periodiche dei test (ad es. trimestrali) per le stazioni critiche o quando vengono distribuite nuove applicazioni con frequenze di eventi più elevate.

Hai trovato quello che cercavi?

Puoi anche visitare community.tulip.co per pubblicare la tua domanda o verificare se altri hanno avuto un problema simile!