Requisitos de estabilidade de rede e integridade de dados para implantações na nuvem do Tulip

Visão geral

É necessária uma conexão de rede estável e de alta qualidade para que as implantações do Tulip Cloud mantenham o desempenho em tempo real e a integridade dos dados. Este artigo define os requisitos de rede quantificáveis — largura de banda, latência, jitter e perda de pacotes — que uma implantação do Tulip deve atender, explica os riscos técnicos da instabilidade da rede (incluindo perda de dados na fila de acionadores e falhas de conformidade com o ALCOA) e fornece recomendações nos níveis físico, lógico e de aplicação para mitigar esses riscos.

A estabilidade é mais importante do que a velocidade bruta: uma conexão instável com alto jitter ou perda intermitente de pacotes pode causar perda silenciosa e permanente de dados, mesmo em links de alta largura de banda. Atender aos requisitos deste artigo requer uma abordagem em duas partes — infraestrutura robusta de TI/rede e arquitetura de aplicativos resiliente — trabalhando em conjunto.

Para obter a lista de domínios e endereços IP específicos a serem incluídos na lista de permissões da sua instância do Tulip Cloud, consulte os requisitos de rede para implantação do Tulip Cloud.

A quem se destina este artigo?

Este artigo é mais útil para usuários avançados do Tulip que estão realizando implantações em ambientes de grande escala. Se você está implantando o Tulip pela primeira vez em sua organização ou está atualmente em um período de teste, essas informações provavelmente são mais avançadas do que suas necessidades atuais.

Use os links à direita para navegar até o conteúdo do tópico desejado.

Resumo executivo

Este documento descreve os requisitos críticos de rede para garantir o desempenho, a estabilidade e a integridade dos dados de uma implantação do Tulip Cloud.

Pontos principais

A estabilidade é mais importante do que a velocidade: uma conexão com fio estável de 15 Mbps é muito superior a uma conexão instável de mais de 100 Mbps com alto jitter ou perda de pacotes.

A instabilidade da rede causa perda de dados: conexões intermitentes, alta latência ou perda de pacotes não causam apenas “lentidão”. Elas fazem com que a fila de acionadores fique congestionada e perca eventos, levando à perda permanente de dados e a falhas críticas na integridade dos dados (ALCOA).

A mitigação requer uma solução em duas partes: são necessárias tanto uma infraestrutura de TI robusta (que atenda aos requisitos abaixo) quanto uma arquitetura de aplicativos resiliente (por exemplo, desacoplamento da lógica por meio de automações).

Políticas de infraestrutura crítica

Padrão para Ethernet com fio: Todos os Tulip Players fixos devem usar Ethernet com fio e blindada.

Configure e monitore proxies e firewalls: todos os domínios Tulip listados na Lista de Permitidos devem ser configurados para passagem de SSL/TLS (consulte Lista de Permitidos). A Inspeção Profunda de Pacotes (DPI) deve ser minimizada, e o desempenho do firewall e do proxy deve ser monitorado de forma proativa.

Lista de verificação de prontidão de rede por estação

