Thiago de Freitas Sa..

UNIVERSIDADE FEDERAL DE SANTA CATARINA
CURSO DE ENGENHARIA DE CONTROLE E AUTOMAÇÃO
Blue Ocean – Desenvolvimento de um
Sistema SCADA para Pipelines
Monografia submetida à Universidade Federal de Santa Catarina
como requisito para a aprovação da disciplina:
DAS 5511 Projeto de Fim de Curso
Thiago de Freitas Santos
Florianópolis, Março de 2007
Blue Ocean – Desenvolvimento de um Sistema SCADA para
Pipelines
Thiago de Freitas Santos
Esta monografia foi julgada no contexto da disciplina
DAS 5511: Projeto de Fim de Curso
e aprovada na sua forma final pelo
Curso de Engenharia de Controle e Automação
Banca Examinadora:
Fábio Dias Fagundez
Paulo Armando Rêgo
Orientadores da Empresa
Prof. Agustinho Plucênio
Orientador do Curso
Prof. Augusto Humberto Bruciapaglia
Responsável pela disciplina
Prof. Nestor Roqueiro, Avaliador
Guilherme Castro Royer, Debatedor
Marcelo de Saulnier Fuchs, Debatedor
Agradecimentos
Foram cinco anos excelentes, sobre todos os aspectos. Tenho muito a agradecer
a todos que me ensinaram, sobre vida e Engenharia, e me apoiaram para chegar até
aqui.
Primeiramente, agradeço à Deus, Senhor desse mundo, pela vida, saúde e paz.
Agradeço à minha família, minha inspiração, meu exemplo, pelo amor e apoio
incondicional. Sem minha mãe, meu pai e meu irmão, certamente não chegaria tão longe.
Não foi fácil suportar a distância, mas ela nos uniu e nos fortaleceu.
Agradeço à Marianna, meu amor, leitora e revisora oficial, pela motivação, ajuda e
carinho. Nossos planos tornam mais saborosas todas as conquistas, ainda teremos
muitas.
Ao Fábio, meu grande incentivador no projeto, pelo entusiasmo, orientação e
amizade. Ao Paulinho e toda a equipe de desenvolvedores da Chemtech: Ricardo, André,
Ramon, Loriato, Alexandre, Schirmer e Britto, pelo companheirismo, pela dedicação,
pelos ensinamentos.
Agradeço ao Agustinho, pela paciência, pelo comprometimento, pela ajuda. Aos
professores do DAS, que ensinaram, cobraram e formaram uma base sólida.
Aos amigos de faculdade, pela amizade verdadeira, pelos bons momentos, pela
parceria. Vocês serão sempre especiais para mim.
Agradeço ainda 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.
A Todos, muito obrigado!
Resumo
Sistemas SCADA (Supervisory Control And Data Acquisition) são de
fundamental importância para indústria nos mais diversos setores. Esses sistemas
concentram informações da planta, fornecendo status em tempo real de milhares de
equipamentos e instrumentos. Áreas de operação e manutenção lidam diariamente
com sistemas SCADA.
SCADA’s modernos têm expandido sua fronteira de atuação. Além de
exibirem o panorama atual de operação eles têm armazenado dados históricos e
distribuído informações através de interfaces padrão, como OPC. Eles têm também
permitido o acoplamento de sistemas externos voltados para o ramo de atuação da
indústria.
Pipelines são componentes essenciais na distribuição de óleo e gás em todo
o mundo. Sistemas SCADA são fundamentais no controle e manutenção dos dutos,
estações de bombeamento e compressão e nas unidades de medição. Os SCADA’s
aplicados à pipelines possuem peculiaridades, principalmente devido à separação
espacial dos equipamentos e a existência de sistemas externos, como os sistemas
de controle de materiais transportados, detecção de vazamento e medição de
órgãos de fiscalização.
Esse trabalho propõe-se a mostrar as fases iniciais de desenvolvimento de
um sistema SCADA moderno para pipelines, em um projeto chamado Blue Ocean,
desenvolvido pela empresa Chemtech. O projeto Blue Ocean foi contratado pela
Siemens, que visava, inicialmente, empregar o SCADA desenvolvido em pipelines
de um cliente da África do Sul.
O SCADA desenvolvido será empregado em pipelines novos e também
substituirá sistemas já implantados. Será apresentada a arquitetura, a plataforma de
desenvolvimento e as primeiras etapas de construção desse novo sistema, com
ênfase na atuação do autor.
ii
Abstract
SCADA (Supervisory Control And Data Acquisition) Systems are of great
importance for industry in all areas. These systems concentrate information of the
plant, providing real time status of thousand of equipments and instruments.
Operation and maintenance staff deal daily with SCADA systems.
Modern SCADAs have expanded its applicability. Beyond showing the current
state of operation process, these systems have stored historical data and distributed
information through standard interfaces, such as OPC. They have also allowed the
coupling of external systems.
Pipelines are the main way to transport oil and gas in the world. SCADA
Systems are essential for controlling and maintenance of ducts, pumping and
compressing stations, and in the units of measurement. SCADAs employed in
pipelines has peculiarities, mainly due to space distribution of the equipment and the
presence of external systems, such as batch tracking systems, leak detection and
regulatory measurements.
This document intents to show the initial phases of development of a modern
SCADA system for pipelines, in a project called Blue Ocean, which were developed
by Chemtech company. Blue Ocean project was contracted by Siemens, who aimed
to use the SCADA in pipelines of a customer in South Africa.
The
built SCADA will be employed in brand new pipelines and also in
operational ones. This document will present the architecture, platform and the first
stages of development of this new system. It will be emphasized the tasks performed
by the author.
iii
Sumário
Agradecimentos................................................................................................. i
Resumo ............................................................................................................ ii
Abstract ........................................................................................................... iii
Sumário ........................................................................................................... iv
Simbologia...................................................................................................... vii
Capítulo 1: Introdução ......................................................................................1
1.1: A Empresa .............................................................................................1
1.2: SCADA...................................................................................................3
1.3: Pipelines ................................................................................................4
1.3.1: Histórico ..........................................................................................5
1.3.2: Organizacional.................................................................................6
1.3.3: SCADA para pipelines.....................................................................7
1.4: Projeto Blue Ocean................................................................................9
1.4.1: SiSchedX.......................................................................................11
1.4.2: Contexto de Engenharia de Controle e Automação .....................11
1.5: Estrutura do Documento ......................................................................13
Capítulo 2: Estrutura do Sistema SCADA ......................................................14
2.1: Arquitetura ...........................................................................................14
2.1.1: Requisitos do sistema ...................................................................14
2.1.2: Atores do sistema SCADA ............................................................15
2.1.3: Modelos de arquitetura e subsistemas..........................................18
2.2: Plataforma de Desenvolvimento ..........................................................21
2.2.1: Linguagem de programação - JAVA .............................................21
iv
2.2.2: Plataforma Eclipse RCP ................................................................21
2.2.3: J-Integra para COM.......................................................................24
2.2.4: JGo................................................................................................25
2.2.5: Gerenciador de Scripts BeanShell ................................................25
2.2.6: Open Splice DDS middleware .......................................................26
2.2.7: MySQL ..........................................................................................26
2.3: Cronograma .........................................................................................27
2.3.1: Fase Zero ......................................................................................27
2.3.2: Fase de Elaboração ......................................................................28
Capítulo 3: Atividades Desenvolvidas ............................................................30
3.1: Preparação – Treinamentos ................................................................30
3.1.1: Curso de PCS7 .............................................................................30
3.1.2: Curso de P&ID ..............................................................................30
3.1.3: Curso de Java ...............................................................................31
3.1.4: Seminários em Eclipse RCP .........................................................32
3.2: Conhecer o sistema SCADA atualmente implantado ..........................32
3.2.1: LSX................................................................................................32
3.2.2: CS7 ...............................................................................................35
3.3: Análise de mercado .............................................................................36
3.4: Bancada de testes para a Prova de Conceito......................................37
3.4.1: Experimento do desafio de controle ..............................................37
3.4.2: Configuração de um servidor OPC................................................39
3.4.3: Estrutura completa da bancada de testes.....................................39
3.5: Elaboração do Plano de testes ............................................................41
3.5.1: Testes de comunicação ................................................................41
3.5.2: MySQL ..........................................................................................45
v
3.5.3: Interface Gráfica............................................................................47
3.5.4: Modularidade.................................................................................49
3.5.5: Portabilidade .................................................................................49
3.6: Testes ..................................................................................................50
3.7: Apresentação.......................................................................................51
3.8: Ferramenta de Configuração de Engenharia.......................................52
3.8.1: Importância....................................................................................52
3.8.2: Estrutura do Aplicativo...................................................................53
3.8.3: Detalhamento do Aplicativo...........................................................54
3.9: Testes para Finalização da versão ......................................................57
3.10: Revisão da arquitetura .......................................................................57
3.11: Definição da bancada final de testes .................................................58
3.11.1: CLP S7-400.................................................................................58
3.11.2: Módulo TIM .................................................................................58
3.11.3: Arranjo dos equipamentos ..........................................................59
3.12: Detalhamento da bancada.................................................................61
3.13: Reformulação do Plano de testes......................................................61
3.14: Teste versão para apresentação .......................................................63
Capítulo 4: Conclusões e Perspectivas ..........................................................64
Bibliografia:.....................................................................................................65
vi
Simbologia
AOPL - Association of Oil Pipe Line
CLP – Controlador Lógico Programável
COM – Component Object Model
DCOM – Distributed Component Object Model
DCS - Distributed Control System
ISA - Instrument Society of America
ODBC – Open Database Connectivity
OLE – Object Linking and Embedding
OPC – OLE for Process Control
OPC AE - Alarm and Event
OPC DA - Data Access
OPC DX - Data Exchange
OPC HDA - OPC Historical Data Access
P&ID - Piping and Instrumentation Diagram
QoS – Quality of Service
RTRDB – Real-time Relational Database
RTU – Remote Telemetry (or Terminal) Unit
SCADA - Supervisory Control And Data Acquisition
vii
Capítulo 1: Introdução
1.1: A Empresa
A Chemtech foi criada em 1989 por três engenheiros químicos recémformados do Instituto Militar de Engenharia (IME) do Rio de Janeiro. Inicialmente, os
projetos eram voltados para sistemas na área de processos, sendo o maior cliente,
na época, o centro de Pesquisas da Petrobras (CENPES).
Os primeiros projetos, como o simulador de processos Petrox - ainda hoje
utilizado na Petrobras, tiveram grande sucesso e abriram caminho para outros
trabalhos.
A qualidade dos produtos gerados e a gestão dos projetos permitiram que a
Chemtech conquistasse gradativamente seu mercado, crescendo e expandindo sua
carteira de clientes.
O reconhecimento dos clientes, o padrão mundial de qualidade e a linha de
soluções da Chemtech foram fatores decisivos de sua escolha pela Siemens, em
2001, para ser a responsável pela área de Tecnologia de Informação para plantas
de processo nos países do Mercosul e México. Desde então, a Chemtech, aliada a
uma das mais respeitadas corporações mundiais de engenharia, cresceu
consideravelmente.
O mercado de Óleo e Gás é, e sempre foi, o maior cliente da Chemtech,
dividido entre empresas representativas como Petrobras, Exxon Mobil, Chevron e
Shell. Os trabalhos nessa área permitiram a atuação em projetos em diversos
países do mundo: Alemanha, Estados Unidos, Rússia, Japão, Cingapura, Tailândia,
Arábia Saudita, França, África do Sul, Canadá e Espanha.
Gradualmente, a Chemtech abriu as portas para as mais diversas áreas de
atuação, como representado na Figura 1. Seus clientes se distribuem nos seguintes
mercados: Software, Água e Energia Elétrica, Metais e Mineração, Papel e Celulose,
Petróleo e Gás, Petroquímica e Química.
1
Figura 1 - Áreas de atuação Chemtech
Dezoito anos depois de sua criação, a Chemtech tornou-se uma empresa
líder de mercado, ocupando um nicho específico e aliando diversas áreas de
engenharia, sempre combinando conhecimento de processo ao domínio das mais
modernas soluções em Tecnologia da Informação.
Como parte da Siemens, a Chemtech oferece basicamente três grandes
grupos de soluções:
Conceituar e projetar
No projeto conceitual e na engenharia básica é feito um uso intensivo da
simulação de processos e da fluidodinâmica computacional. O objetivo é chegar aos
melhores arranjos e dimensões de equipamentos e às melhores condições
operacionais para os processos de transformação e agregação de valor que
ocorrem nas indústrias.
Negócios e processos
Fluxo de informação entre o chão de fábrica e o nível corporativo do cliente.
Inclui desde os serviço de automação industrial até a integração com os sistemas
ERP, envolvendo a implantação dos sistemas de informação e de sistemas LIMS e
MES. O objetivo é desenvolver a integração entre as diversas áreas da empresa a
fim de maximizar seu desempenho como um todo.
2
Operação e produção
Otimização do processo e da produção. Inclui a sintonia de malhas de
controle, o controle avançado do processo, a otimização e o planejamento e a
programação avançada de produção. O objetivo é elaborar e executar estratégias
para o melhor aproveitamento das oportunidades da empresa em relação aos
recursos e às restrições existentes.
1.2: SCADA
Um sistema SCADA (Supervisory Control And Data Acquisition) é formado
por terminais remotos que coletam dados de campo e transmitem esses dados a
uma estação principal através de um sistema de comunicação. A estação principal
exibe os dados adquiridos e também permite que o operador execute tarefas de
controle remoto [ 1 ].
De forma simplificada, SCADA é um sistema que troca sinais codificados
através de canais de comunicação com o intuito de prover controle sobre os
equipamentos das Unidades Terminais Remotas (RTU) [ 6 ].
Sistemas SCADA surgiram da necessidade de um frontend (interface) para
sistemas de controle com CLP’s (Controladores Lógicos Programáveis). Os CLP’s,
embora executem tarefas de medição e controle, não disponibilizam uma interface
para monitoramento e atuação dos operadores.
Os sistemas SCADA podem adquirir dados dos CLP’s através de diversos
métodos e protocolos de comunicação. Eles, então, agrupam e formatam a
informação de maneira adequada para a interpretação do usuário.
A partir da década de 90,
o papel dos sistemas incorporou maiores
funcionalidades automáticas, como a conexão a bancos de dados para o
fornecimento de gráficos em tempo-real, as informações de diagnóstico e logística,
os procedimentos agendados de manutenção, os esquemas detalhados para
máquinas e equipamentos, entre outros.
Em questão de poucos anos, a maioria dos fabricantes de CLP’s já ofereciam
sistemas SCADA integrados, muitos desses já com protocolos de comunicação
abertos e não-proprietários.
3
Os três componentes principais de um sistema SCADA são:
Unidades Terminais Remotas (RTU’s): Majoritariamente, são os CLP’s
distribuídos no nível de campo. Conectam-se aos equipamentos, lêem informações
de status como o sinal aberto/fechado de uma válvula e realizam medições como
pressão, fluxo, tensão e corrente. Tais equipamentos também podem ser
controlados através do envio de sinais com comandos, tais como abrir/fechar ou
definir o set point de uma bomba hidráulica;
Estação Servidora e MMI’s: As Estações Servidoras são responsáveis
pela comunicação com os equipamentos de campo (RTU’s, CLP’s). MMI’s (Man
Machine Interface) são os elementos de visualização (clientes) das informações
geradas pela Estação Servidora. As MMI’s também permitem aos usuários o envio
de comandos a Estação Servidora, as quais os repassam aos equipamentos de
controle em campo.
Infra-estrutura
de
Comunicação:
Sistemas
SCADA
utilizam,
tradicionalmente, combinações de rádio e conexões diretas seriais ou por modem,
para realizarem a troca de dados. No entanto, a partir do ano 2000, ampliou-se o
uso de Ethernet (IEEE 802.3) e IP sobre SONET (GR-253-CORE), especialmente
em grandes plantas com grande número de pontos, como geradoras de energia.
Padrões como IEC 60870-5-101 ou 104, Profibus e DNP3 - atualmente com
extensões para TCP/IP, são reconhecidos pela maioria dos fabricantes de sistemas
SCADA.
1.3: Pipelines1
Pipelines (dutos) são usados predominante no transporte de petróleo e gás
entre as unidades produtoras, de tratamento e distribuidoras em todo o mundo. A
1
O conjunto de dutos e demais componentes que viabilizam o transporte de óleo e gás
recebe a denominação pipeline na língua inglesa. No português é feita a diferenciação entre gasoduto
e oleoduto conforme o transporte seja de gás ou óleo. Para maior simplicidade utiliza-se neste
documento o termo pipeline para referir-se a um duto que transporte óleo ou gás.
4
sua aplicação é a forma mais rápida, confiável e de baixo custo para o transporte de
óleo e gás.
Mais do que isso, os pipelines representam a única forma viável de atender a
enorme demanda global. Por exemplo, para substituir um oleoduto de pequena
dimensão que transporta 150 mil barris de petróleo por dia, é necessário carregar e
descarregar 750 caminhões. Em escala mundial, são consumidos diariamente cerca
de 80 milhões de barris de petróleo.
Figura 2 - Etapas de produção do petróleo
Além de eficiente, o transporte por pipelines também é seguro. Em 1998,
uma pesquisa comparou a tecnologia com outras formas de transporte e apontou
que apenas 0,027 x10 −3 % dos acidentes fatais nos Estados Unidos foram causados
pelo sistema .
1.3.1: Histórico
Os primeiros pipelines construídos no mundo eram feitos de madeira ou ferro
e atendiam predominantemente o transporte de gás natural na Europa e nos
Estados Unidos. Após a Segunda Guerra Mundial, o desenvolvimento da metalurgia,
das tecnologias de soldagem e de enrolamento de dutos provocou um grande
crescimento da utilização deste sistema de transporte. Em 1998, havia mais de 857
mil quilômetros de pipelines voltados unicamente para o transporte de gás natural
em todo o mundo.
No Brasil, o bombeamento de petróleo por pipelines começou em 1940. Nos
anos 60, foi construído o primeiro oleoduto de longa distância brasileiro, ligando
5
Terminal da Guanabara (TORGUÁ) e a Refinaria Duque de Caxias (REDUC), no Rio
de Janeiro.
Atualmente, a Transpetro (Petrobras Transportes S.A.), maior transportadora
brasileira, é responsável por 10 mil quilômetros de rede dutoviária, transportando
petróleo e derivados, gás natural e álcool. Em 2005, a carga transportada pela
Transpetro registrou 640 milhões de metros cúbicos.
1.3.2: Organizacional
Os sistemas de pipelines são formados por três unidades básicas: os próprios
dutos, as estações de bombeamento ou compressão e as estações de medição.
Essas unidades se encaixam em uma estrutura organizacional que pode ser
subdividida em Suporte Corporativo, Manutenção, Operação e Suporte ao
Consumidor, [ 2 ]. Detalhes dessa divisão são mostrados na Figura 3.
O sistema de automação implantado nos pipelines integra e agiliza a
execução da maioria das funções da estrutura organizacional. Manutenção e
Operação são diretamente impactadas e as outras esferas sofrem influência
indireta, mas também significativa. O grau de automação dos pipelines é item
determinante em sua performance e competitividade no mercado.
6
Figura 3 - Distribuição organizacional de um pipeline
1.3.3: SCADA para pipelines
O centro de operações de qualquer pipeline, chamado Centro de Controle,
monitora e controla os dutos, bombas, estações de compressão e unidades de
medição. O sistema que usualmente realiza essa operação de controle e
monitoramento é um sistema SCADA.
7
A tecnologia usada nos sistemas computacionais e de telecomunicações
determinam a funcionalidade, escopo e capacidade dos sistemas SCADA utilizados
em pipelines.
Figura 4- Exemplo de tela de um sistema SCADA para pipelines
Além das funções de monitoramento e controle, os sistemas SCADA
concentram dados de outros sistemas de informação nas aplicações para pipelines.
Alguns softwares usualmente associados aos sistemas SCADAS, têm as seguintes
funções [ 2 ]:
•
Simulação de pipelines;
•
Gerenciamento de tanques;
•
Detecção de vazamentos;
•
Monitoramento de carregamentos (batch tracking);
•
Totalização de vazão;
•
Cobrança e rateio de taxas (billing);
•
Geração de relatórios para clientes.
8
Atualmente, é possível apontar diversas melhorias e retrofits para os pipelines
instalados em todo o mundo. Muitos sistemas são complexos para operar sem
automação. Outros sistemas exigem mais recursos de automação com a ampliação
da linha. Em alguns casos, a transição de sistema de operação manual para outro
automático exige atualização completa desde a unidade de controle até o SCADA.
As modificações nas unidades locais de produção e nos sistemas SCADA,
com o intuito de torná-los mais automatizados, normalmente têm três objetivos
principais: custo, confiabilidade e eficiência.
1.4: Projeto Blue Ocean
O projeto Blue Ocean visa desenvolver um sistema SCADA voltado para o
mercado de pipelines.
O projeto foi contratado pela Siemens AG (Alemanha) para atender,
inicialmente, a maior transportadora de Petróleo da África do Sul, que tem seus
pipelines controlados por CLP'
s e SCADA da empresa alemã.
No entanto, o sistema supervisório instalado pela Siemens, chamado LSX, se
encontra ultrapassado, não atendendo a todas as necessidades da empresa. A falta
de flexibilidade e custo de configuração do sistema atual exigiram que a operadora
de pipelines pedisse ao seu fornecedor (Siemens) uma solução mais moderna e
adequada aos padrões internacionais de monitoramento e controle.
A Siemens dispunha no mercado de outros produtos que poderiam atender o
cliente. Em particular, uma suíte de aplicações para SCADA e DCS (Distributed
Control System) para plantas de processo.
Entretanto, uma análise mais detalhada mostrou que a simples substituição
do sistema SCADA, como ocorria em outras indústrias, era uma solução mais cara e
menos eficiente que a construção de um sistema totalmente novo e voltado para
essa área especificamente.
Geralmente tal solução não é empregada na indústria, a qual prefere utilizar
softwares convencionais configurados para suas aplicações. Contudo, os pipelines
apresentam uma série de peculiaridades que fazem com que a adaptação de
produtos convencionais seja bastante difícil e por vezes não atenda completamente
as necessidades do sistema.
9
As principais características limitantes do pipeline até então instalado são:
•
O SCADA (LSX) opera em um sistema operacional UNIX (Solaris) e o
cliente não gostaria de migrar para outro sistema operacional, tal como
Windows;
•
As telas do sistema supervisório atual e sua estrutura de banco de
dados dificilmente seriam adaptadas a um SCADA comercial;
•
O hardware atualmente usado no pipeline limita consideravelmente a
troca de dados a longa distância. Um protocolo especificamente
desenvolvido para a aplicação sul-africana contorna essa limitação.
Entretanto, esse protocolo não é suportado por nenhum outro SCADA;
•
O procedimento de configuração do sistema SCADA demanda muito
tempo e é feito apenas por engenheiros da Siemens na Alemanha.
Nesse contexto, a Chemtech pertencente ao grupo Siemens e já atuante em
outros projetos de sucesso - se mostrou como a empresa ideal para esse novo
desenvolvimento.
Apesar de inicialmente estruturado como solução para o pipeline do cliente
sul-africano, o SCADA desenvolvido no projeto Blue Ocean tem um objetivo maior.
O SCADA deve ser uma solução ampla voltada para o mercado, não apenas para o
cliente inicial. Mais do que atender às necessidades do sistema da África do Sul, ele
deve se basear em padrões modernos e largamente aceitos, atendendo os
requisitos críticos dos sistemas de pipelines.
Durante a fase de planejamento e análise, os pontos de enfoque do novo
sistema foram enumerados:
•
Integridade dos dados;
•
Redundância e disponibilidade do sistema;
•
Redução dos custos de configuração e engenharia;
•
Facilidade de operação;
•
Escalabilidade;
•
Uso de modernas técnicas de software;
•
Redução dos custos de operação dos pipelines;
10
•
Prover mecanismo de integração com aplicações externas e típicas do
mercado de pipelines;
•
Prover integração com sistemas e dispositivos legados;
•
Modularidade;
•
Segurança;
•
Portabilidade;
1.4.1: SiSchedX
Mesmo fazendo parte do grupo Siemens, a conquista do projeto Blue Ocean
é fruto da qualidade de trabalhos anteriores realizados pela Chemtech. O
reconhecimento da capacidade da empresa deu-se, principalmente, pela confiança
adquirida em um outro projeto, liderado pela mesma equipe que assumiu o
desenvolvimento do Blue Ocean. Esse outro projeto gerou o produto SiSchedX da
Siemens.
SischedX (Siemens Scheduling eXpert) é um produto para planejamento e
programação de produção em refinarias de petróleo. Ele permite que a programação
diária da produção em uma refinaria seja feita com auxílio de simulação e análise de
cenários. Assim, ele oferece um desenho de toda a planta e acessa sistemas ERP,
LIMS, PIMS ou quaisquer outros com informações relevantes. Utilizando dados
reais, simula diferentes seqüências de produção.
Atualmente, o SischedX é utilizado com sucesso numa das maiores refinarias
brasileiras, a REPLAN. O conhecimento adquirido com esse projeto relaciona-se
diretamente com os principais objetivos do Blue Ocean.
1.4.2: Contexto de Engenharia de Controle e Automação
O projeto de um sistema SCADA é um projeto de automação. O SCADA
desempenha papel fundamental na automação industrial, ele reúne as informações
de chão de fábrica e permite o controle sobre toda a planta.
Um grande conjunto de disciplinas vistas durante o curso são abordadas no
desenvolvimento de um sistema SCADA, dentre elas: Informática Industrial, Redes
de Computadores para Automação, Sistemas de Banco de Dados, Sistemas
11
Distribuídos, Instrumentação, Integração de Sistemas Corporativos e Metodologia
para Desenvolvimento de sistemas.
Primeiramente, é necessário conhecimento de redes industriais, uma vez que
serão desenvolvidos protocolos para comunicação com os CLP’s. Fazem parte do
escopo do projeto, a adequação tanto a protocolos padrões da indústria, como IEC
60870-5-101, DNP3 e ModBus, quanto a um protocolo específico para o sistema de
pipelines da África do Sul, o Siemens EDC (Event Driven Communication).
Dentro do âmbito da disciplina de Integração de Sistemas Corporativos, o
SCADA deverá prover servidor e cliente OPC, aderindo, novamente, aos padrões
industriais de automação.
A programação do sistema SCADA será feita em linguagem orientada a
objetos, Java, utilizando-se técnicas de modelagem.
O banco de dados relacional tem enorme importância em um sistema SCADA
e no projeto Blue Ocean, especificamente. O banco de dados existente no pipeline
deverá ser incorporado, o acesso a ele será feito utilizando-se interface
JDBC/ODBC.
A instrumentação de campo e estações SCADA são distribuídas pelos vários
quilômetros de um pipeline. É fundamental conhecer a forma de comunicação e
atuação dos instrumentos de campo e a integração entre as instâncias do SCADA
nesse projeto, da mesma forma que a estrutura de armazenamento de dados do
CLP e a sua forma de comunicação são importantes para o desenvolvimento de um
SCADA eficiente. Desta forma, os conhecimentos adquiridos em informática
industrial são imprescindíveis.
Por fim, a integração entre várias tecnologias e disciplinas é um ambiente
onde o Engenheiro de Controle e Automação sente-se confortável e pode
desempenhar sua função da melhor forma.
12
1.5: Estrutura do Documento
Este documento visa mostrar as etapas de desenvolvimento do projeto Blue
Ocean, enfatizando as minhas atividades em seu contexto. A organização dos
capítulos foi feita de seguinte forma:
•
Capítulo 2 - Será dada uma visão geral do projeto, apresentando a
arquitetura proposta, a metodologia de desenvolvimento e o cronograma de
atividades.
•
Capítulo 3 - Serão detalhadas as etapas do projeto em que tive uma
participação
efetiva.
Os
resultados
de
cada
etapa
são
mostrados
paralelamente.
•
Capítulo 4 – As conclusões e resultados são o foco desse capítulo.
13
Capítulo 2: Estrutura do Sistema SCADA
2.1: Arquitetura
2.1.1: Requisitos do sistema
O sistema tem como objetivo se adequar a pipelines em diferentes etapas de
desenvolvimento. Dessa forma, três distintos tipos de projetos de pipelines foram
considerados:
• Green field – Um novo pipeline está sendo instalado e tanto os
instrumentos de campo quanto o software são projetados para trabalhar em
conjunto;
• Retrofit Total – Infra-estrutura, instrumentos de campo e o sistema SCADA
é modernizado em um pipeline já em funcionamento;
• Retrofit do SCADA – Apenas o sistema SCADA em funcionamento é
modernizado.
O sistema SCADA deve, assim, ter uma base sólida que o torne um produto
aplicável nas três situações listadas, além de ser um produto competitivo
comercialmente, reunindo todas as características que um moderno SCADA deve
possuir. Os elementos centrais buscados para a arquitetura do projeto Blue Ocean
são:
•
Adequação a protocolos padrões (OPC e ODBC, por exemplo);
•
Confiabilidade;
•
Independência de sistema operacional;
•
Troca
de
componentes
durante
a
execução
sem
desempenho;
•
Integração com sistemas de banco de dados em tempo real;
•
Escalabilidade da interface do usuário;
•
Configuração de perfis de usuário;
•
Permissões específicas para cada perfil de usuário;
•
Cerne do sistema acessível através de múltiplas interfaces;
14
perda
de
•
Ferramentas de configuração (também denominadas “ferramentas de
engenharia”) rápidas e fáceis de manusear;
•
Mecanismo flexível para integração dos sistemas e dispositivos
legados.
2.1.2: Atores do sistema SCADA
O ponto de partida para a construção do software foi o levantamento dos
atores que deverão interagir com o sistema SCADA. Atores são usuários e/ou outros
meios externos que desenvolvem algum papel em relação ao sistema. Os meios
externos são hardwares e/ou softwares que, assim como os usuários, geram
informações para o sistema ou necessitam de informações geradas a partir do
sistema.
Os possíveis atores para o Blue Ocean são:
•
Operadores dos pipelines;
•
Engenheiros de configuração;
•
Gerentes de produção;
•
Softwares externos (geram e consome informações do SCADA).
A seguir, é feito um detalhamento do comportamento de cada ator perante o
sistema.
Operadores de pipelines
Os
operadores
de
pipelines
são
os
responsáveis
por
verificar
o
funcionamento da planta. Eles geralmente atuam monitorando as variáveis de
processo ou guiando as máquinas em caso de quebra ou erro na lógica que as
comanda.
Os operadores estão interessados em valores de variáveis restritos a um
curto espaço de tempo, geralmente o próprio turno em que ele está operando, uma
vez que sua função é garantir o funcionamento correto da planta, com máxima
produtividade e risco mínimo.
15
Assim, o SCADA deve prover informações em tempo real (dados de processo
e alarmes), além de uma forma de disponibilizar histórico recente, procurar itens e
alterar valores de variáveis.
Os interesses dos operadores podem ser resumidos em:
•
Visualizar dados em tempo real e obter com facilidade (de preferência
com um único clique) o histórico recente daquele dado se possível na forma de um
gráfico;
•
Controlar o sistema de múltiplas estações, e possivelmente de estações
remotas;
•
Modificar, comparar e procurar por itens e valores de forma rápida e fácil;
•
Exportar dados em diferentes formatos, para confecção de relatórios de
operação.
Engenheiros
Os engenheiros configuram a aplicação com o intuito de adequá-la ao
processo e eles também desenvolvem conectores que permitem ao sistema SCADA
comunicar com outras aplicações como sistemas legados e aplicações de pipelines.
Engenheiros normalmente estão interessados em:
•
Facilidade de extensão e customização;
•
Criação de uma aplicação adequada ao processo;
•
Facilidade de integração com outros sistemas e dispositivos;
•
Escrita de aplicação baseada em plataforma moderna e difundida;
•
Suporte remoto ao sistema através de redes públicas;
•
Minimização do esforço de configuração através do reuso de aplicação e
componentes de software;
Gerentes
16
Em geral, os gerentes de produção são usuários de aplicações adjacentes ao
SCADA, mas não do cerne do sistema.
Os gerentes devem ter acesso a relatórios e gráficos informando estado e
operação do pipeline. Os relatórios devem destacar os eventos mais relevantes
como acionamento de alarmes de prioridade alta, paradas na produção, índices de
produtividade.
Possivelmente, os gerentes desejarão ter acesso ao sistema a partir de
diferentes localidades através da rede mundial de computadores (World Wide Web).
Outros Sistemas
Tradicionalmente, sistemas SCADA estão completamente isolados de
informações gerenciais e sistemas de decisão. Entretanto, ao passo que novas
tecnologias de integração surgem, alguns dados adquiridos dos sistemas SCADA
precisam ser disponibilizados para sistemas em um patamar superior. Essas
informações permitem a tomada de decisões estratégicas em relação à operação e
utilização dos pipelines.
O mercado de pipelines tem sofrido alterações dramáticas e nos dias atuais
os operadores devem ser capazes de planejar e reagir em curtos horizontes de
tempo. Esse fator, em adição com o crescente nível de complexidade das
operações, tem transformado informações anteriormente operacionais (leitura dos
medidores, resultados do SCADA) em informações chave para os negócios.
A Tabela 1 apresenta os sistemas comumente integrados ao sistema SCADA
para pipelines e sua classificação por prioridade desde 1 (menor prioridade) a 5
(maior prioridade).
Observe que as aplicações classificadas como 5 são extremamente
recomendadas para serem incluídas na base de um sistema SCADA, de forma que
esse se torne um produto comercialmente viável.
Também é importante ressaltar que essas prioridades variam de segmento a
segmento; para pipelines maiores e mais complexos as prioridades podem ser
diferentes. A Tabela 1 apenas indica as prioridades de forma geral.
17
Tabela 1 - Sistemas externos ao SCADA
Otimização do pipeline
1
Requisições para entrega de carregamento
2
(para gases seria alterada para 4)
Previsões e modelagem (Estudo hidráulicos off-line,
3
provisão de carregamento, modelos preditivos)
Simuladores para treinamento de operadores
2
Detecção de vazamentos
4
Sistemas de informação geográfica
3
Gerenciamento de ativos e contabilidade
3
Relatórios: consumidores, internos e de regulação
5
Monitoramento de Pig / Batelada
5
2.1.3: Modelos de arquitetura e subsistemas
O SCADA proposto está dividido em 5 módulos principais:
•
Módulo de configuração e engenharia (EC)
•
Modulo de gerenciamento de dados e eventos (DEM)
•
Módulo de comunicação de campo (FC)
•
Interface homem-máquina (MMI)
•
API para aplicações externas (API)
Os módulos acima listados foram projetados para possuir baixo nível de
dependência, o que permite a criação de dois diferentes versões de servidores
SCADA: uma versão com todas as ferramentas, denominada de SCADA Server e
uma versão compacta denominada SCADA de campo.
•
Servidor SCADA
18
Esta constitui a versão global do servidor SCADA, executando todas as
funções de supervisão e gerenciamento providas pelos módulos EC, DEM, FC e
MMI. Ela provê ainda uma API bem definida para conexão de aplicações
relacionadas ao pipeline.
Versão que suporta os clientes empregados por engenheiros e operadores e
que serve a todos os atores do sistema SCADA.
•
SCADA de Campo
Esta versão compacta do SCADA contém apenas os módulos DEM e FC e,
consequentemente, suportam apenas as funcionalidades relacionadas a esses. Ele
pode ser usado somente por arquivos de configuração e para permitir a
disponibilidade de informações em toda a rede de pipeline.
Como conseqüência de tal aproximação modular, algumas vantagens podem
ser listadas:
•
Estações servidoras e de campo podem ser facilmente trocadas, sempre
observando a adição e redução de funcionalidades em cada unidade;
•
Estações servidoras e de campo podem compor ou deixar a topologia sem
quebrar a redundância de dados através da rede;
•
Consumidores podem escolher quantas licenças de cada tipo de servidor eles
desejam e adquiri-los de forma a compor sua topologia SCADA.
Uma configuração típica teria um Servidor SCADA na estação principal,
Servidor SCADA de backup nas estações de backup e algumas instâncias do
SCADA de campo na rede de pipeline, no caso dessa rede ser muito grande ou
complexa.
A Figura 5 apresenta um esquemático dos referidos servidores e os módulos
que os compõem.
19
Figura 5 - Visão geral da arquitetura
20
2.2: Plataforma de Desenvolvimento
Com a finalidade de preencher todos os requisitos expostos anteriormente,
tais como: alta confiabilidade, acesso a dados em tempo real, facilidade de
integração como aplicações externas, modularidade, compatibilidade com diferentes
sistemas operacionais, aparência e usabilidade semelhantes às do Windows, 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.
Existe ainda diversas bibliotecas livres, amplamente difundidas e confiáveis
disponíveis nessa linguagem.
Outro motivo, não menos importante, é que a equipe da Chemtech estava
habituada com desenvolvimento em Java.
2.2.2: Plataforma Eclipse RCP
Eclipse é uma comunidade de código aberto cujos projetos focam-se na
construção de uma plataforma aberta de desenvolvimento. Essa plataforma permite
a construção, implementação e gerenciamento de software durante seu ciclo de vida
[ 4 ].
A mais conhecida e utilizada funcionalidade do Eclipse é o kit de
desenvolvimento de software (SDK) que reúne tanto o ambiente integrado de
desenvolvimento (IDE) para Java, quanto uma ferramenta para implementação de
produtos baseados na Plataforma Eclipse.
21
O kit de desenvolvimento de software do Eclipse (SDK) combina várias
frentes de desenvolvimento do projeto Eclipse: Plataforma, Ferramenta de
desenvolvimento Java (JDT) e o ambiente de Desenvolvimento de Plug-ins (PDE).
A plataforma Eclipse contém todas as funcionalidades necessárias para a
construção de uma IDE. No entanto, a plataforma Eclipse nada mais é do que um
conjunto de componentes. Assim, é possível usar um subconjunto dos componentes
Eclipse para construir aplicações.
Eclipse Rich Client Platform (RCP) é um subconjunto dos componentes da
biblioteca Eclipse que podem ser facilmente aproveitadas para a implementação de
outras aplicações.
A Figura 6 representa alguns componentes que formam a plataforma Eclipse
e ressalta os principais componentes que formam o Eclipse RCP.
Figura 6 - Componentes Eclipse RCP
O uso de Eclipse RCP tem se consagrado por construir aplicações diversas,
especialmente aquelas que operam em conjunto com aplicações servidoras, banco
de dados e outras fontes de dados. Aplicações para bancos, indústria de
22
automóveis, medicina já foram desenvolvidas utilizando-se as ferramentas dessa
plataforma.
Um grande diferencial do RCP é que ele está de acordo com padrão OSGi
(Open Services Gateway initiative), permitindo o desenvolvimento de sistemas
altamente modulares e desacoplados.
Os programas construídos sobre essa plataforma aumentam a usabilidade do
código, facilitam a manutenção, atualização e adição de novos componentes e plugins. Um exemplo de interface de usuário da Plataforma Eclipse pode ser visto na
Figura 7.
Figura 7 - Interface de usuário da Plataforma Eclipse
Todas essas características são a razão da escolha de Eclipse RCP como a
plataforma de desenvolvimento do SCADA no Projeto Blue Ocean.
23
2.2.3: J-Integra para COM
OPC (OLE for Process Control) é uma base tecnológica para integração entre
os componentes de automação , hardwares de controle e dispositivos de campo
[ 3 ].
OPC permite ainda a integração de produtos do MS Office e sistemas de
informação da indústria, como ERP (Enterprise Resource Planning) e MES
(Manufacturing Execution Systems).
O padrão OPC surgiu de uma iniciativa dos próprios fabricantes de
componentes para automação, com o suporte da Microsoft, detentora do protocolo
OLE-DB.
No ano de 1995, grandes companhias de automação, Fisher-Rosemount,
Intellution, Intuitive Technology, Opto22, Rockwell e Siemens AG, formaram uma
força tarefa em busca de uma forma padronizada para acessar dados em tempo
real no sistema operacional Windows.
Assim, no ano seguinte, nasceu a especificação do OPC versão 1.0 e, no
mesmo ano, a OPC Foundation foi estabelecida. Desde então, a lista de
especificações para diferentes aplicações usando OPC tem crescido. Atualmente,
as especificações OPC (já estabelecidas ou em construção) estão organizadas
como representado na Figura 8. Cada especificação destina-se a uma área
específica de aplicação.
A tecnologia OPC é baseada na distribuição de dados utilizando a interface
DCOM (Distributed Component Object Model) do Windows NT. Contudo, uma
interface acoplada ao sistema operacional é limitante para o desenvolvimento de um
sistema SCADA portável para várias arquiteturas.
J-Integra é um pacote de software que faz a ponte entre Java puro e COM.
Isso permite que as funcionalidades de OPC sejam disponibilizadas para qualquer
sistema operacional.
Utilizando-se o J-Integra o sistema SCADA poderá facilmente atuar como um
cliente OPC. Além disso, é possível construir servidor OPC para aplicações
externas.
24
Figura 8 - Especificações disponíveis para OPC
2.2.4: JGo
JGo é um componente Java utilizado para construir gráficos. Os gráficos
construídos são formados por nós e conexões interligando esses nós.
Essa ferramenta suporta vários formatos de imagem e é bastante flexível.
Sua utilização é de grande importância para a elaboração de telas no sistema de
SCADA.
2.2.5: Gerenciador de Scripts Bean Shell
Bean Shell é uma ferramenta que permite ao usuário escrever e executar
scripts Java em tempo de execução.
A utilização desse tipo de script permite a construção de sinóticos em um
sistema SCADA. O comportamento dinâmico dos objetos pode ser configurado
através dessa ferramenta de forma fácil e flexível.
25
2.2.6: Open Splice DDS middleware
DDS
(Data Distribution Service) é um middleware que permite o
particionamento de uma rede com diferente níveis de qualidade do serviço (QoS) e
transmissão confiável sobre o protocolo UDP.
A aplicação que implementa o middleware é desenvolvida pela Open Splice e
compilada para cada sistema operacional.
O módulo DDS é responsável pelas seguintes funcionalidades ao sistema
SCADA:
•
Mecanismo de sincronização em tempo-real;
•
Mecanismo de redundância local;
•
Mecanismo de redundância remoto;
•
Classificação do status dos dados coletados: válidos, inválidos e
antigos;
•
Camada de produção de dados;
•
Camada de Consumo de dados.
2.2.7: MySQL
MySQL foi escolhido como sistema de Banco de Dados Relacional a ser
empregado no SCADA do projeto Blue Ocean. MySQL é um sistema de código
aberto amplamente difundido no mercado. Para a aceitação desse sistema de
banco de dados foram feitos os seguintes testes:
•
Conectividade JDBC (Java Database Connectivity);
•
Redundância / Hot standby;
•
Triggers;
•
Gerenciamento de tabelas;.
•
Replicação de dados auto-adaptativa usando configuração mestre-escravo.
26
Todos os testes realizados foram aprovados. A principal funcionalidade que
levou
à
utilização
desse
software
foi
a
capacidade
de
replicar
dados
automaticamente entre instâncias do banco de dados. Para isso, os servidores são
configurados como mestres e escravos entre si. No caso de parada de um dos
servidores, o sistema se adapta automaticamente e mantém a replicação de dados
entre as instâncias ativas.
2.3: Cronograma
As atividades do projeto Blue Ocean foram divididas em fases. Cada uma
dessas fases contendo uma ou mais iterações. A Tabela 2 mostra as fases e
iterações desde a fase de Concepção até a fase de Transição do sistema SCADA
nos pipelines na África do Sul.
Tabela 2 - Fases e iterações projeto Blue Ocean
0
Fase
Concepção
1
Elaboração
2
3
Construção
Transição
Iteração
1
2
3
4
5
6
7
8
9
10
…
As fases são finalizadas com uma apresentação do que foi desenvolvido e
uma avaliação do cliente.
2.3.1: Fase Zero
A fase de Concepção foi finalizada em junho de 2006 e seu produto principal
foi o documento de arquitetura do novo SCADA, cujas características já foram
apresentadas anteriormente.
27
Nessa fase inicial também foram escolhidos componentes da plataforma de
desenvolvimento como DDS, Eclipse RCP, J-Integra e JGo.
A arquitetura proposta teve grande aceitação por parte do cliente e permitiu o
início imediato da fase de Elaboração, a qual será o foco principal desse
documento.
2.3.2: Fase de Elaboração
A fase de Elaboração possui dois objetivos principais:
Levantar informações detalhadas do sistema de pipelines implantado
na África do Sul;
Preparar uma Prova de Conceito.
O levantamento de informações do pipeline sul-africano será de fundamental
importância para a adequação do projeto e para o plano de migração a ser
desenvolvido.
A Prova de Conceito tem como objetivo mostrar que a arquitetura proposta é
viável e que o desenvolvimento atende aos critérios exigidos. Para tanto, uma
apresentação reunindo todas as frentes de desenvolvimento será cuidadosamente
preparada e um ambiente de testes construído. A Prova de Conceito dará
segurança aos clientes para financiar a continuidade do projeto.
As atividades desenvolvidas durante o Projeto de Fim de Curso tomaram
parte nas duas iterações da fase de elaboração. Essas atividades estão organizadas
na Figura 9.
28
Figura 9 - Cronograma da Fase de Elaboração
A equipe com participação na fase de Elaboração está representada na Tabela 3.
Tabela 3 - Equipe do projeto Blue Ocean durante a Fase de Elaboração
Gerente de Projeto
Chemtech
1
Líder de Projeto
Engenheiro de Software
Engenheiro eletrônico
Designer de Interface
Engenheiro de Automação
Engenheiro Químico
Infra-estrutura – TI
Consultores Software
Consultor de Automação
Consultor em projetos
Consultor pipeline
Consultor SCADA
Chemtech
Chemtech
Chemtech
Chemtech
Chemtech
Chemtech
Chemtech
Chemtech
Chemtech
Siemens Corporate Research
BCT Consulting (CAN)
Black Bird Consulting (CAN)
1
3
2
1
2
1
2
3
1
3
1
1
29
Capítulo 3: Atividades Desenvolvidas
3.1: Preparação – Treinamentos
Durante o Projeto Blue Ocean, vários cursos de qualificação foram
oferecidos. Essas atividades foram ministradas tanto por empregados da Chemtech
quanto por empresas especializadas.
3.1.1: Curso de PCS7
PCS7 é uma suíte de aplicações para a automação da indústria de
processos. Esse sistema amplamente utilizado em todo o mundo foi cotado pela
Siemens como uma solução para os projetos da África do Sul. O curso realizado na
Chemtech teve o objetivo de mostrar as formas de programação de CLP,
semelhante à empregada em nosso cliente, e ambientar a equipe com um SCADA
comercial de sucesso.
3.1.2: Curso de P&ID
P&ID (Piping and Instrumentation Diagram) é uma forma padrão de
documentação na indústria de processos. Nesses diagramas são representadas as
diversas etapas do processo de produção, assim como a instrumentação e
estratégias de controle, exemplo na Figura 10. A documentação detalhada dos
pipelines da África do Sul, em sua maioria, foi feita utilizando-se P&ID’s.
No curso, foram apresentadas as regras normalizadas de representar os
sinais de campo, estratégias de controle, dados a serem apresentados no
supervisório, tags dos instrumentos e equipamentos de campo e tipos de diagramas
existentes.
O material do curso foi compilado e foi preparado um seminário interno para
os integrantes do projeto Blue Ocean. A equipe de desenvolvedores decidiu, após o
seminário, usar a norma ISA (Instrument Society of America) para a nomenclatura
das variáveis internas do sistema SCADA.
30
Figura 10 - Exemplo de P&ID
3.1.3: Curso de Java
O curso de Java foi ministrado para um grupo de desenvolvedores da
Chemtech, especialmente àqueles provenientes da engenharia sem uma base
sólida em programação utilizando essa linguagem de alto nível.
Nesse curso, foram apresentados conceitos básicos como orientação a
objetos em Java, mas também tópicos mais avançados, tais como: acesso a banco
de dados via ODBC e JDBC, e ferramentas de desenvolvimento web, como Struts e
JSP.
31
3.1.4: Seminários em Eclipse RCP
Eclipse RCP é uma plataforma de recente desenvolvimento e rápida
evolução. Todo o grupo do projeto Blue Ocean participou de seminários web sobre
essa
plataforma,
onde
foram
apresentadas
e
discutidas
suas
principais
funcionalidades, formas adequadas de desenvolvimento e exemplos de utilização.
A participação nesses seminários tinha a finalidade de aprimorar a utilização
da plataforma, extraindo o máximo de seu potencial. Dessa maneira, o
desenvolvimento do SCADA seria mais rápido e geraria um produto mais modular e
robusto.
3.2: Conhecer o sistema SCADA atualmente implantado
3.2.1: LSX
O SCADA implantado nos pipelines da África do Sul é o LSX da Siemens.
LSX é um sistema SCADA de propósito geral, que roda sobre Solaris, sistema
operacional UNIX da Sun Microsystems.
Esse sistema SCADA apresenta uma série de funcionalidades para garantir
aos operadores o monitoramento e controle dos processos:
-
Visualização da planta: os estados do processo podem ser mostrados através
de telas totalmente gráficas.
-
Visualização de curvas: podem ser mostradas curvas em tempo real ou
carregadas de arquivos.
-
Relatórios on-line: Para pegar informações acerca de um objeto desejado e
para monitorar esse objeto.
-
Canais de mensagem: mensagens de objetos do processo são mostradas em
uma tela específica de mensagem. O sistema de canais pode ser conectado
diretamente a uma impressora.
-
Analisadores de mensagem: são usados para procura de mensagens
arquivadas.
LSX é caracterizado por suas três unidades principais: computador principal,
computador de banco de dados e computador de operação. Essas unidades se
32
comunicam e trocam dados com os sistemas subordinados, tipicamente CLP’s
Siemens da linha S5 e S7, como mostrado na Figura 11.
Dependendo do tamanho ou da estrutura do sistema, o computador principal
pode ser instalado uma ou muitas vezes. Ele constitui o kernel do sistema com as
funcionalidades conhecidas de um sistema SCADA para controle de processos.
Entre o computador principal e os CLP’s são trocados dados de valores medidos,
contadores, sinais, comandos e set points.
Figura 11 - Distribuição de componentes LSX
A estrutura de dados do LSX tem sua parametrização definida nos
computadores de operação. Todas as variáveis de campo com seu endereçamento,
variáveis de engenharia, protocolos de comunicação são definidas nessa unidade.
O computador de banco de dados com banco de dados da Oracle, armazena
a estrutura parametrizada no computador de operação. Além disso, essa unidade
realiza o arquivamento de longo prazo dos dados coletados.
Os dados parametrizados aparecem, geralmente, na forma de típicos. Típicos
são formados por um conjunto de objetos com a finalidade de
representar um
objeto complexo como um todo. A estrutura de típico permite que válvulas, motores,
bombas, dentre outros equipamentos, sejam caracterizados de uma forma mais
intuitiva.
33
Durante a criação do típico, são definidas os relacionamentos entre as
variáveis lidas do CLP até sua representação no sistema supervisório, isso é melhor
ilustrado pela Figura 12.
Figura 12 - Elementos de um típico
Apenas por uma simples referência a um objeto típico é possível mapear
todas as variáveis associadas a ele. Isso reduz consideravelmente o tempo de
configuração do sistema SCADA e organiza de forma mais intuitiva os dados.
34
A configuração do LSX para as aplicações da África do Sul foi realizada por
engenheiros da Siemens que estudaram pontualmente o problema. Uma solução
totalmente customizada foi desenvolvida desde o CLP até o sistema supervisório.
A customização envolveu alguns pontos principais:
•
Criação de blocos típicos para os modelos de equipamentos existentes
no pipelines e configuração destes tanto nos CLP’s quanto nas telas
do supervisório;
•
Construção de sinóticos atendendo as prioridades dos clientes;
•
Criação de um protocolo específico, baseado em eventos, para
contornar o problema de pouca banda.
O sistema construído se mostrou robusto e confiável em seus anos de
utilização. Contudo, a configuração de novos pontos e a manutenção do sistema era
bastante onerosa, tanto por questões financeiras, já que os engenheiros da Siemens
deveriam ser novamente contratados, quanto por questões de tempo.
3.2.2: CS7
Para melhor estudar e entender as funcionalidades do LSX decidiu-se instalar
o software e testá-lo. Como não havia uma estação Solaris a disposição optou-se
por instalar o CS7, a versão do LSX para Windows.
A instalação do CS7 envolve a configuração de um servidor que torna o LSX
portável para Windows. O servidor adotado pela Siemens foi o Exceed da
Hummingbird.
A instalação do CS7 envolve vários passos e sua instalação foi feita com
auxílio de uma equipe da Siemens Alemanha. Além da utilização do Exceed, um
banco de dados da Oracle e outros softwares externos foram instalados.
Ao final da instalação e configuração do CS7, foi possível recuperar as
tabelas e relacionamentos do banco de dados configurado no Oracle. A
identificação da estrutura de armazenamento será de fundamental importância para
o plano de migração da estrutura existente.
35
3.3: Análise de mercado
Avaliar os sistemas SCADA disponíveis no mercado é quesito fundamental no
desenvolvimento de uma nova solução. Assim, foi preparada uma planilha para
avaliação de sistemas SCADA modernos.
O objetivo de tal planilha é auxiliar no levantamento de funcionalidades mais
comuns e documentar tendências dos sistemas SCADA. Os principais pontos a
serem observados são mostrados na Tabela 4.
Tabela 4 - Planilha para avaliação dos sistemas SCADA
Dispositivos de comunicação
Banco de dados relacional
Edição de projetos
Configuração de gráficos
Configuração de Alarmes
Protocolos disponíveis
Definição do protocolo para cada CLP
Identificação da definição de tags para cada CLP
Forma de renomear as tags definidas para uso interno no sistema
SCADA
Redundância
Editor SQL para buscar dados históricos de processo
Armazenamento de queries e triggers
Importar e Exportar dados
Desfazer/Refazer
Recortar/Copiar/Colar
Importar telas de supervisório e modelos CAD
Biblioteca de objetos gráficos
Associação de objetos a tags
Nível de configuração dos objetos gráficos
Conexão entre os objetos
Associar alarmes e eventos aos objetos
Alteração de propriedades dos objetos
Importar imagens
Adicionar objetos a biblioteca gráfica
Agrupar e desagrupar objetos
Derivação de propriedades dos objetos aos objetos filhos
Zoom
Grid
Rotação e inversão da posição
Habilitar/Desabilitar/Definir muitas layers
Executar projeto
Associar tags aos gráficos
Propriedades editáveis dos gráficos
Definir limites
Adicionar marcação de tempo aos gráficos
Exportar gráficos gerados
Opção para PID
Tipos de alarmes
Forma de definir limites para variáveis
Adição de eventos
36
Associação de dinâmica aos objetos do sinótico
Compilador para scripts gerados
Associação de valores de tags/médias e indicações de tempo
Relatórios
Configurar Impressão
Salvar periodicamente de forma automática
Inspecionar/Alterar valores de tags
Mostrar gráficos em tempo de execução
Sinóticos em tempo de execução Mostrar e reconhecer alarmes
Propriedades editáveis
Links automáticos para outras telas
Customização
3.4: Bancada de testes para a Prova de Conceito
A Prova de Conceito, como apresentado na Seção 2.3.2:,tem por objetivo
mostrar que a arquitetura definida no Projeto Blue Ocean consegue atender os
principais requisitos a que ela se propôs. A principal parte da validação da
arquitetura proposta consistia da apresentação de casos de teste cobrindo as
principais áreas de desenvolvimento.
A construção de uma bancada de testes adequada era fundamental para a
execução satisfatória dos testes na Prova de Conceito. A bancada deveria prover
mecanismos para testar os protocolos desenvolvidos, as interfaces de comunicação,
o mecanismo de edição de telas, a estrutura de banco de dados, o middleware de
comunicação, a portabilidade e modularidade do sistema.
3.4.1: Experimento do desafio de controle
A Chemtech promoveu no ano de 2006 um evento para as universidades de
Controle e Automação do estado do Rio de Janeiro, o Desafio de Controle. Nesse
episódio, os representantes de cada universidade deveriam sintonizar seis malhas
de controle PID utilizando um software específico.
O esquemático do experimento do Desafio de Controle é mostrado na Figura
13. O experimento é formado por um aquário de acrílico com duas entradas de ar
quente, setas na parte inferior, e uma saída de ar frio, seta na parte superior.
Existem dois ventiladores na parte inferior que circulam o calor gerado por
resistências elétricas. Na parte superior, uma abertura permite a saída do ar. Foram
37
colocados seis termopares dentro do aquário e outro registrando a temperatura
ambiente.
O objetivo do Desafio de Controle era controlar individualmente as
temperaturas TT001 a TT006 (TT007 é a temperatura ambiente) através da
alteração das potência fornecida em TY002 e TY001.
As malhas de controle de TT001, TT003 e TT006 tinham como variável
manipulada TY001. Já as malhas de controle de TT002, TT004 e TT005 tinham
como variável manipulada TY002.
Figura 13 - Esquemático do experimento do Desafio de Controle
O controle do experimento realizado é feito por um CLP S7-300 da Siemens.
Nele existem dois cartões analógicos, um de entrada e outro de saída, um cartão de
comunicação Ethernet (CP-343-1), uma CPU e uma fonte de alimentação.
38
3.4.2: Configuração de um servidor OPC
Aproveitando a estrutura existente para o Desafio de Controle, planejou-se
conectar um servidor OPC ao CLP de forma que o experimento pudesse ser
monitorado e controlado remotamente durante a Prova de Conceito do Projeto Blue
Ocean.
Foi feito o mapeamento das variáveis de interesse no CLP. Os set points das
seis malhas de controle de temperatura, a leitura dos seis termopares, a potência de
saída da resistência e uma variável que permitia habilitar e desabilitar o controle
sobre as duas resistências foram selecionadas. Não havia interesse em alterar os
parâmetros do controlador, apenas observar a resposta do sistema para diferentes
set points de temperatura.
Escolheu-se o OPC Server da Softing, que possui suporte para comunicação
com CLP da Siemens. Assim, uma versão do OPC Server foi instalado em um
computador e esse foi conectado diretamente ao CLP através de seu cartão
Ethernet (CP-343-1) utilizando um cabo cross-over.
Em seguida, foi escrito um arquivo de configuração determinando quais
variáveis correspondiam a cada posição de memória de interesse no CLP. Dessa
forma, o software Softing conseguiu localizar cada um dos pontos de interesse e
disponibilizá-la em um servidor OPC.
De forma a certificar a correta publicação do servidor utilizou-se o cliente
OPC da Matrikon para ler e escrever (quando possível) valores no CLP. O resultado
foi positivo, foi possível alterar os set points e observar a variação das variáveis de
processo.
A primeira parte da bancada de testes estava terminada. Era possível
conectar-se a um cliente OPC e alterar a dinâmica do processo controlado por um
CLP.
3.4.3: Estrutura completa da bancada de testes
Partindo do experimento do Desafio de Controle, foi montada a bancada de
testes completa para a Prova de Conceitos, representada na Figura 14. A
montagem da bancada teve como base o levantamento das necessidades das
39
várias frentes de desenvolvimento: Comunicação (OPC, Drivers e DDS), Banco de
Dados, Interface gráfica e Distribuição de Dados via DDS.
Figura 14 - Configuração da bancada de testes para a Prova de Conceito
Foram usados quatro computadores na bancada de testes. A função de cada
um desses na Prova de Conceito é mostrada a seguir:
SCADA Local – Comunica-se com o CLP e distribui os dados para duas
outras redes, tanto via DDS quanto via OPC.
SCADA #1 – Recebe dados via DDS e OPC. Armazena os dados lidos em
uma instância do banco de dados MySQL. Possui também um servidor de dados
que simula o protocolo IEC 60870-5-101.
SCADA #2 – Recebe dados via DDS e OPC. Armazena os dados lidos em
uma instância do banco de dados MySQL. Possui um driver de comunicação IEC
60870-5-101, que lê os dados gerados pelo simulador configurado no SCADA #1.
SCADA #3 – Sistema operacional Linux. Recebe dados via OPC. Armazena
os dados lidos em uma instância do banco de dados MySQL. Possui um driver de
40
comunicação IEC 60870-5-101, que lê os dados gerados pelo simulador configurado
no SCADA #1.
As instâncias Local, #1 e #2 do SCADA estão conectadas a duas redes
através de duas interfaces de rede. Essa duplicidade permitirá o teste de
chaveamento entre conexões durante a distribuição de dados.
Apenas um dos Servidores OPC (Softing) do Local SCADA e o Servidor IEC
do SCADA #1 não foram desenvolvidos pela Chemtech durante a Prova de
Conceito.
3.5: Elaboração do Plano de testes
Conjuntamente com a definição da bancada foram arquitetados os testes a
serem realizados na Prova de Conceito. O plano de testes foi concebido com base
no status de desenvolvimento de cada uma das frentes. Esse status foi cruzado com
a prioridade de desenvolvimento para a Prova de Conceito, gerando, ao final, um
esboço do teste a ser realizado.
Os esboços dos testes, juntamente com o objetivo de cada um deles serão
mostrados a seguir.
3.5.1: Testes de comunicação
3.5.1.1: Cliente OPC
As funcionalidades do cliente OPC-DA serão disponibilizados através da
interface do usuário. O cliente OPC permitirá que o usuário visualize todas as tags
disponíveis no CLP. Será possível organizar essas tags em grupos arbitrariamente.
O cliente OPC-DA será usado para ler e escrever dados de e para o CLP
seguindo uma freqüência arbitrária. O cliente OPC-DA é um plug-in do software Blue
Ocean e irá comunicar com o servidor OPC-DA do SCADA Local.
Os clientes OPC serão executados no SCADA #1 e no SCADA #3 (Linux).
Objetivos do teste: adequação ao padrão OPC, portabilidade e modularidade
do software.
41
3.5.1.2: Servidor OPC
O servidor OPC transmitirá dados do CLP para clientes OPC em todas as
instância do SCADA na rede local.
No SCADA Local está instalado o Servidor OPC da Softing. O Cliente OPC
desenvolvido no projeto Blue Ocean lerá os dados provenientes do Servidor OPC da
Softing e a interface de usuário proverá uma maneira de organizar esses dados em
um servidor OPC confeccionado para o Blue Ocean.
Embora ainda não haja um servidor OPC desenvolvido para Linux, um teste
simples com um servidor COM nesse sistema operacional será mostrado. Uma
aplicação Windows lerá os dados disponibilizados via COM no Linux. Esse é o ponto
de partida para a construção de um servidor OPC.
Objetivos do teste: adequação ao padrão OPC e portabilidade.
3.5.1.3: Conectividade Excel - OPC
De forma a exemplificar a utilização de uma aplicação externa, o Excel será
usado para acessar dados do servidor OPC do Blue Ocean.
O programa desenvolvido em Excel permitirá a leitura de valores de tags, os
dados coletados serão mostrados em células e atualizados automaticamente.
Objetivos do teste: usabilidade e conectividade com aplicativos externos.
3.5.1.4: Driver IEC 60870-5-104
O servidor IEC gerará tags e dados que serão transmitidos através do
protocolo IEC 60870-5-104 para os clientes da rede local. A aplicação cliente será
adicionada como plug-in e fará parte da interface de usuário.
As instâncias #3 e #4 do SCADA lerão dados gerados na instância #1. Um
log dos comandos trocados pelo protocolo de comunicação será mostrado durante a
aquisição dos dados.
Objetivos do teste: adequação ao protocolo IEC 60870-5-104, portabilidade e
modularidade.
42
3.5.1.5: Middleware DDS
Os dados adquiridos do CLP pelo SCADA Local serão transmitidos às demais
instâncias dos SCADA tanto via Servidor OPC quanto via o middleware DDS.
A licença disponível para o software DDS permite apenas a comunicação
usando computadores com sistema operacional Windows. Assim, apenas o SCADA
Local e as instâncias #1 e #2 serão capazes de trocar dados.
Uma série de testes específicos foram preparados para mostrar a capacidade
do DDS. Todos esses testes serão facilmente executados uma vez que foram
criados plug-ins específicos para isso
3.5.1.5.1: Largura de banda utilizada
Os pipelines da África do Sul possuem grande limitação quanto a banda
disponível para a troca de dados. O middleware de comunicação deverá, portanto,
garantir a entrega dos pacotes em tempo satisfatório, sem ultrapassar os limites
físicos da instalação dos pipelines.
Para mostrar que a ocupação da rede está dentro da faixa esperada,
levantou-se o número de pontos em uma estação de grande tráfego. Assim, durante
o teste, será simulada a transmissão do volume de dados calculado pelos canais
DDS.
A largura de banda utilizada será, então, medida utilizando um indicador de
desempenho do próprio, Perfmon. O resultado será comparado com os valores
esperados para o pipeline.
Objetivo do teste: Desempenho da rede.
3.5.1.5.2: Uso do CPU
Paralelamente à medição da largura de banda, será executada também
medição do uso do CPU pelos componentes do DDS. Os componentes do DDS não
podem ultrapassar 80% da utilização total.
Objetivo do teste: Desempenho de processamento.
43
3.5.1.5.3: Distribuição de dados
Um plug-in RCP foi criado para mostrar a distribuição de dados sobre o
middleware DDS. Esse plug-in permite tanto a configuração de um publicador
quanto de um consumidor de dados.
Os dados adquiridos do CLP no SCADA Local serão transmitidos em
broadcast para todas as estações remotas partindo-se do SCADA Local. Os clientes
no SCADA #1 e #2 serão atualizados automaticamente com os dados coletados do
CLP.
Objetivo do teste: distribuição de dados sobre DDS.
3.5.1.5.4: Heartbeat
Uma aplicação também será criada para exibir todos os nós ativos em uma
rede local. Tal funcionalidade é alcançada pelo mecanismo de heartbeat
implementado no middleware DDS. Todos os nós mandam em tempos definidos
uma mensagem informando que estão ativos (heartbeat), o que permite que todos
sejam mapeados na rede.
Objetivo do teste: facilidade para a configuração de redes.
3.5.1.5.5: Disponibilidade
O middleware DDS tem a capacidade de rotear dados em tempo real através
de um canal redundante em caso de falha do meio de comunicação principal.
Usando a bancada de testes para a Prova de Conceito foi proposto um cenário em
que a instância SCADA #2 recebe dados simultaneamente do SCADA Local e do
SCADA #1, conforme representado na Figura 15.
A troca de dados será feita, inicialmente, através da Rede 1. A seguir, o hub
correspondente
à
Rede
1
será
desconectado,
e
os
dados devem
automaticamente roteados através da Rede 2.
Objetivo do teste: redundância, estabilidade, disponibilidade.
44
ser
Figura 15 - DDS e comunicação redundante
3.5.2: MySQL
3.5.2.1: Replicação de dados
As funcionalidades do servidor MySQL também serão disponibilizadas
através de interface com o usuário. Será possível armazenar no banco valores de
tags com suas respectivas marcações de tempo. Esses dados armazenados
poderão ser recuperados em qualquer momento e visualizados em gráficos.
Os servidores MySQL serão distribuídos em uma rede redundante. Os dados
serão replicados entre as múltiplas instâncias dos servidores MySQL, como
mostrado na Figura 16. Para tanto, será necessário que se configure
individualmente cada estação, indicando o mestre e o escravo correspondente. Será
possível ler e escrever em qualquer um dos servidores.
45
Figura 16 - Replicação de dados nos nós do SCADA
Em caso de falha de uma estação específica, os servidores MySQL devem
alterar seu mestre automaticamente, de forma a não interromper leitura e escrita,
segundo quadro da Figura 16. Essa alteração de mestre deve ser transparente ao
usuário, mas ele deve ter ciência de qual unidade apresentou defeito.
Quando uma estação servidora MySQL que estava em falha voltar a operar, o
sistema deverá restabelecer a condição de funcionamento original, isso, também, de
forma transparente ao usuário.
Os dados serão transmitidos ao banco de dados apenas quando o valor da
tag for alterado. A configuração dos Servidores e tags serão apresentadas em uma
árvore. Haverá a opção de inserir grupos de leitura do banco de dados, segundo
uma freqüência arbitrária.
Objetivos do teste: historiar dados, redundância ativa.
3.5.2.2: Conexão entre Excel e banco de dados
Novamente, o Excel será usado como uma aplicação externa. Nesse caso, o
software será usado para acessar dados diretamente do banco de dados relacional
construído para o projeto Blue Ocean.
Os valores de tag serão coletados do banco de dados e mostrados em
células do Excel.
Objetivos do teste: Conectividade com Excel e usabilidade.
46
3.5.3: Interface Gráfica
3.5.3.1: Disposição de janelas
As janelas do SCADA no projeto Blue Ocean são orientadas à perspectiva,
seguindo a forma padrão adotada em Eclipse RCP. Cada uma das perspectivas é
composta por um número de vistas disponíveis. Assim, o usuário pode dividir as
perspectivas de acordo com suas funções, por exemplo: Desenho de telas,
Recursos, Alarmes.
As vistas poderão ser movidas arbitrariamente dentro da perspectiva,
formando arranjos propícios aos usuários. As janelas podem ser desacopladas da
perspectiva e realocadas livremente, permitindo o uso de muitas telas para a
configuração.
Todas as vezes que o programa é encerrado, a disposição das janelas e
salva. Assim, da próxima vez que o programa for reaberto, a tela configurada será
restaurada.
Objetivo do teste: usabilidade.
3.5.3.2: Editor de telas
O Editor de telas contém os mecanismos necessários para a criação de
sinóticos. Existe uma palheta com padrões gráficos que serão adicionados às telas
e podem ser mapeados para os dispositivos de campo.
47
Figura 17 - Editor de telas Blue Ocean
Os objetos imagem padrão são carregados de bibliotecas disponibilizadas
pelos plug-ins, esses plug-ins são acessados por todas as instâncias do SCADA.
O usuário pode arrastar e alocar objetos gráficos para uma tela em edição e
conectá-los entre si. As telas construídas podem ser publicadas na rede, todas as
instâncias
do
SCADA
executando
o
Editor
receberão
a
tela
publicada
imediatamente.
Dentre outras funcionalidades para facilitar a construção de telas estão: caixa
de diálogo para alterar propriedades dos objetos, zoom in/ou, visualização dos
componentes em estrutura de árvore, e janela de visulização global para navegação.
Objetivo do teste: Facilidade de configuração e geração de padrão
48
3.5.3.3: Objetos Animados
Objetos animados são aqueles que possuem comportamento dinâmico de
acordo com o estado da variável a que estão associados. Exemplos típicos são
medidores de nível e indicadores de estado.
O comportamento desses objetos no Blue Ocean será definido por um script
BeanShell, configurado pelo usuário. Essa forma de configuração é apenas um
embrião para o desenvolvimento de um mecanismo flexível.
Objetivo do teste: comportamento dinâmico e performance em tempo real.
3.5.3.4: Gráficos de processo
Através da interface o usuário poderá buscar tanto variáveis em tempo real
quanto do banco de dados e exibir os resultados da procura através de gráficos.
Os gráficos têm parâmetros totalmente editáveis: escala, cor, títulos dos
eixos, zoom.
Objetivo do teste: geração de gráficos, aquisição do banco de dados,
performance em tempo real e usabilidade.
3.5.4: Modularidade
A modularidade do SCADA do projeto Blue Ocean está diretamente
relacionada com a plataforma de desenvolvimento orientada a plug-ins. Os
componentes centrais, por exemplo DDS, são adicionados como plug-ins.
Afim de mostrar a estrutura modular do software desenvolvido, será mostrado
a adição e atualização de um plug-in em tempo de execução. O plug-in então será
usado sem que a aplicação seja reiniciada.
Objetivo do teste: modularidade.
3.5.5: Portabilidade
A plataforma escolhida permite que o SCADA seja executado em diferentes
sistemas operacionais sem perda de funcionalidade. Como mostrado na bancada de
testes, haverá uma estação Linux comunicando-se e executando as mesmas tarefas
49
das demais estações. Exceção feita à comunicação DDS, uma vez que a licença
para Linux ainda não foi adquirida.
Objetivo do teste: Portabilidade.
3.6: Testes
Paralelamente à definição dos itens a serem mostrados e dos objetivos dos
testes, foi iniciado o detalhamento do formato da apresentação.
Foram montados casos de teste organizados passo a passo de forma que os
clientes pudessem acompanhar e avaliar de forma mais precisa.
O detalhamento passo a passo foi preenchido durante a execução dos testes
preliminares e tem a estrutura mostrada na Tabela 5.
Tabela 5 - Detalhamento passo a passo dos testes
Teste 001 – Cliente OPC
Adicionar tags, ler e escrever dados de e para o CLP
!
$
"
#
%
& %
%
'
( %
)
!
"
#
*
+
$
+
&
+
50
"
,
'
'
.
%
+
(
Aprovado
!
Aprovado com comentários
)
Não aprovado
Ao final, foram gerados 26 casos de teste para o sistema SCADA. Desses,
sete testes cobriam a parte de comunicação, cinco a troca de dados via DDS, nove
a construção de telas e interface de usuário, quatro a estrutura de banco de dados,
e um o teste de modularidade. Os testes de portabilidade ficaram distribuídos dentre
os vários testes propostos, uma vez que a estação Linux é usada na bancada.
Após a definição de todos os casos de teste, o guia passo a passo foi
exaustivamente testado na bancada de testes configurada. Todos os testes foram,
ao final, aprovados.
3.7: Apresentação
A apresentação da Prova de Conceito foi realizada no Rio de Janeiro. Dentre
os participantes estavam três especialistas em desenvolvimento e projetos de
Automação da Siemens AG, o gerente do projeto Blue Ocean na Siemens e toda a
equipe da Chemtech.
Primeiramente, os objetivos do desenvolvimento durante essa fase do projeto
foram apresentados de forma global, assim como revisada a arquitetura proposta.
Em um segundo momento, a equipe de desenvolvimento apresentou os 26
casos de teste aos clientes. Todos os testes foram aprovados com sucesso. Os
51
clientes mostraram clara satisfação com a arquitetura e a linha de implementação
adotada.
3.8: Ferramenta de Configuração de Engenharia
3.8.1: Importância
Durante a apresentação da Prova de Conceito, foi levantada a necessidade
do desenvolvimento de uma ferramenta flexível para a configuração e customização
de objetos do sistema SCADA, chamada Ferramenta de Configuração de
Engenharia. Os clientes propuseram a implementação de um protótipo desse
sistema para complementar os tópicos mostrados na Prova de Conceito, dada sua
importância para a aceitação de um sistema SCADA.
Através da Ferramenta de Configuração de Engenharia é possível construir
sinóticos padrão associados a um determinado objeto, de forma a monitorar e
controlar seu funcionamento. Assim, através do sinótico associado a uma válvula,
por exemplo, seria possível mostrar seu estado atual (percentagem de abertura, em
manutenção, em operação local ou remota), seu histórico de funcionamento recente
(gráfico indicando sua abertura no tempo), os alarmes ativados, além de permitir
que o operador altere seu set point.
Durante a etapa de configuração e customização, o usuário deve inserir uma
série de parâmetros mapeando as variáveis de interesse de um determinado
equipamento e a forma como essas variáveis serão apresentadas. O objetivo
principal da Ferramenta de Configuração de Engenharia é reduzir o esforço de
configuração de centenas ou milhares de equipamentos.
A Ferramenta de Engenharia deve possuir atributos como previsibilidade,
consistência e ser de fácil utilização. Esse aplicativo deve também permitir a
definição de templates, macros e bibliotecas.
52
3.8.2: Estrutura do Aplicativo
Tendo em vista as características desejáveis para a Ferramenta de
Configuração de Engenharia, foi iniciado o desenvolvimento de um plug-in para o
software do projeto Blue Ocean.
A estrutura de configuração construída é mostrada na Figura 18. Um
aplicativo gráfico acoplado ao SCADA do projeto Blue Ocean (Plug-in de
Configuração) permitirá que o usuário defina um layout e conteúdo de um sinótico
específico.
Figura 18 - Ferramenta de Configuração de Engenharia
A seguir, a estrutura criada é armazenada na forma de um arquivo XML
(Extensible Markup Language). XML é um padrão W3C (World Wide Web
Consortium) largamente utilizando para padronização de estrutura de dados.
Existem no mercado muitas ferramentas para visualizar, validar e construir arquivos
nesse formato.
O arquivo XML garante a flexibilidade e facilidade de replicação dos sinóticos
criados. Pode-se facilmente construir uma rotina para gerar arquivos construídos
nesse padrão através da leitura de dados de um banco de dados. Os arquivos XML
podem também ser distribuídos para as várias instâncias do SCADA através do
middleware DDS.
Os arquivos XML configurados e replicados podem então ser carregados pelo
Software Blue Ocean através de um componente que realiza a conversão do arquivo
53
XML em objetos Swing. Swing é o kit gráfico para Java mais utilizado no mundo. Os
objetos Swing são, então, mostrados como sinóticos na tela do supervisório.
3.8.3: Detalhamento do Aplicativo
O plug-in de configuração dos sinóticos foi desenvolvido utilizando-se
componentes gráficos da plataforma Eclipse RCP. O componente utilizado foi o
Eclipse Form. A seguir, será mostrado como é criado um novo sinótico (faceplate)
utilizando essa interface.
Não existe uma seqüência definida para a criação do sinótico, o usuário pode
navegar livremente pelas telas de configuração. Inicialmente, pode-se criar adicionar
todas os tags de interesse, como mostrado na Figura 19.
Figura 19 - Adição de tags
Além de tags, podem ser adicionados gráficos ao sinótico, como
representado na Figura 20. Cada gráfico possui propriedades editáveis, como título,
54
subtítulo, cores de fundo e cor do grid. Além disso, podem ser inseridas curvas
relativas a dados históricos (banco de dados) ou de tempo real.
Figura 20 - Adição de Gráficos
As curvas inseridas (trends) também podem ser editadas pelo usuário. Cor do
eixo, posição da escala, título e limites são as variáveis disponíveis.
Assim que concluir a edição do sinótico o usuário pode gerar o arquivo de
configuração XML, Figura 21. O arquivo XML convertido em objeto Swing é
mostrado na Figura 22. Esse objeto pode, então, ser associado a um equipamento
representado em uma tela do sistema SCADA.
55
Figura 21 - Geração do Arquivo XML
Figura 22 - Sinótico gerado
56
3.9: Testes para Finalização da versão
A Ferramenta de Configuração de Engenharia encerrou a última etapa do
desenvolvimento de software na fase de Elaboração. Como nas próximas etapas
seriam realizadas alterações profundas na estrutura do produto devido a
continuidade do desenvolvimento, achou-se conveniente finalizar uma versão com
tudo que havia sido construído até o momento.
Foram, assim, feitos testes completos com todos os módulos produzidos.
Esses testes geraram uma lista de bugs que foram resolvidos ou arquivados para
resolução posterior.
Ao final dos testes e correção dos bugs, foi gerada uma versão do SCADA
para a fase de Elaboração. Essa versão, além de representar o produto final da fase
de projeto, também seria utilizada em futuras apresentações, tanto para os clientes
diretos (Siemens), quanto para os indiretos na África do Sul.
3.10: Revisão da arquitetura
Durante as primeiras etapas de desenvolvimento, o contato com a plataforma
Eclipse RCP e demais componentes de software e a troca de informações com os
clientes e os cursos realizados geraram muito conhecimento em todas as frentes de
trabalho.
Esse conhecimento deveria então ser distribuído e discutido pelo grupo a fim
de tornar mais dinâmica e qualificada a construção do SCADA nas próximas etapas
do projeto.
Assim,
foi
organizada
uma
reunião
de
três
dias
com
todos
os
desenvolvedores do projeto. Essa reunião com tema livre gerou importantes
definições quanto a estruturação de código, controle de versões, testes de
acompanhamento e ambiente de testes.
57
3.11: Definição da bancada final de testes
A reunião de Revisão da Arquitetura gerou uma série de atividades para a
equipe. Uma das importantes atividades era definir uma bancada de testes completa
de forma a simular as condições de troca de dados existentes na África do Sul.
Durante as fases anteriores do projeto, foram levantadas junto a Siemens e a
operadora de pipelines sul-africana informações sobre as instalações em
funcionamento e a serem implantadas nos pipelines em que o SCADA do projeto
Blue Ocean seria utilizado.
Essas informações apontaram dois itens essenciais para a composição da
bancada de testes definitiva do projeto: CLP S7-400 e módulos TIM.
3.11.1: CLP S7-400
A linha de CLP’s Siemens S7-400 é utilizada em todos os pipelines em que o
SCADA do projeto Blue Ocean será instalado. Esses CLP’s permitem variadas
formas de codificação e comunicação.
Um CLP S7-400 pode ser codificado usando as linguagens padrão definidas
pela IEC 61131-3: Diagrama de Blocos Funcionais (FBD), Lista de instruções (IL),
Texto Estruturado (ST) e Ladder (LD).
Cartões para comunicação Profibus, Industrial Ethernet, dentre outros são
disponibilizados para essa linha de CLP’s.
3.11.2: Módulo TIM
Os módulos TIM são componentes Siemens que realizam a comunicação em
redes industriais de longa distância. Esses módulos estão sendo gradativamente
adotados nos pipelines sul-africanos.
Os módulos TIM se interpõem entre os CLP’s e os computadores da rede
trocando dados de forma confiável em uma rede de longa distância (WAN – Wide
Area Network), como mostrado na Figura 23. A comunicação entre TIM e CLP e
entre TIM e sistema supervisório é feita segundo uma interface padrão da Siemens,
chamada MPI.
58
Figura 23 - Utilização Módulo TIM
Dependendo do modelo, os
módulos TIM utilizam formas distintas para
trocar dados na rede WAN. Os modelos TIM 42 utilizam uma rede dedicada, os TIM
43 uma rede discada analógica, e os TIM 44 uma rede ISDN (Integrated Services
Digital Network).
Eles possuem grande importância para a bancada de testes, uma vez que o
SCADA deverá se comunicar diretamente com ele, usando um protocolo proprietário
Siemens, o ST-7.
3.11.3: Arranjo dos equipamentos
Tendo em vista esses dois equipamentos principais, foi elaborada uma
bancada com dispositivos de hardware e software que permitissem os testes
durante as próximas fases do projeto Blue Ocean. O foco principal da bancada é
59
garantir que dados sejam trocados entre CLP e sistema SCADA utilizando todos os
meios disponíveis nas plantas da África do Sul.
Dessa forma, foi elaborada a estrutura mostrada na Figura 24.
Figura 24 - Bancada de testes definitiva
Os módulos TIM escolhidos (TIM 42 V) implementam comunicação através
de uma rede dedicada a dois fios. Existe ainda uma conexão para testes usando o
protocolo RS-232.
A placa CP 5611 acoplada ao SCADA #1 realiza a troca de dados sobre a
interface proprietária MPI da Siemens. A instalação e configuração dessa placa é
necessária para testes do driver ST-7 a ser construído.
A comunicação Ethernet entre o SCADA Local e o CLP S7-400 servirá para
transferência de programas e realização de testes simples com servidor OPC, como
na Prova de Conceito.
Os softwares ST7cc e WinCC são softwares da Siemens. O ST7cc converte
os dados adquiridos via ST-7 e disponibiliza-os para o sistema SCADA WinCC.
60
Esses dois softwares serão úteis durante a configuração da bancada e
posteriormente no estudo para implementação do driver ST-7.
O arranjo proposto foi apresentado para engenheiros da Siemens Alemanha
e para um consultor de automação da Chemtech, todos aprovaram.
3.12: Detalhamento da bancada
Após a definição da disposição geral da bancada, partiu-se para o
detalhamento da montagem da bancada. Foram estudados os esquemas de ligação
dos componentes e proposta a estrutura mostrada na Figura 25.
Figura 25 - Bancada de testes definitiva
3.13: Reformulação do Plano de testes
Foi agendada uma visita à África do Sul para a apresentação do SCADA em
desenvolvimento. Nessa visita, seriam mostrados o plano de migração do sistema
61
SCADA atualmente utilizado e alguns cenários de teste, semelhantes aos da Prova
de Conceito.
Assim, usando a versão do software finalizada após a Prova de Conceito, já
com
a
Ferramenta
de
Configuração
de
Engenharia
e
algumas
outras
funcionalidades, foram revisados os casos de teste.
Aspectos como relevância do teste, equipamentos utilizados e tempo para
execução foram considerados na reformulação do Plano de Testes.
Ao final, foram identificados 20 cenários a serem apresentados, distribuídos
conforme Tabela 6.
Tabela 6 - Testes a serem realizados na África do Sul
Tipo de teste
Comunicação (OPC, IEC)
Middleware DDS
Funcionalidades de interface
MySQL
Ferramenta de Configuração de Engenharia
Alarmes
Quantidade
4
3
6
3
2
2
Um problema crítico da apresentação na África do Sul era a indisponibilidade
de um CLP para teste. Foi pesquisada uma alternativa e chegou-se ao OPC Data
Calculator.
OPC Data Calculator é um produto da Matrikon, desenvolvedor mundial de
produtos para OPC. Esse software permite que variáveis OPC sejam manipuladas
em um diagrama de blocos semelhante ao Simulink do MatLab.
O Data Calculator foi usado, então, para simular o comportamento de um
sistema de segunda ordem. O sistema de segunda ordem foi concebido com
variáveis discretas com a seguinte estrutura:
y (n + 1) = α ((1 − β ) * y (n) + β * y (n − 1)) + (1 − α ) * u (n)
Os parâmetros livres eram α e β , variando de zero a um. Quanto mais
próximos de zero mais rápido o sistema. Não foi desenvolvido um controlador, os
resultados serão vistos apenas em um sistema de malha aberta.
62
De forma a relacionar o novo teste com o realizado na Prova de Conceito, a
variável de atuação (u) foi chamada de set point do aquecedor e a variável de saída
(y) de temperatura, como pode ser visto na Figura 26.
Figura 26 - Diagrama de Blocos do Data Calculator
Através do acesso OPC os usuários do Blue Ocean podem alterar o set point
do aquecedor e verificar a dinâmica de temperatura. Também pode-se alterar os
parâmetros α e β , mudando o tipo de resposta do sistema. Assim, mesmo sem o
acesso a um CLP é possível simular um processo e tornar mais agradável a
apresentação.
3.14: Teste versão para apresentação
Uma vez definido o plano de testes, foram instalados e testados todos os
componentes de software necessários para a apresentação do Projeto Blue Ocean
na África do Sul. Três laptops foram integrados em rede e os testes descritos
anteriormente exaustivamente testados.
63
Capítulo 4: Conclusões e Perspectivas
Os resultados obtidos no Projeto Blue Ocean atenderam completamente às
expectativas da equipe de desenvolvimento e dos clientes. O conhecimento e
empenho de todos, aliado ao suporte da empresa, permitiram que um trabalho de
qualidade fosse realizado.
A Prova de Conceito foi o principal marco do projeto. A completa aprovação
de uma equipe de avaliadores multi-qualificados representou o reconhecimento da
qualidade e aplicabilidade da solução desenvolvida.
Do ponto de vista pessoal, o trabalho permitiu que os conhecimentos
adquiridos no curso de Engenharia de Controle e Automação fossem explorados e
aprofundados intensamente. Áreas como instrumentação, desenvolvimento de
software, redes e CLP’s fizeram parte do cotidiano de trabalho. O contato com uma
empresa e grupo de trabalho que valorizam e incentivam a pesquisa e a inovação foi
enriquecedor.
Infelizmente, antes da viagem de apresentação do projeto aos clientes da
África do Sul, a Siemens AG (Alemanha) optou por suspender o projeto Blue Ocean.
A suspensão não estava ligada ao desenvolvimento realizado, ela atendia anseios
gerenciais e estratégicos da empresa alemã.
Entretanto, o protótipo e arquitetura desenvolvidos e, principalmente,
o
conhecimento adquirido continuam como propriedade da Chemtech. Pesquisas de
mercado estão sendo feitas com a intenção de vender o projeto para uma outra
operadora de pipeline. Essa alternativa pode-se tornar realidade em breve.
64
Bibliografia:
[1]
BAILEY D., WRIGHT E., “Practical SCADA for Industry”, Elsevier, 2005.
[2]
MOHITPOUR M., SZABO J. e
HARDEVELD T.V. “Pipeline Operation &
Maintenance – A Practical Approach”, ASME Press New York, 2005.
[3]
IWANITZ F., LANGE J., “OPC – Fundamentals, Implementation and
Application”, Hüthig Verlag Heidelberg, 3rd rev. Ed., Alemanha, 2006.
[4]
BURNETTE E., “Rich Client Tutorial”, http://www.eclipse.org/articles/ArticleRCP-1/tutorial1.html, 2006.
[5]
KRUTZ R., “Securing SCADA Systems”, Wiley Publishing, 2006.
[6]
IEEE STANDARD C37.1-1994, “Definition, Specification, and Analysis of
Systems Used for Supervisory Control, Data Acquisition, and Automatic Control”,
Institute of Electrical and Electronics Engineers, 1994.
65