• Nenhum resultado encontrado

4.2 Implementação do Controle Supervisório

4.2.2 Implementação no Dispositivo de Controle

Após representar o sistema de controle seguindo a formalização mostrada na seção 4.2.1 deve-se passar ao último passo do processo de implementação, que consiste na transformação do sistema de controle em um programa cuja forma seja adequada a um dispositivo de controle, no caso, um CLP. A forma de implementação escolhida é por meio de Diagrama Escada (do inglês, ladder) [16], dentre outras razões, por se tratar de uma linguagem de programação de CLPs muito utilizada e difundida na atualidade.

A etapa do processo de implementação mostrada na seção 4.2.1 se justifica por estabelecer as variáveis a serem empregadas no programa de controle e suas inter-relações [35]. Desta maneira, torna-se possível a construção de compiladores para geração automática de código, o que reduz con- sideravelmente o tempo despendido com programação no escopo de um projeto de automação. Um bit da memória interna do CLP deve ser alocado para cada uma das seguintes variáveis:

• estados dos geradores que representam os supervisores;

• estados dos autômatos que representam cada um dos módulos do sistema produto; • eventos;

• desabilitações de evento controlável; • comandos;

• respostas;

• sinalizações de evolução de módulo do sistema produto; • desabilitações de evolução de módulo do sistema produto.

4.2.2.1 Nível dos Supervisores Modulares

Neste nível é necessário implementar estruturas que realizem as transições de estado dos ger- adores que representam os supervisores modulares assim como a ativação das desabilitações dos eventos controláveis.

Considere a função de transição de estadosδj do supervisor modular Sj. Pode-se relacionar um estado de origem (x) e um evento (α) a um estado destino (x’), relação esta representada pela tripla ordenada (x, α, x’). Para a implementação do gerador que realiza o supervisor Sj, implementa-se cada uma das triplas ordenadas dadas pela funçãoδj conforme mostrado na Figura 4.4.

Quando ocorrem nos supervisores os chamados autolaços (o estado de origem é o estado de destino) não é necessário implementar a estrutura da Figura 4.4, uma vez que o estado ativo do supervisor não se altera, mesmo com a ocorrência do evento do autolaço.

Figura 4.4: Estrutura de implementação de transição do supervisor

Considere agora a desabilitação de evento controlávelαd e o conjunto de estados de todos os su-

pervisores modulares{x1, x2, ..., xy} nos quais esta desabilitação deve ser ativada. Para cada desabil- itação e conjunto de estados correspondente deve ser implementada a estrutura mostrada na Figura 4.5. Essa estrutura faz com que caso um ou mais supervisores modulares esteja desabilitando algum evento controlável, o sistema de controle como um todo desabilite esse evento.

Figura 4.5: Estrutura de implementação de ativação de desabilitação de evento controlável

4.2.2.2 Nível do Sistema Produto

Considere a função f loc definida pela equação 4.3. Cada uma das n-uplas desta função pode ser representada por(gk, {g1, g2, · · · , gx}). Visto que o módulo do sistema produto relacionado com gk deve ter sua evolução desabilitada caso um dos módulos em{g1, g2, · · · , gx} evolua, esta mesma n- upla pode ser dada por(gkd, {g1evt, g2evt, · · · , gxevt}), onde gievt indica que o módulo gievoluiu e gid estabelece a desabilitação de evolução deste módulo. Cada uma destas n-uplas deve ser implementada conforme mostrado na Figura 4.6.

Figura 4.6: Estrutura de implementação de ativação de desabilitação de evolução de módulo do sis- tema produto

negação de desabilitação de evento controlável (¬αd). Para o primeiro caso, considere a função de

transição de estados ξi onde pode-se representar por (x, r plβ, x’) cada tripla ordenada da função que relaciona um estado de origem (x) e uma resposta (r plβ) a um estado de destino (x’). Durante essa transição o evento não-controlável βdeve ser gerado, conforme definido pela função de saída ωi. Para todo módulo do sistema produto, implementar a estrutura mostrada na Figura 4.7 para cada tripla ordenada da função de transição de estadosξirelacionada à uma transição ocasionada por uma resposta. x x' rpl gid S x R gievt S gievt

Figura 4.7: Estrutura de implementação de transição relacionada a uma resposta