Para cada estação do Tulip Player, verifique:* [ ] Tipo de conexão: os Players fixos utilizam Ethernet com fio e blindada (STP, Cat6a ou superior).* [ ] Largura de banda: pelo menos 15 Mbps disponíveis para download e upload; nunca abaixo de 10 Mbps por estação ativa ou do mínimo calculado (consulte Requisitos de rede quantificáveis)* [ ] Latência: a latência média de ida e volta (RTT) para your-instance.tulip.co é < 80 ms; o RTT máximo é < 100 ms*[ ] Jitter: O jitter ($RTT_{max}-RTT_{avg}$) é < 10 ms (e sempre < 30 ms)* [ ] Perda de pacotes: A perda de pacotes medida é de 0% durante a operação normal e < 0,1% em testes de pior cenário.* [ ] Tempo de atividade: O caminho do Player até o Tulip Cloud não depende de conexões instáveis (Wi-Fi ad hoc, redes de visitantes, VPNs com quedas frequentes etc.)* [ ] Proxies/firewalls: Todos os domínios da Tulip na lista de permissões estão configurados para passagem direta de SSL/TLS, sem interceptação de SSL, reescrita de protocolo, adulteração ou armazenamento em cache e, de preferência, sem DPI.* [ ] WebSockets: Proxies e firewalls permitem conexões WebSocket de longa duração pela porta 443, sem problemas de tempo limite de inatividade ou reinicialização da conexão.
[ ] Atividade do processo*: Os dispositivos (especialmente os móveis) estão configurados para* evitar hibernação agressiva de processos em segundo plano*, otimização de bateria ou políticas do sistema operacional que suspendam o Tulip Player ou limitem solicitações de rede, conexões TCP ou conexões WebSocket enquanto estiverem em uso.* [ ]* Aplicativos resilientes*: os aplicativos críticos nesta estação seguem os* padrões** da arquitetura de aplicativos resilientes*(minimizar a taxa de eventos e chamadas de API em caminhos de acionamento críticos durante o fluxo de trabalho do operador, priorizar as Tulip Tables e minimizar conectores de longa duração).

Riscos de instabilidade e integridade dos dados

Esta seção explica por que uma conexão estável é fundamental e quais são os riscos técnicos que afetam o desempenho e a integridade dos dados.

Além do simples atraso nas mensagens, a conectividade intermitente ou a perda de pacotes podem levar a dois problemas principais: 1. Perda de eventos e perda de dados. Quandoa rede está instável ou offline, as ações do operador (como pressionamentos de botões, entradas de dispositivos ou leitura de códigos de barras) ainda geram eventos. Esses eventos se acumulam em uma fila. Como essa fila tem um limite finito (100 eventos por padrão), se for excedida enquanto se aguarda a recuperação da rede, todos os novos eventos recebidos são descartados e perdidos permanentemente. 2. Sobrecarga do sistema e lentidão por “recuperação”: quandoa conectividade é restaurada após uma interrupção, todo o acúmulo de eventos na fila (até 100) tentará ser executado em rápida sucessão. Isso pode causar uma carga repentina e massiva na plataforma Tulip e em quaisquer sistemas de terceiros conectados (via Connector Functions). Especialmente quando coordenado entre várias estações que se reconectam devido a um problema de conectividade de rede compartilhada. Esse fluxo de “recuperação” pode ser uma fonte de lentidão e sobrecarga substanciais, além de poder levar à limitação da API (erros HTTP 429) e a outras falhas.

Como problemas de rede causam perda de dados na fila de gatilhos

Para compreender esse risco, é essencial saber como os gatilhos são executados. Consulte Gatilhos para obter detalhes.* Fila de thread único: o ambiente de execução de gatilhos do Tulip opera em uma fila sequencial de thread único. Cada evento de gatilho (por exemplo, “botão pressionado”) é adicionado a essa fila e deve concluir todas as suas ações antes que o próximo evento na fila possa sequer começar.* “Congestionamento” de rede: Uma interrupção na rede ou instabilidade grave faz com que as ações dentro de um gatilho (como “Criar registro na tabela” ou “Executar Connector Function ”) fiquem travadas ou entrem em um longo estado de repetição de tentativa. Por exemplo, a partir da versão LTS15, uma ação de tabela com falha tentará novamente por até 2 minutos.* O gargalo: Esse único gatilho lento bloqueia toda a fila. Enquanto estiver bloqueada, as ações subsequentes do operador (por exemplo, mais 99 pressionamentos de botão) enchem a fila.* Eventos descartados: assim que o limite da fila é atingido (padrão de 100 eventos), todos os eventos adicionais são cancelados e descartados. Isso significa que, se um operador escanear o 101º item durante a interrupção da rede, esse evento será perdido para sempre e não será processado quando a rede voltar a funcionar.

Mesmo quando a fila não está cheia, a instabilidade geral da rede pode fazer com que chamadas individuais à API ( Connector Functions ) falhem. Essas ações não são repetidas (ao contrário das ações em tabelas no LTS15) e podem levar a falhas silenciosas de dados e problemas de integridade.

Fatores de risco para perda de dados

