Padrões de arquitetura baseados em aplicativos de monitoramento de máquinas

A Tulip oferece flexibilidade na forma como você estrutura os aplicativos em torno das máquinas. O padrão certo depende da maturidade técnica da sua equipe, da padronização dos processos e do orçamento.

Padrão 1: Aplicativos de máquina composíveis (modelo 1:1)

Estrutura: Uma máquina → Um aplicativo → Uma estação → Um terminal

Diagrama de arquitetura:

Casos de uso

• Desenvolvedores amadores iniciantes criando seus primeiros aplicativos de monitoramento de máquinas
• Implantaçõesrápidas de prova de conceito, nas quais a simplicidade supera a eficiência
• Processos manuais personalizados por instância de máquina (por exemplo, a Máquina 1 requer etapas de inspeção exclusivas que não se aplicam à Máquina 2)
• Desenvolvimento orientado por operações, em que os desenvolvedores têm várias funções e tempo limitado

Por que isso é importante

Esse padrão mapeia fisicamente o software para o hardware na proporção de 1:1, eliminando a abstração. Os desenvolvedores podem identificar uma máquina no chão de fábrica e mapeá-la para seu próprio aplicativo. Essa clareza reduz o esforço mental e torna o diagnóstico de problemas intuitivo.

Exemplo

Cenário: Um fabricante de alimentos e bebidas possui três linhas de embalagem. Cada linha apresenta motivos exclusivos de inatividade, configurações de peças e fluxos de trabalho dos operadores.

Implementação

• Crie o tipo de máquina: “Linha de Embalagem”
• Crie 3 máquinas: “Linha A”, “Linha B”, “Linha C”
• Crie 3 aplicativos: “Terminal da Linha A”, “Terminal da Linha B”, “Terminal da Linha C”
• Atribuir cada aplicativo a uma estação dedicada com um terminal fixo

Benefícios

• O isolamento claro de dados evita a corrupção de dados entre máquinas
• Fácil personalização dos fluxos de trabalho por máquina
• Solução simples de problemas (o problema está sempre em um aplicativo independente)

Limitações

• Requer um terminal físico por máquina (custo de hardware)
• Alterações globais no aplicativo exigem a atualização de três aplicativos distintos
• Não é escalável para mais de aproximadamente 10 máquinas

Padrão 2: Atribuição de máquinas ao aplicativo de estação

Estrutura: Um tipo de máquina → Um aplicativo → Várias estações (máquina atribuída dinamicamente por meio do mapeamento de estações)

Diagrama de arquitetura:

Casos de uso

• Processos padronizados entre tipos de máquinas idênticos
• Desenvolvedores amadores em tempo integral, familiarizados com abstração e lógica de acionamento
• Necessidade deescalonamento horizontal (mais de 10 máquinas do mesmo tipo)
• A manutenção centralizada de aplicativos é uma prioridade

Como funciona

1. Atribua cada máquina a uma estação em Chão de Fábrica > Máquinas (guia Configuração)
2. No aplicativo, use as condições de acionamento “nesta estação” para referenciar dinamicamente a máquina atribuída
3. Quando o aplicativo é executado na Estação 1, ele interage com a Máquina 1. Quando é executado na Estação 2, ele interage com a Máquina 2

Exemplo de acionador de aplicativo

Quando: A máquina nesta estação gera uma saída demudança de estadoSe: Saída da máquina / Mudança de estado =DesligadaEntão: Crie um registro na tabela 'Histórico de status'.

Exemplo

Cenário: Um fornecedor de primeiro nível do setor automotivo possui 15 fresadoras CNC idênticas executando o mesmo processo de produção.

Implementação

• Criar tipo de máquina: “Fresadora CNC de 5 eixos”
• Criar 15 máquinas (CNC-001 a CNC-015)
• Crie um aplicativo: “Terminal do Operador CNC”
• Criar 15 estações, atribuindo uma máquina a cada uma
• Implantar o único aplicativo em todas as 15 estações

Benefícios

• Um único aplicativo para manutenção (atualizações globais são propagadas instantaneamente)
• Tempo reduzido de desenvolvimento de aplicativos para implantações em frotas
• Utiliza a lógica de acionamento “nesta estação” (referência dinâmica integrada à máquina)

Limitações

• Ainda requer um terminal por estação (o custo de hardware permanece)
• Todas as máquinas devem ser do mesmo tipo, com atributos idênticos
• A lógica personalizada por máquina requer ramificação condicional (maior complexidade)

Padrão 3: Aplicativo com variável de máquina (terminal flutuante)

Estrutura: Um aplicativo → Vários tipos de máquinas → Seleção de máquinas com base em variáveis → Terminal compartilhado/flutuante

Diagrama da arquitetura:

Casos de uso

• Restrições orçamentárias: número limitado de terminais disponíveis
• Modelo de operador flutuante: um operador se desloca entre as máquinas com um iPad compartilhado
• As máquinas não exigem monitoramento contínuo: o aplicativo precisa ser executado apenas durante as operações ativas

Limitação crítica: Não suporta monitoramento sem interface gráfica

Este padrão não suporta monitoramento em segundo plano/sem interface gráfica. Se o aplicativo estiver fechado, nenhuma máquina acionará o alarme. Este padrão é adequado apenas para:

• Entrada de dados iniciada por pessoas (o operador registra defeitos, conta peças)
• Inspeções ad hoc nas máquinas
• Cenários em que as máquinas não geram dados quando o aplicativo não está em execução

Como funciona

1. Crie uma variável de máquina no aplicativo (por exemplo, selectedMachine)
2. Adicione um widget de menu suspenso ou leitura de código QR para preencher selectedMachine em tempo de execução
3. Use selectedMachine em todas as referências de gatilho

Exemplo de gatilho de aplicativo

Quando: a variável de máquina “Máquina selecionada” gerar {Atributo}Então: Armazenar a saída da última máquina na variável

Exemplo

Cenário: Um laboratório farmacêutico possui 5 instrumentos analíticos que só são executados durante testes programados. Os técnicos usam um iPad compartilhado para registrar os parâmetros e resultados dos testes.

Implementação

• Crie 5 máquinas (HPLC-1, GC-MS-2, etc.)
• Crie um aplicativo: “Registro de Equipamentos de Laboratório”
• Adicionar menu suspenso: “Selecionar Instrumento” → preenche a variável selectedMachine
• O técnico leva o iPad de um instrumento para outro, seleciona a máquina ativa e registra os dados

Benefícios

• Custo mínimo de hardware (um terminal compartilhado)
• Seleção flexível de máquinas durante a execução
• Ideal para fluxos de trabalho pontuais/intermitentes

Limitações

• Não é “headless” — o aplicativo deve estar ativamente em execução para que qualquer lógica seja executada
• Não há monitoramento em segundo plano quando o aplicativo está fechado
• Gerenciamento complexo de estado (qual máquina está ativa no momento?)
• Não é adequado para acompanhamento de OEE 24 horas por dia, 7 dias por semana

Árvore de decisão de padrões de arquitetura

Use esta árvore de decisão para selecionar o melhor padrão para suas necessidades:

Leitura complementar

• Monitoramento de máquinas — arquitetura headless x arquitetura baseada em aplicativo
• Variáveis

{{snippet.Você encontrou o que estava procurando?}}