jonatas pavei prh34 ufsc das g
TRANSCRIPT
UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE ENGENHARIA DE CONTROLE E AUTOMAÇÃO INDUSTRIAL
Sistemas de Controle via Redes
Industriais: Desenvolvimento de um software para controle avançado via
OPC
Monografia submetida à Universidade Federal de Santa Catarina como requisito para a aprovação da disciplina:
DAS 5501: Estágio em Controle e Automação Industrial
Jonatas Pavei
Florianópolis, Março de 2009
Sistemas de Controle via Redes Industriais: Desenvolvimento de um software para controle avançado via
OPC
Relatório submetido à Universidade Federal de Santa Catarina
como requisito para a aprovação da disciplina:
DAS 5501: Estágio em Controle e Automação Industrial
Jonatas Pavei
Florianópolis, Março de 2009
2
Sistemas de Controle via Redes Industriais:
Desenvolvimento de um software para controle avançado
via OPC
Jonatas Pavei
Orientador:
Prof. Agustinho Plucenio
______________________________ Assinatura do Orientador
Este relatório foi julgado no contexto da disciplina
DAS 5501: Estágio e Controle e Automação Industrial
e aprovado na sua forma final pelo
Curso de Engenharia de Controle e Automação
3
Agradecimentos
Agradeço à minha família, por todo apoio e compreensão nesses últimos
anos. Mesmo à distância, foi fundamental sua participação.
Agradeço à minha noiva Thiele, minha companheira em todas as ocasiões,
sempre presente nos momentos mais importantes da minha vida, por todo carinho,
atenção e motivação.
Agradeço ao Agustinho, pelo apoio, paciência e motivação que muito me
contribuíram.
Agradeço o apoio financeiro da Agência Nacional do Petróleo, Gás Natural e
Biocombustiveis-ANP e da Financiadora de Estudos e Projetos (FINEP) por meio do
Programa de Recursos Humanos da ANP para o Setor do Petróleo e Gás PRH-34
ANP/MCT.
4
Resumo
OPC é um padrão industrial aberto para transmissão de dados em tempo real que
consiste em um conjunto padrão de interfaces, propriedades e métodos para o uso
em aplicações de controle de processos e de automatização de manufaturas.
Utilizando um servidor OPC conectado a um dispositivo de comunicação como um
computador, CLP, rede Foudation Fieldbus, etc, os dados desses dispositivos são
disponibilizados para diferentes aplicações. Os clientes OPC se conectam a um
servidor OPC, a fim de buscar as informações coletadas nos dispositivos para que
se possa ler, escrever e atualizar os dados coletados.
Os custos de integração de sistemas eram altos devido a falta de uma
padronização nos protocolos utilizados por diferentes fabricantes. A tecnologia OPC
possibilitou uma padronização de dados compartilhados e uma considerável redução
de custo na integração de sistemas assim como uma maior facilidade de uso e
melhoria na confiabilidade da troca de informações. Mais escolhas de fornecedores,
melhor acesso aos dados do processo, facilidade da operação “plug-and-play”, e a
utilização eficiente de recursos do desenvolvimento são os benefícios principais da
tecnologia OPC.
A partir da constatação da existência dessas facilidades foi proposto o
desenvolvimento de um software para a realização de controle avançado em
sistemas onde se utilizam tecnologias de redes industriais com servidores OPC. Este
software deveria possuir blocos de controle a fim de permitir a implementação de
diferentes estratégias de controle.
O desenvolvimento será realizado com o auxílio de uma planta didática (PD3 da
empresa SMAR) que opera com a tecnologia Foundation Fieldbus e CLP, ambos
com servidores OPC. A tecnologia Foundation Fieldbus utiliza uma rede local de
comunicação permitindo que instrumentos desenvolvidos para esta tecnologia se
comuniquem entre si trocando informações em formato digital segundo uma
estratégia de controle definida pelo usuário que implementa o controle regulatório de
um determinado processo. Os instrumentos Foundation Fielbus são dotados de
5
processadores e interface de comunicação e executam tarefas de controle
processando algoritmos encapsulados em Blocos Funcionais pré-definidos e
instanciados pelo usuário. Todas as informações do processo (variáveis medidas,
referências de controle, sinais de controle, parâmetros, etc.) se transmitem utilizando
uma rede digital que interliga os diferentes componentes de um sistema de controle
(atuadores, controladores, transmissores, etc). Entre os benefícios na utilização de
uma rede Foundation Fieldbus, se encontram a interoperabilidade (O padrão
Foundation Fieldbus é aberto), dados de processo na forma digital, economia de
cabos, melhor segurança da planta, entre outros.
6
Abstract
OPC is an open industry standard for data transmission in real time. It makes use
of standard interfaces, properties and methods to implement process control and
manufacturing automation. An OPC server runs in a computer, PLC, etc and creates
tags for the process variables which are delivered through a communication device to
OPC clients running in other machines. The OPC clients connect with the OPC
server, to collect the information in the devices for reading, writing and updating the
tags.
Systems integration costs were high due to the lack of a standard communication
protocol. The OPC technology provided a standard for data sharing resulting in a
considerable cost reduction in system integration due to its simplicity and reliability in
applications needing real time information exchange. More choices, better access to
process data, technical facilities as “plug-and-play” operation, and the efficient
utilization of development resources are the main benefits of OPC technology.
In order to take advantage of all these facilities it was proposed the development
of software for advanced control in systems using technologies of industrial networks
with OPC servers. The proposed software is intended to make use of the OPC
technology in order to access process data through the several OPC servers running
in the regulatory control level of a modern plant like PLCs, Fielbus, etc. The main
services the software will provide is Multivariate Control like Model Predictive Control
(QDMC, GPC, Nonlinear MPC), Feed-Forward Control, Smith Predictor Control,
Cascade Control, etc.
The development will be done using a Laboratory Plant (PD3 Smar) which makes
use of Foundation Fieldbus Technology and PLC both with OPC servers.
The Foundation Fieldbus technology uses a local area network allowing devices
developed for this technology to communicate with each other exchanging
information in a digital format according to a control strategy defined by the user. This
control strategy implements the regulatory control. The Foundation Fieldbus devices
have processors and communication interfaces allowing them to execute control
7
tasks by executing algorithms encapsulated in Function Blocks which are instantiated
by the user.
All process data (measuring variables, control references, parameters, etc.) are
transmitted using local area networks that join the different components of a control
system (actuators, controls, transmitters, etc.). Among the benefits of a Fieldbus
Network, is the interoperability (devices from different manufactures), process data
quality (digital and quality control), less cabling, better plant security, among others.
8
Sumário
AGRADECIMENTOS .............................................................................................................................3
RESUMO..............................................................................................................................................4
ABSTRACT ...........................................................................................................................................6
SUMÁRIO ............................................................................................................................................8
SIMBOLOGIA ..................................................................................................................................... 10
CAPÍTULO 1: INTRODUÇÃO ............................................................................................................... 11
1.1: PADRÃO OPC .................................................................................................................................. 11
1.1.1: Histórico ............................................................................................................................... 11
1.1.2: Arquitetura .......................................................................................................................... 11
1.2: REDES INDUSTRIAIS ........................................................................................................................... 16
1.2.1: Introdução ........................................................................................................................... 16
1.2.2: Aspectos Importantes .......................................................................................................... 17
1.3: IMPLEMENTAÇÃO DO SOFTWARE ......................................................................................................... 18
1.3.1: Motivação ............................................................................................................................ 19
1.3.2: Objetivos .............................................................................................................................. 19
1.3.3: Metodologia ........................................................................................................................ 19
1.3.4: Justificativa .......................................................................................................................... 20
1.3.5: Contexto do Projeto no Curso de Controle e Automação .................................................... 20
1.3.6: Estrutura do Documento ..................................................................................................... 21
CAPÍTULO 2: ESTRUTURA DO SOFTWARE .......................................................................................... 22
2.1: ARQUITETURA .................................................................................................................................. 22
2.1.1: Cliente OPC .......................................................................................................................... 22
2.1.2: Interface............................................................................................................................... 23
2.1.3: Rede industrial ..................................................................................................................... 23
2.1.4: Blocos de Controle ............................................................................................................... 24
2.2: PLATAFORMA UTILIZADA .................................................................................................................... 25
2.2.1: Linguagem de Programação – JAVA .................................................................................... 25
2.2.2: Ambiente de Desenvolvimento Netbeans IDE...................................................................... 26
2.2.3: Bibliotecas OPC .................................................................................................................... 26
9
2.3: MODELAGEM DO SISTEMA ................................................................................................................. 27
2.4: CRONOGRAMA ................................................................................................................................. 29
CAPÍTULO 3: TÉCNICAS UTILIZADAS .................................................................................................. 30
3.1: TEMPO DE AMOSTRAGEM .................................................................................................................. 30
3.1.1: Leitura e Escrita de Dados ................................................................................................... 30
3.1.2: Tarefa Periódica ................................................................................................................... 33
3.2: OLE X XML .................................................................................................................................... 34
3.3: BIBLIOTECA OPC .............................................................................................................................. 35
3.4: BLOCOS DE CONTROLE ....................................................................................................................... 36
CAPÍTULO 4: ATIVIDADES DESENVOLVIDAS ....................................................................................... 37
4.1: INTERFACE GRÁFICA .......................................................................................................................... 37
4.2: CLIENTE OPC .................................................................................................................................. 38
4.3: TAREFA PERIÓDICA ........................................................................................................................... 41
4.4: DEFINIÇÃO DO PERÍODO DE AMOSTRAGEM............................................................................................ 41
4.5: ALGORITMOS DE CONTROLE ............................................................................................................... 44
4.6: LÓGICA DO SOFTWARE ...................................................................................................................... 45
CAPÍTULO 5: RESULTADOS ................................................................................................................ 46
5.1: RESULTADOS DA APLICAÇÃO DA TAREFA PERIÓDICA ................................................................................. 46
5.2: GARANTIA DOS TEMPOS DE ESCRITA E LEITURA ...................................................................................... 47
5.3: ANDAMENTO DO SOFTWARE .............................................................................................................. 48
5.3.1: Interface............................................................................................................................... 48
5.3.2: Cliente OPC .......................................................................................................................... 49
5.3.3: Lógica do Software .............................................................................................................. 49
5.4: ALGORITMOS DE CONTROLE ............................................................................................................... 49
CAPÍTULO 6: CONCLUSÕES E PERSPECTIVAS ...................................................................................... 51
BIBLIOGRAFIA: .................................................................................................................................. 53
10
Simbologia
OPC - Ole process of control
OLE - Object Linking and Embedding
DCOM - Distribuited Component Object Model
UML - Unified Modeling Language
PDIII - Planta Didática III, da empresa brasileira SMAR.
tags - Itens OPC, referentes as variáveis dos dispositivos ligados ao um
servidor OPC
Thread - processo de divisão de tarefas em programação de computadores
Timestamp – Tempo real relacionado ao item OPC
Student - é uma distribuição de probabilidade estatística
11
Capítulo 1: Introdução
1.1: Padrão OPC
1.1.1: Histórico
Em 1995, buscando uma padronização nas operações de comunicação em tempo
real, algumas empresas se reuniram com o objetivo de desenvolver um padrão
baseado na tecnologia OLE/DCOM para acesso de dados em tempo real dentro do
sistema operacional Windows. Com o resultado dessa reunião, formou-se um grupo
que hoje conta com mais de 300 membros em todo mundo, incluindo quase todos os
maiores provedores de controle de sistemas, instrumentação e controle de
processos. Essa organização, sem fins lucrativos, chama-se OPC Foundation e a
partir dela são definidos os padrões OPC.
1.1.2: Arquitetura
O padrão OPC é baseado nas tecnologias OLE e DCOM da Microsoft, que é
um membro da OPC Foundation. Essas tecnologias dão suporte para essa interface
padrão que estabelece comunicação entre dispositivos de campo (CLPs, sensores,
redes industriais, etc.) com sistemas de supervisão, monitoração (SCADA, ERP,
etc.). Essas tecnologias são descritas abaixo:
A tecnologia OLE (Object Linking and Embedding) foi desenvolvida pela
Microsoft em meados de 1990, para suprir a necessidade de se integrar diferentes
aplicações dentro da plataforma Windows, de forma a solucionar os problemas de
desempenho e confiabilidade do até então utilizado padrão DDE (Dynamic Data
Exchange) (OPCTI).
Como uma continuação da tecnologia OLE, o DCOM (Distribuited Component
Object Model) surgiu junto com o sistema operacional Windows NT e foi logo aceito
12
pela indústria. Basicamente, o DCOM é um conjunto de definições para permitir a
implementação de aplicações distribuídas em uma arquitetura cliente-servidor. Desta
forma, um cliente pode acessar diferentes servidores ao mesmo tempo e um
servidor pode disponibilizar suas funcionalidades para diferentes clientes ao mesmo
tempo. Através da definição de interfaces, o DCOM permite que objetos sejam
instanciados de forma distribuída e seus serviços e métodos (funções) sejam
acessíveis por diferentes programas. Para isso é necessário a utilização de uma
linguagem especial, a IDL (Interface Definition Language). Isto significa que cada
cliente pode chamar os métodos de qualquer objeto DCOM em um determinado
servidor, independentemente do ambiente de programação (linguagem, compilador,
versão, etc.) que os mesmos foram criados. Através de um identificador único
(GUID, Global Unique Identifier), as interfaces são protegidas contra modificações
após a sua publicação e a compatibilidade dos objetos DCOM é então garantida. Os
objetos DCOM existem nos servidores DCOM. A forma de implementação dos
servidores (DLL EXE, InProcess e OutProcess) determina como os objetos são
carregados e gerenciados pelo servidor. Os objetos DCOM são acessíveis através
de uma identificação CLSID (ClassIdentifier) mantida pela Registry do sistema
operacional. Através da CLSID os clientes podem lançar os componentes, solicitar
as interfaces dos objetos e chamar os métodos desta interface. O ciclo de vida de
um objeto DCOM é controlado pelo próprio componente, de forma que o mesmo se
“auto-deleta” quando nenhum cliente está utilizando o mesmo, fazendo a liberação
dos recursos do sistema (OPCTI).
A utilização dessas tecnologias define bem o objetivo do uso do padrão OPC
como integração de sistemas, que fica evidenciado na figura abaixo:
13
BatchBatch
OPC UA OPC UA
Manufacturing, Production and MaintenanceManufacturing, Production and Maintenance
OPC UA
OPC UA
Adv.Adv.
ControlControl
OPC UA
OPC UA
HMIHMI SCADASCADA
ControlControl
MESMES
OPC UAOPC UA
OPC UAOPC UA
Industrial NetworksIndustrial Networks Data
Acquisition
Data
AcquisitionPLCDCS
PLCDCS ??.......????.......??
Corporate EnterpriseCorporate Enterprise
OPC UA OPC UA
Figura 1: Visão Geral do Uso do Padrão OPC
Após a criação da OPC Foundation, foi publicada a primeira especificação
para atender as necessidades das indústrias que passou a ser chamada de OPC
Data Access Specification Version 1.0A. E a partir de então foram desenvolvidas
muitas outras especificações de acordo com as necessidades do mercado. Segue
abaixo a estrutura atual das especificações, umas já aprovadas e algumas a serem
aprovadas:
� OPC Overview (Versão 1.00) – Descrição geral dos campos de aplicação das
especificações OPC.
� OPC Common Definitions and Interfaces (Versão 1.01) – Definição das
funcionalidades básicas para as demais especificações.
� OPC Data Access Specification (Versão 3.00) – Definição da interface para
leitura e escrita de dados de tempo real.
� OPC Alarms and Events Specification (Versão 1.01) – Definição da interface
para monitoração de eventos.
14
� OPC Historical Data Access Specification (Versão 1.02) – Definição da
interface para acesso a dados históricos.
� OPC Batch Specification (Versão 2.00) – Definição da interface para acesso
aos dados de processos por batelada (batch). Esta especificação é uma extensão da
OPC Data Access Specification.
� OPC Security Specification (Versão 1.00) – Definição da interface para
utilização de políticas de segurança.
� OPC and XML (Versão 1.01) – Integração entre OPC e XML para aplicações via
Internet (web).
� OPC DX Data Exchange for Ethernet (Versão 1.00) – Definição da
comunicação entre servidores OPC através de uma rede TCP/IP
Figura 2: Especificações do Padrão OPC
15
A publicação dessas especificações possibilitou uma gama de vantagens para a
indústria com a utilização desse padrão (OPC Foudation, March 6, 2008):
� Padronização das interfaces de comunicação entre os servidores e clientes de
dados de tempo real, facilitando a integração e manutenção dos sistemas.
� Eliminação da necessidade de drivers de comunicação específicos
(proprietários);
� Melhoria do desempenho e otimização da comunicação entre dispositivos de
automação.
� Interoperabilidade entre sistemas de diversos fabricantes;
� Integração com sistemas MES1, ERP2 e aplicações Windows (Excel, etc.);
� Redução dos custos e tempo para desenvolvimento de interfaces e drivers de
comunicação, com conseqüente redução do custo de integração de sistemas.
� Facilidade de desenvolvimento e manutenção de sistemas e produtos para
comunicação em tempo real;
� Facilidade de treinamento.
1 MES (Manufacturing Execution Systems) é um sistema de chão-de-fábrica orientado para a
melhoria de desempenho que complementa e aperfeiçoa os sistemas integrados de gestão
(planejamento e controle) da produção.
2 ERP (Enterprise Resource Planning) ou SIGE (Sistemas Integrados de Gestão Empresarial,
no Brasil) são sistemas de informações que integram todos os dados e processos de uma
organização em um único sistema.
16
1.2: Redes Industriais
1.2.1: Introdução
Com a tendência da informatização crescente das empresas, cada vez mais
se pôde aprimorar as técnicas utilizadas nos desenvolvimentos de produtos e
serviços. Este aprimoramento, porém, exige um número cada vez maior de troca de
informações em um campo fabril, tanto em nível de chão de fabrica como nos altos
níveis dentro de uma empresa. (Stemmer, 2001)
A utilização de redes industriais veio impulsionada pelo motivo de que as
redes de comunicação utilizadas até o momento não apresentavam características
desejáveis para um cenário fabril, como por exemplo:
• Garantia de tempo real, garantia da troca de informações e a garantia da
troca de informações em um tempo determinado.
• Segurança intrínseca, por operar na maioria das vezes em ambientes
controlados, as características da rede devem ser tais que durante sua
operação não haja nenhum risco à segurança física dos operários e a
integridade das máquinas e instalações.
• Capacidade de dispositivos na rede, a necessidade da utilização de vários
dispositivos em uma rede pode ser um fator limitante em seu uso, assim como
pode também afetar a confiabilidade da entrega dos dados.
• Padronização dos dados, por existirem diferentes drivers para diferentes
dispositivos e assim diferentes formas de dados, o custo, a complexidade e a
eficiência da integração desses dispositivos se tornava inviável para
aplicações industriais. A indústria de instrumentação percebia a necessidade
de uma padronização entre todos os fabricantes.
Com o surgimento de redes que resolviam os problemas acima citados pode-
se então integrar cada vez mais o chão de fábrica, assim como todos os níveis
hierárquicos de uma empresa.
17
Outra grande mudança que só pode ser realizada após o surgimento de redes
industriais foi à utilização de elementos inteligentes cada vez mais perto dos
processos, chegando até ao nível de chão de fábrica. Isto diminuiu o tráfego na rede
tornando-a mais eficaz em termos de controle e supervisão. A figura 3 representa
um exemplo de estrutura de uma rede industrial:
Figura 3: Estrutura de uma Rede Industrial
1.2.2: Aspectos Importantes
18
1.2.2.1: Restrições de Tempo real
Para a utilização das redes industriais em aplicações de controle, a garantia
de tempo real é um fator crucial na qualidade e confiabilidade do sistema. Pois, as
redes são de uso compartilhado e os sistemas de controle necessitam de troca de
informações em intervalos fixos.
Um sistema em tempo real é um sistema computacional para o qual é
requerida uma reação a estímulos oriundos do ambiente dentro de intervalos de
tempo impostos pelo próprio ambiente (Farines, Fraga, & Oliveira). Na figura 4
observa-se a aplicação de um sistema de tempo real.
Figura 4: Sistema de Tempo Real
Portanto, as redes para essa utilização devem ser deterministas, a fim de
garantir o escalonamento da entrega de pacotes e garantir a confiabilidade do
sistema.
Outro parâmetro associado com esses sistemas é o Jitter. O Jitter é uma
variação estatística do retardo na entrega de dados em uma rede, ou seja, pode ser
definida como a medida de variação do atraso entre os pacotes sucessivos de
dados. Observa-se ainda que, uma variação de atraso elevada produz uma
recepção não regular dos pacotes.
1.3: Implementação do Software
19
1.3.1: Motivação
OPC é um padrão industrial aberto para transmissão de dados em tempo real
que está sendo adotado pela maioria dos fabricantes de produtos, tornando-se um
padrão de mercado. É amplamente utilizado atualmente nas indústrias, na
comunicação com o chão de fábrica. Diante dessa realidade torna-se cada vez mais
pertinente o desenvolvimento de sistemas que utilizem a comunicação com o chão
de fabrica a fim de melhorar o desempenho e a otimização dos processos através da
comunicação entre dispositivos de controle e automação.
1.3.2: Objetivos
Deseja-se desenvolver um software para controle de sistemas utilizando a
tecnologia OPC. O software será utilizado para a implementação de estratégias de
controle de alto nível permitindo ao usuário definir subsistemas de controle e a
aplicação de técnicas de controle avançadas como Controle Preditivo multivariável
Linear e não Linear, Controle de Processos bateladas, Controle de seqüências, etc.
1.3.3: Metodologia
A metodologia prevê o estudo dos conceitos fundamentais de sistemas de
controle via rede, buscando embasar com a terminologia, estado da arte sobre
sistema de controle em tempo real. O estudo permitirá ainda a definição dos tempos
de amostragem mínimos atingíveis com a tecnologia OPC e a estimativa do jitter
esperado.
Na seqüência deve-se estudar a implementação de uma estrutura de
software que incorpore um cliente OPC. Esta fase do projeto é crucial para o
desenvolvimento do projeto.
A partir daí deve-se criar as interfaces para o usuário executar as tarefas de
configuração dos blocos. Os blocos irão utilizar algoritmos desenvolvidos pelos
professores orientadores e co-orientadores.
Todo o desenvolvimento do projeto utilizará técnicas de desenvolvimento de
software avançadas como UML (Unified Modeling Language).
20
1.3.4: Justificativa
O resultado final deste projeto deverá conduzir ao desenvolvimento de
sistema de controle baseado em redes que permita uma boa adaptação a qualquer
meio industrial, onde há algum servidor OPC conectado a esta. No qual, também
poderá ser escolhido, dentro de diversas opções, o tipo de controle que melhor se
adaptará ao processo.
O principal benefício consiste na redução dos custos e tempo de
desenvolvimento de interfaces e drivers de comunicação, com conseqüente redução
de custo de integração de sistemas.
Tais sistemas têm aplicação direta no setor de petróleo e gás, incluindo-se aí,
com especial ênfase, a automação de refinarias de petróleo, plataformas de
produção off-shore, supervisão e controle de oleodutos, etc.
1.3.5: Contexto do Projeto no Curso de Controle e Automação
Para o desenvolvimento de um software com objetivo para controle é
necessário utilizar-se de vários conceitos de controle e automação, visto que,
conceitos de redes, software e controle são fundamentais.
Um grande conjunto de disciplinas, vistas durante o curso, foram abordadas
no desenvolvimento do Software para controle avançado, dentre elas: Redes de
Computadores para Automação Industrial, Informática industrial, Sistemas
Realimentados, Tópicos Especiais em Controle: Técnicas de Controle Aplicadas à
Industria de Petróleo e Gás, Metodologia para Desenvolvimento de Sistemas.
Para a integração das redes industriais com o sistema externo e
conhecimento de seus problemas intrínsecos foi utilizado o conceito de Redes
Industriais. Assim como, verificar os possíveis problemas com sistemas de tempo
21
real e suas limitações foi imprescindível o conhecimento adquirido em Informática
Industrial.
O Software foi desenvolvido usando a plataforma JAVA, utilizando conceitos
de orientação a objetos, com isso técnicas de Metodologia.
Como o objetivo principal desse sistema é a aplicação de controle em plantas
industriais. As matérias como Sistemas Realimentados e Técnicas de Controle
Aplicadas à Industria de Petróleo e Gás, vista no programa PRH-34, foram
fundamentais para o conhecimento das técnicas de controle avançados e clássicos,
assim como um melhor entendimento com instantes de amostragens possíveis e
desejados nos sistemas a serem controlados.
Por fim, a integração de varias tecnologias e disciplinas vistas dentro do curso
de engenharia de controle e automação é um ambiente favorável para um
Engenheiro de Controle e Automação poder desempenhar sua função da melhor
forma possível.
1.3.6: Estrutura do Documento
Este documento visa mostrar as etapas do desenvolvimento do Software para
aplicações de controle avançado. Onde os capítulos seguintes são organizados da
seguinte forma:
• Capitulo 2: Será dada uma visão geral do projeto, apresentando a
metodologia utilizada, a arquitetura do projeto e o cronograma de
atividades.
• Capitulo 3: Serão mostrados os problemas encontrados no
desenvolvimento do sistema, assim como as técnicas utilizadas para
suas soluções.
• Capitulo 4: Serão mostradas as implementações utilizadas no projeto
até esse momento.
• Capitulo 5: Serão mostrados os resultados encontrados até esse
momento
• Capitulo 6: Conclusões e Perspectivas
22
Capítulo 2: Estrutura do Software
2.1: Arquitetura
Para o desenvolvimento desse sistema, foi realizada uma divisão entre as
partes mais importantes do desenvolvimento do software. Cada uma das partes tem
seu papel fundamental no funcionamento e na troca de informações entre eles.
Estes partes são divididas da seguinte forma:
2.1.1: Cliente OPC
Para os propósitos desejados para a aplicação, foi desejado o
desenvolvimento de um cliente OPC, no qual este pode se conectar com vários
servidores OPC diferentes, sendo assim muito dinâmico no que se diz respeito à
quantidade de plantas industriais e itens que este pode comunicar-se. Também outra
característica desejada foi à conexão remota ao servidor OPC. A figura 5 mostra a
comunicação entre clientes e servidores OPC.
Figura 5: Comunicação entre OPC Client e OPC Server
23
2.1.2: Interface
Para realizar a interface homem - máquina com o usuário e poder fornecer a ele
a possibilidade de escolher qual a melhor estratégia de controle para a planta em
que se deseja controlar. Foi utilizada a linguagem JAVA, com o ambiente de
desenvolvimento Netbeans IDE, para a aplicação deste.
A interface tem como função poder fornecer ao usuário as opções de
implementar a estratégia de controle desejada e assim fazer a comunicação desta
estratégia com o cliente OPC, que por sua vez fará a comunicação com a planta, e
então, garantir o bom desempenho e confiabilidade do sistema.
2.1.3: Rede industrial
O sistema tem como objetivo final sua aplicação em uma rede industrial, logo
uma rede industrial provida de um servidor OPC é fundamental para o sucesso
desse projeto, pois é baseada nessas tecnologias que pretende atingir a eficiência
desejada.
Para fins de testes e implementação foi utilizado a Planta Didática III da
empresa brasileira SMAR. Essa planta é equipada com uma rede industrial
Foundation Fieldbus e um CLP, da mesma empresa, onde ambos contêm servidores
OPC disponíveis. Essa rede conta com alguns sensores e atuadores micro
processados ligados em um barramento, onde é possível aplicar varias técnicas de
controle e possibilitar um ambiente industrial próximo do real para fins de teste e
validações do sistema.
2.1.4: Blocos de Controle
Em aplicações industriais, onde se encontram redes
que se possam controlar processos,
mais usadas nesses sistemas são de controle avançado, no qual estes controlam
uma gama de processos, informando os
no chão de fabrica.
Esses tipos de controle podem
• Controle Preditivo Multivariável DMC
• Controle Preditivo Multivariável GPC
• Controle Preditivo Multivariável Não
24
Figura 6: Planta Didática Smar III
Blocos de Controle
iais, onde se encontram redes integrando dispositivos para
am controlar processos, diferentes tipos de controles são
mais usadas nesses sistemas são de controle avançado, no qual estes controlam
uma gama de processos, informando os set-points para os controladores presentes
Esses tipos de controle podem ser:
Controle Preditivo Multivariável DMC
Controle Preditivo Multivariável GPC
Controle Preditivo Multivariável Não-Linear
integrando dispositivos para
diferentes tipos de controles são desejados. As
mais usadas nesses sistemas são de controle avançado, no qual estes controlam
para os controladores presentes
25
• Controle Feed-Forward
• Estrutura de Controle baseado no Preditor de Smith
• Estrutura de Controle em Cascata
• Estrutura de Controle Override
• Controle de Processos Batelada
• Etc.
Esses blocos serão desenvolvidos para que o usuário, ao utilizar-se do sistema,
possa definir as variáveis controladas e manipuladas de um processo unitário
que deseje controlar e aplicar a técnica de controle desejada utilizando as
bibliotecas disponíveis.
2.2: Plataforma Utilizada
Com a finalidade de preencher todos os requisitos expostos anteriormente,
tais como: alta confiabilidade, acesso à dados em tempo real e facilidade de
integração como aplicações externas, foi escolhida uma plataforma de
desenvolvimento e alguns componentes de terceiros. O detalhamento desses
componentes é feito a seguir.
2.2.1: Linguagem de Programação – JAVA
A escolha de Java deve-se a uma série de motivos. Primeiramente, pretendia-
se usar uma linguagem completamente orientada a objetos, com uma grande
variedade de ferramentas e componentes. Além disso, a máquina virtual de Java
permite que as aplicações construídas nessa linguagem sejam executadas na
maioria dos sistemas operacionais (Deitel & Deitel, 2005). Existem ainda diversas
bibliotecas livres, amplamente difundidas e confiáveis disponíveis nessa linguagem.
26
2.2.2: Ambiente de Desenvolvimento Netbeans IDE
Foi utilizado para o desenvolvimento do software o ambiente de
desenvolvimento netbeans IDE. Esse ambiente é um software livre altamente
utilizado, pois ele possui grande confiabilidade e opções para se desenvolver um
software. Um dos principais motivos pela escolhe deste ambiente é a sua grande
facilidade e disponibilidade de criação de ambientes gráficos para o desenvolvimento
de softwares.
Figura 7: Ambiente de Desenvolvimento Netbeans IDE
2.2.3: Bibliotecas OPC
Na integração de um cliente OPC com o sistema desenvolvido, foram
selecionadas algumas bibliotecas potenciais para a aplicação desejada. Entre estas
bibliotecas algumas são livres, porém visando a maior confiabilidade do sistema em
se tratando na restrição temporal foram selecionadas também algumas privadas.
27
Entre as possíveis bibliotecas em que existia a possibilidade de incorporar no
projeto foram pré selecionadas algumas:
• JeasyOpc
• JOpcClient
• JOPC-Bridge
Sendo apenas a JeasyOPC uma biblioteca livre.
2.3: Modelagem do Sistema
. A Unified Modeling Language (UML) é uma tentativa de padronizar a
modelagem orientada a objetos de uma forma que qualquer sistema, seja qual for o
tipo, possa ser modelado corretamente, com consistência, fácil de comunicar com
outras aplicações, simples de ser atualizado e compreensível (Deitel & Deitel, 2005).
Assim foi desenvolvido um diagrama de classes UML, a fim de melhor poder
representar o sistema sem ambigüidades, com clareza e consistência. Esse
diagrama foi baseado nas funcionalidades desejadas para que o sistema se
comporte da forma especificada e desejada. Procurou-se também realizar-lo de uma
forma que facilite a implementação do software, assim como, facilite o seguimento
do desenvolvimento do sistema por bolsistas futuros.
28
Figura 8: Diagrama de Classes
29
2.4: Cronograma
Duração do trabalho: Abril/2007 – Março/2009
Ano 2007 2008 2009
Meses 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3
Etapas
I x x x x
II x x x x x
III x x x x x
IV x x x x x
V x x x x x
Tabela 1: Tabela Referente ao Cronograma Proposto
Etapas:
I) Pesquisa bibliográfica: Estudo das tecnologias OPC e Foudation Fieldbus, assim
como a escolha da linguagem de programação.
II) Elaboração do projeto a ser desenvolvido,
III) Implementação do cliente OPC, e a interface do software.
IV) Implementação dos blocos de controle no software.
V) Testes de usabilidade e confiabilidade do software, utilizando a planta SMAR.
30
Capítulo 3: Técnicas Utilizadas
3.1: Tempo de Amostragem
O tempo necessário para o período de amostragem tornou-se um dos temas
mais cruciais no desenvolvimento do projeto. Muitos problemas relacionados á esse
tempo foram encontrados.
3.1.1: Leitura e Escrita de Dados
Em estudos preliminares sobre a utilização da tecnologia OPC, foram
realizados inúmeros testes. O tempo de escrita e leitura dos dados em uma planta
real foi um dos aspectos mais estudados. Para estes testes foi utilizada a planta
didática PDIII fabricada pela SMAR. Primeiramente foi testado o tempo necessário
para realizar a leitura desde um até vários dados, contidos no mesmo grupo OPC ou
não.
Os resultados mostraram que para esse processo não se utilizou mais que 1,5
segundos, não importando o número de dados lidos o tempo continuou quase que
constante para leitura de dados. (É claro que este tempo varia de sistema para
sistema. A planta didática PDIII utiliza uma rede Foundation Fieldbus que utiliza uma
velocidade de transmissão de dados no barramento (31.25KBps) similar aquela
utilizada pela maioria dos padrões de redes industriais com a característica de
segurança intrínseca. Considerando que outros sistemas apresentem uma
velocidade semelhante (Algumas sem segurança intrínsica podem ser até mais
rápidas), conclui-se que esses resultados são interessantes).
Já para o caso de escrita de dados em uma rede industrial foram realizados
dois tipos de escrita. O primeiro tipo testado foi à escrita síncrona, onde nesse caso
todo dado escrito aguarda o sinal de confirmação da inscrição do dado. Esse tipo de
escrita se tornou ineficiente, pois, em média para cada dado que se quer escrever,
um tempo extra é utilizado para essa transação. Observou-se uma diferença
insignificante com a aplicação da técnica de agrupar os itens escritos em um grupo.
Logo, como estamos tratando de controle avançado, sendo esse utilizado em
31
processos multivariáveis e na possibilidade de realizar mais de um processo de
controle ao mesmo tempo, esse tipo de escrita se tornou ineficaz. Então, a solução
para esse problema foi à realização de uma escrita assíncrona, sendo esta a forma
mais eficaz para a utilização nesse software. Pois ela consiste em apenas enviar os
valores para a atualização dos dados e não espera o retorno de confirmação para
liberação do programa. Porém para que esse método funcione conforme o esperado
deve-se ter um compromisso entre o numero de variáveis escritas e o tempo de
amostragem. Pois quanto maior o número de dados a serem escritos, maior deverá
ser o tempo de amostragem.
Foram realizados testes preliminares onde a cada iteração foi escrito o valor
da iteração em cada item num grupo de seis. Na figura 9 temos um caso onde o
período está muito justo e assim a confiabilidade de escrita é baixa.
Figura 9: Gráfico de Escritas Consecutivas com período de 1s
Podemos perceber que em vários momentos o valor se repetiu, mostrando
que não foi possível escrever dentro do período desejado. Já na figura 10, temos um
caso onde o período foi de 2,5s e assim conseguindo aumentar a confiabilidade de
escrita dos dados.
32
Figura 10: Gráfico de Escritas Consecutivas com período de 2,5s
Nesse caso houve menos perdas de dados na escrita devido à maior folga no
tempo de amostragem conseguindo assim uma maior confiabilidade na escrita dos
dados. Concluindo então a existência de uma relação entre a quantidade de dados
escritos e o tempo de amostragem mínimo possível.
Essa relação deve ser calculada antes da aplicação da técnica de controle,
pois escolhendo um tempo de amostragem errado, abaixo de um nível adequado de
confiabilidade, pode trazer conseqüências como, não conseguir escrever de uma
forma confiável e no tempo determinado os dados desejados e assim conseguir uma
eficiência de escrita baixa, podendo chegar a níveis críticos de 50% de escrita.
O método que possibilitou encontrar um período confiável mínimo foi à
utilização de um algoritmo onde a partir de um número de iterações, definido pelo
usuário ou por um valor padrão, mede-se os tempos necessários para a escrita de
dados. De posse de todos esses valores é feito um tratamento estatístico, onde se
aproximando de uma distribuição normal podemos encontrar um valor confiável
mínimo desejado. O nível de confiança é um valor padrão de 95%, porém o usuário
pode aumentar essa porcentagem, caso ele ache necessário.
33
Essa função deverá ocorrer obrigatoriamente antes da aplicação da estratégia
de controle utilizada pelo usuário, pois ela é a garantia da eficiência dos dados
escritos nos dispositivos desejados.
Vale notar que o problema principal está na escrita, pois se comparando com
a leitura de dados, a escrita se torna muito lenta. Sendo assim, garantindo um
período mínimo confiável estaremos também garantindo uma leitura de dados
confiável.
3.1.2: Tarefa Periódica
Com o problema de escrita e leitura resolvido, o foco sobre o período de
amostragem se voltou à confiabilidade na entrega dos dados no período correto.
Visto as inúmeras eventualidades que podem ocorrer durante as transmissões,
como o jitter e os diferentes tempos para o processamento dos cálculos, o tempo de
amostragem volta a ser um problema critico para o sistema.
Em sistemas de tempo real aplicados em controle, uma característica
fundamental necessária para um funcionamento adequado do sistema é o
determinismo. Isso implica que o sistema deve atender mensagens periódicas com a
maior eficiência possível, respeitando seus deadlines.
Quando as ativações do processamento de uma tarefa ocorrem, numa
seqüência infinita, uma só ativação por intervalo regular chamado de período, essa
tarefa é identificada como periódica. As ativações de uma tarefa periódica formam o
conjunto de diferentes instâncias da tarefa. Neste contexto, assumimos a primeira
ativação da tarefa periódica na origem dos tempos considerados na aplicação.
Com esses conceitos foi solucionado esse problema utilizando uma tarefa
periódica. Na primeira ativação dessa tarefa é definida sua origem dos tempos e a
partir de então, é feito a correção de qual o tempo necessário a tarefa deve “dormir”.
Essa correção é baseada no tempo gasto de processamento de dados com o tempo
em que a tarefa deve terminar. Com isso se garante uma entrega de dados num
período fixo de tempo, resolvendo os problemas de jitter e eventuais problemas que
34
possam ocorrer nessa entrega. Essa solução também evita a possibilidade de um
acúmulo de erro no tempo amostrado.
3.2: OLE x XML
Como a tecnologia OPC foi fundamentalmente baseada nas tecnologias
DCOM e COM da Microsoft, isso nos permite apenas a utilização do sistema em um
único sistema operacional. Porém, existindo essa limitação do uso dessa tecnologia,
foi desenvolvida a especificação OPC and XML (Versão 1.01). Esta especificação
nos abrange a utilização de OPC DA para outros sistemas operacionais, pois com a
tecnologia XML não seria mais necessário a utilização do uso do DCOM.
Levando em consideração esse aspecto, foram estudados também quais
outros fatores que poderiam impactar no desempenho do sistema utilizando uma ou
outra tecnologia.
Segundo Frank Iwatnitz e Jürgen Lange, foram feitas comparações sobre o
desempenho de leitura de dados utilizando duas diferentes tecnologias, uma a OLE
e a outra XML. Com as mesmas condições de processamento e velocidade de
propagação, em diferentes sistemas operacionais e com os mesmos tipos de leitura
chegou-se aos resultados mostrados na figura 11.
35
Figura 11: Resultados de Comparação entre OPC DCOM DA Server e OPC XML DA
Server
Portanto, avaliando as diferentes características das duas tecnologias e
considerando que o uso de DCOM possui mais bibliotecas e uma maior facilidade de
uso, esta tecnologia foi escolhida para o desenvolvimento do cliente OPC. Mesmo
essa tecnologia sendo limitada a utilização de apenas um sistema operacional, sua
escolha se dá principalmente pela sua larga vantagem em relação ao desempenho
de comunicação (Iwanitz & Lange, 2006).
3.3: Biblioteca OPC
Considerando os problemas e as soluções vistas acima, foi possível escolher
uma biblioteca que possa garantir as propriedades desejadas para a comunicação
entre o sistema e as possíveis redes industriais a serem conectados.
Dentre as três bibliotecas pré-selecionadas, a que mais atendeu os requisitos
desejáveis foi a JOpcClient, da NOVOTEK Plannig Systems, que apesar se ser
privada, possui a nova especificação de OPC DA 3.00 (Ole Process Control Data
Access). Logo, pode-se contar com a escrita assíncrona e um fácil acesso dos itens
de diferentes servidores OPC.
36
3.4: Blocos de Controle
Para a utilização inicial do software é desejado à utilização de pelo menos um
bloco de controle avançado. Porém, para efeitos de simplicidade, foi decidido utilizar
primeiramente um bloco de controle PID já integrado ao sistema, assim
possibilitando a validação do software no que se diz respeito à confiabilidade dos
dados trocados e a eficiência dos meios de comunicação, como também verificar a
coerência do tempo de amostragem mínimo analisando o sucesso de sua aplicação
e garantindo ao usuário a eficiência do produto.
O desenvolvimento do PID digital seguiu o principio de que para o usuário
somente necessita saber os parâmetros desejados para a sintonia do controlador, no
tempo contínuo, sem precisar realizar transformadas para o tempo discreto. Isso é
possível segundo aproximações realizadas nas equações do ganho proporcional,
tempo integrativo e derivativo. Essa aproximação é realizada através do método de
Euler:
�� ��� � ����� ���� , (Equação 1)
onde � seria o tempo de amostragem utilizado (Franklin, Powell, &
Workmam).
Já em relação ao bloco de controle avançado, se optou primeiramente pela
utilização do controle Preditivo Multivariável não Linear (Plucenio, Rico, Pagano, &
Bruciapaglia, 2007). Para esse método, foram realizados alguns ajustes para casos
de controle específicos e atualmente se encontra em fase de desenvolvimento para
torná-lo um algoritmo genérico e assim poder fazer o seu uso no software.
37
Capítulo 4: Atividades Desenvolvidas
4.1: Interface Gráfica
Para a realização da interface gráfica foi analisado o que se pretendia com o
software, buscando a facilidade de utilização e a clareza com as trocas de
informações com o usuário. Uma interface está sendo desenvolvida com base nas
melhores técnicas presentes nos inúmeros softwares utilizados hoje em dia, onde a
partir de uma tela inicial o usuário pode abrir um projeto já existente ou iniciar um
novo. Iniciando um novo projeto, o usuário poderá escolher os blocos de controle a
serem utilizados através de uma lista onde todos os possíveis blocos estarão
localizados, e após isso selecionar as entradas e saídas em que se deseja utilizar, e
assim inseri-las nos blocos desejados. Podendo então planejar uma estratégia de
controle e após isso rodar o projeto especificado.
Para ser possível selecionar as entradas e saídas do projeto, utilizou-se uma
árvore, na qual o cliente OPC fornece os tags de todos os servidores OPC visíveis
na máquina em que está instalado o software.
38
Figura 12: Interface Gráfica
Na figura 12, podemos observar a janela principal do software (Ainda não
concluído). Ela mostra um menu, que contém todas as opções disponíveis do
sistema como, salvar projeto, abrir projeto, ajuda, gerenciar janelas, opções de
execução do projeto, editar projeto, entre outras.
Pode-se observar também nessa figura duas janelas, uma sendo a janela
principal do projeto de controle e a outra a janela onde se localiza os blocos que
farão parte da estratégia escolhida pelo usuário.
A partir dessa escolha é que será feito a especificação do controle fornecendo
a este seus parâmetros, suas entradas e saídas.
4.2: Cliente OPC
No desenvolvimento do cliente OPC foi considerado que, além de fornecer a
comunicação entre o servidor OPC e o software, ele também deveria fornecer ao
usuário o acesso a todos os tags de todos os servidores OPC visíveis na máquina
onde esteja instalado o sistema.
39
Considerando este aspecto foi desenvolvida uma árvore onde nela estará
todos esses elementos e a partir de lá o usuário poderá escolher as que ele
necessita.
Figura 13: Visualização dos Servidores OPC
Na figura 13 podemos ver a lista de servidores OPC em que o usuário pode
se conectar.
40
Figura 14: Visualização dos itens OPC
Na figura 14, pode-se observar o acesso a todos os itens de um servidor OPC
especifico, tornando-se fácil a escolha das variáveis desejadas pelo usuário.
Para a leitura e escrita de dados foi especificado que o cliente OPC depois de
formar um ou mais grupos de leitura e um ou mais grupos de escrita (depende do
número de servidores em que está a malha de controle, cada servidor possui um
grupo de cada), faria a leitura dos dados de forma síncrona, pois assim, garante
100% da leitura e não traz perda no desempenho da malha já que seus tempos são
muito abaixo em relação ao da escrita. Já a escrita dos dados seria de forma
assíncrona, como já tinha sido visto anteriormente que seria a melhor escolha. Essa
escolha se justifica pelo fato de que para aplicações de controle avançado os
tempos de amostragens são maiores e eventuais perdas de informação são
toleráveis, claro que com um baixo nível de erro.
41
4.3: Tarefa Periódica
Visando a entrega dos dados em tempos fixos pré-determinados, o que seria
o tempo de amostragem mínimo fornecido pelo software ou o desejado pelo usuário
para a sua aplicação, foi implementado o método relacionado no item 3.1.2:
Foi desenvolvido na linguagem JAVA, onde ao inicializar a execução da
estratégia da malha de controle, dispara-se uma thread (Deitel & Deitel, 2005) que
realizará o controle propriamente dito. Essa thread inicializará definindo o inicio dos
tempos dela e a partir de então entrando num laço onde será efetuado a cada
período de tempo fixo.
Através da comparação do tempo atual com o tempo do início do próximo
laço, se obtém o tempo exato em que a thread deve esperar, garantindo assim a
troca de dados em tempos fixos. Porém, em casos que o tempo de processamento
de dados se torna maior que o período determinado, a garantia de tempo fixo não se
concretizará, porém ele não se tornará um erro cumulativo. Esse tempo de
processamento de dados depende de vários fatores como:
• Nível de utilização do processador;
• Capacidade da máquina utilizada;
• Tempo de leitura e escrita;
• Complexidade do calculo da malha de controle desejada;
Assim dessa forma, o tempo de amostragem se torna um item crucial para a
qualidade total do sistema, exigindo uma definição correta deste, considerando todos
esses fatores.
4.4: Definição do Período de Amostragem
Sendo esse um aspecto de extrema importância para o bom funcionamento
do sistema, com confiabilidade e eficiência. Para sua definição foram levados em
conta todos os possíveis problemas em que uma má escolha desse período pode
acarretar. Eficiência da leitura e escrita com a quantidade de Tags utilizados, tempo
necessário para o cálculo da ação de controle (nisso inclui a capacidade da
42
máquina), são aspectos levados em consideração para a determinação do período
de amostragem mínimo possível. Deve-se levar em consideração que se o nível de
utilização do processador estiver em níveis acima da utilização normal, pode
acarretar problemas no desempenho da malha, logo quando se utilizar esse sistema
se aconselha utilizar ao mínimo a capacidade da máquina.
Antes de executar a estratégia definida pelo usuário, este deve definir o
período de amostragem desejado. Para isto ele tem um valor mínimo possível
determinado pelo sistema.
A partir da verificação dos tempos de leitura e escrita de dados e o tempo do
calculo da ação de controle é feito um tratamento estatístico desses e então,
determinado um valor mínimo possível com certo nível de confiabilidade. Logo o
usuário sabe o valor mínimo que ele pode usar, garantindo assim o bom
funcionamento do sistema.
Utilizando como exemplo, foi feito testes com um grupo para leitura contendo
três itens. Esses três itens foram escritos iterativamente, conseguindo observar o
tempo necessário para sua efetuação. As figuras 15 e 16 representam os resultados
obtidos.
43
Figura 15: Histograma dos Tempos de Escrita com sua Distribuição Normal
Figura 16: Distribuição Normal
44
Na figura 15, a partir de um histograma obtido pelos tempos de escrita, é
obtida uma distribuição normal que representa esses tempos. Já na figura 16,
mostra o ponto em que representa a probabilidade de 98% de sucesso de escrita.
Esse ponto terá como padrão 95% de probabilidade, porém o usuário poderá
somente aumentá-lo, caso desejar. Nesse caso em especifico foi encontrado um
valor mínimo de tempo de amostragem de 2,119s.
Através da tabela de student, se consegue obter a faixa de probabilidade
desejada dentro da distribuição, e assim obter o valor mínimo de amostragem.
4.5: Algoritmos de Controle
Para o começo do software, a idéia foi implementar pelo menos um bloco de
controle avançado. A técnica de controle escolhida para ser a primeiro a ser
desenvolvida foi o Controle Preditivo Multivariável não Linear.
A partir do modelo desenvolvido pelo meu orientador, foi feito uma adaptação
ao um modelo multivariável especifico. Esse modelo é um sistema multivariável de
controle de temperatura e vazão com as entradas sendo uma vazão de água quente
e outra de água fria. Esse sistema se encontra na PDIII, da Smar, onde foi possível
ser feita todos os experimentos necessários.
A adaptação dessa técnica ao um modelo genérico, e assim poder ser
utilizada no software, será uma das próximas etapas conforme o cronograma
proposto.
Enquanto isso, foi implementado o controle PID digital, para que se possam
validar as características desejadas no software e assim poder validar sua utilização.
Considerando a equação diferencial de um PID (Franklin, Powell, &
Workmam):
�� � ���� � �
� � �����; (Equação 2)
45
E através método de Euler obtém como resultado (Franklin, Powell, &
Workmam):
���� � ��� � 1� � � ��1 � �
� � � ���� � �1 � 2 �
� ��� � 1� � � ��� � 2��; (Equação 3)
Com essa equação podemos relacionar os parâmetros em que o usuário esta
acostumado, que seriam os contínuos, com os do PID digital que de fato será
utilizado.
4.6: Lógica do Software
A parte em que se diz respeito a toda lógica do sistema, de como será
realizado as trocas de informação, realizado os cálculos necessários, a formalização
da estratégia definida pelo usuário, foi modelada conforme o diagrama de classes
UML da figura 8. Essa modelagem foi muito útil em relação à organização no
desenvolvimento do software, possibilitando uma implementação mais rápida,
eficiente e clara.
O software se baseia no conceito de threads, que serão disparadas conforme
o necessário, possibilitando realizar a aplicação de várias estratégias de controle ao
mesmo tempo, sem que elas interfiram entre sim. Com essa aplicação se consegue
garantir todos os conceitos vistos acima referentes ao período de amostragem,
tempo de leitura e escrita, tempo de processamento de dados.
O sistema todo é realizado com orientação a objetos, possibilitando assim
maior facilidade de incorporação de funções prontas, maior facilidade para
reutilização de código e por conseqüência do projeto.
46
Capítulo 5: Resultados
Seguindo o cronograma proposto, os resultados finais serão para o começo
do ano de 2009, sendo assim podendo apenas ser concluído alguns resultados
intermediários que são de extrema importância para a validação do projeto e assim
ser viável sua continuação.
5.1: Resultados da aplicação da tarefa periódica
Após a implementação da tarefa periódica, podemos observar que ela atingiu
as expectativas e as especificações do problema proposto. Nas figuras 17 e 18,
podemos verificar sua confiabilidade, sendo que na figura 17 não existe um uso
demasiado do processador e já na figura 18 foi realizada usando acima do normal a
capacidade do processador.
Figura 17: Tarefa Periódica em Condições Normais
47
Figura 18: Tarefa Periódica em Condições com Alto uso do Processador
Podemos verificar com esses dois gráficos que no primeiro o período começa
exatamente em períodos fixos, sem alteração durante o seu andamento. Já no
segundo caso observa-se que mesmo com um alto uso do processador obteve-se
um pequeno erro no começo de alguns períodos. Porém o erro não se tornou
cumulativo, pois os períodos fixos voltaram a começar aos instantes determinados
pelo inicio dos tempos.
5.2: Garantia dos Tempos de Escrita e Leitura
Com o uso da distribuição normal, e assim possibilitando um grau de
confiabilidade para o período mínimo a ser utilizado, possibilitou uma maior
segurança ao usuário para que ele possa definir o tempo de amostragem que ele
deseja, sabendo o mínimo possível que não acarretará problemas de comunicação.
Porém, para aplicações em que o software está destinado, que seriam a
utilização de controle avançado para sistemas multivariáveis, não necessitam em
grande parte dos casos, de um pequeno tempo de amostragem. Portanto o sistema
é robusto para estes casos onde se pode trabalhar com grandes períodos, na ordem
de dezenas de segundos a minutos.
48
Na figura 15, temos um exemplo de aplicação de controle utilizando a técnica
de tarefa periódica e com um grau de confiabilidade maior que 98% de escrita de
dados.
Figura 19: Controle de temperatura
Assim, podemos também verificar que com essa garantia de escrita
juntamente com a garantia de tempos fixos, se consegue corrigir o atraso na entrega
dos dados devido ao jitter existentes em redes industriais e locais.
5.3: Andamento do Software
Em relação ao software, ele está ainda em desenvolvimento. Estando agora
na etapa de integração da lógica com o cliente OPC e com a interface gráfica.
5.3.1: Interface
A interface está com sua estrutura principal pronta, possibilitando a criação de
novos projetos, abertura de projetos já implementados, escolha dos controles
desejados para a estratégia e a escolha das variáveis necessárias para a realização
deste.
49
5.3.2: Cliente OPC
O desenvolvimento do cliente OPC está na fase de integração com a lógica
do software, sendo já possível encontrar os servidores e todos os Tags relacionados
a estes.
A criação de grupos de leitura e escrita e a posterior escrita e leitura dos
dados selecionados na estratégia estão em fase de desenvolvimento, sendo em
breve já possível a sua utilização ao completo.
Outro desafio relacionado ao cliente OPC está na possibilidade de conexão
com servidores OPC em computadores remotos ligados em uma LAN. Isto ainda não
foi possível pelos vários problemas ocorridos na disponibilidade desses servidores
na rede. Esse assunto também está sendo estudado para poder ser também
acrescentado ao software.
5.3.3: Lógica do Software
A lógica do software se encontra praticamente pronta, faltando apenas a
interligação entre os setores de interface e comunicação com a rede. Possui as
classes de acordo com o modelo do diagrama UML e não acarreta grandes
preocupações futuras, pois pelos testes preliminares o seu funcionamento ocorreu
conforme o esperado.
5.4: Algoritmos de Controle
Os dois algoritmos obtiveram resultados satisfatórios. No caso do controle
Preditivo Multivariável não Linear, que foi aplicado na PDIII, foi obtido bons
resultados no seu desempenho, conforme a figura 15, mesmo tendo problemas com
os atuadores da planta.
Também foram realizados testes com outros tipos de controle como Controle
Preditivo DMC e Controle Preditivo não Linear com critério de Robustez por
Lyapunov (Plucenio, Pagano, Normey-Rico, Pavei, & Moya, 2008), todos
apresentando resultados convincentes em relação ao seu desempenho.
50
O Controle Preditivo não Linear com critério de Robustez por Lyapunov
(Plucenio, Pagano, Normey-Rico, Pavei, & Moya, 2008) foi tema de um artigo
desenvolvido junto com meus orientadores, realizado em paralelo com o
desenvolvimento do software, no qual foi aprovado recentemente no XVII CBA
(Congresso Brasileiro de Automática) que acontecerá no mês de setembro no
corrente ano.
51
Capítulo 6: Conclusões e Perspectivas
Apesar de o projeto estar em fase de implementação, alguns aspectos são
relevantes considerando a potencialidade que esse sistema pode trazer. Os
benefícios em relação à integração de sistemas como, redes industriais com
sistemas de controle avançado e ainda a possibilidade da escolha de qual estratégia
desejada para um problema especifico são enormes tanto em relação a custos,
complexidade de uso e capacidade de escolha dos tipos de controle a serem
utilizados. Também sendo muito útil academicamente, principalmente no estudo de
técnicas de controle avançado, em que o usuário tem toda a liberdade de projetar
seu controlador, alterar os parâmetros de período de amostragem e ter acesso à
aplicações reais fazendo a aproximação dos conhecimentos teóricos com a
utilização na pratica.
Outro aspecto importante nesse projeto foi verificar toda a potencialidade do
padrão OPC, tecnologia sendo utilizada em larga escala nas aplicações industriais.
A integração de sistemas com esse padrão torna-se esse custo muito baixo e com
uma boa confiabilidade da troca de informações, visto alguns detalhes de
implementação como os períodos necessários para isso.
Em relação aos tempos necessários para um bom desempenho da estratégia
de controle, os cuidados relacionados nesse documento são de grande importância,
pois a garantia de tempos fixos e entrega confiável dos dados são cruciais para uma
malha de controle. Assim pode-se concluir que sempre pode existir um caso onde
possa a vim atrapalhar esse desempenho, porém esses casos podem ser
diminuídos ao máximo, fazendo que o sistema possa ser muito robusto
principalmente no uso de controle avançado, onde os períodos de amostragem são
normalmente grandes.
Algumas perspectivas até o fim do cronograma são esperadas, como a
possibilidade do acesso remoto do cliente OPC à servidores OPC e o funcionamento
pleno do software com pelo menos um bloco de controle avançado.
52
Um objetivo desse projeto é deixar possível o incremento de blocos e o
melhoramento do software. Blocos de outros tipos de controle como Controle
Preditivo DMC, Preditor de Smith, entre outros, são esperados em desenvolvimentos
futuros por outros estagiários que venham a trabalhar nesse projeto.
Além dos blocos de controle, também se deseja ser incorporados ao projeto
blocos de identificação, blocos de controle adaptativo, filtros, etc.
53
Bibliografia:
[1 ] Deitel, H. M., & Deitel, P. J. (2005). JAVA como programar. Pearson
Prentice Hall.
[2 ] Farines, J.-M., Fraga, J. d., & Oliveira, R. S. Sistemas de Tempo Real.
[3 ] Franklin, G. F., Powell, J. D., & Workmam, M. L. Digital Control of Dynamic
Systems. Addison Wesley Longmam.
[4 ] Iwanitz, F., & Lange, J. (2006). OPC Fundamentals, Implementation and
Application. Hüthig Verlag Heidelberg.
[5 ] OPC Foudation. (s.d.). Fonte: OPC Foudation: www.opcfoudation.com
[6 ] OPC Foudation. (March 6, 2008). OPC Unified Architecture. Incorporates
feedback to date from IEC w.g.
[7 ] OPCTI. (s.d.). Fonte: OPC Training Institute: www.opcti.com
[8 ] Plucenio, A., Pagano, D. J., Normey-Rico, J. E., Pavei, J., & Moya, C. (2008).
Including Robustness in the MPC Cost Function. XVII Congresso Brasileiro
de Automática .
[9 ] Plucenio, A., Rico, J. E., Pagano, D. J., & Bruciapaglia, A. H. (2007).
Controle Preditivo Não Linear na indústria do petróleo e gás. IV PDPETRO -
4 Congresso Brasileiro de P&D em PETROLEO e GAS .
[10 ] Stemmer, M. R. (2001). Sistemas Distribuidos e Redes de Computadores
para Controle e Automação Industrial.