O risco de perda de dados durante uma conectividade de rede precária não é uniforme. Ele aumenta substancialmente em arquiteturas de aplicativos que são “ricas em eventos”. Saiba mais sobre as práticas recomendadas para esses aplicativos aqui.

Você corre um risco muito maior se seus aplicativos tiverem:* Alta taxa de eventos: aplicativos que geram muitos eventos em um curto período de tempo. Isso inclui leitura rápida de códigos de barras, entradas frequentes de dispositivos ou acionamentos de temporizador em intervalos curtos (por exemplo, a cada 30 segundos).* Gatilhos complexos: gatilhos que executam muitas ações sequenciais, especialmente múltiplas chamadas de API (Connector Functions) ou gravações em tabelas. Cada ação dependente da rede aumenta o tempo potencial de “congestionamento” durante uma interrupção.* Dependência de Connector Functions: uso de Connector Functions para captura de dados críticos. Uma chamada Connector Function com falha devido a uma oscilação na rede não será repetida e fará com que o acionador falhe, o que pode interromper o processo ou levar à perda de dados. Use automações (e/ou funções) sempre que possível.

Conformidade com ALCOA para ciências da vida

Para clientes do setor de Ciências da Vida e outros ambientes regulados por GxP, esses riscos de rede não são apenas questões de desempenho; são ameaças diretas à integridade dos dados e à conformidade.

Os riscos técnicos descritos acima se relacionam diretamente aos princípios ALCOA:* Impreciso e incompleto: quando o limite da fila de acionadores é atingido durante uma interrupção, todos os eventos subsequentes são descartados permanentemente. Se um operador escanear o 101º item, esse evento será perdido para sempre. O registro de lote resultante é fundamentalmente impreciso e incompleto.* Não contemporâneo: Quando a conectividade é restaurada, a enxurrada de “recuperação” executa um acúmulo de eventos em fila, muitas vezes minutos depois que o operador realizou a ação. Um auditor que analise um conjunto de carimbos de data e hora claramente atrasados em relação ao processo real questionaria a integridade de contemporaneidade do registro.* Impreciso (entre sistemas): Connector Functions (chamadas de API) não possuem tentativas de repetição integradas. Uma falha momentânea na rede pode fazer com que um gatilho consiga gravar com sucesso em uma tabela do Tulip (o registro original), mas falhe ao atualizar um MES ou QMS externo. Isso resulta em um estado de dados impreciso e fora de sincronia entre seus sistemas validados.

Seguir as recomendações arquitetônicas da próxima seção é essencial para construir um processo robusto e validável que proteja contra falhas de integridade de dados.

Requisitos quantificáveis de rede

Para evitar os bloqueios na fila de acionadores, eventos perdidos e falhas de integridade de dados discutidos anteriormente, cada estação do Tulip Player deve manter uma conexão persistente e de alta qualidade. As quatro dimensões a seguir definem esse requisito.

Largura de banda (taxa de transferência)

Esse é o “tamanho” da conexão, que evita a saturação. Embora as cargas úteis de dados dos aplicativos sejam frequentemente pequenas, a largura de banda insuficiente gera latência e perda de pacotes, o que, por sua vez, bloqueia a fila de acionadores.

• Recomendação: 15 Mbps por estação ativa.
• Mínimo absoluto: 10 Mbps por estação ativa ou a Largura de Banda Necessária calculada, o que for maior.
• Limite quantificável: a largura de banda mínima deve exceder a Taxa de Dados Básica (BDR) do aplicativo, multiplicada por um Fator de Margem ($H$) de pelo menos 2,0 (100%) para compensar a sobrecarga da rede e as retransmissões.
  • $R_{peak}$ = Taxa de Pico de Eventos (eventos por segundo)
  • $S_{event}$ = Carga útil média de dados por evento (bytes, incluindo todos os dados enviados e recebidos pelo gatilho)
  • $H$ = fator de margem (adimensional), sendo recomendado que $H > 2,0$

Primeiro, calcule a Taxa de Dados Básica (BDR) em bits por segundo:* $BDR (bps) = R_{pico} \times S_{evento} \times 8$

