Como usar aplicativos de manufatura em ambientes de alta mistura
  • 04 Nov 2023
  • 9 Minutos para Ler
  • Contribuintes

Como usar aplicativos de manufatura em ambientes de alta mistura


Resumo do artigo

Como usar aplicativos de manufatura em ambientes de alta mistura

Saiba como configurar instruções de trabalho em um ambiente de alta mistura com o Tulip.

Neste guia, você aprenderá...

  • Como combinar os recursos do Tulip para se adequar ao seu ambiente de alta mistura.
  • Os prós e contras de cada abordagem para lidar com a variação no Tulip

Você gerencia centenas de SKUs em seu chão de fábrica? Ou você tem uma série de processos que são reutilizados em várias linhas de produtos?

Este guia abordará todas as diferentes maneiras pelas quais a Tulip pode ajudá-lo a lidar com a alta variabilidade de seus produtos.

Há vários fatores que podem criar um "ambiente de alta mistura", portanto, não há uma única ferramenta ou recurso na Tulip que possa cobrir todos os cenários de alta mistura. Em vez disso, você combinará vários recursos, dependendo da sua situação. Os principais fatores incluem:

  • Número de dispositivos conectados
  • Variação entre SKUs
  • Requisitos analíticos para os dados do Tulip
  • Se existem "famílias" de produtos

Em geral, há cinco maneiras diferentes de lidar com um grande mix de produtos:

  • Aplicativos: Criação de aplicativos especializados para cada produto ou cada família de produtos
  • Etapas: Criação de diferentes combinações de grupos de etapas
  • Tabelas: Carregar dinamicamente dados de instruções de trabalho de tabelas sem criar várias etapas
  • Gatilhos: Uso de instruções "If" ou concatenação de strings para lidar com centenas de combinações
  • SQL: Se você já escreveu SQL no passado, poderá usar as funções do Connector para trabalhar com um banco de dados SQL externo.

Aqui estão algumas estratégias que você pode usar com cada um desses recursos.

Observação: este guia destina-se a usuários da Tulip com alguma experiência na criação de aplicativos. Se você ainda não criou um aplicativo, deve começar com o Tulip Basics

Aplicativos

Há duas maneiras de aproveitar vários aplicativos para gerenciar a complexidade.

A primeira maneira é criar um aplicativo distinto para cada produto ou SKU e usar um aplicativo de roteamento para enviar automaticamente os operadores para o aplicativo correto. Isso funciona bem se os produtos em seu andar tiverem uma sobreposição limitada nas instruções de trabalho.

Aqui está um guia completo sobre aplicativos de roteamento.

Para fazer isso, você deverá criar um aplicativo de uma etapa chamado "Routing". Por padrão, ele pode ser executado em todas as estações do seu andar. Quando um operador inicia uma nova ordem de serviço, ele pode digitalizar a ordem de serviço e ser direcionado automaticamente para o aplicativo correto.

A etapa pode se parecer com esta etapa do Terminal Tulip

Em seguida, você escreveria uma série de instruções "If" em um acionador na etapa para direcionar os operadores para o conjunto correto de instruções.

Esta é a aparência de uma instrução "If" para um produto com SKU "1A2B3X4D".

Isso representa um desafio: se um operador escanear um código de barras no aplicativo de roteamento, você precisará encontrar uma maneira de passar esses dados para o próximo aplicativo. Use este guia para saber como passar dados entre aplicativos.

Em seguida, você pode incluir algum tipo de confirmação no início de cada aplicativo para garantir que o operador não digitou incorretamente a SKU e acabou no aplicativo errado.

Duplicação de um aplicativo com um conjunto abrangente de instruções

Você também pode usar a abordagem de "vários aplicativos" quando todos os aplicativos usam um subconjunto de uma série de etapas. Isso funciona quando há muitas etapas comuns entre os produtos.

