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

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 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:
  1. 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).
  2. 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”).
  3. Modelagem discreta: escolher representação (autômato finito para lógica sequencial clara; Rede de Petri para concorrência e análise de propriedades).
  4. Verificação analítica: verificar alcance, vivacidade, contenção, possibilidades de deadlock.
  5. Implementação: converter estados/condições para diagrama de ladder, bloco de função ou código IEC 61131-3.
  6. 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 Q, alfabeto de eventos/entradas \Sigma, função de transição \delta: Q \times \Sigma \to Q, estado inicial q_0 e (opcional) conjunto de estados de saída.
  • Em automação, estados representam modos de operação (ex.: \text{IDLE}, \text{MOVE1}, \text{TRANSFER}, \text{ALARM}); 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 \text{ESTADO}_a \xrightarrow{\text{evento}/\text{saída}} \text{ESTADO}_bí, 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:
  • Sensores:
    • S_{in}: detecta chegada de peça na entrada da E1. (peguei esta necessidade como típica)
    • S_{mid}: detecta peça pronta para transferência na junção E1 \to E2.
    • S_{out}: detecta peça na saída da E2 (peça saída do sistema).
  • Atuadores:
    • M_1: motor da Esteira 1 (liga/desliga).
    • M_2: motor da Esteira 2 (liga/desliga).
    • P: pistão empurrador (opcional) para ajudar transferência (liga/desliga).
  • Botões/entradas operacionais:
    • Start, Stop, EStop (emergência).
  • Regras de operação (simples e típicas):
    1. No modo automático, quando Start é pressionado o sistema fica pronto. Quando S_{in} detecta peça, M_1 liga até S_{mid} detectar a peça; então M_1 para e inicia transferência: aciona P (se houver) e liga M_2 para receber a peça; quando S_{out} detecta peça, M_2 para se não houver peça seguinte.
    2. Evitar colisão: não ligar M_1 para empurrar nova peça para E2 se E2 estiver ocupada próximo da entrada (ou seja, se S_{mid} ou algum sensor de bloqueio indicar presença).
    3. EStop desliga tudo imediatamente e seta estado de ALARM.
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):
  1. Definir estados (cada estado representa um modo de operação coerente):
  • q_0 = \text{IDLE}: aguardando Start.
  • \text{READY}: iniciado, aguardando peça.
  • \text{MOVE1}: Esteira 1 rodando para levar peça até S_{mid}.
  • \text{WAIT\_TRANSFER}: peça detectada em S_{mid}, preparando transferência (pára M_1).
  • \text{TRANSFER}: empurra/encerra transferência e liga M_2.
  • \text{MOVE2}: Esteira 2 rodando até S_{out}.
  • \text{ALARM}: emergência (EStop acionado).
  1. Definir eventos/condições principais (alfabeto \Sigma):
  • Start, Stop, EStop, S_{in}=1, S_{mid}=1, S_{out}=1, \text{timer\_transfer\_done}.
    Nota: variáveis booleanas e timers são tratadas como eventos quando mudam de valor.
  1. Definir saídas (controle de atuadores) por estado (Moore-style para ficar didático):
  • Em \text{IDLE}: M_1=0,M_2=0,P=0.
  • Em \text{READY}: M_1=0,M_2=0,P=0.
  • Em \text{MOVE1}: M_1=1,M_2=0,P=0.
  • Em \text{WAIT\_TRANSFER}: M_1=0,M_2=0,P=0.
  • Em \text{TRANSFER}: M_1=0,M_2=1,P=1 (liga M_2 e empurra).
  • Em \text{MOVE2}: M_1=0,M_2=1,P=0.
  • Em \text{ALARM}: M_1=0,M_2=0,P=0.
  1. Transições (vou escrever no formato \text{estado}_a \xrightarrow{\text{condição}} \text{estado}_bçã):
  • \text{IDLE} \xrightarrow{Start} \text{READY}.
  • \text{READY} \xrightarrow{S_{in}=1} \text{MOVE1}.
  • \text{MOVE1} \xrightarrow{S_{mid}=1} \text{WAIT\_TRANSFER}.
  • \text{WAIT\_TRANSFER} \xrightarrow{\text{cond\_ok\_transfer}} \text{TRANSFER}, onde \text{cond\_ok\_transfer} verifica que M_2 pode receber (ex.: S_{mid} indica peça e não há bloqueio em E2). Em implementação, \text{cond\_ok\_transfer} pode ser simplesmente true ou um teste de sensor.
  • \text{TRANSFER} \xrightarrow{\text{timer\_transfer\_done}} \text{MOVE2}.
  • \text{MOVE2} \xrightarrow{S_{out}=1} \text{READY} (após saída da peça, volta a aguardar próxima peça).
  • Em qualquer estado, \xrightarrow{EStop} \text{ALARM}.
  • De \text{ALARM}, \xrightarrow{Reset} \text{IDLE} (após correção e reset).
  1. Observações didáticas:
  • A transição de \text{MOVE1} para \text{WAIT\_TRANSFER} pára M_1 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
  • \text{IDLE} | Start | \text{READY} | M_1=0,M_2=0,P=0
  • \text{READY} | S_{in}=1 | \text{MOVE1} | M_1=1
  • \text{MOVE1} | S_{mid}=1 | \text{WAIT\_TRANSFER} | M_1=0
  • \text{WAIT\_TRANSFER} | \text{cond\_ok\_transfer} | \text{TRANSFER} | P=1,M_2=1
  • \text{TRANSFER} | \text{timer\_transfer\_done} | \text{MOVE2} | M_2=1,P=0
  • \text{MOVE2} | S_{out}=1 | \text{READY} | M_2=0
  • qualquer | EStop | \text{ALARM} | M_1=0,M_2=0,P=0
  • \text{ALARM} | Reset | \text{IDLE} | —
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 P (círculos), transições T (barras), e arcos direcionais entre eles. Uma marcação m atribui tokens ( \bullet) aos lugares.
  • Firing rule: uma transição t é habilitada se todos os lugares de entrada tiverem tokens suficientes; quando t 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 M_0 é vetor de tokens iniciais; matriz de incidência C = C^+ - C^- (onde C^+ é de arcos saída e C^- 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.
  1. Definir lugares P_i (descrição intuitiva ao lado):
  • P_0: sistema pronto (modo automático) — token indica que a máquina está habilitada a receber peças.
  • P_1: peça na entrada (após S_{in}).
  • P_2: esteira 1 em movimento (recurso M1 ligado).
  • P_3: peça na posição de transferência (detectada por S_{mid}).
  • P_4: transferência em andamento (pistão ou sincronização ativa).
  • P_5: esteira 2 em movimento (recurso M2 ligado).
  • P_6: peça na saída (após S_{out}).
  • P_{alarm}: estado de alarme/EStop (token indica bloqueio por emergência).
  1. Definir transições T_j (ações/acontecimentos):
  • T_{arrive}: peça chega no S_{in}.
  • T_{start\_M1}: iniciar M_1.
  • T_{reach\_mid}: peça alcança S_{mid} (fim de movimento E1).
  • T_{prepare\_transfer}: preparação/cheque para transferência (intertravamento).
  • T_{do\_transfer}: efetua transferência (aciona pistão e liga M2).
  • T_{transfer\_done}: término da transferência / timer expirado.
  • T_{reach\_out}: peça detectada em S_{out}.
  • T_{estop}: emergência ativada.
  • T_{reset}: reset do alarme.
  1. Arcos (vou descrever em palavras para cada transição):
  • T_{arrive}: de mundo externo para P_1 (simula sensor S_{in}): produz token em P_1.
  • T_{start\_M1}: entrada P_0 e P_1 \to consome token de P_1 e produz em P_2 (representa que com sistema pronto e peça disponível, inicia M1 e ocupa o recurso).
  • T_{reach\_mid}: entrada P_2 \to remove token de P_2 e produz em P_3 (peça chega ao mid).
  • T_{prepare\_transfer}: entrada P_3 \to verifica condição de transferência (se necessário pode requerer token em lugar que represente M2 livre) e produz token em P_4. Para simplificar, vamos modelar M2 livre como P_{M2free} (inicialmente 1 token). Então T_{prepare\_transfer} consome P_3 e P_{M2free} e produz P_4 e retira disponibilidade de M2 (representando sincronização).
  • T_{do\_transfer}: entrada P_4 \to produz P_5 (esteira 2 em movimento) mantendo token em P_4 durante o tempo se precisar; para simplificar, T_{do\_transfer} consome P_4 e produz P_5.
  • T_{transfer\_done}: entrada P_5 \to quando S_{out} é detectado ou timer, consome P_5 e produz P_6 e também repõe P_{M2free} (M2 livre novamente).
  • T_{reach\_out}: pode ser modelado como parte de T_{transfer\_done}.
  • T_{estop}: de qualquer lugar possível produz token em P_{alarm} e consome tokens que representam disponibilidade, para modelar que tudo parou.
  • T_{reset}: de P_{alarm} de volta a P_0 (reset completo).
  1. Marcação inicial M_0:
  • M_0(P_0)=1 (sistema pronto).
  • M_0(P_{M2free})=1 (M2 livre).
  • Todos os outros P_i têm 0 tokens.
  1. Comentários didáticos sobre a Petri:
  • Tokens em P_2 e P_5 representam recursos ativos (motores ligados). Com isso é possível analisar se dois recursos entram em conflito.
  • A exigência de P_{M2free} em T_{prepare\_transfer} 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 P_{M2free}, a rede é limitada (cada peça consome e produz tokens controladamente).
  • Liveness (vivacidade): verificar se não há deadlock. No modelo, se EStop for acionado, sistema vai para P_{alarm} e precisa de T_{reset} 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 M_0: tokens em P_0=1, P_{M2free}=1.
  • Ao chegar peça ( T_{arrive} dispara): P_1=1.
  • Agora T_{start\_M1} habilitado (pois P_0=1,P_1=1): despacha e gera P_2=1 e retira P_1. 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, state\_MOVE1 = 1 quando no estado MOVE1). Implementar transições com lógica booleana. Ex.: condição para entrar em MOVE1: Start \land S_{in} \land \lnot EStop.
  • 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 \to 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 EStop), cenário de sensor falhando (simular S_{mid} 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: \text{IDLE},\\ \text{READY},\\ \text{MOVE1},\\ \text{WAIT\_TRANSFER},\\ \text{TRANSFER},\\ \text{MOVE2},\\ \text{ALARM}.
  • Eventos: Start,\\ Stop,\\ EStop,\\ S_{in}=1,\\ S_{mid}=1,\\ S_{out}=1,\\ timer\_transfer\_done.
  • Saídas por estado (Moore):
    • \text{IDLE}: M_1=0,M_2=0,P=0
    • \text{READY}: M_1=0,M_2=0,P=0
    • \text{MOVE1}: M_1=1,M_2=0,P=0
    • \text{WAIT\_TRANSFER}: M_1=0,M_2=0,P=0
    • \text{TRANSFER}: M_1=0,M_2=1,P=1
    • \text{MOVE2}: M_1=0,M_2=1,P=0
    • \text{ALARM}: M_1=0,M_2=0,P=0
  • Transições principais:
    • \text{IDLE} \xrightarrow{Start} \text{READY}
    • \text{READY} \xrightarrow{S_{in}=1} \text{MOVE1}
    • \text{MOVE1} \xrightarrow{S_{mid}=1} \text{WAIT\_TRANSFER}
    • \text{WAIT\_TRANSFER} \xrightarrow{cond\_ok\_transfer} \text{TRANSFER}
    • \text{TRANSFER} \xrightarrow{timer\_transfer\_done} \text{MOVE2}
    • \text{MOVE2} \xrightarrow{S_{out}=1} \text{READY}
    • qualquer \xrightarrow{EStop} \text{ALARM} ; \text{ALARM} \xrightarrow{Reset} \text{IDLE}.
Rede de Petri (caso exemplo)
  • Lugares: P_0 (sistema pronto), P_1 (peça na entrada), P_2 (E1 em movimento), P_3 (peça em mid), P_4 (transferência em andamento), P_5 (E2 em movimento), P_6 (peça na saída), P_{M2free} (M2 livre), P_{alarm}.
  • Transições: T_{arrive},\\ T_{start\_M1},\\ T_{reach\_mid},\\ T_{prepare\_transfer},\\ T_{do\_transfer},\\ T_{transfer\_done},\\ T_{estop},\\ T_{reset}.
  • Arcos (resumo):
    • T_{arrive} produz token em P_1.
    • T_{start\_M1} consome P_1,P_0 e produz P_2.
    • T_{reach\_mid} consome P_2 e produz P_3.
    • T_{prepare\_transfer} consome P_3,P_{M2free} e produz P_4.
    • T_{do\_transfer} consome P_4 e produz P_5.
    • T_{transfer\_done} consome P_5, produz P_6 e repõe P_{M2free}.
    • T_{estop} produz token em P_{alarm} e bloqueia recursos.
    • T_{reset} consome P_{alarm} e repõe P_0.
  • Marcação inicial M_0: M_0(P_0)=1,\\ M_0(P_{M2free})=1. 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.

Exercícios relacionados