Em seguida, calcule a largura de banda necessária: * $Largura de banda necessária (bps) = BDR \times H = R_{pico} \times S_{evento} \times 8 \times H$

Na prática, se esse valor calculado for inferior a 10 Mbps, você ainda deve provisionar pelo menos 10 Mbps por estação ativa (e, de preferência, 15 Mbps) para garantir compatibilidade futura, proporcionar margem ampla e levar em conta outro tráfego no mesmo link.

Exemplo

Se a taxa de eventos de pico no pior caso do seu aplicativo for $R_{pico}=2\text{ eventos}/s$ e cada evento enviar e receber cerca de $S_{evento}=5.000 bytes$, então:* $BDR=2\times 5.000\times 8=80.000 bps$* $Largura de banda necessária (H=2,0)=160.000 bps=0,16 Mbps$

Embora a necessidade calculada seja baixa, ainda assim provisionamos pelo menos 10 a 15 Mbps por estação.

Latência (tempo de ida e volta)

Trata-se do atraso que um pacote sofre ao viajar até o servidor e voltar. Uma alta latência aumenta diretamente o tempo de execução de todas as ações de acionamento dependentes da rede (como uma gravação em tabela ou um connector function), tornando toda a fila vulnerável a bloqueios.

• Recomendação: < 80 ms
• Máximo absoluto: 100 ms (para o seu domínio [instância].tulip.co).
• Limite quantificável: a latência determina diretamente quanto tempo as ações dependentes da rede levam dentro de um gatilho. Para evitar o acúmulo na fila de gatilhos, o Tempo Total de Execução do Gatilho contribuído pelas ações de rede deve ser significativamente menor do que o tempo entre eventos.

Seja:* $R_{peak}$ = taxa de pico de eventos (eventos por segundo)* $T_{between}$ = tempo entre eventos (segundos).* $N_{net}$ = número de ações de rede sequenciais no gatilho (por exemplo, gravações em tabelas, chamadas de conectores)* $RTT_{avg}$ = latência média de ida e volta (segundos)

O tempo entre eventos é:* $T_{between}=\frac{1}{R_{peak}}$

Uma aproximação simples para o tempo de acionamento contribuído pela latência de rede é:* $T_{trigger,net}=N_{net}\times RTT_{avg}$

Para manter uma fila saudável, exigimos que o tempo de acionamento determinado pela rede seja bem inferior ao tempo entre eventos.Uma regra prática é:* $N_{net}\times RTT_{avg}\leq 0,25\times T_{between}$* $N_{net}\times RTT_{avg}\leq \frac{0,25}{R_{peak}}$

Em outras palavras: a soma de todas as idas e voltas sequenciais da rede em um gatilho deve ser menor que um quarto do tempo esperado entre eventos do operador na carga de pico. Se essa condição não for atendida, a fila ficará gradualmente congestionada e, eventualmente, atingirá o limite de 100 eventos. Para obter o desempenho mais confiável, considere manter $N_{net}\times RTT_{avg}\lt \lt \frac{0,1}{R_{peak}}$

Jitter (variação de latência)

Trata-se da variação na latência. Uma conexão com alto jitter é instável; um pico repentino de latência em um único pacote pode travar um gatilho com a mesma eficácia que uma latência média elevada, bloqueando a fila e levando a travamentos “aleatórios” e eventos perdidos.

• Limite quantificável: O jitter é a variação na latência ao longo do tempo. Um único pico de latência pode travar um gatilho com a mesma eficácia que uma latência consistentemente alta.

Seja:* $RTT_{avg}$ = latência média de ida e volta em uma janela de amostragem (segundos)* $RTT_{max}$ = latência máxima observada de ida e volta na mesma janela (segundos)

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

Esse valor deve ser mantido baixo para garantir um desempenho previsível dos gatilhos. Para implantações do Tulip:* Recomendação: $Jitter$ < 10 ms * Máximo absoluto: $Jitter$ < 30 ms

Se o jitter medido se aproximar ou exceder 30 ms, os operadores observarão travamentos “aleatórios” e os gatilhos poderão permanecer em execução por tempo suficiente para bloquear a fila.