Primeiro, você deve criar um aplicativo de "Modelo geral" que contenha todas as etapas que são usadas por vários produtos ou SKUs. Em seguida, para cada produto distinto, duplique o aplicativo e corte todas as etapas que são irrelevantes para aquele produto específico.

Essas estratégias baseadas em aplicativos são fáceis de gerenciar para todos os novos usuários da Tulip, pois todos os Triggers são simples. O padrão "um aplicativo para um produto" é fácil de entender. Mas, se você quiser alterar o design de etapas individuais, essa abordagem exigirá que você refaça a etapa em cada aplicativo.

Etapas/Grupos de etapas

Você também pode tornar as etapas individuais e os grupos de etapas mais dinâmicos se os seus produtos tiverem instruções de trabalho semelhantes. Em vez de criar vários aplicativos, você pode criar muitos grupos de etapas em um único aplicativo e encaminhar os operadores pelos grupos de etapas com lógica de acionamento.

Talvez você ainda queira incluir uma etapa de leitura de código de barras, como no exemplo da seção acima. Em seguida, você desejará armazenar os dados do código de barras como uma variável para vincular o código de barras a uma conclusão do aplicativo e encaminhar o operador para a etapa correta.

Como os dados do código de barras agora estão armazenados no aplicativo, você também pode fazer referência a eles posteriormente se quiser recombinar as instruções de trabalho de várias maneiras usando gatilhos.

Isso facilita a atualização de todas as etapas das instruções de trabalho em um só lugar a partir da interface principal do Tulip. Porém, se você tiver centenas ou milhares de SKUs, talvez queira facilitar ainda mais a atualização das etapas em tempo real, para que os operadores líderes ou supervisores possam fazer alterações em tempo real.

Para fazer atualizações em tempo real em cada conjunto de instruções de trabalho, você pode usar uma etapa de formulário com alguns campos. Vamos imaginar que cada etapa de instrução de trabalho tenha os seguintes campos:

  1. Título da instrução principal
  2. Detalhes da instrução
  3. Imagem
  4. Notas especiais

A aparência pode ser mais ou menos assim:

Para atualizar essas instruções em tempo real, você pode usar uma etapa de formulário como esta:

Em seguida, você pode armazenar os resultados em uma tabela ou banco de dados SQL e recuperá-los dinamicamente quando um operador passar pelo aplicativo com base no campo "Step Number" (Número da etapa). Veja como fazer isso.

Tabelas

O recurso Tabelas do Tulip permite que você crie um banco de dados com dados do aplicativo ou conjuntos de instruções sem escrever nenhum código. Você pode usá-las para instruções se:

  1. Todos os produtos tiverem diferentes conjuntos de instruções.
  2. Os produtos compartilham uma série de processos comuns, como fundição, limpeza ou auditoria, e há pouca ou nenhuma variabilidade dentro desses processos.

Além disso, cada etapa das instruções deve ter o mesmo conteúdo, como um título, um conjunto de detalhes e uma imagem.

Se suas instruções de trabalho não se enquadrarem em nenhuma dessas duas categorias, as tabelas podem não ser uma boa opção.

Entretanto, se elas seguirem um desses padrões, você poderá criar um aplicativo com apenas uma etapa que carrega dinamicamente as instruções de trabalho de uma tabela.

Primeiro, crie uma tabela com campos como este:

Em seguida, adicione pelo menos um registro, por exemplo:

Em seguida, crie um aplicativo e crie uma etapa que carregará todas as instruções de trabalho dinamicamente. Você usará o widget de texto "Table Record" para alterar o texto e a(s) imagem(ns) na etapa assim que o operador estiver pronto para avançar.

Aqui está um exemplo de layout que usa campos do widget "Table Record" (Registro de tabela):

Então, quando um operador pressionar o botão "Next" (Próximo), você não desejará avançar para a próxima etapa. Em vez disso, será necessário escrever a lógica para que o próximo registro da tabela seja carregado. Você precisa usar uma variável que será incrementada a cada vez que o botão for pressionado para alterar o registro. Assim:

