navcim uma arquitectura distribu´ıda de suporte ao ...casim/papers/msc/msc.pdf · navcim uma...

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.


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.


��

��

��

��

��

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,


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.


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.


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


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


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.


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


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


Bases de dados:• dBASE IV

Aplicações:• Formatos Standard


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.


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.


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


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.


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


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.


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-


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


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.


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


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.


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


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


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


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.


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-


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


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-


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.


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


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.


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


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


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


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.


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.


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


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


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


�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


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.


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


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,


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


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


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.


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


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.


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.


('�� :

('��

('�� .��

��

��

��

��

��

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


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.


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.


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;


� 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


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


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-


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.


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.


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.


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.


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.


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.


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.


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.


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


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


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


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,


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


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


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


5)��8 5)��5)��9 =�=�=�=�=

�� =�=�=�=�=

��/�� "%�%��"��%

(��

(��

*��+�� *��+��)�,�

-� ��>�� '��

-� ��>��:

�&"'�&��%(��%

�"��%��!�%%"��%

��

$��0#�

Figura 3.7: Fluxo de informacao. Dados de supervisao e de controlo.


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.


(��: �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


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.


(��: �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


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


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:


� 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.


��: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


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


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.


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,


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.


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-


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


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.


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.


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.


� 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.


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.


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


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


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.


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


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


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


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.


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,


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;


� 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


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.


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.


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.


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.


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.


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.


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.


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.


��&��%�'

('�� ;

('�� 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.


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.


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.


� 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


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.


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�


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.


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.


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.


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.


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;


� 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.


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


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


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


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


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


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.


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


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.


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.


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.


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.


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


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.


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


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

navcim uma arquitectura distribu´ıda de suporte ao ...casim/papers/msc/msc.pdf · navcim uma...

Documents