Confiabilidade (perda de pacotes e tempo de atividade)

Essa é a dimensão mais crítica para a integridade dos dados. A perda de pacotes força retransmissões, o que pode paralisar um gatilho por segundos, causando graves congestionamentos na fila. As desconexões (falhas no tempo de atividade) são catastróficas, levando a uma fila cheia (100 eventos) e à perda permanente de todos os dados subsequentes, garantindo registros incompletos.

• Recomendação: 0% de perda de pacotes e tempo de atividade contínuo.
• Máximo absoluto: < 0,1% de perda de pacotes.
• **Limite quantificável:**a fila do gatilho pode conter apenas um número limitado de eventos. Quando a rede está fora do ar, as ações do operador continuam a gerar eventos até que a fila fique cheia. Assim que a fila atinge seu limite, todos os eventos subsequentes são descartados e perdidos permanentemente.

Seja:* $Q_{max}$ = tamanho máximo da fila (eventos). Atualmente, $Q_{max}=100$ por padrão.* $R_{peak}$ = taxa de pico de eventos durante uma interrupção (eventos por segundo).

A duração máxima tolerável da interrupção antes que os eventos comecem a ser descartados é:* $T_{outage,max}=\frac{Q_{max}}{R_{peak}}$

Exemplo: Para um aplicativo com uma alta taxa de eventos de $R_{peak}=2$ eventos/seg (por exemplo, valores rápidos de torque):* $T_{outage,max}=\frac{100}{2}=50$ segundos

Nesse exemplo, qualquer interrupção contínua da rede com duração superior a 50 segundos causará perda de dados: todos os eventos após os primeiros 100 serão descartados e nunca processados, mesmo após a recuperação da rede.

Essa relação simples é crucial para a avaliação de riscos: aplicativos com alta taxa de eventos toleram apenas interrupções muito curtas antes que a integridade dos dados seja comprometida.

Recomendações de infraestrutura física

Atender aos requisitos quantificáveis de rede não depende apenas do seu provedor de internet; depende fortemente da infraestrutura física interna de rede das suas instalações.

Recomendação padrão: Ethernet com fio

Para atingir as métricas de estabilidade, confiabilidade e baixa latência definidas na seção anterior, uma conexão Ethernet com fio é a recomendação padrão e mais segura para todas as estações fixas do Tulip Player.

No entanto, essa não é uma solução do tipo “configure e esqueça”. A camada física é um ponto de falha comum e frequentemente negligenciado que pode causar perda de pacotes intermitente e difícil de diagnosticar.

• Integridade física dos cabos: as equipes de TI e de Operações devem gerenciar essa infraestrutura de forma proativa. Inspecione regularmente os cabos em busca de defeitos, fios desgastados ou conexões soltas. Uma fonte comum de falha é um carrinho passando repetidamente por cima de um cabo não blindado ou mal roteado.
• Interferência eletromagnética (EMI): no chão de fábrica, máquinas com alta vibração, motores ou equipamentos de alta tensão podem causar interferência significativa. Use cabos Ethernet blindados (por exemplo, STP, Cat6a ou superior) nesses ambientes para proteger contra a degradação do sinal.

Considerações sobre Wi-Fi e dispositivos móveis

Reconhecemos que muitos clientes utilizam dispositivos móveis (tablets, telefones) ou carrinhos móveis onde uma conexão com fio não é viável. Nesses cenários, uma conexão Wi-Fi estável é um pré-requisito para a integridade dos dados.

• Projeto de rede: é necessário garantir uma rede sem fio robusta e projetada profissionalmente. O objetivo é uma cobertura contínua, sem lacunas (que causam desconexões) e com o mínimo de sobreposição entre pontos de acesso (AP). A sobreposição excessiva pode fazer com que um dispositivo “oscile” entre os APs, forçando uma renegociação do DHCP e causando uma paralisação da rede que bloqueia a fila de acionamento.
• Interferência: o Wi-Fi também é altamente suscetível à interferência eletromagnética (EMI) proveniente de máquinas. O projeto da sua rede deve levar isso em consideração.
• Risco aumentado: Como uma conexão sem fio é inerentemente menos estável do que uma com fio, é ainda mais crítico que os aplicativos nesses dispositivos sigam as recomendações da Arquitetura Resiliente de Aplicativos (como a lógica de desacoplamento) para se protegerem contra as inevitáveis falhas de rede.
• Os sistemas operacionais móveis podem suspender ou limitar agressivamente os aplicativos em segundo plano para economizar bateria. O Tulip Player deve ser isento dessas políticas enquanto estiver em uso (o modo quiosque/aplicativo bloqueado é preferível).

