Desenvolva o projeto de automação para o sistema de movimentação por esteiras transportadoras, descrito abaixo. O projeto deverá ser realizado conforme a metodologia de abordagem mostrada em aula e deverá conter os seguintes itens:
Modelagem em autômatos e em Redes de Petri
Modelagem em autômatos e em Redes de Petri
Passo 1
O enunciado pede: desenvolver o projeto de automação para um sistema de movimentação por esteiras transportadoras, gerando a modelagem em autômatos e em Redes de Petri.
Informações fornecidas no enunciado: nenhuma além do pedido (ou seja, não há descrição das esteiras, sensores, atuadores, sequência de operação, requisitos de segurança, condições de entrada/saída nem fluxos de produto).
Informações fornecidas no enunciado: nenhuma além do pedido (ou seja, não há descrição das esteiras, sensores, atuadores, sequência de operação, requisitos de segurança, condições de entrada/saída nem fluxos de produto).
Informações que estão faltando e que são necessárias para um projeto específico:
- Quantas esteiras existem e como estão conectadas (em série, paralelo, loop)?
- Que equipamentos atuam (motores de esteira, inversores, cilindros, empurradores)?
- Quais sensores existem (fotocélulas, chaves fim de curso) e suas localizações?
- Regras de operação (modo automático/manual, prioridade, intertravamentos, handling de falhas)?
- Condições de partida (ex.: start por botão, chegada de peça) e parada (ex.: emergência, parada normal)?
- Requisitos de tempo (delays, temporizações entre etapas) e de segurança (estop, proteção)?
Conclusão do passo: não é possível entregar um projeto específico sem os dados acima. Abaixo (nos passos seguintes) vou: (a) explicar a metodologia de projeto passo a passo; (b) apresentar um exemplo completo e didático de projeto (autômato + Rede de Petri) para um caso típico de duas esteiras em série com transferência de peças, de modo que você possa adaptar esse modelo ao seu exercício ou à descrição real que tiver. Não peço nada a você — apenas explico que faltam dados e sigo com um exemplo didático.
Passo 2
Metodologia padrão (resumida, prática e aplicável em prova) para projetar automação de transportadores:
- Especificação funcional: listar entradas (sensores, botões), saídas (motores, atuadores) e objetivos (ex.: transportar peças de A até B, evitar colisão).
- Decomposição em máquinas/etapas: dividir o processo em etapas discretas observáveis (ex.: “espera peça”, “andar esteira 1”, “transferir para esteira 2”, “parar”).
- Modelagem discreta: escolher representação (autômato finito para lógica sequencial clara; Rede de Petri para concorrência e análise de propriedades).
- Verificação analítica: verificar alcance, vivacidade, contenção, possibilidades de deadlock.
- Implementação: converter estados/condições para diagrama de ladder, bloco de função ou código IEC 61131-3.
- Testes e validação: testar cenários normais e falha (sensores ausentes, emergência).
Explicação didática: cada etapa traduz requisitos desejados em estados e eventos; o autômato é ótimo para sequências simples e legíveis; Rede de Petri é poderosa para mostrar concorrência, sincronização e para provar ausência de deadlocks.
Passo 3
Breve aula prática sobre autômatos finitos (para quem não lembra):
- Um autômato finito determinístico para controle discreto é formado por: conjunto de estados
, alfabeto de eventos/entradas , função de transição , estado inicial e (opcional) conjunto de estados de saída. - Em automação, estados representam modos de operação (ex.:
, , , ); eventos são leituras booleanas ou condições (ex.: sensor = 1, timer expirou). - Existem dois estilos para gerar saídas: Moore (saídas dependem apenas do estado) e Mealy (saídas dependem do estado e do evento). Mealy costuma ser mais compacto; Moore é mais simples de testar.
- Como extrair estados: identifique passos sequenciais relevantes. Cada passo que requer ações distintas vira um estado.
- Como extrair eventos/condições: transforme cada condição que provoca mudança em um evento (botão START, chegada peça, sensor de fim de esteira, conditions de tempo).
Exemplo simples de notação que usarei: escreverei transições como
, onde
evento é condição ou sensor e saída são sinais acionados.Passo 4
Definição do caso-exemplo (vou usar este caso para modelar; adapte ao seu caso real quando tiver os dados):
Sistema típico: duas esteiras em série, chamada Esteira 1 (E1) e Esteira 2 (E2), com transferência entre elas. Componentes e requisitos:
Sistema típico: duas esteiras em série, chamada Esteira 1 (E1) e Esteira 2 (E2), com transferência entre elas. Componentes e requisitos:
- Sensores:
-
: detecta chegada de peça na entrada da E1. (peguei esta necessidade como típica) -
: detecta peça pronta para transferência na junção E1 E2. -
: detecta peça na saída da E2 (peça saída do sistema).
-
- Atuadores:
-
: motor da Esteira 1 (liga/desliga). -
: motor da Esteira 2 (liga/desliga). -
: pistão empurrador (opcional) para ajudar transferência (liga/desliga).
-
- Botões/entradas operacionais:
-
, , (emergência).
-
- Regras de operação (simples e típicas):
- No modo automático, quando
é pressionado o sistema fica pronto. Quando detecta peça, liga até detectar a peça; então para e inicia transferência: aciona (se houver) e liga para receber a peça; quando detecta peça, para se não houver peça seguinte. - Evitar colisão: não ligar
para empurrar nova peça para E2 se E2 estiver ocupada próximo da entrada (ou seja, se ou algum sensor de bloqueio indicar presença). -
desliga tudo imediatamente e seta estado de ALARM.
- No modo automático, quando
Essas regras são suficientes para construir um autômato e uma Rede de Petri didáticos que cobrem sequenciamento, intertravamento e tratamento de emergência.
Passo 5
Modelagem por autômato (passo a passo, bem mastigado):
- Definir estados (cada estado representa um modo de operação coerente):
-
: aguardando Start. -
: iniciado, aguardando peça. -
: Esteira 1 rodando para levar peça até . -
: peça detectada em , preparando transferência (pára ). -
: empurra/encerra transferência e liga . -
: Esteira 2 rodando até . -
: emergência (EStop acionado).
- Definir eventos/condições principais (alfabeto
):
-
, , , , , , .
Nota: variáveis booleanas e timers são tratadas como eventos quando mudam de valor.
- Definir saídas (controle de atuadores) por estado (Moore-style para ficar didático):
- Em
: . - Em
: . - Em
: . - Em
: . - Em
: (liga e empurra). - Em
: . - Em
: .
- Transições (vou escrever no formato
):ç ã
-
. -
. -
. -
, onde verifica que pode receber (ex.: indica peça e não há bloqueio em E2). Em implementação, pode ser simplesmente ou um teste de sensor. -
. -
(após saída da peça, volta a aguardar próxima peça). - Em qualquer estado,
. - De
, (após correção e reset).
- Observações didáticas:
- A transição de
para pára justamente para não empurrar a peça enquanto a transferencia (TRANSFER) é iniciada — isto evita colisões. - O uso de temporizador na TRANSFER garante tempo suficiente para o pistão completar o movimento ou para sincronizar.
- Essa modelagem é determinística: dado estado e entrada, próxima transição conhecida.
Passo 6
Expressar em tabela de transição (útil para prova e implementação):
Linha por linha: Estado atual | Condição de transição | Próximo estado | Saídas
Linha por linha: Estado atual | Condição de transição | Próximo estado | Saídas
-
| | | -
| | | -
| | | -
| | | -
| | | -
| | | - qualquer |
| | -
| | | —
Dica de prova: saber escrever tabela de transição como acima é frequentemente suficiente; se pedirem diagrama, desenhe nós e setas com rotulação de condições/saídas.
Passo 7
Breve aula prática sobre Redes de Petri (essencial e aplicada):
- Rede de Petri tem lugares
(círculos), transições (barras), e arcos direcionais entre eles. Uma marcação atribui tokens ( ) aos lugares. - Firing rule: uma transição
é habilitada se todos os lugares de entrada tiverem tokens suficientes; quando dispara, consome tokens dos lugares de entrada e produz tokens nos lugares de saída. - Vantagens: modela concorrência, sincronização e recursos; permite análise formal (vivacidade, contenção, reachability).
- Notação: incidência inicial
é vetor de tokens iniciais; matriz de incidência (onde é de arcos saída e de arcos entrada) é utilizada para cálculo teórico.
Explicação didática: pense em tokens como “peças” ou “permits”. Lugares representam condições ou disponibilidade de recursos. Transições representam eventos ou ações que mudam a situação.
Passo 8
Construção da Rede de Petri para o mesmo caso (duas esteiras e transferência). Vou listar lugares, transições, arcos e marcação inicial.
- Definir lugares
(descrição intuitiva ao lado):
-
: sistema pronto (modo automático) — token indica que a máquina está habilitada a receber peças. -
: peça na entrada (após ). -
: esteira 1 em movimento (recurso M1 ligado). -
: peça na posição de transferência (detectada por ). -
: transferência em andamento (pistão ou sincronização ativa). -
: esteira 2 em movimento (recurso M2 ligado). -
: peça na saída (após ). -
: estado de alarme/EStop (token indica bloqueio por emergência).
- Definir transições
(ações/acontecimentos):
-
: peça chega no . -
: iniciar . -
: peça alcança (fim de movimento E1). -
: preparação/cheque para transferência (intertravamento). -
: efetua transferência (aciona pistão e liga M2). -
: término da transferência / timer expirado. -
: peça detectada em . -
: emergência ativada. -
: reset do alarme.
- Arcos (vou descrever em palavras para cada transição):
-
: de mundo externo para (simula sensor ): produz token em . -
: entrada e consome token de e produz em (representa que com sistema pronto e peça disponível, inicia M1 e ocupa o recurso). -
: entrada remove token de e produz em (peça chega ao mid). -
: entrada verifica condição de transferência (se necessário pode requerer token em lugar que represente M2 livre) e produz token em . Para simplificar, vamos modelar M2 livre como (inicialmente 1 token). Então consome e e produz e retira disponibilidade de M2 (representando sincronização). -
: entrada produz (esteira 2 em movimento) mantendo token em durante o tempo se precisar; para simplificar, consome e produz . -
: entrada quando é detectado ou timer, consome e produz e também repõe (M2 livre novamente). -
: pode ser modelado como parte de . -
: de qualquer lugar possível produz token em e consome tokens que representam disponibilidade, para modelar que tudo parou. -
: de de volta a (reset completo).
- Marcação inicial
:
-
(sistema pronto). -
(M2 livre). - Todos os outros
têm 0 tokens.
- Comentários didáticos sobre a Petri:
- Tokens em
e representam recursos ativos (motores ligados). Com isso é possível analisar se dois recursos entram em conflito. - A exigência de
em garante que não se inicia transferência se M2 não estiver livre — isto evita colisão e modela intertravamento. - A rede permite modelar concorrência: se houver duas linhas alimentando a E2, tokens e lugares de disponibilidade evitam colisões; aqui temos um caso simples de sincronização.
Passo 9
Análise básica da Rede de Petri (como fazer e o que checar):
- Boundedness (limitado): verifique se o número de tokens por lugar permanece limitado. Neste projeto, com um token por peça e reciclagem de
, a rede é limitada (cada peça consome e produz tokens controladamente). - Liveness (vivacidade): verificar se não há deadlock. No modelo, se
for acionado, sistema vai para e precisa de para retornar; sem reset haveria deadlock — isto é desejado pela segurança. Para operação normal, sem falhas, a sequência permite saída de peças repetida — logo é viva. - Reachability: pode-se construir a árvore de marcações alcançáveis para provar sequências (no exame, descrever alguns passos com vetores de marcação é suficiente).
Pequeno exemplo de cálculo de marcação (um passo):
- Começo
: tokens em , . - Ao chegar peça (
dispara): . - Agora
habilitado (pois ): despacha e gera e retira . Etc. Mostrar esse raciocínio passo a passo é suficiente em prova para demonstrar que você entende firing e alcance.
Passo 10
Como converter e implementar (prático para prova e para lab):
- Do autômato para PLC: codificar estados como bits (por exemplo,
= 1 quando no estado MOVE1). Implementar transições com lógica booleana. Ex.: condição para entrar em MOVE1: . - Da Rede de Petri para implementação: cada lugar vira uma variável booleana ou inteiro (número de tokens). Cada transição vira um bloco lógico que checa as precondições (lugares com tokens) e faz as operações de consumo/produção (set/ reset de variáveis). Existem ferramentas de síntese Petri
ladder. - Testes a fazer: cenário normal com peças em sequência, cenário com falta de peça, cenário de emergência (pressionar
), cenário de sensor falhando (simular não detectando).
Dica de prova: explique como mapear um lugar para uma flag interna e uma transição para um bloco que testa flags; isso mostra compreensão de implementação.
Passo 11
Resumo e entrega final do projeto-exemplo (modelo pronto para usar/adjustar):
- Entreguei: (A) Autômato completo com estados, transições e saídas (Passos 5-6). (B) Rede de Petri com lugares, transições, arcos e marcação inicial (Passo 8).
- Como usar: substitua nomes de sensores/atuadores e condições pela especificação real do seu sistema (quantidade de esteiras, sensores). Se seu enunciado tiver diferenças (ex.: presença de acumulador, empilhador), adapte adicionando lugares/estados correspondentes seguindo a metodologia.
Resposta
Não é possível desenvolver um projeto específico porque o enunciado não fornece descrição do sistema (número de esteiras, sensores, atuadores e regras de operação). Abaixo segue um projeto-exemplo completo que pode ser usado como template e adaptado ao seu caso:
Autômato (caso exemplo: duas esteiras em série)
- Estados:
. - Eventos:
. - Saídas por estado (Moore):
-
: -
: -
: -
: -
: -
: -
:
-
- Transições principais:
-
-
-
-
-
-
- qualquer
; .
-
Rede de Petri (caso exemplo)
- Lugares:
(sistema pronto), (peça na entrada), (E1 em movimento), (peça em mid), (transferência em andamento), (E2 em movimento), (peça na saída), (M2 livre), . - Transições:
. - Arcos (resumo):
-
produz token em . -
consome e produz . -
consome e produz . -
consome e produz . -
consome e produz . -
consome , produz e repõe . -
produz token em e bloqueia recursos. -
consome e repõe .
-
- Marcação inicial
: . Todos os outros lugares com 0 tokens.
Use estes modelos como template: ao receber a descrição real do seu enunciado, ajuste nomes de sensores/atuadores, condições de transferência e adicione lugares/estados para acumuladores, múltiplas linhas ou lógicas de priorização.