Já para uma negação de desabilitação de evento controlável, a tripla ordenada associada à função de transição de estados ξi é dada por (x, ¬αd, x’), que relaciona um estado de origem (x) e uma negação de desabilitação de evento controlável (¬αd) a um estado de destino (x’). Durante esta

transição são gerados o evento controlável α e o comando cmdα conforme a função de saída ωi. Para todo módulo do sistema produto, implementar a estrutura mostrada na Figura 4.8 para cada tripla ordenada da função de transição de estadosξirelacionada à uma transição ocasionada por uma negação de desabilitação de evento controlável.

x x' gid S x R g ievt S d cmd gievt

Figura 4.8: Estrutura de implementação de transição relacionada a uma negação de desabilitação de evento controlável

Cabe ressaltar que a estrutura que desabilita a evolução de um autômato gi(Figura 4.6) deve pre- ceder imediatamente todas as implementações das transições deste autômato (Figuras 4.7 e 4.8). A desabilitação de evolução de um autômato deve ser desativada depois que todas as suas transições de

estados tiverem sido processadas. Além disso, as variáveis que indicam a evolução dos autômatos devem ser desativadas depois que as transições de estados de todos os autômatos tiverem sido proces- sadas.

Nas estruturas mostradas nas Figuras 4.7 e 4.8 percebe-se que quando ocorre uma transição de estado em um dos autômatos gi, a sinalização de evolução do mesmo é ativada com retenção. Vieira [35] considera que para que uma transição ocorra em um autômato, é necessário também que apenas a desabilitação de evolução do autômato não esteja ativada. No entanto, caso o próprio autômato evolua em um determinado ciclo do CLP, a estrutura, tal como foi proposta, não impede a ocorrência de uma outra transição no mesmo autômato. Por isso, propõe-se uma outra condição para o ocorrência de uma transição: que a evolução do autômato em questão (gievt) não esteja ativada.

A ordem na qual as estruturas das Figuras 4.7 e 4.8 são colocadas no programa interfere na priori- dade de uma transição sobre as demais. A transição que for processada primeiro terá maior prioridade sobre aquelas que a sucedem, visto que caso ela ocorra nenhuma outra transição poderá ocorrer no mesmo autômato no mesmo ciclo. Assim sendo, deve-se priorizar o tratamento da ocorrência das transições relacionadas às respostas, uma vez que elas estão diretamente relacionadas aos eventos não-controláveis, ou seja, aos eventos que ocorrem espontaneamente em algum instante de tempo desconhecido e não podem ser coibidos.

4.2.2.3 Nível das Seqüencias Operacionais

A implementação da lógica relativa às seqüências operacionais, assim como as demais já apre- sentadas, pode ser realizada por meio de diagrama escada. Devido à especificidade deste nível não existe um procedimento padrão para projeto. A implementação neste caso irá depender inteiramente das atividades a serem desempenhadas pelo subsistema a que diz respeito.

Neste nível é muito comum que outras formas de implementação sejam utilizadas visto que tais seqüências muitas vezes já são projetadas e otimizadas pelos próprios fabricantes do equipamento. Um exemplo tradicional é a implementação da lógica das seqüências operacionais em placas de cir- cuito integrado embutidas no próprio equipamento. Neste casos utiliza-se muitas vezes programação em linguagens como C, C++ ou Java. Outras vezes pode-se programar as seqüencias operacionais em alguma outra linguagem de programação de CLPs que seja mais conveniente ao programador e à situação.

Essa diversidade de possibilidades de programação confere uma flexibilidade ao nível Seqüências Operacionais bastante interessante visto que possibilita a integração dessas seqüências aos demais níveis, independentemente da forma com que foram programadas.

4.2.2.4 Inicialização e Ordenação do Programa de Controle

Segundo Vieira [35], na inicialização do programa que implementa o sistema de controle é necessário:

• desativar todas as variáveis internas do CLP; • desativar todas as saídas de sinal;

• ativar a variável relacionada ao estado inicial de todo gerador Sj;

• ativar as variáveis relacionadas ao estado inicial de todo autômato gi;

• ativar as variáveis relacionadas ao passo inicial de todo autômato gi.

Recomenda ainda que a seqüência de implementação do programa seja a seguinte:

• inicialização do programa;

• estrutura dos geradores que representam os supervisores; • estrutura de ativação de desabilitação de eventos controláveis; • estrutura dos autômatos do sistema produto;

• desativação de desabilitações de evolução dos módulos do sistema produto; • estrutura das seqüências operacionais.