Lista de verificação da infraestrutura física

Estações com fio

• [ ] Tipo de cabo: Todos os Tulip Players fixos utilizam Ethernet blindada (STP, Cat6a ou superior) em áreas com alta interferência eletromagnética (motores, acionamentos, soldadores etc.).
• [ ] Traçado dos cabos: Nenhum cabo passa por locais onde carrinhos, empilhadeiras ou cadeiras costumam passar por cima deles; os cabos são encaminhados por bandejas, conduítes ou por cima, sempre que possível.
• [ ] Integridade dos cabos: há um cronograma de inspeção documentado (por exemplo, trimestral) para verificar se há fios desgastados, dobras, revestimentos amassados e conexões soltas.
• [ ] Terminações: Todos os conectores e painéis de conexão estão devidamente terminados e com alívio de tensão; nenhum cabo de conexão “temporário” é utilizado como instalação permanente.
• [ ] Portas de switch: As portas dos players estão configuradas para a velocidade/duplex adequadas e não compartilham uplinks sobrecarregados que ficam regularmente saturados.
• [ ] Alimentação / PoE: Se for utilizado PoE, o orçamento de energia do switch não está sobrecarregado; quedas de tensão ou eventos de reinicialização são monitorados e acionam alarmes.
• [ ] Monitoramento: O monitoramento básico do switch (CPU, memória, erros de interface e utilização) está ativado e é revisado periodicamente.

Wi-Fi e dispositivos móveis

• [ ] Projeto profissional: A rede sem fio foi projetada profissionalmente (ou, pelo menos, avaliada) para a área de produção onde os dispositivos Tulip operam.
• [ ] Cobertura: A intensidade do sinal medida ao longo de todo o trajeto do operador (a “rota de deslocamento”) mostra cobertura contínua, sem zonas mortas que forcem desconexões ou “quedas livres” de roaming.
• [ ] Sobreposição de APs: Os pontos de acesso são posicionados de forma a minimizar a sobreposição excessiva; os clientes não “oscilam” entre os APs enquanto estão parados.
• [ ] Comportamento de roaming: Os limites de roaming e o direcionamento de banda são ajustados para que os dispositivos alternem entre pontos de acesso de maneira suave, sem renegociações repetidas de DHCP ou quedas breves.
• [ ] Interferência: Fontes conhecidas de EMI (máquinas, soldadores, motores de grande porte, links de micro-ondas etc.) foram consideradas no planejamento de canais.
• [ ] Segmentação: os dispositivos Tulip estão em um SSID/VLAN dedicado para sistemas de produção, sem mistura com o Wi-Fi para visitantes ou dispositivos de consumidores com alta rotatividade.
• [ ] Backhaul: os APs possuem uplinks confiáveis e sem congestionamento; o Wi-Fi gerenciado por controlador ou na nuvem não está operando próximo à capacidade máxima.
• [ ] Aplicativos resilientes: Os aplicativos em execução em dispositivos Wi-Fi/móveis seguem a arquitetura de aplicativos resilientes de forma mais rigorosa para levar em conta o risco inerentemente maior da conectividade sem fio.

Teste

Percorra uma rota com um Player executando o networkCheck e seus próprios diagnósticos e certifique-se de que não haja desconexões ou picos além do limite por 10 minutos.

Infraestrutura lógica e de segurança (proxies, firewalls e DPI)

Além dos cabos físicos, sua infraestrutura lógica de segurança de rede é a fonte mais comum de latência “misteriosa”, jitter e falhas de conexão.