WHEN

  • "O botão é pressionado"

ENTÃO

  • "Data Manipulation" "Increment Value" "counter" (Manipulação de dados)
  • By: "Valor estático" "Número" "1"
  • "Registros de tabela" "Carregar registro"
  • By ID "Static Value" "text" (variável que contém SKU) + (variável de contador) into: (espaço reservado para registro)

Portanto, você precisará de uma variável que contenha a SKU ativa e outra que esteja contando consistentemente à medida que o operador avança.

Essa abordagem facilita a manutenção de todo o conteúdo em vários conjuntos de instruções de trabalho. Ela funciona bem se as instruções tiverem um formato consistente, mas se houver vários tipos de etapas nas instruções, provavelmente será necessário usar um método diferente.

Uso da lógica de acionamento

Em quase todos os cenários destacados acima, você precisará criar Triggers personalizados para criar seu(s) aplicativo(s) com sucesso. Já mostramos alguns simples, como:

  • Incrementar uma variável de contador
  • Mudar para um novo aplicativo
  • Passar para um grupo de etapas diferente
  • Armazenar um número de código de barras

Aqui estão alguns padrões mais avançados que podem aparecer em qualquer um dos padrões de criação de aplicativos acima:

Série de instruções IF

Digamos que você tenha 50 SKUs ativos diferentes em sua fábrica. Cada uma delas tem um conjunto separado de instruções de trabalho. Se quiser criar um "aplicativo de roteamento" que envie automaticamente os operadores para o conjunto correto de instruções, você precisará criar 50 instruções "if" com diferentes números de SKU. É possível fazer tudo isso em um único Trigger. Embora isso exija muita criação manual de instruções "se/então", permite que qualquer pessoa clique no acionador e entenda facilmente o que está acontecendo.

Aqui está um exemplo de uma instrução if/then:

Concatenação de strings

Concatenação significa simplesmente "combinar duas cadeias de caracteres". Como os IDs de registro da tabela são cadeias de caracteres, você pode ser criativo ao usar o ID da cadeia de caracteres para fornecer o conteúdo correto ao operador.

Digamos que você tenha um processo de limpeza que seja comum em várias linhas de produtos. Ele tem 5 etapas. Talvez você não queira reconstruir as mesmas instruções de limpeza em vários aplicativos, pois isso será difícil de manter.

Em vez disso, você poderia criar uma tabela chamada "Common Procedures" (Procedimentos comuns) que incluísse instruções para processos comuns. Em seguida, talvez queira usar IDs de registro como "Cleaning-1" e "Cleaning-2" para mostrar uma série de etapas de um processo.

Em seguida, no Trigger Editor, você combinará o processo específico com uma variável que aumenta a cada avanço de etapa. Aqui está o exemplo da seção "Tabelas" acima sobre a combinação de duas variáveis no campo "Static Value:Text".

Com a concatenação de strings, você pode não saber quando parar. Em outras palavras, se houver 5 etapas no processo de limpeza, você precisará passar para uma etapa diferente quando o contador atingir "6". Para fazer isso, você pode usar uma instrução "If" no Trigger para verificar primeiro se a etapa existe.

Assim:

IF

  • "Tabela" "dynamic_work_instructions" "tem registro com ID"
  • "Static Value" "text" (insira o conteúdo dinâmico aqui)

Uso de SQL

Se você tiver experiência anterior com a criação de bancos de dados SQL, também poderá criar um conector SQL para carregar dinamicamente texto e imagens de um banco de dados SQL. Isso permitirá que você crie um modelo em uma etapa e carregue dados nele, assim como no exemplo de tabelas acima.

Isso funciona bem se você tiver requisitos complicados para carregar dados. Entre em contato com um representante da Tulip se estiver planejando usar essa abordagem e teremos prazer em aconselhá-lo sobre como configurar seu banco de dados.

Leitura adicional


Encontrou o que estava procurando?

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


Este artigo foi útil?