Um caso de uso real: Gerenciamento de receitas

Introdução

O cliente é um fabricante líder de válvulas e componentes de manuseio de fluidos para HVAC e aplicações industriais. A divisão de soluções de energia solicitou uma solução de Sistema de Execução de Manufatura (MES) capaz de lidar com o processo de montagem de bombas hidráulicas, ou seja, uma solução que pudesse lidar com a variedade extremamente grande de receitas e a rastreabilidade das unidades ao longo da linha de montagem.

Entre essas duas metas principais, o principal desafio foi gerenciar o grande número de receitas para um único produto final de forma extremamente configurável, sem recorrer à "codificação" de uma grande quantidade de informações. Isso não apenas tornaria o desempenho inaceitável, mas também levaria a uma manutenção de dados extremamente ineficiente.

Contexto de produção

Considerando um produto (ou, melhor ainda, uma família de produtos) fabricado na divisão de energia, seu processo de montagem é extremamente variável. Em outras palavras, embora o número e o tipo de operações de trabalho realizadas sejam sempre os mesmos para todas as unidades pertencentes a essa família, duas unidades quaisquer podem variar por vários motivos, que podem ir desde um deslocamento diferente da etiqueta de identificação até uma forma, cor e/ou subconjuntos usados completamente diferentes.

Por exemplo, em um produto chamado bomba H1P, as operações de trabalho serão sempre as seguintes

1. Carregamento da carcaça - Placa oscilante - Servo pistões - Servo cilindros - Suporte do ímã.
2. Pinos de cavilha - Junta - Placa de travamento.
3. Eixo de carga - Rolamento de pressão - Montagem do bloco de cilindros - Válvulas de carga - Sensor de pressão.
4. Bucha de carga - Proteção de carga - Gaxeta superior - Bloco de cilindros de óleo - Tampa de aperto - Bomba de carga - Vaselina - Sensor de velocidade.
5. Scan HPVR - Placa axial - Adaptador de tampa - Teste de rotação de torque - Manuseio de descarga.
6. Teste final.
7. Pintura.

No entanto, o número de variações possíveis dentro da mesma família H1P é de cerca de 500. Como essas 500 variam se forem montadas "da mesma forma"? Por exemplo, a operação "carregamento da carcaça" (nº 1) poderia ser realizada com parafusos diferentes, de acordo com o lote específico de unidades, ou a operação "rolamento da prensa" (nº 3) poderia ser executada com o uso de diferentes forças de prensagem e assim por diante. As diferenças podem variar de "mínimas" a "enormes", o que resulta em um grande número de variações dentro da mesma família; os produtos mais configuráveis podem ter mais de 2.000 variações possíveis.

Mas como um engenheiro de processos pode distinguir uma variante da outra? O "truque" usado pelo cliente é atribuir uma lista de materiais (BoM) diferente a cada variação possível. No caso de uma peça usada variar, é bastante óbvio como isso pode acontecer, mas pode não ser assim se a diferença for dada por uma cor de tinta diferente ou pelo deslocamento da etiqueta de identificação. Esse "problema" é superado reservando um lugar no BoM também para itens "não físicos" (como a cor da tinta) e atribuindo um designador de referência a cada item do BoM (chamado de string de classificação na terminologia SAP), que normalmente define o deslocamento de um item dentro do projeto CAD.

Com base nesses fatos, observando um BoM, os engenheiros de processo podem entender se estão lidando com a variante A em vez da B:

• Item do BoM: A pode ter um item BoM que B não tem e vice-versa (um parafuso, uma submontagem diferente, uma cor de tinta diferente);
• Cadeia de classificação: A e B compartilham o mesmo item, mas colocado em um local diferente;
• Código do modelo mestre: o código do modelo atribuído a uma ordem de produção pode mudar de variante para variante.

Considerando todos os itens acima e aproveitando a suíte Siemens Opcenter Execution (SIMATIC IT), os fatores determinantes considerados pela Engineering ao chegar à solução ideal incluíam