• Proxies e firewalls como gargalos: os dispositivos de segurança (firewalls, proxies, CASB etc.) que realizam Inspeção Profunda de Pacotes (DPI) ou descriptografia SSL/TLS em todo o tráfego são a principal fonte de instabilidade. Esse processo de inspeção, por si só, adiciona latência significativa e variável (jitter) a cada solicitação de rede, o que pode facilmente violar os requisitos de latência <100 ms e jitter <30 ms.
• Monitore a integridade dos dispositivos: as equipes de rede devem monitorar a utilização da CPU e da memória desses dispositivos. Um firewall ou proxy sobrecarregado descartará pacotes ou introduzirá latência, criando exatamente a instabilidade que leva à perda de dados.
• Não interfira no tráfego do Tulip: a comunicação cliente-nuvem do Tulip depende de protocolos da web específicos, incluindo WebSockets seguros, para a transferência de dados em tempo real. Algumas soluções de segurança tentam interceptar, reescrever ou “interferir” nesse tráfego HTTPS. Essa interceptação pode interromper a conexão WebSocket ou classificar incorretamente chamadas de API padrão como solicitações de origem cruzada (CORS), fazendo com que elas falhem.
• Requisito: Todos os domínios do Tulip (listados na seção Lista de permissão ) devem ser configurados para passagem direta de SSL/TLS. O tráfego deve ser contornado por qualquer DPI, inspeção de protocolo ou cache.

Lista de verificação

