NavCimUma Arquitectura Distribuıda de Suporte ao
Controlo e Supervisao em Tempo-realde Processos Industriais.
Antonio Casimiro Ferreira da Costa(Licenciado)
Dissertacao para obtencao do Grau de Mestre emEngenharia Electrotecnica e de Computadores
Setembro de 1995
Tese realizada sob a orientacao do
Prof. Doutor Paulo Jorge Esteves Verıssimo
Professor Associado com Agregacao do Departamento de Informatica da Faculdadede Ciencias da Universidade de Lisboa
A Beta e a Maria.
NAVCIMUMA ARQUITECTURA DISTRIBUIDA DE SUPORTEAO CONTROLO E SUPERVISAO EM TEMPO-REAL
DE PROCESSOS INDUSTRIAIS.
Antonio Casimiro Ferreira da CostaIST� - INESC� - JNICT�
E-mail: [email protected]
�Instituto Superior Tecnico.�Instituto de Engenharia de Sistemas e Computadores.�Este trabalho foi suportado por uma bolsa da Junta Nacional de Investigacao Cientıfica e
Tecnologica, atraves do “Programa Ciencia”.
Resumo
Este trabalho e dedicado ao estudo de uma arquitectura distribuıda, a arquitec-
tura NavCim, que pretende fornecer os mecanismos essenciais para a supervisao e o
controlo de processos em ambientes industriais. As solucoes inovadoras nela propos-
tas tentam suprimir as limitacoes evidenciadas pela generalidade dos sistemas actual-
mente existentes.
As principais caracterısticas dos sistemas de supervisao e controlo sao analisadas
e sistematizadas em diversas vertentes, nomeadamente em termos de funcionalidades
disponibilizadas, de capacidades de configuracao e de comunicacao e, ainda, do su-
porte a heterogeneidade e distribuicao. Estas caracterısticas sao ilustradas com exem-
plos retirados de alguns sistemas, representativos do actual panorama de mercado.
A modularidade da arquitectura proposta e uma caracterıstica fundamental, bem
patente na descricao que e feita do seu modelo do fluxo de informacao e do seu modelo
computacional. Sao analisadas as solucoes propostas para transporte, armazenamento
e distribuicao da informacao e sao focados os aspectos relativos ao funcionamento dos
modulos e as suas interaccoes.
A concretizacao de uma plataforma baseada na arquitectura proposta e tambem
descrita, sendo fornecido um exemplo da sua utilizacao e algumas medidas de
desempenho que permitem sugerir novas direccoes para a evolucao do trabalho ja
desenvolvido.
i
Abstract
This work studies the NavCim architecture, a distributed architecture, which
is supposed to supply the essential mechanisms to the supervision and control of
processes in industrial environments. The solutions proposed aim to suppress the
limitations shown by the majority of the nowadays existing systems.
The essential characteristics of the supervision and control systems are analyzed
and systematized in different ways, namely for what concerns the available functio-
nalities, configuration and communication capacities and support to the heterogeneity
and distribution. Examples taken from some systems, representative of the actual mar-
ket panorama, are given to illustrate these characteristics.
That the modularity of the proposed architecture is a fundamental characteristic
reveals itself obvious in the description made of the information flow model and
of the computational model. The solutions proposed to the transport, storage and
distribution of information are analyzed and the aspects concerning module operation
and interactions are focused.
The development of a platform based in the designed architecture is also described
and an example of its use is given as well as some performance measures that suggest
new directions to the persecution of the up to now developed work.
ii
Palavras Chave
– Sistemas Distribuıdos
– Sistemas SCADA
– Automatizacao Industrial
– Sistemas de Informacao
Keywords
– Distributed Systems
– SCADA Systems
– Industrial Automation
– Information Systems
iii
Agradecimentos
Ao meu orientador, Prof. Paulo Verıssimo, a quem desejo expressar o meu
reconhecimento pelo empenho que colocou na orientacao deste trabalho. As conversas
que tivemos, as suas crıticas e sugestoes constituiram um incentivo fundamental para
a concretizacao da presente tese.
Ao Eng. Luıs Rodrigues, meu colega de trabalho, devo um especial agradecimento
pelo seu exemplo e pelos preciosos ensinamentos que sempre me transmitiu.
Aos restantes elementos da minha equipa de trabalho no INESC: Eng. Sergio
Melro, Eng. Henrique Fonseca, Eng. Jose Rufino, Eng. Luis Silva, Eng. Carlos
Almeida, Eng. Francois Cosquer e Eng. Jorge Frazao, pela excelente camaradagem,
espırito de equipa e elevado profissionalismo.
A Isabel Miguel e ao Jose Martins pela sua colaboracao na construcao das interfaces
graficas da plataforma NavCim.
Ao INESC, pela disponibilizacao dos meios tecnicos e de enquadramento cientıfico,
essenciais para a realizacao deste trabalho.
Finalmente, deixo aqui uma palavra de agradecimento a todos aqueles que de
alguma forma contribuıram com sugestoes, crıticas ou simplesmente palavras de
incentivo para a realizacao deste trabalho.
Lisboa, Setembro de 1995
Antonio Casimiro Ferreira da Costa
iv
Indice
Resumo i
Abstract ii
Palavras Chave iii
Agradecimentos iv
Indice v
Lista de Figuras ix
Lista de Tabelas x
1 Introducao 1
1.1 Estrutura da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Panoramica Sobre Sistemas SCADA 4
2.1 Os Sistemas Estudados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 EasyMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 FactoryLink IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 InTouch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4 Processyn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Caracterısticas Principais dos SCADA . . . . . . . . . . . . . . . . . . . . 11
2.3 A Modularizacao dos Sistemas . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Aplicacoes e Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1 Configuracao do Sistema . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.2 Controlo de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3 Gestao da Execucao . . . . . . . . . . . . . . . . . . . . . . . . . . 21
v
2.4.4 Monitorizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.5 Sinopticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.6 Temporizacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.7 Coleccao de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.8 Alarmes e Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.9 Graficos de Tendencia . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.10 Receitas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.11 Gestao de Ficheiros . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4.12 Processamento de Dados . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.13 Processamento Estatıstico . . . . . . . . . . . . . . . . . . . . . . . 28
2.4.14 Relatorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.5 Capacidades de Representacao e Manipulacao de dados . . . . . . . . . 29
2.6 Capacidades Graficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7 Capacidades de Configuracao . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8 Capacidades de Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.8.1 Comunicacao com os Dispositivos . . . . . . . . . . . . . . . . . . 36
2.8.2 Comunicacao entre Aplicacoes . . . . . . . . . . . . . . . . . . . . 38
2.9 Expansibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.10 Compatibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.11 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3 A Arquitectura NavCim 42
3.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.1 Heterogeneidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.2 Distribuicao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.3 Escalabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.4 Expansibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.1.5 Tempo-Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1.6 Custo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2 Descricao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1 Nıvel dos Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.2 Nıvel de Celula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.2.3 Nıvel de Gestao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3 A Modularizacao NavCim . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.1 Modulos de Suporte . . . . . . . . . . . . . . . . . . . . . . . . . . 64
vi
3.3.2 Modulos de Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.3.3 Modulos Nucleares . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.4 Modelo do Fluxo de Informacao . . . . . . . . . . . . . . . . . . . . . . . 72
3.4.1 Dados de Supervisao e Controlo . . . . . . . . . . . . . . . . . . . 73
3.4.2 Distributividade da Informacao . . . . . . . . . . . . . . . . . . . 76
3.4.2.1 Distributividade da Informacao de Tempo-Real . . . . . 78
3.4.2.2 Distributividade da Informacao Estavel . . . . . . . . . 80
3.4.3 Eventos e Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.4.4 Longevidade da Informacao . . . . . . . . . . . . . . . . . . . . . 83
3.5 Modelo Computacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.5.1 Visao Integrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.5.2 Inicializacao e Configuracao . . . . . . . . . . . . . . . . . . . . . . 90
3.5.3 VMD-Celula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.5.4 Coleccao de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.5.5 Pre-processamento de Dados . . . . . . . . . . . . . . . . . . . . . 99
3.5.6 Arquivo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.5.7 Gestao de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.5.8 Gestao de Alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.5.9 Servico de Tempo Global . . . . . . . . . . . . . . . . . . . . . . . 106
3.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4 Concretizacao 110
4.1 Ambientes e Sistemas de Suporte . . . . . . . . . . . . . . . . . . . . . . . 110
4.1.1 Sistema de Ficheiros Distribuıdo (NFS) . . . . . . . . . . . . . . . 111
4.1.2 Plataforma MMS (SWCP) . . . . . . . . . . . . . . . . . . . . . . . 113
4.1.3 Emulador de pilhs OSI (ISODE) . . . . . . . . . . . . . . . . . . . 116
4.1.4 Ambiente de Suporte Local (LSE) . . . . . . . . . . . . . . . . . . . 117
4.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.2.1 Interface de Celula . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.2.2 Interface de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.3 A Celula NavCim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.3.1 Linguagem de Configuracao . . . . . . . . . . . . . . . . . . . . . 123
4.3.2 Mecanismos de Execucao Concorrente . . . . . . . . . . . . . . . . 126
4.3.3 Arquitectura de Software . . . . . . . . . . . . . . . . . . . . . . . . 127
4.3.4 Coleccao de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
vii
4.3.5 Tratamento de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.3.6 Servico de Tempo Global . . . . . . . . . . . . . . . . . . . . . . . 133
4.3.6.1 Sincronizacao Interna . . . . . . . . . . . . . . . . . . . . 133
4.3.6.2 Sincronizacao Externa . . . . . . . . . . . . . . . . . . . . 135
4.3.6.3 Tolerancia a faltas . . . . . . . . . . . . . . . . . . . . . . 136
4.4 Cenario de Aplicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.5 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5 Conclusoes e Perspectivas Futuras 144
Bibliografia 146
viii
Lista de Figuras
2.1 Interligacao entre aplicacoes e dispositivos no EasyMAP. . . . . . . . . . 72.2 Arquitectura Open Software Bus do sistema FactoryLinkIV. . . . . . . . . 82.3 Mecanismo de comunicacao no InTouch. . . . . . . . . . . . . . . . . . . 102.4 Arquitectura basica do Processyn. . . . . . . . . . . . . . . . . . . . . . . 11
3.1 A arquitectura NavCim face a heterogeneidade de sistemas e aplicacoes. 453.2 Resolucao dos problemas de distribuicao utilizando a arquitectura Nav-
Cim. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3 A hierarquia NavCim e as entidades do sistema: plataforma, dispositi-
vos e aplicacoes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4 Os tres cenarios possıveis de localizacao de um VMD. . . . . . . . . . . . 583.5 A plataforma NavCim no nıvel de celula. . . . . . . . . . . . . . . . . . . 623.6 Modulos da arquitectura NavCim. . . . . . . . . . . . . . . . . . . . . . . 643.7 Fluxo de informacao. Dados de supervisao e de controlo. . . . . . . . . . 773.8 Distributividade da informacao de tempo-real. . . . . . . . . . . . . . . . 793.9 Distributividade da informacao estavel. . . . . . . . . . . . . . . . . . . . 813.10 Transformacao de eventos em estado. . . . . . . . . . . . . . . . . . . . . 833.11 Longevidade dos dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853.12 Relacoes entre os modulos e a informacao. . . . . . . . . . . . . . . . . . . 873.13 Controlo hierarquico proporcionado pelo VMD-Celula. . . . . . . . . . . 943.14 Polıticas de organizacao de dados na coleccao. . . . . . . . . . . . . . . . 983.15 Tipos de eventos e sua representacao estatica. . . . . . . . . . . . . . . . . 1043.16 Sincronizacao de relogios. . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.1 Agentes SE e CM no modelo de referencia OSI. . . . . . . . . . . . . . . . 1144.2 Utilizacao do TCP/IP no agente CM-ISODE. . . . . . . . . . . . . . . . . 1174.3 Os dois nucleos de execucao da celula NavCim. . . . . . . . . . . . . . . 1294.4 Temporizacoes na coleccao de dados. . . . . . . . . . . . . . . . . . . . . . 1314.5 Algoritmo utilizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1354.6 Cenario de demonstracao da plataforma NavCim. . . . . . . . . . . . . . 1374.7 A aplicacao PMtool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1384.8 As aplicacoes PMrob, PMtool e a celula NavCim. . . . . . . . . . . . . . . 139
ix
Lista de Tabelas
2.1 Alguns sistemas SCADA disponıveis no mercado. . . . . . . . . . . . . . 52.2 Caracterısticas principais dos sistemas SCADA estudados. . . . . . . . . 14
4.1 Sintaxe da linguagem de configuracao. . . . . . . . . . . . . . . . . . . . . 1254.2 Tempos de execucao utilizando o agente CM-TCP/IP. . . . . . . . . . . . 1404.3 Influencia do agente CM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1414.4 Influencia do NFS nos tempos de leitura de dados. . . . . . . . . . . . . . 142
x
Capıtulo 1
Introducao
Os sistemas informaticos sao cada vez mais utilizados em ambientes industriais. A
automatizacao dos procedimentos e aplicada na realizacao de tarefas muito diversifi-
cadas que vao desde o controlo dos dispositivos fısicos ate a planificacao e a elaboracao
de relatorios sobre os dados da producao.
Verifica-se, no entanto, que a automatizacao destes procedimentos e realizada de
uma forma geral por sistemas dedicados, os quais, por nao interagirem entre si, dao
origem ao aparecimento de “ilhas” de automatizacao. Esta situacao traduz-se num
visıvel desperdıcio de recursos e num desaproveitamento de potencialidades inerentes
a existencia de multiplos nos computacionais.
No domınio das solucoes para este problema enquadram-se os sistemas designa-
dos na nomenclatura inglesa por SCADA�, que permitem realizar de uma forma inte-
grada a supervisao e o controlo dos equipamentos industriais, fornecendo os mecanis-
mos de ligacao a controladores industriais, computadores, sensores, terminais e outros
dispositivos e disponibilizando diversas funcionalidades, tais como visualizacao de
graficos e sinopticos animados, gestao de alarmes e arquivo de dados, que os tornam
plataformas capazes de atender a generalidade das necessidades encontradas na auto-
matizacao de sistemas industriais. Sao no entanto reconhecidas algumas limitacoes aos
sistemas SCADA. As solucoes propostas, indissociaveis do seu caracter comercial, sao
sistematicamente solucoes proprietarias que requerem a utilizacao de equipamentos e
produtos especıficos. Tal caracterıstica facilmente inviabiliza a sua utilizacao em am-
bientes heterogeneos ou onde os equipamentos ja existentes nao sao suportados. Por
�Supervisory, Control And Data Acquisition
1
CAPITULO 1. INTRODUCAO 2
outro lado, sendo a eficiencia do sistema adoptado determinada pelo equilıbrio entre
os requisitos e as solucoes, e naturalmente difıcil encontrar um sistema SCADA que
apresente as caracterısticas ideais. Na verdade, e mesmo que tal aconteca, as possibi-
lidades de evolucao, expansao ou alteracao do sistema supervisionado estao ate certo
ponto condicionadas pelo sistema SCADA utilizado.
Justifica-se assim a procura de solucoes no domınio dos sistemas distribuıdos que
proporcionem o preenchimento das lacunas evidenciadas pelos sistemas actualmentes
disponıveis, nomeadamente no respeitante a problemas de heterogeneidade, escalabili-
dade e desempenho.
Esta tese propoe uma arquitectura distribuıda, concebida no sentido de proporcio-
nar a facil integracao de solucoes no domınio dos sistemas de supervisao e controlo,
oferecendo ao mesmo tempo o suporte necessario para realizar ajustamentos ao nıvel
da distribuicao e da escala. O esforco desenvolvido na concepcao desta arquitectura
assenta em grande medida na discussao de tematicas dos sistemas distribuıdos, com
especial relevo nos aspectos relacionados com a comunicacao, com os sistemas de fi-
cheiros e com os ambientes de suporte. Sao tambem abordados aspectos relacionados
com desempenho em tempo-real, numa perspectiva lata (Soft Real-Time).
A arquitectura proposta incorpora algumas das ideias desenvolvidas no seio do
projecto Esprit 6779 - DINAS-DQS� (no qual esteve envolvido o grupo de Sistemas
Distribuıdos e Automatizacao Industrial do INESC), tendo sido utilizada, em particu-
lar, a plataforma de comunicacao SWCP�. Esta plataforma, inicialmente desenvolvida
no IPK-Berlim, foi cedida ao INESC no ambito de um acordo de cooperacao celebrado
entre ambas as instituicoes.
A validacao da arquitectura proposta sera realizada atraves da concretizacao
de uma plataforma de software, a plataforma NavCim, que integrara os diversos
componentes especificados na arquitectura: o ambiente de suporte, as plataformas
de comunicacao, as interfaces e os modulos funcionais. Do desenvolvimento e da
utilizacao desta plataforma poderao ser obtidos alguns resultados e retiradas algumas
conclusoes acerca dos conceitos propostos na arquitectura.
�Design and Implementation of CNMA-Based Networks for CIM Applications in SMEs— DistributedQuality System.
�System Wide Communications Platform.
CAPITULO 1. INTRODUCAO 3
1.1 Estrutura da Tese
Dado que os sistemas SCADA constituem um dos elementos fundamentais de
estudo neste trabalho, o capıtulo 2 tracara uma panoramica acerca destes sistemas.
Serao analisados os seus aspectos mais importantes e as funcionalidades normalmente
disponibilizadas, sendo a discussao centrada num pequeno conjunto dos sistemas mais
relevantes actualmente existentes no mercado.
A arquitectura NavCim e descrita no capıtulo 3, sendo feita uma abordagem
inicial dos requisitos que esta deve verificar, seguida de uma descricao geral dos
seus elementos mais importantes. Sera depois feita uma analise da arquitectura
na perspectiva do fluxo de dados, que permitira compreender o papel por esta
desempenhado nas perspectivas da integracao de sistemas e do acesso das aplica-
coes aos dados de supervisao. Este capıtulo finaliza com a apresentacao do modelo
computacional da arquitectura, onde serao descritos os diversos modulos funcionais
que a compoem e as interaccoes que entre eles se verificam.
No capıtulo 4, serao abordados os aspectos relacionados com a concretizacao da
plataforma NavCim, nomeadamente os componentes de software de suporte e de
comunicacao, as interfaces desenvolvidas, as ferramentas utilizadas e a arquitectura
de software. Sera tambem apresentado o cenario de demonstracao que foi utilizado
para validar a plataforma desenvolvida, sendo explicitadas algumas medidas de
desempenho relativas a mesma.
Finalmente, no capıtulo 5 sao expostas as conclusoes mais importantes resultantes
do trabalho efectuado e sao indicadas as perspectivas em termos das possıveis evolu-
coes deste trabalho.
Capıtulo 2
Panoramica Sobre Sistemas SCADA
Dado que temos vindo a assistir, nos ultimos anos, a utilizacao cada vez mais
generalizada de sistemas SCADA em empresas e industrias, que existe uma grande
diversidade de sistemas SCADA disponıveis no mercado e que estes nao oferecem,
obviamente, as mesmas funcionalidades, e interessante proceder ao estudo das suas
caracterısticas para que possamos fazer uma analise comparativa.
Nesta medida, comecaremos por descrever de uma forma informal os sistemas
SCADA abordados ao longo do capıtulo, dando ainda algumas indicacoes sobre outros
sistemas existentes no mercado. Faremos um resumo das principais caracterısticas
destes sistemas dando relevo aos seus aspectos modulares. Analisaremos ainda as
suas funcionalidades mais importantes e discutiremos alguns aspectos relativos as
capacidades graficas, de representacao e manipulacao de dados, de configuracao e de
comunicacao. Debrucar-nos-emos, finalmente, sobre as capacidades de expansao e a
compatibilidade dos sistemas com outras aplicacoes.
2.1 Os Sistemas Estudados
Os domınios de aplicabilidade de sistemas SCADA sao muito diversificados,
abrangendo sectores industriais como a industria quımica, farmaceutica, alimentar, au-
tomovel, metalo-mecanica ou da pasta de papel. E tambem possıvel encontrar aplica-
coes de sistemas SCADA na producao, tratamento e distribuicao de gas, electricidade
e outros recursos energeticos.
A tabela apresentada em seguida contem informacoes gerais relativas a alguns dos
4
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 5
sistemas SCADA disponıveis no mercado. Nao faremos um estudo exaustivo de cada
um deles, pois pensamos ser mais proveitoso fazer uma abordagem tematica relativa
a funcionalidades normalmente fornecidas. Nos momentos oportunos faremos as
referencias que considerarmos convenientes em termos de comparacao dos diversos
sistemas SCADA.
SCADA Companhia País Tipo de SoluçãoContronic S Hartmann & Braun Alemanha Sistema Integrado
DCI System Six Fischer & Porter Estados Unidos Sistema Integrado
EasyMAP PROCOS A/S Dinamarca Software OS/2
FactoryLink IV USDATA Estados Unidos Software Multi-plataforma
FIX DMACS Intellution Estados Unidos Software Windows
Genesis ICONICS Estados Unidos Software MS-DOS
InTouch Wonderware Estados Unidos Software Windows
LabVIEW National Instruments Estados Unidos Software Multi-plataforma
Processyn Logique Industrie França Software MS-DOS e OS/2
Process Window Taylor Canadá Software Windows
SCAN 1000 Hexatec Inglaterra Software Windows
VXL Control Systems International Estados Unidos Software VMS
Tabela 2.1: Alguns sistemas SCADA disponıveis no mercado.
Nao incluımos nesta tabela os sistemas que, apesar de relacionados com a tematica
da supervisao e controlo, oferecem outro tipo de funcionalidades, sendo mais vo-
cacionados para a concretizacao de aplicacoes na area da gestao fabril, como sejam
aplicacoes para gestao de operacoes, controlo da qualidade e gestao da manuten-
cao. Referimo-nos, por exemplo, a ferramenta PROFIT�, colocada no mercado por um
consorcio Luso-Alemao, que permite concretizar as aplicacoes atras mencionadas.
Dos sistemas apresentados na tabela apenas alguns foram estudados em maior
profundidade. Foram eles o EasyMAP[EM92], o FactoryLink[FL93], o InTouch[IT93]
e o Processyn[PRO91]. A seleccao deste subconjunto de sistemas, que consideramos
representativo do estado actual do mercado de sistemas SCADA, foi realizada com
base nos seguintes criterios: conhecimentos previos acerca do sistema, experiencia de
utilizacao e quantidade de informacao disponıvel.
�PRoduction Optimization through Flexible and Integrated software Tools.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 6
2.1.1 EasyMAP
O EasyMAP e um sistema SCADA que permite o desenvolvimento de uma
vasta gama de aplicacoes no ambito da automatizacao de sistemas e do controlo
de processos. A unica plataforma de execucao suportada e o OS/2, da IBM, para
computadores PC/AT ou compatıveis.
A sua caracterıstica mais particular reside no metodo utilizado para comunicacao
com os dispositivos industriais. Para este fim o EasyMAP segue a norma MAP/TOP�
para comunicacoes, o qual especifica o protocolo MMS� como um dos protocolos de
nıvel superior, em termos do modelo de referencia OSI� (ISO� 7498) para os nıveis de
comunicacao.
A especificacao do MMS e totalmente orientada as caracterısticas dos ambientes
industriais, fornecendo as aplicacoes o tipo de servicos de comunicacao adequados a
este ambiente. As caracterısticas especıficas do protocolo sao escondidas ao integrador
de sistemas, ao qual sao fornecidas interfaces de programacao e de configuracao
graficas que simplificam e aceleram o desenvolvimento do sistema de supervisao.
Na figura 2.1 apresentamos um panorama do ambiente de comunicacoes encon-
trado no EasyMAP. Ressalta o facto do MMS ser o protocolo utilizado, mesmo para
comunicacao entre as aplicacoes do sistema. Observa-se, ainda, que e possıvel interli-
gar o EasyMAP a redes proprietarias utilizando o Novell Netware ou o Microsoft LAN
Manager. Esta opcao pode ser utilizada para interligar multiplas instancias do Easy-
MAP, ou seja, para alargar o leque de possibilidades de comunicacao entre aplicacoes.
Verifica-se tambem que e possıvel interligar o EasyMAP a aplicacoes tais como o EX-
CEL ou o ORACLE, gracas a utilizacao de gateways especıficas. Refira-se que a gateway
entre o EasyMAP e o EXCEL e baseada no protocolo DDE�.
As aplicacoes existentes no EasyMAP permitem a visualizacao grafica da informa-
cao atraves de sinopticos, janelas de alarme e de eventos ou graficos de tendencia e
permitem ainda construir e configurar o sistema. Finalmente, sao disponibilizadas
aplicacoes diversas, das quais destacamos uma interface de programacao para lingua-�Manufacturing Automation Protocol/T O Protocol.�Manufacturing Message Specification.�Open Systems Interconnection.�International Standards Organization.�Dynamic Data Exchange.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 7
�������
���� �����
������������ ���� � ���������� ���������������
�������
������� ���
MIMIC
ALARMDISP
CTL-EXEC
COLLECT/LOG
PICTOOL
FORMTOOL
CLIENTGATEWAY
EXCEL
ORACLE
OUTRASAPLICAÇÕES
STACK
HW
MicrosoftLAN Manager
NovellNetWare UPSE
EthernetToken Ring
EthernetToken Ring Outras
IBMOSI / MMS
SISCOMMS-EASE
AEG-ComputrolISO comm
CONCORD AEG-ComputrolCONCORD
GATEWAYUWYO
Figura 2.1: Interligacao entre aplicacoes e dispositivos no EasyMAP.
gem C, que permite o desenvolvimento de gateways entre o MMS e qualquer protocolo
proprietario.
2.1.2 FactoryLink IV
O FactoryLink e constituıdo por um nucleo de software de base e por um conjunto
de programas, chamados modulos, que permitem o desenvolvimento de aplicacoes de
supervisao e controlo. Uma das suas caracterısticas principais consiste na diversidade
de sistemas operativos suportados, entre os quais salientamos o Microsoft Windows, o
VMS, o OS/2, o HP-UX e o DEC Alpha AXP.
As interfaces de programacao e configuracao do sistema utilizam um ambiente
grafico baseado em janelas, menus, preenchimento de tabelas, editores e outras
ferramentas de uso intuitivo. A construcao das aplicacoes de supervisao nao requer,
na maioria das situacoes, conhecimentos especıficos acerca das tecnologias de suporte,
tais como sistemas operativos, bases de dados ou redes de comunicacao.
Outra das caracterısticas relevantes deste sistema e a utilizacao da arquitectura
Open Software Bus para comunicacao entre os diversos modulos. Esta arquitectura,
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 8
representada na figura 2.2, permite que os modulos sejam totalmente independentes
uns dos outros e, no entanto, compatıveis. A comunicacao entre os modulos e realizada
atraves de uma base de dados de tempo-real incorporada no Open Software Bus, a qual
desempenha um papel fundamental na execucao global do sistema. A interface de
acesso ao Open Software Bus e unica e publica, o que permite a interligacao de modulos
funcionais desenvolvidos por outros fabricantes
����������
� �
���������������������������������������
������������ ������������� �������� ����
�!����"#$����%�������������������� �������& '���������� ����������������� �����
������������#���
$��%����(��������))���������
��*�������$�+���#��,��)-�
����������.�/����
����������������
����������������,�����
���������!����
������������� �������
-��0���
Figura 2.2: Arquitectura Open Software Bus do sistema FactoryLinkIV.
A comunicacao com os dispositivos industriais e feita por modulos EDI�, os quais
proporcionam uma interface uniforme entre a base de dados de tempo-real e os
diversos equipamentos.
A comunicacao entre diversas instancias do FactoryLink e realizada atraves de um
modulo de acesso a rede local. Este modulo suporta diversos protocolos de comunica-
cao: TCP/IP, NetBIOS, DECnet e MMS. Atraves deste modulo e possıvel transferir
informacao entre duas bases de dados de tempo-real, a qual fica disponıvel a todos
os modulos a elas ligados. Esta opcao permite distribuir as aplicacoes de supervisao
pelos varios nos da rede, facto que se pode revelar de grande utilidade.
Para finalizar, refira-se que existe um modulo de comunicacao por DDE que,
�External Device Interface.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 9
funcionando como servidor DDE, permite a interligacao entre a base de dados de
tempo-real e qualquer aplicacao com suporte para DDE.
2.1.3 InTouch
O recurso a interfaces homem-maquina extremamente sofisticadas e uma realidade
que se verifica cada vez com mais frequencia no actual universo aplicacional. O
InTouch e mais um exemplo desta evolucao. Este sistema proporciona uma interface
baseada no ambiente grafico do Microsoft Windows para desenvolvimento de aplica-
coes SCADA.
A construcao das aplicacoes e orientada a objectos: os graficos sao constituıdos
por objectos, disponibilizados em bibliotecas de objectos, ou previamente definidos,
cujos metodos correspondem as suas caracterısticas dinamicas. A activacao dos
metodos e feita atraves de associacoes entre os objectos e os dados do sistema. A
caracterıstica principal deste SCADA e, de facto, a simplicidade das ferramentas de
desenvolvimento das aplicacoes.
Internamente, o InTouch possui uma base de dados que contem os nomes das
variaveis definidas no sistema, com uma capacidade maxima de 32000 nomes. A ar-
quitectura de comunicacoes deste sistema baseia-se nos protocolos DDE e netDDE,
utilizando para comunicacoes internas uma extensao ao DDE, proprietaria, denomi-
nada fastDDE. Na figura 2.3 e possıvel observar este mecanismo de comunicacao, e as
aplicacoes que dele dependem. Como se pode verificar, a comunicacao com os disposi-
tivos industriais e com outras entidades da rede local e levada a cabo atraves interfaces
dedicadas, que funcionam como gateways entre um protocolo especıfico e o DDE.
O utilizador pode optar por utilizar servidores DDE disponibilizados no InTouch
ou construir os seus proprios servidores, utilizando uma ferramenta de desenvolvi-
mento propria para esse fim. Todos os servidores, incluindo aqueles desenvolvidos
pelo utilizador, podem ser acedidos por aplicacoes com interface DDE, tais como o
EXCEL ou o Lotus 1-2-3.
E possıvel interligar aplicacoes em maquinas distintas da rede ao InTouch atraves
do NetDDE. Este protocolo pode ser utilizado em redes TCP/IP, DECnet, NetBIOS e
Novell, ou ainda sobre ligacoes serie atraves de modem.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 10
1�������2�����������*�,�������
������� �� �!�� ���
�����"#��$���%�&&�
�� ��'���&&�
�� �������
�� ��'���&&�����
������������ ��
������
�� ��
������
�����������������������
������������������������
������!���� �� �������������(����)��
Figura 2.3: Mecanismo de comunicacao no InTouch.
2.1.4 Processyn
O Processyn, de origem francesa, e uma solucao no domınio dos sistemas SCADA
que diverge em alguns aspectos da generalidade das solucoes existentes no mercado.
Uma caracterıstica particular deste sistema consiste no metodo utilizado para criar
as aplicacoes de supervisao. A configuracao do Processyn recorre a programacao das
aplicacoes, utilizando instrucoes especıficas para cada tipo de aplicacao, apos a qual
e necessario gerar o programa executavel, o que e feito atraves da utilizacao de um
compilador.
Devido ao metodo utilizado para criacao das aplicacoes, o Processyn consegue
apresentar um bom desempenho durante a execucao. Talvez por isso se justifique o
elevado numero de empresas onde e referida a utilizacao deste sistema.
A execucao do sistema e suportada por uma base de dados que contem as
variaveis utilizadas. Apenas existem tres tipos de variaveis: logicas, analogicas e
sequencias de caracteres. A definicao das interaccoes entre o sistema e o exterior e
realizada em modulos relativos a cada unidade externa. Na figura 2.4 pode observar-
se a arquitectura basica do Processyn, sendo visıveis os quatro tipos de modulos
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 11
respeitantes as interfaces existentes: comunicacao, visualizacao, comando e arquivo.
�������2�
(3� ����
����������4 ����
��������
�-�4 ����
�������
��
�
��
��
�����5��
�6���
������������������
���������� ����� ���
)7� ���
"�� �6���
Figura 2.4: Arquitectura basica do Processyn.
Devido a arquitectura do sistema, a interaccao com os dispositivos industriais e
feita por modulos de interface especıficos para cada tipo de dispositivo. O Processyn
disponibiliza um elevado numero de modulos de interface de forma a abranger os
equipamentos mais comuns. Em todo o caso, e possıvel desenvolver programas em
C ou PASCAL que executem qualquer funcionalidade nao suportada pelo Processyn,
inclusivamente funcionalidades de interface a outros dispositivos. Estes programas
sao ligados a um modulo especial do Processyn, denominado Modulo Residente, que
disponibiliza uma interface de acesso a base de dados do sistema e funcoes de acesso
a porta serie do computador.
A comunicacao em redes locais entre aplicacoes Processyn pode ser realizada
utilizando modulos especıficos para o tipo de rede utilizada. Existe suporte para redes
compatıveis com a interface NetBIOS e para redes MS-NET (em sistemas MS-DOS).
2.2 Caracterısticas Principais dos SCADA
Genericamente, a analise de sistemas e das suas caracterısticas pode ser realizada
de uma forma metodica, decompondo o conjunto em modulos mais pequenos e, como
tal, mais faceis de analisar. Os sistemas SCADA sao apenas um caso particular, sendo
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 12
assim proveitoso comecarmos por identificar as suas caracterısticas mais relevantes,
para em seguida nos debrucarmos com mais profundidade sobre cada uma delas.
Assim, apos uma analise alargada dos diversos sistemas SCADA, concluımos que
uma das possıveis abordagens ao estudo das suas caracterısticas se pode basear na
seguinte reparticao tematica:
Aplicacoes: Supervisao, Controlo, Gestao da producao, Planeamento da producao,
Controlo da qualidade, Simulacao, Manutencao e Teste automatico.
Funcionalidades disponıveis: Curvas de tendencia, Historicos, Tratamento de alar-
mes, Arquivo da dados, Ordenacao (temporal) de eventos, Receitas e Tratamen-
tos especıficos (programacao).
Capacidades de representacao e tratamento: Tamanho das aplicacoes, tipo dos dados
e mecanismos de actualizacao.
Capacidades graficas: Mecanismos de suporte a configuracao das aplicacoes, a edicao
de sinopticos, a sua animacao e a qualidade geral da representacao.
Configurabilidade: Capacidades de gestao de configuracoes (criacao ou modificacao,
estatica ou dinamicamente).
Expansibilidade: Possibilidades de expansao do sistema (escalabilidade, suporte a
heterogeneidade).
Adaptabilidade: Possibilidades de adaptacao a novos produtos e possibilidades de
evolucao.
Comunicacao: Tipos de redes ou interfaces (Ethernet, Token Ring, Token Bus, portas
serie e paralela) e protocolos suportados (TCP/IP, Novell, NetBIOS, MAP,
DECnet, Arcnet, DDE, NetDDE, Dedicados).
Compatibilidade: Interaccao com bases de dados (DBASE IV, ORACLE, Ingres, Infor-
mix, Sybase, WIN-Access), folhas de calculo (Lotus, Excel, MultiPlan) e aplica-
coes desenvolvidas pelo utilizador (em linguagem C ou Pascal, por exemplo).
Sistemas operativos: Suporte para os sistemas operativos mais divulgados: MS-DOS,
WINDOWS, OS/2, SunOS, HP-UX, VMS, SCO-UNIX, AIX.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 13
A tabela 2.2 sintetiza, de acordo com a reparticao tematica proposta, as carac-
terısticas dos quatro sistemas SCADA que foram escolhidos como objecto de estudo.
O aprofundamento de cada um destes temas sera materia das seccoes seguintes.
No entanto, dedicaremos ainda algum espaco a discussao de uma caracterıstica que se
revelou constante nos diversos sistemas SCADA estudados. Referimo-nos a estrutura-
cao modular dos SCADA.
2.3 A Modularizacao dos Sistemas
No estudo que efectuamos, registamos a tendencia para a apresentacao dos
sistemas SCADA como pacotes de software constituıdos por diversos modulos, muitas
vezes independentes. A modularidade apresentada e efectiva, e revela-se no facto de
as diversas aplicacoes ou funcionalidades suportadas por um determinado sistema
estarem agrupadas em modulos, os quais serao ou nao utilizados de acordo com o
criterio do utilizador e de acordo com os requisitos do sistema de controlo.
Este tipo de abordagem flexibiliza consideravelmente a instalacao e a configuracao
do sistema SCADA. Permite tambem melhorar alguns parametros com importancia
em sistemas deste tipo, tais como o desempenho e a facilidade de utilizacao. A
modularizacao traduz-se numa maior facilidade de utilizacao dado que, por um lado,
permite uma maior especializacao com consequente ganho de rendimento e, por outro
lado, gracas a clara definicao das interfaces entre os diversos modulos, nao impede a
congregacao dos esforcos separados na concretizacao de um sistema coerente.
Como exemplos de sistemas que fazem da modularizacao um argumento para a
sua valorizacao podemos salientar o EasyMAP, o FactoryLink e o InTouch. Tipica-
mente, funcionalidades tais como a criacao de receitas, o controlo estatıstico, a edicao
de sinopticos, a comunicacao entre aplicacoes (DDE) e a simulacao, sao apresentadas
como modulos separados.
A modularizacao tem tambem consequencias do ponto de vista economico. Nor-
malmente, os sistemas apresentam determinados modulos como componentes total-
mente separados do sistema de base, os quais apenas terao de ser adquiridos quando
necessario. Por outro lado, aproveitando as interfaces de compatibilidade oferecidas
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 14
AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA
AAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AAAAAAAA
AA
Sistemas SCADAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA
AAAA
AAAAAAAAAAAAAAAAAAAAAFactoryLink IV EasyMAP Processyn InTouch
Aplicações • Controlo de Célula• Supervisão e Aquisição de
dados• Controlo da Qualidade• Controlo de processos
contínuos e discretos• Controlo Distribuído
• Controlo de Célula• Gestão de Alarmes• Gestão e Controlo da
Produção• Supervisão e Aquisição de
dados• Controlo da Qualidade• Instrumentação
• Supervisão• Controlo de Célula• Gestão da Produção• Controlo da Qualidade• Simulação• Teste Automático
• Interfaces de Operação• Aquisição de dados• Controlo e Supervisão• Gestão de Alarmes• Controlo da Qualidade
Funcionalidades Interfaces:• Sinópticos• Curvas de Tendência• Alarmes• Gráficos Estatísticos• Gestão de Receitas
Computação:• Funções Lógicas e
Matemáticas• Processamento Estatístico• Programação em C e C++
Execução:• Eventos• Contadores• Relatórios• Históricos• Passwords
Interfaces:• Sinópticos• Alarmes• Curvas de Tendência• Gestão de Receitas
Computação:• Linguagem de Controlo
Sequencial• Programação em C• Lógica Fuzzy
Execução:• Históricos• Eventos• Relatórios• Passwords
Interfaces:• Sinópticos• Curvas de Tendência• Alarmes• Gráficos de barras
Computação:• Tratamentos específicos• Programação em Microsoft
C, Pascal ou MacroAssembler
Execução:• Históricos• Eventos• Receitas• Relatórios• Estatísticas• Cronómetros• Passwords
Interfaces:• Sinópticos• Curvas de Tendência• Alarmes• Gestão de Receitas• Gráficos Estatísticos
Computação:• Processamento Estatístico• Expressões Lógicas e
MatemáticasExecução:
• Históricos• Eventos• Relatórios• Passwords
Capacidade Memória disponível Memória disponível Memória disponível ou 65535variáveis
64, 128, 256 ou 32767variáveis
Visualização • X Windows• Microsoft Windows• Presentation Manager• DEC Windows
• Presentation Manager • CGA (320x200x4)• EGA (640x350x16)• VGA (640x480x16)• GALAXY, MERCURY
(1024x768x16)
• Microsoft Windows
Configuração Utilização de interfacesgráficas e recurso aprogramação.
Utilização de interfacesgráficas e recurso aprogramação.
Editores gráficos, semi--gráficos e Editores de texto.
Programação.
Interfaces Gráficas.
Comunicação Redes:• Ethernet• Token Ring• MAP
Protocolos:• DECnet• MMS• NetBIOS• TCP/IP
Redes:• Ethernet• Token Ring• Token Bus• MAP
Protocolos:• MMS• LAN Manager• NetWare
Redes:• Ethernet• Token Ring
Protocolos:• NetBIOS• MS-NET
Redes:• Ethernet• Token Ring
Protocolos:• DECnet• NetBIOS• NetWare• TCP/IP• Série/Modem
Compatibilidade Bases de dados:• dBASE IV• IBM Database manager• Ingres• ORACLE• Rdb/VMS• SYBASE
Aplicações:• Interface DDE
Bases de dados:• ORACLE
Aplicações:• Interface DDE
Bases de dados:• dBASE IV
Aplicações:• Formatos Standard
Aplicações:• Interface DDE
Interface comdispositivos
• Larga gama de drivers• Plataforma para
desenvolvimento de novosdrivers
• Plataforma paradesenvolvimento deGateways entre a interfaceMMS e protocolosproprietários
• Larga gama de drivers • Larga gama de servidoresDDE
• Plataforma paradesenvolvimento deservidores DDE
Plataformas • Windows e NT• OS/2• VMS• AIX• HP-UX• OSF/1• SCO Open Desktop
• OS/2 • MS-DOS• OS/2
• Windows
Tabela 2.2: Caracterısticas principais dos sistemas SCADA estudados.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 15
pelos sistemas SCADA para acesso aos dados, e possıvel realizar tarefas de calculo ou
de apresentacao de graficos utilizando aplicacoes externas. Esta utilizacao de aplica-
coes previamente disponıveis comporta nao so benefıcios economicos mas tambem a
nıvel da utilizacao para os utilizadores com conhecimento dessas aplicacoes.
A decomposicao modular dos sistemas SCADA permite racionalizar o esforco
despendido na sua configuracao. Um bom exemplo deste facto pode ser ilustrado pela
decomposicao das funcionalidades relativas a edicao de sinopticos em dois modulos.
Um dos modulos permite a criacao e gestao de sımbolos graficos que sao armazenados
numa base de dados para posterior utilizacao e o outro permite a criacao e edicao
de sinopticos construıdos por composicao dos sımbolos existentes na base de dados.
Neste exemplo cada modulo tem uma funcao especıfica bem determinada. A cria-
cao de sımbolos e normalmente necessaria apenas na instalacao do sistema, ao passo
que a edicao dos sinopticos sera provavelmente realizada sempre que se verifique
alguma alteracao do sistema supervisionado. Faz portanto sentido separar estas
funcionalidades em dois modulos distintos.
Ao nıvel da comunicacao, quer com os dispositivos industriais, quer com outras
entidades ligadas a rede, a modularizacao do sistema e tambem vantajosa. Cada
modulo de comunicacao concretiza os servicos especificados numa interface para um
determinado protocolo ou rede, isolando a dependencia do sistema relativamente ao
suporte de comunicacao utilizado. Por outro lado, se a interface entre os modulos
de comunicacao e o SCADA for aberta, e ainda possıvel, utilizando ferramentas
apropriadas, desenvolver novos modulos, por exemplo, para comunicacao atraves de
protocolos proprietarios.
Alguns SCADA suportam multiplos sistemas operativos. A este nıvel, a modula-
rizacao no contexto aplicacional nao comporta vantagens evidentes. No entanto, no
contexto da arquitectura de software, a modularizacao e um aspecto fundamental, de-
terminante em termos de portabilidade do codigo.
Finalmente, nao podıamos deixar de referir as vantagens da modularizacao
do ponto de vista da evolucao do sistema. Dado que os modulos sao blocos
independentes, e possıvel melhora-los ou mesmo substituı-los por novos modulos sem
que isso afecte o funcionamento dos outros modulos ou de outras aplicacoes. A evolu-
cao do sistema pode, portanto, ser gradual.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 16
Uma possıvel desvantagem da modularizacao prende-se com questoes de desem-
penho. Em comparacao com solucoes de software integrado, onde todas as funcionali-
dades sao realizadas num unico bloco, e natural que se note um menor desempenho
das solucoes modulares.
Em seguida apresentamos uma analise das funcionalidades e das aplicacoes mais
comuns encontradas nos sistemas SCADA.
2.4 Aplicacoes e Funcionalidades
As empresas que comercializam os sistemas SCADA apresentam-nos atraves da
indicacao das suas caracterısticas principais, explicitando os requisitos de hardware,
de software e as funcionalidades oferecidas. Optamos por nao seguir uma logica
semelhante, pois pensamos ser mais frutuoso explorar o significado e a necessidade
das funcionalidades mais comuns, dando apenas indicadores das grandezas relativas
a diversidade e qualidade das concretizacoes. A prova do que acabamos de dizer pode
ser obtida por inspeccao da tabela 2.2. Como pode ser observado existe uma grande
uniformidade em termos das funcionalidades oferecidas, o que reforca a nossa opcao
estrategica de abordar o problema numa perspectiva tematica. A analise individual de
cada SCADA seria certamente muito repetitiva.
Vimos na seccao anterior que algumas funcionalidades oferecidas pelos sistemas
SCADA sao realizadas por modulos de software independentes. No entanto, como foi
tambem referido, as funcionalidades basicas, essenciais para a construcao de um sis-
tema de supervisao, estao incorporadas num unico modulo, normalmente o modulo
principal do SCADA. O texto que se segue tracara uma panoramica muito alargada
de funcionalidades comummente suportadas pelos sistemas SCADA, independente-
mente da forma como nos sao apresentadas: como modulos, como aplicacoes inde-
pendentes ou simplesmente como opcoes em menus de escolha multipla.
2.4.1 Configuracao do Sistema
No seu sentido mais lato, um sistema de supervisao e composto por diversos
componentes que devem ser configurados, e que podem ser agrupados de acordo
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 17
com a parte do sistema a que dizem respeito. Referimo-nos, entre outros, ao meio de
comunicacao, aos dispositivos fabris, a infraestrutura computacional e aos perifericos.
Nesta seccao iremos apenas descrever os aspectos que dizem respeito a configura-
cao do proprio SCADA, ou seja, do software de supervisao. Na seccao 2.7 serao
entao abordados os aspectos relativos a configuracao mais generica de um sistema de
supervisao. Aı sera tambem exposta a nossa visao crıtica relativamente as capacidades
de configuracao dos diferentes SCADA.
Todos os sistemas SCADA possuem ferramentas que de alguma forma permitem
facilitar as tarefas de configuracao. Fazendo um esforco de sistematizacao, poderemos
considerar dois grupos basicos de ferramentas que se distinguem pelos objectivos a
que se destinam. Aquelas que permitem configurar variaveis e servicos globais ao
sistema e as que sao utilizadas na construcao e na configuracao das aplicacoes de
supervisao.
As variaveis globais do SCADA, que indicam nomes de ficheiros, determinam o
modo grafico ou caracterısticas sonoras, especificam formatos a utilizar ou nomeiam
servicos de rede, sao normalmente configuradas directamente a partir do programa
principal do SCADA. Este tipo de accoes de configuracao, bem como as ferramentas
que lhes estao associadas, sao pouco complexas e de importancia superficial no
contexto das tarefas de configuracao. Como tal nao lhes dedicaremos mais espaco.
A configuracao das aplicacoes de supervisao e uma tarefa bem mais complicada.
Engloba diversas accoes, tais como a definicao das variaveis que vao ser supervisiona-
das, a criacao dos sinopticos, o estabelecimento de associacoes entre objectos graficos e
variaveis, a definicao de alarmes e do tratamento a dar-lhes e a definicao de accoes de
processamento e arquivo de dados.
As solucoes propostas pelos diversos SCADA para a execucao destas tarefas nao
podem ser consideradas uniformes. O Processyn, por exemplo, oferece uma interface
semi-grafica de auxılio a programacao (semelhante a um editor), atraves da qual se
pode descrever o ciclo de processamento que sera realizado. A mesma interface e
tambem utilizada para descrever os sinopticos ou os graficos de tendencia. Todas
as descricoes sao baseadas numa linguagem especıfica que exige conhecimentos de
programacao.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 18
Em contraste com esta aproximacao, podemos citar o InTouch, sistema cuja filosofia
assenta fundamentalmente na simplicidade das interfaces e na ausencia de requisitos
de programacao. Este apresenta um ambiente grafico e uma metodologia de utiliza-
cao que tem por base o Microsoft Windows, revelando-se assim muito familiar para a
grande maioria dos utilizadores. A integracao das diversas ferramentas de definicao e
configuracao e tambem uma caracterıstica deste sistema.
Num ponto intermedio podemos ainda encontrar sistemas SCADA que, sem
desprezarem as vantagens da utilizacao de atraentes interfaces, permitem o recurso
a programacao e descentralizam as tarefas de configuracao e modelacao. Referimo-
-nos ao FactoryLink, que, fazendo juz a sua arquitectura muito modular, possui
modulos especıficos que suportam cada uma das funcionalidade do sistema (e que
sao configurados independentemente). Alguns modulos apresentam ferramentas de
configuracao baseadas no preenchimento de tabelas e na parametrizacao de variaveis,
como por exemplo os modulos de supervisao de alarmes e de carregamento de
receitas, ao passo que outros obrigam o utilizador a criar programas obedecendo a
uma linguagem propria, como e o caso do modulo de funcoes logicas e matematicas.
A informacao de configuracao e armazenada em ficheiros, normalmente em
formato binario, apenas legıveis pelo SCADA onde foram gerados. No entanto, alguns
sistemas utilizam bases de dados como meio preferencial para armazenamento da
informacao. Por exemplo, o EasyMAP utiliza uma base de dados ORACLE para
guardar a informacao relativa aos elementos graficos que compoem os sinopticos.
Alguns sistemas permitem a criacao de multiplas configuracoes para um determi-
nado componente (por exemplo, podem criar-se diversos sinopticos que diferem ape-
nas nas cores utilizadas), sendo seleccionada durante a execucao a configuracao mais
adequada de cada componente.
A configuracao do sistema de supervisao deve iniciar-se pela definicao das
variaveis que serao supervisionadas. De uma forma simplista, pode dizer-se que tal
definicao corresponde a atribuicao de nomes as variaveis existentes nos dispositivos
acedidos. Em concreto, deverao definir-se pontos de acesso ao dispositivo, utiliza-
dos nas accoes de comunicacao para atribuicao de valores as variaveis. Um ponto de
acesso pode ser visto como uma entidade que apenas possui a informacao para ace-
der a uma determinada variavel num dispositivo, nao tendo autonomia para decidir
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 19
quando deverao ser executadas accoes de leitura ou escrita. Estas accoes so serao reali-
zadas quando tal for solicitado por outras entidades do sistema. E possıvel definir di-
versos pontos de acesso associados ao mesmo gestor de dispositivo: o gestor conhece
os detalhes especıficos do protocolo de comunicacao com o dispositivo e o ponto de
acesso fornece os dados que permitem enderecar uma determinada variavel.
No EasyMAP um ponto de acesso tem de descrever uma variavel MMS, ou seja,
tem de indicar o VMD� que a disponibiliza, o nome pelo qual e referenciada nesse
VMD e o seu tipo. No Processyn, os pontos de acesso sao definidos nos modulos de
interface aos dispositivos, e contem informacao que dependente do modulo utilizado.
Por exemplo, num modulo de interface a um PLC, um ponto de acesso tera de indicar
um endereco do PLC. No caso do InTouch, como a interface aos dispositivos e realizada
por servidores dedicados que sao acedidos por DDE, um ponto de acesso tera de
conter a indicacao do servidor a utilizar. No FactoryLink, o acesso aos dispositivos
e realizado atraves do modulo EDI (External Device Interface), que e mais do que uma
simples interface como nos casos anteriores. Como foi referido na seccao 2.1.2, todos
os modulos deste SCADA comunicam entre si atraves da base de dados de tempo-real.
Assim, a leitura ou escrita de variaveis dos dispositivos, realizada pelo modulo EDI, e
implicitamente comandada pelas aplicacoes de supervisao atraves da modificacao de
variaveis nessa base de dados. Cada ponto de acesso tem de definir nao so o endereco a
aceder no dispositivo, mas tambem as variaveis que determinam a execucao de leituras
e escritas e ainda a variavel da base de dados que sera utilizada na transferencia.
Durante a definicao das diversas aplicacoes que constituem o sistema, a referencia
a uma determinada variavel sera feita sempre atraves do mesmo nome, que aponta
para uma entrada na base de dados de tempo-real, em memoria. Assim, o numero
maximo de variaveis que se podem definir numa sistema de supervisao sera limitado,
na pior das hipoteses, pela dimensao maxima da base de dados. Contudo, alguns
SCADA limitam explicitamente o numero maximo de pontos de acesso que podem
ser definidos, no intuito de obter lucros do ponto de vista comercial. O custo destes
sistemas e funcao do numero maximo de pontos de acesso disponibilizados.
Apos a definicao das variaveis pode iniciar-se a construcao dos sinopticos e a confi-
�Virtual Manufacturing Device— Nos ambientes de comunicacao por MMS os dispositivos saorepresentados por VMDs, entidades virtuais que disponibilizam o estado do dispositivo, atraves dasquais se processa a comunicacao.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 20
guracao das diversas aplicacoes e funcionalidades de supervisao. Nao continuaremos
aqui a descrever as particularidades da configuracao de cada uma delas, dado que isso
sera feito nas seccoes que as descrevem.
Para finalizar, sera interessante referir a incapacidade de configuracao dinamica
que se verifica em todos os sistemas. Queremos com isto dizer que nao e possıvel
modificar o comportamento do sistema durante a sua execucao, quer ao nıvel da defini-
cao de variaveis, quer mesmo ao nıvel das accoes realizadas. O que e possıvel fazer,
mas apenas em alguns sistemas, e activar ou desactivar a execucao de determinadas
aplicacoes, por exemplo aplicacoes de deteccao de eventos ou coleccao de dados. No
Processyn, o metodo de construcao das aplicacoes, por conter uma fase de geracao
da aplicacao, impede totalmente a activacao de modulos isolados durante a execucao.
Neste sistema, a modificacao de apenas um modulo implica a reconstrucao do sistema
na sua globalidade!
2.4.2 Controlo de Acesso
Quase todos os SCADA estudados permitem a distribuicao de aplicacoes de super-
visao por varias entidades do sistema espalhadas numa rede local. E assim natural que
existam multiplos utilizadores com acesso ao sistema SCADA, eventualmente com res-
ponsabilidades especıficas no respeitante a manutencao e a interaccao com as diversas
aplicacoes de supervisao.
As funcionalidades para controlo de acessos permitem limitar o acesso de utili-
zadores a determinadas partes do sistema, ou ao sistema na sua totalidade. A mais
simples das proteccoes consiste na obrigatoriedade de introducao de uma senha para
inicializacao do sistema. Outros tipos de proteccao consistem, por exemplo, na de-
finicao de nıveis de acesso ou na definicao de operacoes condicionais. Neste ultimo
caso, a condicao para a realizacao de uma operacao pode consistir, simplesmente, na
introducao de uma senha.
No EasyMAP e no InTouch, as funcoes do controlo de acesso permitem a distin-
cao de utilizadores e consequente atribuicao individual de privilegios. No Processyn,
como o sistema e baseado na execucao sequencial de instrucoes, a definicao de protec-
coes de acesso torna-se relativamente simples, bastando que sejam introduzidas instru-
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 21
coes de introducao e validacao de senhas. De certa forma, este tipo de proteccao
corresponde a definicao de operacoes condicionais. O FactoryLink, pelo facto de poder
ser executado em plataformas UNIX, admite que a validacao de utilizadores seja feita
atraves dos mecanismos proprios do sistema operativo ou do sistema de ficheiros.
Assim, a inicializacao do SCADA estara implicitamente protegida. Durante a execu-
cao, o FactoryLink pode tambem utilizar operacoes condicionais, tal como nos outros
sistemas.
2.4.3 Gestao da Execucao
Apenas alguns sistemas SCADA possuem uma arquitectura assente na defini-
cao e na execucao de modulos de supervisao e controlo independentes. So nestes
faz portanto sentido falar de aplicacoes cuja funcao e gerir a execucao dos modulos
definidos. Os sistemas FactoryLink e EasyMAP podem ser englobados nesta categoria.
Estes dois sistemas sao ainda representativos do panorama geral dos SCADA no
respeitante a forma como a gestao de modulos e realizada. O FactoryLink possui
um modulo dedicado exclusivamente as tarefas de gestao da execucao dos outros
modulos, enquanto que o EasyMAP incorpora as mesmas funcionalidades no modulo
principal.
A utilidade principal desta funcionalidade e permitir a activacao ou desactivacao
de modulos ou aplicacoes definidas. Permite, paralelamente, a monitorizacao do seu
estado de actividade, bem como a visualizacao de outras informacoes que lhes sao
relativas, tais como nomes de ficheiros ou utilizadores.
Convem referir, no entanto, que as versoes de Run-Time, apesar de nao incluırem
as ferramentas que permitem o desenvolvimento das aplicacoes, tem obrigatoriamente
de possuir um mecanismo para o seu lancamento.
2.4.4 Monitorizacao
A monitorizacao e uma funcionalidade que consiste na visualizacao do valor de
determinadas variaveis, a pedido do utilizador, paralelamente a execucao do sistema.
Na pratica, nao e obrigatoria a existencia de um modulo especıfico para realizar esta
funcionalidade, dado que ela e implicitamente realizada por outros modulos. Apesar
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 22
disso, o FactoryLink dispoe de um modulo especialmente vocacionado para este efeito.
Nos SCADA que nao dispoem de opcoes explıcitas para monitorizar variaveis, e
sempre possıvel reservar uma zona do sinoptico para visualizar a evolucao do valor de
determinadas variaveis. So nao sera possıvel, durante a execucao, monitorizar outras
variaveis que nao as escolhidas. A alteracao de variaveis e tambem permitida, pelo
mesmo processo, e com as mesmas restricoes.
Gracas a esta funcionalidade, pode testar-se a execucao de uma aplicacao, con-
frontando o valor das variaveis inspeccionadas com o comportamento da aplicacao
face a esse valor. Podem ainda realizar-se simulacoes, por imposicao dos valores das
variaveis.
2.4.5 Sinopticos
Os sinopticos constituem o meio mais eficaz de apresentacao dos dados dos
processos supervisionados. Atraves de um sinoptico pode captar-se rapidamente a
informacao mais relevante do sistema, qualquer que seja o tipo de aplicacao. Tal
eficiencia deriva da representacao grafica dos dispositivos supervisionados, e da
utilizacao de cores, sons, padroes a animacoes graficas.
Todos os sistemas estudados possuem editores graficos para o desenvolvimento
de sinopticos. Com estes editores e possıvel desenhar todo o tipo de objectos, escolher
cores, tamanhos, padroes e outros atributos, e ainda dispor de funcoes de duplica-
cao de objectos, simetria, rotacao, ampliacao, alinhamento e outros. Os objectos mais
comuns, tais como valvulas, interruptores, tanques, canalizacoes ou tapetes rolantes
sao disponibilizados em bibliotecas de objectos. Naturalmente, todas as tarefas de
desenho sao realizadas utilizando um dispositivo apontador.
Apesar das diferencas entre os diversos editores serem reduzidas, o metodo de
animacao dos objectos graficos nao e sempre o mesmo. Enquanto que no Processyn
existe um modulo que indica as accoes de animacao de um sinoptico, as quais sao
descritas atraves de uma sintaxe especıfica, nos outros sistemas as caracterısticas de
animacao de um objecto sao determinadas pelo preenchimento de tabelas.
O tipo de funcoes de animacao varia, igualmente conforme o SCADA utilizado.
Na seccao 2.6 este assunto sera tratado com maior detalhe.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 23
2.4.6 Temporizacoes
Esta funcionalidade, muito importante no contexto das aplicacoes de supervisao, e
necessaria, por exemplo, para a aquisicao cıclica de dados na construcao da historia de
um processo ou para executar accoes de controlo distribuıdas e sincronizadas.
Uma temporizacao consiste na definicao de um valor temporal, medido no
relogio do computador, que, quando atingido, ira desencadear a execucao de uma
determinada accao ou a sinalizacao de uma variavel. O valor temporal pode tambem
referir-se a um intervalo de tempo e nao a um valor absoluto. Neste caso, e ainda
possıvel optar-se por reactivar a temporizacao, de modo a que esta seja cıclica.
De uma forma geral, esta funcionalidade nao e explicitamente oferecida por
nenhum sistema SCADA, sendo o FactoryLink a excepcao a regra. Na verdade, a
situacao mais vulgar corresponde a uma utilizacao implıcita de temporizacoes, que
sao geradas pelo proprio sistema. Estas temporizacoes implıcitas sao utilizadas para
a leitura cıclica dos dados dos processos, e consequente actualizacao de sinopticos,
graficos e outro tipo de informacao.
Tal como foi dito, o FactoryLink foge a esta regra, dado que possui um modulo
dedicado a definicao de temporizacoes, bem como um modulo de contadores que pode
ser utilizado para fins semelhantes. A existencia destes modulos e apenas possıvel
devido a arquitectura deste sistema, baseada na existencia de uma base de dados
central, acessıvel por todos os modulos.
O Processyn tambem oferece um mecanismo que, de certa forma, pode permitir
a definicao de temporizacoes. Este mecanismo consiste na definicao de cronometros
e metronomos, que, durante a execucao cıclica do sistema, podem ser testados como
condicao para execucao de accoes.
2.4.7 Coleccao de dados
A funcionalidade de coleccao de dados e imprescindıvel na concretizacao de um
sistema de supervisao. Ela e utilizada com duas finalidades basicas, materializadas na
construcao de historicos dos processos e na actualizacao das interfaces graficas.
A sobreposicao das duas finalidades nao implica, no entanto, a duplicacao do
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 24
numero de acessos aos dispositivos. O que acontece e que a leitura de uma variavel
e aproveitada simultaneamente para actualizar os graficos e para produzir os dados
historicos. No caso dos sistemas que integram estas funcionalidades no modulo prin-
cipal, esta gestao e feita internamente, nao sendo da responsabilidade do utilizador.
No caso do FactoryLink, a configuracao do modulo de geracao de dados historicos
tem de ser feita em sincronia com a configuracao das temporizacoes para coleccao de
dados, ou seja, as variaveis que determinam a realizacao de novas leituras tem de ser as
mesmas que determinam a escrita de dados na base de dados historica. No Processyn,
como e o utilizador quem descreve as accoes a realizar pelo sistema, este podera incluir
instrucoes de escrita de dados em ficheiros de dados historicos, apos cada aquisicao de
dados.
Tanto no EasyMAP como no FactoryLink, os dados historicos sao registados em
bases de dados relacionais. O segundo sistema e contudo mais flexıvel no sentido
em que permite a utilizacao de diversas bases de dados, enquanto que o EasyMAP se
restringe a utilizacao de bases de dados ORACLE.
No InTouch, a criacao de dados historicos e realizada em simultaneo com a produ-
cao de graficos de tendencia. A definicao destes graficos permite especificar operacoes
de registo em ficheiros ou bases de dados.
2.4.8 Alarmes e Eventos
A utilizacao de alarmes para deteccao e aviso de situacoes anormais, e uma
funcionalidade disponıvel em todos os SCADA. A configuracao dos alarmes segue
sempre o mesmo princıpio: e necessario referenciar a variavel que sera monitorizada e
indicar as condicoes activadoras do alarme.
As condicoes mais comuns de activacao consistem nas igualdades e desigualdades
matematicas, no valor booleano e na alteracao de valor. Outras condicoes menos
comuns sao a passagem por valor e a taxa de variacao.
Alguns sistemas permitem atribuir prioridades aos alarmes. Por exemplo, o
InTouch permite utilizar ate 999 prioridades distintas e o FactoryLink ate 99. No
Processyn, como a actividade do sistema e determinada pela execucao sequencial das
instrucoes, nao faz sentido falar em prioridades dos alarmes.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 25
Relativamente as accoes realizadas aquando da ocorrencia de alarmes, todos os
sistemas permitem o seu registo em memoria estavel durante a execucao. Estes registos
podem ser consultados posteriormente, como fazendo parte da historia dos processos.
Outras accoes que podem ser realizadas consistem na afixacao de mensagens em
janelas de alarmes ou na producao de relatorios directamente para impressoras.
A definicao de alarmes pode ser utilizada em conjugacao com funcionalidades de
controlo estatıstico dos processos. Por exemplo, no InTouch e possıvel definir alarmes
cujas condicoes de activacao consistem nos limites dos valores da qualidade impostos
no modulo de controlo estatıstico. Se um determinado limite for violado, sera activado
o alarme correspondente.
2.4.9 Graficos de Tendencia
Os graficos de tendencia que, a par dos sinopticos, sao um dos instrumentos mais
importantes dos sistemas SCADA, permitem visualizar a evolucao temporal do valor
de uma ou varias variaveis, fornecendo uma visao clara da tendencia evolutiva do
processo, tornando por isso possıvel detectar, num curto espaco de tempo, situacoes
de evolucao anormais que requerem medidas correctivas.
A configuracao destes graficos comporta nao so a indicacao das variaveis visuali-
zadas como tambem os valores maximos e mınimos atribuıdos ao eixo das variaveis.
Eventualmente pode ser necessario indicar o sentido de desenho das curvas, as cores e
outros parametros visuais.
Todos os sistemas, com excepcao do Processyn, permitem a visualizacao de
graficos de tendencia de dados historicos. Esta funcionalidade pode ser muito util para
efeitos de comparacao da evolucao actual com a tendencia registada ao longo de um
largo espaco de tempo. Na configuracao deste tipo de graficos poderao ser indicados
os valores inicial e final do espaco temporal a visualizar.
Os graficos de tendencia, para alem de poderem ser visualizados em janelas
individuais, podem ser utilizados como objectos, incorporados num sinoptico do
sistema e animados pelas variaveis cujo valor se pretende monitorizar.
A frequencia de amostragem utilizada para produzir estes graficos relaciona-se
com as temporizacoes definidas para a coleccao de dados (seccao 2.4.7). Assim, no
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 26
InTouch e no Processyn nao e possıvel alterar esta frequencia. No EasyMAP e possıvel
escolher uma das frequencias disponıveis numa lista de opcoes e no FactoryLink e
utilizado o modulo de temporizacoes (seccao 2.4.6).
Finalmente, relembramos que no InTouch a producao dos dados historicos dos
processos e realizada em paralelo com a visualizacao de graficos de tendencia.
2.4.10 Receitas
A funcionalidade de criacao e carregamento de receitas e utilizada para automa-
tizar os procedimentos de configuracao dos proprios processos industriais. De certa
forma pode considerar-se que esta e uma funcionalidade estritamente de controlo dos
processos, dado que determina o seu modo de funcionamento. Normalmente, uma re-
ceita e carregada num dispositivo antes deste ser posto em execucao e funciona como
uma inicializacao. Uma receita pode consistir, por exemplo, num programa que sera
executado ou num conjunto de valores que indicam a quantidade de cada ingrediente
que sera utilizado no processo de fabrico.
A criacao de receitas e uma tarefa normalmente simples, dado que e feita atraves
do preenchimento de formularios e nao requer conhecimentos de programacao. Cada
receita e guardada num ficheiro individual, sendo por isso possıvel criar tantas receitas
quanto o espaco disponıvel no disco. Em alguns sistemas a edicao de receitas pode
tambem ser feita em editores externos ao sistema, dado que o formato dos ficheiros,
nestes casos, nao e binario. No Processyn esta e, alias, a unica forma de criar receitas.
Uma caracterıstica importante desta funcionalidade e a possibilidade de carrega-
mento de receitas como resposta a eventos gerados no sistema e nao apenas por deter-
minacao do utilizador.
2.4.11 Gestao de Ficheiros
A capacidade de gerir ficheiros nao e, em princıpio, um atributo dos sistemas de
supervisao. No entanto, dado que ela existe nos sistemas Processyn e FactoryLink,
pensamos ser necessario referı-la. Note-se que apenas se justifica a existencia de
funcionalidades de gestao de ficheiros pelo facto de elas poderem ser realizadas
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 27
durante a execucao do sistema, na consequencia de eventos ou da deteccao de alarmes.
As funcionalidades oferecidas permitem realizar as operacoes habituais com
ficheiros, ou seja, visualizar o conteudo, imprimir, copiar, remover ou modificar o seu
nome.
2.4.12 Processamento de Dados
O processamento de dados consiste na realizacao de operacoes logicas e ma-
tematicas sobre os dados supervisionados. Os valores obtidos podem ser utilizados
por aplicacoes de supervisao ou armazenados em ficheiros para posterior consulta
e tratamento por outras aplicacoes. Por exemplo, e possıvel definir animacoes num
sinoptico ou condicoes de alarme baseadas em dados processados.
Relativamente a forma como e feita a expressao das operacoes de processamento
encontram-se muitas diferencas entre os diversos SCADA. O sistema mais versatil e
o FactoryLink, pois permite nao so definir operacoes que sao interpretadas durante
a execucao, como permite tambem a utilizacao de funcoes compiladas, escritas em
linguagem C. Neste sistema o tratamento das operacoes e feito por um modulo de fun-
coes logicas e matematicas que existe nas versoes interpretada e compilada. A defini-
cao das operacoes pode ser feita, independentemente da versao, numa linguagem
proprietaria, semelhante ao BASIC mas mais estruturada. Na versao compilada, o
codigo definido nesta linguagem e previamente traduzido para linguagem C.
O EasyMAP possui uma aplicacao que permite executar programas escritos
numa linguagem propria para controlo sequencial— a linguagem ALL, Algorithmic
Language. Na verdade, esta funcionalidade nao esta directamente relacionada com
o processamento de dados, mas dado que permite realizar algumas funcoes de
processamento relacionadas com o controlo sequencial de dispositivos, pensamos ser
importante referı-la aqui. Como complemento a esta aplicacao, o EasyMAP propoe
a utilizacao de aplicacoes externas para processamento de dados, especificamente o
EXCEL, disponibilizando os mecanismos adequados para tal utilizacao.
No InTouch a funcionalidade de processamento de dados e permitida atraves da
definicao de scripts de accoes. Estas accoes, que consistem na realizacao de calculos e
simulacoes sobre os dados do sistema, podem ser invocadas quer por accao directa do
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 28
operador do sistema, quer como resultado de eventos tais como a mudanca de estado
de variaveis, a ocorrencia de alarmes ou a abertura de janelas.
No Processyn e igualmente possıvel executar accoes de processamento de dados.
Neste sistema, para alem das normais funcoes logicas e matematicas, sao ainda
disponibilizadas funcoes de conversao de valores, de formatacao e de teste evolutivo
de valores.
Convem referir a importancia das funcionalidades de processamento de dados
para a definicao de eventos e alarmes. De facto, e frequente a necessidade de definir
condicoes de alarme que resultam de dados processados sendo assim relevante a
possibilidade de interligar estas duas funcionalidades.
2.4.13 Processamento Estatıstico
O processamento estatıstico nao deve ser considerado apenas como uma extensao
ao processamento matematico descrito na seccao anterior. Na verdade, a possibilidade
de realizar operacoes de calculo estatıstico e determinante para a construcao de aplica-
coes de gestao, de planeamento da producao e de controlo da qualidade, entre outras.
A importancia desta funcionalidade e evidente nos SCADA estudados, pois a sua
utilizacao implica normalmente custos adicionais pelo facto de nao ser incluıda no
software basico e ter de ser adquirida separadamente. Esta situacao e particularmente
notoria no caso do InTouch.
O controlo estatıstico dos processos e fundamental para a obtencao de dados sobre
o comportamento do processo produtivo e para o controlo da qualidade. As indica-
coes que podem ser obtidas atraves da comparacao dos dados estatısticos com padroes
previamente estabelecidos servem para orientar e melhorar todo o processo produtivo.
As accoes de processamento estatıstico podem ser efectuadas em tempo-real sobre
dados do processo ou entao sobre dados provenientes de bases de dados historicas.
Neste ultimo caso e possıvel realizar o controlo estatıstico em diferido com a coleccao
e supervisao dos dados, e ate de uma forma distribuıda.
No InTouch esta funcionalidade permite a apresentacao de dados estatısticos sob a
forma grafica atraves de histogramas, graficos do desvio padrao e outros.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 29
O FactoryLink tem um modulo de controlo estatıstico de processos muito com-
pleto, proporcionando uma vasta gama de tipos de graficos. A tıtulo de exemplo po-
demos mencionar os seguintes tipos: Media, Mediana, Desvio padrao, Media em des-
locamento e Histograma. O funcionamento deste modulo segue os mesmos princıpios
que todos os outros, ou seja, baseia-se em interaccoes com a base de dados de tempo-
real do sistema atraves do Open Software Bus.
O EasyMAP, tal como para o processamento matematico, propoe a utilizacao do
EXCEL para realizacao de processamento estatıstico dos dados.
2.4.14 Relatorios
A funcionalidade de producao de relatorios nao e muito relevante. Na verdade,
consiste na disponibilizacao de uma forma auxiliar de apresentacao dos dados,
normalmente mais condensada, fundamentalmente a base de tabelas ou quadros.
Os relatorios podem ser produzidos sob a forma visual (no ecran) ou escrita (na
impressora).
No caso do InTouch e possıvel configurar a forma como o relatorio sera apresen-
tado, utilizando ferramentas graficas para tal disponibilizadas. No Processyn e apenas
possıvel produzir tabelas com um formato fixo.
2.5 Capacidades de Representacao e Manipulacao de da-dos
A reserva de espaco em memoria para armazenamento das variaveis, implica a
caracterizacao do tipo de dados que lhes estarao associados. Os tipos admitidos pela
generalidade dos SCADA sao basicamente quatro: Boleano, Inteiro, Real e Mensagem
(sequencia de caracteres). A excepcao digna de referencia e o EasyMAP, sistema que,
pelo facto de assentar a sua estrutura de comunicacao no protocolo MMS, considera
como tipos admissıveis para as variaveis todos os que estao definidos nesse protocolo.
Durante a execucao das aplicacoes, os diversos sistemas SCADA guardam os va-
lores das variaveis numa base de dados interna, em memoria, denominada por vezes
como base de dados de tempo-real. Dado que a gestao desta base de dados e de im-
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 30
portancia fulcral no desempenho global do sistema, todos os SCADAs revelam a preo-
cupacao de optimizar os mecanismos de actualizacao dos valores das variaveis. Antes
de descrevermos as optimizacoes normalmente efectuadas, e necessario salientar que
a leitura de variaveis dos dispositivos pode ser desencadeada com dois fins distintos:
� Para construcao de historicos do processo, sendo os dados registados em bases
de dados relacionais ou, simplesmente, em ficheiros;
� Para processamento imediato, com vista a actualizacao de sinopticos, graficos de
tendencia ou graficos de controlo estatıstico do processo.
Dado que a coleccao de dados para construcao de historicos do processo requer
um ritmo de aquisicao constante, as variaveis que definem o processo estao perma-
nentemente activas, ou seja, tem de ser constantemente actualizadas. No entanto,
as variaveis referenciadas por sinopticos ou por outras aplicacoes de caracterısticas
graficas, apenas estao activas se as aplicacoes que as referenciam estiverem grafica-
mente visıveis. Assim, a primeira optimizacao consiste na eliminacao de acessos des-
necessarios, ou seja, acessos para leitura de variaveis que nao estao activas. A se-
gunda optimizacao e conseguida gracas a deteccao das variaveis cujo valor foi alte-
rado: apenas estas sao transmitidas do gestor de dispositivo para a base de dados.
Desta forma consegue reduzir-se o tempo de processamento do sistema, com conse-
quentes benefıcios para o desempenho.
No que respeita as capacidades de manipulacao dos dados do ponto de vista apli-
cacional e importante reter os aspectos relativos ao seu processamento e armazena-
mento. Referimo-nos a diversidade de funcoes de processamento disponibilizadas e
aos formatos com que podem ser guardados os dados. Globalmente, nao registamos
diferencas assinalaveis quanto as capacidades de processamento. O mesmo nao se ve-
rifica relativamente as capacidades de armazenamento. Na verdade verifica-se que
tanto e possıvel encontrar sistemas que apenas disponibilizam uma interface mınima
de escrita em ficheiros (eventualmente utilizando algumas formatacoes especıficas
para determinadas aplicacoes), como sistemas que dispoem de interfaces para diversas
bases de dados, para alem da simples escrita em ficheiros.
De uma forma geral, pensamos que um sistema SCADA deveria apresentar as
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 31
seguintes caracterısticas no que diz respeito a capacidade de representacao e manipula-
cao de dados:
� Possibilidade de definir um numero ilimitado de variaveis (pelo menos virtual-
mente);
� Capacidade de manipulacao nao so de tipos basicos mas igualmente de tipos
compostos de variaveis (vectores e estruturas)— que pode ser util na comunica-
cao com determinados dispositivos, dado permitir a reducao da quantidade de
mensagens trocadas gracas ao agrupamento dos dados;
� Capacidade de armazenamento interno de variaveis para utilizacao simultanea
por multiplas aplicacoes— tendo como objectivo evitar a troca excessiva de
mensagens com os dispositivos, o que aconteceria se cada aplicacao gerasse um
pedido de leitura de variaveis independentemente das outras aplicacoes.
� Disponibilizacao de funcoes de processamento, em concreto de funcoes mate-
maticas, logicas e trigonometricas. Sera ainda conveniente a existencia de fun-
coes estatısticas basicas, tais como media, maximo, mınimo e desvio padrao.
� Possibilidade de armazenamento dos dados em ficheiros, utilizando formatos
compatıveis com aplicacoes comuns tais como EXCEL ou LOTUS.
2.6 Capacidades Graficas
As capacidades graficas dos sistemas SCADA sao extremamente importantes
do ponto de vista do utilizador. Na verdade, a interaccao do utilizador com o
sistema assenta fundamentalmente na observacao das aplicacoes de supervisao e
eventualmente na utilizacao de funcionalidades especıficas por exemplo para actua-
cao nos dispositivos.
De uma forma geral todos os sistemas estudados possuem capacidades graficas
suficientes para a construcao de sinopticos visualmente eficientes, embora alguns
fornecam um maior leque de opcoes graficas.
Ha fundamentalmente dois aspectos a considerar relativamente as capacidades
graficas dos SCADA: as capacidades de definicao de sımbolos estaticos e as capacida-
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 32
des de animacao. Relativamente a definicao dos sımbolos, as capacidades estao muito
condicionadas pelo editor grafico utilizado, ou seja, pelas ferramentas de edicao dis-
ponibilizadas. A este nıvel nao se registam diferencas assinalaveis entre os diversos
sistemas, ja que todos eles permitem o desenho dos elementos basicos (por exemplo,
linhas, arcos, caixas, polıgonos e texto) e possuem aproximadamente as mesmas fun-
coes de manipulacao dos objectos (por exemplo, copia, simetria, rotacao, alinhamento
e agrupamento).
As capacidades de animacao dos objectos sao relativamente diferentes nos diversos
SCADA estudados. Porem, antes de discutirmos estas diferencas, pensamos ser rele-
vante sumarizar as formas mais importantes de animacao que podem ser encontradas
num sistema SCADA.
Introducao de texto: Dados alfanumericos (por exemplo codigos ou passwords).
Afixacao de texto: Texto com fontes, cores e tamanhos variaveis.
Botoes: Execucao de accoes associadas a botoes.
Sımbolos: Utilizacao de objectos ou sımbolos para representar o valor de uma
variavel. Cada valor (ou gama de valores) esta associado a um sımbolo.
Graficos: Valores representados em graficos do tipo amplitude-versus-tempo ou
graficos de barras.
Barras: Valores representados atraves de barras de comprimento e cor variaveis.
Som: Producao de sons devido a modificacoes de valores.
Cor: Associacao da cor dos objectos ao valor das variaveis.
Tamanho: Associacao do tamanho, largura ou altura dos objectos a variaveis.
Posicao: Definicao da posicao dos objectos em funcao de variaveis.
Preenchimento: Definicao da percentagem de preenchimento dos objectos em funcao
de variaveis. Muito util para representar nıveis.
Rotacao: Definicao de angulos de rotacao em funcao de variaveis.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 33
Visibilidade: Tornar objectos visıveis ou invisıveis.
A introducao e a afixacao de texto e valores digitais ou analogicos e possıvel em
todos os sistemas. No Processyn, as variaveis analogicas podem ser representadas por
graficos de barras ou curvas de tendencia e as variaveis de texto podem ver os seus
atributos modificados. Neste sistema, o aspecto visual dos sinopticos depende em
grande medida da configuracao do gestor de ecran. Relembramos que este sistema
pode funcionar em plataformas MS-DOS, suportando por isso ele proprio as interac-
coes com o ecran. Nas versoes em OS/2, os gestores de vıdeo fazem parte da propria
plataforma, sendo o aspecto visual das aplicacoes sempre semelhante. De certa forma
pode dizer-se que em MS-DOS os sinopticos sao orientados ao pixel, ao passo que
em OS/2 e em Windows sao orientados a objectos. No caso do EasyMAP a defini-
cao dos graficos e tambem muito boa, dado que utiliza a interface grafica do OS/2, o
Presentation Manager.
No FactoryLink e de assinalar a coerencia do aspecto grafico dos sinopticos,
quando estes sao transportados para plataformas diferentes. Na verdade, e possıvel
criar sinopticos numa plataforma (por exemplo em OS/2) e posteriormente utiliza-los
noutras plataformas (por exemplo em UNIX, com interface grafica X-Windows).
Resta assinalar que, de uma forma geral, se encontram grandes deficiencias do
ponto de vista de representacao tridimensional dos objectos, tecnologia que sera
certamente incorporada em futuros produtos desta area.
2.7 Capacidades de Configuracao
A configuracao de um sistema SCADA e, como ja vimos, uma tarefa delicada.
A complexidade desta tarefa depende, para alem das ferramentas postas a disposi-
cao para executar as tarefas de configuracao, de factores como: a dimensao do
sistema a supervisionar (quantidade de dispositivos), o seu grau de heterogeneidade
(diversidade de dispositivos) e o seu grau de interdependencias (interaccoes entre
dispositivos), e ainda de factores de ordem tecnica relacionados com a arquitectura
do sistema SCADA.
A influencia destes factores reflecte-se nas diversas etapas da configuracao do
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 34
sistema. No entanto, nem todos contribuem da mesma forma para a complexidade
das tarefas de configuracao, o que justifica uma analise mais detalhada das relacoes
existentes. Antes de mais, e para sistematizar esta analise, pensamos ser importante
identificar um conjunto de elementos basicos que necessitam de ser configurados.
Assim, e necessario configurar:
� Os mecanismos que permitem a comunicacao com os dispositivos fabris (escolha
e configuracao dos gestores de perifericos);
� As mensagens (dados) que serao trocadas entre o sistema SCADA e os dispositi-
vos (definicao de variaveis);
� As aplicacoes que permitem recolher, tratar, representar e armazenar os dados
recolhidos dos dispositivos;
� O ambiente de suporte do sistema, ou seja, outras aplicacoes, ferramentas ou
plataformas das quais depende o SCADA.
A quantidade de dispositivos existentes no sistema supervisionado e directamente
proporcional a quantidade de dados produzidos e por isso influencia o processo de
configuracao das variaveis e tambem a configuracao das aplicacoes. Na verdade,
e natural que quanto maior for o numero de dispositivos mais complexos sejam os
sinopticos, maior seja o numero de alarmes, etc. Porem, se os dispositivos forem
todos iguais, os objectos que sao utilizados no sinoptico sao sempre os mesmos, sendo
portanto mais rapida a prototipagem do sistema. Por outro lado, a diversidade de
dispositivos tem um efeito oposto, ja que obriga a definicao de multiplos objectos
graficos, apesar de nao conduzir obrigatoriamente a uma maior complexidade dos
sinopticos. O grau de heterogeneidade tem tambem grande influencia na configuracao
dos mecanismos de comunicacao. De facto, as implicacoes acarretadas pela utilizacao
de dispositivos diferentes fazem sentir-se ao nıvel do numero de gestores de periferico
que e necessario utilizar. E importante verificar, a este proposito, que alguns sistemas
SCADA tornam impossıvel a supervisao em ambientes muito heterogeneos, pois nao
permitem a utilizacao simultanea de um numero arbitrario de gestores de periferico.
Nesta situacao encontra-se, por exemplo, o Processyn.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 35
A heterogeneidade pode tambem ter implicacoes a nıvel da configuracao da
plataforma de suporte, especialmente no que respeita as redes de comunicacao. A
instalacao de novas redes implica normalmente a configuracao da propria plataforma
(sistema operativo), dado que e esta a responsavel pelas interaccoes de mais baixo
nıvel. Do ponto de vista do SCADA este tipo de heterogeneidade e transparente.
Por ultimo, a interdependencia entre os dispositivos tem reflexos principalmente
ao nıvel da complexidade dos sinopticos, embora se reflicta tambem ao nıvel da
definicao de accoes de processamento e de controlo, dado que e exigida uma maior
sincronizacao destas accoes.
Os factores que analisamos nao influenciam, normalmente, a configuracao dos
ambientes de suporte ou de aplicacoes externas aos SCADA. Verifica-se que estas
possuem mecanismos independentes de configuracao, que dependem apenas do tipo
de interaccao com o SCADA.
A configuracao de sistemas de supervisao em pequenas instalacoes industriais nao
levanta grandes problemas. No entanto, o problema da escala e da distribuicao pode
fazer-se sentir aquando da configuracao do SCADA, se as capacidades do sistema
forem limitadas. Um aspecto essencial deve ser a capacidade do sistema para executar
as aplicacoes de supervisao independentemente da sua localizacao. Deve ser possıvel,
por exemplo, executar aplicacoes para visualizacao de graficos de tendencia num
computador, utilizando dados gerados ou armazenados noutro computador. Verifica-
-se que quanto a este aspecto se levantam dificuldades de configuracao, emergentes da
necessidade de instalar pelo menos o sistema de base em cada local onde se pretende
executar uma aplicacao de supervisao. Tal exigencia deve-se ao facto de o transporte
da informacao ser sustentado por mecanismos proprios de cada SCADA, que tornam
o sistema fechado do ponto de vista da distribuicao. Sao exemplos disto o FactoryLink,
que fornece modulos especıficos para transferencia de dados entre duas instancias do
sistema, e o InTouch, que utiliza o protocolo netDDE para acesso atraves da rede a
instancias remotas.
As capacidades dos sistemas relativamente aos aspectos da sua reconfiguracao
tambem devem ser avaliadas. Os problemas que normalmente surgem devem-se a uti-
lizacao de novos equipamentos para os quais o sistema nao esta configurado, e tambem
a necessidade de redimensionar o sistema em geral e as aplicacoes de supervisao, em
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 36
particular. O problema da reconfiguracao ao nıvel dos gestores de dispositivo apenas
e complicado se estes nao estiverem disponıveis. Apesar dos fabricantes anunciarem
o suporte de uma gama muito diversificada de dispositivos, e natural que novos equi-
pamentos apresentem interfaces diferentes, ainda nao suportadas. Nestes casos e ne-
cessario esperar ate que os novos gestores de periferico sejam desenvolvidos, ou entao
utilizar as ferramentas adequadas (com custos adicionais de aquisicao) para desenvol-
vimento dos gestores necessarios.
O redimensionamento do sistema pode implicar a utilizacao de novas instancias
do SCADA. Neste caso, tal como ja foi focado, pode ser necessario despender
algum tempo na interligacao das diversas celulas de supervisao, de forma a obter
bons resultados em termos da eficiencia global do sistema. Em termos da redefini-
cao dos sinopticos e das outras funcionalidades, as dificuldades serao semelhantes
nos diversos sistemas. Registe-se apenas que no caso do Processyn, pelo facto da
configuracao das aplicacoes ser realizada atraves de editores de texto, o tempo gasto
na reescrita das aplicacoes (e posteriormente na sua compilacao e teste) pode ser mais
elevado que nos restantes sistemas estudados.
2.8 Capacidades de Comunicacao
2.8.1 Comunicacao com os Dispositivos
Um dos aspectos fulcrais dos sistemas SCADA consiste na forma como interagem
com os dispositivos supervisionados ou controlados. Nos ambientes onde mais
frequentemente sao utilizados, os sistemas SCADA encontram uma variada gama
de dispositivos, desde computadores pessoais passando por PLCs, reguladores PID,
terminais fabris ou simplesmente sistemas de aquisicao de dados. Dado nao se
verificar, na maior parte dos casos, qualquer tipo de uniformidade em termos das
interfaces apresentadas por estes dispositivos, surgem naturalmente divergencias na
forma como os SCADA resolvem este problema.
Do ponto de vista da ligacao fısica a comunicacao pode ser realizada atraves de
portas serie ou paralela, redes proprietarias ou redes normalizadas.
No caso das redes normalizadas as interfaces de baixo nıvel estao ja incorporadas
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 37
no sistema operativo. Nestas redes, apenas os protocolos dos nıveis superiores tem de
ser concretizados pelos gestores de periferico ou pelas aplicacoes de supervisao. Nos
restantes casos os gestores de periferico sao responsaveis pela realizacao das interfaces
com o nıvel fısico.
A nıvel protocolar existem essencialmente duas aproximacoes possıveis na resolu-
cao do problema da interface com os dispositivos fabris: a primeira, e tambem a
mais usual, consiste na utilizacao de um gestor de periferico para cada tipo de dis-
positivo ligado ao sistema SCADA; a segunda consiste na utilizacao de uma inter-
face normalizada de comunicacao entre o SCADA e os dispositivos, sendo para tal
necessario que os dispositivos estejam, ou possam ser munidos com essa interface.
Quando os dispositivos possuem interfaces especıficas e necessario desenvolver me-
canismos de traducao entre as primitivas do protocolo normalizado e as primitivas
reconhecidas pelo dispositivo. As diferencas entre estas duas aproximacoes reflectem-
-se a diversos nıveis, nomeadamente ao nıvel da configuracao e da distribuicao do
sistema.
Os sistemas SCADA que comunicam com os dispositivos atraves de gestores de
dispositivo especıficos comportam uma limitacao intrınseca derivada da necessidade
de existencia de uma enorme diversidade desses gestores. Na verdade, dado que os
sistemas SCADA sao normalmente empregues em ambientes ja constituıdos, nao e
possıvel prever quais os dispositivos ja existentes na planta fabril, sendo tanto maior a
probabilidade de existirem dispositivos nao suportados pelo sistema SCADA quanto
menor for o numero de gestores nele incorporados. Prevendo a possibilidade de
lacunas em termos de suporte a dispositivos, a generalidade dos SCADA disponibiliza
ferramentas para o desenvolvimento de gestores de dispositivos. Como exemplos
podemos referir o FactoryLink e o InTouch. No entanto, e de referir que o utilizador
tera de aprender ou conhecer os mecanismos particulares oferecidos por cada um dos
SCADAs para o desenvolvimento desses gestores.
A utilizacao de uma interface uniforme para comunicacao com os dispositivos
obriga a existencia de tradutores para cada tipo de dispositivo. E assim evidente que a
construcao de um novo sistema de supervisao pode acarretar um esforco adicional de
geracao de tradutores para os novos equipamentos. Contudo, o desenvolvimento des-
tes tradutores e, em princıpio, mais simples que o desenvolvimento de um gestor de
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 38
periferico pois nao requer o conhecimento de novas ferramentas de desenvolvimento.
Por outro lado, os tradutores tem a vantagem de poderem ser posteriormente utiliza-
dos para equipamentos do mesmo tipo e de virtualizarem os dispositivos. Do ponto de
vista do sistema SCADA um dispositivo e uma entidade cuja localizacao e irrelevante,
podendo por isso ser facilmente movido. Depois de estar configurado, o sistema de su-
pervisao pode muito facilmente ser reconfigurado, dado que nao e necessario realizar
qualquer modificacao nas interfaces com os dispositivos.
2.8.2 Comunicacao entre Aplicacoes
A comunicacao entre multiplas entidades do mesmo sistema SCADA e realizada
utilizando protocolos proprietarios desenvolvidos para cada sistema. A disponibiliza-
cao destes mecanismos de comunicacao e motivada por questoes que se prendem
com a distributividade e escalabilidade dos sistemas. Na verdade, para que o sistema
possa ser distribuıdo e necessario que os dados dos processos industriais sejam visıveis
remotamente, o que nao acontece na situacao normal de operacao do sistema.
A este respeito verifica-se que a generalidade dos sistemas SCADA nao demonstra
capacidades intrınsecas para a distribuicao. E verdade que a possibilidade de
comunicacao entre duas instancias do mesmo SCADA permite realizar algumas opera-
coes distribuıdas, mas a custa da utilizacao de protocolos proprietarios, eventualmente
pouco eficientes e certamente limitativos em termos de expansibilidade. Implica ainda
a necessidade de aquisicao de um maior numero de licencas de instalacao.
Relativamente aos sistemas estudados, podemos afirmar que nenhum deles oferece
uma interface aberta para que qualquer aplicacao possa aceder directamente aos
dados de tempo-real mantidos internamente ao sistema. Esta lacuna impossibilita
definitivamente a utilizacao de aplicacoes que necessitem de aceder a estes dados, por
exemplo outras aplicacoes graficas de representacao de sinopticos ou aplicacoes de
processamento e armazenamento de dados. No caso concreto da comunicacao entre
diferentes sistemas SCADA, verifica-se, pelas razoes ja indicadas, que tal tambem nao
e possıvel.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 39
2.9 Expansibilidade
Actualmente, as exigencias economicas e concorrenciais conduzem a um acelerado
crescimento das empresas, que se traduz na permanente necessidade de reciclagem
dos recursos humanos, de expansao das estruturas e de modernizacao tecnologica. Na
medida do possıvel e realizado um esforco de aproveitamento e expansao da estrutura
ja existente, em vez da sua mera substituicao. No entanto, tal so sera possıvel se essa
estrutura for aberta e expansıvel.
No caso concreto dos sistemas SCADA, sera interessante averiguar as possibilida-
des de reestruturacao do sistema na sua expansao para grandes instalacoes. Por outras
palavras, deve determinar-se se a organizacao hierarquica da estrutura industrial em
expansao, agora composta por um maior numero de nıveis, pode ser eficazmente inte-
grada pelo sistema SCADA utilizado.
Relativamente aos sistemas estudados, o enfase das potencialidades e maioritaria-
mente dado as funcionalidades tıpicas das aplicacoes de supervisao e controlo ao nıvel
de uma celula fabril. De certa forma, verifica-se que a arquitectura basica da gene-
ralidade dos sistemas SCADA despreza a visao integrada do ambiente industrial em
detrimento de uma maior eficiencia e capacidade de actuacao ao nıvel de celulas de
fabrico isoladas. Pode assim dizer-se que a visao integradora destes SCADA se limita
aos dois nıveis inferiores da estrutura industrial, ou seja, ao nıvel dos dispositivos e da
sua supervisao.
As exigencias de grandes instalacoes industriais obrigam a existencia de um
terceiro nıvel (normalmente onde residem as aplicacoes de controlo da qualidade,
de gestao da producao e de gestao da manutencao) que deve estar no topo da
estrutura hierarquica e por isso ter visibilidade sobre todas as celulas fabris e linhas
de producao. Nao estando os sistemas SCADA vocacionados para este tipo de
estruturacao, impossibilitam a visibilidade e o fluxo de informacao e comprometem as
possibilidades de expansao. A integracao com o nıvel de gestao tera de ser realizada
com base noutras plataformas, por exemplo recorrendo a bases de dados distribuıdas.
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 40
2.10 Compatibilidade
A construcao de um sistema de supervisao requer normalmente a execucao
de diversos tipos de aplicacoes em paralelo com a execucao do sistema SCADA,
nomeadamente de sistemas gestores de bases de dados, folhas de calculo e aplicacoes
de geracao de graficos. A interaccao entre estas aplicacoes e o sistema SCADA so e
possıvel se este dispuser de interfaces compatıveis com as das aplicacoes.
Pode afirmar-se que tem de existir pelo menos um mecanismo de compatibilidade
entre o sistema SCADA e as restantes aplicacoes, pois caso contrario nao seria
possıvel utilizar os dados recolhidos pelo SCADA. O mecanismo mais basico de
compatibilidade entre aplicacoes consiste na transferencia de informacao atraves de
ficheiros, utilizando formatos comuns. Outros mecanismos mais elaborados permitem
a comunicacao e transferencia de dados directamente entre as aplicacoes. Por exemplo,
no Windows e utilizado o DDE, no UNIX podem ser utilizados sockets e no OS/2
podem ser utilizadas queues.
Os sistemas estudados apresentam diversos graus de compatibilidade. O Facto-
ryLink e aquele que permite a interaccao com a maior variedade de aplicacoes, em
especial com aplicacoes de bases de dados. No outro extremo situa-se o Processyn,
cujo mecanismo exclusivo de exportacao de dados e atraves da escrita em ficheiros.
De uma forma geral, pode dizer-se que todos os sistemas que assentam em
plataformas Windows ou OS/2 disponibilizam uma interface DDE para acesso a
aplicacoes externas. Por exemplo, e atraves desta interface que os SCADA garantem a
compatibilidade com a folha de calculo EXCEL.
2.11 Resumo
Neste capıtulo apresentamos uma panoramica de alguns sistemas SCADA actual-
mente existentes no mercado. Definimos os criterios que permitiram orientar o estudo
efectuado e discutimos as diversas caracterısticas desta famılia de sistemas.
Escolhemos um conjunto de quatro sistemas SCADA que descrevemos sumaria-
mente e que utilizamos como referencia para exemplificar os diversos tipos de solucoes
CAPITULO 2. PANORAMICA SOBRE SISTEMAS SCADA 41
existentes para a concretizacao das funcionalidades mais comuns.
Observamos que as funcionalidades oferecidas pelos sistemas SCADA sao normal-
mente semelhantes, sendo a qualidade grafica das aplicacoes e a possibilidade de inte-
raccao com uma larga gama de dispositivos preocupacoes generalizadas.
Observamos ainda que sao poucos os sistemas SCADA da geracao actual que dao
importancia aos problemas da expansibilidade, distributividade e heterogeneidade
de sistemas e aplicacoes. De facto, verificamos que a interligacao entre os sistemas
SCADA e os sistemas de gestao de alto nıvel e normalmente comprometida quer pela
heterogeneidade de sistemas operativos quer pela utilizacao de interfaces de comu-
nicacao e transferencia de dados proprietarias. Constatamos tambem os problemas
de expansibilidade caracterısticos da generalidade dos SCADA, em parte devidos as
limitadas capacidades de comunicacao ao nıvel aplicacional.
Capıtulo 3
A Arquitectura NavCim
Como vimos no capıtulo anterior, os sistemas SCADA possuem potencialidades,
por exemplo ao nıvel da representacao grafica, que sao extremamente importantes
na automatizacao de processos industriais. Infelizmente, estes sistemas apresentam
tambem algumas lacunas. Verifica-se, por exemplo, que ao nıvel da gestao dos
recursos e da visibilidade da informacao o suporte oferecido e por vezes insuficiente,
inadequado ou mesmo inexistente, o que obviamente limita as possibilidades de
utilizacao.
A arquitectura descrita neste capıtulo propoe-se suprimir as barreiras encontradas
na aplicacao de sistemas SCADA em ambientes onde a distribuicao, a escalabilidade e
a heterogeneidade sao factores relevantes.
3.1 Requisitos
Nesta seccao sera feita a descricao dos requisitos que a arquitectura NavCim
devera preencher. A formulacao destes requisitos surge como resultado da analise dos
sistemas actualmente existentes e da consequente observacao das lacunas de muitos
deles. Muitas destas lacunas foram ja apontadas no capıtulo anterior, mas serao
exploradas em maior profundidade na discussao que se segue.
42
CAPITULO 3. A ARQUITECTURA NAVCIM 43
3.1.1 Heterogeneidade
A integracao de todos os componentes que constituem um sistema de controlo
e supervisao industrial e orientada, em larga medida, pelo tipo, caracterısticas e
diversidade desses componentes. Nas industrias construıdas de raız a escolha dos
componentes simplifica o desenvolvimento do sistema de supervisao. Este nao e,
contudo, o caso tıpico.
Actualmente, verifica-se que para a resolucao de um problema e possıvel encontrar
multiplas solucoes nos mercados informatico, de computadores e de equipamentos
electronicos. De facto, um dos aspectos mais marcantes nestes sectores de actividade e
a feroz concorrencia entre as diversas empresas, daı que seja natural a constante oferta
de novos produtos, melhores e por vezes mais baratos. Esta elevada diversidade de
solucoes transparece muito facilmente nos ambientes industriais, mas nao constitui por
si so um motivo de preocupacao para o integrador de sistemas. No entanto, e em parte
devido aos motivos concorrenciais, acontece que estes produtos apresentam na maioria
dos casos interfaces proprietarias, que originam problemas de heterogeneidade.
Estes problemas de heterogeneidade sao visıveis a varios nıveis, podendo destacar-
-se os seguintes: sistemas operativos, aplicacoes e equipamentos.
Relativamente aos sistemas operativos, a utilizacao de uma determinada plata-
forma limita imediatamente as opcoes a nıvel aplicacional, e por vezes a nıvel de
equipamentos. A integracao do sistema tera de ser realizada utilizando aplicacoes
compatıveis com as plataformas existentes, quer sejam SCADAs, bases de dados ou
aplicacoes de gestao.
Uma das formas de ultrapassar o problema da heterogeneidade de sistemas
operativos consiste na utilizacao de software multi-plataforma. Infelizmente, a maioria
das aplicacoes e desenvolvida exclusivamente para uma plataforma (no maximo duas),
como e o caso da generalidade dos sistemas SCADA, o que invalida esta solucao. Para
o integrador de sistemas, a heterogeneidade de plataformas pode assim ser um factor
muito limitativo das opcoes disponıveis em termos de SCADAs e outras aplicacoes.
Ao nıvel aplicacional a heterogeneidade nao sera tao evidente, mas existe. O
problema reside normalmente na incompatibilidade de interfaces, que impossibilita
a transferencia de dados entre aplicacoes. A necessidade de utilizacao de interfaces
CAPITULO 3. A ARQUITECTURA NAVCIM 44
especıficas para acesso a bases de dados sera talvez um bom exemplo deste problema.
Finalmente, a heterogeneidade de equipamentos sera certamente um problema
menor que os anteriores. De facto, se os sistemas SCADA nao pudessem, ou pelo
menos nao tentassem, resolver este problema, a sua utilidade seria nula, pois nao
podemos esquecer que uma das tarefas primordiais destes sistemas e a interoperacao
com os dispositivos para a recolha de dados. Tem assim de ser capazes de lidar com a
heterogeneidade a este nıvel.
Mesmo assim, como vimos no capıtulo anterior, existem alguns sistemas que
apresentam algumas restricoes quando se verifica uma elevada heterogeneidade de
dispositivos.
Propomos agora um exemplo muito simples que ilustra claramente os problemas
de heterogeneidade que acabamos de descrever. Suponha-se a necessidade de instalar
um sistema de supervisao e aquisicao de dados num ambiente constituıdo por
equipamentos industriais e por uma zona de escritorios. Os elementos a integrar
consistem na plataforma computacional que realiza algumas tarefas de controlo
dos processos industriais, que consideraremos ser uma plataforma do tipo P1, na
plataforma existente nos escritorios, do tipo P2, numa base de dados, BD, instalada
sobre a plataforma P2 e, finalmente, nas aplicacoes de gestao e planeamento que
interagem com a base de dados sobre a mesma plataforma. Suponha-se ainda que
nao existe qualquer tipo de ligacao fısica entre as duas plataformas e que os dados
relativos aos processos industriais sao recolhidos por um operador na plataforma P1 e
posteriormente introduzidos por outro operador na base de dados da plataforma P2.
O que se pretende e nao so desenvolver as aplicacoes de supervisao e aquisi-
cao de dados na plataforma P1, como automatizar o processo de transferencia e
armazenamento da informacao recolhida. O problema e que se as plataformas forem
diferentes o SCADA tera de ser compatıvel com ambas, requisito nao preenchido pela
maior parte destes sistemas. Nao consideramos como solucao a utilizacao de um
SCADA diferente em cada uma das plataformas, pois isso seria inviabilizado pela
impossibilidade de interligar os dois SCADAs.
Mesmo considerando a utilizacao de um SCADA multi-plataforma, ainda e
necessario garantir que o sistema escolhido e capaz de interagir com a base de dados
CAPITULO 3. A ARQUITECTURA NAVCIM 45
�8
�9
����������
����������������� ���
�����
�����
�8
�9
����������
�� �!"#$�%
�������������
�� �!"#$�%
�������������������
�����������������
������������������������
������������ ������������
Figura 3.1: A arquitectura NavCim face a heterogeneidade de sistemas e aplicacoes.
existente, o que restringe ainda mais o leque de solucoes.
Supondo que a empresa tinha resolvido o problema transferindo a informacao sob
a forma de ficheiros, por rede, entre P1 e P2, continuariam a existir diversos problemas,
nomeadamente de coerencia dos dados, de conversao de formatos e, principalmente,
de transparencia.
A arquitectura proposta devera possibilitar a construcao de aplicacoes de super-
visao e a sua interligacao com os sistemas de gestao de alto nıvel, em ambientes he-
terogeneos. Deverao ser disponibilizados mecanismos imunes a heterogeneidade de
sistemas e aplicacoes que realizem o transporte da informacao e que proponham in-
terfaces normalizadas de compatibilizacao com as aplicacoes, de modo a flexibilizar a
construcao do sistema numa perspectiva integradora.
3.1.2 Distribuicao
Actualmente, o funcionamento das estruturas computacionais assenta cada vez
mais na utilizacao de redes de comunicacao e de sistemas distribuıdos, substituindo
a tradicional organizacao em torno de sistemas centralizados. De facto, esta nova
orientacao e motivada por aspectos tao importantes como a descentralizacao das
CAPITULO 3. A ARQUITECTURA NAVCIM 46
responsabilidades e a partilha de recursos, que podem ser obtidos atraves da distribui-
cao. A concretizacao destes aspectos reflecte-se nao so numa melhor eficiencia e
desempenho da organizacao, como tem consequencias muito positivas do ponto de
vista economico.
Assim, e conveniente, e a evolucao actual dos sistemas para la aponta, que na area
do controlo e da supervisao de processos industriais se caminhe no sentido de uma
cada vez maior distribuicao.
Infelizmente, as capacidades de distribuicao dos sistemas SCADA da geracao
actual sao ainda bastante limitadas. Efectivamente, a visibilidade e a facilidade de
acesso aos dados, condicoes essenciais para a distribuicao, nao sao devidamente
preenchidas pela maioria dos SCADA existentes.
Voltando ao nosso exemplo, suponha-se agora que alguns dos dispositivos indus-
triais supervisionados atraves da plataforma P1 passam a ser controlados atraves de
outra plataforma. No entanto, do ponto de vista das aplicacoes pretende manter-se
uma visao global de todos os dispositivos, ou seja, pretende ter-se acesso simultaneo
aos dados recolhidos em ambas as plataformas. Nesta nova especificacao pressupoe-se
que deve ser indiferente a localizacao das aplicacoes de supervisao.
�8
�9
����������
�����������������
�����
�9��������
��
�� �!"#$�%
�������������
�����
�8
�����
�������������������
�8 �8
�� �!"#$�% �� �!"#$�%
�� �!"#$�%
�9
������������ ������������ ������������ ������������
��,�� ��,��
��,�� ��,��
Figura 3.2: Resolucao dos problemas de distribuicao utilizando a arquitectura Nav-Cim.
CAPITULO 3. A ARQUITECTURA NAVCIM 47
Como vimos no capıtulo anterior, a generalidade dos sistemas SCADA disponi-
biliza mecanismos de comunicacao para acesso a dados remotos. Contudo, quer se
baseiem em protocolos proprietarios ou normalizados (caso em que e possıvel a in-
teraccao
com outras aplicacoes), estes mecanismos implicam a definicao de dependencias inter-
-aplicacoes (com prejuızo para a mobilidade das mesmas) e constituem um factor de
degradacao do desempenho do sistema. Por outro lado, como para cada aplicacao que
queira aceder aos dados e necessario definir uma ligacao ponto-a-ponto com o sistema
SCADA, podem provocar-se situacoes de sobrecarga que prejudicam o funcionamento
do sistema.
A nossa arquitectura devera responder positivamente a estes problemas, apresen-
tando uma solucao que garanta a visibilidade da informacao em todos os nıveis da
estrutura empresarial. Ela devera permitir a independencia da localizacao das aplica-
coes, caracterıstica fundamental dos sistemas distribuıdos. As capacidades de distri-
buicao devem reflectir-se em termos do esforco necessario para a reconfiguracao do
sistema, que devera ser mınimo.
3.1.3 Escalabilidade
Devido ao facto da dimensao dos sistemas supervisionados ser variada, os sistemas
SCADA devem possuir qualidades que permitam a sua utilizacao qualquer que
seja a dimensao do ambiente de aplicacao. Para alem disso, o seu desempenho
nao deve sofrer alteracoes significativas e o custo da sua utilizacao nao devera ser
significativamente afectado.
No capıtulo anterior estudamos diversos sistemas SCADA e uma das conclusoes
a que chegamos foi que esta geracao de sistemas procura resolver essencialmente os
problemas da supervisao ao nıvel da celula de fabrico, relegando para segundo plano
os problemas da integracao de todos os nıveis da estrutura empresarial.
Assim, pode dizer-se que a generalidade dos SCADA nao e escalavel a dimensao
das empresas, pelo menos numa perspectiva integradora. A aplicacao destes SCADA
em empresas de grande dimensao tendera para solucoes assentes na supervisao local,
ao nıvel das celulas de fabrico. Pode no entanto afirmar-se que estes sistemas sao
CAPITULO 3. A ARQUITECTURA NAVCIM 48
escalaveis em termos da dimensao da planta fabril, pois essa dimensao apenas podera
ter reflexos no numero de celulas a supervisionar.
Pretende-se que a arquitectura NavCim seja escalavel em todos os sentidos, ou
seja, pretende-se que seja possıvel nao so adaptar o sistema de supervisao a dimensao
da planta fabril, como tambem adapta-lo as dimensoes globais da empresa, tendo em
vista a integracao de todos os nıveis da sua estrutura.
3.1.4 Expansibilidade
A expansibilidade podera ser entendida como a capacidade de reajustamento de
um sistema, motivada pela alteracao da dimensao do sistema supervisionado. Esta
capacidade e importante, pois o crescimento de uma empresa nao deve ser compro-
metido pelo sistema de supervisao utilizado, caso este nao possa ser redimensionado.
Note-se que a expansibilidade nao esta directamente relacionada com a escalabi-
lidade, ou seja, se um sistema for expansıvel nao sera obrigatoriamente escalavel, e
vice-versa. De facto, a escalabilidade e um conceito que esta associado a uma nocao
de dimensao ou espaco fısico, ao contrario da expansibilidade, que envolve a ideia de
quantidade de elementos do sistema (dimensao quantitativa e nao espacial).
No entanto, pode considerar-se que quer a escalabilidade quer a expansibilidade
sao requisitos relacionados com as capacidades de configuracao dos sistema SCADA.
No primeiro caso exige-se que o sistema possua capacidades de configuracao que
permitam uma certa independencia face as condicionantes espaciais, ou seja, que
permitam a construcao de um sistema independentemente da localizacao das aplica-
coes. No caso da expansibilidade, pretende-se que as capacidades de configura-
cao permitam efectuar adaptacoes do sistema motivadas pela introducao de novos
equipamentos e pela necessidade de diferentes requisitos ao nıvel das aplicacoes de
supervisao.
A avaliacao das capacidades de expansao de um sistema SCADA deve ser reali-
zada tendo em conta a evolucao do sistema supervisionado, quer em termos quanti-
tativos, quer em termos qualitativos. O que queremos dizer e que o crescimento do
sistema, para alem de implicar um aumento da quantidade de informacao a supervi-
sionar, pode ter repercussoes em termos da diversidade de dispositivos e aplicacoes,
CAPITULO 3. A ARQUITECTURA NAVCIM 49
condicionando inevitavelmente o processo de reconfiguracao e readaptacao do sistema
SCADA. Isto significa que as capacidades de expansao de um sistema sao tambem con-
dicionadas pela sua capacidade de resolver os problemas de heterogeneidade.
Como temos visto, as limitacoes de muitos dos sistemas SCADA existentes
em termos de suporte a heterogeneidade tem inevitavelmente influencia na sua
expansibilidade. Ao contrario destes sistemas, a arquitectura NavCim devera ser
concebida por forma a que a eventual necessidade de expandir a estrutura industrial
possa ser facilmente acompanhada por uma expansao do sistema de supervisao. Esta
capacidade estara naturalmente implıcita na arquitectura a partir do momento em que
esta for capaz de lidar com a heterogeneidade de aplicacoes, sistemas e equipamentos.
3.1.5 Tempo-Real
A criticalidade das accoes de controlo e supervisao dos processos industriais
e variavel. Ela depende de diversos factores que tem a ver com a natureza dos
processos e com as consequencias da possıvel falha dessas accoes. Assumimos que
na generalidade dos casos, para os quais se orientam a maior parte das solucoes,
se pretende ter algumas garantias da atempada execucao das accoes programadas,
embora a eventual falha temporal da sua execucao nao tenha efeitos catastroficos.
A supervisao em tempo-real estrito, ou seja, com limites temporais previstos
e rıgidos, nao constitui um requisito da arquitectura que aqui descrevemos. O
desenvolvimento de uma tal arquitectura poderia constituir o tema de outro trabalho,
na area de sistemas como [Cristian 90, Kopetz 89].
Pode dizer-se que os sistemas SCADA existentes fornecem as garantias de tempo-
-real que pretendemos tambem fornecer. A incapacidade destes sistemas prende-se
com a falta de visibilidade da informacao de tempo-real e nao com a capacidade
de recolha desta informacao. Na realidade, apenas as aplicacoes ou modulos que
constituem o proprio sistema SCADA tem acesso aos chamados dados de tempo-real.
O facto de se designarem os dados recolhidos como dados de tempo-real nao sig-
nifica que sejam dadas garantias absolutas sobre a validade desses dados. A utilizacao
de sistemas operativos e de redes de comunicacao que nao dao garantias de tempo-
-real
CAPITULO 3. A ARQUITECTURA NAVCIM 50
e o primeiro factor que inviabiliza a possibilidade de recolher dados em tempo-real,
num sentido estrito [Verıssimo 93]. Assim, designacoes tais como “dados de tempo-
-real” ou “base de dados de tempo-real” terao sempre de ser interpretadas num sen-
tido lato, tendo o tempo-real um significado que depende das condicoes em que e feita
a coleccao dos dados dos processos industriais. Quanto menor for o numero de facto-
res que introduzam incertezas no tempo de recolha dos dados e quanto menor for essa
incerteza, mais estrito sera o significado da nocao de tempo-real.
Pretende-se que a arquitectura NavCim demonstre capacidades de tempo-real no
sentido lato. A arquitectura deve ter a capacidade de tornar visıvel esta imagem em
tempo-real nos nıveis que se encontram acima do nıvel de recolha dos dados. O pre-
co da visibilidade dos dados podera traduzir-se, no entanto, numa degradacao das
caracterısticas de tempo-real desses mesmos dados.
3.1.6 Custo
A utilizacao de um sistema de supervisao tem um custo, que deve ser encarado
como um investimento. Pretende-se que esse investimento seja compensado tanto
quanto possıvel a curto prazo, sendo para tal necessario que o custo inicial nao seja
muito elevado em relacao ao benefıcio esperado e que a utilizacao do sistema de
supervisao seja favoravel ao aumento dos lucros.
Em relacao aos sistemas SCADA existentes, verifica-se que o seu custo e relativa-
mente elevado, principalmente se tivermos em conta que e muitas vezes necessario ad-
quirir software extra para realizar determinadas funcionalidades nao disponibilizadas
no pacote basico do SCADA. E tambem necessario, em muitos deles, adquirir gestores
de perifericos para ligacao aos equipamentos industriais, o que encarece ainda mais a
solucao de supervisao. Por outro lado, vimos ja que a integracao dos diversos nıveis
de uma empresa e normalmente possıvel apenas se for utilizado o mesmo SCADA em
todas as plataformas a integrar, o que implica, eventualmente, a necessidade de ad-
quirir um maior numero de licencas desse SCADA. Para tentar reduzir os custos de
utilizacao poderia pensar-se em centralizar o mais possıvel as funcoes de supervisao,
de modo a utilizar um menor numero de instancias do sistema SCADA. No entanto,
como muitos dos sistemas fazem depender o seu custo do numero de variaveis que
sao supervisionadas, e a dimensao do sistema supervisionado e nao a forma como a
CAPITULO 3. A ARQUITECTURA NAVCIM 51
supervisao e feita que determina o custo final de utilizacao.
De uma forma generica, o custo de um sistema SCADA pode ser influenciado pelas
solucoes tecnicas a que recorra na resolucao dos problemas da supervisao. Assim,
a arquitectura NavCim devera recorrer o mais possıvel a solucoes normalizadas e de
grande divulgacao, pois estas sao normalmente de custos muito reduzidos, permitindo
por isso que a construcao dos sistemas de supervisao seja menos onerosa e que o seu
uso se vulgarize.
3.2 Descricao Geral
O modelo CIM� constitui actualmente o principal modelo de referencia na constru-
cao das estruturas empresariais [Beekmann 89]. Neste modelo enquadram-se as
estruturas onde e feita a integracao entre o nıvel produtivo, normalmente segmentado
em ilhas automatizadas de producao, e os nıveis superiores, de forma a que a informa-
cao possa fluir facilmente entre as diversas areas da empresa [Bauer 91, Gutschke 87].
A estrutura do modelo CIM e constituıda por diversos nıveis hierarquicos, que se
distribuem desde o nıvel produtivo (shop-floor) ate ao nıvel de planeamento e gestao
(office-floor). Nesta hierarquia, cada nıvel e responsavel pela coordenacao e gestao do
nıvel inferior, realizando o transporte da informacao entre nıveis sucessivos e entre as
diversas celulas de um mesmo nıvel.
O sucesso da integracao de sistemas de acordo com este modelo depende essencial-
mente de dois factores: dos mecanismos de tratamento da informacao e dos suportes
de comunicacao.
No capıtulo anterior vimos que os sistemas SCADA existentes respondem muito
positivamente ao primeiro destes factores, ou seja, possuem um variado e eficiente
leque de ferramentas para tratamento da informacao. No entanto, o mesmo nao acon-
tece no que concerne aos mecanismos de comunicacao, essenciais para o transporte da
informacao entre os diversos nıveis do modelo CIM, cujas limitacoes sao muitas vezes
notorias.
A constatacao da existencia de uma serie de lacunas, evidenciadas por muitos
�Computer Integrated Manufacturing.
CAPITULO 3. A ARQUITECTURA NAVCIM 52
sistemas SCADA, motivou o desenvolvimento de uma arquitectura que desse resposta
a essas lacunas e que permitisse, por isso, a construcao de sistemas coerentes com o
modelo CIM. Surgiu assim a arquitectura NavCim.
Do ponto de vista pratico, o desenvolvimento de um conjunto de modulos de
software respeitando a arquitectura definida deu origem a plataforma NavCim. Na
globalidade de um sistema de supervisao e controlo industrial a plataforma NavCim
sera uma entidade unica. No entanto, neste sistema poderao existir diversas celulas
NavCim, nucleos computacionais onde esta instalado o software que constitui a
plataforma.
Concretamente, a arquitectura NavCim permite resolver os seguintes problemas,
encontrados na integracao de sistemas industriais:
� heterogeneidade de ferramentas, sistemas e aplicacoes;
� escalabilidade na continuidade, de PME a GE.
A par disto, a arquitectura NavCim tem tambem como objectivos o fornecimento
de funcionalidades que permitam realizar a supervisao de processos industriais de
uma forma integrada, eficiente e simples, bem como o fornecimento do suporte ne-
cessario para a execucao de tarefas de gestao, tais como o controlo da qualidade, ela-
boracao de relatorios de producao, tratamento de condicoes de excepcao e alteracoes
dos parametros de supervisao. A NavCim pretende ainda oferecer mecanismos sufi-
cientes para a automatizacao distribuıda e integrada da producao, isto e, mecanismos
que conduzam ao automatismo da execucao de ordens de fabrico, da recolha de dados
de producao e do tratamento de eventos e alarmes.
Para cumprir todos estes requisitos a arquitectura NavCim apresenta um perfil
totalmente aberto. A sua concepcao baseia-se na utilizacao de solucoes normalizadas
no universo dos sistemas de computadores, quer no respeitante a protocolos de
comunicacao quer relativamente aos suportes de armazenamento da informacao.
A resolucao dos problemas de heterogeneidade a nıvel de sistemas operativos e
conseguida, em termos praticos, atraves da utilizacao de uma camada de suporte e in-
terface ao sistema. Esta camada constitui o unico ponto de dependencia relativamente
ao sistema e, ao ser utilizada, permite que o software que constitui a plataforma seja
CAPITULO 3. A ARQUITECTURA NAVCIM 53
identico em todos os sistemas. Torna-se assim mais facil o desenvolvimento da plata-
forma NavCim para um novo sistema operativo, bastando para tal redefinir a camada
de interface.
A independencia face a heterogeneidade de dispositivos e conseguida a custa da
utilizacao da norma de comunicacao industrial, MAP/MMS [MAP85, Crowder 86,
Thacker 87, ISO90a, ISO90b], que uniformiza o acesso aos dispositivos e comporta
vantagens a nıvel da distribuicao e expansao do sistema. Na plataforma NavCim
o ambiente MMS e fornecido pela SWCP�, plataforma de comunicacoes que oferece
uma interface de programacao uniforme, independente do sistema operativo utilizado
[Rang 92].
A heterogeneidade das aplicacoes faz-se sentir em termos do acesso a informacao.
A arquitectura NavCim resolve este problema assumindo que todas as aplicacoes tem
a capacidade de aceder ao sistema de ficheiros, sendo portanto a utilizacao de ficheiros
a forma mais eficaz de garantir a compatibilidade entre todas as aplicacoes e garantir
que todas elas consiguam aceder a informacao.
Por outro lado, a utilizacao de um sistema de ficheiros distribuıdo, no nosso caso
concreto o NFS� [SM89], apresenta varios aspectos positivos: permite que a informa-
cao seja visıvel em todos os nucleos computacionais onde tal seja desejavel o que, do
ponto de vista da distribuicao do sistema de supervisao, e extremamente importante;
constitui uma solucao largamente divulgada com vantagens evidentes em termos da
sua disponibilidade e custo. Na verdade, e possıvel utilizar este sistema de ficheiros
em qualquer dos sistemas operativos actualmente mais utilizados, sem implicar custos
elevados. E ainda de assinalar que em muitos dos casos o NFS faz parte integrante dos
sistemas operativos, o que permite a sua utilizacao sem qualquer custo adicional, ou
seja, apenas aproveitando os recursos existentes.
Um aspecto importante desta arquitectura relaciona-se com as caracterısticas de
tempo-real que podem ser atribuıdas a uma parte da sua estrutura, caracterısticas essas
que, ainda que relativamente limitadas, podem tornar viavel a utilizacao da NavCim
em ambientes onde o tempo de reaccao para a tomada de decisoes pode ser crıtico.
Noutros ambientes, a criticalidade pode exigir que a supervisao dos processos
�System Wide Communications Platform.�Network File System.
CAPITULO 3. A ARQUITECTURA NAVCIM 54
seja tolerante a faltas. A arquitectura NavCim, apesar de nao dispor de mecanis-
mos intrınsecos para a tolerancia a faltas, foi concebida no sentido de permitir a
posterior utilizacao de tecnicas de tolerancia a faltas na construcao de um sistema
de supervisao. Por exemplo, os modelos de comunicacao definidos na arquitec-
tura permitem utilizar tecnicas de replicacao baseadas na comunicacao em grupo
[Rodrigues 92, Rodrigues 93a, Birman 94] para suportar a supervisao replicada utili-
zando a plataforma NavCim, solucionando problemas decorrentes da falha de uma
das replicas [Verıssimo 91, Powell 91].
A utilizacao da arquitectura NavCim nao pressupoe a existencia de nenhum tipo
de hardware dedicado, ou especıfico. Tera de existir apenas o hardware basico que
devera dispor da memoria suficiente para execucao dos varios modulos que compoem
o sistema. Em princıpio, a arquitectura sera utilizada na integracao dos diversos
nıveis da estrutura empresarial, sendo por isso necessaria a existencia de uma rede
de comunicacao entre esses nıveis. O tipo de rede utilizado nao e imposto pela
arquitectura, pelo menos de uma forma directa. A possibilidade de utilizar a NavCim
esta condicionada, no entanto, pela disponibilizacao de determinados servicos de
comunicacao, nomeadamente a comunicacao atraves dos protocolos normalizados
TCP/IP, os quais podem depender do tipo de hardware de comunicacao existente.
Como ja foi dito, a arquitectura NavCim pressupoe uma estruturacao hierarquica
do sistema industrial. Esta hierarquia e composta por tres nıveis correspondentes ao
nıvel dos dispositivos, ao nıvel de celula e ao nıvel de gestao. Tipicamente, os dois
primeiros nıveis enquadram-se na area de producao e o ultimo enquadra-se na area de
gestao.
A figura 3.3 representa esta decomposicao hierarquica, bem como as entidades
intervenientes num sistema de supervisao baseado na arquitectura NavCim.
Seguidamente descreveremos cada um destes nıveis, os elementos neles interve-
nientes, as interaccoes entre nıveis consecutivos e o papel desempenhado pela plata-
forma NavCim.
CAPITULO 3. A ARQUITECTURA NAVCIM 55
('�� �����:
('�� �����������������
('�� ����.�����
������������� �������
����������������
������������������
�������� ���������� � ��
���� �����
Figura 3.3: A hierarquia NavCim e as entidades do sistema: plataforma, dispositivos eaplicacoes.
3.2.1 Nıvel dos Dispositivos
O nıvel dos dispositivos constitui a base da hierarquia do sistema de supervisao.
Neste nıvel situam-se todos os equipamentos que fornecem os dados objecto de
supervisao.
Estes equipamentos tanto podem estar logicamente isolados como associados entre
si. As associacoes logicas de dispositivos resultam normalmente da organizacao do
processo produtivo e devem ser mantidas ao nıvel do controlo. Os equipamentos
cooperantes ou intervenientes numa determinada fase do processo de fabrico formam
uma celula de fabrico. O nıvel dos dispositivos esta assim agrupado em diversas
celulas, cuja supervisao pode ser realizada de uma forma independente.
Neste nıvel nao e essencial a existencia de uma rede de comunicacao que interligue
os dispositivos. Cada um deles pode estar directamente ligado a plataforma de
supervisao atraves de mecanismos normalizados ou proprietarios. E tambem possıvel
que os dispositivos estejam interligados atraves de uma rede proprietaria, ou atraves
de uma rede de instrumentacao (field bus), sendo a ligacao a plataforma feita apenas
por intermedio de um ponto de acesso que funciona como uma gateway. No entanto, e
CAPITULO 3. A ARQUITECTURA NAVCIM 56
tambem possıvel que exista uma rede de comunicacao a qual estejam ligados quer os
dispositivos industriais, quer a plataforma de supervisao.
Do ponto de vista protocolar, a ligacao entre um dispositivo e a plataforma
NavCim e mantida atraves da norma de comunicacoes em ambientes industriais, a
norma MAP, com o protocolo MMS no topo. Neste protocolo, todas as entidades
comunicantes sao representadas por um VMD�, podendo actuar como clientes ou
servidoras. Normalmente, as entidades da plataforma NavCim funcionam como
clientes e os VMDs dos dispositivos como servidores. No entanto, como veremos, a
plataforma funciona como um servidor no que diz respeito a recepcao de eventos. Um
VMD, como abstraccao de uma entidade concreta, mantem um conjunto de variaveis
que em cada instante caracterizam o estado do dispositivo representado. A comunica-
cao entre dois VMDs processa-se atraves de primitivas definidas pelo protocolo, que
permitem, entre outras, estabelecer associacoes, fazer pedidos de leitura e escrita de
variaveis e sinalizar eventos.
Cabera aqui uma interrogacao acerca da capacidade dos dispositivos de comunicar
atraves deste protocolo, obrigatoriedade imposta pela arquitectura NavCim. De facto,
podera pensar-se que a solucao proposta nao e viavel pelo facto de, na maioria dos
casos, os equipamentos industriais nao disporem de uma interface MMS. A negacao
desta hipotese e justificada pelo facto de ser possıvel superar a inexistencia do MMS
de uma forma muito simples, baseada na construcao de VMDs representantes dos
dispositivos.
Efectivamente, um VMD pode ser concretizado por um processo ou por uma
aplicacao que reconhece as primitivas MMS e sabe assim responder a pedidos efectua-
dos por outros VMDs. Por outro lado, este processo ou aplicacao podera comunicar
com um dispositivo atraves do protocolo por este suportado, funcionando entao como
uma entidade que representa esse dispositivo. A construcao deste representante, que
e um VMD, implica o desenvolvimento quer da interface MMS, quer da interface com
o dispositivo. A primeira nao depende do dispositivo, sendo sempre igual e, por isso,
facil de desenvolver. A segunda tera de ser desenvolvida para cada caso particular, im-
plicando apenas um esforco adicional quando surgem novas interfaces (para as quais
ainda nao existem VMDs).�Virtual Manufacturing Device.
CAPITULO 3. A ARQUITECTURA NAVCIM 57
O problema da utilizacao de redes e protocolos proprietarios em ambientes MMS
tem sido um motivo de preocupacao da comunidade cientıfica ligada a divulgacao
desta nova norma. Por isso mesmo, no seio do projecto europeu CNMA [CNMA 93] foi
especificada uma solucao para este problema [Consortium 93], tendo sido assimiladas
algumas ideias nela contidas, nomeadamente o mecanismo de traducao.
A arquitectura NavCim requer que todos os dispositivos, ou grupos deles, sejam
representados por VMDs. Como vimos, para que tal se verifique podera ser necessario
introduzir no sistema entidades que realizem esta representacao nas situacoes em que
os dispositivos nao possuam interface MMS. Como pode ser observado na figura 3.4,
qualquer que seja a situacao em que se encontre o dispositivo, a arquitectura NavCim
resolve o problema, uma vez que aquela se resume a uma das seguintes tres hipoteses:
a) VMD local ao dispositivo. Neste caso, o dispositivo suporta o MMS, fazendo
ele proprio a representacao do VMD. Esta e a situacao tıpica dos PLCs mais
modernos (mas de custo elevado), que disponibilizam diversas interfaces, entre
as quais a MMS.
b) VMD externo ao dispositivo e a plataforma NavCim. O dispositivo nao tem
interface MMS, sendo a representacao do VMD realizada por uma entidade
externa. Esta entidade, que pode ser materializada por um PC ou outro tipo de
controlador, dispoe de uma interface especıfica de ligacao ao dispositivo e de uma
interface MMS. Dado que e utilizada uma plataforma computacional dedicada
para fazer a representacao do dispositivo, a ligacao por MMS com a plataforma
NavCim e feita atraves de rede de comunicacoes. Um bom exemplo desta situa-
cao consiste na utilizacao de um PC com uma carta de entradas/saıdas a qual
estao ligados sensores, sendo neste PC construıdo um VMD que representa estes
sensores.
c) VMD externo ao dispositivo e local a plataforma NavCim. Nesta situacao, o dis-
positivo nao tem interface MMS sendo tambem utilizada uma entidade externa
para representar o VMD. No entanto, neste cenario, o VMD representante do dis-
positivo e a plataforma NavCim irao coexistir no mesmo nucleo computacional,
sendo portanto a comunicacao por MMS realizada localmente.
CAPITULO 3. A ARQUITECTURA NAVCIM 58
Controlador
VMD
Dispositivo
Protocolo proprietario
MMS
Controlador
VMD
Dispositivo
MMS
Controlador
VMD
MMS
Protocolo proprietario
Dispositivo
a) b) c)
Figura 3.4: Os tres cenarios possıveis de localizacao de um VMD.
As vantagens que resultam da utilizacao do MMS como protocolo de comunicacao
com os dispositivos sao as seguintes:
� Do ponto de vista da plataforma existe uma independencia total em relacao
aos dispositivos, ou seja, a comunicacao nao depende do tipo, modelo ou
caracterısticas particulares do equipamento;
� A localizacao do dispositivo, ou do seu VMD representante, e irrelevante para a
plataforma; a entidade da arquitectura NavCim que comunica com o VMD pode
ser colocada em qualquer plataforma computacional, inclusivamente num nıvel
diferente da hierarquia, por exemplo no nıvel de gestao. Esta flexibilidade nao e
obtida a custa de qualquer tipo de reconfiguracao do sistema;
� A ligacao a equipamentos que disponham de interfaces MMS e directa;
� A facilidade de programacao e interaccao com o dispositivos, para pessoal com
“formacao informatica”, bem como a facilidade de interligacao com as restantes
aplicacoes de mais alto nıvel.
� Nao existe nenhuma limitacao em termos da variedade de equipamentos que po-
dem ser acedidos atraves da plataforma NavCim, mesmo no caso de novos equi-
pamentos que surjam no mercado e que nao utilizem interfaces ja conhecidas.
Como a especificacao da interface e sempre disponibilizada, e sempre possıvel
criar um VMD que represente o dispositivo;
CAPITULO 3. A ARQUITECTURA NAVCIM 59
� Como o dispositivo e representado por um VMD, eventuais modificacoes inter-
nas do dispositivo, ou mesmo a sua completa substituicao, nao tera reflexos na
plataforma se as variaveis representativas do estado nao se alterarem.
3.2.2 Nıvel de Celula
A supervisao dos processos industriais e fundamentalmente feita agrupando
diversos dispositivos em celulas de supervisao. Este agrupamento de dispositivos ou
equipamentos corresponde a um primeiro nıvel de integracao, realizado por todos os
sistemas de supervisao. A definicao de celulas nao obriga, contudo, a que a supervisao
seja realizada exclusivamente ao nıvel da celula, pois e possıvel que exista um segundo
nıvel de integracao, que integre multiplas celulas e realize a sua supervisao de uma
forma conjunta.
O nıvel de celula corresponde, portanto, ao nıvel onde estao logicamente definidos
os grupos de dispositivos supervisionados e onde existem as plataformas que fazem a
supervisao de cada celula definida. A definicao das celulas existentes numa planta
fabril nao e regida por regras estaticas, mas existem alguns factores normalmente
influentes nessa definicao, tais como:
� a organizacao espacial dos equipamentos na planta fabril;
� a organizacao logica da planta fabril (por exemplo, linhas de montagem, fabrico
ou embalagem);
� a quantidade de equipamentos que formam uma celula.
Na arquitectura NavCim, existe em cada celula um computador ligado aos
dispositivos dessa celula, onde e instalado o software da plataforma NavCim. Este
software, que constitui uma celula NavCim, e responsavel por recolher os dados
que serao utilizados na supervisao e, eventualmente, realizar outras funcionalidades
tambem elas relacionadas com a supervisao ou com o controlo dos dispositivos.
Os computadores utilizados para a supervisao e controlo das celulas podem
ser simples PCs. De facto, mesmo que fosse necessario utilizar maquinas com
uma capacidade de processamento elevada, pode afirmar-se que actualmente os
CAPITULO 3. A ARQUITECTURA NAVCIM 60
PCs apresentam caracterısticas que permitiriam a sua utilizacao. Isto significa que
em termos de hardware de suporte, a definicao de multiplas celulas tem um custo
relativamente baixo, pois o custo actual dos PCs pode ser considerado reduzido. Por
outro lado, a utilizacao de PCs e tambem vantajosa no respeitante a disponibilidade
do sistema pois estes sao facilmente substituıveis. Finalmente, o software que pode ser
executado nestas plataformas e normalmente de baixo custo e de grande divulgacao e,
por isso mesmo, igualmente vantajoso.
Ainda no que diz respeito a precos, convem salientar que o hardware adicional
que pode ser necessario para ligacao aos dispositivos e tambem mais barato se forem
utilizados PCs. Por exemplo, a ligacao a redes Ethernet exige a utilizacao de interfaces
de hardware cujo custo e muito reduzido.
Em cada celula definida, a plataforma NavCim ira construir uma imagem de todos
os dispositivos ou processos industriais residentes nessa celula. Essa imagem, a que
chamaremos imagem em tempo-real dos processos, e formada pelos dados recolhidos
pela plataforma e armazenados num repositorio de tempo-real. Qualquer processo ou
aplicacao que pretenda conhecer o estado de um processo industrial podera utilizar
os dados armazenados no repositorio de tempo-real, pois estes representam com
fidelidade o estado actual dos processos da celula.
De acordo com as necessidades de supervisao e de integracao, a arquitectura
NavCim propoe que a visibilidade dos repositorios de tempo-real, ao nıvel de celula,
se restrinja as aplicacoes afectas ao repositorio. Isto significa que as aplicacoes de
supervisao de uma celula nao terao, em princıpio, acesso a imagem em tempo-real
dos dispositivos de outra celula. No entanto, todos os repositorios serao visıveis no
nıvel hierarquico imediatamente superior, ou seja, no nıvel de gestao. Pensamos que
esta aproximacao se justifica plenamente pelo facto de nao ser provavel a necessidade
de numa celula ter conhecimento do estado dos processos que se encontram noutra
celula. Relembramos, a este proposito, que a definicao das celulas tem em conta as
relacoes entre dispositivos e a organizacao logica da planta fabril, o que contribui para
a independencia da informacao recolhida em cada celula.
Para que possa ser construıda uma imagem dos processos industriais, a plataforma
NavCim define uma entidade cuja responsabilidade e, precisamente, a recolha ou co-
leccao de dados relativos aos processos. Esta entidade, que por enquanto manteremos
CAPITULO 3. A ARQUITECTURA NAVCIM 61
em abstracto, dispoe de uma interface MMS que lhe permite comunicar com os VMDs
dos diversos dispositivos, invocando primitivas de leitura de variaveis e sendo capaz
de receber eventos.
Os dados lidos dos VMDs sao armazenados no repositorio de tempo-real. Este
repositorio consiste na forma mais simples de armazenar informacao num sistema
computacional, ou seja, num ficheiro do sistema de ficheiros local. O formato com
que os dados sao registados nos ficheiros sera analisado mais adiante. A simplicidade
desta aproximacao traduz-se imediatamente pelo facto de as aplicacoes locais terem a
capacidade de aceder directamente a imagem em tempo-real dos processos.
A deteccao de eventos originados no nıvel dos dispositivos e realizada pela pla-
taforma NavCim no nıvel de celula. Estes eventos fazem parte da imagem dos pro-
cessos industriais e, como tal, sao igualmente armazenados no repositorio de tempo-
-real.
Na plataforma NavCim estao ainda definidas outras entidades cuja funcionalidade
diz respeito ao nıvel de celula. Por exemplo, a plataforma permite realizar algumas
funcoes de pre-processamento de dados, definir condicoes de alarme e ainda actuar
sobre os dispositivos utilizando primitivas disponibilizadas pelo MMS para escrita
nos VMDs. Estas entidades serao enunciadas e resumidamente descritas na seccao
3.3 e a sua analise mais pormenorizada aparecera na seccao 3.5. Na figura 3.5 e
representada uma celula NavCim, podendo observar-se algumas das funcionalidades
por ela disponibilizadas e a evolucao do repositorio de tempo-real ate ao de dados
estaveis. Esta representacao pretende evidenciar o pre-processamento efectuado
sobre os dados de supervisao, mostrando um conjunto de dados sucessivamente
processados, constituindo imagens de tempo-real dos processos industriais, ate chegar
aos dados armazenados num repositorio estavel, que contem informacao historica.
Na plataforma computacional do nıvel de celula podem residir tambem as aplica-
coes de supervisao que, acedendo a imagem dos processos industriais, realizam
as operacoes de supervisao comuns neste nıvel. No entanto, e pensando numa
perspectiva integradora, estas aplicacoes poderao residir num nıvel hierarquicamente
superior, dado que tem igualmente acesso a imagem em tempo-real dos processos. A
visibilidade dos sistemas de ficheiros das diversas celulas, obtida atraves da utilizacao
do sistema de ficheiros distribuıdo NFS, permite o acesso aos repositorios de tempo-
CAPITULO 3. A ARQUITECTURA NAVCIM 62
real remotos tal como se fossem repositorios locais.
Repare-se que esta duplicidade tem como fim satisfazer a configuracao mais
economica face a dimensao da unidade fabril, permitindo que com base na mesma
plataforma de suporte se consigam desenvolver versoes compactas ou expandidas do
sistema de supervisao.
5)��8
5)��9 5)��;
�� �����
�������
��:������������
����������$����
.��������������, ����
<��*����������,=
��,��$����0#�
��-�-� -� ���>��
MMS
5)�0�:
�����������
�� �� �����
Figura 3.5: A plataforma NavCim no nıvel de celula.
A ligacao entre o nıvel de gestao e nıvel de celula e assim estabelecida de
uma forma extremamente simples, que confere a arquitectura NavCim excelentes
capacidades de distribuicao das aplicacoes, permite integrar sistemas heterogeneos e
permite expandir facilmente o sistema.
3.2.3 Nıvel de Gestao
O nıvel de gestao, situado no topo da hierarquia CIM, e normalmente constituıdo
por computadores de grande capacidade de processamento e armazenamento, utili-
zados para executar aplicacoes de processamento de vencimentos, facturacao, stocks,
ou outras mais ligadas ao processo produtivo, tais como a gestao e o planeamento da
producao, o controlo da qualidade e a manutencao.
CAPITULO 3. A ARQUITECTURA NAVCIM 63
A este nıvel, a arquitectura NavCim desempenha um papel muito importante
na perspectiva integradora de sistemas. De facto, nao so torna visıveis a este nıvel
os repositorios das celulas de fabrico, como o faz independentemente dos sistemas
operativos utilizados, ou seja, independentemente da heterogeneidade de sistemas.
Por outro lado, mas ainda numa perspectiva integradora, a plataforma NavCim dispoe
de capacidades para o armazenamento de dados dos processos industriais em bases de
dados relacionais existentes a este nıvel. Esta capacidade, associada a funcionalidades
de pre-processamento de dados que tambem podem estar disponıveis a este nıvel,
permite a completa integracao das accoes de supervisao a todos os nıveis da estrutura
empresarial.
E a partir dos dados contidos nos repositorios de tempo-real e dos dados re-
sultantes de accoes de pre-processamento de dados (a que chamaremos dados pre-
processados) que sao construıdas as bases de dados situadas neste nıvel, que guar-
dam toda a informacao sobre a execucao dos processos de fabrico. Estes dados dizem
respeito a historia dos processos e sao normalmente utilizados por aplicacoes de alto
nıvel, cujos resultados permitem tomar decisoes ao nıvel da gestao e do planeamento
da producao. Devido ao facto de relatarem a historia dos processos, estes sao chama-
dos dados historicos.
3.3 A Modularizacao NavCim
A plataforma NavCim define um conjunto de entidades que executam determina-
das tarefas necessarias para a supervisao dos processos industriais. Estas entidades
estao organizadas como modulos funcionais que permitem isolar logicamente as fun-
cionalidades oferecidas pela plataforma e clarificar as dependencias funcionais. Assim,
dedicaremos agora algum espaco a apresentacao dos modulos definidos na arquitec-
tura, explicando porque sao necessarios e descrevendo-os resumidamente.
Os modulos definidos na arquitectura NavCim, representados na figura 3.6, podem
ser organizados em tres categorias, de acordo com a sua natureza e tendo em conta a
organizacao do software. Assim, temos: modulos que constituem a plataforma NavCim
(ou nucleares), modulos de suporte a plataforma e modulos de interface.
CAPITULO 3. A ARQUITECTURA NAVCIM 64
NavCim NavCim
�������������� �����
- �����������
-�4 ���
�����, ����
$����
5)�0�:
�1��
(<�
�����
-���������� -�������:
Figura 3.6: Modulos da arquitectura NavCim.
3.3.1 Modulos de Suporte
Os modulos de suporte a plataforma dizem respeito a aplicacoes, interfaces ou pro-
tocolos previamente definidos ou existentes, necessarios na definicao da arquitectura
NavCim. De certa forma, pode dizer-se que estes modulos constituem o suporte de
comunicacao da arquitectura NavCim, dado que sao utilizados para a interligacao en-
tre a plataforma e os dispositivos, para a distribuicao dos repositorios de informacao
e, por ultimo, para a interligacao entre multiplas instancias da plataforma. Assim, os
modulos de suporte a plataforma considerados sao os seguintes�:
� NFS:
Antes da mais, parece-nos importante salientar o caracter inovador da utiliza-
cao do NFS, pois nao e de todo habitual a utilizacao de sistemas de ficheiros
distribuıdos em ambientes industriais.
O NFS e um sistema de ficheiros distribuıdo, largamente divulgado e disponi-
bilizado para a maioria dos sistemas operativos actualmente existentes. Atraves
�No capıtulo dedicado a concretizacao da plataforma NavCim abordaremos estes modulos e os deinterface mais pormenorizadamente, pois consideramos ser este um assunto de natureza mais tecnica.
CAPITULO 3. A ARQUITECTURA NAVCIM 65
da utilizacao do NFS obtem-se a transparencia na localizacao de ficheiros, sendo
isso conseguido ao nıvel do sistema operativo, ou seja, sendo possıvel utilizar
as primitivas de sistema relativas a manipulacao de ficheiros mesmo no caso de
ficheiros localizados remotamente.
Do ponto de vista de configuracao e administracao, o NFS e extremamente
simples, o que torna atractiva a sua utilizacao em ambientes onde se pretende que
o esforco de manutencao seja mınimo, como e o caso dos ambientes industriais.
Por outro lado, em termos de desempenho este sistema de ficheiros apresenta
excelentes resultados, daı, talvez, a sua grande divulgacao.
Na arquitectura NavCim este modulo desempenha o papel fundamental de
veıculo distribuidor da informacao de supervisao, ou seja, dos repositorios de
tempo-real e de dados pre-processados. Numa perspectiva integradora pode
dizer-se que o NFS constitui uma ponte de ligacao entre os nıveis de celula
e de gestao. Caso nao fosse utilizado, teria de existir um modulo interno
a plataforma, responsavel pelo transporte da informacao entre os dois nıveis
hierarquicos. Neste caso o problema estaria a ser resolvido de forma semelhante
ao que se verifica na maioria dos sistemas SCADA existentes, ou seja, utilizando
protocolos especıficos para transferencia de informacao (como por exemplo o
FTP� [Postel 85]). Este tipo de aproximacao comporta algumas desvantagens face
a utilizacao de sistemas de ficheiros distribuıdos que, pode dizer-se, constituem
uma forma mais evoluıda de distribuicao que a utilizacao de protocolos tais como
o FTP [Coulouris 88, Mullender 93].
� ISODE:
O ISODE� [Rose 91] e uma plataforma de software cujo objectivo principal e
permitir a utilizacao de protocolos do nıvel aplicacional conformes com a norma
ISO sobre redes TCP/IP.
A necessidade de utilizar o ISODE na arquitectura NavCim advem do facto
de se utilizar o MMS como protocolo de comunicacoes, o qual pode apenas
ser utilizado em redes ISO. De facto, a utilizacao do ISODE torna-se apenas
necessaria nos sistemas cujos protocolos de comunicacao nao sao ISO, como e o
�File Transfer Protocol.�ISO Development Environment.
CAPITULO 3. A ARQUITECTURA NAVCIM 66
caso dos sistemas que utilizam o protocolo (de facto standard) TCP/IP. Como ficara
claro no capıtulo 4, a utilizacao deste modulo e implicitamente condicionada pela
plataforma SWCP.
O ISODE, ate a sua versao 7.0, e de domınio publico e esta disponıvel para a
maioria dos sistemas operativos mais divulgados.
� SWCP:
A SWCP e uma plataforma que permite a comunicacao entre aplicacoes atraves
do protocolo MMS [Rang 92]. Para tal, e oferecida uma interface de programacao
onde estao definidas diversas primitivas para envio de mensagens que permitem
o aproveitamento das potencialidades do MMS, bem como primitivas de recep-
cao e tratamento de mensagens que simplificam o desenvolvimento das aplica-
coes.
Na arquitectura NavCim a utilizacao da SWCP como modulo de suporte e
indispensavel, pois e este modulo que fornece os servicos do protocolo MMS
necessarios, por exemplo, para comunicacao com os dispositivos.
A SWCP fornece o suporte tanto para comunicacoes locais como remotas. Lo-
calmente, os mecanismos de comunicacao entre processos sao concretizados com
base nos recursos disponibilizados pelo sistema operativo utilizado�. No caso
de comunicacoes remotas a SWCP apresenta diversas opcoes no que respeita as
solucoes protocolares. Esta flexibilidade e conseguida devido a natureza modu-
lar da SWCP, na qual as ligacoes remotas sao geridas por uma entidade inde-
pendente que pode ser escolhida para cada caso particular. Se a rede de comu-
nicacao for TCP/IP, a entidade a utilizar fara uso do ISODE como camada emu-
ladora, permitindo que sejam enviadas mensagens MMS atraves de TCP/IP. Se
estiverem disponıveis os protocolos de comunicacao ISO, entao podera utilizar-
-se uma entidade de comunicacao remota que faca uso destes protocolos, sem
recorrer ao ISODE. Note-se que e possıvel manter em paralelo os dois tipos de
comunicacao mencionados, o que flexibiliza a construcao dos sistemas de super-
visao.�Assinale-se que a plataforma SWCP foi desenvolvida para diversos sistemas operativos, nomeada-
mente para OS/2 e sistemas UNIX V e BSD.
CAPITULO 3. A ARQUITECTURA NAVCIM 67
A utilizacao da SWCP na arquitectura NavCim permite que a interligacao com
os dispositivos industriais nao dependa das interfaces por estes oferecidas, uma
vez que a flexibilidade ao nıvel dos protocolos utilizados esta garantida.
� LSE:
O LSE [Fonseca 90] constitui um ambiente de programacao que oferece uma
interface uniforme, independente do sistema operativo. Pensamos que e im-
portante referi-lo como um possıvel modulo integrante da arquitectura NavCim,
pois este confere-lhe a independencia face ao sistema operativo tornando-a, dessa
forma, uma arquitectura portavel. Optamos por nao incluir o LSE na figura 3.6,
uma vez que pretendemos que a arquitectura nao restrinja, tanto quanto possıvel,
as possibilidades de concretizacao. Apenas nos referimos ao LSE pelo facto de ter
sido este o ambiente de suporte escolhido para a concretizacao da plataforma que
efectuamos. Assim, as particularidades do LSE serao abordadas no capıtulo da
concretizacao.
3.3.2 Modulos de Interface
Ao contrario dos modulos de suporte, cuja existencia ultrapassa a definicao da
arquitectura NavCim, os modulos de interface estao intrinsecamente relacionados com
a mesma. De facto, dado que estes modulos fornecem interfaces de programacao
que permitem a interaccao com a plataforma, a sua existencia apenas se justifica pela
existencia da plataforma. Na arquitectura NavCim estao definidos dois modulos de
interface que sao os seguintes:
� Interface de celula:
Esta interface pretende fornecer dois tipos de servico, qualquer um deles para
interaccao directa entre as aplicacoes e uma celula NavCim. O primeiro permite
a visualizacao e alteracao dinamica da configuracao da celula, utilizando um
protocolo proprietario especıfico para esse fim. O segundo permite a comunica-
cao com a celula atraves do MMS, disponibilizando primitivas que permitem a
leitura e a escrita de variaveis definidas no VMD-Celula (do qual falaremos mais
Local Support Environment.
CAPITULO 3. A ARQUITECTURA NAVCIM 68
a frente). Igualmente atraves do MMS, este segundo servico disponibiliza ainda
primitivas relacionadas com a deteccao de eventos.
A necessidade desta interface e relativa. De facto, a possibilidade de modificar
dinamicamente a configuracao da celula nao e imprescindıvel e a interaccao por
MMS com a celula, alem de nao ser obrigatoria, pode ser realizada de outras
formas, por exemplo utilizando a SWCP. No entanto, a modificacao dinamica da
configuracao pode ser extremamente util durante o desenvolvimento do sistema
de supervisao, ao permitir a adaptacao dos parametros durante a sua execucao.
Daı a existencia desta interface.
� Interface de dados, eventos e alarmes:
Devido ao facto de os dados relativos aos processos industriais se encontrarem
armazenados em repositorios do sistema de ficheiros, as aplicacoes de supervisao
terao de aceder a estes repositorios na realizacao das accoes para que foram
programadas. Como ja foi assinalado, as primitivas de sistema que permitem
manipular os ficheiros podem ser utilizadas no acesso aos repositorios de dados
da plataforma NavCim. Assim, os mecanismos normalmente disponıveis nas
aplicacoes para acesso aos ficheiros podem tambem ser utilizados para aceder
aos dados dos processos.
No entanto, dado que a organizacao dos dados nos repositorios obedece a
algumas regras, as aplicacoes sao responsaveis pelo conhecimento dessas regras
no caso de acederem directamente aos ficheiros. Para libertar as aplicacoes
desta responsabilidade, a arquitectura NavCim fornece um modulo de interface
que permite as aplicacoes acederem aos repositorios de informacao, atraves da
utilizacao de primitivas orientadas aos dados de supervisao e nao ao conteudo
binario dos ficheiros.
Esta interface contem funcoes de acesso aos repositorios de tempo-real, de dados
pre-processados, de eventos e de alarmes. E de referir que esta e uma interface
de programacao, e que por isso nao podera ser utilizada por aplicacoes ja
construıdas.
CAPITULO 3. A ARQUITECTURA NAVCIM 69
3.3.3 Modulos Nucleares
A ultima categoria de modulos, os constituintes da plataforma, engloba todos os
modulos que permitem a concretizacao das funcionalidades proprias da arquitectura
NavCim. Nesta categoria, os modulos definidos resultam apenas de uma divisao
logica da plataforma, divisao esta que podera nao ser visıvel em termos da arquitectura
de software, mas que sera certamente util para a analise do funcionamento interno da
plataforma. Assim, estao definidos os seguintes modulos:
� Configuracao e Inicializacao:
A necessidade de um modulo de configuracao e inicializacao parece-nos evi-
dente. De facto, durante o arranque do sistema e necessario realizar determi-
nadas tarefas de inicializacao, de acordo com a configuracao estabelecida. Por
exemplo, e necessario criar e inicializar as estruturas internas de informacao, criar
as associacoes com os dispositivos e desencadear a execucao de outros modulos
do sistema.
A execucao deste modulo nao se limita a fase de arranque do sistema. Na
verdade, dado que lhe cabem todas as responsabilidades relativas a configuracao
do sistema e dado que se pretende que essa configuracao possa ser modificada
durante a execucao, estara permanentemente activo e sera capaz de interagir com
o utilizador por intermedio do modulo de interface atras descrito.
� VMD-Celula:
Como ja foi dito, a arquitectura NavCim proporciona as aplicacoes de supervisao
a visibilidade dos dados industriais. No entanto, para a execucao de accoes de
controlo e necessario aceder aos proprios dispositivos, o que implica tambem a
sua visibilidade.
Na arquitectura NavCim os dispositivos sao representados por VMDs. Dado
que um VMD e uma entidade autonoma, visıvel e acessıvel a qualquer aplicacao,
mesmo do nıvel de gestao, seria possıvel aceder-lhe directamente. Contudo, a
arquitectura NavCim propoe uma solucao diferente, mais coerente com a visao
hierarquica do sistema, baseada na constituicao de um VMD unico ao nıvel de
celula, representativo de todos os VMDs localizados nessa celula.
CAPITULO 3. A ARQUITECTURA NAVCIM 70
Desta forma, cada entidade da plataforma NavCim constitui em si um VMD, a
que chamamos VMD-Celula, que disponibiliza todas as variaveis dos dispositi-
vos a ela ligados. E a esse VMD que as aplicacoes de controlo se associam para
interagir com os dispositivos, podendo, para tal, utilizar qualquer uma das pri-
mitivas definidas no protocolo MMS. E de referir que a interaccao entre as aplica-
coes e o VMD-Celula podera ser efectuada atraves de um modulo de interface, o
qual disponibiliza um leque de primitivas limitado (oferecendo apenas as mais
comuns), mas simplifica a construcao das aplicacoes.
� Coleccao de dados:
O modulo de coleccao de dados e o elemento fundamental na interaccao entre a
plataforma NavCim e os dispositivos. A sua missao consiste na recolha periodica
de dados dos processos industriais para actualizacao dos repositorios de tempo-
-real, onde e mantida a imagem desses processos. A comunicacao com os VMDs
dos dispositivos e realizada por MMS, utilizando em exclusivo a primitiva de
leitura de variaveis.
Sendo certo que num sistema de supervisao e essencial a recolha de dados, e
natural que a arquitectura NavCim, desempenhando o seu papel de arquitectura
de suporte a construcao de sistemas de supervisao, assuma integralmente essa
responsabilidade. A existencia deste modulo deve-se, portanto, a necessidade da
recolha de dados pela plataforma NavCim.
� Processamento de dados:
As especificacoes do sistema de supervisao implicam por vezes a necessidade de
utilizacao de dados que correspondem nao a uma imagem em tempo-real dos
processos, mas a um conjunto de imagens relativas a um intervalo de tempo.
Estas imagens permitem obter informacoes acerca da evolucao dos processos e,
utilizando funcoes de processamento de dados, realizar analises estatısticas.
Dado que a arquitectura NavCim pretende simplificar a construcao dos sistemas
de supervisao, e conveniente que as funcionalidades de pre-processamento refe-
ridas estejam integradas na plataforma. Assim, o modulo de pre-processamento
de dados e a entidade da plataforma NavCim responsavel pela producao dos
dados estatısticos, centrando a sua actuacao na memorizacao das sucessivas
CAPITULO 3. A ARQUITECTURA NAVCIM 71
imagens dos processos industriais (recolhidas pelo modulo de coleccao de da-
dos) e na actualizacao dos repositorios onde sao armazenados os dados pre-
processados.
� Arquivo de dados:
O modulo de arquivo de dados aglomera as responsabilidades da plataforma
NavCim no tocante a interaccao com as bases de dados existentes no sistema
de supervisao. Estas bases de dados, utilizadas pelas aplicacoes de supervisao,
possuem interfaces normalizadas de acesso que permitem a sua manipulacao.
De acordo com a configuracao estabelecida, o modulo de arquivo utiliza uma
destas interfaces e armazena numa base de dados as informacoes de tempo-
real ou estatısticas que, a partir desse momento, passam a constituir informacao
historica sobre o processo.
� Gestao de Eventos:
A necessidade do modulo de gestao de eventos prende-se com a forma como os
eventos gerados pelos dispositivos industriais sao assinalados as aplicacoes de
supervisao. Uma vez que os dispositivos sao representados por VMDs, sao estes
que, utilizando as primitivas adequadas do MMS, comunicam as entidades que
a eles estao associadas a ocorrencia de eventos. A celula NavCim, sendo a unica
entidade ligada aos VMDs dos dispositivos, ira receber estes eventos e devera ser
responsavel pela sua gestao.
O modulo de gestao de eventos, para alem da capacidade de os receber,
tem como obrigacoes a actualizacao dos repositorios referentes aos eventos,
complementando a accao do modulo de coleccao, e a activacao do modulo
VMD-Celula, que devera, por sua vez, comunicar o evento a todas as entidades
associadas a celula (que podem ser aplicacoes de supervisao ou outras celulas).
� Gestao de Alarmes:
A programacao de condicoes de alarme e uma funcionalidade comum nos
sistemas SCADA. Ela e fundamental no ambito da supervisao de sistemas
industriais, pois constitui uma forma muito simples de deteccao de situacoes
anormais e permite a sua rapida resolucao. Consideramos que a gestao de
alarmes deveria ser uma competencia da plataforma NavCim nao so devido
CAPITULO 3. A ARQUITECTURA NAVCIM 72
ao seu caracter de funcionalidade basica, mas tambem porque dessa maneira
poderiam ser aproveitadas as capacidades de distribuicao ou de escalabilidade
da arquitectura para melhorar a gestao.
Essencialmente, este modulo e activado sempre que sao produzidos novos dados
de supervisao, quer sejam relativos a imagem em tempo-real dos processos ou a
resultados de pre-processamento de dados, verificando se esses dados reflectem
alguma das condicoes de alarme previamente configuradas. Em caso afirmativo,
o modulo de gestao de alarmes pode realizar uma ou varias das seguintes accoes:
actualizar o repositorio que descreve o estado do alarme; gerar um evento que e
comunicado ao modulo de gestao de eventos; actuar nos dispositivos.
� Servico de Tempo Global:
A necessidade de um servico de tempo global incorporado na arquitectura
NavCim e justificada, por um lado, pelo facto de esta ser distribuıda e, por outro,
pelo facto de algumas aplicacoes necessitarem de referencias temporais para
realizarem determinadas accoes de supervisao. Se nao forem dadas garantias
mınimas quanto a coerencia relativa de tempos obtidos em celulas distintas,
nao sera conveniente tomar decisoes de supervisao baseadas nessas marcas
temporais.
O modulo de tempo global e o mais autonomo de todos os modulos da
plataforma NavCim. A sua missao unica, do ponto de vista funcional, e a de
providenciar marcas temporais sempre que tal lhe for solicitado. A globalidade
do servico de tempo restringe-se as celulas NavCim que se encontrem na mesma
rede local.
A descricao pormenorizada de cada um destes modulos, bem como das interac-
coes que se verificam entre eles, sera realizada na seccao 3.5, relativa ao modelo
computacional.
3.4 Modelo do Fluxo de Informacao
Nesta seccao descrevemos a arquitectura NavCim do ponto de vista do fluxo de in-
formacao. Alguns aspectos foram ja abordados na descricao geral da arquitectura, mas
CAPITULO 3. A ARQUITECTURA NAVCIM 73
serao agora mais profundamente explorados, nomeadamente os aspectos relacionados
com o tipo, os repositorios e a distributividade da informacao.
3.4.1 Dados de Supervisao e Controlo
Nos sistemas de supervisao e controlo, a informacao constitui o objecto central
em torno do qual se posicionam as aplicacoes e em funcao do qual todo o sistema e
concebido. De facto, a concepcao de um sistema de supervisao ou de uma arquitectura
de suporte deve ter em grande atencao a forma como a informacao circula no sistema
e e utilizada pelas aplicacoes, pois tal tem reflexos inevitaveis no seu desempenho e na
sua distributividade.
De uma forma geral, pode considerar-se que nos sistemas de supervisao e con-
trolo existem essencialmente dois fluxos de informacao, correspondentes aos dados
provenientes dos processos industriais e aos dados enviados para esses processos. A
informacao que constitui cada um destes fluxos tem caracterısticas especıficas, sendo
por isso natural que os factores relacionados com o seu transporte, tratamento e ar-
mazenamento apresentem algumas diferencas. Quais sao, entao, as caracterısticas de
cada um destes tipos de informacao e que reflexos tem na arquitectura do sistema em
termos dos mecanismos para transporte da informacao?
Antes de mais, parece-nos importante deixar clara a importancia relativa de
cada um dos dois fluxos de informacao que aqui consideramos. Para os sistemas
cujo objectivo e unicamente a supervisao dos processos industriais, apenas os dados
provenientes dos dispositivos tem importancia. De facto, nao sendo necessario realizar
quaisquer accoes de controlo, nunca serao enviados dados para os dispositivos, nao
existindo, portanto, qualquer fluxo de informacao de controlo. Quando, para alem da
supervisao, se pretende igualmente controlar os dispositivos, tal como acontece com
a arquitectura NavCim, ambos os fluxos de informacao se tornam importantes. De
qualquer forma, as potencialidades do sistema serao essencialmente reservadas para
as tarefas de supervisao, pois estas implicam uma actividade consideravelmente mais
elevada. Na realidade, a maioria das actividades intensivas de controlo sao realizadas
localmente aos controladores dos dispositivos (PLCs, controladores PID e outros).
Na arquitectura NavCim os processos industriais sao representados por VMDs,
CAPITULO 3. A ARQUITECTURA NAVCIM 74
entidades que comunicam exclusivamente atraves do protocolo MMS. Este protocolo,
tendo sido concebido com o intuito de se adaptar as exigencias dos ambientes
industriais, dispoe naturalmente das capacidades necessarias para veicular informa-
cao de supervisao e de controlo e, por essa razao, pode ser utilizado como meio unico
de ligacao entre a plataforma NavCim e os dispositivos. Nesta ligacao, o mecanismo
de comunicacao utilizado e, assim, independente do sentido do fluxo de informacao.
Poderia entao pensar-se na utilizacao exclusiva deste protocolo para transporte
de toda a informacao do sistema, resolvendo definitivamente as duvidas quanto
aos mecanismos de comunicacao utilizados. No entanto, tendo em consideracao
os requisitos impostos na definicao da arquitectura, esta solucao teria um impacto
negativo relativamente a heterogeneidade de aplicacoes e ao desempenho do sistema.
De facto, e considerando apenas os dados de supervisao, a utilizacao exclusiva
do MMS tornaria inviavel a utilizacao do software ja existente que nao dispusesse
dessa interface. Por outro lado, implicaria uma sobrecarga na comunicacao entre
a plataforma NavCim (ou os dispositivos) e as aplicacoes, dado que o fluxo de
dados e elevado e neste protocolo as ligacoes sao ponto-a-ponto, comprometendo a
escalabilidade e a expansibilidade.
A solucao proposta pela arquitectura NavCim para o acesso aos dados de super-
visao nao so evita estes problemas, como o faz de uma forma bastante elegante. E
utilizada uma aproximacao fundamentalmente baseada em estado. Em cada celula
industrial, a plataforma NavCim constroi uma imagem dos VMDs dessa celula, que
armazena no sistema de ficheiros local. Assim, em cada celula existe um repositorio
de informacao que contem o estado actualizado dessa celula. Este repositorio pode ser
considerado de “tempo-real” pois e construıdo a um nıvel suficientemente proximo
dos dispositivos para que se possa garantir a validade temporal dos dados. Estes po-
dem ser obtidos explicitamente a pedido da plataforma ou entao por eventos rece-
bidos pela mesma. Repare-se que mesmo os eventos indicados pelos VMDs passam
a fazer parte do estado da celula, sendo da responsabilidade das aplicacoes a detec-
cao da ocorrencia desses eventos. Por esta razao podem levantar-se alguns problemas
relativos a reactividade do sistema, que serao discutidos mais adiante.
O repositorio e entao distribuıdo por todos os nıveis hierarquicos do sistema, de
modo a que qualquer aplicacao tenha visibilidade sobre o estado da celula e possa
CAPITULO 3. A ARQUITECTURA NAVCIM 75
utilizar esses dados. Do ponto de vista das aplicacoes o acesso aos dados e sempre
feito localmente, utilizando a interface disponıvel no sistema, tal como para qualquer
ficheiro. Consegue assim evitar-se que as aplicacoes tenham de saber comunicar
atraves do MMS e tenham de construir a sua propria imagem dos VMDs.
De certa forma, pode dizer-se que esta aproximacao se adapta bem ao tipo de dados
que o estado das celulas representa. De facto, podendo existir multiplas aplicacoes
acedendo simultaneamente a estes dados, faz sentido que exista apenas uma entidade
responsavel pela construcao e manutencao da imagem da celula, acedendo as outras
apenas a esta imagem. Em vez de uma aproximacao apenas baseada em eventos, onde
cada aplicacao seria responsavel por construir a sua imagem da celula, tem-se uma
aproximacao baseada em estado, partilhado por todas as aplicacoes.
Nao podemos deixar de referir, no entanto, que o acesso directo aos VMDs por
parte das aplicacoes nao esta vedado pela plataforma. Em certas situacoes esta
possibilidade podera revelar-se muito util, nomeadamente no que respeita a deteccao
de eventos gerados pelos VMDs.
Em termos do fluxo de dados de supervisao, e ainda necessario referir a existencia
de um repositorio contendo os dados que permitem reproduzir os aspectos relevantes
da historia dos processos industriais. Este repositorio, contendo dados estaveis, pode
ser construıdo pela plataforma NavCim ou por quaisquer outras aplicacoes, e consiste,
em princıpio, numa base de dados relacional. A construcao e feita a custa da leitura
cıclica de dados contidos nos repositorios de tempo-real, que sao introduzidos na base
de dados utilizando as instrucoes SQL adequadas. Esta construcao pode tambem ser
desencadeada por eventos ou pela deteccao de situacoes de alarme.
Relativamente aos dados de controlo, os inconvenientes apontados na utilizacao
exclusiva do MMS para a comunicacao nao sao muito relevantes, pois o fluxo de dados
de controlo e normalmente reduzido e originado por aplicacoes muito especıficas ou
mesmo pela propria plataforma NavCim (atraves do modulo de alarmes) que podem
facilmente utilizar a interface MMS.
Todo o percurso de uma mensagem de controlo, desde a sua geracao ate ao seu
tratamento, pode ser visto como um encadeado de eventos que ocorrem em diversas
entidades do sistema. Como nenhuma destas entidades regista estes eventos (pois nao
CAPITULO 3. A ARQUITECTURA NAVCIM 76
existe essa necessidade) ou, por outras palavras, como estes nunca sao transformados
em estado, pode dizer-se que o fluxo de dados de controlo corresponde a uma
aproximacao puramente baseada em eventos.
A figura 3.7 representa, de uma forma geral, os fluxos de dados de controlo e de
supervisao na arquitectura NavCim. Nesta figura nao tivemos qualquer intencao de
representar as potencialidades da plataforma no respeitante a distribuicao dos dados.
Assim, encontramos o caso mais comum, em que as aplicacoes de supervisao acedem
aos dados de tempo-real, e as aplicacoes de gestao acedem aos dados estaveis, o que
pode nem sempre acontecer. Pode dizer-se que a configuracao representada e apenas
uma das varias possıveis.
Em resumo, e como esta representado na figura, o fluxo de dados de supervisao
e consideravelmente mais intenso que o fluxo de dados de controlo. Em cada celula
e mantida uma imagem do estado dessa celula. A imagem dos VMDs, bem como os
dados pre-processados pela plataforma, sao armazenados num repositorio de tempo-
-real local a cada celula de fabrico. Este repositorio e visıvel nos nıveis hierarquica-
mente superiores atraves da distribuicao do sistema de ficheiros. Assim, a construcao
de um repositorio de informacao estavel, contendo a historia dos processos industriais,
pode ser realizada nos nıveis superiores.
Os repositorios de informacao sao acedidos pelas aplicacoes de supervisao ou de
gestao. Em funcao da evolucao do sistema, estas poderao necessitar de actuar sobre
os dispositivos. Tal podera ser feito enviando os dados de controlo para a plataforma
NavCim ou directamente para os VMDs, em ambos os casos utilizando o protocolo
MMS. A aproximacao utilizada para o fluxo de dados de controlo, ao contrario da
utilizada para os dados de supervisao, e apenas baseada em eventos.
3.4.2 Distributividade da Informacao
Um dos aspectos que focamos com grande relevo no inıcio deste capıtulo foi a
obrigatoriedade de conceber uma arquitectura distribuıda, requisito essencial para
a escalabilidade e expansibilidade do sistema. Constituindo a informacao o objecto
fundamental tratado pela arquitectura proposta, interessa analisar as possibilidades
de distribuicao dessa informacao. Encontrando-se esta armazenada essencialmente
CAPITULO 3. A ARQUITECTURA NAVCIM 77
5)��8 5)���5)��9 =�=�=�=�=
������������ ������������ ������������=�=�=�=�=
������������/�� �"%�%���"��%
(����
(����
*��+�������� ���� *��+����������)�,�
-� ���>����� ����'��
-� ���>������:
�&"'�&��%(��%
�"��%���!�%%"��%
�����������
$����0#�
Figura 3.7: Fluxo de informacao. Dados de supervisao e de controlo.
CAPITULO 3. A ARQUITECTURA NAVCIM 78
sob duas formas, em repositorios de tempo-real e em repositorios estaveis, faremos a
analise separada da distributividade de cada um destes repositorios.
3.4.2.1 Distributividade da Informacao de Tempo-Real
Nos ambientes industriais, onde se pretende aplicar a arquitectura aqui descrita, a
informacao utilizada na supervisao esta em constante mutacao. Como e ja sabido, esta
informacao e armazenada em repositorios que denominamos de tempo-real, consti-
tuindo estes os polos distribuidores da informacao, a volta dos quais de posicionam
as aplicacoes do sistema. Esta aproximacao, sendo trivial, representa um claro avanco
relativamente a aproximacao seguida por muitos sistemas existentes.
Tradicionalmente, a informacao recebida dos dispositivos industriais e apenas uti-
lizada localmente as aplicacoes que a recebem (por exemplo, SCADAs), podendo even-
tualmente ser disponibilizada para outras aplicacoes atraves do seu armazenamento
em repositorios estaveis (por exemplo, bases de dados). Na execucao distribuıda de
aplicacoes, tal solucao revela-se impraticavel se as exigencias de tempo-real ou de de-
sempenho forem elevadas. Restara a estas aplicacoes, caso tal seja possıvel, aceder
directamente aos dispositivos para a recolha da informacao necessaria.
Na nossa arquitectura, gracas aos eficientes mecanismos de distribuicao utilizados,
os repositorios de tempo-real para partilha da informacao podem ser acedidos por
qualquer aplicacao independentemente da sua localizacao (figura 3.8), mantendo
elevados nıveis de desempenho e de tempo-real. O transporte da informacao entre
os diversos nos da rede e feito transparentemente pelos mecanismos de distribuicao.
Por isso, do ponto de vista das aplicacoes o acesso aos repositorios de tempo-real e
sempre feito localmente.
A distributividade da informacao de tempo-real e conseguida atraves da utiliza-
cao de um sistema de ficheiros distribuıdo. Existem actualmente diversos sistemas de
ficheiros distribuıdos [Satyanarayanan 90, Borghoff 92], mas os mais divulgados sao o
NFS e o AFS� [Satyanarayanan 85]. Na arquitectura NavCim o sistema proposto e o
NFS, uma vez que este e disponibilizado sem custos adicionais em diversas sistemas
operativos. Convem referir que a utilizacao do NFS nao compromete as caracterısticas
�Andrew File System.
CAPITULO 3. A ARQUITECTURA NAVCIM 79
(�����: �8
(�����: �9
����$����0#�
�: �8
����$����0#�
�: �9
-� ���>���: �8
-� ���>���: �9
-� ���>��.�����
����
�8
����
�9
Acessos locais
Acessos remotos
Figura 3.8: Distributividade da informacao de tempo-real.
de tempo-real da informacao, no sentido lato. De facto, como veremos em maior
pormenor no capıtulo 4, e possıvel configurar o sistema de ficheiros de modo a que
as actualizacoes da informacao se repercutam remotamente no mais curto espaco de
tempo, ou seja, garantindo a “frescura” da informacao independentemente da localiza-
cao das aplicacoes.
Em termos de desempenho, pode dizer-se que dificilmente se conseguiriam obter
melhores resultados do que aqueles apresentados pelo NFS ou pelo AFS. Tal pode ser
justificado pelo facto de estes estarem intrinsecamente ligados ao sistema operativo e,
como tal, usufruırem de vantagens em termos de prioridade de execucao face a aplica-
coes do utilizador.
O facto de os repositorios serem ficheiros apresenta dois aspectos positivos que
cabe referenciar:
a) A interface de acesso e uniforme e bem conhecida, permitindo que sejam utilizados
os mecanismos de acesso ja existentes, e evitando a necessidade de aprendizagem
ou utilizacao de uma nova interface, eventualmente nao suportada.
b) Resolve problemas de heterogeneidade de aplicacoes, pois os ficheiros constituem
CAPITULO 3. A ARQUITECTURA NAVCIM 80
o mecanismo normalizado de armazenamento de informacao, sendo acessıveis
por todas as aplicacoes.
3.4.2.2 Distributividade da Informacao Estavel
A par da informacao relativa a evolucao dos processos industriais, os sistemas
de supervisao utilizam informacao sobre a historia dos processos, guardada em
repositorios de informacao estavel. A arquitectura NavCim nao condiciona a forma
como e armazenada e distribuıda esta informacao, pois pressupoe a utilizacao dos
recursos e das configuracoes ja existentes. Assim, permite tambem que o sistema possa
evoluir, continuando salvaguardados os pressupostos contidos na arquitectura.
Na figura 3.9 estao representadas tres aproximacoes respeitantes ao armazena-
mento e distribuicao da informacao estavel, todas elas passıveis de integracao com
a plataforma NavCim, que podem ser entendidas como modelos representativos da
generalidade das configuracoes possıveis.
Na primeira aproximacao, cada celula industrial possui a sua propria base de
dados local (uma base de dados simples, centralizada, tal como ORACLE, Ingres ou
Access) , contendo apenas os dados estaveis relativos a essa celula. Nesta situacao
nao existe uma visao integrada dos dados estaveis das diversas celulas. Se existirem
aplicacoes num nıvel de gestao que tenham de aceder a multiplos fragmentos, terao
de o fazer atraves de acessos remotos, explicitamente dirigidos as bases de dados
ou as celulas pretendidas. Pode assim dizer-se que neste caso a distributividade da
informacao estavel e apenas conseguida atraves da utilizacao de protocolos dedicados
de comunicacao, nunca sendo transparente a localizacao da informacao. Este tipo de
configuracao e normalmente encontrado em ambientes de reduzida dimensao, onde
todos os recursos estao integrados numa unica maquina, e existe amiude apenas uma
celula.
A figura 3.9.b) representa uma base de dados centralizada (do tipo das enumaradas
no caso anterior), unica, que e partilhada por todas as celulas do sistema (utilizando
mecanismos de acesso remoto tais como o RDA�� ou o Ingres NET). Os acessos
representados sao todos remotos por uma questao de generalidade. De facto, nao
��Remote Database Access.
CAPITULO 3. A ARQUITECTURA NAVCIM 81
(�����: �8
(�����: �9
�������/��
�: �8
(����.�����
�������/��
�: �9
(�����: �8
(�����: �9
�������/��
�: �8?
�: �9
(����.�����
(�����: �8
(�����: �9
�������/��
�: �8
(����.�����
�������/��
�: �9
�������/��
�: �8?
�: �9
a) SGBD local à célula
b) SGBD remoto
c) SGBDdistribuído
Acessos locais
Acessos remotos
Figura 3.9: Distributividade da informacao estavel.
e obrigatorio que a base de dados se encontre numa plataforma dedicada, remota a
todos os outros nos computacionais. E igualmente possıvel, por exemplo, que esta se
encontre numa das celulas do sistema. Na figura e ainda possıvel observar que a cada
celula corresponde uma parte especıfica da base de dados, que aquela e responsavel
por actualizar. As aplicacoes que se encontram no nıvel de gestao tem, no entanto,
visibilidade sobre a totalidade da informacao das celulas industriais, tendo de aceder
apenas a um repositorio fısico. Tal como na situacao anterior, os acessos remotos
exigem a utilizacao de protocolos proprietarios, a custa dos quais se garante tambem
a distributividade da informacao. Tipicamente, esta e a aproximacao que se encontra
em empresas de media envergadura constituıdas por algumas celulas de fabrico.
Finalmente, a ultima aproximacao diz respeito a uma base de dados distribuıda
(por exemplo, Distributed Ingres). O acesso ao repositorio de informacao estavel e
CAPITULO 3. A ARQUITECTURA NAVCIM 82
sempre feito localmente, mesmo que a informacao acedida esteja fisicamente guardada
num local remoto. Todas as copias da base de dados sao coerentes, apesar desta conter
a informacao referente a todas as celulas. Qualquer actualizacao efectuada numa das
copias sera transparentemente transmitida a todas as outras. Todos os mecanismos de
comunicacao necessarios para a distribuicao da base de dados sao internos a mesma.
A distributividade da informacao esta assim automaticamente garantida.
3.4.3 Eventos e Estado
Na arquitectura NavCim a actividade das aplicacoes de supervisao baseia-se na
leitura cıclica de dados contidos em repositorios de informacao, que representam o
estado da celula. E esta a aproximacao preferencial seguida pela arquitectura. A outra
aproximacao seria basear a actividade das aplicacoes em eventos indicativos da evolu-
cao do estado da celula, ou seja seguir uma aproximacao baseada em eventos.
Ja sabemos que o estado da celula e representado pela informacao contida em
repositorios de tempo-real, existentes em cada celula. Sabemos tambem que a constru-
cao destes repositorios e realizada pela plataforma NavCim, atraves dos seus modulos
de coleccao de dados e de gestao de eventos. De facto, os dados armazenados nos
repositorios de tempo-real podem provir de eventos assinalados pelos VMDs da celula,
em vez de serem explicitamente recolhidos atraves de pedidos de leitura de variaveis.
Convem entao discutir as implicacoes que advem do facto de os eventos recebidos
dos VMDs passarem a constituir estado, em vez de serem explicitamente assinalados
a todas as entidades neles interessadas (figura 3.10).
A aproximacao seguida, baseada em estado, pode efectivamente levantar alguns
problemas na perspectiva do controlo do sistema. Aquando da ocorrencia de eventos,
a rapidez de resposta das aplicacoes de controlo passa a estar dependente da periodici-
dade com que estas aplicacoes consultam o estado da celula. A criticalidade das accoes
de resposta torna-se nesta situacao um factor determinante das opcoes a tomar: ou as
aplicacoes sao suficientemente rapidas para conseguirem detectar a tempo a alteracao
do estado da celula, ou se torna indispensavel a utilizacao de mecanismos baseados
em eventos. Neste ultimo caso, convem assinalar que a utilizacao de eventos nao esta
dissociada da transformacao em estado. Repare-se que a escrita num ficheiro pode
ser vista como um evento, podendo eventualmente tirar-se partido disso para detectar
CAPITULO 3. A ARQUITECTURA NAVCIM 83
5)�0�:
5)�
������������
(����#������7���
�����������
-� �����
-� �����
-� ������������
�����
���������
� ����
������
���������
Figura 3.10: Transformacao de eventos em estado.
alteracoes do estado.
Em ultimo caso, tal como esta representado na figura, existe a possibilidade de
utilizacao da interface MMS para ligacao das aplicacoes a celula NavCim. Desta
forma, os eventos recebidos pela plataforma serao propagados por todas as associa-
coes estabelecidas. Note-se tambem que do lado da plataforma NavCim todo o
processamento e baseado em eventos. Assim, e ainda possıvel (e talvez desejavel)
que algumas accoes de controlo possam ser delegadas na plataforma, para serem
concretizadas pelo modulo de alarmes.
No caso de aplicacoes de supervisao, os eventos vao sendo processados a veloci-
dade de execucao dessas aplicacoes. Como todos os eventos sao estampilhados com
marcas temporais, tal como a informacao descritiva do estado da celula, esta salva-
guardada a possibilidade de ordenacao dos eventos face a evolucao dos processos.
3.4.4 Longevidade da Informacao
Pode dizer-se que toda a informacao de supervisao acessıvel as aplicacoes se
enquadra numa das seguintes tres categorias:
CAPITULO 3. A ARQUITECTURA NAVCIM 84
� Informacao de tempo-real, nao processada, correspondente ao valor das
variaveis existentes nos VMDs. Esta informacao reflecte uma imagem fiel dos
processos industriais;
� Informacao de tempo-real pre-processada, resultante da intervencao do modulo
de pre-processamento de dados da plataforma. Esta informacao permite obter
indicacoes sobre o comportamento dos processos em intervalos de tempo;
� Informacao estavel, resultante do arquivo permanente de dados pre-processados
e nao pre-processados. Esta informacao constitui a historia dos processos e
permite reconstituir a sua evolucao.
As duas primeiras categorias englobam dados cuja longevidade e limitada, ou
seja, dados que apenas estao disponıveis durante algum tempo, apos o qual serao
substituıdos por dados novos. Eles representam um estado, que vai sendo actualizado.
Os dados nao pre-processados, ou dados em bruto, sao normalmente utilizados
para concretizar as representacoes graficas (sinopticos) dos processos industriais.
Assim, a sua frequencia de actualizacao tem de ser bastante elevada, tipicamente na
ordem das dezenas de milisegundos. Os dados pre-processados podem igualmente
ser actualizados muito frequentemente, dependendo do fim a que se destinam. De
qualquer forma nao existe qualquer limitacao por parte da plataforma quanto a
frequencia com que as accoes de processamento se efectuam. Convem assinalar que
os dados relativos a eventos, recebidos pelo modulo de gestao de eventos, constituem
igualmente dados em bruto. No entanto, a longevidade da informacao relativa a
um evento depende apenas do intervalo de tempo que decorre entre dois eventos
consecutivos. Os dados em bruto sao tambem utilizados pelo modulo de pre-
processamento de dados da plataforma NavCim (figura 3.11).
O pre-processamento de dados consiste, resumidamente, na aplicacao de funcoes
estatısticas (tais como media ou desvio padrao) a um conjunto de dados formados
por sucessivos valores de dados em bruto, ou seja, por sucessivas imagens dos
processos industriais. O modulo de pre-processamento tem por isso de memorizar
todos os dados que sao utilizados nas accoes de pre-processamento. Obviamente,
a longevidade dos dados pre-processados depende do numero de amostras que e
necessario recolher.
CAPITULO 3. A ARQUITECTURA NAVCIM 85
��:0����������
-�4 �����
Figura 3.11: Longevidade dos dados.
Uma importante faceta do modulo de pre-processamento de dados e a sua
capacidade para encadear accoes de processamento, ou seja, de gerar multiplos nıveis
de dados pre-processados. De certa forma, pode dizer-se que quanto maior for o
nıvel de pre-processamento, maior sera o grau de amadurecimento da informacao
gerada. Os dados gerados por este modulo podem ser uteis para as aplicacoes de
supervisao, no sentido em que fornecem indicacoes estatısticas ou variaveis compostas
(velocidades, taxas, etc.) relativas a evolucao dos processos supervisionados. Sao
tambem uteis para a propria plataforma, pois, podendo ser monitorizados pelo
modulo de alarmes, servem de base para a realizacao de algumas accoes de controlo
estatıstico dos processos.
O modulo de arquivo permite concretizar a ultima etapa no percurso da informa-
cao. Este modulo, tal como o seu nome indica, desempenha a tarefa de arquivar os
dados de tempo-real num repositorio de informacao estavel, ou seja, numa base de
dados. Os dados que sao arquivados podem ser dados em bruto ou pre-processados,
sendo a frequencia de arquivo variavel. No entanto, dado que sao normalmente os
dados pre-processados que sao arquivados, existe uma cooperacao entre o modulo
de pre-processamento e o modulo de arquivo, no sentido de o primeiro assinalar o
segundo sempre que forem gerados novos dados que devem ser arquivados. Para
finalizar, salientamos o facto da informacao arquivada conter marcas temporais, que
permitem nao so a sua posterior ordenacao, como tambem reconstituir exactamente a
CAPITULO 3. A ARQUITECTURA NAVCIM 86
evolucao dos processos industriais.
3.5 Modelo Computacional
Sendo objectivo dos sistemas baseados na arquitectura NavCim a automatizacao
de tarefas de gestao atraves da recolha automatica de dados dos processos de fabrico,
sao de fulcral importancia os modulos arquitecturais relacionados com a manipulacao
dos dados, isto e, com a recolha, transporte, armazenamento, visibilidade e interfaces
de acesso.
Na seccao anterior, a descricao da arquitectura NavCim na perspectiva do fluxo
da informacao centrou-se fundamentalmente nos aspectos estritamente relacionados
com os dados. Os modulos funcionais que interagem com estes dados serao agora
analisados, procedendo-se a descricao do seu funcionamento, das semanticas que
lhes estao associadas, das interdependencias entre modulos e de outros aspectos
que, em cada caso, se demonstrem relevantes. Contudo, comecaremos por tracar
um panorama integrado do funcionamento dos diversos modulos componentes da
arquitectura NavCim, focando posteriormente cada um deles.
3.5.1 Visao Integrada
De uma forma geral, a figura 3.12 resume as relacoes existentes ao nıvel da
plataforma entre os diversos modulos funcionais.
A ligacao da plataforma aos dispositivos industriais processa-se exclusivamente
atraves do modulo SWCP, recorrendo as primitivas definidas no protocolo MMS. O
envio de mensagens para os VMDs dos dispositivos e efectuado pelos modulos de
coleccao de dados e VMD-Celula. Contudo, apenas o ultimo e responsavel pelo envio
de mensagens de controlo, traduzidas no protocolo MMS pela escrita nos VMDs dos
dispositivos.
Verifica-se assim que a separacao do fluxo de dados dos processos e do fluxo de
informacao de controlo, analisada anteriormente numa perspectiva global, e tambem
observada no interior da plataforma. De facto, ao passo que os dados dos processos
circulam atraves dos modulos de coleccao de dados e de eventos, a informacao de
CAPITULO 3. A ARQUITECTURA NAVCIM 87
controlo circula atraves do modulo VMD-Celula.
Sintetizando, a comunicacao com os dispositivos desenrola-se em tres frentes—
materializadas pelos modulos de coleccao de dados, de eventos e VMD-Celula— e
apresenta as seguintes caracterısticas��:
������������
�� �����
- ����
�������
-�4 ���
�����, ����
$����
5)�0�:
-���������� -�������:
�1��(<�
$������@����������������
����������������
����������))�
����������������
!��� ��� ����
!��� ���������
-�����������/��
$��%��
Figura 3.12: Relacoes entre os modulos e a informacao.
Coleccao: A ligacao com o SWCP e bidireccional dado que a primitiva de leitura
de variaveis, a unica primitiva do MMS invocada por este modulo, origina
naturalmente uma resposta. Esta interaccao constitui o mecanismo de construcao
por pedido da imagem dos processos industriais.��Existe ainda um outro ponto de ligacao entre a plataforma e o SWCP, relativo ao estabelecimento das
associacoes com os VMDs da celula, que nao esta representado na figura pelo facto de ser secundario enao estar relacionado com a transferencia de dados.
CAPITULO 3. A ARQUITECTURA NAVCIM 88
Eventos: Este modulo trata as mensagens de informacao enviadas pelos dispositivos.
Como estas mensagens nao requerem qualquer resposta e visto que este modulo
nao invoca primitivas do MMS, a ligacao ao SWCP e unidireccional. A interaccao
levada a cabo por este modulo permite a construcao por evento dos repositorios
de tempo-real.
VMD-Celula: Este modulo pode invocar as primitivas de leitura e escrita do MMS.
A ligacao ao SWCP e, portanto, bidireccional. Os pedidos de leitura de variaveis
efectuados por este modulo sao marginais a plataforma, dado que resultam de
solicitacoes provenientes de aplicacoes externas. Assim, a intervencao deste
modulo no processo de construcao dos repositorios de tempo-real e nula. Atraves
da escrita de variaveis, este modulo permite o controlo dos dispositivos.
Internamente a plataforma, os dados recolhidos pelos modulos de coleccao e de
gestao de eventos podem ser utilizados de quatro formas distintas:
� Podem ser armazenados nos repositorios de tempo-real correspondentes, para
que possam ser utilizados na supervisao;
� Podem ser directamente enviados para o modulo de pre-processamento de
dados, caso estejam configuradas accoes de pre-processamento para esses dados;
� Podem tambem ser enviados para o modulo de alarmes, se forem especificados
em condicoes de alarme;
� Podem ser enviados para o modulo de arquivo, se for pretendido o seu armaze-
namento como informacao permanente.
No caso do modulo de gestao de eventos e possıvel que os eventos recebidos
sejam retransmitidos, igualmente sob a forma de informacoes MMS, para aplicacoes de
supervisao ligadas a celula NavCim. Neste caso, os dados sao internamente enviados
para o modulo VMD-Celula, que se encarregara de realizar as accoes necessarias.
Deve notar-se que o funcionamento interno da plataforma e baseado em eventos,
ou seja, as accoes realizadas pelos diversos modulos sao sempre desencadeadas
por algum acontecimento interno, como seja a coleccao de novos dados. Poderia
conceber-se uma arquitectura em que os modulos fossem totalmente isolados, onde,
CAPITULO 3. A ARQUITECTURA NAVCIM 89
por exemplo, o modulo de pre-processamento fosse ler aos repositorios a informa-
cao escrita pelo modulo de coleccao em vez deste lha enviar directamente, mas isso
significaria a reducao do desempenho da plataforma. A vantagem da aproximacao
baseada em estado apenas faz sentido externamente a plataforma, por uma questao de
partilha de dados e de suporte a heterogeneidade de aplicacoes.
O modulo de pre-processamento actua sobre os dados provenientes de eventos ou
da coleccao de dados e deposita os resultados das suas accoes nos repositorios (de
tempo-real) de dados pre-processados. Pode ainda assinalar e enviar esses dados para
o modulo de alarmes e para o modulo de arquivo.
Neste encadeado de accoes, e se os dados em bruto ou pre-processados que
recebeu verificarem determinadas condicoes pre-configuradas, o modulo de alarmes
desempenha o importante papel de poder comunicar com o modulo VMD-Celula, no
sentido de executar accoes de controlo sobre dispositivos industriais. O modulo VMD-
-Celula pode tambem ser utilizado para gerar mensagens de informacao (eventos), que
serao enviadas as aplicacoes associadas por MMS a plataforma. Alem disso, os alarmes
podem tambem ser arquivados no repositorio estavel, sendo nesse caso enviados para
o modulo de arquivo. Tal como nos casos anteriores, a informacao relativa aos alarmes
pode ainda ser disponibilizada para as aplicacoes atraves do repositorio de tempo-real.
Convem salientar que a informacao originada por qualquer dos modulos e apenas
opcionalmente escrita no repositorio de tempo-real. De facto, e possıvel que os dados
gerados por um modulo se destinem intencionalmente a outro modulo e nao a satisfa-
cao de necessidades das aplicacoes.
O modulo de arquivo e solicitado pelos outros modulos, no sentido de proceder ao
armazenamento de informacao na base de dados do sistema. Para tal tera de utilizar
uma interface de ligacao adequada a base de dados utilizada.
O modulo VMD-Celula pode ser activado por accao de aplicacoes externas ou
por accao dos modulos de alarmes ou de gestao de eventos. No entanto, a activacao
externa consiste na recepcao de mensagens MMS, ao passo que internamente a activa-
cao tera de ser baseada nos mecanismos de comunicacao entre modulos da plataforma.
Globalmente, as suas competencias resumem-se a leitura e escrita de variaveis dos
VMDs e ao envio de informacoes MMS (eventos) para as aplicacoes.
CAPITULO 3. A ARQUITECTURA NAVCIM 90
Em termos dos modulos que compoem a plataforma, resta-nos referir que os
modulos de configuracao e de tempo nao tem um papel interveniente no que respeita
ao fluxo de dados. Ainda assim, o modulo de configuracao e responsavel pelo
atendimento de pedidos provenientes de aplicacoes externas, relativos a modificacao
das accoes executadas pelos modulos de coleccao, processamento, alarmes e arquivo.
O repositorio representado na figura, ligado ao modulo de configuracao, contem
informacao inicialmente utilizada por este modulo para determinar a configuracao
de arranque do sistema. A ligacao e bidireccional pelo facto de este modulo poder
guardar no repositorio a sua configuracao actual.
Internamente a cada celula NavCim, o modulo de tempo disponibiliza as marcas
temporais utilizadas na escrita da informacao nos repositorios de tempo-real. Por isso,
todos os modulos que armazenam informacao nestes repositorios recorrem aos servi-
cos do modulo de tempo. Resta assinalar o facto de existir uma troca de informacao
entre os modulos de tempo de diferentes celulas NavCim, representada na figura 3.12
pela utilizacao da interface TCP/IP.
Finalmente, convem referir que a interface de dados, parte integrante da plata-
forma NavCim, constitui uma forma alternativa de acesso a informacao contida no
repositorio de tempo-real. Na realidade, apenas constitui uma camada que esconde
das aplicacoes a interface de acesso aos ficheiros disponibilizada pelo sistema. O NFS
esta na figura representado como interface para acessos remotos (mas transparentes,
do ponto de vista das aplicacoes) a informacao.
3.5.2 Inicializacao e Configuracao
No capıtulo anterior falamos bastante acerca de aspectos relacionados com a
configuracao dos sistemas SCADA. Tal como nestes, tambem na plataforma NavCim e
necessario configurar as accoes que irao ser realizadas durante a execucao.
As polıticas de configuracao sao diversas. Contudo, em todas elas se recorre a
utilizacao de ficheiros contendo dados de configuracao. A construcao e utilizacao
desses ficheiros e que difere.
Relativamente a construcao dos ficheiros de configuracao existem essencialmente
duas opcoes: a) sao disponibilizadas aplicacoes especıficas que vao guiando o utiliza-
CAPITULO 3. A ARQUITECTURA NAVCIM 91
dor na realizacao dessa tarefa, caso em que o conteudo dos ficheiros lhe e irrelevante
(casos do FactoryLink, do EasyMAP e do Intouch); b) o utilizador e o responsavel pela
edicao desse conteudo, tendo necessariamente de conhecer a sintaxe especıfica de con-
figuracao (como no Processyn).
Os ficheiros podem entao ser utilizados, basicamente de duas formas: a) por aplica-
coes especıficas de compilacao que interpretam as instrucoes de configuracao e que,
com base nelas, criam programas de supervisao executaveis (Processyn); b) por aplica-
coes de supervisao que se executam de acordo com as instrucoes de configuracao
(FactoryLink, EasyMAP e Intouch).
No caso concreto da plataforma NavCim, a construcao dos ficheiros de configura-
cao pode ser levada a cabo pelo utilizador, dado que e utilizada uma sintaxe especıfica
para descricao das instrucoes de configuracao. Na verdade, tal aproximacao nao
invalida que existam aplicacoes dedicadas a criacao dos ficheiros de configuracao,
mas isso e um problema de concretizacao. Relativamente a sua utilizacao, seguimos
a aproximacao b) acima descrita, sendo por essa razao que existe um modulo de
inicializacao e configuracao na plataforma NavCim. E a este modulo que estao
confiadas as responsabilidades de leitura e interpretacao dos ficheiros de configura-
cao, bem como algumas outras atribuicoes de que falaremos seguidamente.
Em termos de fio de execucao, pode dizer-se que este modulo sera o primeiro a
entrar em actividade. Comecara imediatamente a realizar as tarefas de inicializacao do
sistema, com base nas instrucoes de configuracao contidas nos ficheiros, inicializando
as estruturas de dados internas, estabelecendo e configurando as associacoes com os
VMDs industriais e activando os modulos de coleccao de dados, de gestao de eventos
e de tempo.
Se algum dos VMDs nao responder ao pedido de estabelecimento de associacao, a
inicializacao do sistema devera continuar ate ao fim, voltando a tentar-se mais tarde
o estabelecimento dessa associacao. Seria possıvel optar por interromper a execucao
do sistema, mas pensamos que uma solucao do tipo melhor esforco se adequa mais as
exigencias destes sistemas.
Durante a execucao o modulo de configuracao permanece activo, pois e res-
ponsavel pela realizacao de mais algumas tarefas. Uma delas, a que consideramos
CAPITULO 3. A ARQUITECTURA NAVCIM 92
mais importante, consiste no atendimento de pedidos de alteracao da configuracao
do sistema durante a execucao. De facto, esta possibilidade nao e de todo comum
nos sistemas SCADA existentes, sendo por isso de salientar particularmente. A altera-
cao dinamica da configuracao permite realizar ajustamentos as accoes realizadas pelos
modulos da plataforma sem interromper o seu funcionamento, o que se pode revelar
especialmente util em duas situacoes particulares: a) durante o desenvolvimento do
sistema de supervisao, pois nesta fase e necessario proceder a muitos ajustes e, sendo
estes feitos dinamicamente, reduz-se muito o tempo de desenvolvimento; b) em situa-
coes crıticas, quando se observam alteracoes subitas do funcionamento dos processos,
e se pretende alterar rapidamente as accoes de supervisao executadas.
Para enviarem os pedidos de alteracao da configuracao, as aplicacoes utilizam uma
interface de comunicacao proprietaria, disponibilizada pela plataforma e exclusiva
para este fim. Os pedidos sao executados imediatamente apos a sua recepcao. As
primitivas contidas nesta interface serao referidas a medida que formos descrevendo
cada modulo, pois aı o leitor compreendera mais facilmente os motivos da sua
existencia e a sua utilidade.
Outra das funcionalidades concretizadas pelo modulo de configuracao consiste
na possibilidade de se registar num ficheiro a configuracao actual da plataforma. A
necessidade de tal funcionalidade e bastante evidente. De facto, dado que e possıvel
modificar a configuracao dinamicamente, torna-se util poder registar novas configura-
coes para posterior utilizacao. E novamente atraves da interface acima mencionada
que se procede a salvaguarda da configuracao.
Dado que e este modulo o responsavel pelo estabelecimento das associacoes com
os VMDs, podera receber uma indicacao, do modulo de coleccao de dados, de que
uma das associacoes foi terminada (por exemplo por falha de um VMD). Nesta situa-
cao, devera tentar ciclicamente restabelecer a associacao abortada, apos o que avisara o
modulo colector para que este reinicie as accoes de coleccao de dados. De certa forma,
pode afirmar-se que este e um procedimento tipicamente de tolerancia a faltas, pois
torna a plataforma imune a falha temporaria de VMDs. Refira-se apenas o efeito de
paragem que se pode ter, do ponto de vista da informacao contida nos repositorios de
tempo-real.
CAPITULO 3. A ARQUITECTURA NAVCIM 93
3.5.3 VMD-Celula
A existencia deste modulo e, em grande parte, motivada pela necessidade do con-
trolo dos dispositivos. E evidente que as aplicacoes, desde que disponham da pos-
sibilidade de comunicar atraves do protocolo MMS, podem associar-se directamente
aos VMDs industriais, realizando as accoes de controlo sem necessitarem da interven-
cao da plataforma NavCim. No entanto, do ponto de vista arquitectural essa opcao
nao sera a mais correcta, pois implica a criacao arbitraria de ligacoes aos VMDs e
uma consequente perda de eficiencia e da nocao de “celula industrial” transmitida
pela plataforma. Por exemplo, se tres aplicacoes necessitassem de informacao pre-
-processada de um dispositivo, teriam que repetidamente aceder ao mesmo VMD e
pre-processar a informacao, isto em lugar de simplesmente aceder a informacao pre-
-processada pela plataforma.
Parece-nos fundamental que as interaccoes com os VMDs dos dispositivos sejam
delegadas em exclusividade a plataforma NavCim. Assim sendo, a plataforma
funcionara como uma representacao fiel da celula industrial, concentrando todos os
VMDs dessa celula num unico VMD, esse sim, acessıvel as aplicacoes de supervisao
e controlo. Constitui-se deste modo uma estrutura hierarquica de controlo (figura
3.13), onde cada aplicacao tem apenas de se ligar ao VMD representativo da sua celula,
podendo atraves dessa unica ligacao controlar todos os dispositivos que se encontram
no nıvel inferior.
Este modulo e responsavel pela representacao dos VMDs aos quais a plataforma
esta associada. De um ponto de vista estritamente protocolar, essa representacao
consistiria na concretizacao de todas as primitivas definidas no MMS, relativas a todas
as variaveis disponıveis nos VMDs. No entanto, consideramos que as primitivas
fundamentais sao apenas as de leitura e escrita de variaveis, sendo por isso as unicas
exigidas. Em relacao a primitiva de escrita nao existem quaisquer duvidas quanto as
tarefas que devem ser executadas. E apenas necessario identificar o VMD a que se
destina a mensagem recebida e reenvia-la para esse VMD��. Relativamente a leitura de
variaveis pode dizer-se que existem as seguintes aproximacoes:
��As primitivas de escrita e leitura do MMS permitem a referencia simultanea a varias variaveis.Assim, se as variaveis referenciadas numa mensagem forem respeitantes a multiplos VMDs, terao deser enviadas mensagens para todos esses VMDs.
CAPITULO 3. A ARQUITECTURA NAVCIM 94
5)�0�: -� ���>��
�� ��������
-������:
�)�� ����%*+�
5)�0�: -� ���>��
�� ��������
����� ��
5)�
����� ��
5)�
����� ��
5)�
�)�� ���, - "
�)�� ��%��%��%�*���%
-������:
�
5)�0�: -� ���>��
�� ��������
����� ��
5)�
����� ��
5)�
����� ��
5)�
�)�� ���, - "
�)�� ��%��%��%�*���%
-������:
�
-� ���>��
�� ��������
����� ��
5)�
����� ��
5)�
����� ��
5)�
�)�� ���, - "
�)�� ��%��%��%�*���%
-������:
-
5)�0�:
Figura 3.13: Controlo hierarquico proporcionado pelo VMD-Celula.
CAPITULO 3. A ARQUITECTURA NAVCIM 95
� Os pedidos de leitura sao localmente atendidos, sendo para tal necessario que a
plataforma mantenha actualizadas todas as variaveis definidas;
� Os pedidos de leitura sao retransmitidos para os VMDs, sendo necessario esperar
pela resposta destes para se poder responder ao pedido recebido.
Para decidir qual a melhor das opcoes e importante observar que a leitura de
variaveis apenas devera ser realizada no contexto de accoes de controlo e nunca no
contexto de accoes de supervisao. Como ja foi visto, a arquitectura define uma solucao
especıfica para o acesso aos dados de supervisao, a qual tenta explicitamente evitar
que as aplicacoes tenham de aceder directamente aos dispositivos.
Tendo em conta que a leitura de variaveis e necessaria apenas ocasionalmente, no
contexto de accoes de controlo (por exemplo, para confirmar o sucesso de uma ac-
cao de escrita), a ineficiencia da primeira opcao parece-nos evidente. De facto, tal
opcao implicaria um elevado esforco de comunicacao com todos os VMDs, o qual
poderia nunca vir a ser aproveitado. Assim, o modulo VMD-Celula funciona de acordo
com a segunda aproximacao, que, apesar de implicar uma maior lentidao de resposta,
contribui para um melhor desempenho global da plataforma.
A identificacao dos VMDs para onde se devem reenviar as mensagens tem de ser
feita com base no nome das variaveis. No entanto, dado que na mesma celula podem
existir VMDs com nomes de variaveis identicos, e necessario que no VMD-Celula se
distingam esses nomes. Uma solucao simples e definitiva consiste na associacao ao
nome da variavel do nome do VMD (que e unico no sistema) onde esta definida. Desta
forma, passara a ser necessario traduzir os nomes das variaveis, antes de reenviar as
mensagens para os VMDs.
Durante a execucao da plataforma, o modulo VMD-Celula e ainda responsavel
por mais duas funcionalidades: pelo envio de mensagens de escrita para os VMDs,
solicitado pelo modulo de alarmes, e pelo envio de mensagens de informacao para as
aplicacoes, solicitado pelo modulo de gestao de eventos. Ambas as funcionalidades sao
invocadas internamente a plataforma, nao sendo por isso utilizada qualquer primitiva
do MMS para transferir a informacao entre os modulos. Assim, a construcao das
mensagens MMS sera realizada pelo modulo de representacao.
CAPITULO 3. A ARQUITECTURA NAVCIM 96
3.5.4 Coleccao de Dados
O modulo colector de dados e o responsavel pela construcao da imagem em tempo-
-real dos processos industriais. A recolha de dados e feita utilizando a primitiva
de leitura de variaveis do MMS, sendo os dados armazenados em ficheiros locais a
plataforma. A actividade deste modulo nao depende dos VMDs existentes na celula,
mas sim das accoes de coleccao de dados definidas na configuracao. So sera construıda
a imagem de um VMD se tal for explicitamente requerido.
A definicao de uma accao de leitura (ou de coleccao) consiste na especificacao dos
seguintes argumentos:
� Variavel ou variaveis que devem ser lidas;
� Repositorio utilizado para armazenamento;
� Periodicidade da accao de leitura.
A execucao das accoes de leitura e desencadeada periodicamente. A cada accao
devera estar associado um temporizador��, que sera utilizado pelo modulo de coleccao
para detectar os instantes em que devera executar novamente a respectiva accao. Como
podem estar definidas multiplas accoes de leitura, sera necessario prever a ocorrencia
de situacoes de paralelismo. Idealmente, para que as caracterısticas de tempo-real do
sistema nao sejam muito afectadas, pensamos que as accoes devem ser executadas com
o maior paralelismo possıvel. No entanto, se em termos de concretizacao tal nao for
possıvel, podera optar-se por uma solucao de encadeamento das accoes.
A reactivacao dos temporizadores devera ser feita de modo a que o intervalo de
tempo que decorre entre duas accoes de leitura consecutivas seja o mais proximo
possıvel do valor especificado. Assim, a solucao ideal consiste em relancar uma nova
temporizacao somente apos se ter concluıdo a accao de leitura, especificando um
valor temporal que tenha em conta o tempo ja decorrido desde o fim da temporiza-
cao anterior. Nesta aproximacao, se a periodicidade pretendida for inferior ao tempo
de duracao da accao (nao desprezavel), ela nao podera ser cumprida.
��Na arquitectura NavCim esta prevista a utilizacao de uma camada de interface ao sistema operativoque devera oferecer alguns servicos adicionais, entre os quais um servico de temporizadores que poderaser util neste caso.
CAPITULO 3. A ARQUITECTURA NAVCIM 97
Apos a recepcao da resposta ao pedido de leitura, os dados sao escritos num
ficheiro e sao tambem enviados para os modulos que deles necessitem. Em concreto,
podem ser enviados para os modulos de pre-processamento, de alarmes ou de arquivo.
Uma caracterıstica importante da funcionalidade de coleccao de dados e o facto de
cada accao de coleccao estar associada a um ficheiro diferente. De facto, esta aproxima-
cao simplifica extremamente nao so a execucao da plataforma como tambem a das
aplicacoes de supervisao. Comparativamente a utilizacao de um unico ficheiro para
armazenamento de todos os dados, esta solucao apresenta as seguintes vantagens:
� O acesso e mais rapido, dado que nao e necessaria a utilizacao de mecanismos de
indexacao para aceder aos dados pretendidos;
� Podem ser aproveitadas as facilidades do sistema de ficheiros, nomeadamente no
que diz respeito aos nomes utilizados para identificacao da informacao contida
nos ficheiros e em termos da organizacao tematica ou hierarquica da informacao,
utilizando directorios;
� A resolucao dos problemas de exclusao mutua no acesso aos dados e mais facil e
eficiente, pois esta podera ser feita apenas ao nıvel de segmentos da informacao.
As polıticas para definicao das accoes de leitura de variaveis estao assim relaciona-
das com a organizacao dos dados nos repositorios de tempo-real. Tal como esta repre-
sentado na figura 3.14, e possıvel definir accoes de coleccao de dados que permitam
caracterizar o estado da celula industrial de tres maneiras distintas:
� Com base em variaveis individuais, ou particulares;
� Com base em conjuntos de variaveis, reflectindo uma organizacao tematica da
informacao ou da estrutura da celula;
� Com base na totalidade da informacao, que reflecte o estado global da celula.
Convem salientar que os agrupamentos de variaveis apenas podem ser concretiza-
dos ao nıvel de cada VMD, nao sendo por isso possıvel definir accoes de coleccao de
dados referentes a varios VMDs em simultaneo. Tal facto nao tem, contudo, qualquer
CAPITULO 3. A ARQUITECTURA NAVCIM 98
reflexo ao nıvel do funcionamento interno da plataforma. Quanto as aplicacoes de su-
pervisao, estas nao estao impedidas de aceder em simultaneo a multiplos repositorios
de tempo-real, podendo dessa forma aceder a todas as variaveis pretendidas.
�� �����
����������������� ����������� !����!����!���
5)�
����������������� ����������� !����!����!���
!���
!����!����!���
����������!����
��������
��������
������
����������
�����������������
����� ������� ��
-
�
�
Figura 3.14: Polıticas de organizacao de dados na coleccao.
O formato com que os dados sao escritos nos repositorios e um aspecto relativo
da concretizacao. No entanto, parece-nos importante referir que esse formato nao tera
de obedecer a regras muito rıgidas, podendo mesmo ser estabelecido pelo utilizador,
por exemplo por meio de indicacoes adicionais na definicao das accoes de leitura.
E contudo fundamental que em todos os repositorios exista uma marca temporal
que identifique o instante da sua ultima actualizacao, sendo esta obtida atraves do
modulo de tempo da plataforma. A inclusao desta marca nao seria estritamente
necessaria, dado que aos ficheiros esta ja normalmente associado o instante da sua
ultima modificacao. No entanto, esse valor e de mais difıcil acesso as aplicacoes, e a
sua coerencia e apenas local.
Pode levantar-se o problema da coerencia dos dados contidos nos repositorios pelo
facto de o acesso aos mesmos ser efectuado simultaneamente por varias entidades. Na
verdade, o problema que aqui encontramos e semelhante ao dos leitores/escritores
[Lamport 86]. A diferenca e que neste caso nao e necessario garantir exclusividade
nos acessos para escrita, uma vez que existe apenas uma entidade encarregue de tal
CAPITULO 3. A ARQUITECTURA NAVCIM 99
operacao: o modulo colector de dados. A simultaneidade das operacoes de leitura
tambem nao constitui qualquer problema. A unica situacao merecedora de atencao, e
aquela que envolve operacoes de escrita e de leitura simultaneas. De facto, e necessario
garantir que estas operacoes sejam exclusivas, pois caso contrario o resultado das
operacoes de leitura torna-se imprevisıvel.
Como foi dito atras, e possıvel modificar dinamicamente a configuracao da pla-
taforma, nomeadamente das accoes de coleccao de dados. As primitivas disponibi-
lizadas para este efeito permitem modificar qualquer um dos parametros das accoes
(variaveis, repositorio ou perıodo) e permitem tambem criar novas accoes ou eliminar
as ja existentes.
3.5.5 Pre-processamento de Dados
A plataforma NavCim possui algumas capacidades de pre-processamento de
dados por dois motivos: para poder cumprir de forma mais completa o seu papel de
suporte as aplicacoes de supervisao e para permitir a execucao de accoes de controlo
estatıstico de processos.
Uma accao de pre-processamento consiste na aplicacao de uma funcao estatıstica
a um conjunto de valores de uma variavel. A definicao de uma destas accoes implica
a especificacao dos seguintes parametros:
� Variavel ou variaveis utilizadas na accao (podem ser eventos);
� Funcao de pre-processamento utilizada;
� Numero de amostras as quais e aplicada a funcao;
� Periodicidade com que e realizada a accao;
� Repositorio onde e armazenado o resultado da accao.
Tal como no caso das accoes de coleccao de dados, e tambem possıvel modificar
dinamicamente qualquer um destes parametros bem como definir ou remover accoes
de pre-processamento.
CAPITULO 3. A ARQUITECTURA NAVCIM 100
Em termos praticos, o nome das variaveis e necessario nao so para este modulo,
mas tambem para os modulos que geram os dados que serao processados. Sao estes
os responsaveis pelo envio dos novos dados e consequente activacao do modulo de
pre-processamento, tendo por isso de saber quais as variaveis que devem ser pre-
-processadas. As accoes de pre-processamento podem dizer respeito a dados em bruto
(provenientes do modulo de coleccao), pre-processados ou relativos a eventos.
As funcoes de pre-processamento concretizadas por este modulo deverao consistir,
obrigatoriamente, na media, no maximo e no mınimo. Na concretizacao da plataforma
poderao ser disponibilizadas outras funcoes, tais como o desvio padrao ou a mediana,
pois tal apenas contribuira para melhorar as suas caracterısticas.
A periodicidade de processamento dos dados pode ser definida em funcao do
tempo ou em funcao do numero de amostras recolhidas. De qualquer forma, e
sempre possıvel determinar o tempo que decorre entre duas accoes de processamento
consecutivas, bastando conhecer a periodicidade das accoes de coleccao de dados.
Se a periodicidade for especificada em funcao do numero de amostras, devera
ser utilizado um contador para determinacao da altura de processamento. Apos a
recepcao de novos dados o contador e incrementado e pode verificar-se uma de tres
situacoes: a) o numero de amostras recebido ate ao momento ainda nao e suficiente
para que se possa aplicar a funcao de pre-processamento, procedendo-se apenas
a memorizacao dos dados para posterior utilizacao; b) o numero de amostras e
suficiente, mas nao e ainda altura de efectuar o processamento dos dados memorizados
(neste caso, os novos dados sao memorizados e os dados mais antigos, se em excesso,
sao descartados); c) o numero de amostras e suficiente e o contador atingiu o valor
estabelecido para o perıodo. Pode entao efectuar-se o processamento dos dados e
reinicializar o contador da periodicidade. Apenas os dados mais antigos sao libertados.
Se a periodicidade for especificada em funcao do tempo, entao deverao ser
utilizados temporizadores e o funcionamento do modulo sera ligeiramente diferente.
A determinacao do instante de processamento passa a ser independente da recep-
cao de novas amostras e sempre que novos dados sao recebidos apenas se procede
a sua memorizacao. Quando a temporizacao expira, o modulo de pre-processamento
verifica se estao memorizadas amostras suficientes e, em caso afirmativo, procede ao
seu processamento. Caso contrario nao executa qualquer accao, reactivando apenas o
CAPITULO 3. A ARQUITECTURA NAVCIM 101
temporizador.
Relativamente ao armazenamento dos dados, o funcionamento deste modulo e
identico ao do modulo de coleccao. Por isso nao sera aqui novamente descrito.
O controlo estatıstico dos processos industriais e feito com base nos resultados pro-
duzidos por este modulo. Estes resultados sao enviados para o modulo de gestao de
alarmes que determina se os limiares pre-estabelecidos para esses valores foram ou
nao ultrapassados. Em caso afirmativo pode enviar mensagens de controlo para os
dispositivos, por exemplo, para interromper a sua actividade.
De acordo com a descricao feita, ter-se-a o leitor apercebido de que as funcionali-
dades oferecidas por este modulo nao permitem realizar o processamento de variaveis
distintas. Nao permitem, por exemplo, calcular o valor medio de um conjunto de
variaveis ou realizar a sua adicao. Esta incapacidade pode ser justificada pelo facto
de este nao ser um modulo de funcoes aritmeticas, mas sim um modulo cujo objectivo
e produzir resultados que possam ser utilizados para realizar o controlo estatıstico
dos processos. Neste contexto, pretende-se normalmente analisar as variaveis isola-
damente, aplicando funcoes estatısticas a um conjunto de valores de cada variavel,
tal como e feito por este modulo. Nao desprezamos, evidentemente, a utilidade de
um modulo de funcoes matematicas, que poderia consistir numa aplicacao comercial
(por exemplo o EXCEL) integrada na plataforma NavCim por intermedio de interfaces
adequadas (por exemplo, DDE).
3.5.6 Arquivo de Dados
A necessidade de depositar a informacao num repositorio estavel constitui a razao
da existencia do modulo de arquivo de dados. No entanto, tendo em conta que a
informacao estavel nao e necessaria do ponto de vista do controlo dos dispositivos,
seria admissıvel a concretizacao das funcionalidades de arquivo externamente a
plataforma. Estas sao, contudo, integradas na plataforma, uma vez que podem
ser directamente associadas a outras funcionalidades (pre-processamento e alarmes)
obtendo-se assim proveito da infraestrutura ja existente.
Este modulo e responsavel pela concretizacao das accoes de arquivo definidas na
configuracao da plataforma. Estas accoes sao desencadeadas a pedido dos modulos
CAPITULO 3. A ARQUITECTURA NAVCIM 102
que fornecem os dados a arquivar e sao definidas atraves dos seguintes elementos:
� Variavel ou variaveis utilizadas na accao (podem ser eventos);
� Base de dados a utilizar.
A execucao deste modulo e trivial. A unica accao efectivamente executada consiste
na escrita dos dados na base de dados indicada sempre que tal e requerido por algum
dos outros modulos. A escrita dos dados e realizada atraves da utilizacao de primitivas
SQL, sendo utilizado um formato para os dados pre-definido.
3.5.7 Gestao de Eventos
Este modulo recebe a indicacao de eventos provenientes dos dispositivos existentes
na celula que sao enviados como mensagens de informacao do MMS. Por uma
questao de generalidade, a plataforma assume que uma determinada variavel pode ser
referenciada por uma accao de coleccao de dados e simultaneamente assinalada num
evento. Assim, mesmo que os eventos enviados pelos VMDs nao fossem tratados, seria
sempre possıvel conhecer o valor de todas as variaveis neles existentes.
Se nao estiver definida nenhuma accao a tomar aquando da recepcao de um
evento, ele sera ignorado por este modulo, sendo apenas assinalado ao modulo VMD-
-Celula. Assim, se for pretendido o registo de um determinado evento (que se espera
eventualmente receber) devera ser configurada uma accao de tratamento de evento,
atraves da indicacao dos seguintes elementos:
� Variavel ou variaveis assinaladas;
� Repositorio para armazenamento do evento;
� Metodo de armazenamento.
Como ja afirmamos, os eventos sao armazenados em repositorios de tempo-real, tal
como os dados provenientes da coleccao ou do pre-processamento. Portanto, e atraves
do acesso aos repositorios que as aplicacoes se poderao aperceber da ocorrencia de
um evento. No proximo capıtulo, quando descrevermos as interfaces disponibilizadas
CAPITULO 3. A ARQUITECTURA NAVCIM 103
pela plataforma, serao abordados alguns aspectos tecnicos relativos a forma como
os ficheiros de eventos podem ser tratados pelas aplicacoes. Por agora apenas
descreveremos a forma como os dados devem ser armazenados para que nao se perca
nenhuma informacao relativa ao evento.
Existem dois metodos de armazenamento de eventos. Um deles coincide com
o metodo utilizado nas outras accoes, ou seja, consiste na substituicao dos valores
contidos no repositorio. O outro nao conduz a perda da informacao ja contida no
repositorio, pois consiste na adicao de um novo registo em vez da substituicao do que
la se encontrava. O problema do crescimento constante do tamanho do ficheiro nao nos
parece ser muito relevante, dado que, no caso dos eventos, a frequencia das escritas e,
em princıpio, muito reduzida. Em todo o caso, seria sempre possıvel a concretizacao
de mecanismos de garbage collection, associados aos ficheiros com tendencia a crescer.
Temos, contudo, de justificar a necessidade de tal metodo de armazenamento. Para
tal, observemos a figura 3.15 que representa os diferentes tipos de eventos que podem
ocorrer.
As tres situacoes representadas pretendem sintetizar os significados possıveis de
um evento no contexto da supervisao de processos industriais. A figura representa
tambem o resultado que se poderia obter se os eventos fossem arquivados utilizando
o segundo metodo descrito— de adicao de registos.
O caso A mostra um evento impulsivo, ou seja, um evento ao qual nao esta
subjacente nenhum valor, indicando apenas que algo aconteceu. Como exemplo de
um evento deste tipo, podemos referir o evento gerado por um sensor de passagem.
Na situacao representada, admite-se que a variavel associada ao evento tem um valor
sempre igual a 1. Assim, apos a segunda ocorrencia do evento o repositorio passa a
conter dois registos, que diferem apenas na marca temporal que indica o instante em
que cada um ocorreu��.
No caso B, o evento representado diz respeito a uma variavel binaria, tendo por
isso dois significados: no primeiro instante o evento indica a activacao da variavel e no
segundo indica a sua desactivacao. Em termos dos registos efectuados no repositorio,
verifica-se que atraves do valor registado e possıvel diferenciar o significado de cada
��Na realidade, a marca temporal indica o instante em que o evento foi recebido pela plataforma ouescrito no repositorio e nao o instante em que foi gerado.
CAPITULO 3. A ARQUITECTURA NAVCIM 104
uma das ocorrencias do evento.
����������� �����
��������&��/����
��������� 7,����
Tempo1 2
-
Tempo1 2
�
Tempo1 2
�
k
t=1, A=1 t=1, A=1t=2, A=1
t=1, B=1 t=1, B=1t=2, B=0
t=1, C>k t=1, C>kt=2, C<k
Figura 3.15: Tipos de eventos e sua representacao estatica.
Finalmente, no caso C o significado do evento representado esta relacionado com a
deteccao da passagem por um nıvel de uma determinada variavel. Neste caso, o valor
associado ao evento devera indicar o sentido em que se deu a passagem (podendo
arbitrar-se quaisquer valores, por exemplo, 1 e 0) e nao o nıvel de passagem. O
nıvel devera estar subjacente ao evento. Em termos dos dados armazenados, se o
valor do evento for 1 podera deduzir-se que a variavel passou para o nıvel superior
(representamos como c�k), caso seja 0 tera passado para o nıvel inferior.
Repare-se que nos dois ultimos casos se verifica sempre uma alternancia do
significado dos eventos, ou seja, duas ocorrencias consecutivas do evento tem sempre
significados diversos, podendo por isso ser diferenciadas atraves do valor registado
no repositorio. Assim, nestes dois casos seria possıvel utilizar o metodo normal de
armazenamento, sem perda de informacao para as aplicacoes. Em cada cada momento,
CAPITULO 3. A ARQUITECTURA NAVCIM 105
o repositorio forneceria uma imagem fiel do estado do evento.
A necessidade do metodo de armazenamento por adicao e, assim, justificada
pelos eventos impulsivos. Na pratica, se apenas estivesse disponıvel o metodo de
armazenamento normal, poderia detectar-se um novo evento impulsivo atraves da
marca temporal contida no repositorio. No entanto passaria a ser necessario manter
um contexto ao nıvel das aplicacoes relativo ao estado anterior do repositorio. Convem
apenas assinalar que se for utilizado o metodo de armazenamento por adicao, o acesso
aos repositorios devera ser feito de uma forma diferente da habitual.
Apos a recepcao de um evento, o modulo de gestao de eventos devera verificar
se existe alguma accao de tratamento definida para esse evento. Se existir, o evento
e armazenado de acordo com a configuracao, sendo posteriormente enviado para
todos os modulos que dele estejam a espera para executar outro tipo de accoes. De
qualquer maneira, sera sempre enviado para o modulo VMD-Celula, o qual fara o
envio de novas informacoes MMS relativas ao evento para todas as aplicacoes ligadas
a plataforma.
3.5.8 Gestao de Alarmes
A possibilidade de definir situacoes de alarme e extremamente importante no
contexto da supervisao. Por isso, e tambem porque nessas situacoes e muitas vezes
necessario executar accoes de controlo dos dispositivos, se justifica a existencia deste
modulo.
O funcionamento basico deste modulo e semelhante ao dos outros modulos ja
descritos. Durante a execucao da plataforma, a activacao deste modulo verifica-se
sempre que os modulos de coleccao, de pre-processamento ou de gestao de eventos
produzem novos dados que sao referenciados em accoes de alarme. Estas accoes
definem os parametros que permitem ao modulo de gestao de alarmes desempenhar
o seu papel e consistem no seguinte:
� Variavel ou variaveis utilizadas;
� Expressao condicional relativa as variaveis utilizadas;
CAPITULO 3. A ARQUITECTURA NAVCIM 106
� Repositorio para armazenamento dos dados que conduziram a situacao de
alarme;
� Evento gerado pelo VMD-Celula, na situacao de alarme;
� Accao de escrita executada na situacao de alarme.
E atraves da avaliacao da expressao condicional definida que o modulo de
gestao de alarmes baseia a sua accao. Se a expressao avaliada for verdadeira
poderao ser executadas ate tres accoes, tambem definidas na accao de alarme. O
armazenamento dos dados no repositorio e feito da mesma forma que nos casos ja
descritos. Relativamente ao evento gerado nas situacoes de alarme, ha que dizer
que este implica a definicao de uma nova variavel (a que sera assinalada as aplica-
coes), exclusiva do VMD representado pela plataforma. E o modulo VMD-Celula
quem constroi a mensagem de informacao, utilizando o evento e o valor desse evento
indicados pelo modulo de gestao de alarmes.
As accoes de escrita nao foram ainda definidas, pois e apenas este modulo
que desencadeia a sua utilizacao. Como ja foi dito, em caso de alarme pode ser
necessario enviar mensagens de controlo para os dispositivos. Uma accao de escrita
permite definir o conteudo de uma destas mensagens, sendo por isso constituıda pelos
seguintes elementos:
� Variaveis escritas;
� Valor escrito em cada variavel.
Note-se que a indicacao do VMD para onde sera enviada a mensagem de escrita
nao constitui um dos elementos da accao, pois presume-se que na definicao das
diversas accoes esta sempre subjacente o VMD a que dizem respeito.
Refira-se que em termos da modificacao dinamica da configuracao, as accoes de
alarme e as accoes de escrita sao modificadas separadamente.
3.5.9 Servico de Tempo Global
A disponibilidade de um servico de tempo e fundamental num sistema de
supervisao e controlo. O caracter global deste servico justifica-se numa arquitectura
CAPITULO 3. A ARQUITECTURA NAVCIM 107
distribuıda, pois permite um ordenamento total de actividades paralelas. A utilizacao
de um servico de tempo global e imprescindıvel para a concretizacao dos seguintes
aspectos funcionais do sistema:
� ordenacao de eventos gerados pelos dispositivos industriais— se estes eventos
forem gerados em celulas distintas, e apenas possıvel ordena-los�� atraves da uti-
lizacao de marcas temporais geradas por relogios sincronizados [Verıssimo 95a];
� leitura coordenada de variaveis dos dispositivos— a garantia de coordenacao
de actividades distribuıdas, nao sendo estas desencadeadas por um sistema
central, tera necessariamente de ser obtida com recurso a mecanismos baseados
em relogios sıncronos [Kopetz 93];
� reproducao posterior da evolucao do estado do sistema— esta reproducao so sera
congruente e fiavel se os dados utilizados possuırem marcas temporais que os
permitam ordenar e intervalar com precisao.
Convem desde ja assinalar o facto de as marcas temporais serem sempre realizadas
ao nıvel da plataforma NavCim e nao ao nıvel dos dispositivos, o que pode introduzir
erros de ordenacao relativamente aos instantes absolutos de ocorrencia dos eventos.
Para reduzir o erro, o controlador do dispositivo teria que ter mecanismos de
estampilhagem.
A concretizacao de um servico de tempo global pode ser levada a cabo de multiplas
maneiras, utilizando diferentes algoritmos e fornecendo diversos valores no que
respeita a precisao e exactidao dos relogios sincronizados. No caso da arquitectura
NavCim a solucao proposta baseia-se na utilizacao de um algoritmo de sincronizacao
interna, sendo realizado um reforco de exactidao baseado na utilizacao de uma fonte
externa de tempo (figura 3.16) [Srikanth 87].
Garante-se assim o sincronismo de todos os relogios do sistema, dentro de um
determinado limite de precisao (ou seja, diferenca relativa entre quaisquer dois
relogios) e de exactidao (diferenca relativamente a fonte externa de tempo).
��Note-se que a ordenacao “absoluta” de eventos e apenas uma abstraccao. Na realidade podemsempre ser cometidos erros devido a granularidade e a precisao dos relogios utilizados.
CAPITULO 3. A ARQUITECTURA NAVCIM 108
123
69
(�����: �;
(�����: �9
123
6
9
(�����: �8
123
69
123
69
(�����: �A
(�����: �B
123
6
9
123
69
��������6����������
��������6����������
��������6���������
$���� $���� $����
$���� $����#�������
.��
#�������.��
#���� ��
#���� ��
Figura 3.16: Sincronizacao de relogios.
Na figura apresentada pode observar-se a solucao proposta. Ao nıvel de cada
rede local e utilizada a sincronizacao interna, que garante a precisao dos relogios
intervenientes, sendo a precisao global garantida pela utilizacao de uma referencia
externa de tempo, comum a todo o sistema. Refira-se que actualmente o custo das
solucoes baseadas na utilizacao de referencias externas de tempo comeca a ser muito
reduzido, nomeadamente atraves da utilizacao de equipamentos GPS��, tendo ja sido
desenvolvidos algoritmos vocacionados explicitamente para o aproveitamento deste
tipo de solucoes [Verıssimo 95b].
O modulo de tempo da plataforma e responsavel pela execucao destes algoritmos
de sin-
cronizacao e pelo fornecimento do servico de tempo. Este modulo pode considerar-
-se um modulo isolado do resto da plataforma, pois nao tem qualquer intervencao em
termos do fluxo de dados. Em termos de configuracao e apenas necessario especificar
os parametros requeridos para a execucao dos algoritmos utilizados. Normalmente
estes parametros consistem na indicacao da precisao e da exactidao desejadas.
��Global Positioning System.
CAPITULO 3. A ARQUITECTURA NAVCIM 109
3.6 Resumo
Neste capıtulo apresentamos a arquitectura NavCim, tendo comecado por descre-
ver os requisitos que motivaram a sua concepcao. Assim, foi apontado como requisito
essencial a capacidade de resolucao dos problemas da heterogeneidade de sistemas e
aplicacoes, da escalabilidade, da expansibilidade e da distribuicao.
Descreveu-se de uma forma generica a arquitectura, salientando o seu caracter
hierarquico e analisando cada um dos nıveis dessa hierarquia. Apresentaram-se em se-
guida os diversos modulos componentes da arquitectura, explicando resumidamente
o papel desempenhado por cada um deles.
Finalmente foram descritos os pormenores da arquitectura, quer do ponto de vista
do fluxo de dados, quer do ponto de vista computacional.
Capıtulo 4
Concretizacao
A descricao da arquitectura NavCim que fizemos no capıtulo anterior, permitiu
compreender a forma como se articulam os seus componentes e os pormenores do seu
funcionamento. Daremos agora conta dos aspectos praticos de concretizacao e aplica-
cao desta arquitectura, com base na experiencia que adquirimos no desenvolvimento
de uma plataforma de software nela baseada— a plataforma NavCim.
Comecaremos por abordar os ambientes e sistemas de suporte, descrevendo
de seguida as interfaces de interaccao com a plataforma. Falaremos ainda dos
seus componentes mais relevantes e de alguns aspectos tecnicos de concretizacao,
para terminar com a descricao do demonstrador e a referencia aos resultados que
recolhemos da sua utilizacao.
4.1 Ambientes e Sistemas de Suporte
A arquitectura NavCim define a necessidade de utilizacao de alguns modulos
de software, classificados como modulos de suporte, que, tendo sido sumariamente
apresentados no capıtulo anterior, serao agora analisados com maior profundidade.
Sera dada uma maior atencao aos aspectos com relevancia na optica do utilizador, ou
seja, as interfaces de programacao e utilizacao disponibilizadas.
110
CAPITULO 4. CONCRETIZACAO 111
4.1.1 Sistema de Ficheiros Distribuıdo (NFS)
O sistema de ficheiros distribuıdo NFS e actualmente um dos mais divulgados a
nıvel mundial. Para tal contribuem diversos factores, tais como a sua inclusao ou
disponibilizacao nos sistemas operativos mais utilizados, a sua facilidade de utiliza-
cao e as provas de fiabilidade e eficiencia que tem dado [Sandberg 85, Kleiman 86,
Rosen 86]. Estes factores foram tambem determinantes na escolha deste sistema como
plataforma de distribuicao de ficheiros da aquitectura NavCim.
Sintetizamos de seguida algumas das caracterısticas gerais do NFS, no sentido
positivo, aquelas cuja importancia no ambito da arquitectura NavCim nos parece
relevante.
� Independencia em relacao a sistemas, maquinas e redes, permitindo a operacao
em ambientes heterogeneos;
� Transparencia no acesso a ficheiros remotos, facilitando o desenvolvimento das
aplicacoes;
� Indices razoaveis de desempenho, que nao comprometem a rapidez no acesso
remoto aos ficheiros.
Negativamente, salientamos apenas as deficiencias do NFS no que toca aos aspec-
tos de seguranca, que felizmente nao vem comprometer os objectivos da arquitectura
NavCim.
A estrutura do NFS e composta por um cliente, um servidor e pelo protocolo [SM89].
A concretizacao do cliente e do servidor e totalmente independente, garantindo-se a
sua interoperabilidade atraves do protocolo. Nos ambientes alvo de aplicacao da nossa
arquitectura, os servidores NFS situar-se-ao nas celulas industriais, disponibilizando
os repositorios de tempo-real, e os clientes estarao situados nos nıveis superiores,
de gestao, onde permitem o acesso remoto aos repositorios. A comunicacao entre
clientes e servidores e feita atraves do mecanismo de RPC�, utilizado na concretiza-
cao do protocolo, cujo caracter bloqueante torna mais simples a gestao das mensagens
trocadas. Por outro lado e utilizada a especificacao XDR� [SM87] na definicao das�Remote Procedure Call.�eXternal Data Representation.
CAPITULO 4. CONCRETIZACAO 112
estruturas e tipos de dados utilizados, a qual confere a independencia do protocolo
relativamente as maquinas e redes utilizadas.
No NFS nao e mantida qualquer informacao sobre o estado das ligacoes, pois
todas as chamadas definidas no protocolo sao idempotentes, contendo a informa-
cao necessaria para a execucao do procedimento remoto. Por este facto, as accoes a
tomar em caso de falha do servidor ou do cliente sao extremamente simples: se o
servidor falhar o cliente fica a espera ate que a chamada se conclua (tal como acontece
se a comunicacao estiver lenta); se o cliente falhar o servidor nao e afectado, pois
nao tem qualquer registo do estado. Em termos do funcionamento do NFS refira-
se ainda a existencia de uma cache de ficheiros e seus atributos mantidas no cliente,
que torna mais eficiente o tratamento de acessos consecutivos (para leitura) a um
mesmo ficheiro. Como o ficheiro pode ser modificado, o NFS compara periodicamente
os atributos locais (mantidos na cache) com os remotos, e se estes forem diferentes
actualiza a copia local do ficheiro. Este procedimento nao evita, no entanto, que sejam
lidos dados obsoletos entre duas comparacoes sucessivas de atributos, o que pode
ter efeitos indesejados no caso da plataforma NavCim. E contudo possıvel alterar o
funcionamento do NFS por forma a evitar estas situacoes, tal como veremos mais a
frente.
A configuracao do NFS consiste essencialmente na definicao das ligacoes entre
o sistema de ficheiros local e os remotos. O estabelecimento dessas ligacoes e feito
atraves de um protocolo distinto do NFS, o protocolo de mount, que permite “montar”
no sistema de ficheiros do cliente NFS um directorio do sistema de ficheiros remoto.
No contexto da plataforma NavCim, os pontos de acesso deverao reflectir de alguma
forma a organizacao das celulas de supervisao, automaticamente garantida no caso dos
sistemas MS-DOS ou OS/2 e conseguida com uma adequada estrutura de directorios
no caso dos sistemas UNIX�.
Na definicao de cada ponto de acesso podem configurar-se alguns parametros,
utilizados pelo cliente NFS, relativos a forma como se processam as chamadas ao
servidor. Em particular, pode alterar-se o mecanismo de funcionamento da cache de
�Os mecanismos de mount diferem consoante os sistemas operativos. No caso do MS-DOS ou doOS/2, as directorias remotas apenas podem ser “montadas” nas drives livres do sistema, ao passo quenos sistemas UNIX qualquer directorio pode constituir um ponto de acesso (um mount point) para osistema de ficheiros remoto.
CAPITULO 4. CONCRETIZACAO 113
ficheiros e atributos, de maneira a que todas as chamadas de leitura impliquem a
verificacao dos atributos do ficheiro, garantindo que este seja localmente actualizado
se tiver sido modificado remotamente. Assim, na plataforma NavCim deve sempre
activar-se o parametro que impede a utilizacao da cache de atributos.
No que respeita as interfaces, a utilizacao do NFS e totalmente transparente, uma
vez que as chamadas do sistema operativo relativas a manipulacao dos ficheiros
podem ser indistintamente usadas para acesso a ficheiros locais e remotos.
4.1.2 Plataforma MMS (SWCP)
A plataforma SWCP permite a comunicacao ao nıvel local e entre nos distintos da
rede, utilizando o protocolo MMS. A sua concepcao baseia-se no modelo de referencia
OSI, em particular nos perfis e nos protocolos CNMA (MAP/MMS) [MAP85, ISO90a,
ISO90b], permitindo por isso a comunicacao ISO/OSI com quaisquer outros produtos
de software.
O modelo OSI consiste basicamente na organizacao do sistema de comunicacoes
segundo nıveis de funcionalidade, onde cada nıvel acede aos servicos do nıvel inferior
atraves de uma interface bem definida e onde a comunicacao entre instancias de um
mesmo nıvel utiliza o protocolo definido para esse nıvel. As aplicacoes utilizam
as interfaces disponibilizadas pelo setimo nıvel, o nıvel de aplicacao, quando querem
utilizar um dos servicos existentes.
A concretizacao deste modelo e realizada na SWCP por dois agentes, o agente SE
(System-wide Exchange) e o agente CM (Communication Management) [Rang 92], sendo
o primeiro responsavel pela realizacao das funcionalidades do nıvel de aplicacao e o
segundo pela realizacao das restantes, tal como representado na figura 4.1.
Do ponto de vista computacional estes agentes sao concretizados por processos
distintos, sendo as interaccoes entre eles e com as aplicacoes levada a cabo atraves dos
mecanismos de comunicacoes entre processos (IPC�) disponıveis no sistema operativo
utilizado (por exemplo, OS/2 queues ou UNIX message queues).
O SE garante as aplicacoes a transparencia no acesso, ou seja, esconde a localizacao
�Inter-Process Communication.
CAPITULO 4. CONCRETIZACAO 114
real (local ou remota) das aplicacoes. No caso da comunicacao ser entre aplicacoes
locais, apenas os servicos do SE sao necessarios, sendo o CM utilizado so quando
a comunicacao tem de ser efectuada atraves da rede. Assim, e possıvel construir
diversos agentes CM, cada qual concretizando um perfil de comunicacao distinto�, que
podem ser simultaneamente utilizados pelo agente SE de um determinado no. Para a
comunicacao atraves da rede, a escolha do agente CM a utilizar— e, portanto, do perfil
de protocolos— e um ponto fulcral da construcao do sistema.
��
�)('�� �8('�� �9('�� �;('�� �B('�� �A
�� ��������� ����!"��#��
-� ������C-C-� ������C�C(����
��������
('�� ����-� �����
���
����� ��������� ����!$�%��
('�� ����-����������
Figura 4.1: Agentes SE e CM no modelo de referencia OSI.
Nos casos em que os dispositivos industriais (por exemplo, PLCs) nao dispoem
de interfaces MMS, sendo essa interface concretizada externamente (no nosso caso
usando tambem a SWCP), torna-se possıvel escolher o perfil de protocolos utilizado.
No ambito da arquitectura NavCim, a solucao encontrada baseia-se na utilizacao, na
medida do possıvel, dos protocolos normalizados do mundo UNIX, ou seja, na utiliza-
cao de um perfil compatıvel com redes TCP/IP. Assim, foi utilizado um agente CM
�O facto de ser utilizado o protocolo MMS no nıvel de aplicacao nao impede que cada fabricantecomponha o seu proprio perfil (OSI) no que respeita aos outros nıveis. Assim, e possıvel que para cadafabricante tenha de ser utilizado um agente CM diferente.
CAPITULO 4. CONCRETIZACAO 115
com as caracterısticas desejadas, ou seja, capaz de comunicar atraves de redes IP.
A utilizacao de um dos agentes CM existentes na SWCP que integram produtos
existentes no mercado baseados no perfil MAP/MMS, tais como o DEComni da DIGI-
TAL, o SISCO MMS-EASE e o PROCOS EasyMAP, representa um investimento con-
sideravelmente superior quando comparado com uma solucao baseada no TCP/IP. O
agente utilizado, o CM-ISODE, integra apenas o ambiente de desenvolvimento ISODE
que, sendo um produto freeware, nao encarece a solucao. O papel desempenhado pelo
ISODE sera descrito na seccao seguinte.
Para as aplicacoes (em particular para a plataforma NavCim) a utilizacao da SWCP
e feita atraves de um conjunto de primitivas que permitem utilizar os protocolos
disponıveis no nıvel de aplicacao (no nosso caso apenas nos interessa o protocolo
MMS). A cada servico definido no protocolo estao associadas quatro funcoes, para o
envio de pedidos e respostas e para a recepcao de indicacoes e confirmacoes. Estas
funcoes sao unicas, utilizadas para todos os servicos, havendo apenas diferencas
nas estruturas passadas como argumentos. Cada aplicacao deve registar-se junto do
agente SE local antes de poder estabelecer associacoes com as aplicacoes com as quais
pretende comunicar. As primitivas essenciais disponibilizadas pela interface sao as
seguintes:
� Registo no SE: se activate e se deactivate
� Associacoes: se associate req, se conclude req e se abort
� Pedidos: se request
� Respostas: se response
� Indicacoes: se process events e se pending events
Refira-se que o envio de pedidos pode ser realizado com ambas as semanticas
bloqueante e nao bloqueante, sendo que no ultimo caso as confirmacoes serao
recebidas apenas apos invocacao da primitiva de processamento de indicacoes. Esta
ultima tem um caracter bloqueante, ou seja, bloqueara a aplicacao que a invocou ate
que seja recebida uma indicacao ou uma confirmacao, sendo nesse momento chamada
uma funcao definida na aplicacao para tratamento da mensagem recebida.
CAPITULO 4. CONCRETIZACAO 116
4.1.3 Emulador de pilhs OSI (ISODE)
O ambiente de desenvolvimento ISODE� [Rose 91, ISO93] foi utilizado na concre-
tizacao dos nıveis de sessao, de apresentacao e do ACSE� do agente CM-ISODE men-
cionado na seccao anterior. Este pacote de software pressupoe a existencia dos nıveis
de transporte e de rede, mas nao especifica os protocolos particulares a utilizar. Assim,
admitem-se duas configuracoes para o agente CM-ISODE que permitem a comunica-
cao sobre o protocolo ISO TP4 (Transport Class 4, tal como especificado no perfil CNMA)
ou sobre TCP/IP.
Na plataforma NavCim e possıvel utilizar qualquer um dos agentes CM ou, tal
como ja explicado, varios simultaneamente. No caso particular da plataforma de teste
desenvolvida, recorremos ao agente CM-ISODE configurado para TCP/IP, tal como
representado na figura 4.2. A utilizacao do TCP/IP e feita atraves da interface de sockets
do sistema, tal como no caso de qualquer aplicacao, sendo usado um unico porto TCP
para recepcao das mensagens.
O recurso ao ISODE para concretizacao das funcionalidades dos nıveis 5 e 6 OSI
garante que sao utilizadas normas ISO nesses nıveis. No entanto, nao e possıvel tirar
nenhum partido deste facto a partir do momento em que sao utilizados protocolos
do mundo UNIX nos nıveis inferiores, pois nao e provavel que algum dispositivo
concretize um perfil de protocolos semelhante. O unico cenario previsıvel corresponde
a comunicacao entre dois agentes CM identicos. Assim, pode dizer-se que os
protocolos escolhidos para os nıveis 5 e 6 sao irrelevantes, podendo inclusivamente
utilizar-se protocolos normalizados do mundo UNIX, a semelhanca do que e feito nos
nıveis inferiores.
Pelas razoes expostas, foi desenvolvido no INESC (pelo grupo de Sistemas Dis-
tribuıdos e Automatizacao Industrial) um agente CM exclusivamente composto por
protocolos normalizados do mundo UNIX, o CM-TCP/IP, que utiliza a norma XDR
para representacao dos dados� (tal como o NFS, descrito na seccao 4.1.1). Este agente
foi tambem testado na plataforma desenvolvida, nao se tendo registado, no entanto, di-
�A versao utilizada e a versao 8.0 . Saliente-se que as versoes mais recentes do ISODE deixaram deser freeware, passando a ser necessario a aquisicao de licencas de utilizacao para se ter acesso ao software.
�Association Control Service Element.�O encapsulamento dos dados e imprescindıvel para garantir a independencia dos servicos face ao
tipo ou arquitectura das maquinas utilizadas.
CAPITULO 4. CONCRETIZACAO 117
��&��%�'
('�� �;
('�� �B
('�� �A
('�� �D
('�� �8
('�� �9
�����
$����
������������+���
����������'�� �ED����
Figura 4.2: Utilizacao do TCP/IP no agente CM-ISODE.
ferencas significativas de desempenho relativamente ao CM-ISODE, tal como se vera
na seccao 4.5.
4.1.4 Ambiente de Suporte Local (LSE)
A heterogeneidade dos sistemas operativos e resolvida na arquitectura NavCim
com a utilizacao do LSE, um ambiente que esconde as particularidades de cada sistema
operativo, oferecendo as aplicacoes sobre ele construıdas uma interface uniforme,
identica em todas as plataformas [Fonseca 90]. Alem disso, o LSE disponibiliza ainda
alguns servicos que facilitam a construcao das aplicacoes, em particular no que respeita
aos aspectos da comunicacao.
Em cada sistema operativo existe uma versao especıfica do LSE, estando neste
momento disponıveis versoes para os sistemas SunOS 4.1.3, SunOS 5 (Solaris) e OS/2
2.1 (a qual foi desenvolvida no ambito deste trabalho). Note-se que a programacao do
LSE e realizada na linguagem C [Kernighan 88], de resto tal como todo o software de
que temos vindo a falar e de que falaremos futuramente.
Dos servicos disponibilizados pelo LSE destacam-se como mais importantes o
No ambito do projecto ESPRIT Delta-4 foi desenvolvida uma outra versao do LSE, para o executivode tempo-real SPART, que dispoe contudo de funcionalidades mais reduzidas.
CAPITULO 4. CONCRETIZACAO 118
servico de temporizadores (timers), o servico de caixa de correio (mailboxes) e o de es-
calonador (scheduler) de modulos. Os temporizadores, utilizados pelo modulo de co-
leccao de dados, podem ser sıncronos ou assıncronos, sendo respectivamente enviada
uma mensagem para uma caixa de correio ou invocada uma funcao de tratamento,
quando expira a temporizacao. O servico de caixas de correio, apesar de especialmente
vocacionado para a comunicacao inter-processos, admite a possibilidade de criar uma
caixa de correio especial, unica em cada maquina, para comunicacao em redes locais.
Neste ultimo caso, a comunicacao nao e orientada a ligacao, sendo apenas possıvel en-
viar mensagens em difusao e tendo a fiabilidade das transmissoes de ser garantida ao
nıvel aplicacional�. Em contrapartida, este servico garante um optimo desempenho
dos protocolos sobre ele construıdos. Refira-se que na plataforma NavCim, a caixa de
correio de rede e apenas utilizada pelo modulo de tempo, na execucao do protocolo
de sincronizacao de relogios. Finalmente, o servico de escalonador permite a gestao
centralizada da execucao do sistema, sendo especialmente apropriado para a concre-
tizacao de maquinas de estados [Schneider 93].
4.2 Interfaces
A interaccao entre as aplicacoes de supervisao e a plataforma NavCim pode ser
efectuada atraves das chamadas do sistema operativo, que permitem o acesso directo
aos repositorios de informacao, ou atraves das bibliotecas de interface disponibilizadas
pela plataforma, que fornecem nao so um metodo alternativo de acesso a informacao,
como tambem possibilidades de reconfiguracao dinamica do funcionamento da celula
e de acesso directo a variaveis para leitura, escrita ou deteccao de eventos.
As referidas bibliotecas, desenvolvidas como parte integrante da plataforma,
contem primitivas que passamos a descrever genericamente, para que se fique com
uma ideia geral das possibilidades de programacao por elas oferecidas.
�Na versao actual do LSE para OS/2 a caixa de correio associada a rede esta excepcionalmenteconstruıda sobre o TCP/IP, sendo por isso fiavel, mas menos eficiente.
CAPITULO 4. CONCRETIZACAO 119
4.2.1 Interface de Celula
A biblioteca que constitui a interface de celula contem todas as primitivas que
envolvem interaccoes com a celula NavCim, as quais se dividem em dois grupos
caracterizados pelo metodo de comunicacao utilizado:
Primitivas de eventos e controlo: Sao concretizadas sobre o protocolo MMS, recor-
rendo aos servicos da SWCP.
Primitivas de configuracao e monitorizacao: Utilizam um protocolo proprietario,
executado sobre o servico de caixas de correio do LSE.
As primitivas de eventos e controlo sao as seguintes:
� IniciaAssociacao ��
A comunicacao entre dois VMDs so pode ser efectuada apos ter sido estabelecida
uma associacao MMS entre eles. Assim, antes de serem utilizadas as funcoes
da biblioteca que implicam a comunicacao com o VMD da celula NavCim, deve
ser invocada esta primitiva para criar a associacao necessaria. A sua existencia
justifica-se fundamentalmente por uma questao de estruturacao do codigo, uma
vez que o estabelecimento da associacao podia ser efectuado por omissao da
primeira vez que fosse necessario comunicar com o VMD da celula.
� AssociaEvento ��in� NomeDoVMD� NomeDoEvento� funcao�
A semantica desta funcao e semelhante a da chamada signal do sistema UNIX,
dado que permite a especificacao de uma funcao que sera assincronamente
invocada quando ocorrer um determinado evento, identificado pelo nome do
VMD que o gera e pelo seu proprio nome. Convem assinalar que o nome
do evento corresponde ao nome atribuıdo na configuracao da celula, e nao
ao nome da variavel (ou das variaveis) efectivamente assinalada(s) pelo VMD.
Assim, para que posteriormente se saiba a que evento corresponde a variavel
recebida por MMS, e recolhida a informacao de configuracao necessaria (atraves
do protocolo proprietario de comunicacao com a celula) quando esta primitiva e
invocada. As variaveis que constituem o evento sao passadas como argumentos
da funcao especificada.
CAPITULO 4. CONCRETIZACAO 120
� CancelaEvento ��in� NomeDoVMD� NomeDoEvento�
Permite desactivar a recepcao de um evento, bastando para tal indicar os
parametros que o identificam.
� LeVariavel ��in� NomeDoVMD� NomeDaVariavel� �out� Variavel�
Esta primitiva permite ler uma variavel disponıvel num dos VMDs acedidos
pela celula NavCim. O pedido de leitura MMS e enviado para o VMD da
celula e nao directamente para o VMD especificado. A execucao da funcao
e bloqueante, obtendo-se como resposta uma estrutura contendo os elementos
relativos a variavel (nome, tipo e valor).
� EscreveVariavel ��in� NomeDoVMD� Variavel�
Permite alterar o valor de uma variavel, utilizando a funcionalidade de escrita do
MMS. E necessario indicar, atraves da estrutura passada como parametro para a
funcao, a variavel que se pretende alterar bem como o seu novo valor. Tal como
sucede com a primitiva anterior, a chamada MMS e bloqueante..
Todas as primitivas descritas retornam um codigo de erro que permite aferir do
sucesso da invocacao, codigo esse que podera, em caso de erro, discriminar a origem
do mesmo.
Antes de procedermos a descricao das principais primitivas que constituem a
interface de configuracao e monitorizacao da celula, parece-nos importante relembrar
as orientacoes propostas na arquitectura NavCim relativas a informacao de configura-
cao e a sua relacao com os modulos existentes na plataforma. Ao longo da seccao 3.5
referimos que a execucao de alguns dos modulos se processa de acordo com as accoes
definidas para esses modulos e especificadas no ficheiro de configuracao. Vimos assim
como sao definidas as accoes de coleccao de dados, de pre-processamento, de gestao
de eventos, de tratamento de alarmes, de escrita e de arquivo. A concretizacao destas
ultimas nao fez parte do presente trabalho, de modo que nao serao referidas como
parte integrante da plataforma concretizada.
Em termos de concretizacao, cada uma destas accoes pode ser vista como um
objecto que e caracterizado por um nome (unico no contexto de cada VMD) e por
um tipo (o tipo da accao). Para alem dos objectos correspondentes as accoes, podem
CAPITULO 4. CONCRETIZACAO 121
ainda definir-se mais dois tipos de objectos, que representam as variaveis definidas nos
VMDs�� e os grupos de variaveis, com base nelas formados. Assim, como veremos de
seguida, a reconfiguracao da celula podera ser efectuada atraves da criacao, remocao
ou modificacao de objectos. As primitivas disponibilizadas sao as seguintes:
� ObtemNomes ��in� NomeVMD� TipoObj� �out� Nomes�
Permite obter os nomes dos objectos de um determinado tipo, relativos ao VMD
especificado. Pode ser utilizado qualquer um dos tipos de objecto definidos (ao
todo 8), uma vez que a primitiva apenas recolhe informacao, nao executando
qualquer alteracao da configuracao estabelecida.
� ObtemObjecto ��in� NomeVMD� TipoObj� NomeObj� �out� Objecto�
Tal como a primitiva anterior, tambem esta tem como objectivo apenas a recolha
de informacao, permitindo por isso a especificacao de qualquer um dos tipos
de objecto definidos. A invocacao desta primitiva permite obter a informacao
relativa ao objecto indicado, a qual e retornada na forma de uma estrutura de
dados especıfica de cada tipo de objecto.
� CriaObjecto ��in� NomeVMD� TipoObj� NomeObj� Objecto�
Esta e uma das tres primitivas que permitem modificar a configuracao da
celula, neste caso atraves da criacao de um novo objecto. Contudo, e apenas
permitido criar os seguintes tipos de objectos: grupos (de variaveis) e accoes de
leitura, escrita, pre-processamento, alarme e arquivo. A estrutura passada como
argumento deve corresponder ao tipo do objecto a criar e conter os elementos
necessarios para a definicao do objecto.
� RemoveObjecto ��in� NomeVMD� TipoObj� NomeObj�
Permite remover o objecto identificado pelo nome e tipo indicados. Os tipos
admitidos sao os mesmos que na primitiva anterior. A impossibilidade de criar
ou remover accoes de gestao de eventos e motivada pela nossa conviccao de
que, numa aplicacao industrial de supervisao e controlo, dado um determinado
VMD de um dispositivo, sao conhecidos a partida todos os eventos que podem
eventualmente ser recebidos desse VMD, devendo por isso ser estabelecidas logo
��Neste caso o nome do objecto coincide com o nome da variavel representada.
CAPITULO 4. CONCRETIZACAO 122
de inıcio todas as accoes de gestao de eventos necessarias, as quais nao serao
nunca removidas.
� ModificaObjecto ��in� NomeVMD� TipoObj� NomeObj� Objecto�
E possıvel modificar apenas alguns dos elementos de definicao dos objectos
utilizando esta primitiva. Para tal, devem apenas ser preenchidos os registos
que se pretende modificar, na estrutura que define o objecto. Obviamente, deve
existir uma definicao previa do objecto indicado.
� GuardaConfiguracao ��in� NomeDoFicheiro�
A invocacao desta primitiva permite gerar um ficheiro de configuracao contendo
as definicoes actualmente activas. Esse ficheiro podera ser utilizado em inicializa-
coes futuras da celula NavCim.
A comunicacao entre as aplicacoes e a celula NavCim, necessaria sempre que
uma destas primitivas e invocada, e realizada atraves do servico de caixas de correio
existente no LSE. O envio de mensagens e feito para uma caixa de correio da celula
cuja identificacao e globalmente conhecida, sendo utilizada uma primitiva de envio
com uma semantica semelhante a de uma chamada RPC. No retorno, a primitiva de
envio devolve um codigo de erro (que sera eventualmente remetido para o utilizador
na conclusao das primitivas da interface) que pode revelar erros quer de comunicacao,
quer de execucao do pedido ao nıvel da celula (por exemplo, causados por argumentos
invalidos).
4.2.2 Interface de Dados
Como ja foi afirmado, a interface de dados constitui apenas um meio alternativo
para acesso a informacao contida nos repositorios de tempo-real. A funcao essencial
desta biblioteca consiste em oferecer um filtro de leitura que evite a necessidade de
conhecer o formato com que os dados estao guardados nos ficheiros. Tal pode ser feito
com uma unica primitiva, com as seguintes caracterısticas:
� leRegisto ��in� NomeDoFicheiro� �out� Tempo� Dados�
CAPITULO 4. CONCRETIZACAO 123
Permite a leitura dos dados contidos num dos repositorios de informacao (dados
em bruto, pre-processados, de eventos ou de alarmes). E necessario indicar o
ficheiro que contem esses dados, sendo obtida a marca temporal associada a
informacao lida e uma estrutura contendo essa informacao. Note-se que esta
estrutura pode conter o valor de diversas variaveis, sendo da responsabilidade
do utilizador o conhecimento das variaveis a que esses valores dizem respeito.
Refira-se ainda que a granularidade do tempo e o milesimo de segundo.
Se forem detectados erros, eles serao assinalados no retorno da funcao. Os servicos
da SWCP nao sao agora utilizados, mas continua a ser necessario recorrer ao ambiente
de suporte LSE, dado que se pretende manter a independencia da biblioteca face ao
sistema operativo (as bibliotecas devem ser portateis, tal como a celula NavCim).
4.3 A Celula NavCim
Dando continuidade a descricao da concretizacao e do funcionamento dos com-
ponentes da plataforma NavCim, abordamos nesta seccao o seu componente central,
ou seja, a celula NavCim. Por considerarmos que a exposicao exaustiva do software
desenvolvido seria inapropriada e demasiado extensa, optamos por referir apenas os
aspectos, no nosso entender, com relevancia significativa. Mais uma vez referimos que
todo o software foi desenvolvido na linguagem C.
4.3.1 Linguagem de Configuracao
Um dos aspectos importantes da celula NavCim, quer pelo facto de implicar a
tomada de opcoes ao nıvel da concretizacao, quer pela visibilidade que tem do ponto
de vista da utilizacao, consiste no metodo utilizado para leitura e interpretacao do
ficheiro de configuracao.
Em termos da concretizacao, admitimos que a construcao do interpretador pode
ser feita de duas maneiras: a) desenvolvendo explicitamente o codigo necessario; b)
utilizando ferramentas proprias, que o geram autonomamente. A escolha de uma
destas solucoes e fundamentalmente determinada pela complexidade do problema a
resolver, sendo a primeira mais adequada para a resolucao de pequenos problemas.
CAPITULO 4. CONCRETIZACAO 124
Assim, consideramos que no nosso caso a complexidade do problema justificava
a utilizacao de ferramentas especializadas, mesmo sabendo que isso obrigaria ao
conhecimento e estudo dessas ferramentas.
Apesar de ter sido a complexidade do problema o factor determinante para a
utilizacao destas ferramentas, outros aspectos foram tambem tomados em considera-
cao, nomeadamente as facilidades de modificacao da sintaxe e de introducao de
novas regras e a possibilidade de definir uma linguagem clara, simples e eficiente.
Perspectivando a continuidade do trabalho desenvolvido, esta era, sem duvida, a op-
cao mais aconselhavel.
A definicao exacta da sintaxe das instrucoes de configuracao, apresentada na ta-
bela 4.1, so foi efectuada apos ser conhecido o metodo de interpretacao utilizado,
conseguindo-se assim, adaptando a sintaxe, simplificar o desenvolvimento do inter-
pretador.
As ferramentas utilizadas foram o FLEX�� [SUN90, Paxson 93], para realizacao da
analise lexica, e o YACC�� [SUN90] para definicao das regras de sintaxe e geracao
do interpretador. Ambas estao disponıveis nos sistemas operativos mais utilizados
(em particular no UNIX, onde foram inicialmente desenvolvidas, e no OS/2) e o seu
funcionamento consiste na criacao de ficheiros de linguagem C, que serao utilizados
em conjunto com codigo definido pelo utilizador. A geracao destes ficheiros e feita
com base em regras, que consistem em regular expressions no caso do FLEX, e que sao
descritas numa linguagem propria, no caso do YACC.
As directivas que determinam a configuracao inicial da celula NavCim tem de
respeitar a sintaxe apresentada na tabela 4.1. Cada directiva e identificada por uma
palavra-chave e e constituıda por diversos argumentos que podem ser opcionais��,
sendo a directiva VMD ENTRY especialmente utilizada para indicar e iniciar uma sec-
cao contendo a informacao relativa a um determinado VMD. A interpretacao das
directivas e consequente construcao das estruturas internas de informacao e feita
sequencialmente, o que implica o respeito por uma ordem de declaracao, que coincide
com a ordem apresentada. No entanto, cada directiva pode ser repetidamente utilizada
��Fast LEXical analyzer generator.��Yet Another Compiler Compiler.��Na tabela, as palavras-chave estao escritas em letras maiusculas, os argumentos opcionais estao
representados entre parentesis rectos e as opcoes de escolha sao indicadas com uma barra vertical.
CAPITULO 4. CONCRETIZACAO 125
VMD�ENTRY vmdName
VARIABLE �vmd��name scope �domainName� type
scope� VMD� DOMAIN� AA
type � INTEGER� UNSIGNED� BOOLEAN� VISIBLE
GROUP groupName �varName��� ��� �varName�k
EVENT eventName varNamegroupName �mode� �fileName�
mode� LEVEL� PULSE
READ readName varNamegroupName �fileName� interval
interval� em milesimos de segundo
WRITE writeName varNamegroupName �value��� ��� �value�k
PROC procName eventNamereadName operation samples outputPeriod �fileName�
operation � AVERAGE� STDEV� SUM� MAX� MIN
samples � numero de amostras processadas
outputPeriod� periodo �em numero de amostras de processamento
So sao permitidos os tipos INTEGER e UNSIGNED
ALARM alarmName eventNamereadNameprocName
�c����v���� ��� �c�k��v�k� �switch�
�ARCH fileName� �EXEC actionName� �REPORT�
condition� HIGH LOW EQUAL EQHIGH EQLOW �para INTEGER e UNSIGNED
condition� TRUE FALSE �para BOOLEAN
switch � INCL EXCL �so para grupos� k��
O numero de pares condition value deve igualar a dimensao do grupo
Tabela 4.1: Sintaxe da linguagem de configuracao.
para definir todos os objectos ou accoes pretendidos. Note-se que a referencia a um
objecto so pode ser feita se ele estiver definido na mesma seccao, ou seja, se for relativo
ao mesmo VMD.
Na tabela apresentada nao e descrita qualquer directiva relacionada com o arquivo
de dados, uma vez que essa funcionalidade nao foi ainda incluıda na presente versao
da celula NavCim.
CAPITULO 4. CONCRETIZACAO 126
4.3.2 Mecanismos de Execucao Concorrente
No modelo computacional proposto, a execucao de algumas tarefas da responsa-
bilidade da celula NavCim e motivada por factores independentes, internos ou ex-
ternos, que podem ocorrer concorrentemente. Assim, dependendo da concretizacao,
a execucao dessas tarefas podera ser tambem concorrente, ou poderao ser utilizados
mecanismos que determinem o seu sequenciamento.
No desenvolvimento da celula NavCim a solucao que adoptamos nao foi uniforme,
verificando-se ambas as situacoes de execucao concorrente e sequencial��. Assim,
dado que no ambiente de suporte LSE nao eram oferecidos mecanismos de execucao
concorrente, foi necessario disponibiliza-los a partir do suporte existente nos sistemas
operativos utilizados.
No sistema operativo OS/2 a concorrencia pode ser levada a cabo atraves da cria-
cao de actividades��, cuja gestao compete ao proprio sistema. Todas as actividades
criadas por um processo partilham o mesmo segmento de codigo e de dados, tendo
por isso acesso ao mesmo contexto de execucao. Em termos de execucao as activida-
des sao independentes, existindo mecanismos de preempcao e de escalonamento que,
em funcao da prioridade e da criticalidade de cada uma, permitem atribuir o proces-
sador a uma das que estiverem em condicoes de se executar. O sistema disponibiliza
tambem mecanismos de sincronizacao explicitamente vocacionados para as activida-
des, essenciais para a definicao de regioes de exclusao mutua e para a resolucao dos
problemas causados pela preempcao.
Infelizmente, o sistema operativo SunOS para o qual desenvolvemos a plataforma
nao dispoe de qualquer mecanismo interno de gestao de actividades, sendo a execucao
concorrente exclusivamente materializada por processos. Foi assim necessario utilizar
um pacote de software para gestao de actividades, tendo sido escolhido aquele que
e disponibilizado pela propria Sun, ou seja, o pacote de LWP�� [SUN90]. A gestao
das actividades LWP e realizada exteriormente ao sistema operativo, no contexto de
um processo, apresentando por isso caracterısticas diferentes das actividades OS/2.
De facto, a diferenca mais significativa prende-se com o facto de o controlo de execu-��A discussao dos fluxos de execucao e das opcao tomadas ao nıvel de concorrencia sao apresentadas
na seccao 4.3.3 .��Em ingles designadas por threads.��Light Weight Processes.
CAPITULO 4. CONCRETIZACAO 127
cao estar a cargo do programador, uma vez que nao existe nenhum mecanismo de
preempcao externo. Uma outra diferenca relaciona-se com a invocacao de chamadas
do sistema bloqueantes, que no OS/2 apenas provocam o bloqueio da actividades
que executa a chamada (passando a execucao para outra actividade) e no SunOS
provocam o bloqueio do processo na sua totalidade (impedindo a execucao de
qualquer outra actividade). Esta diferenca pode ser, contudo, anulada, se for utilizada
uma biblioteca de funcoes (tambem disponıvel no pacote de LWP) que redefine
as chamadas bloqueantes por forma a que o funcionamento das actividades seja
semelhante ao das do OS/2.
Relativamente a mecanismos de sincronizacao, refira-se que estes sao tambem
disponibilizados pelo pacote de LWP, apesar da sua necessidade ser mais reduzida
que no OS/2, pelo facto de as actividades nao serem preemptıveis.
No ambiente de suporte LSE foram assim incorporadas as funcionalidades descri-
tas, tendo-se construıdo uma interface identica nos dois sistemas que, apesar das ine-
vitaveis diferencas semanticas, permite a utilizacao do mesmo codigo da celula Nav-
Cim.
4.3.3 Arquitectura de Software
Como afirmamos na seccao anterior, foram utilizadas as duas aproximacoes
possıveis para o tratamento dos eventos geradores de actividade da celula NavCim,
as quais consistem na: (a) deteccao centralizada dos eventos e no sequenciamento do
respectivo processamento; (b) na deteccao descentralizada e na execucao concorrente
do processamento.
Na solucao adoptada, o tratamento dos eventos que desencadeiam a actividade
da celula e feito em duas actividades de execucao, sendo uma delas exclusivamente
responsavel pelo tratamento das mensagens relativas ao protocolo MMS e sendo a
outra responsavel pela deteccao dos seguintes acontecimentos:
� Mensagens provenientes da rede, enviadas atraves do TCP/IP e geradas pelo
protocolo de sincronizacao de relogios;
� Mensagens locais, enviadas pelas aplicacoes;
CAPITULO 4. CONCRETIZACAO 128
� Expiracao de temporizadores.
Esta solucao foi em grande parte condicionada pela interface de programacao
da SWCP, a qual nao disponibiliza nenhum mecanismo normalizado para deteccao
da existencia de mensagens pendentes (por exemplo, um descritor que pudesse ser
utilizado na primitiva do sistema select), sendo essa deteccao apenas possıvel atraves
da invocacao de primitivas. Nesta interface a recepcao de mensagens e feita atraves
da utilizacao da primitiva se process events, a qual constitui o escalonador SWCP
que, para cada mensagem pendente, ira invocar a respectiva funcao de tratamento��.
Se nao estiver nenhuma mensagem pendente o escalonador ficara bloqueado ate que
uma seja recebida, retornando apos o seu tratamento. Contudo, existe uma primitiva
que permite obter o numero de mensagens pendentes, se pending events, informacao
esta que pode ser utilizada para evitar chamadas bloqueantes ao escalonador.
No nosso caso, a utilizacao do ambiente de suporte LSE permite detectar e tratar
todos os outros eventos, para alem das mensagens MMS, atraves do escalonador
LSE. Como este nao pode ser utilizado para detectar mensagens MMS pendentes,
consideramos que a melhor solucao seria a criacao de duas actividades para execucao
de cada um dos dois escalonadores em paralelo. A outra solucao, evitando o recurso
as actividades mas implicando uma utilizacao ineficiente dos recursos existentes (em
particular do processador), seria definir de um ciclo de espera activa onde fossem
utilizadas as funcoes se pending events e a correspondente do LSE, associadas a
activacao dos respectivos escalonadores.
Um problema que surge com a execucao concorrente das actividades da celula e o
do acesso e modificacao das estruturas de dados globais. Estas estruturas, contendo
o “conhecimento” da celula, sao acedidas pelos diversos modulos funcionais que aı
buscam a informacao necessaria para execucao das suas tarefas. Assim, dado que
existem dois fluxos de execucao paralelos, e necessario averiguar que modulos podem
estar simultaneamente activos e, se for necessario, precaver possıveis situacoes de
acesso concorrente aos dados. Repare-se que a criacao de zonas de exclusao mutua
e apenas motivada pelas accoes de modificacao dos dados, uma vez que se os acessos
fossem unicamente para leitura nao haveria qualquer problema. Dado que o modulo
��As funcoes de tratamento sao indicadas como argumentos da primitiva. Se nao for especificadauma funcao para determinado tipo de mensagens (por exemplo, confirmacoes), estas serao ignoradas.
CAPITULO 4. CONCRETIZACAO 129
de configuracao e o unico cuja actividade implica a modificacao das estruturas de
dados, basta analisar os modulos que podem com ele executar concorrentemente. Pela
observacao da figura 4.3 verifica-se que nesta situacao se encontram os modulos de
gestao de eventos e de representante de VMD, bem como aqueles (nao representados
na figura) que se encontram no seu caminho de execucao, ou seja, os modulos de pre-
processamento, de alarmes e de arquivo.
�� �����
�������
�����,= $����
5)�
���� � ����������, �&�������� *���
�� �����!��� "���#���������
( �)���
������ ����
�#��
��'���������
�#�����������
Figura 4.3: Os dois nucleos de execucao da celula NavCim.
Relativamente ao funcionamento dos escalonadores, refira-se que o da SWCP
apenas tem de gerir as mensagens recebidas num unico ponto de acesso, resultantes
da comunicacao quer com as aplicacoes (VMDs) locais quer com os agentes CM
(igualmente locais). O escalonador LSE, apesar de tratar tres tipos de eventos, tem
de gerir apenas dois pontos de acesso, relativos a mensagens provenientes da rede
e a mensagens locais, uma vez que os temporizadores, sendo utilizados em modo
sıncrono, assinalam a expiracao das temporizacoes atraves do envio de mensagens
para o ponto de acesso local do escalonador. O tratamento das mensagens pendentes
no ponto de acesso local segue uma polıtica do tipo FIFO, sendo dada prioridade, no
CAPITULO 4. CONCRETIZACAO 130
entanto, a todas as mensagens que surgem da rede.
Em resumo, pode dizer-se que a arquitectura de software da celula NavCim se
baseia na existencia de dois fluxos de execucao paralelos, no curso dos quais sao
activados os diversos modulos funcionais cuja accao e determinada pela informacao
de configuracao contida em estruturas de dados globais. A activacao dos modulos
representados na figura e feita pelos escalonadores em funcao dos eventos recebidos.
Para que os modulos de coleccao e de eventos saibam que outros modulos devem ser
invocados, as estruturas de dados que descrevem as suas accoes contem referencias
para as estruturas de dados que descrevem outras accoes. Assim, por cada uma
das referencias definidas e chamado o modulo correspondente, sendo-lhe enviada
esse referencia para a estrutura que descreve a accao a efectuar. Este mecanismo e
sucessivamente utilizado por cada um dos modulos chamados, estabelecendo-se assim
um fluxo de execucao sequencial dentro de cada uma das actividades da celula.
4.3.4 Coleccao de Dados
O modulo de coleccao de dados desempenha um papel fundamental no contexto
de toda a celula, sendo de grande importancia as decisoes tomadas ao nıvel da
sua concretizacao. Assim, temos de assinalar tres aspectos que nos parecem de
grande relevancia, uma vez que tem implicacoes consideraveis no desempenho e no
funcionamento da celula.
Como e sabido, na configuracao das accoes de coleccao de dados e estabelecido o
intervalo de tempo com que deverao ser efectuadas, cujo valor e utilizado na defini-
cao dos temporizadores que as desencadeiam. Idealmente, assim que terminasse uma
temporizacao deveria ser iniciada uma nova, por forma a que o perıodo especificado
fosse rigorosamente cumprido. Tal poderia ser feito utilizando as facilidades do
ambiente de suporte LSE, que permitem a criacao de temporizadores que se auto-
-activam apos cada intervalo de tempo. Desta forma, cada temporizador iria enviar
periodicamente uma mensagem para o escalonador LSE, que seria colocada em fila
de espera ate ser atendida. O problema desta aproximacao seria a possıvel acumula-
cao de mensagens enviadas pelo mesmo temporizador, nao atendidas devido a um
eventual atraso na execucao das accoes anteriores. De facto, em face dos objectivos do
modulo de coleccao de dados, e inutil acumular os eventos de temporizacao, uma vez
CAPITULO 4. CONCRETIZACAO 131
que o factor importante e a periodicidade de actualizacao dos dados e nao o numero
de vezes que sao actualizados.
A solucao optima, utilizada na nossa concretizacao, pode ser observada na figura
4.4 (B e D) e consiste em activar o temporizador apenas apos o termo da accao de
coleccao, ajustando o valor da temporizacao para que esta se aproxime do perıodo
especificado. Assim, se o perıodo nao for cumprido, a nova accao de coleccao sera
imediatamente executada assim que termine a anterior. Se o valor da temporizacao
nao fosse ajustado, verificar-se-iam as situacoes A e C representadas na figura 4.4.
-
�
�
$����
��������������������� ���� ������ $���������������%��&'
�������������
��������������()"�
*����������()"�
F �9�8
$������6������9�0��8�
$������6������9�
-������� ����� $������6������9�
=�=�=�=
� =�=�=�=
(������� =�=�=�=
=�=�=�=
� +������������()"�
-������� �����
-������� �����
-������� �����
(�������
(�������
Figura 4.4: Temporizacoes na coleccao de dados.
Um outro aspecto que importa referir consiste na possibilidade de utilizar as
primitivas de leitura de dados do MMS de forma nao bloqueante, contrariamente ao
que e efectuado na nossa concretizacao. A leitura nao bloqueante dos dados poderia
melhorar a eficiencia deste modulo, uma vez que poderiam ser simultaneamente
executadas accoes de coleccao distintas. Neste caso, o modulo de coleccao seria
decomposto em duas partes, uma emissora e uma receptora, as quais se executariam
concorrentemente, passando a ser necessario concretizar mecanismos de exclusao
CAPITULO 4. CONCRETIZACAO 132
mutua (apenas na parte receptora).
O facto de nao termos utilizado esta aproximacao deve-se a um problema de
funcionamento encontrado no software da plataforma SWCP, que so pode ser evitado
se a primitiva de leitura for utilizada em modo bloqueante. Em futuras versoes desta
plataforma o problema sera certamente corrigido, sendo entao aconselhavel modificar
a forma de funcionamento do modulo de coleccao de dados.
Finalmente, um ultimo aspecto importante consiste na deteccao e no tratamento
de falhas realizado por este modulo. Quando ocorre a falha do um VMD (ou a sua
inacessibilidade temporaria) as primitivas de leitura de dados que a ele se referem
retornam com uma condicao de erro que denuncia essa ocorrencia. Nesta situa-
cao, a imagem do VMD, distribuıda atraves dos repositorios de tempo-real, fica
inevitavelmente estagnada ate que o VMD volte a estar activo. O modulo de coleccao
nao volta a activar o temporizador, impedindo novas execucoes da accao de coleccao,
e desencadeia um mecanismo de recuperacao de falhas, concretizado pelo modulo de
configuracao, que consiste na execucao de tentativas periodicas para o estabelecimento
da associacao com o VMD falhado, e na consequente activacao das accoes de coleccao
que lhe dizem respeito.
4.3.5 Tratamento de Eventos
No que respeita ao funcionamento e a concretizacao do modulo de gestao de
eventos, falaremos apenas de um aspecto cujo nomeacao se justifica pelo facto de ser
exclusivo deste modulo. Referimo-nos a necessidade de identificar o evento a que
as mensagens de informacao MMS recebidas se referem, uma vez que estas apenas
indicam nomes de variaveis e nao nomes de eventos.
Na realidade, o mecanismo de reconhecimento de eventos e extremamente simples.
Quando recebe uma mensagem, o modulo de eventos pesquisa exaustivamente todas
as estruturas de dados referentes a eventos definidos na celula ate encontrar a que
corresponde as variaveis recebidas. A partir daı, sendo conhecida a estrutura de dados
que descreve o evento e as accoes a ele associadas, a execucao do modulo prossegue
normalmente. Se o evento nao estiver definido nao sera executada qualquer accao
especıfica, sendo este apenas enviado para o modulo de representacao do VMD da
CAPITULO 4. CONCRETIZACAO 133
celula.
Como contrapartida pela sua simplicidade, este metodo revela-se muito ineficiente
se o numero de eventos definidos for elevado. Infelizmente, uma vez que as entidades
que geram os eventos (os VMDs) nao tem acesso ao contexto de execucao da celula
(nao podendo indicar de uma forma explicita a estrutura de dados que representa o
evento assinalado) este e o unico metodo que pode ser utilizado.
4.3.6 Servico de Tempo Global
A concretizacao do servico de tempo global da celula NavCim e baseada num
algoritmo de sincronizacao interna de relogios muito semelhante ao proposto por
Srikanth e Toueg [Srikanth 87], tendo sido incorporadas algumas ideias que permitem
a realizacao simultanea de sincronizacao externa de relogios. Assim, uma vez que o
algoritmo concretizado apresenta algumas diferencas relativamente ao algoritmo que
lhe serviu de modelo, parece-nos importante fazer aqui a sua descricao, ainda que
informal. Assumiremos que o leitor esta relativamente familiarizado com a tematica da
sincronizacao de relogios, nao sendo por isso feita uma introducao previa dos termos
e dos conceitos utilizados.
4.3.6.1 Sincronizacao Interna
A execucao deste algoritmo e muito simples. Quando um processador decide
iniciar um novo ciclo de ressincronizacao (ou seja, quando o seu relogio virtual,
RV �t�, atinge um valor pre-determinado) envia uma mensagem SYNC para todos os
participantes. Ao receberem esta mensagem, os processadores verificam se ela e valida
(o ciclo a que diz respeito nao deve ser um ciclo anterior) e, se tal acontecer, ajustam
o valor do seu relogio virtual utilizando os parametros enviados na mensagem. O
perıodo de ressincronizacao, T , e calculado em funcao da precisao pretendida e da
taxa de desvio maxima dos relogios fısicos.
Este algoritmo, representado na figura 4.5, garante que os criterios de precisao
sao verificados, desde que os processadores sejam correctos e desde que nao ocorram
omissoes nas transmissoes. Note-se que o facto dos relogios virtuais terem tendencia
a adiantar-se, uma vez que as ressincronizacoes sao determinadas pelos relogios mais
CAPITULO 4. CONCRETIZACAO 134
velozes, apenas afecta a sua exactidao, que sera no entanto mantida pela componente
de sincronizacao externa do algoritmo.
Uma diferenca fundamental entre o nosso algoritmo e o de Srikanth consiste no
valor temporal apresentado pelos relogios virtuais, que no nosso caso devera estar
relacionado com uma referencia de tempo “real” (devera ser exacto�), ao passo que
no outro apenas devera ser preciso�. Assim, em cada ressincronizacao, os relogios
sao acertados nao apenas em funcao do ciclo e do perıodo de ressincronizacao (i e
T , respectivamente), mas tambem em funcao de um valor de referencia, ref , que
devera ser identico em todos os nos do sistema. Esta referencia e determinada
por cada participante no inıcio da execucao (quando i � �), a partir do valor do
relogio fısico local. Assim, o relogio virtual e inicializado com o tempo fısico local,
independentemente da existencia de uma fonte externa ou de um tempo global
definido por outros participantes que ja estejam a executar o algoritmo. Desta forma, e
possıvel que o relogio virtual permaneca algum tempo impreciso, pelo menos ate que
todas as referencias sejam iguais.
Havendo apenas um elemento activo, o seu relogio virtual sera identico ao relogio
fısico do sistema. O segundo processador a iniciar a execucao do algoritmo enviara
uma mensagem com i � � que inicializara o seu relogio virtual, mas que sera ignorada
pelo processador ja activo, que tera i � �. Nesse momento os valores de i e ref
serao diferentes mas passarao a ser iguais quando o primeiro processador enviar
uma mensagem SY NC. Na verdade, o algoritmo garante que todos os processadores
ficarao com valores de i, T e ref identicos e iguais aos do primeiro processador a iniciar
a execucao do algoritmo.
Note-se que apos a aplicacao do ajuste ao relogio virtual os processadores que
ainda nao enviaram a mensagem SY NC tambem ja nao o farao. Isto significa que sera
possıvel a sincronizacao de todos os relogios com o envio de apenas uma mensagem.
Em contrapartida, significa tambem que poderao surgir problemas devido a faltas de
omissao, assunto sobre o qual falaremos mais a frente.
�A exactidao e uma medida da diferenca maxima que se pode verificar entre o valor de um relogio eo valor do tempo absoluto.
�A precisao e uma medida da diferenca maxima que se pode verificar entre dois relogiossincronizados.
CAPITULO 4. CONCRETIZACAO 135
case evento ofRVi���t� � iT � ref :
broadcast (h SYNC, i, T , ref i ) ;
mensagem h SYNC, i, T , ref i :if i � i local then
ref local � ref ;T local � T ;if i � adj i then
RVi�t� � iT � adj ref ;else
RVi�t� � iT � ref ;i � i� � ;
fi;
RVi�t� � jText :ajuste � RE�t��RVi�t� ;broadcast (h ADJST, i� �, T , ref � ajuste i ) ;
mensagem h ADJST, i, T , ref i :if i � i local then
adj i � i ;adj ref � ref ;
fi;esac;
Figura 4.5: Algoritmo utilizado.
Convem referir que para evitar “saltos” no valor do tempo virtual, o ajuste
correspondente a diferenca entre dois relogios virtuais consecutivos e aplicado de uma
forma contınua ao longo dos perıodos de ressincronizacao seguintes.
Na nossa concretizacao o envio das mensagens foi efectuado utilizando o servico
de rede do ambiente de suporte LSE, o qual se baseia na interface de sockets do sistema
(enviando as mensagens em difusao, sobre o TCP/IP).
4.3.6.2 Sincronizacao Externa
No respeitante a sincronizacao externa, esta e tambem feita periodicamente, sendo
o periodo (Text) calculado em funcao da exactidao requerida e, tal como na sincroniza-
cao interna, da taxa de desvio maxima dos relogios fısicos. O envio da mensagem
ADJST processa-se concorrentemente com o resto do algoritmo, sendo o processador
CAPITULO 4. CONCRETIZACAO 136
com acesso ao relogio externo (RE�t�) o unico responsavel pelo envio desta mensagem.
Este processador calcula a diferenca entre o seu tempo virtual e o tempo real, a qual
e utilizada para ajustar o valor de referencia (ref ), que constitui a base do tempo
virtual. Para que este ajuste seja efectuado em todos os elementos participantes, e
disseminada uma mensagem contendo a nova referencia temporal (ref � ajuste) e o
ciclo de ressincronizacao (i� �) em que esta nova referencia devera ser aplicada.
E evidente que se ocorrerem omissoes no envio destas mensagens, alguns relogios
virtuais ficarao dessincronizados, constituindo esta uma das razoes pelas quais este
algoritmo nao e tolerante a faltas.
4.3.6.3 Tolerancia a faltas
O algoritmo apresentado na figura 4.5 nao e tolerante a faltas. De facto, para
que este algoritmo tolerasse f processadores faltosos era necessario que as decisoes
so fossem aceites quando pelo menos f � � participantes estivessem de acordo, ou
seja, quando pelo menos um deles fosse garantidamente correcto. No entanto, como
pretendıamos que o algoritmo fosse executado mesmo que so existisse um elemento,
arbitramos para f o valor 0, tendo sido eliminadas as condicoes de maioria.
Para que fosse possıvel manter as caracterısticas de tolerancia a faltas e, ao mesmo
tempo, permitir a execucao do algoritmo apenas com a presenca de um elemento,
seria necessario introduzir o conceito de grau de tolerancia adaptativo [Rodrigues 93b],
que exige, contudo, a utilizacao de mecanismos de filiacao. Caso se revelasse
indispensavel garantir a tolerancia a faltas, poderiam utilizar-se os mecanismos de
filiacao disponibilizados por uma plataforma de comunicacao em grupo (por exemplo
o xAMp).
No que respeita as faltas de omissao, estas poderiam ser facilmente toleradas
se fossem utilizados mecanismos de comunicacao fiaveis, bastando para tal recorrer
novamente aos servicos de uma plataforma de comunicacao em grupo. Por exemplo,
a utilizacao da qualidade de servico reliable do xAMp seria suficiente para evitar
problemas devidos a omissoes.
CAPITULO 4. CONCRETIZACAO 137
4.4 Cenario de Aplicacao
No sentido de confirmar as potencialidades de plataforma desenvolvida, foi
construıdo o cenario representado na figura 4.6, que ilustra um hipotetico sistema de
supervisao industrial. Neste cenario estao incluıdos os tres nıveis hierarquicos que
normalmente se podem considerar em ambientes reais, sendo o nıvel dos dispositivos
representado por um braco robot.
O VMD que representa o braco robot foi colocado numa plataforma computacional
cuja funcao exclusiva e, precisamente, realizar essa representacao. Em termos dos
casos possıveis para a configuracao dos VMDs dos dispositivos, este corresponde a
situacao b) representada na figura 3.4 e descrita na seccao 3.2.1. A ligacao entre o
robot e a plataforma computacional consiste numa ligacao serie (RS232), tendo sido
desenvolvido o codigo necessario, parte integrante do VMD, para comunicacao atraves
desta interface. O sistema operativo existente nesta plataforma computacional e o
OS/2, de forma a que o cenario se aproxime o mais possıvel da generalidade das situa-
coes reais.
#� ���
#���� ��
#���� ��
#�&��
#�9;9 ��BGD��%9�9=8 ��BGD
��%9�9=8
��-#��������� ����B=8=;
5)�#�&��
�: (����
('�� ���,�����
(<�
#������7������$����0��
Figura 4.6: Cenario de demonstracao da plataforma NavCim.
CAPITULO 4. CONCRETIZACAO 138
Foi utilizada uma segunda plataforma, tambem com o sistema operativo OS/2,
que pretende representar o nıvel de controlo da celula industrial. Nesta plataforma
foram colocadas diversas aplicacoes, entre as quais uma celula NavCim, que simulam
as aplicacoes de supervisao normalmente existentes neste nıvel. Como pode ser visto
na figura 4.6, os repositorios de tempo-real estao situados nesta plataforma, sendo
actualizados pela celula NavCim e utilizados pelas aplicacoes de supervisao.
Entre as aplicacoes de supervisao construıdas, podemos referir uma aplicacao
grafica cujo objectivo e apresentar um sinoptico do braco robot e uma aplicacao
construıda na folha de calculo EXCEL (com base em macros) que permite visualizar
um conjunto de graficos representativos da evolucao de variaveis do robot.
Uma outra aplicacao, ilustrada na figura 4.7, foi utilizada para fazer a monitoriza-
cao da celula NavCim, podendo considerar-se esta aplicacao como parte integrante da
plataforma. Esta aplicacao, que recorre as bibliotecas de interface disponibilizadas na
plataforma, permite igualmente a modificacao dinamica da configuracao da celula.
Figura 4.7: A aplicacao PMtool.
Uma perspectiva global das aplicacoes que podem ser visıveis nesta plataforma do
cenario construıdo e apresentada na figura 4.8.
CAPITULO 4. CONCRETIZACAO 139
Figura 4.8: As aplicacoes PMrob, PMtool e a celula NavCim.
Finalmente, para simular a existencia de um nıvel de gestao utilizamos uma plata-
forma UNIX, que foi colocada numa rede de comunicacao independente, interligada
atraves de um router. Em termos da configuracao dos repositorios de informacao, o
cenario foi construıdo de modo a que fosse possıvel aceder no nıvel de gestao a uma
imagem do repositorio de tempo-real, localizada no nıvel inferior.
Para demonstrar a natureza distribuıda da plataforma, foi construıdo um sinoptico
do robot identico ao existente no nıvel de celula��, de modo a que fosse possıvel
observar em simultaneo, e em locais distintos, representacoes baseadas exactamente
no mesmo estado (veiculado atraves do repositorio de tempo-real e da sua imagem).
O facto de ter sido possıvel construir este cenario permitiu demonstrar as capaci-
dades efectivas proporcionadas pela plataforma NavCim para construcao de sistemas
de supervisao e controlo.
��Se no nıvel de gestao fosse utilizado o OS/2 a aplicacao poderia ser a mesma.
CAPITULO 4. CONCRETIZACAO 140
4.5 Desempenho
Relativamente ao desempenho da plataforma, sao essencialmente dois os vectores
que consideramos importante analisar: a influencia dos tempos de execucao das
primitivas MMS nas accoes de coleccao de dados e a influencia do sistema de ficheiros
distribuıdo (neste caso o NFS) nas caracterısticas de tempo-real dos repositorios.
Pensamos que a analise do desempenho da plataforma do ponto de vista da velocidade
de execucao do software nao e relevante quando comparada com a importancia dos
aspectos de comunicacao.
As medidas que efectuamos utilizaram como base a infraestrutura descrita na sec-
cao anterior, no sentido de se obterem resultados com significado face as situacoes reais
de funcionamento do sistema. Assim, foi feita uma instrumentacao do codigo da celula
NavCim, de modo a que fosse possıvel obter os tempos de execucao “reais” de duas
das primitivas disponibilizadas pela plataforma SWCP: leitura e escrita de variaveis.
Os valores obtidos, apresentados na tabela 4.2, dizem respeito quer a execucoes locais
das primitivas, quer a execucoes remotas. Neste ultimo caso, convem referir que o
agente de comunicacoes remotas da SWCP utilizado foi o CM-TCP/IP.
Foram utilizadas as duas plataformas para as quais a celula NavCim se encontra
disponıvel (OS/2 e SunOS), tendo sido consideradas todas as hipoteses de funciona-
mento possıveis. Os valores representados dizem respeito a valores medios, nao tendo
sido feita qualquer analise estatıstica.
Tempos de execucao das primitivas MMS (ms)Leitura Escrita
Sistemas Local Remota Local RemotaOS/2–OS/2 78 290 77 288
SunOS–SunOS 9 113 10 111OS/2–SunOS – 229 – 227
Tabela 4.2: Tempos de execucao utilizando o agente CM-TCP/IP.
Da observacao dos valores apresentados pode imediatamente constatar-se uma
diferenca significativa entre execucoes locais e remotas. Alem disso, verifica-se ainda
que essa diferenca e mais acentuada no SunOS do que no OS/2, o que sera certamente
justificado por uma maior eficiencia dos mecanismos de comunicacao locais do
CAPITULO 4. CONCRETIZACAO 141
primeiro destes sistemas face aos mecanismos de comunicacao remotos. Apesar de
nao ser o nosso objectivo a comparacao dos sistemas operativos, salientamos a diferen-
ca registada, que permite pressupor uma maior rapidez do SunOS face ao OS/2��.
A influencia destes valores na plataforma, traduz-se na capacidade maxima de
coleccao de dados que e possıvel atingir. Na melhor das hipoteses, verifica-se que
e possıvel efectuar aproximadamente 100 accoes de coleccao de dados por segundo
(durando cada uma 9 ms) e, no pior cenario, este numero sera de 3 por segundo. Se
tivermos como meta para a “frescura” dos dados um valor de 100ms (que, em certos
casos, sera ate conservativo), podemos concluir que os valores obtidos ficam abaixo
do desejavel. No entanto, convem salientar que estes valores sao condicionados pela
plataforma SWCP, nao podendo ser imputados a qualquer opcao arquitectural.
Para que nao existissem duvidas quanto a possibilidade dos valores estarem
relacionados com o agente de comunicacao remota utilizado, realizamos tambem
algumas medidas que permitem comparar o desempenho dos agentes CM-ISODE e
CM-TCP/IP. Os valores obtidos, apresentados na tabela 4.3, permitem concluir que
o agente CM-TCP/IP nao tem qualquer influencia na velocidade de execucao das
primitivas MMS, quando comparado com o agente CM-ISODE.
Tempos de execucao com o CM-ISODE e o CM-TCP/IP (ms)Leitura Escrita
Sistemas ISODE TCP/IP ISODE TCP/IPOS/2–OS/2 264 290 263 288
SunOS–SunOS 113 113 115 111OS/2–SunOS 200 229 197 227
Tabela 4.3: Influencia do agente CM.
Finalmente, mas nao menos importante, averiguamos a influencia do NFS nas
operacoes de leitura de dados dos repositorios. Os valores obtidos, apresentados
na tabela 4.4, permitem comparar os tempos de execucao da primitiva de leitura
de dados quando esta e realizada sobre um repositorio local e sobre uma imagem
de uma repositorio (obtida por NFS). Refira-se que na situacao em que intervem os
dois sistemas operativos, as plataformas computacionais estavam situadas em redes
��Convem nao esquecer que o tipo de processador existente em cada plataforma tem uma influenciadecisiva nos valores obtidos, nao se devendo por isso formular conclusoes precipitadas quando adesempenho relativo dos sistemas operativos.
CAPITULO 4. CONCRETIZACAO 142
distintas, o que se traduz na obtencao de valores que correspondem a um cenario
pessimista.
Foram utilizados dois metodos de leitura de dados, ambos permitindo a leitura
dos dados iniciais do ficheiro: a) procedendo a abertura do ficheiro para cada leitura ;
b) procedendo ao reposicionamento (no inıcio do ficheiro) do descritor de leitura.
Tempos medios de leitura (256 bytes; ms)Cenario Metodo
(Cliente/Servidor) open lseekOS/2 local 4.3 0.5
SunOS local 1.2 0.6OS/2 / OS/2 90.9 23.0
SunOS / OS/2 110.0 6.3SunOS / SunOS 17.3 3.6
Tabela 4.4: Influencia do NFS nos tempos de leitura de dados.
Observando a tabela, verifica-se, tal como seria de esperar, que os tempos de leitura
locais sao nitidamente inferiores aos tempos de leitura remotos. No entanto, os valores
obtidos permitem confirmar a ideia de que a utilizacao do NFS nao compromete, de
forma alguma, a construcao do sistema de supervisao. De facto, o maior valor temporal
registado (110 ms) permite, ainda assim, que seja efectuada uma dezena de accoes de
coleccao de dados sendo todos os resultados destas accoes visıveis remotamente.
Relativamente as diferencas registadas entre as duas formas de leitura avaliadas,
podemos concluir e vantajoso utilizar um metodo de leitura que nao implique a
necessidade de abertura do ficheiro.
4.6 Resumo
Este capıtulo foi dedicado a descricao dos aspectos de concretizacao da plataforma
NavCim. Os modulos de suporte da plataforma e os modulos de interface foram
descritos em pormenor, completando a breve descricao que tinha sido efectuada no
capıtulo anterior.
Foram tambem analisadas as particularidades mais importantes da plataforma
concretizada, quer no tocante a aspectos de engenharia, quer no que diz respeito a
CAPITULO 4. CONCRETIZACAO 143
solucoes particulares utilizadas.
Finalmente, descreveram-se as aplicacoes de software desenvolvidas no ambito
deste trabalho, e discutiram-se algumas medidas de desempenho da plataforma.
Capıtulo 5
Conclusoes e Perspectivas Futuras
Este trabalho apresentou a arquitectura distribuıda NavCim, destinada a suportar
o desenvolvimento de sistemas de controlo e supervisao de processos industriais, pre-
enchendo as lacunas evidenciadas por muitos sistemas SCADA actualmente existentes
no mercado, em particular no que respeita a resolucao dos problemas de heterogenei-
dade, escalabilidade e desempenho.
O estudo e sistematizacao das principais caracterısticas dos sistemas SCADA,
focado essencialmente em quatro sistemas representativos do leque de solucoes
existente (EasyMAP, Processyn, FactoryLink e InTouch), permitiu constatar estas
lacunas e estabelecer os objectivos a atingir pela arquitectura NavCim.
Antecedendo a descricao pormenorizada da arquitectura, foi feita uma abordagem
geral dos seus elementos mais importantes em cada nıvel estrutura hierarquica e na
perspectiva da integracao de sistemas, tendo sido ainda apresentada de uma forma
generica a sua organizacao modular. Seguiu-se a analise da arquitectura do ponto
de vista do fluxo de dados, onde foram salientadas as opcoes tomadas em termos
do tratamento dos dados de supervisao e dos dados de controlo e onde foi dado um
especial relevo ao tema da distributividade da informacao. Foi tambem assinalada a
importancia da nocao de eventos e estado, bem como da longevidade da informacao.
A descricao do modelo computacional permitiu identificar as interaccoes existentes
entre os diversos componentes modulares e definir as responsabilidades de cada um.
Para testar e validar as ideias propostas foi desenvolvida uma plataforma baseada
na arquitectura NavCim, cuja aplicacao numa situacao concreta foi realizada com
sucesso, permitindo assim concluir positivamente acerca da sua viabilidade de utiliza-
144
CAPITULO 5. CONCLUSOES E PERSPECTIVAS FUTURAS 145
cao. No entanto, alguns dos resultados de desempenho obtidos poderiam ter sido
mais animadores. Fica assim em aberto a necessidade de melhorar o desempenho da
plataforma ao nıvel da comunicacao com os dispositivos, que passa inevitavelmente
pela utilizacao de uma plataforma de comunicacao MMS mais eficiente do que a
actualmente utilizada. Note-se, no entanto, que o principal objectivo a que nos
propunhamos— a definicao de uma arquitectura inovadora, que permitisse a facil
integracao de sistemas, aplicacoes e dispositivos em ambientes industriais— foi
cumprido, sendo agora a optimizacao do desempenho uma questao de engenharia.
Em termos de evolucao do trabalho realizado, um dos primeiros passos a dar
consiste na concretizacao nao apenas dos mecanismos de arquivo actualmente em falta,
mas de mecanismos de arquivo distribuıdo. Perspectiva-se desta forma o fornecimento
ao nıvel da plataforma NavCim do suporte para a distribuicao dos dados historicos,
por exemplo utilizando o recente standard RDA, ja mencionado atras, evitando a
necessidade de utilizacao de produtos proprietarios e de elevado custo.
Naturalmente, a continuidade do trabalho desenvolvido passara por incorporar
novas funcionalidades ao nıvel das accoes de pre-processamento de dados e de gestao
de alarmes e, eventualmente, pela adicao de outro tipo de accoes, tais como a realiza-
cao de calculos aritmeticos ou o carregamento de receitas.
Tambem a melhoria das interfaces existentes se encontra incluıda nas perspectivas
de evolucao, sendo em particular desejavel encontrar novas e melhores solucoes para
o tratamento de eventos. Quanto a isto assinalamos a necessidade de investigar o
protocolo DDE, que constitui um standard actualmente muito divulgado e que, em
certos casos, podera ser favoravelmente utilizado para disseminacao de eventos em
substituicao do protocolo MMS.
A arquitectura podera ainda evoluir na vertente mais voltada a interaccao com o
utilizador, passando a constituir mais do que um suporte a construcao de sistemas
de controlo e supervisao, ela propria uma ferramenta para tal vocacionada. Esta
possibilidade de evolucao, por implicar a definicao de novas interfaces de utilizacao e
interfaces graficas, e tendo em conta a qualidade dos produtos existentes no mercado,
pode considerar-se bastante arrojada.
Bibliografia
[Bauer 91] A. Bauer, R. Bowden, J. Browne, J. Duggan, e G. Lyons. Shop FloorControl Systems. Chapman Hall, London, 1991.
[Beekmann 89] D. Beekmann. Cim-osa: computer integrated manufacturing -open system architecture. International Journal Computed Integra-ted Manufacturing, 1989.
[Birman 94] Kenneth Birman e Robbert van Renesse, editores. Reliable Distri-buted Computing With the ISIS Toolkit. Numero ISBN 0-8186-5342-6. IEEE CS Press, Marco 1994.
[Borghoff 92] Uwe M. Borghoff. Catalogue of Distributed File/Operating Systems.Springer-Verlag, 1992.
[CNMA 93] CNMA. CNMA Implementation Guide, Revision 6.01. Relatoriotecnico, ESPRIT Project 7096, Julho 1993.
[Consortium 93] CCE-CNMA Consortium. NIK Implementation Guide, Revision1.0. Relatorio tecnico, ESPRIT Project 7096, Outubro 1993.
[Coulouris 88] G. Coulouris e J. Dollimore. Distributed Systems, Concepts andDesign. Int’l Computer Science Series. Addison-Wesley, 1988.
[Cristian 90] Flaviu Cristian, Robert D. Dancey, e Jon Dehn. High Availabilityin the Advanced Automation System. Em Digest of Papers,The 20th International Symposium on Fault-Tolerant Computing,Newcastle-UK, Junho 1990. IEEE.
[Crowder 86] R. Crowder. Enhanced performance and MAP. MAP/TOPInterface, Novembro 1986.
[EM92] PROCOS A/S. EasyMAP, General Description, 1992.
[FL93] United States Data Corporation. USDATA FactoryLink IV SoftwareSystem. Technical Overview, Setembro 1993.
[Fonseca 90] H. Fonseca, L. Rodrigues, J. Rufino, e Paulo Verıssimo. Localsupport environment: User specification. Relatorio TecnicoRT/50-90, INESC, Lisboa, Portugal, Agosto 1990.
146
BIBLIOGRAFIA 147
[Gutschke 87] W. Gutschke e K. Mertins. CIM: Competitive Edge in manufac-turing, Robotics & Computer - Integrated Manufacturing. 3(1),1987.
[ISO90a] International Organization for Standardization. MMS Specifica-tion - Part 1: Service definition, 1990.
[ISO90b] International Organization for Standardization. MMS Specifica-tion - Part 2: Protocol specification, 1990.
[ISO93] ISODE Consortium Limited, London, England. ISODE Volume 1:Overview of ISODE, 1.0 edicao, Fevereiro 1993.
[IT93] Wonderware Software Development Corporation. InTouch Pro-duct Data Sheet, Marco 1993.
[Kernighan 88] Brian W. Kernighan e Dennis M. Ritchie. The C ProgrammingLanguage. Prentice Hall Software Series, second edition edicao,1988.
[Kleiman 86] S.R. Kleiman. Vnodes: An Architecture for Multiple File SystemTypes in Sun UNIX. Em Proc. of the Summer 1986 USENIXConference, paginas 238–247, Junho 1986.
[Kopetz 89] Hermann Kopetz, Andreas Damm, Christian Koza, Marco Mu-lazzani, Wolfgang Schwabl, Christoph Senft, e Ralph Zainlin-ger. Distributed Fault-Tolerant Real-Time Systems: The MarsApproach. IEEE Micro, paginas 25–41, Fevereiro 1989.
[Kopetz 93] Hermann Kopetz e Paulo Verıssimo. Real-time and Dependabi-lity Concepts. Em S.J. Mullender, editor, Distributed Systems, 2ndEdition, ACM-Press, paginas 411–446. Addison-Wesley, 1993.
[Lamport 86] Leslie Lamport. The mutual exclusion problem - statement andsolutions. Journal of the ACM, paginas 327–348, Abril 1986.
[MAP85] Manufacturing Automation Protocol Specification V2.1, Marco 1985.
[Mullender 93] S.J. Mullender, editor. Distributed Systems, 2nd Edition. ACM-Press. Addison-Wesley, 1993.
[Paxson 93] V. Paxson. flexdoc - documentation for flex, fast lexical analyzergenerator, Novembro 1993.
[Postel 85] J. Postel e Reynolds J. File transfer protocol (ftp). RelatorioTecnico RFC 959, Outubro 1985.
[Powell 91] David Powell e Paulo Verıssimo. Distributed fault-tolerance. EmD. Powell, editor, Delta-4 - A Generic Architecture for DependableDistributed Computing, ESPRIT Research Reports, paginas 89–124.Springer Verlag, Novembro 1991.
BIBLIOGRAFIA 148
[PRO91] Logique Industrie. Processyn, Generateurd’Applications d’Informatique Industrielle, Documentation Generale,1991.
[Rang 92] C. Rang e W. Schonewolf. Communication Platform Prototype— Information. Relatorio tecnico, IPK, Berlin, 1992.
[Rodrigues 92] L. Rodrigues e P. Verıssimo. xAMp: a Multi-primitive GroupCommunications Service. Em Proceedings of the 11th Symposium onReliable Distributed Systems, Houston, Texas, Outubro 1992. IEEE.
[Rodrigues 93a] L. Rodrigues e P. Verıssimo. Replicated object management usinggroup technology. Em Proceedings of the 4th Workshop on FutureTrends of Distributed Computing Systems, paginas 54–61, Lisboa,Portugal, Setembro 1993. Also as INESC AR/28-93.
[Rodrigues 93b] L. Rodrigues, P. Verıssimo, e A. Casimiro. Using atomic broad-cast to implement a posteriori agreement for clock synchroniza-tion. Em Proceedings of the 12th Symposium on Reliable DistributedSystems, paginas 115–124, Princeton, New Jersey, Outubro 1993.IEEE. Also as INESC AR/29-93.
[Rose 91] Marshall T. Rose, Julian P. Onions, e Colin J. Robbins. The ISODevelopment Environment: User’s Manual (Version 7.0), 6.24 edicao,Julho 1991.
[Rosen 86] Michael J. Wilde Rosen, Mordecai B. e B. Fraser-Campbell. NFSPortability. Em Proc. of the Summer 1986 USENIX Conference,paginas 299–305, Junho 1986.
[Sandberg 85] Russel Sandberg. The sun network filesystem: Design, imple-mentation and experience. Em Proceedings of the Summer 1985USENIX Conference, paginas 119–130, Mountain View, CA.94110- (415)960-7293, Junho 1985. USENIX.
[Satyanarayanan 85] M. Satyanarayanan, J. Howard, D. Nichols, R. Sidebotham,A. Spector, e M. West. The ITC distributed file system: Principlesand design. Em Proc. 10th ACM Symposium on Operating SystemsPrinciples, paginas 35–50, 1985.
[Satyanarayanan 90] M. Satyanarayanan. A survey of distributed file systems. Annu.Rev. Comput. Sci., ****(4):73–104, 1990.
[Schneider 93] Fred. B. Schneider. Replication management using the state-machine approach. Em S.J. Mullender, editor, Distributed Systems,2nd Edition, ACM-Press, capıtulo 7. Addison-Wesley, 1993.
[SM87] Inc. Sun Microsystems. XDR: Eternal Data Representation Stan-dard. Relatorio Tecnico RFC 1014, Mountain View, CA., Junho1987.
[SM89] Inc. Sun Microsystems. NFS: Network File System ProtocolSpecification. Relatorio Tecnico RFC 1094, Mountain View, CA.,Marco 1989.
[Srikanth 87] T. K. Srikanth e Sam Toueg. Optimal Clock Synchronization.Journal of the Association for Computing Machinery, 34(3):627–645,Julho 1987.
[SUN90] Sun, Microsystems, Mountain View, CA. Programming Utilities &Libraries, Marco 1990.
[Thacker 87] B. Thacker. Top 3.0 update. MAP/TOP Interface, 1987.
[Verıssimo 91] Paulo Verıssimo, L. Rodrigues, e J. Rufino. The Atomic Multicastprotocol (AMp). Em D. Powell, editor, Delta-4 - A Generic Ar-chitecture for Dependable Distributed Computing, ESPRIT ResearchReports, paginas 267–294. Springer Verlag, Novembro 1991.
[Verıssimo 93] Paulo Verıssimo. Real-time Communication. Em S.J. Mullender,editor, Distributed Systems, 2nd Edition, ACM-Press, paginas 447–490. Addison-Wesley, 1993.
[Verıssimo 95a] P. Verıssimo. Causal Delivery Protocols in Real-time Systems: aGeneric Model. Journal of Real-Time Systems, to appear 1995.
[Verıssimo 95b] P. Verıssimo, L. Rodrigues, e A. Casimiro. Cesiumspray: aprecise and accurate global clock service for large-scale systems.Relatorio tecnico, INESC, Lisboa, Portugal, Marco 1995.
149