• Volume de dados: ter, em média, centenas de receitas para cada família de produtos resultaria em uma enorme quantidade de dados no banco de dados;
• Flexibilidade de dados: o mapeamento de qualquer BoM individual para um PPR levaria a uma configuração estritamente estática; um ambiente de produção que lida com tantas variações é assim porque as necessidades de produção são extremamente flexíveis e podem mudar facilmente com o tempo, de acordo com as demandas dos clientes, e uma solução projetada de forma estática não pode lidar com essa exigência;
• Manutenção de dados: as alterações aplicadas a qualquer peça não seriam facilmente propagadas.

A solução

A solução desenvolvida para esse cliente, também conhecida como "módulo de gerenciamento de receitas", baseia-se no conceito de regra de produção; uma regra de produção tem a finalidade de definir uma ação a ser tomada caso uma variante específica esteja sendo trabalhada em uma determinada estação.

Qualquer regra de produção pode ser dividida em três partes:

1. estação de destino (operação de trabalho);
2. critério de aplicabilidade (em quais casos a regra deve ser aplicada);
3. corpo da regra (o que deve ser feito).

O ponto 1 responde à pergunta "Estou trabalhando com a variante de produção "abc"" (ou então "Estou trabalhando com as variantes de produção "abc"/"def"/..."). O ponto nº 2 define o que fazer caso a resposta ao ponto nº 1 seja positiva. Devido à sua natureza, o Ponto 1 deve ser definido por meio de referência:

• os elementos no BoM que podem distinguir uma variante de outra, ou seja, o número do item do BoM, a cadeia de classificação ou o código do módulo;
• em um nível ainda mais alto, os elementos que podem distinguir uma família de produtos de outra, ou seja, o local de armazenamento do material final.

Dessa forma, um engenheiro de processos pode definir regras para toda uma família de produtos (granularidade mais grosseira) ou para uma variante muito específica (granularidade mais fina).

O ponto nº 2 define o que deve ser feito caso a regra seja aplicável. As ações possíveis podem ser:

• usar um instrumento específico;
• selecionar uma peça em um depósito "Pick To Light";
• mostrar uma EWI (Instrução de Trabalho Eletrônica);
• imprimir uma etiqueta ou um crachá;
• enviar uma confirmação para o SAP.

Normalmente, as regras de produção são baixadas para a camada de controle para serem aplicadas. Por exemplo, no caso de regras de instrumentos, a ID do instrumento e um conjunto de parâmetros de trabalho são enviados ao controlador de linha, que acionará a ferramenta automaticamente, sinalizará visualmente ao operador qual ferramenta deve ser usada e/ou predefinirá seus parâmetros de trabalho.

Para facilitar a implementação, a solução fornecida ao cliente abstrai a "maneira real" como os dados são enviados ao controlador de linha (enviando um XML), mas é capaz de gravar dados diretamente nos registros do PLC.

Como e quando as regras são calculadas

Quando um novo pedido está disponível, ele é importado junto com seu BoM pelo módulo de gerenciamento de receitas. Em seguida, o gerenciador de receitas percorrerá o BoM e, estação por estação (ou seja, entrada de ordem de produção por entrada de ordem de produção), verificará as regras definidas para a estação atual e identificará aquelas que têm um critério de aplicabilidade "correspondente".

Como as regras podem ser rotuladas com um número de sequência pelo engenheiro de processos que as define, para cada pedido, todo o processo resultará em um "script" para cada estação. Em outras palavras, o Opcenter Execution (SIMATIC IT) "conhecerá" todas as microoperações a serem executadas em qualquer estação e as baixará para a camada de controle ou as aplicará diretamente.

Uma última palavra sobre regras diz respeito a como elas são baixadas para a camada de controle. A solução se baseia em um protocolo de comunicação de quatro etapas; para cada unidade, a camada de controle

1. solicitará autorização para trabalhar com o número de série na estação (intertravamento);
2. solicitará todas as regras aplicáveis em sequência;
3. carregar os resultados reais de cada regra aplicada (força de pressão real, ângulo, torque etc.);
4. por fim, confirmar se o resultado é bom ou não.

Essa solução, embora seja "mais lenta", pois leva a uma sobrecarga de comunicação, permite uma comunicação síncrona entre o Opcenter Execution (SIMATIC IT) e a camada de controle, de modo que a produção possa ser interrompida e retomada caso isso seja necessário. Além disso, o módulo de gerenciamento de receitas possibilita o download de todas as regras aplicáveis de uma só vez e permite que a camada de controle inteligente as revise.