• [ ] Domínios da Tulip contornados: Todos os domínios da Tulip listados na Lista de Permitidos estão configurados para passagem de SSL/TLS e estão excluídos da descriptografia/interceptação de SSL.
• [ ] Prefira sem DPI e sem reescrita de protocolo: a Inspeção Profunda de Pacotes (DPI), a reescrita do protocolo HTTP e o cache de conteúdo estão desativados para o tráfego do Tulip, especialmente para WebSockets.
• [ ] Suporte a WebSocket: firewalls e proxies permitem conexões WebSocket de longa duração pela porta 443, sem tempos de espera curtos por inatividade ou reinicializações forçadas.
• [ ] Monitoramento de capacidade: a CPU, a memória e a taxa de transferência nos dispositivos de segurança são monitoradas; há alertas em vigor para utilização elevada e prolongada que possa causar latência ou perda de pacotes.
• [ ] Regras de saída: as regras de saída permitem explicitamente intervalos de IPs/nomes de host do Tulip (por identificador de garden), incluindo pontos finais de armazenamento de ativos (S3/Blob).
• [ ] Comportamento “fail-open”: sempre que possível, o tráfego do Tulip é configurado para operar em modo “fail-open” (ou com erros claros e registrados), em vez de descartar pacotes silenciosamente.
• [ ] Controle de mudanças: Qualquer alteração na configuração do firewall/proxy que possa afetar o Tulip é rastreada e, idealmente, testada em um ambiente de teste (https://your-account.tulip.co/networkCheck) durante as janelas de mudança.

Arquitetura resiliente de aplicativos

Esta seção explica como os desenvolvedores podem mitigar riscos de infraestrutura.

Os desenvolvedores devem projetar aplicativos para que sejam resilientes a problemas intermitentes de rede. É fundamental garantir margem de segurança para latência de rede e pequenas degradações da plataforma. Use automações (e/ou funções, sempre que possível).

• Priorize gravações na tabela do Tulip: para toda captura de dados críticos, use primeiro as ações nativas da tabela do Tulip “Create Record” ou “Store” em seu gatilho. Essas ações são mais resilientes a falhas momentâneas de rede e possuem lógica de repetição integrada (até 2 minutos no LTS15).
• Minimize a taxa de eventos: revise o design do seu aplicativo. Se um operador puder gerar razoavelmente 100 eventos (por exemplo, varreduras) durante uma queda de rede de 2 minutos, sua arquitetura está em alto risco. Considere agrupar entradas ou simplificar o fluxo de trabalho.
• Siga as práticas recomendadas de desempenho: siga as orientações documentadas para aplicativos de alto desempenho aqui. Sobrecarregar a plataforma com chamadas de alta frequência cria latência interna que se assemelha a uma rede de baixa qualidade.

Veja também: Gatilhos de aplicativos baseados em eventos por meio da “máquina virtual” Tulip

Lista de verificação

• [ ] Tabelas em primeiro lugar: toda a captura de dados críticos (varreduras, decisões de operadores, medições) é gravada primeiro em uma tabela do Tulip.
• [ ] Sem chamadas longas de API nos gatilhos do operador: os gatilhos voltados para o operador não contêm chamadas de API de longa duração ( Connector Functions ) nem lógica complexa de API externa.
• [ ] Padrão de desacoplamento: automatizações são preferidas para realizar chamadas de API externas sempre que possível.
• [ ] Campos de status: as tabelas de processamento utilizam campos de status claros (pendente, em processamento, processado, erro) para que as falhas possam ser repetidas ou investigadas.
• [ ] Taxa de eventos controlada: o design do aplicativo não permite que os operadores gerem taxas de eventos sustentadas que encheriam a fila durante pequenas interrupções (veja a matemática das interrupções acima).
• [ ] Temporizadores e loops: os gatilhos de temporizador e os loops não são acionados em intervalos desnecessariamente curtos (por exemplo, a cada 1–5 segundos), a menos que seja absolutamente necessário e validado.
• [ ] Tratamento de erros nos conectores: os conectores de rede ( Connector Functions ) que podem falhar devido a problemas de rede possuem mecanismos de tratamento de erros e repetição de tentativas (de preferência por meio de automações, e não de acionadores de operador).
• [ ] Melhores práticas de desempenho: os aplicativos seguem as melhores práticas da Tulip para aplicativos de alto desempenho.

Configuração técnica e solução de problemas

Se sua rede não atender aos requisitos quantificáveis descritos acima, ou se você estiver enfrentando problemas de desempenho que suspeita estarem relacionados à rede, siga as etapas em nosso guia detalhado. Esse guia fornece um fluxograma priorizado para diagnosticar e resolver problemas de desempenho de rede, desde verificações básicas até análises avançadas no nível de pacotes.

Veja aqui o guia completo de solução de problemas de rede.

Utilitário de teste de rede e WebSocket

A Tulip faz uso extensivo de WebSockets, um tipo de conexão de longa duração, para permitir atualizações em tempo real. Esses WebSockets utilizam criptografia SSL na porta 443. Alguns proxies não suportam essas conexões, e alguns monitores de rede podem precisar permitir explicitamente essas conexões. Consulte a seção acima para verificar a compatibilidade.

Está disponível um utilitário simples para ajudá-lo a testar a latência da sua conexão de rede e a compatibilidade com WebSockets:

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

Lista de verificação para comissionamento e monitoramento contínuo

• [ ] Teste inicial: para cada nova estação, acesse https://your-account.tulip.co/networkCheck (ou a URL da DMG MORI / Serendie) e execute seus próprios diagnósticos por pelo menos 10 a 15 minutos durante a carga normal de produção.
• [ ] Registre as métricas: registre a latência média, mínima e máxima, o jitter e qualquer perda de pacotes observada; verifique se eles atendem aos limites estabelecidos neste artigo.
• [ ] Teste de pico de carga: Repita o teste durante um período conhecido de pico de carga na rede da fábrica (troca de turno, processamento de grandes lotes) para garantir a estabilidade sob carga pesada.
• [ ] Testes de regressão após alterações: execute novamente o teste após qualquer alteração significativa na configuração da rede, do Wi-Fi, do firewall ou do proxy que afete o Tulip.
• [ ] Armazenamento de referência: Armazene os resultados dos testes (capturas de tela ou exportações) como parte de seus registros de validação/comissionamento.
• [ ] Revalidação periódica: Programe novos testes periódicos (por exemplo, trimestralmente) para estações críticas ou quando novos aplicativos com taxas de eventos mais altas forem implantados.

Você encontrou o que estava procurando?

Você também pode acessar community.tulip.co para postar sua pergunta ou ver se outras pessoas já tiveram uma dúvida semelhante!