Dissertacao Marcos Roberto Alves Martins

MARCOS ROBERTO ALVES MARTINS
INTEGRAO SISTMICA EM MIDDLEWARE
So Paulo
2010
MARCOS ROBERTO ALVES MARTINS
INTEGRAO SISTMICA EM MIDDLEWARE
Dissertao
apresentada
Escola
Politcnica da Universidade de So
Paulo para obteno do ttulo de
Mestre em Engenharia Eltrica.
rea de concentrao:
Engenharia Eltrica e de Sistemas Digitais
Orientador:
Prof. Dr. Jos Sidnei Colombo Martini
So Paulo
2010
Este exemplar foi revisado e alterado em relao verso

original, sob-responsabilidade nica do autor com a anuncia
de seu orientador.
So Paulo, 29 de julho de 2010.
Assinatura do autor _____________________________________
Assinatura do orientador ________________________________
FICHA CATALOGRFICA
Martins, Marcos Roberto Alves

Integrao sistmica em middleware / M.R.A. Martins. -ed. rev. -- So Paulo, 2010.
233 p.
Dissertao (Mestrado) - Escola Politcnica da Universidade
de So Paulo. Departamento de Engenharia de Computao e
Sistemas Digitais.
1. Middleware (Desenvolvimento; Anlise) I. Universidade de
So Paulo. Escola Politcnica. Departamento de Engenharia de
Computao e Sistemas Digitais II. t.
DEDICATRIA
Para Marcos Filho, que a criatividade e a dedicao

faam parte de todos os seus dias.
AGRADECIMENTOS
Ao Prof. Dr. Jos Sidnei Colombo Martini, pela motivao, dedicao, inspirao,
que foram fundamentais na elaborao deste trabalho, mostrando sempre o
caminho a ser seguido, mesmo quando a estrada se mostrava difcil.
A todos os Professores que contriburam com conhecimento e dedicao.
A todos os colegas com os quais tive o privilgio de conviver durante o perodo de

estudos.
minha famlia pela motivao e compreenso e pelas horas de ausncia.
Ao meu pai Osvaldo (in memorian) pelo exemplo de vida e perseverana.
minha esposa Antonia pela dedicao e companheirismo.
Ao meu filho Marcos pelo incentivo.
minha irm Djanira pela motivao e orientao.
A DEUS sobretudo, pelo grande milagre da Vida.
No basta ensinar ao homem uma

especialidade, porque se tornar assim uma
mquina utilizvel, mas no uma
personalidade. necessrio que adquira um
sentimento, um senso prtico daquilo que vale
a pena ser empreendido, daquilo que belo, do
que moralmente correto. A no ser assim, ele
se assemelhar, com seus conhecimentos
profissionais mais a um co ensinado do que a
uma criatura harmoniosamente desenvolvida.
Deve aprender a compreender as motivaes
dos homens, suas quimeras e suas angstias,
para determinar com exatido seu lugar preciso
em relao a seus prximos e comunidade.
Albert Einstein (1879 1955)
Fsico alemo
RESUMO
O presente trabalho estuda de forma analtica as diversas arquiteturas de redes

utilizadas em ambientes industriais e administrativos, bem como os aspectos de
convergncia que levaram ao surgimento de plataformas de integrao que
definiram solues de gesto corporativas.
Sob uma abordagem evolutiva sero analisados os conceitos e aplicabilidades dos
padres de comunicao de dados e de informao que definiram arquiteturas de
sistemas distribudos.
Sero abordados os aspectos de relevncia em tecnologia da informao utilizados
na gesto corporativa e industrial que possibilitaram o entendimento de solues de
integrao baseadas em tecnologias de middleware.
Palavras-chave: Middleware, Redes, Integrao.
ABSTRACT
This paper studies analytically the various network architectures used in industrial
environments and administrative, as well as areas of convergence that led to the
emergence of integration platforms that have defined corporate management
solutions.
Under an evolutionary approach will consider the applicability of the concepts and
communication patterns of data and information that defined architectures of
distributed systems.
The aspects of relevance in information technology used in corporate management
and industrial enabled the understanding of integration solutions based on
middleware technologies.
Keywords: Middleware, Network Integration.
LISTA DE ILUSTRAES
Figura 01:
Modelo OSI
28
Figura 02:
Splitting camada (N)
32
Figura 03:
Pass-through dos servios de sesso
35
Relao entre processos, entidades e elementos de servio

Figura 04:
36
de aplicao.
Figura 05:
Transmisso de dados no Modelo OSI
37
Figura 06:
Sistema distribudo organizado como Middleware
41
Figura 07:
Sistemas com mltiplos processadores
44
Figura 08:
Sistemas distribudos
47
Figura 09:
Arquitetura em camadas computao em grade
48
Figura 10:
Camadas de software e hardware em sistemas distribudos
53
Figura 11:
Arquitetura de sistema operacional de ncleo monoltico
56
Figura 12:
Sistema cliente/servidor.
57
Aplicao de banco de dados por arquivo compartilhado e

Figura 13:
58
cliente/servidor
Relao entre Modelo de Referncia OSI e Sistema
Figura 14:
60
Operacional de Rede (SOR).
Figura 15:
As ondas da arquitetura cliente/servidor
60
Figura 16:
Arquitetura Peer-to-Peer
62
Figura 17:
Estrutura de banco de dados hierrquico
66
Figura 18:
Sistema corporativo e seus subsistemas
71
Figura 19:
Tecnologia da informao e sistemas de informao
73
Figura 20:
Comunicao entre cliente e servidor com Novell
74
Figura 21:
Modelo Novell x Modelo OSI
75
Figura 22:
Encapsulamentos existentes para IPX
76
Figura 23:
Sliding Window - controle de fluxo em protocolo
76
Figura 24:
Interface Shell da rede Novell
77
Figura 25:
Modelo de Referncia OSI e arquitetura SNA
79
Figura 26:
Modelo Rede SNA
80
Figura 27:
Projeto original da Ethernet
84
Correspondncia entre protocolos modelo OSI e protocolos

Figura 28:
86
LAN
Figura 29:
Formato Frame Ethernet DIX V1.0 e IEEE 802.3
87
Figura 30:
Variantes do Frame Ethernet
88
Figura 31:
Estrutura dos padres IEEE 802.x
89
Figura 32:
IEEE 802.3z e IEEE 802.3ab
93
Figura 33:
Frames IEEE 802.3 e 802.3q
95
Figura 34:
Camadas da arquitetura TCP/IP
98
Figura 35:
Camadas do Modelo OSI e TCP/IP
99
Figura 36:
Camada de Rede - Servios
100
Figura 37:
Servios executados na camada de transporte
101
Figura 38:
Estrutura do segmento TCP
102
Figura 39:
Estrutura do segmento UDP
103
Figura 40:
Formato de datagrama Internet TCP/IP
104
Figura 41:
Formatos cabealhos IPv4 e IPv6
106
Figura 42:
Classificao geral dos sistemas de automao
107
Figura 43:
Linguagens de programao IEC 61131-3
112
Figura 44:
Estrutura da Pirmide de Automao
114
Figura 45:
Base de Dados Comum
115
Figura 46:
Camadas Fieldbus Foundation e Modelo de Referncia OSI
120
Figura 47:
Arquiteturas das Redes Fieldbus
124
Figura 48:
Comparao entre o Modelo OSI e o padro Fieldbus
124
Figura 49:
Comparao entre Modelo OSI e padro Fieldbus H1.
126
Figura 50:
Arquitetura do protocolo Profibus.
128
Figura 51:
Acesso ao meio do protocolo Profibus
130
Configurao tpica de sistema Profibus em automao de

Figura 52:
134
processo.
Figura 53:
Estrutura de dispositivo Profinet
136
Figura 54:
Integrao Profibus com Ethernet e TCP/IP
137
Figura 55:
Transaes entre dispositivos Modbus
139
Figura 56:
Modbus TCP/IP
140
Figura 57:
Formato padro do Comando HART
141
Figura 58:
Camadas do padro HART.
142
Figura 59:
Formato do frame FIP
144
Figura 60:
Arquitetura EtherNet/IP
145
Figura 61:
Encapsulamento de mensagens EtherNet/IP
146
Figura 62:
Estrutura do protocolo CAN
147
Figura 63:
Camadas do padro DeviceNet.
148
Figura 64:
Aplicao de redes industriais
150
Figura 65:
Aplicao de Sistema Supervisrio
151
Figura 66:
Gerao de sistemas SCADA monolticos
152
Figura 67:
Gerao de sistemas SCADA distribudos
153
Figura 68:
Gerao de sistemas SCADA Networked
153
Figura 69:
Tela grfica SCADA
155
Figura 70:
Integrao de sistema SCADA
157
Figura 71:
Interface grfica SCADA++
160
Arquitetura de sistema de gerenciamento tipicamente

Figura 72:
163
distribudo
Figura 73a:
Conexes no hierrquicas (peer-to-peer) entre gerentes
164
Figura 73b:
Conexes hierrquicas entre gerentes
164
Figura 74:
Modelo de gerenciamento OSI
167
Figura 75:
Aplicao do protocolo SNMP
169
Figura 76:
Troca de informaes SNMP
171
Figura 77:
Formato de mensagens SNMP
173
Figura 78:
Relacionamento entre verses do SNMP
176
Figura 79:
Subrvore MIB II
179
Figura 80:
Resumo comparativo MIBs
180
Figura 81:
Elementos componentes de processo de gesto
182
Distribuio dos Sistemas de Informao nos nveis

Figura 82:
184
hierrquicos
Figura 83:
Estrutura tpica de sistema ERP
186
Figura 84:
Distribuio de fornecedores de sistemas ERP
187
Figura 85:
Fases de planejamento de sistemas ERP
188
Nveis propostos para normatizao das empresas industriais

Figura 86:
190
MES
Figura 87:
Pirmide de automao sem integrao
191
Figura 88:
Aplicao tpica de objetos distribudos
193
Figura 89:
Invocao mtodos locais e remotos
197
Figura 90:
Middleware para comunicao em sistema distribudo
200
Figura 91:
Localizao de Middleware no Modelo OSI
200
Figura 92:
Middleware arquitetura TCP/IP
201
Figura 93:
Comunicao entre processos
202
Figura 94:
Modelo proposto de gesto produtiva.
206
Figura 95:
Arquitetura proposta
207
Figura 96:
ERP com incluso de camada MES e SNMP4J
208
Figura 97:
Camada Middleware
209
Figura 98:
Estrutura da mensagem requisio/resposta
209
Figura 99:
Comunicao entre entidades RMI
210
Figura 100a:
Invocao remota
211
Figura 100b:
Interao entre componentes - Invocao remota
211
Figura 101:
Construo de aplicao RMI
212
Figura 102:
Arquitetura de infraestrutura de integrao
214
LISTA DE TABELAS
Tabela 01:
Computadores com IP registrados na Internet
42
Tabela 02:
Caractersticas de sistemas NUMA
45
Tabela 03:
Comparao de arquiteturas de redes SNA e TCP/IP
82
Tabela 04:
Grupos de trabalhos normatizao padro IEEE 802
85
Tabela 05:
Novas especificaes IEEE 802
90
Tabela 06:
Meio de transmisso IEEE 802.3 Ethernet 10 Mbps
90
Tabela 07:
Meio de transmisso IEEE 802.3u Ethernet 100 Mbps.
91
Tabela 08:
Comparao entre IEEE 802.3u e IEEE 802.12
92
Tabela 09:
Resumo comparativo Ethernet
94
Tabela 10:
Meio fsico para Ethernet Gigabit
94
Tabela 11:
Modelos de comunicao industrial
117
Tabela 12:
Velocidades de transmisso Profibus DP
129
Tabela 13:
Resumo de funes padro Profibus DP
132
Tabela 14:
Formato mensagem ASCII
139
Tabela 15:
Formato mensagem RTU
139
Tabela 16:
Caractersticas de Supervisrios SCADA++
160
Tabela 17:
RFCs relacionadas com SNMPv1
171
Tabela 18:
174
Tabela 19:
RFCs relacionadas com SNMPv2c
175
Tabela 20:
175
Tabela 21:
Mtodos utilizados da interface Context
213
LISTA DE SIGLAS
ALI
Application Layer Interface
AES
Advanced Encryption Standard
API
Application Program Interface
ASCII
American Code For Information Interchange
ASCE
Association Control Service Element
ASN
Abstract Syntax Notation
BD
Banco de dados
CCITT
Comit Consultatif International Tlgraphique et Tlphonique
CMIP
Common Management Information Protocol
CSMA/CD
Carrier Sense Multiple Access/Collision Detection
CLP
Controlador Lgico Programvel
CNC
Controle Numrico por Computador
CRC
Cyclic Redundancy Checy
DARPA
Defense Advanced Research Projects Agency
DNS
Domain Name System
DES
Data Encryptation Standard
DDM
Distributed Database Maintenance
DIS
Data Independent Sublayer
DME
Distributed Management Environment
DLL
Data Link Layer
EIA
Electronic Industries Association
ER
Elemento de Rede
ERP
Enterprise Resource Planning
EPROM
Erasable Programmable Read Only Memory
FAS
Fieldbus Access Layer
FIP
Factory Instrumentation Protocol
FMS
Fieldbus Message Specification
FTP
File Transfer Protocol
FISCO
Fieldbus Intrinsically Safe Concept
HTTP
Hypertext Transfer Protocol
HDLC
High Level Data Link Control
HSE
High Speed Ethernet
ISP
Interoperable Systems Project
ICMP
Internet Control Message Protocol
IEC
International Electrotechnical Commission
IEEE
Institute Of Electrical And Electronics Engineers
IHM
Interface Homem Mquina
IP
Internet Protocol
ISA
International Society For Measurement And Control
ISO
International Organization For Standardization
I/O
Input / Output
IMSE
Industrial Message Service Element
LAN
Local Area Networks
LAS
Link Active Scheduler
LE
Layer Entity
LLA
Logical Layered Architecture
LLC
Logical Link Control
LLI
Lower Layer Interface
MAC
Medium Access Control
MAU
Medium Attachment Unit
MCSE
Message Common Service Element
MDS
Medium Dependent Sublayer
MIB
Management Information Base
MMS
Manufacturing Message Specification
MPS
Message Periodic / Aperiodic Services
MRP
Material Resource Planning
NMS
Network Management Stations
OID
Object Identifier
OSF
Open Software Foundation
OSI
Open Systems Interconnection
OPC - OLE
Object Linking And Embedding Process Control
PC
Personal Computer
PDU
Protocol Data Unit
PI
Profibus International
ROSE
Remote Operations Service Element
RMON
Remote Monitoring
RFC
Request For Comment
RTU
Remote Terminal Unit
SCADA
Supervisory Control And Data Acquisition
SDCD
Sistema Digital De Controle Distribudo
SGMP
Simple Gateway Management Protocol
SQL
Structure Query Language
SHA
Secure Hash Algorithm
SOR
Sistemas operacionais de rede
SMI
Structure Of Management Information
SNAP
Subnetwork Access Protocol
SNMP
Simple Network Management Protocol
SMTP
Simple Mail Transfer Protocol
SNAP
Subnetwork Access Protocol
TCP
Transmission Control Protocol
TDMA
Time Division Multiple Access
UCP
Unidade Central De Processamento
UDP
User Datagram Protocol
VCR
Virtual Communication Relationship
VFD
Virtual Field Device
19
SUMRIO
1.
INTRODUO .......................................................................................................... 21
1.1 MOTIVAO ............................................................................................................. 22
1.2 OBJETIVO ................................................................................................................ 22
1.3 METODOLOGIA ......................................................................................................... 23
1.4 ORGANIZAO DA DISSERTAO ............................................................................... 23
2.
MODELO OSI ........................................................................................................... 26

2.1 PROTOCOLOS DE INTERCONEXO .............................................................................. 27
2.2 CAMADA FSICA ........................................................................................................ 29
2.3 CAMADA DE ENLACE ................................................................................................. 29
2.4 CAMADA DE REDE .................................................................................................... 30
2.5 CAMADA DE TRANSPORTE ......................................................................................... 31
2.6 CAMADA DE SESSO ................................................................................................ 33
2.7 CAMADA DE APRESENTAO ..................................................................................... 34
2.8 CAMADA DE APLICAO ............................................................................................ 35
3.
SISTEMAS DISTRIBUDOS ..................................................................................... 39

3.1 MODELOS DE ARQUITETURAS DE SISTEMAS DISTRIBUDOS .......................................... 52
3.2 ARQUITETURAS CENTRALIZADAS ............................................................................... 55
3.3 ARQUITETURAS DESCENTRALIZADAS ......................................................................... 61
3.4 BANCO DE DADOS..................................................................................................... 64
4.
TECNOLOGIA DA INFORMAO ........................................................................... 70

4.1 NOVELL ................................................................................................................... 74
4.2 SNA ....................................................................................................................... 78
4.3 ETHERNET ............................................................................................................... 83
4.4 TCP/IP ................................................................................................................... 96
5.
AUTOMAO INDUSTRIAL .................................................................................. 107

5.1 EVOLUO DO CONTROLE INDUSTRIAL..................................................................... 107
5.2 ARQUITETURA DE AUTOMAO INDUSTRIAL .............................................................. 111
5.3 MODELO PARA TROCA DE INFORMAES ................................................................. 116
6.
REDES DE CAMPO INDUSTRIAIS ........................................................................ 119
20
6.1 CAMADA FSICA ...................................................................................................... 121

6.2 CAMADA LINK DE DADOS (ENLACE) ......................................................................... 121
6.3 CAMADA DE APLICAO .......................................................................................... 122
6.4 CAMADA DE APRESENTAO (USURIO) .................................................................. 122
7.
ARQUITETURAS DE REDES INDUSTRIAIS ......................................................... 123

7.1 FIELDBUS .............................................................................................................. 123
7.2 PROFIBUS .............................................................................................................. 128
7.3 MODBUS ................................................................................................................ 138
7.4 HART ................................................................................................................... 141
7.5 WORLDFIP............................................................................................................. 142
7.6 ETHERNET/IP (ETHERNET INDUSTRIAL PROTOCOL) .................................................. 145
7.7 CAN ..................................................................................................................... 146
7.8 LONW ORKS .......................................................................................................... 148
7.9 BACNET ............................................................................................................... 149
8.
SISTEMAS DE AQUISIO DE DADOS ............................................................... 151

8.1 COMPONENTES DE SISTEMAS SUPERVISRIOS SCADA ............................................ 156
8.2 MODOS DE COMUNICAO SCADA ......................................................................... 158
8.3 SISTEMA SUPERVISRIO SCADA ORIENTADO OBJETO .......................................... 159
9.
GERENCIAMENTO DE REDES ............................................................................. 161

9.1 PROTOCOLO DE GERENCIAMENTO SNMP ................................................................ 168
9.2 MIB (MANAGEMENT INFORMATION BASE)................................................................. 177
10. MODELO DE GESTO CORPORATIVA ............................................................... 182

10.1 ERP (ENTERPRISE RESOURCE PLANNING) .............................................................. 185
10.2 MES (MANUFACTURING EXECUTION SYSTEM).......................................................... 189
11. INTEGRAO EM APLICAES DISTRIBUDAS ............................................... 193
11.1 TECNOLOGIAS EM APLICAES DISTRIBUDAS ........................................................... 197
11.2 MIDDLEWARE ......................................................................................................... 199
12. ARQUITETURA PROPOSTA ................................................................................. 206
13. CONCLUSO E CONSIDERAES FINAIS......................................................... 215
14. REFERNCIAS ....................................................................................................... 218
21
1. INTRODUO
O estudo da evoluo de qualquer rea da tecnologia proporciona uma melhor
compreenso das principais realizaes nestes segmentos, fornecendo subsdios
para a compreenso de tais desenvolvimentos e suas tendncias.
O aprimoramento da tecnologia possui uma relao intrnseca com o
desenvolvimento corporativo. No campo das comunicaes, desde a inveno do
telefone aos atuais sistemas de processamento de dados, as tecnologias
possibilitaram o surgimento de mtodos de gesto corporativos cada vez mais
abrangentes e eficientes.
As redes de computadores surgiram h relativamente pouco tempo, no final da
dcada de 1960, elas herdaram diversas propriedades teis de suas predecessoras,
as mais antigas e amplamente adotadas redes telefnicas. Isto no deve causar
surpresa, uma vez que tanto computadores quanto telefones so instrumentos de
comunicao.
Os
processos
industriais
tiveram
desenvolvimento
anlogo
ao
das
comunicaes, e ambos possuem em comum a busca pela eficincia na gesto de

seus processos. Os atuais sistemas de automao industrial baseados em sinais
digitais tiveram como precursores os sistemas pneumticos, e da mesma forma
herdaram propriedades tambm muito teis.
Contudo, atualmente existe um novo contexto, a presena dos sistemas de
tecnologia da informao, que foram alavancados com o surgimento da Internet nos
anos de 1990, que criou um cenrio de integrao e de convergncia.
A
influncia
das
redes
de
computadores
sobre
outros
tipos
de
telecomunicaes resultou em uma convergncia de redes que atualmente definiu o

VoIP; sistemas de TV convergiram com os sinais digitais definindo a TV digital, entre
muitos outros exemplos.
A Internet contribuiu de forma determinante para o surgimento de novas formas
de relacionamento, entre pessoas e principalmente entre empresas, com o
surgimento de servios como e-Commerce, e-Banking, que propiciaram um
ambiente de aplicaes distribudas como os WebServices.
22
O elemento comum de todo este enorme processo de convergncia tem sido a

tecnologia da informao, que no ambiente corporativo, possui como uma das
principais metas a interoperabilidade.
O surgimento e aprimoramento de linguagens de programao de alto nvel
possibilitam que a interopebilidade possa ser atingida com a utilizao de nveis de
abstrao definidos como middleware entre as diversas aplicaes legadas, as
existentes e as novas tecnologias que certamente surgiro.
1.1 Motivao
A principal motivao para o desenvolvimento deste trabalho deve-se a falta de
a interoperabilidade entre os sistemas destinados ao segmento de processos
produtivos, inclusive em sistemas produtivos que herdaram plataformas legadas de
automao.
Alm dos problemas tcnicos provenientes entre estas plataformas, onde a
troca de informaes ocorre mediante o desenvolvimento de solues dedicadas,
que comumente so onerosas e possuem aplicabilidade especfica e que so
desenvolvidas em sua grande maioria ao nvel de hardware, inviabilizando a
convergncia das informaes geradas com outros sistemas no ambiente
corporativo.
A busca pela eficincia e padronizao de Modelos de Gesto Empresariais
inseriu o contexto de integrao das informaes como elemento fundamental na
estratgia das corporaes.
A aproximao entre processos nos ambiente da tecnologia de automao (TA)
e da tecnologia da informao (TI), antes separados por barreiras culturais e
tecnolgicas, encontra na integrao uma forma de dispor as informaes aos nveis
decisrios das empresas de forma gil e consistente.
1.2 Objetivo
A presente dissertao tem por objetivo elaborar uma proposta de integrao
em ambientes heterogneos, por meio da especificao de uma arquitetura aberta
23
baseada em middleware que possa prover o gerenciamento da informao no

ambiente industrial integrado gesto corporativa.
1.3 Metodologia
Para atingir o objetivo proposto para a elaborao deste trabalho, ser adotada
a seguinte metodologia:
Pesquisa dos modelos e de padronizao das arquiteturas de redes de

computadores;
Anlise dos modelos e arquiteturas de sistemas distribudos, e suas

respectivas aplicaes;
Anlise das tecnologias de informao que foram mais utilizadas no

ambiente corporativo, e formas de integrao dos protocolos que
constituem tais solues;
Anlise do contexto da automao industrial, arquiteturas e sistemas mais

utilizados nas diversas camadas do processo produtivo;
Avaliao dos sistemas de aquisio de dados utilizados na coleta de dados

no ambiente industrial;
Anlise de arquiteturas destinadas ao gerenciamento de redes de

computadores e suas plataformas;
Anlise dos modelos de Gesto Corporativas embasadas em tecnologias da

informao e solues disponveis para integrao de dados;
Pesquisa das tecnologias utilizadas para integrao em aplicaes

distribudas, com aplicao de camadas de abstrao entre processos;
Elaborao de uma proposta de arquitetura baseada em camadas de

middleware integrando processo produtivo a gesto corporativa.
1.4 Organizao da dissertao

Alm desta introduo, a dissertao compreende os seguintes captulos:
24
CAPTULO 2: Modelo OSI, descreve as principais caractersticas da

padronizao das redes de computadores.
CAPTULO 3: Sistemas Distribudos apresenta as principais caractersticas que
definiram as arquiteturas de sistemas distribudos, aspectos evolutivos relacionados
s aplicaes distribudas e suas respectivas tecnologias.
CAPTULO 4: Tecnologia da Informao descreve as principais arquiteturas de
redes de computadores destinadas ao ambiente corporativo, aspectos conceituais e
evolutivos, arquiteturas e formas de integrao entre protocolos.
CAPTULO 5: Automao Industrial analisa os principais aspectos relacionados
automao de processos.
CAPTULO 6: Redes de Campo Industriais; aborda os principais aspectos e
caractersticas das redes de automao industrial, definio de servios e camadas.
CAPTULO 7: Arquiteturas de Redes Industriais detalha as principais
arquiteturas destinadas automao de processos industriais, focando aspectos
estruturais dos protocolos utilizados e suas respectivas arquiteturas de rede
industrial, bem como a aplicabilidade de cada grupo de padro de protocolo dentro
da cadeia de processo produtivo.
CAPTULO 8: Sistemas de Aquisio de Dados analisa as caractersticas
construtivas relacionadas a sistemas de aquisio de dados em ambientes de
automao industrial.
CAPTULO 9: Gerenciamento de Redes descreve as principais arquiteturas de
gerenciamento de redes, utilizadas em arquiteturas padronizadas como OSI e
TCP/IP.
CAPTULO 10: Modelo de Gesto Corporativa descreve os conceitos de gesto
corporativos e sua integrao com a tecnologia da informao por plataformas ERP.
CAPTULO 11: Integrao em Aplicaes Distribudas descreve os aspectos
relacionados s tecnologias utilizadas em aplicaes distribudas e suas respectivas
aplicabilidades e propriedades.
CAPTULO 12: Arquitetura Proposta, prope um modelo de integrao entre
processos baseado em middleware.
25
CAPTULO 13: Concluso e Consideraes Finais, onde so apresentadas as

consideraes finais derivadas do desenvolvimento da dissertao e propostas de
trabalhos futuros.
26
2. MODELO OSI
A comunicao entre os equipamentos implementados em uma rede ocorre por
meio de modelos de arquiteturas de redes e de protocolos que viabilizem a
comunicao entre estes equipamentos e dispositivos.
Vrios modelos de arquiteturas foram propostos nas ltimas dcadas, porm o
desenvolvimento de redes por meio de protocolos de comunicao tem-se mostrado
o mtodo mais eficiente devido s possibilidades de expanso e implementaes. As
redes proprietrias deixaram de ser solues para as comunicaes medida que o
nmero, o conjunto de servios e os protocolos de cada camada apresentam
variaes de uma arquitetura para outra; e para que haja a interligao de redes
heterogneas proprietrias fizeram-se necessrio a utilizao de drivers de
comunicao, que realizam uma coleo de rotinas do sistema operacional que
efetivamente unem as pilhas de protocolos ao hardware da rede. Ele normalmente
inclui rotinas para inicializar o dispositivo, transmitir quadros no enlace e interrupes
de campo. O cdigo utilizado no driver comumente difcil de ler, pois repleto de
detalhes especficos do dispositivo, mas a lgica geral relativamente simples.
Este fato foi determinante para a elaborao de modelos que iniciassem a
padronizao das redes; com a definio do modelo OSI (Open Systems
Interconection) proposto pela ISO (International Organization for Standardization)
entre 1978 e 1984, conforme expe [CARVALHO-94], que foi desenvolvido com o
objetivo de padronizar a comunicao entre os equipamentos de uma rede por meio
de protocolos de rede; a proposta do Modelo de Referncia ISO OSI (Open System
Interconnection) foi oferecer modelo de interconexo para sistemas abertos.
O Modelo de Referncia para Interconexo de Sistemas Abertos e os diversos
padres correlacionados foram desenvolvidos por grupos de trabalho do
Telecommunications and Information Exchange Between Systems e do Information
Retrieval, Transfer and Management for OSI, ambos pertencentes ao Information
Processing Systems, conforme expe [SOARES-99].
A ISO foi uma das organizaes que formalmente definiram um modo comum
de conectar computadores em rede. A arquitetura estruturada pela organizao ISO,
definida como Open System Interconnection (OSI), define uma estrutura em sete
27
camadas, de forma aberta, onde protocolos implementam as funcionalidades de

cada camada, viabilizando o trfego da informao, desde o nvel fsico at os nveis
de aplicao.
Conforme expe [CARVALHO-94], o funcionamento em camadas do Modelo
de Referncia OSI esta baseado no princpio de usurio e prestador de servios,
sendo que cada servio representa um conjunto de funes, onde cada uma das
camadas prestadora de servio camada superior.
Cabe salientar que o Modelo de Referncia OSI aplicado de forma isolada no
define a arquitetura de uma rede, ele aponta o que cada camada deve executar.
Conforme define [SOARES-99], o fato de dois sistemas distintos atenderem o
Modelo de Referencia OSI no garante que eles possam trocar informaes entre si,
pois o modelo permite que sejam usadas diferentes opes de servios/protocolos
para as vrias camadas.
2.1 Protocolos de Interconexo

O modelo OSI foi estruturado em pilhas, composto por sete camadas, onde
cada camada deve ser vista como um programa, implementado por hardware ou
software, que se comunica com o nvel correspondente no outro equipamento. Os
dados no so transferidos diretamente de forma horizontal entre os equipamentos,
mas verticalmente pelos nveis, partindo do equipamento transmissor seguindo
atravs do meio fsico at o nvel correspondente no equipamento receptor at o seu
destino. Desta forma a comunicao percorre as sete camadas do modelo, sendo
que cada camada executa uma funo limitada e definida, dentro da arquitetura.
Os limites entre cada camada so chamados de interfaces, e estas interfaces
so especficas para cada camada. Cada camada oferece servios para a prxima
camada, durante o transporte das informaes, que so realizados por protocolos.
Apesar de o modelo OSI possuir sete camadas, um sistema de comunicao
no precisa necessariamente implementar as sete camadas. A figura 01 a seguir
ilustra a interao entre as camadas do modelo OSI.
28
Figura 01: Modelo OSI

Fonte: [PETERSON-04]
O modelo OSI composto pelas seguintes camadas, segundo expe

[TANENBAUM-03], sendo:
Camada fsica;
Camada de enlace de dados;
Camada de rede;
Camada de transporte;
Camada de sesso;
Camada de apresentao;
Camada de aplicao.
Entre cada nvel adjacente (entre camadas) so definidas interfaces, que

realizam a transmisso de dados verticalmente. O servio fornecido por uma
camada outra especificado pelo conjunto de primitivas de servios, trocadas
29
entre si e pela ordem segundo a qual as primitivas so trocadas, conforme define

[SOARES-99].
Segundo [OLIFER-08], h distino entre o Modelo de Referncia OSI e a pilha
de protocolos OSI, onde o Modelo de Referncia constitui um mtodo conceitual
entre sistemas abertos e a pilha OSI trata-se de um conjunto de especificaes para
protocolos determinados.
2.2 Camada Fsica

A camada fsica define as caractersticas eltricas, mecnicas, funcionais e
procedurais para manter e ativar conexes fsicas, onde uma das principais funes
da camada fsica permitir a ativao e desativao de conexes fsicas. Os
protocolos nesta camada se dedicam ao tipo de conexo e topologia fsica. Sua
funo possibilitar o envio de uma cadeia de bits pela rede, no tratando o
significado destes bits nem a forma como sero agrupados. Neste nvel definido se
a transmisso ser half-duplex ou full-duplex. Esta camada compreende as
especificaes do hardware utilizado na rede.
A camada fsica exerce a funo de sequenciao, onde os bits so
transmitidos e encaminhados ao nvel da camada de enlace na mesma ordem em
que so recebidos. No nvel da camada fsica tambm realizado o gerenciamento
das conexes fsicas, assegurando a qualidade de servio, porm neste nvel no
so tratados problemas relacionados com erros de transmisso.
2.3 Camada de Enlace

Conforme expe [TANENBAUM-03], a principal tarefa da camada de enlace
transformar um canal de transmisso bruto em uma linha que parea livre de erros
de transmisso no detectados para a camada superior (camada de rede). Neste
nvel, a camada de enlace organiza os bits transmitidos pelo meio fsico,
organizando-os na forma de quadros (frames). Este nvel detecta erros durante o
processo de transmisso, utiliza tcnicas de redundncia, controla o fluxo de
transmisso impedindo desta forma que o transmissor envie mais dados que o
receptor possa processar e identificar os dispositivos da rede; os protocolos desta
30
camada possuem como funcionalidade principal fazer com que os dados

transmitidos alcancem o destino com integridade.
Conforme expe [CARVALHO-94], as principais funes da camada de enlace
so:
Estabelecimento/liberao da conexo de enlace;
Mapeamento um-para-um entre as unidades de dados;
Splitting da conexo de enlace;
Montagem e delimitao de quadros;
Controle de seqncia;
Controle de fluxo;
Controle de erro;
Controle de interconexo de dados;
Gerenciamento da qualidade de servios prestados.
O controle ao acesso do canal compartilhado, conforme define [TANENBAUM03] pode ser obtido por meio de uma subcamada especial da camada de enlace de
dados: a camada de controle de acesso, definida como subcamada MAC (Medium
Access Control) e a subcamada LLC (Logical Link Control), que executa controle de
seqncia, controle de fluxo e recuperao de erros em redes locais.
2.4 Camada de Rede

A camada de rede define a rota e o processo pelo qual os dados sero
trafegados pela rede, fornecendo ao nvel de transporte uma independncia quanto
as consideraes de chaveamento e roteamento, onde as mensagens so
encaminhadas na rede segundo algoritmos de roteamento e endereamento. Prove
tambm servios pertinentes a duas filosofias:
Circuitos virtuais. So servios orientados conexo, nesta tcnica, os

pacotes pertencentes a uma nica conversao, no so independentes;
Datagramas. So servios no orientados conexo, onde o roteamento

determinado toda vez que um pacote encaminhado por um n da rede.
31
O controle de congestionamento de pacotes tambm realizado pela camada

de rede, possibilitando que redes heterogneas sejam interconectadas.
As principais funes da camada de rede, conforme define [CARVALHO-94]
so:
Roteamento e relaying;
Multiplexao da conexo de rede;
Segmentao e blocagem;
Controle de erro;
Sequenciao;
Controle de fluxo;
Transferncia de dados expressos;
Reinicializao;
Seleo de servio;
Gerenciamento.
O objetivo do nvel da camada de rede oferecer ao nvel da camada de

transporte independncia quanto ao roteamento, possibilitando entre outros
servios, controle de congestionamento.
2.5 Camada de Transporte

A camada de transporte tem a funo de endereamento e de organizao das
mensagens em segmentos, entregando-as camada superior (camada de sesso);
a camada de transporte tambm determina o tipo de servio a ser fornecido
camada de sesso. Neste nvel tambm configurada a distribuio dos endereos
dos ns, bem como os mtodos de deteco de erros e recuperao. Caso os dados
no sejam enviados corretamente ao dispositivo receptor, a camada de transporte
inicia a retransmisso ou informa s camadas superiores para correo do
problema.
No nvel da camada de transporte so realizados o controle de fluxo das
mensagens, a multiplicao e o splitting (uma conexo de transporte ligada a vrias
32
conexes de rede). Conforme expe [CARVALHO-94], o splitting corresponde ao

caso em que uma nica conexo (N) mapeada em diversas conexes da camada
inferior (N-1).
A figura 02 abaixo ilustra o mapeamento entre conexes.
Figura 02: Splitting camada (N)

Fonte: [CARVALHO-94]
Conforme define [TANENBAUM-03], a camada de transporte uma

verdadeira camada fim-a-fim, que liga origem destino, ou seja, nas camadas
inferiores, os protocolos so trocados entre cada uma das mquinas, nas camadas
de transporte, de sesso, de apresentao e aplicao, as camadas so
consideradas fim-a-fim, complementa [TANENBAUM-03].
Conforme expe [CARVALHO-94], as principais funes da camada de
transporte, definidas pela ISO, em funo da qualidade de servio, so:
Mapeamento do endereo de transporte no endereo de rede;
Estabelecimento e liberao de conexo de transporte;
Multiplexao (fim-a-fim) de conexes de transporte sobre conexes de

rede;
Segmentao, blocagem e concatenao fim-a-fim;
Controle de seqncia e controle de erro;
33
Controle de fluxo;
Monitorao de fluxo;
Monitorao de qualidade de servio;
Transferncia de unidades de dados expressos;
Gerenciamento da qualidade de servio.
Conforme define [SOARES-99], o controle de fluxo possui funo relevante

neste nvel, visto que nenhuma implementao tem espao de armazenamento
infinito, algum mecanismo deve ser assegurar que o transmissor envie mensagens
numa taxa maior que a capacidade do receptor possa receb-las.
2.6 Camada de Sesso

Na camada de sesso realizado o gerenciamento de token, controle do
dilogo e gerenciamento de atividades de trfego de informaes. A definio de
direo dos dados pelos modos:
Simplex, comunicao em apenas uma direo;
Half duplex, cada equipamento pode transmitir e receber, entretanto, um de

cada vez;
Full duplex permite comunicao simultnea, recebendo e transmitindo

dados.
Este nvel executa tambm a administrao da sesso, efetuando o

estabelecimento da conexo, transferindo dados e a liberao da conexo,
permitindo
que
os usurios
de
diferentes mquinas
possam
estabelecer
comunicao, realiza estabelecimento de conexo com outros usurios, definio de

pontos de sincronizao em um dilogo, interrupo de dilogos, negociao e
utilizao de tokens para permuta de dados. Conforme expe [CARVALHO-94],
estes servios esto baseados nos conceitos de:
Pontos de sincronizao, onde so definidos o ponto de sincronizao

maior e ponto de sincronizao menor;
Atividade, que define um conjunto de unidades de dilogo;
34
Token, propriedade de uma conexo de sesso dinamicamente atribuda

aos servios da camada de sesso. So definidos os tokens de: dados,
sincronizao menor, sincronizao maior e de liberao ordenada.
O nvel de sesso oferece mecanismos que possibilitam estruturar os circuitos

oferecidos pelo nvel de transporte. A camada de sesso utiliza o conceito de
atividade, possibilitando aos usurios distinguir partes do intercmbio de dados,
definidos como atividades, que so constitudas de unidades de dilogo; que podem
ser interrompidas e depois recomeadas na mesma sesso, ou em conexes de
sesso subseqentes, conforme expe [SOARES-99].
2.7 Camada de Apresentao

A camada de apresentao realiza a semntica e a transformao adequada
dos dados. Antes do envio dos dados pelo nvel de sesso, executa tarefas como
compresso de textos e dados, descompresso de arquivos, criptografia de dados,
converso de padres ASCII (American Standard Code for Information Interchange)
e EBCDIC (Extended Binary-Coded Decimal Interchange Code) de terminais e
arquivos para padres de rede e vice-versa.
A camada de apresentao gerencia as estruturas de dados abstratos e
possibilita o intercmbio de dados de nvel mais elevado. Nesta camada realizada
a codificao da informao especificada por meio de sintaxe abstrata em octetos
para que os dados possam ser transferidos camada de sesso.
Conforme define [CARVALHO-94], as principais funes da camada de
apresentao so:
Mapeamento da conexo de apresentao;
Negociao e renegociao de contexto de apresentao;
Transformao de sintaxe;
Transferncia de dados;
Pass-through dos servios de sesso, que repassa as primitivas de servios

diretamente camada superior (camada de aplicao). A figura 03 a seguir
ilustra esta operao.
35
Gerenciamento da camada de apresentao.
Figura 03: Pass-through dos servios de sesso.

Existe uma correspondncia biunvoca entre os endereos de apresentao e

de sesso; no existe nenhum tipo de multiplexao nesse nvel de protocolo,
conforme expe [SOARES-99].
2.8 Camada de Aplicao

O nvel da camada de aplicao oferece aos processos de aplicao os meios
para que estes utilizem os meios de comunicao.
A camada de aplicao contm vrios protocolos comumente necessrios para
os usurios. Neste nvel so definidas as funes de gerenciamento da rede. O
nvel de aplicao possui todas as funes necessrias a comunicao entre
sistemas abertos que no so executadas pelos outros nveis, alm disto, o nvel de
aplicao realiza tambm os seguintes servios: [CARVALHO-94]
Definio da qualidade de servio aceitvel na conexo;
Sincronizao das aplicaes participantes;
Identificao de parceiros de comunicao;
36
Mapeamento da associao de aplicao;
Determinao da disponibilidade do parceiro de comunicao;
Definio da responsabilidade na recuperao de erros;
Especificao de aspectos relativos segurana, integridade de dados,

controle de acesso, etc.;
Autenticao de parceiros de comunicao;
Determinao da qualidade de servio;
Seleo de modo de dilogo (full duplex ou half duplex).
Conforme expe [CARVALHO-94], o conjunto de elementos de servio de

aplicao vinculados a uma associao e a relao existente entre tais elementos
constituem o contexto de aplicao.
A figura 04 abaixo ilustra a relao que ocorre entre processos, entidades e
elementos de servio de aplicao, onde cada entidade de aplicao constituda
por Elementos de Servio de Aplicao, ASE (Application Service Elements).
Figura 04: Relao entre processos, entidades e elementos de servio de aplicao.

37
As seis camadas inferiores incluem funes e implementaes que suportam

os servios de rede, enquanto que a camada de aplicao fornece os protocolos
necessrios para a realizao das funes especificas dos servios da rede, como o
FTAM (File Transfer, Access and Management), o DS (Directory Service) e o MHS
(Message Handling System), conforme menciona [SOARES-99].
O processo de transmisso de dados no Modelo de Referncia OSI, pode ser
ilustrado conforme a figura 05 abaixo.
Figura 05: Transmisso de dados no Modelo OSI

Fonte: [SOARES-99]
O processo de transmisso de dados tem incio pelo nvel de aplicao da

estao transmissora; os dados do usurio so denominados SDU (Service Data
Unit). O nvel de aplicao agrega aos dados um cabealho definido, conforme
expe [SOARES-99] por PCI (Protocol Control Information), onde o resultado desta
juno denominado por PDU (Protocol Data Unit).
As informaes so transmitidas pelas camadas do Modelo de Referncia OSI,
que acrescentam em cada nvel um cabealho; este processo ocorre at o nvel de
enlace, que acrescenta dispositivo de checagem de erros definido por FCS (Frame
Check Sequence). Quando os dados so recebidos pela camada fsica do
destinatrio, ocorre processo inverso, fazendo com que os dados sejam recebidos
pelo usurio destinatrio.
As aplicaes podem implementar seus prprios protocolos de interao
utilizando o conjunto de sete camadas de ferramentas do Modelo de Referencia OSI,
conforme expe [OLIFER-08]; especificamente, para esse propsito fornecida aos
38
programadores uma interface de programao de aplicaes especial definida por

API (Application Programming Interface).
39
3. SISTEMAS DISTRIBUDOS
Os sistemas de informao atravessaram nas ltimas dcadas revolues
importantes que certamente alavancaram o desenvolvimento de diversos segmentos
da sociedade. Com o surgimento dos computadores, desde a era moderna da
computao a partir da dcada de 1940, quando os primeiros computadores
eletrnicos no possuam sistemas operacionais at os sistemas mainframes,
utilizados no processamento de informaes e sistemas de grandes corporaes e
instituies, que atingiram o auge na dcada de 1980; possibilitou que diversos
setores da economia fossem favorecidos com o surgimento e desenvolvimento de
sistemas que agregaram confiabilidade, agilidade a processos executados de forma
manual; quando em 1936, o primeiro computador eletromecnico foi desenvolvido
pelo engenheiro alemo Konrad Zuse. [MACHADO-07]
A ocorrncia da Segunda Guerra Mundial acelerou o desenvolvimento de
equipamentos e sistemas computacionais que auxiliaram militares nos esforos de
guerra. O ENIAC (Eletronic Numeric Integrator And Calculator) foi o primeiro
computador a vlvulas desenvolvido pelo exrcito dos Estados Unidos, utilizado para
clculo de trajetrias balsticas, tendo sido desenvolvido pelos engenheiros J.
Presper Eckert e John W. Mauchly, na Universidade da Pensilvnia, conforme expe
[MACHADO-07].
Nesta ocasio, a linguagem de programao era desenvolvida em funo da
linguagem da mquina, um bit por vez, em filas de chaves mecnicas, conforme
expe [DEITEL-05]. Os primeiros sistemas operacionais passaram a ser utilizados a
partir dos anos 50, quando os laboratrios da General Motors utilizaram seu
computador IBM 701. Em 1951, o MIT (Masssachusetts Institute of Technology)
colocou em funcionamento o primeiro computador voltado para aplicaes em tempo
real, o Whirlwind I, conforme expe [MACHADO-07].
A partir dos anos 60, Leonard Kleinrock, Paul Baran e Donald Davis;
conceituaram os sistemas de redes que utilizavam datagramas definindo a
comutao
de pacotes em
sistemas de
computadores.
Desde
ento,
desenvolvimento e conseqente aperfeioamento das redes de computadores locais

(LANs - Local Area Networks) e mesmo at as redes de longa distncia (WANs
40
Wide Area Networks) possibilitaram que milhares de equipamentos se conectassem,

trocando informaes, dados, arquivos; enfim, acelerando o desenvolvimento social,
cultural e tecnolgico. Nesta ocasio tambm houve a introduo do conceito de
multiprogramao, tornando os sistemas ociosos, em sistemas mais rpidos e
eficientes.
A partir da dcada de 70, sistemas com multiprocessadores, aplicaes de
tempo compartilhado e de tempo real alcanaram solues de integrao em larga
escala para slidos produtos comerciais. Neste momento, a Internet, as redes locais
(intranets) e as diversas tecnologias que emergiram em dispositivos de comunicao
suportadas em redes exemplificam a gama de servios e aplicaes de sistemas
distribudos. Surgiram solues proprietrias, como SNA (System Network
Architecture), DECNet, NCP (Netware Core Protocol) e X.251.
Na dcada de 80, softwares de rede passam a estar relacionados com
sistemas operacionais, dando incio aos sistemas operacionais de rede, como a
Novell Netware e a Microsoft LAN Manager, conforme expe [MACHADO-07].
Ocorreu enorme difuso de aplicaes voltadas correio eletrnico, transferncia de
arquivos e acesso a bancos de dados remotos. A computao distribuda passou a
integrar o ambiente corporativo, principalmente com solues baseadas no modelo
cliente/servidor.
A consolidao de sistemas operacionais baseados em interfaces grficas
ocorreu na dcada de 1990. O surgimento do WWW (World Wide Web), nesta
ocasio causou enorme popularidade nas aplicaes de computao distribuda.
Esta dcada foi marcada pelo surgimento de solues voltadas software de fonte
aberto, com a fundao da OSI (Open Source Iniciative).
A partir da dcada de 2000, o conceito de processamento distribudo teve
aplicao cada vez mais acentuada, conforme menciona [MACHADO-07]. A
necessidade de interligar aplicaes distintas e heterogneas, simplificando a
comunicao entre vrias arquiteturas divergentes aliados WebService fizeram de
solues
como
APIs
(Application
Programming
Interfaces)
middleware,
ferramentas indispensveis no ambiente computacional.

1
Uma norma do CCITT que descreve como os dados so tratados ao serem recebidos, e como os
computadores podem acessar uma rede de comutao de pacotes. [DERFLER-95].
41
A diviso de responsabilidades entre os componentes de um sistema e a

atribuio destes com os diversos computadores de uma rede talvez seja o aspecto
mais evidente do projeto de sistemas distribudos. Um sistema distribudo segundo
[TANENBAUM-07] pode ser definido como uma coleo de computadores
independentes que se apresenta aos seus usurios como um sistema nico e
consistente.
Para interligar computadores e redes heterogneas de forma simultnea, os
sistemas distribudos comumente podem ser dispostos por meio de uma camada de
software de alto nvel, que propicia a comunicao de dados entre as aplicaes. A
figura 06 abaixo ilustra o sistema distribudo organizado como camada de
middleware. [TANENBAUM-07].
Figura 06: Sistema distribudo organizado como Middleware

Fonte: [TANENBAUM-07]
A presena de computador autnomo associado com redes apresenta entre

outras vantagens a possibilidade de integrao de sistemas que executam
aplicaes distintas. [COULOURIS-07] define sistema distribudo como ambiente
onde os componentes de hardware ou software, localizados em computadores,
interligados em redes, se comunicam e coordenam suas aes apenas enviando
mensagens entre si.
Cabe salientar que o conceito que define sistema distribudo no faz meno
quanto distncia imposta aos componentes do sistema, que podem variar de
computadores pessoais, sistemas destinados CPD (Centros de Processamento de
Dados) at mesmo sistemas indstrias automatizados e informatizados.
42
O desempenho de sistemas distribudos analisado pelo aspecto da distncia

entre seus componentes tem sido continuamente aprimorado, devido aos
conseqentes esforos no desenvolvimento e aperfeioamento de redes e
protocolos destinados s redes de computadores, que tm crescido de forma
acentuada, conforme tabela 01 abaixo. Este crescimento, porm, traz uma
caracterstica relevante quanto interoperabilidade destes sistemas, fazendo com
que os mesmos sejam extensveis, ou seja, se o sistema prove servios em
conformidade com regras padronizadas que descrevam a sintaxe e a semntica de
tais servios. [COULOURIS-07].
Tabela 01: Computadores com IP registrados na Internet
Data
Dezembro de 1979
Julho de 1989
Julho de 1999
Janeiro de 2003
Computadores
Servidores Web
188
130.000
56.218.000
171.638.297
0
0
5.560.866
35.424.956
Fonte: [COULOURIS-07]
Inicialmente, os computadores eram vistos como dispositivos seqenciais,

capazes somente de realizar operaes de forma seqencial, entretanto, com a
implementao de sistemas multiprocessadores, elevou-se de forma exponencial o
poder computacional, reduzindo-se o tempo de processamento de diversas
aplicaes. Segundo [DEITEL-05], que define sistema de multiprocessamento como
qualquer sistema que contenha mais de um processador. Entre os exemplos de
multiprocessadores esto os computadores pessoais de dois processadores,
servidores de alta capacidade que contm muitos processadores e grupos
distribudos de estaes de trabalho que trabalham juntas para executar tarefas.
Em 1966, conforme expe [MACHADO-07], o modelo proposto por Michael
Flynn define os sistemas computacionais em funo do grau de paralelismo, sendo:
SISD (Single Instruction Stream, Single Data Stream). Este tipo caracteriza
o tipo mais elementar de arquitetura, que suporta fluxo nico de instrues
e fluxo nico de dados. Esta arquitetura enquadra a maioria dos
computadores pessoais que esto baseados em monoprocessadores.
Tcnicas como pipeline, VLIW (Very Long Instruction Word) e Hyper-
43
Threading (desenvolvida pela empresa Intel) possibilitam inserir paralelismo

em computadores com arquitetura SISD.
SIMD (Single Instruction Stream, Multiple Data Stream). Arquiteturas

definidas como SIMD consistem em uma ou mais unidades de
processamento.
Estas
arquiteturas
possuem
benefcios
quando
as
instrues executadas e possuem elevado grau de paralelismo de dados,

onde so efetuadas reiteradas operaes aritmticas. Computadores
providos com processadores vetoriais e processadores matriciais utilizam
arquitetura SIMD e so conhecidos como supercomputadores, capazes de
realizar elevadas quantidades de operaes.
MISD (Multiple Instruction Stream, Single Data Stream). Arquiteturas com

fluxo mltiplo de instrues e fluxo nico de dados no so comumente
encontrados, onde diversas unidades de processamento atuariam sobre o
mesmo fluxo de dados.
MIMD (Multiple Instruction Stream, Multiple Data Stream). Esta classe de

arquitetura enquadra sistemas com fluxo mltiplo de instrues e fluxo
mltiplo de dados, caracterizadas por unidades com multiprocessamento
atuando de forma independente sobre fluxo de dados diversos e separados.
Conforme expe [MACHADO-07], as arquiteturas baseadas em MIMD, podem

ser classificadas quanto ao grau de acoplamento de um sistema, ou seja, fatores
como compartilhamento e tempo de acesso memria principal, mtodos de
comunicao e velocidade dos processadores, possibilitam que estas arquiteturas
sejam classificadas em sistemas fortemente acoplados e fracamente acoplados.
A figura 07 a seguir ilustra estes sistemas e suas respectivas subdivises.
44
Figura 07: Sistemas com mltiplos processadores

Fonte: Adaptado de [MACHADO-07]
Em sistemas caracterizados como fortemente acoplados (tightly coupled

system), possuem uma nica memria principal, que compartilhada por todos os
processadores que utilizam um nico sistema operacional centralizado e os sistemas
definidos como fracamente acoplados (loosely coupled system), so conectados por
uma rede de comunicao, onde existem vrios processadores, sistemas
operacionais e memria principal. Estes sistemas apresentam caractersticas de
maior flexibilidade e escalabilidade em relao aos sistemas fortemente acoplados.
[MACHADO-07]
Os sistemas fortemente acoplados, denominados tambm por arquiteturas de
multiprocessadores, se subdividem em: SMP e NUMA.
Os sistemas SMP (Symemetric Multiprocessors), que tambm so definidos
UMA
(Uniform
Memory
Access
multiprocessor),
so
arquiteturas
de
multiprocessador de acesso uniforme memria principal; este tipo de sistema
45
possui degradao de desempenho, conforme expe [DEITEL-05], em sistemas de

grande escala.
Outra vertente de sistemas fortemente acoplado so os sistemas NUMA
(NonUniform Memory Access), que possuem elevado grau de escalabilidade, onde a
memria principal fisicamente distribuda entre os diversos processadores,
existindo, porm um nico espao de endereamento. A tabela 02 abaixo ilustra
caractersticas de sistemas NUMA.
Tabela 02: Caractersticas de sistemas NUMA
Sistema
CM-2
Paragon
T3D
SP-2
CM-5
Fabricante
Thinking Machines
Intel
Cray
IBM
Thinking Machines
Nmero de processadores
1024 a 4096
4 a 2048
16 a 2048
2 a 512
32 a 2048
Topologia
Cubo
Grid 2D
Torus 3D
rvore
rvore
Fonte: [MACHADO-07]
Os sistemas de multiprocessadores de arquitetura de memria somente de

cache, definidos por COMA (Cache Only Memory Architecture), so considerados
uma variao da arquitetura NUMA, onde cada processador, com seu respectivo
cache, esta associado com uma frao da memria global compartilhada; no existe
uma hierarquia de memria em cada processador, todos os caches formam um
espao de endereamento global, conforme expe [PITANGA-04]. Outra variante de
sistemas NUMA so os sistemas de multiprocessadores escalveis CC-NUMA, que
possuem arquitetura de coerncia com acesso no uniforme, onde a memria
dividida na mesma quantidade de blocos e de processadores, sendo que cada bloco
conectado via barramento a um processador com memria local.
Sistemas fracamente acoplados, conforme define [DEITEL-05] comumente
conectam componentes indiretamente por meio de enlace de comunicao. Estes
sistemas possuem como caracterstica essencial maior flexibilidade e acentuada
escalabilidade em comparao sistemas fortemente acoplados. Estes sistemas
tambm so designados como arquiteturas multicomputadores. Exemplos de
sistemas desta natureza so Sistemas Clusters, que so constitudos por redes de
interconexo, destinados aplicaes de alto desempenho.
46
Os Sistemas Clusters possuem elevada tolerncia falhas associados com

alta disponibilidade; estes sistemas so utilizados em servidores de banco de dados,
sistemas de firewall entre outras aplicaes.
Outra exemplificao de sistemas fracamente acoplados so os Sistemas
Operacionais de Rede (SOR), conforme expe [MACHADO-07]. Atualmente estes
sistemas so encontrados em redes locais (LANs) e redes metropolitanas,
distribudas geograficamente (WANs) e esto implementados em sistemas
operacionais heterogneos, possibilitando comunicao por meio da pilha de
protocolos que formou a base da internet, os protocolos TCP/IP (Transmission
Control Protocol/ Internet Protocol).
Outra vertente relevante de sistemas fracamente acoplados so os Sistemas
Distribudos; que so definidos por [PITANGA-04] como conjunto de elementos que
se comunicam atravs de uma rede de interconexo e que utilizam software de
sistema distribudo. Cada elemento composto por um ou mais processadores e
uma ou mais memrias.
Conforme salienta [MACHADO-07], um aspecto essencial na conceituao de
sistemas distribudos, onde se pode definir um sistema distribudo como fracamente
acoplado pelo aspecto de hardware e fortemente acoplado pelo aspecto de software.
Tais sistemas permitem elevada escalabilidade, implementao de sistemas de
tolerncia falhas, que podem estar dispostos em vrios nveis, alm de permitir a
implementao de aplicaes distribudas em funo das necessidades dos
usurios.
Cabe salientar a distino existente entre sistemas de computao distribudos,
sistemas de informao distribudos e sistemas embutidos distribudos (tambm
conhecidos por sistemas distribudos pervasivos), conforme expe [TANENBAUM07].
A figura 08 a seguir ilustra os tipos de sistemas distribudos e suas respectivas
subdivises:
47
Figura 08: Sistemas distribudos

Fonte: Adaptado de [TANENBAUM-07]
Sistemas de computao distribudos, utilizados para computao de alto

desempenho para sistemas distribudos, que se subdivide em dois grupos:
Sistemas de computao de cluster, que utilizada na maioria das

aplicaes para programao paralela onde um nico programa
executado
em
vrias
mquinas,
tendo
como
aspecto
tpico
homogeneidade;
Sistemas de computao em grade, definidos pelo alto grau de

heterogeneidade, onde a colaborao entre aplicaes distintas ocorre sob
forma de uma organizao virtual. Conforme prope [FOSTER et al. 2001]1
adup [TANENBAUM-07], uma arquitetura para este tipo de sistema
constituda em quatro camadas, sendo:
Camada base, que prove interfaces para recursos em locais em site
especfico;
FOSTER, I.; KISHIMOTO, H. e SAVVA, A. The Open Grid Service Architecture, Version 1.0 GGF
Information Document GFD-I.030, janeiro 2005.
48
Camada de conectividade, formada por protocolos de comunicao

para suportar transaes da grade que abranjam a utilizao de
mltiplos recursos;
Camada de recursos, com subsdios da camada de conectividade,
responsvel pelo gerenciamento de um nico recurso, chama as
interfaces que esto disponveis pela camada base;
Camada coletiva, que manipula o acesso a mltiplos recursos, alm de
realizar o escalocamento e alocao de tarefas para mltiplos recursos;
Camada de aplicao, que realiza aplicaes para o ambiente de
computao em grade.
A figura 09 abaixo ilustra arquitetura computao em grade.
Figura 09: Arquitetura em camadas computao em grade.

O conjunto destas camadas, ou seja, camadas de coletividade, de

conectividade e de recursos, definem conforme expe [TANENBAUM-07], a
essncia de middleware em grade.
Sistemas de informao distribudos caracterizam uma classe definida por
sistemas distribudos encontrados em corporaes e instituies, que necessitaram
buscar solues para integrao em aplicaes de rede. Vrias solues de
middleware existentes atualmente so procedentes do desenvolvimento com uma
infraestrutura na qual era mais fcil integrar aplicaes a um sistema de informaes
49
de mbito empresarial. Conforme expe [TANENBAUM-07] pode-se distinguir vrios

nveis nos quais ocorreu a integrao, algumas solues propunham uma aplicao
em rede, consistindo em um servidor que executava aplicao especfica,
freqentemente incluindo um banco de dados e que a disponibilizava para
programas remotos, definidos como clientes, que podiam enviar solicitaes ao
servidor para execuo de tarefa determinada.
Ainda conforme [TANENBAUM-07], a integrao ocorrida a baixo nvel
possibilitava que clientes empacotassem vrias requisies possivelmente para
diferentes servidores em uma nica requisio maior, e posteriormente, as
enviassem para execuo como uma transao distribuda, onde todas as
requisies deveriam ser executadas.
Com o surgimento de aplicaes mais elaboradas, que eram gradativamente
separadas em componentes independentes, distinguindo componentes de banco de
dados de componentes de processamento, ficou evidente que a integrao deveria
ocorrer de modo que possibilitasse as aplicaes se comunicar diretamente entre si,
esta necessidade resultou nos modelos de integrao entre aplicaes empresariais
definidos
como
EAI
(Enterprise
Application
Integration),
conforme
expe
[TANENBAUM-07].
A EAI surgiu da necessidade de integrar aplicaes COTS (Commercial-OffThe-Shelf), que surgiram em meados da dcada de 1990, oferecendo suporte s
funes de negcios especficos, tais como fabricao, administrao de pessoal e
contabilidade, conforme aborda [CUMMINS-02]. As solues de integrao
baseadas em EAI provem ferramentas, dispositivos e componentes para facilitao
do processo de integrao, por meio de adaptadores sistemas legados.
Sistemas
distribudos
pervasivos,
tambm
conhecidos
como
sistemas
embutidos distribudos, so sistemas que possuem como caractersticas a

estabilidade e tamanho comumente reduzido; so compostos de um ou mais
computadores pessoais que integram equipamentos eletrnicos de consumo, tpicos
como aparelhos de TV, equipamentos de udio e vdeo, smart phones, PDAs
(Personal digital Assistants) e outros equipamentos de uso pessoal, por isso so
inerentemente distribudos e que esto entorno da vida cotidiana, integrados em um
nico sistema.
50
Os requisitos para aplicaes pervasivas devem prover mudanas contextuais,

devido modificao contnua do ambiente, como alterao entre estaes-base,
possibilitando conectar-se a outra rede; incentivar composio ad hoc, visto que
usurios diversos utilizam de modos diferentes e reconhecer compartilhamento
como padro de forma facilitada.
Conforme expe [MASCOLO et al. 2004]1 adup [TANENBAUM-07] na
presena de mobilidade, tais dispositivos devem suportar a adaptao fcil e
dependente de aplicao a seu ambiente local. Tambm devem ser capazes de
descobrir servios como eficincia e reagir de acordo.
Exemplos de sistemas distribudos pervasivos so encontrados em sistemas
domsticos, onde atualmente a conexo, em muitos casos, obtida por meio de
padres UPnP (Universal Plug and Play). No ambiente hospitalar, em sistemas e
dispositivos eletrnicos destinados ao tratamento de sade, freqentemente so
utilizados sistemas equipamentos com sensores organizados em rede de rea
corporal denominados por BAN (Body-area Network). Os dispositivos e redes de
reas corporais devem suportar processamento de dados na rede, onde os dados
de monitoramento devem ser agregados, armazenados e enviados de forma
permanente centros mdicos especializados. [TANENBAUM-07]
Outro exemplo de sistemas distribudos pervasivos so as redes de sensores,
que so utilizados na aquisio de dados e processamento de informaes. Ainda
conforme [TANENBAUM-07], que aborda rede de sensores, definindo-os como as
redes em malha, que em essncia, formam um conjunto de ns que se comunicam
por meio de ligaes sem fio. Essas redes podem forma a base para muitos
sistemas distribudos de mdio porte. Tais dispositivos e sistemas so utilizados
atualmente em sistemas wireless para comunicao e troca de dados e informaes
em uma rede LAN em ambientes corporativos; no contexto industrial, dispositivos
com estas caractersticas so utilizados para interligar dispositivos de automao em
ambientes hostis e de difcil acesso.
MASCOLO, C.; CAPRA, L. e EMMERICH, W. Principles of Mobilie Computing Middleware. In

Mahamoud, Qusay H. (ed.), Middleware for Communications, captulo 12. Nova York: John Wiley,
2004.
51
Assim, a computao distribuda consiste em adicionar o poder computacional

de diversos computadores interligados por uma rede de computadores ou mais de
um processador, atuando em conjunto no mesmo computador, para processar
colaborativamente atividade determinada de forma coerente e transparente.
A unio desses diversos computadores com o objetivo de compartilhar a
execuo de tarefas caracteriza os modernos sistemas distribudos. O fator
motivador para o desenvolvimento e aplicao de sistemas distribudos a
necessidade de compartilhamento de recursos.
Usurios de sistemas operacionais distribudos possuem a noo de que esto
interagindo com uma mquina somente, enquanto, os sistemas operacionais de
rede, devem estar conscientes da implementao distribuda. Conforme define
[TANENBAUM-07], um sistema distribudo deve ter por meta a abertura, onde o
sistema deve prover servios de acordo com regras padronizadas que descrevem a
sintaxe e semntica desses servios. Estas regras so definidas em protocolos e
descritas por meio de IDL (Interface Definition Language). Alm deste requisito,
desejvel que o sistema distribudo tenha caractersticas de:
Transparncia, em um sistema distribudo, os usurios no devem ser

capazes de distinguir a localizao dos recursos, por exemplo, sistema de
arquivo distribudo remoto no deve ser diferente do sistema de arquivo
local. A ISO
Open Distribuited Processing Model, define oito tipos de
transparncias de sistemas distribudos, conforme aborda [DEITEL-05]:

Transparncia de acesso;
Transparncia de localizao;
Transparncia de falha;
Transparncia de replicao;
Transparncia de persistncia;
Transparncia de migrao;
Transparncia de relocao;
Transparncia de transao.
52
Flexibilidade, sistemas distribudos devem ser construdos para redes,

processos e linguagens de programao heterogneas, desta forma,
protocolos
sistemas
middleware
devem
dissimular
divergncias
existentes;
Segurana, os recursos de um sistema distribudo devem ser protegidos

contra agentes externos, e esta baseada em trs componentes principais:
Confidencialidade,
Integridade,
Disponibilidade.
Desempenho, apesar do custo computacional, a implementao de

dispositivos de tolerncia no devem afetar o desempenho de sistemas
distribudos, que podem ser mensurados por:
Nmero de mensagens;
Granulidade.
Concorrncia, caracterstica relacionada a pedidos concorrentes para

recursos, onde cada recurso deve ser definido para assegurar a
consistncia quando requerido;
Escalabilidade, caracterstica relacionada ao acrscimo de usurios e

recursos de forma constante ao sistema, sendo, portanto uma das metas
mais importantes no desenvolvimento de sistemas distribudos. Esta
caracterstica pode ser mensurada sob aspectos de tamanho, em termos
geogrficos e administrativos.
3.1 Modelos de Arquiteturas de Sistemas Distribudos

Os incrementos de velocidade e confiabilidade que a redes de dados obtiveram
devido constantes aprimoramentos, associados com o desenvolvimento de
arquiteturas computacionais mais eficientes, tornaram os sistemas destinados
informao cada vez mais conectados. A necessidade de compartilhar recursos e
dispor de sistemas integrados e tolerantes falhas tornou os Sistemas Distribudos
difundidos em diversas arquiteturas.
53
A arquitetura de um sistema distribudo pode ser definida em funo de sua

estrutura, em termos de componentes especificados separadamente, conforme
expe [COULOURIS-07]. A organizao de sistemas distribudos, onde os
componentes de software que compem o sistema possuem como objetivo central
assegurar que a estrutura atenda as demandas atuais e, provavelmente as
solicitaes futuras que sero impostas ao sistema, tendo como maior anseio tornar
o sistema confivel, gerencivel, adaptvel s implementaes. Esta expectativa
atingida por meio das camadas de software que compem os sistemas distribudos.
Conforme aborda [COULOURIS-07], que define o termo arquitetura de software
como algo que se refere estruturao do software em camadas ou mdulos em
um nico computador e, mais recentemente, em termos de servios oferecidos e
solicitados entre processos localizados em um mesmo computador ou em
computadores diferentes. A necessidade de definio de uma arquitetura de
software para sistemas distribudos conduz necessariamente determinao de
uma arquitetura de sistema.
A figura 10 abaixo ilustra os principais componentes de software de sistemas
distribudos.
Figura 10: Camadas de software e hardware em sistemas distribudos

Fonte: [COULOURIS-07]
A plataforma define os nveis baixos da arquitetura, oferecendo servios aos

nveis que esto localizados acima. Esta camada facilita a comunicao e
coordenao entre processos. Os sistemas operacionais distribudos fazem parte da
54
plataforma, provendo o gerenciamento de recursos localizados em vrios

computadores em rede, utilizando vrios dos mesmos mtodos de comunicao,
estruturas e outros protocolos encontrados em sistemas operacionais de rede
tornando a comunicao transparente. [COULOURIS-07]
A definio de arquitetura de sistemas distribudos atende a estilos
arquitetnicos, que podem ser especificados em funo dos componentes que
constituem as arquiteturas de sistemas distribudos e pela forma de como estes
componentes esto conectados. [TANENBAUM-07] classifica os estilos de
arquiteturas de sistemas distribudos em:
Arquiteturas em camadas;
Arquiteturas baseadas em objetos;
Arquiteturas centradas em dados;
Arquiteturas baseadas em eventos.
Os dispositivos que compem sistemas distribudos, comumente, possuem

caractersticas heterogneas, para dissimular a heterogeneidade faz-se necessria
camada de programao, que oferea abstrao aos sistemas operacionais e
linguagens de programao subjacentes assegurando portabilidade, transparncia e
interoperabilidade em sistemas distribudos; estes requisitos so obtidos por meio de
camadas de software Middleware.
A disposio dos componentes de software em sistemas distribudos define
arquiteturas de sistemas, classificadas em:
Arquiteturas centralizadas;
Arquiteturas descentralizadas;
Arquiteturas hbridas.
Os sistemas distribudos com arquiteturas centralizadas podem ser definidos

pela simplicidade de implementao e gerenciamento, entretanto, so um
estrangulamento em potencial, visto que, comumente o servidor central possui
capacidade limitada e ter o desempenho afetado em virtude do aumento de
demanda. Por outro lado, os sistemas descentralizados so escalveis e robustos,
porm isso demanda certa complexidade de implementao, principalmente nas
55
questes de tolerncia falhas e descoberta de recursos. Muitos sistemas

distribudos combinam caractersticas das duas arquiteturas, parte do sistema no
tradicional modelo cliente-servidor e outra parte do modelo peer-to-peer definindo
arquiteturas hbridas.
Estruturas hbridas so implantadas notavelmente em sistemas distribudos
colaborativos. A principal preocupao em muitos desses sistemas como se juntar
ao sistema, para o qual muitas vezes um esquema tradicional cliente-servidor
adotado. Uma vez que o n se une ao sistema, pode-se utilizar um esquema
totalmente descentralizado para colaborao.
3.2 Arquiteturas Centralizadas

Os sistemas distribudos, com arquiteturas centralizadas, possuem como
caractersticas, serem fortemente acoplados, tipo monoltico, onde no ocorre o
particionamento ncleo, ou seja, os servios do sistema e do ncleo fazem parte de
um mesmo programa.
Conforme define [DEITEL-05], o sistema operacional monoltico a arquitetura
de sistema operacional mais antiga e mais comum. Cada componente do sistema
operacional contido no ncleo e pode comunicar-se diretamente com qualquer
outro. O ncleo normalmente executado com acesso irrestrito ao sistema de
computador.
A figura 11 a seguir ilustra arquitetura de sistema operacional de ncleo
monoltico.
56
Figura 11: Arquitetura de sistema operacional de ncleo monoltico

Fonte: [DEITEL-05]
Quando se aborda arquiteturas centralizadas, em sistemas distribudos, a

arquitetura
cliente/servidor
possui
ampla
utilizao,
tendo
sido
bastante
implementada ao longo dos anos por diversas aplicaes.

Conforme
expe
[RENAUD-94],
sistemas
cliente/servidor
so
mais
interessantes quando os processos cliente e servidor so executados em mquinas

diferentes conectadas por meio de uma rede. Um servidor um processo que
implementa um servio especifico, e um cliente um processo que solicita um
servio de um servidor por meio de uma requisio. Como exemplo de aplicao do
modelo cliente-servidor, podem-se citar sistemas de servidor para banco de dados
distribudos, que interage continuamente com clientes, retransmitindo informaes
requisitadas.
A figura 12 a seguir ilustra arquitetura cliente/servidor, composta por trs
camadas.
57
Figura 12: Sistema cliente/servidor.

Fonte: [RENAUD-94]
Conforme expe [TANENBAUM-07], vrias aplicaes cliente-servidor podem

ser construdas em conformidade com partes distintas da arquitetura: uma parte que
manipula a interao com um usurio, uma parte que atua sobre um banco de dados
e uma parte que contm a funcionalidade central de uma aplicao.
Exemplificaes deste modelo de arquitetura podem ser encontrados em
dispositivos de busca na Internet, em sistemas de banco de dados implementados
em redes locais; em funo do ambiente de negcio da corporao onde tais
sistemas estejam atuando, o nvel dos dados pode ser organizado como banco de
dados relacional.
A figura 13 a seguir ilustra aplicao de banco de dados por arquivo
compartilhado e cliente/servidor.
58
Figura 13: Aplicao de banco de dados por arquivo compartilhado e cliente/servidor

Fonte: [RENAUD-94]
Neste
modelo
de
arquitetura
computao
distribuda,
controle
gerenciamento das operaes do sistema ocorrem de forma centralizada, provendo

possibilidade
de
reduo
de
custos
comparativamente
aos
sistemas
descentralizados, porm, conforme expe [LOPES-00], estes modelos no so to

confiveis quanto os sistemas descentralizados, em que as estaes de trabalhos
atuam de forma independente e com redundncia.
3.2.1 Cliente/Servidor
O modelo cliente/servidor uma arquitetura computacional que envolve
requisies de servios de clientes para servidores, desta forma, a definio para
cliente/servidor seria a existncia de uma plataforma base para que as aplicaes,
onde um ou mais clientes e um ou mais servidores, juntamente com o sistema
operacional da rede, executem processamento distribudo. O sistema poderia ser
entendido como a interao entre hardware e software em diferentes nveis,
implicando na composio de diferentes computadores e aplicaes.
O
modelo cliente/servidor
pode
ser visto
como um
paradigma de
programao que representa as interaes entre os processos e a estrutura do
59
sistema. Este sistema utilizado para melhorar a estrutura do sistema operacional,

movendo-se a maior quantidade possvel de funes para nveis mais altos do
sistema, reduzindo, portanto o tamanho do ncleo.
A estao servidor disponibiliza recursos de uma estao aos usurios da rede,
dentre alguns tipos de servidores, podem ser citados: [SOARES-99]
Servidor de arquivos;
Servidor de banco de dados;
Servidor de impresso;
Servidor de comunicao;
Servidor de gerenciamento.
O processo cliente ativo, emitindo solicitaes ao servidor utilizando Sistema

Operacional de Rede (SOR). A estao cliente pode interagir com nico servidor ou
com
vrios,
conforme
expe
[SILVERSCHATZ-99],
cliente
possui
responsabilidade de manter e processar o dilogo com o usurio, alm de realizar a

validao dos dados. O processo servidor possui caracterstica reativa, oferecendo
servios mediante solicitao s estaes cliente, via SOR. Comumente, um
servidor possui funo especfica, podendo ser acessado por vrias estaes
clientes simultaneamente.
O modelo cliente/servidor pode ser implementado em camadas.
Nos sistemas dispostos em duas camadas, a GUI (Graphical User Interface) e
a lgica de aplicao so executados na estao cliente, enquanto o servidor SQL
(Structure Query Language) executado na estao servidor.
Para a arquitetura disposta em trs camadas, a GUI processada na estao
cliente, a lgica de aplicao executada em um servidor de aplicao que atua
como um cliente para o servidor SQL. [MENASCE-02]
A figura 14 a seguir relaciona os componentes da arquitetura cliente/servidor
com Modelo de Referencia OSI.
60
Figura 14: Relao entre Modelo de Referncia OSI e Sistema Operacional de Rede
(SOR).
Fonte: Adaptado de [SOARES-99]
Em 1998, [ORFALI-98] abordava na ocasio que as prximas geraes de

tecnologias cliente/servidor estaro baseadas em objetos distribudos, como CORBA
e JAVA; e define a prxima onda como Web Technology. As ondas da evoluo
da arquitetura cliente/servidor so ilustradas na figura 15 abaixo:
Figura 15: As ondas da arquitetura cliente/servidor

Fonte: [ORFALI-98]
61
3.3 Arquiteturas Descentralizadas

Nas ltimas dcadas, tem crescido de forma acentuada a necessidade de
sistemas computacionais escalveis e que apresentem maior tolerncia falhas,
permitindo o compartilhamento de recursos em larga escala, fato considerado
natural, devido ao aumento de demanda por servios online associado diretamente
ao crescimento da Internet que impulsionou diversas transaes.
As redes de dados tornaram-se maiores e mais complexas, pela substituio
de sistemas monolticos por sistemas distribudos; este crescimento esta relacionado
tambm ao processo de reduo de custos que os servios de telecomunicaes
atingiram nos ltimos anos, tendo sido resultado de esforos no desenvolvimento de
polticas de integrao de usurios na Internet devido ao enorme potencial mercantil,
social e cultural.
Conforme expe [COULOURIS-07], esperado que a demanda por servios
na Internet cresa em uma escala limitada apenas pelo tamanho da populao
mundial. Esta afirmao pode ser complementada pela incluso de novas
populaes que atualmente no tm acesso a Internet, seja por motivos
econmicos, polticos e sociais.
Em arquiteturas descentralizadas, a interao entre os sistemas operacionais
de rede, que estabelecem a comunicao entre as estaes da rede, no havendo
necessidade de servidor central de gerenciamento; nesta arquitetura, todas as
estaes possuem o mdulo cliente do sistema operacional (SORC) e o mdulo
servidor do sistema operacional (SORS). [SOARES-99]
Conforme expe [TANENBAUM-07], o conceito de arquitetura de sistema
distribudo descentralizado pode ser considerada uma evoluo do modelo de
arquitetura distribuda cliente/servidor multidivididas (distribuio vertical/distribuio
horizontal), onde o peer-to-peer define uma classe de arquitetura de sistemas que
suporta distribuio horizontal.
Ainda conforme [TANENBAUM-07], de uma perspectiva de alto nvel, os
processos que constituem um sistema peer-to-peer so todos iguais, o que significa
que as funes que precisam ser realizadas so representadas por todo processo
62
que constitui o sistema distribudo; como conseqncia, grande parte da interao

entre processo simtrica.
As redes onde os ns formam processos e os enlaces formam os caminhos,
definem uma rede de sobreposio, na qual as redes peer-to-peer se
desenvolveram.
Existem dois tipos de redes de sobreposio (peer-to-peer): estruturadas e no
estruturadas. [TANENBAUM-07]
A figura 16 abaixo ilustra a arquitetura peer-to-peer.
Figura 16: Arquitetura Peer-to-Peer

Conforme expe [COULOURIS-07], que definiu peer-to-peer como aplicativos

que exploram os recursos disponveis nos limites da Internet armazenamento,
ciclos de processamento, contedo, presena humana.
Diferente de arquiteturas centralizadas tradicionais, os sistemas peer-to-peer
fornecem acesso e recursos de informao localizados em computadores de toda
uma rede, seja uma rede corporativa ou mesmo a Internet. Os sistemas peer-to-peer
compartilham as seguintes caractersticas: [COULOURIS-07]
Garantia que cada usurio contribua com recursos ao sistema;
Todos os ns em um sistema peer-to-peer possuem as mesmas

capacidades e responsabilidades funcionais;
63
A administrao do sistema deve ocorrer de forma descentralizada;
Devem ser projetados de forma a proporcionar um grau limitado de

anonimato para provedores e usurios dos recursos;
Equilbrio da carga de trabalho e garantia de disponibilidade sem adio de

sobrecargas indevidas por meio da escola correta de algoritmo de
disposio de dados em vrios hosts.
3.3.1 Peer-to-Peer
A primeira utilizao da expresso peer-to-peer ocorreu em 1984, com o
desenvolvimento do projeto Advanced Peer-to-Peer Networking Architecture, na
IBM. Conforme expe [TANENBAUM-07], as redes peer-to-peer se desenvolveram
em torno do paradigma do conceito de rede de sobreposio, ou seja, uma rede
onde os ns so constitudos pelos processos e os enlaces representam os canais
de comunicao, onde as estaes so interconectadas por grafos, interconectados
por arestas, que simbolizam as conexes entre as estaes da rede.
A partir de 1999, as redes peer-to-peer surgiram de forma acentuada, quando
nmero significativo de usurios adquiriram conexes de banda larga. Em meados
do ano de 2004, o nmero de conexes de banda larga da internet ultrapassava 100
milhes. O desenvolvimento dos sistemas peer-to-peer podem ser classificados em
trs geraes: [COULOURIS-07]
Primeira gerao, definida pelo lanamento de servios de msicas;
Segunda gerao, caracterizada pelo compartilhamento de arquivos em

maior escalabilidade, tolerncia de falhas, esta gerao introduziu o
conceito Super-peers. (peers com altas taxas de transmisso);
Terceira gerao, caracterizada pelo Gnutella1 e BitTorrent2.
Gnutella um protocolo distribudo para buscas, modelado para redes no estruturadas e

descentralizadas, cujo sistema composto por servents que acumulam funo de cliente e servidor
simultaneamente. [FONSECA, Hubert. Compartilhamento de Contedo em Redes Peer-to-Peer]
2 BitTorrent um sistema peer-to-peer de transferncia de arquivos (download), que consiste em
reunir arquivos a partir de pores fracionadas de outros usurios (conceito de colaborao)
[TANENBAUM-07].
64
A arquitetura da rede peer-to-peer constituda pelas conexes entre os

softwares nas estaes que pertencem ao sistema, e independe da arquitetura da
rede fsica, podendo ser caracterizada em: no estruturada ou estruturada.
Alguns sistemas peer-to-peer possuem ns com funes especficas, onde os
sistemas possam ser caracterizados pelo nvel de centralizao em arquiteturas
puramente descentralizadas, parcialmente centralizadas ou hbridas.
[COULOURIS-07] cita que a funo de um middleware peer-to-peer
simplificar a contruo de servios implementados em vrios hosts, em uma rede
amplamente distribuda.
Para que isto seja obtido, o middleware deve possibilitar aos clientes localizar e
se comunicar com qualquer recurso disponvel, mesmo que este recurso esteja
amplamente distribudo entre os hosts.
Conforme aborda [COULOURIS-07], prover mecanismos que possibilitem aos
clientes acessarem recursos de dados de forma rpida e segura um problema
relevante no projeto de aplicativos peer-to-peer. Alm de requisitos funcionais, o
middleware peer-to-peer deve tratar requisitos no funcionais, tais como:
Escalabilidade global;
Balanceamento de carga;
Otimizao das interaes entre peers;
Segurana de dados em ambientes heterogneos;
Anonimato.
Conforme finaliza [COULOURIS-07], expondo que o projeto de uma camada

middleware para suportar sistemas peer-to-peer em escala global problema difcil;
os requisitos de escalabilidade e disponibilidade tornam impraticvel manter um
banco de dados em todos os ns clientes.....
3.4 Banco de dados

As
informaes
geradas
no
processamento
de
dados em
sistemas
computacionais so armazenadas em repositrios definidos por banco de dados.

Sistemas de bancos de dados so desenvolvidos para prover o gerenciamento de
65
grandes quantidades de informaes, onde so utilizados Sistemas Gerenciadores

de Banco de Dados (SGBD), conforme define [SILVERSCHATZ-99].
No atual ambiente corporativo, os bancos de dados podem ser vistos como
sistemas de gesto que possibilitam que diversos processos e usurios utilizem a
mesma base de informao sob necessidades diversas.
Conforme expe [SILVERSCHATZ-99], um sistema de banco de dados oferece
o benefcio de proporcionar aos usurios deste sistema uma viso abstrata dos
dados, ocultando detalhes sobre maneiras de armazenamento e manuteno destes
dados.
Existem vrios tipos de bancos de dados disponveis, dos quais se destacam:
Banco de dados relacional. Este sistema de banco de dados se consolidou

como pioneiro em aplicaes comerciais. A estrutura do modelo de banco
de dados relacional se constitui de coleo de tabelas. Conforme expe
[LAUDON-98] define banco de dados relacional como o modelo relacional
algo como tipo de modelo lgico de banco de dados que tratam dados como
se tivessem sido armazenados em tabelas bidimensionais. A metodologia
de consulta de dados utiliza linguagens procedurais e no procedurais e
modelos definidos por lgebra relacional. Na dcada de 1970, a IBM
desenvolveu a linguagem SQL (Structure Query Language), inicialmente
utilizado para consulta em bancos de dados relacional, esta linguagem foi
incorporada a outros construtores de bancos de dados. O sistema utiliza
uma linguagem declarativa que baseada em trs comandos bsicos: Select,
From e Where.
Banco de dados orientado objetos uma adequao ao paradigma de

programao orientada objetos, este modelo surgiu para atender as
exigncias destas aplicaes como: Banco de Dados Hipertexto, Banco de
Dados Multimdia, Office information systems (OIS), Computer-Aided
Design (CAD). Segundo [LAUDON-98], banco de dados orientado objetos
uma abordagem ao gerenciamento de dados que armazenam tanto
dados quanto procedimentos atuando sobre os dados como objetos que
podem automaticamente ser recuperados e compartilhados; os objetos
podem conter multimdia.
66
Banco de dados hierrquico uma coleo de registros conectados uns aos

outros por meio de rede de comunicao. O conjunto dos registros
organizado na forma de uma rvore estruturada em segmentos: raiz, pai e
filhos.
A figura abaixo 17 ilustra este tipo de arquitetura.
Figura 17: Estrutura de banco de dados hierrquico
Banco de dados em rede considerado uma extenso do modelo

hierrquico, uma coleo de registros conectada uns aos outros tambm
por redes de comunicao, o modelo em rede estabelece uma relao
membro-proprietrio. Segundo [LAUDON-98], define banco de dados em
rede como modelo lgico de banco que til para lidar com
relacionamentos muitos-para-muitos.
Conforme expe [SILVERSCHATZ-99], a arquitetura de um sistema de banco

de dados fortemente influenciada pelo sistema bsico computacional sobre o qual
o sistema de banco de dados executado. Este fato influencia na arquitetura dos
bancos de dados, que atualmente pode ser classificados em:
67
Sistema centralizado, caracterizados por sistemas de banco de dados que

atuam em um nico computador. Computadores pessoais e estaes de
trabalhos enquadram-se nesta categoria. Nesta configurao o front-end1 e
back-end2 so executados em um nico sistema. [SILVERSCHATZ-99]
Sistema cliente/servidor, caracterizados pelo desenvolvimento das redes de

computadores e dos protocolos de compartilhamento de recursos que
aproximaram aplicaes de front-end e back-end para estaes cliente e
servidor por meio da linguagem SQL ou de um programa de aplicao de
comunicao (Middleware).
Sistemas paralelos, caracterizados por mltiplos processadores e mltiplos

discos interconectados por redes de alta velocidade e que possuem
capacidade
elevada
de
processamento
em
relao
aos
sistemas
centralizados e cliente/servidor. O desempenho de sistemas paralelos pode

ser avaliado por meio de throughput e pelo tempo de resposta do sistema
para concluir uma tarefa especfica. Parmetros como acelerao (reduo
de tempo de execuo de uma tarefa por meio do aumento do grau de
paralelismo) e escalabilidade (manuseio de maior nmero de tarefas por
meio de aumento do grau de paralelismo) so considerados na avaliao de
sistemas paralelos. [SILVERSCHATZ-99].
Front-end consiste em ferramentas como formulrios, gerador de relatrios e recursos de interface

grfica. [SILVERSCHATZ-99].
2
Back-end executa o gerenciamento das estruturas de acesso, desenvolvimento e otimizao de

consultas, controle de ocorrncias e recuperao. [SILVERSCHATZ-99].
68
Sistemas distribudos so caracterizados pelo armazenamento de dados em

diversos computadores como um conjunto de banco de dados parciais
independentes que compartilha um esquema comum e que coordena o
processamento de transaes com acesso de dados no local. O banco de
dados em sistemas distribudos distingue-se dos sistemas paralelos pela
distncia
geogrfica que separam os componentes do sistema. Os
processadores comunicam-se uns aos outros por meio de redes de

comunicao que definem o roteamento e as estratgias de comunicao.
Neste modelo de bando de dados, fatores como replicao, fragmentao
devem ser considerados no armazenamento distribudo de dados.
Sistemas de bancos de dados distribudos robustos necessitam detectar falhas
e possuir capacidade de reconfigurao do sistema, de forma que o sistema
recupere a condio original aps restabelecimento do processamento de
informaes, isto se deve ao fato de que sistemas distribudos trabalham com
algoritmos distribudos que conseqentemente necessitam de um coordenador; caso
este coordenador venha a falhar em conseqncia de uma falha no site onde este
esteja instalado; aps o reincio do processamento, o sistema dever restabelecer as
condies de funcionamento.
No segmento de tecnologia da informao, existem atualmente bancos de
dados especficos desenvolvidos por Business Information Warehouse, destinados
ao conceito de Consumer Oriented, como o Operating Data Storage (ODS), Data
Warehouse, Data Mart, Data Mining, On-line Analytical Processing (OLAP) e
sistemas ERP (Enterprise Resource Planning); todos desenvolvidos para integrar
dados e informaes nos diversos segmentos no ambiente corporativo voltado as
necessidades especificas.
Para [BERRY-97], sistemas Data Warehouse devem ser visto como um
conjunto de dados de diferentes fontes, em um formato comum com definies
consistentes de campos e chaves, ainda conforme [BERRY-97],
que tambm
define Data Mining como explorao e anlise, por meios automticos ou

semiautomticos, de grande quantidade de dados no sentido de descobrir meios e
regras significativas.
69
Sistemas OLAP segundo [ARAUJO-07] se referem a um conjunto de

ferramentas voltadas para acesso e anlise ad hoc de dados, com o objetivo final de
transformar dados em informaes capazes de dar suporte s decises gerenciais
de forma amigvel e flexvel ao usurio e em tempo hbil.
Conforme expe [CORNACHIONE-01], com o avano da tecnologia de
informao associada ao substancial aumento da complexidade dos processos
empresariais em ambientes corporativos, a integrao dos dados das corporaes
passa a ser condio necessria para suportar as necessidades de planejamento e
decises estratgicas. Neste contexto a integrao de sistemas e dados apresentase como soluo para obteno, tratamento de informaes e dados corporativos;
tende-se a observar uma soluo que privilegia um banco de dados nico,
compartilhado pelas diversas aplicaes presentes nas empresas.
Conforme afirma [STAIR-04]1 adup [MENASCE-02] que se uma organizao
no possui dados ou a capacidade de process-los, no ter condies de obter
sucesso em grande parte de suas atividades empresariais.
STAIR, M. R. Princpios de sistemas de informao: uma abordagem gerencial. 4 edio. Rio de

Janeiro: LTC, 2004.
70
4. TECNOLOGIA DA INFORMAO
O atual panorama dos Sistemas de Informao destinados ao ambiente
corporativo resultado da evoluo dos negcios e da tecnologia aplicada com o
passar dos anos. A tecnologia da informao traz para empresas e organizaes a
capacidade de melhorar a qualidade e disponibilidade de informaes relevantes
para a produtividade, gerando eficincia aos processos.
A gesto estratgica da informao transformou-se numa parte essencial e
crtica a qualquer estrutura organizacional de sucesso. Esta gesto deve ocorrer de
forma integrada e que possibilite a insero de novas tecnologias que certamente
sero desenvolvidas.
Conforme expe [BIO-08], um sistema aberto pode ser compreendido como
um conjunto de partes em constante interao (o que ressalta um dos aspectos
fundamentais da idia de sistemas: a interdependncia entre as partes), constituindo
um todo orientado para determinados fins e em permanente relao de
interdependncia com o ambiente externo. Este conceito apresenta com
propriedade a relevante necessidade de abertura de sistemas, especificamente nos
Sistemas de Informao destinados s aplicaes corporativas; tais sistemas tornam
iminente a necessidade de reavaliao de processos para que a implementao da
TI (Tecnologia da Informao) possa proporcionar um aumento da satisfao de
usurios.
Vrios aspectos devem ser analisados para contextualizar a constituio de
organizaes corporativas, dentre as quais podem ser citados a interao entre
subsistemas que compe grande parte dos modelos de gesto corporativas, que
atualmente esto apoiados em sistemas de informao e comunicao: [BIO-08]
Sistema fsico-operacional;
Sistema de informao;
Sistema social;
Sistema de gesto.
A figura 18 a seguir apresenta a interao entre estes segmentos dentro do

contexto de sistema organizacional.
71
Figura 18: Sistema corporativo e seus subsistemas

Fonte: Adaptado de [BIO-08]
Cada um dos subsistemas do processo corporativo compe-se de uma rede de

subsistemas e processos interdependentes. Em uma empresa do segmento
industrial, por exemplo, o subsistema de Planejamento e Controle de Produo deve
interagir junto s reas de vendas, controle de materiais, estoque e expedio de
produtos, subsidiando o nvel gerencial da empresa por meio de dados e
informaes.
Conforme
expe
[BIO-08],
no
contexto
atual,
os
recursos
computacionais so imprescindveis no processo de gesto administrativa, onde o

computador um recurso transformador de dados e informaes....
A evoluo da tecnologia contribuiu tambm para o processo de fragmentao
de sistemas, ou seja, quando novos sistemas foram desenvolvidos, antigos sistemas
foram abandonados ou no foram integrados de forma correta a nova tecnologia.
Deve haver, portanto a definio e adoo de um Plano Estratgico em Tecnologia
da Informao. Segundo [SIMCSIK-02], que define MIS (Management Information
System) como todo o processo metodolgico de coleta de dados e gerao de
informao, comunicadas para os nveis gerenciais e de direo da empresa, que os
utilizam nos processos decisrios e nas comunicaes organizacionais.
Os Sistemas em Informao podem ser classificados em dois principais
grupos: [BIO-08]
72
Sistemas de apoio s operaes;

Processos de transaes;
Tomada de decises direcionadas operao.
Sistemas de apoio gesto.

Tomada de decises estratgicas.
Segundo [SIMCSIK-02] dentro das empresas existem dois tipos de

processamento de informaes. Um baseia-se em transaes e utilizado
operacionalmente, o outro trabalha com sistemas de apoio s decises. Os
sistemas de apoio s decises operam atualmente com uma tecnologia que j existe
h um bom tempo e que agora ganha fora impulsionada pela evoluo do hardware
e software. Trata-se do conceito denominado Data Warehouse, no qual as
informaes so preparadas para o uso de pessoas que tomam decises.
O ambiente de Data Warehouse integra informaes provenientes de uma
grande variedade de bancos de dados operacionais em um nico banco de dados
lgico, que pode ser visto com um repositrio central desenvolvido para facilitar o
processo de suporte deciso. Sistemas reduzidos de Data Warehouse so
definidos por Data Marts, tendo sido concebidos para aplicaes especficas de
armazenamento e anlise de dados. [SIMCSIK-02]
Dada diversidade de solues de sistemas de informao, especialmente as
empresariais, a base de sustentao pelo mbito da Tecnologia da Informao pode
ser composta por vrios grupos, dos quais se destaca hardware, software, banco de
dados e telecomunicaes.
A figura 19 a seguir apresenta estes quatro componentes dentro do contexto
da Tecnologia da Informao.
73
Figura 19: Tecnologia da informao e sistemas de informao

Fonte: Adaptado de [BIO-08]
Conforme expe [SIMCSIK-02], analisando o mbito industrial, o controle do

sistema industrial implica em um sistema de informaes qualificado, com
ferramentas de assistncia tomada de decises, que devem proporcionar:
Sistema de planejamento a longo e mdio prazo, incorporando o mximo de

informaes, relacionando vendas provisionais e capacidade de produo;
Planejamento em curto prazo e sistema provisional para organizar a

fabricao;
Ferramentas de consulta em tempo real aos dados do sistema produtivo;
Anlise estatstica e ferramentas de simulao para situaes envolvendo

mltiplos parmetros e que requerem rpida tomada de decises.
Segundo [WANG-98], expe que a informao tecnologia pode ser a maior

ferramenta dos tempos modernos, mas o julgamento de negcios dos humanos
que a faz poderosa.
74
4.1 Novell
O sistema operacional NetWare, da empresa Novell, considerado um dos
primeiros sistemas operacionais de rede a serem implementados em larga escala. O
sistema foi desenvolvido como sistema operacional proprietrio em 1983.
A concepo do sistema NetWare possibilita que o mesmo possa ser
implementado em redes com configurao token-ring, estrela e barramento. Os
servidores Netware provm servios a seus usurios como: arquivo, impresso,
mensagens, aplicao e banco de dados. Para ter acesso aos recursos clientes
NetWare enviam GNS (GetNearestServer) para localizar o Servidor, que
estabelecem comunicao e confeccionam tabela SAP (Service Advertising
Protocol), com recursos disponveis. A figura 20 abaixo ilustra esta comunicao.
Figura 20: Comunicao entre cliente e servidor com Novell

Fonte: Adaptado de [DIOGENES-01]
Desde a concepo do sistema operacional Netware, a Novell desenvolveu

solues para comunicao para o sistema operacional baseado nos protocolos
proprietrios SPX (Sequenced Packet Exchange) e IPX (Internetwork Packet
Exchange). Estes protocolos serviram de bases para outras solues para redes,
como o Windows NT. A figura 21 a seguir ilustra estes protocolos.
75
Figura 21: Modelo Novell x Modelo OSI

Fonte: Adaptado de [DIOGENES-01]
O protocolo IPX utilizado pela Novell e atua na camada de rede, fornece um

servio de datagrama no orientado conexo a seus usurios, isto , seus pacotes
so transmitidos sem que seja necessrio estabelecer conexes e no so
reconhecidos pelo destinatrio.
Conforme expe [DIOGENES-01], o IPX define a inter-rede e o endereo dos
ns baseados nos nmeros de rede que so atribudos a cada segmento de rede.
Os endereos IPX so constitudos por trs componentes: o endereo da rede onde
esta conectada a estao, o endereo da estao na rede e o endereo de uma
porta (socket) que identifica o processo que esta executando na estao que enviou
ou que ira receber o pacote.
O IPX implementa um esquema de roteamento inter-redes baseado em tabelas
de rotas localizadas nos gateways. O frame IPX pode ser encapsulado para trafegar
nos meios: Ethernet, Token Ring e FDDI (Fiber Distributed Data Interface); a figura
22 abaixo ilustra os tipos de encapsulamentos existentes para Ethernet.
76
Figura 22: Encapsulamentos existentes para IPX

Fonte: [DOWNES-98]
O protocolo SPX da arquitetura NetWare um protocolo orientado conexo,

atua no nvel de transporte. O protocolo implementa servio de circuito virtual, ou
seja, mecanismos de controle de erros, de fluxo e de sequenciao; o protocolo
capaz de supervisionar as transmisses de dados informando ao operador a falha
em retransmisses.
O SPX utiliza algoritmo sliding window para controle de erros e de fluxo, a
figura 23 ilustra este controle de fluxo por meio deste algoritmo, que realiza o
controle de erros por meio de janelas deslizantes.
Figura 23: Sliding Window - controle de fluxo em protocolo

77
A concepo da rede Novell Netware esta baseada no modelo cliente-servidor;

inicialmente o conceito deste sistema foi atuar como suporte de servidor de arquivos,
conforme expe [FOROUZAN-06], o software do servidor de arquivos Netware
reside na camada de aplicao, tendo como parmetro o Modelo de Referncia OSI.
A Novell foi a primeira empresa a lanar um sistema operacional de rede para
compartilhamento real de arquivos [DERFLER-95].
A figura 24 abaixo ilustra a interface do servidor Netware com rede, utilizando
em sua concepo de 1986, comandos em DOS (Disk Operating System).
Figura 24: Interface Shell da rede Novell

Fonte: [SCHATT-93]
O Novell NetWare oferece sistema de segurana para servidor de arquivos de

quarto formas diferentes: [SCHATT-93]
O procedimento de acesso (login), onde o controle de acesso realizado

por nome e senha vlida do usurio;
Os direitos de sndico, o administrador da rede estabelece direitos de

acesso personalizado para cada usurio, definido a partir de ento como
sindico, em funo das necessidades quanto aos recursos disponveis na
rede;
Os direitos de diretrios;
78
Os atributos de arquivos, onde a rede NetWare possibilita que usurios

definidos executem alteraes de arquivos.
Os sistemas de tolerncia a falhas (STF System Fault Tolerance) possuem

funes de proteo dispostos em trs nveis caso ocorram falhas no servidor de
arquivos: [SHELDON-93]
STF nvel I (Hot fix);
STF nvel II (Disk mirroring/Disk duplexing);
STF nvel III (Server duplexing).
O sistema operacional de rede Novell NetWare possui duas formas de

apresentao aos usurios: [CUSTODIO-95]
NetWare Life, que pode ser instalado em todos os dispositivos da rede,

onde todas as estaes podem desempenhar funes de cliente e servidor
simultaneamente, caracterizando a arquitetura peer-to-peer;
NetWare v2.x, v3.x, v4.x, a serem instalados em estaes servidores e

estaes
clientes,
caracterizando
arquitetura
cliente/servidor,
estabelecendo desta forma o compartilhamento dos recursos de rede.
4.2 SNA
A arquitetura SNA (Systems Network Architecture), foi anunciada em 1974 para
comunicao de dados em sistemas de larga escala. O SNA sofreu processo
evolutivo para acomodar as redes de computadores, que passou a incluir suporte
para redes peer-o-peer e outros meios de protocolos de comunicao padronizados
como Ethernet, FDDI, frame relay, entre outros.
O modelo SNA uma coleo de componentes de hardware e software
integrados para criar uma rede funcional. A quantidade e o tipo de hardware e
software instalado definem a funcionalidade da rede SNA.
Esta arquitetura foi uma soluo desenvolvida pela IBM para a evoluo
continua que sofrem os produtos de comunicao de dados, tanto em hardware
como software; isso se deve a necessidade de padronizao de uma linha de
produtos, sem levar em considerao que a IBM estava focando uma conectividade
79
universal entre seus produtos, para que houvesse ideal compartilhamento de

recursos, sem necessidade de reconfigurao da instalao. Antes da soluo SNA,
os terminais de usurios de sistemas mainframe eram conectados diretamente a
programas de aplicativos especficos no computador central. A arquitetura SNA o
principal mecanismo de comunicao de dados para computadores desenvolvidos
pela IBM, utilizado em aplicaes de larga escala, o SNA um modelo de referncia
que define como que os sistemas de informao podem transportar dados.
A figura 25 abaixo ilustra as operaes fundamentais do modelo SNA,
comparando-as aos nveis definidos pelo Modelo de Referncia OSI. [DOMINGUES02]
Figura 25: Modelo de Referncia OSI e arquitetura SNA

Fonte: Adaptado de [DOWNES-98]
Conforme expe [DOMINGUES-02], o SNA consiste de:
Uma arquitetura que define regras e responsabilidades de entidades de

comunicao dentro de uma rede;
Uma especificao de protocolo, que define os formatos e fluxos de

mensagens dentro dessas entidades.
SNA baseia-se nos seguintes conceitos fundamentais:
SNA uma rede hierrquica (master-slave)
SNA utiliza rotas pr-definidas para transportar dados;
ACF/VTAM (Access Control Field / Virtual Telecommunications Access

Method) o master da rede.
80
SNA uma arquitetura que habilita comunicao entre unidades endereveis

de rede. A comunicao tradicional do SNA envolve quatro entidades fsicas: Host,
Front-end Processor, controladores de Cluster e Terminais.
Conforme expe [DOMINGUES-02], o conceito de redes hierrquicas obedece
existncia de dois elementos na arquitetura, uma entidade principal, definida por
master e as entidades secundrias, denominadas por slave. A arquitetura
tradicional SNA centraliza o processamento, com caractersticas determinsticas no
trfego de dados na rede.
A figura 26 abaixo ilustra a arquitetura SNA.
Figura 26: Modelo Rede SNA

Fonte: Adaptado de [DOMINGUES-02]
Na arquitetura SNA, utilizado Classe de Servio, definida por COS (Class of

Service) para assegurar caractersticas de prioridade de transmisso de dados,
possibilitando tempo de resposta de alta prioridade.
A COS SNA designa as caractersticas do servio de transporte de rede de
uma determinada sesso e em funo das necessidades do usurio, diferentes
COSs podem ser especificadas em uma rede SNA. A COS fornece o mecanismo
para determinar todas as rotas SNA e descreve os nveis de servio aceitveis para
81
uma sesso e especifica tambm a coleo de sesses caractersticas, incluindo o

tempo de resposta, segurana e disponibilidade. [DOMINGUES-02]
O gerenciamento de redes na arquitetura SNA realizado por meio do sistema
NetView, que foi inserido em 1986; constituda por uma estrutura de
gerenciamento desenvolvida pela IBM para o gerenciamento de redes de
computadores com grande capacidade de processamento, com base no protocolo
de gerenciamento SNMP (Simple Network Management Protocol). O NetView
capaz de obter gerenciamento de dados solicitados como dados no solicitados,
permitindo monitorar, controlar e reconfigurar redes SNA.
O
roteamento
de
SNA
tradicional
realizado
por
VTAM
(Virtual
Telecommunications Access Method) no mainframe, devido a incompatibilidades

com fornecedores de roteadores, a IBM adequou a estrutura de roteamento por meio
da Comunicao No Hierrquica Avanada, definida por APPC (Advanced
Program-to-Program Communication). A capacidade de roteamento no APPC
conhecida como Formao de Rede No Hierrquica Avanada APPN (Advanced
Peer-to-Peer Networking). [BENNETT-98a]
O roteamento SNA realizado pelo APPN IBM Advanced Peer-to-Peer
Networking Routing, que uma arquitetura peer IBM que apia a comunicao de
servios de roteamento em sistemas APPC (Advanced Program-a-Program
Comunnications). Conforme expe [DOWNES-98], o roteamento dinmico e esta
baseado em um caminho de peso mnimo estabelecido a partir de sugestes
recebidas de todos os ns de rede APPN. Cada n da rede APPN responsvel por
informar alteraes em sua topologia local (isto , o prprio n e os links em anexo).
A informao de topologia transmitida at que todos os ns APPN possam receblos. Quando um n recebe informaes que j possui, este interrompe a transmisso
de dados para outros ns e informaes duplicadas so reconhecidas por meio de
um sistema de verificao.
O Roteamento de Alto Desempenho, (HPR - High Performance Routing) uma
extenso da arquitetura APPN. Constitudo de um conjunto de melhorias para
melhorar o roteamento de dados APPN, aumentar a confiabilidade, facilitar a
compatibilidade e migrao, o HPR proporciona funcionalidade adicional pelos
componentes: [DOMINGUES-02]
82
RTP
(Rapid
Transport
Protocol),
protocolo
orientado
conexo,
desenvolvido para redes de alta velocidade, com baixas taxas de erro;
ANR
(Automatic
Networking
Routing),
algoritmo
desenvolvido
para
roteamento em redes de alta velocidade; por meio de rpida comutao de

pacotes, o algoritmo elimina o armazenamento em ns intermedirios de
uma conexo, reduzindo tempo de roteamento.
As redes baseadas em SNA podem ser integradas a outras tecnologias de
redes, como o TCP/IP.
Conforme aborda [DOMINGUES-02], os protocolos de rede tem sido
determinados pelas aplicaes escolhidas pelas organizaes, fato que tem levado
a uma inevitvel propagao de protocolos de rede. Visto que arquiteturas de redes
possuem comportamentos diferentes em situaes adversas, o desempenho e
aspectos para integrao devem ser analisados sob aspectos especficos. Ainda
conforme [DOMINGUES-02] prope que a analise de integrao seja analisada
considerando: perdas de comunicao, perda de frame de dados e retransmisso de
frames recebidos de forma incorreta.
A tabela 03 abaixo apresenta comparao entre redes SNA e TCP/IP.
Tabela 03: Comparao de arquiteturas de redes SNA e TCP/IP
Parmetro
TCP/IP
Definio
Pr-definio.
Roteamento Rotas pr-definidas.
Integridade
Priorizao
Overhead
Garantida pela rede e pela

camada de transporte;
Capacidade de gerar resposta
definida.
Tabelas de classes de servio;
Prioridade baseada em sesso.
N de roteamento = 29 bytes;
N perifrico = 9 bytes
SNA
Topologia dinmica
Rotas so dinamicamente determinadas;
Roteamento determinado por diversos tipos de
algoritmos.
Determinao de erros no ponto final da
transmisso;
Baseada em datagramas, sem recuperao nas
camadas de rede e transporte.
Sem priorizao,
Priorizao de roteamento em alguns roteadores,
44 bytes de header.
Fonte: Adaptado de [DOMINGUES-02]
A integrao entre SNA e TCP/IP pode ocorrer de vrias formas por meio de
solues disponveis no mercado atuando em diversos nveis na arquitetura de
83
comunicao, entretanto, o roteamento apresenta-se como forma vivel de

integrao devido aos protocolos desenvolvidos, apesar de causar aumento de
overhead; o TCP/IP utiliza para roteamento os protocolos RIP (Routing Information
Protocol) e OSPF (Open Shortes Path First), a arquitetura SNA dispe dos
protocolos de roteamento VTAM e NCP.
4.3 Ethernet
A Ethernet esta enquadrada nas tecnologias de redes locais LAN (Local Area
Network), sendo uma das redes mais bem sucedida dos ltimos anos, caracterizada
tambm como o padro de rede mais utilizada para a transmisso de dados em
redes corporativas. A simplicidade foi um dos principais motivadores do sucesso
desta rede, que foi pioneira a sugerir a utilizao de um meio compartilhado para
acesso s redes. [OLIFER-08]
Vrios outros fatores so associados ao xito desta arquitetura de rede,
[ROSS-06] enfatiza a velocidade da rede Ethernet de alta velocidade e
complexidade das tecnologias existentes, como token ring, FDDI (Fiber Distributed
Data Interface) e ATM (Assynchronous Transfer Mode), que alm de complexas
eram mais onerosas.
A flexibilidade da arquitetura Ethernet devido ampla divulgao, possibilitou o
conhecimento da estrutura dos protocolos que compem a arquitetura, tornando-o
um padro acessvel e passvel de implementaes, apresentando grande
viabilidade quanto adoo do padro Ethernet. Conforme expe [OLIFER-08],
sobre sistemas abertos, que define tais sistemas como qualquer sistema, seja
computador isolado, uma rede de computadores, um sistema operacional, um
aplicativo ou qualquer outro hardware ou software; constitudo de acordo com as
especificaes abertas, onde tais especificaes, aps amplamente divulgadas e
disponibilizadas, sendo submetidas a uma ampla e diversificada discusso.
Dentro deste contexto, pode-se considerar a Ethernet, um sistema aberto bem
sucedido, pela participao de instituies acadmicas, institutos de pesquisa e
corporaes no desenvolvimento e aprimoramento do padro, e pela aceitao dos
usurios. Ainda, conforme expe Robert M. Metcalfe, a tecnologia Ethernet
84
transformou os PCs de unidades de processamento de dados em dispositivos de

comunicao. [HANCOCK-03]
A figura 27 ilustra o projeto original da Ethernet desenvolvido por Robert
Metcalfe e David Borges na dcada de 1970. [ROSS-06]
Figura 27: Projeto original da Ethernet

Fonte: [ROSS-06].
O surgimento e desenvolvimento das redes Ethernet ocorreram nos

laboratrios da Xerox (Palo Alto Reserch Center) e da Intel, em 1976. Tendo sida
desenvolvida originalmente por Robert Metcalfe e David Boggs, o sistema
desenvolvido ento foi definido como Ethernet, em referncia ao ter luminoso,
atravs do qual os antigos diziam que a radiao eletromagntica se propagava.
(Fsico
britnico
James
Maxwell,
sculo
XIX
descobriu
que
radiao
eletromagntica podia ser descrita por uma equao de onda).

Em 1978, a Digital Equipament Corporation (DEC) e a Intel Corporation uniramse Xerox para definir o padro Ethernet DIX V1.0, que operava a velocidade de
2,94 Mbps. Os procedimentos utilizados para a elaborao do padro foram
divulgados numa publicao conhecida por Livro Azul da Ethernet. [HANCOCK-03]
Como continuidade deste desenvolvimento, foi elaborado o padro cooperativo
Ethernet Verso 2.0, que contribuiu para formar a base para o padro 802.3.
Conforme expe [HANCOCK-03], as duas especificaes, Ethernet V2.0 e IEEE
802.3 so similares, visto que o IEEE utilizou as detalhes tecnolgicos da Ethernet
V2.0 como base para o padro 802.3, porm, existem as diferenas entre os
padres, tornam-os incompatveis entre si, tais como cabos, diferenas entre
85
funes de transceptores, formato de quadros. Utilizando um mtodo de acesso para

gerenciar demandas simultneas, este padro difundiu-se como a tecnologia mais
utilizada em ambientes corporativos, evoluiu para um protocolo utilizado em mais de
85% das conexes instaladas. [ROSS-06]
A rede Ethernet foi oficialmente aceita como padro em 1985, definido no IEEE
802.3 (Institute of Electrical and Electronics Egineers), que operava a taxa de 10
Mbps, atualmente as redes Ethernet operam a taxas de transmisso de at 10 Gbps.
A normatizao IEEE 802.3, definiu a camada fsica e de software para a rede local
LAN. A tabela 04 abaixo apresenta os principais grupos para a normatizao do
padro IEEE 802.
Tabela 04: Grupos de trabalhos normatizao padro IEEE 802.
Padro
802.1
802.2
802.3
802.4
802.5
802.6
802.7
802.8
802.9
802.10
802.11
802.12
802.13
802.14
802.15
802.16
802.17
Especificao
Avaliao e arquitetura de LANs
LLC (Logical Link Control) Controle de link lgico
Ethernet
Token bus
Token Ring (anel de smbolos - representa entrada da empresa IBM nas LANs)
Fila Dual / Barramento Dual (primeira rede metropolitana)
Grupo tcnico consultivo para tecnologias de banda larga
Grupo tcnico consultivo para tecnologias de fibra ptica
LANs iscronas, para aplicaes de tempo real
LANs virtuais e segurana
LANs sem fio (Wireless Networks)
Prioridade de demanda (AnyLAN da Hewlett Pachard)
Vago, nmero no utilizado.
Modens a cabo, acabou extinto (consrcio industrial conseguiu chegar primeiro)
Redes pessoais, Bluetooth.
Radio de banda larga
Anel de pacote elstico
O padro 802.11, que trata as redes Wireless, sob nome comercial de WiFi,
oferece diversos produtos no mercado, dedicados dispositivos mveis; o padro
802.15 tambm engloba o ZigBee, destinado ao fornecimento de comunicao de
dados para equipamentos domsticos de largura de banda baixa com baixas
potencias; o padro 802.16, com denominao comercial de WiMax, foi ratificado em
2004/2005 como alternativa para os enlaces a cabo e DSL (Digital Subscriber Line)
para aplicao em residncias e escritrios. [COULOURIS-07]
86
Conforme expe [OLIFER-08], atualmente a Ethernet engloba as tecnologias

Token Ring, FDDI (Fiber Distributed Data Interface), IEEE 802.11, entre outras, onde
todas estas tecnologias, apesar de terem caractersticas especficas, destinam-se a
construo de redes LANs. Entretanto, na ocasio do desenvolvimento inicial das
tecnologias de redes locais (LANs), a integrao com redes de longa distncia WAN
no foi tratada como prioritria, desta forma, as redes LANs implementam somente
as funes descritas para as duas camadas mais baixas do modelo OSI, ou seja,
camada fsica e camada de enlace de dados; a figura 28 ilustra esta
correspondncia.
Figura 28: Correspondncia entre protocolos modelo OSI e protocolos LAN

Fonte: [OLIFER-08]
Esta caracterstica inicial ocorreu devido funcionalidade destas duas

camadas atenderem os requisitos para entrega dos quadros na topologia de padres
LAN. Contudo, posteriormente a Ethernet foi integrada a arquitetura TCP/IP
(Transmission Control Protocol/Internet Protocol), caracterizada como rede WAN,
que enfatiza a interligao de redes de tecnologias heterogneas formando uma
inter-rede.
Os frames definidos pela norma IEEE 802.3 e o padro elaborado pela Intel,
Digital e Xerox possuem diferenas, conforme ilustra a figura 29 a seguir.
87
Figura 29: Formato Frame Ethernet DIX V1.0 e IEEE 802.3

Fonte: Adaptado de [TANENBAUM-03] e [PETERSON-04]
A constituio do quadro Ethernet (formato frame padro Ethernet Xerox, Intel

e Digital), conforme figura 29, mostra prembulo de 64 bits, permite que o
equipamento receptor seja sincronizado com o sinal, sendo uma seqncia de 0 e 1
alternados. Os hosts de origem e destino so identificados por um endereo de 48
bits. O campo de tipo de pacote serve como uma chave de demultiplexao,
identificando os possveis protocolos de nvel mais alto no qual este quadro dever
ser entregue. Cada quadro contm at 1500 bytes de dados. No mnimo, um quadro
precisa conter pelo menos 46 bytes de dados, mesmo que isso signifique que o host
deve completar o quadro antes de transmiti-lo. O motivo para esse tamanho mnimo
do quadro que ele precisa ter tamanho suficiente para detectar uma coliso.
[PERTERSON-04].
As divergncias quanto ao padro IEEE 802.3 e a proposta DIX elaborada pelo
consrcio Xerox, Intel e DEC levaram ao surgimento de variantes do frame Ethernet,
sendo: [OLIFER-08]
Segunda variante - 802.3/LLC (802.3/802.2 ou Novell 802.2);
Terceira variante - Raw 802.3/Novell 802.3;
Quarta variante - Ethernet SNAP (SNAP Subnetwork Access Protocol).
Os formatos das variantes do frame Ethernet so ilustrados na figura 30.
88
Figura 30: Variantes do Frame Ethernet

Fonte: [OLIFER-08]
A partir da dcada de 1980, o Comit IEEE 802 padronizou as tecnologias de

redes LAN, baseado nos padres IEEE 802.x, conforme ilustra a figura 31 e tabela
04. A primeira verso do padro IEEE 802.3, foi publicada em 1985, tendo como
ttulo formal IEEE 802.3 Carrier Sense Multiple Access with Colision Detection
Access Method and Physical Layer Specifications.''
89
Figura 31: Estrutura dos padres IEEE 802.x

Fonte: [OLIFER-08]
Ainda,
conforme
[OLIFER-08],
vrios
outros
grupos
participaram
da
padronizao dos protocolos LAN, como o ANSI (American National Standards

Institute), desenvolvedor do padro FDDI (Fiber Distributed Data Interface), definindo
em 1986 o padro ANSI X3T9.5, utilizado para interconexo de sistemas de
computadores em rede de topologia em anel de fibra, com taxas de transmisso de
100 Mbps. A relao de especificaes que atendem ao IEEE 802.1 continua a
ganhar novos padres, recentemente, foram incorporados o 802.1Q que define
modelos para LANs virtuais; o 802.1p, que determina os modelos de priorizao de
trfego, oferecendo suporte para aplicaes de QoS (Quality of Service).
A tabela 05 a seguir apresenta relao das principais especificaes.
90
Tabela 05: Novas especificaes IEEE 802.
Padro
IEEE 802.P
IEEE 802.12d
IEEE 802.3x
IEEE 802.3z
Funo
Priorizao de mensagens
Redundncia de Links
Full duplex
Gigabit Ethernet
Observao
256 nveis de prioridade
Maior confiabilidade para a rede
Comunicao bidirecional simultnea
Utilizado como backbone corporativo
Conforme expe [OLIFER-08], inicialmente, as redes Ethernet foram criadas

com base em cabos coaxiais, posteriormente, com o desenvolvimento de outros
meios fsicos para transmisso; foram elaboradas especificaes que atendem a
estes meios de transmisso para a rede Ethernet 10 Mbps, em funo da distncia e
meio fsico. As principais implementaes so ilustradas na tabela 06, sendo:
Tabela 06: Caractersticas de meio de transmisso IEEE 802.3 Ethernet 10 Mbps
Rede
10Base5
10Base2
10Base-T
10Base-F
10Broad 36
Meio
Baseband coaxial grosso
Baseband coaxial fino
Baseband par tranado
Baseband fibra ptica
Broadband
Distncia (m)
500
185
100
Varivel
3600
Fonte: Adaptado de [OLIFER-08]
O padro Ethernet 10 Mbps atendeu aos principais requisitos para transmisso

de dados por muitos anos, porm, a partir dos anos 90, com o aumento das taxas de
velocidade dos barramentos internos dos computadores, que superaram 1000 Mbps,
tornou-se necessrio o surgimento de novas tecnologias Ethernet para atender a
esta nova demanda, culminando com o surgimento da Fast Ethernet.
Em 1993, a organizao FEA (Fast Ethernet Alliance), props a adoo do Fast
Ethernet como padro ao IEEE. A organizao FEA contava com fabricantes como
Intel, SynOptics, 3Com, Sun Microsystems, entre outros. O padro proposto foi
definido como 802.3u, especificado por 100Base-T.
As especificaes de meio para o padro Fast Ethernet (100 Mbps) so
ilustradas na tabela 07.
91
Tabela 07: Caractersticas de meio de transmisso IEEE 802.3u Ethernet 100 Mbps.
Rede
Meio
100Base-TX UTP EIA/TIA Cat. 5 / STP IBM tipo 1
100Base-T4 UTP EIA/TIA Cat. 5 / STP IBM tipo 1
100Base-FX Fibra multmodo 62,5/125
Distncia (m)
100
100
412 - 2000
Fonte: Adaptado de [HANCOCK-03]
O padro IEEE 802.3u (Fast Ethernet 100Base-T) manteve o CSMA/CD para o

acesso ao meio de transmisso, mantendo portando compabitilidade com a Ethernet
Convencional 10 Mbps, porm, a coalizo formada pela HP e AT&T defendiam
novos mtodos de acesso ao meio, definido o mtodo de prioridade por demanda,
similar padro token ring (IEEE 802.5).
O padro proposto pela HP e AT&T, denominado 100VG-AnyLAN foi definido
em 1995 como IEEE 802.12, entretanto apresenta incompatibilidade com padro
Fast Ethernet IEEE 802.3u. O protocolo proposto pelo padro 100VG-AnyLAN define
prioridade por demanda, especifica como os hubs disponibilizam suas portas para
identificar os ns com dados para transmitir e a ordem das transmisses.
[HANCOCK-03]
A tabela 08 apresenta resumo comparativo entre padres IEEE 802.3u (Fast
Ethernet) e IEEE 802.12 (100VG-AnyLAN).
92
Tabela 08: Comparao entre IEEE 802.3u e IEEE 802.12
Meio
UTP categoria 3
UTP categoria 4
UTP categoria 5
UTP de 25 pares
Meio
STP IBM Tipo 1
Fibra ptica (62,5/125)
Topologia
Dimetro da rede
Repetidoras em cascata
Subcamada MAC
Acesso ao meio
Quadros IEEE 802.3
Quadros IEEE 802.5
Suporte a aplicaes
Dados sensveis
passagem de tempo
Desempenho
Taxa de transferncia de
100 m
Taxa de transferncia de
2500 m
IEEE 802.3u
IEEE 802.12
4 pares (100 m) - 100Base T4

4 pares (100 m) - 100Base T4
2 pares (100 m) - 100Base TX
4 pares (100 m)
4 pares (100 m)
2 pares (no
disponvel)
4 pares (200 m)
Suporte
4 pares (100 m) - 100Base T4

Sem suporte
Sim (100 m) - 10Base - T4 / TX
412 m duplex parcial - 100Base-FX
2 km duplex completo - 100Base-FX
Sim (100 m)
Sim (200 m)
Varia de 200 m a 320 m

dependendo do tipo de cabo e das
repetidoras
Dois nveis
8 km
CSMA/CD
Cinco nveis
Sim
No
Prioridade de
demanda
Sim
Sim
No
Sim
80%
95%
Sem suporte
80%
O padro IEEE 802.12, possui caractersticas determinsticas, livre de colises,

utiliza com eficincia a largura de banda com estabilidade, entretanto, apesar destas
caractersticas, no foi enquadrado como uma rede Ethernet, onde foi definida outra
designao para enquadr-lo (802.12) por no utilizar o meio de acesso CSMA/CD
(Carrier Sense Multiple Access/Collision Detection). Conforme expe [HANCOCK03]; o processo de consulta e determinao da ordem de transmisso dos dados,
denominado de arbitragem cclica priorizada, o corao do protocolo de prioridade
por demanda, que desempenha a funo de controlar e tomar decises quanto ao
acesso das estaes ao meio compartilhado. A partir de 1996, o IEEE elaborou
93
grupo de estudo para elevar as taxas de transmisso do Fast Ethernet, o Grupo de

Estudos de Alta Velocidade (HSSG Higher Speed Study Group) conduziu estudos
com objetivo de elevar as taxas de transmisso a 1000 Mbps, definindo a Gigabit
Ethernet Alliance (GEA), que rapidamente atingiu mais de 100 membros aps seis
meses de criao. [HANCOCK-03]
Como resultados destes estudos foram elaborados dois padres para a Gigabit
Ethernet, o IEEE 802.3z, tendo como meio fsico a fibra ptica e o IEEE 802.3ab,
que focou o cobre como meio para transmisso. Em 1998, o padro IEEE 802.3z foi
aprovado e em 1999 o IEEE 802.3ab foi confirmado como padro. A conduo de
grupos de desenvolvimentos distintos ocorreu para atender tecnologias diferentes,
conforme ilustra a figura 32 abaixo.
Figura 32: IEEE 802.3z e IEEE 802.3ab

A tabela 09 apresenta resumo comparativo entre os trs grupos de redes

Ethernet: a Convencional (10 Mbps), Fast Ethernet (100 Mbps) e Gigabit Ethernet
(1000 Mbps).
94
Tabela 09: Resumo comparativo: Ethernet convencional, Fast Ethernet e Gigabit

Ethernet.
Taxa de dados
UTP categoria 5
STP IBM tipo 1
Fibra multmodo
Fibra modo nico
Comprimento mximo por segmento

Ethernet Convencional
Fast Ethernet
10 Mbps
100 Mbps
100 m
100 m
500 m
100 m
2 Km
412 m - duplex parcial
2 Km - duplex completo
25 Km
20 Km
Gigabit Ethernet
1000 Mbps
100 m
25 m
260 - 550 m
3 Km
O padro Ethernet Convencional requer um tempo mximo de 1,2

milissegundos para a transmisso de um frame de 1518 bytes. Atualmente, esse
tempo pode ser reduzido a 12 microssegundos utilizando Gigabit Ethernet. No
entanto, as possibilidades para Ethernet a 10Gbit/s j esto sob considerao, onde
um pacote pode ser transmitido dentro de 1,2 microssegundos. A Ethernet Gigabit
admite utilizao de cabos de cobre e de fibra ptica, para as derivaes do padro,
conforme apresenta a tabela 10.
Tabela 10: Meio fsico para Ethernet Gigabit
1000Base-SX
Meio
Fibra de
multmodo (50 /
62,5 mcron)
Tamanho mximo de
segmento
550 metros
1000Base-LX
Modo nico (10
mcron) ou
multmodo (50 /
62,5 mcron)
1000Base-CX
1000Base-T
Par tranado
blindado
UTP padro
da categoria 5
500 metros
25 metros
100 metros
O conceito principal dos desenvolvedores da Gigabit Ethernet foi manter as

caractersticas essenciais da Ethernet Convencional, portanto a Gigabit Ethernet no
oferece suporte direto a QoS (Quality of Service) para isto, o IEEE inseriu dois
protocolos para a camada de enlace, o IEEE 802.3p e o IEEE 802.3q. O IEEE
802.3p define um esquema de prioridade de 03 bits com oito nveis de prioridade,
que atende aos padres 802.4, 802.5 802.6 e 802.12. Para definio de prioridade
no padro IEEE 802.3 (Ethernet) o IEEE 802.q fornece priorizao de dados que
pode ser configurado e ativado pelo usurio.
95
Conforme expe [HANCOCK-03], outro protocolo relacionado com esse

conceito o controle de fluxo IEEE 802.3x duplex completo, que possibilita que
portas de chave duplex completo enviem comandos de controle de fluxo para
estaes de trabalho a elas conectadas. Estendendo esse conceito s camadas
superiores, o IETF (Internet Engineering Task Force) desenvolveu o RSVP
(Resource Reservation Protocol) que opera na camada 03 e permite que nos
terminais reservem uma quantidade especifica de largura de banda atravs de uma
rede IP para uma transmisso particular.
A figura 33 ilustra os frames IEEE 802.3 e IEEE 802.3q.
Figura 33: Frames IEEE 802.3 e 802.3q

O padro Ethernet um meio compartilhado, onde a ocorrncia de disputa

para transmisso de dados inerente; a definio de priorizao de trfego, remete
a Qualidade de Servios (QoS) que implementada de forma correta, assegura que
todas as transmisses sejam entregues. Conforme expe [DONAHUE-08], a
implantao da QoS ocorre inicialmente por meio da marcao de pacotes,
posteriormente o controle e finalmente a programao destes pacotes. A marcao
refere-se a decidir que prioridade deve possuir; o controle esta relacionado as
medidas tomadas pelo roteador e a programao se refere a interface que esta
atendendo os pacotes, ou seja, na ordem determinada pela prioridade definida.
96
A Gigabit Ethernet possibilita redes comutadas, roteadas e compartilhadas.

Todas as tecnologias de interconexo atuais, como IP switching e Layer 3 switching,
so completamente compatveis com Gigabit Ethernet e Fast Ethernet. Portanto, a
escolha de Gigabit Ethernet como uma rede de alta velocidade, no restringe a
escolha da tecnologia de interconexo ou a topologia da rede.
A Ethernet utilizada no ambiente Industrial executa a transmisso de dados
crticos e dados rotineiros, distinguindo e priorizando-os conforme tipo de servio,
assegurando a eficcia da transmisso. O switch industrial utilizado na Ethernet
assegura confiabilidade e determinismo para processos produtivos, evitando que
CLPs e outros dispositivos processem informaes desnecessrias, priorizando o
trfego crtico em tempo real comparado s mensagens menos importantes,
assegurando o controle em tempo real do processo produtivo e postergando as
transmisses configuradas como secundrias.
4.4 TCP/IP
A DARPA (Defense Advanced Reserarch Projects Agency) iniciou os trabalhos
em direo a uma tecnologia de interconexo de redes em meados da dcada de
1970, com a arquitetura e os protocolos tomando forma entre 1977 e 1979,
entretanto, os primeiros passos para a definio de uma rede de comunicao
iniciaram-se na dcada de 1960. Estudos conduzidos no MIT (Massachusetts
Institute of Technology), no Rand Insititute e no National Physical Laboratory
forneceram os alicerces para a atual Internet. [ROSS-06]
Na dcada de 1970, a DARPA era reconhecida como a principal agncia
financiadora de pesquisa de redes de comutao de pacotes com a ARPANET, que
inicialmente era uma rede fechada.
A partir de meados da mesma dcada iniciaram novas redes de comutao por
pacotes: ALOHAnet, Telenet, Cyclades, SNA. [ROSS-06]
Conforme expe [COMER-06], a Internet global comeou por volta de 1980,
quando a DARPA iniciou processo de converso de computadores conectados s
redes de pesquisa aos recm-desenvolvidos protocolos TCP/IP; a transio para a
tecnologia de Internet foi concluda em 1983, momento em que a Secretaria de
Defesa dos Estados Unidos determinou que todos os computadores de redes de
97
longa distncia utilizassem os protocolos TCP/IP; simultaneamente, a DCA (Defense

Communication Agency) dividiu a ARPANET em duas redes distintas: uma destinada
pesquisa e outra com a finalidade de comunicao militar.
A DARPA, por meio de uma poltica extensiva de divulgao, disponibilizou os
protocolos TCP/IP para serem implementados em universidades dos Estados
Unidos, que rapidamente atingiram cerca de 90% dos departamentos de cincias da
computao das universidades. Aps sete anos de seu inicio, a Internet cresceu por
milhares de redes localizadas nos Estados Unidos e Europa; em 2005, a Internet
global atingiu cerca de 300 milhes de computadores em 209 pases. [COMER-06]
O surgimento da Internet implementada pelos protocolos TCP/IP ocorreu de
forma
paralela
ao
desenvolvimento
das
redes
de
comunicao,
seu
desenvolvimento no seguiu as padronizaes como o Modelo de Referncia OSI

ou IEEE.
O modelo TCP/IP, foi concebido para situaes extremas e para ter capacidade
de enviar mensagens, mesmo que houvesse interrupes no trajeto, por caminhos
ou rotas alternativas, o que permite interligar redes de tecnologias heterogneas,
permitindo a formao de uma inter-rede.
Os dois principais protocolos que implementam este modelo acabaram por
fornecer o nome ao modelo. Esta arquitetura baseia-se em um servio de transporte
orientado conexo, servio que fornecido pelo TCP (Transmission Control
Protocol) orientado conexo, e, pelo IP (Internet Protocol) no orientado
conexo.
A arquitetura do modelo TCP/IP organizada em quatro camadas: host/rede,
inter-redes, transporte e aplicao.
A figura 34 a seguir ilustra as camadas e trfego de dados entre as mesmas.
98
Figura 34: Camadas da arquitetura TCP/IP

A arquitetura TCP/IP enfatiza a interligao de redes de tecnologias diferentes,

o conceito desta necessidade esta associada ao fato de que no h nenhuma
tecnologia que atenda as necessidades de todos os usurios.
Para que sejam conectadas duas ou mais redes fazem-se necessrio a
utilizao de Internet gateway ou Internet router, o usurio enxerga a inter-rede
como uma rede virtual nica, onde todas as mquinas esto conectadas, no
importando a forma fsica de como isto ocorre.
Como comparao entre o modelo TCP/IP e o Modelo OSI, o ponto de
fundamental relevncia que pode ser estabelecido entre os eles o motivo de suas
concepes: a arquitetura TCP/IP foi elaborada para interligar redes com tecnologias
distintas, a simplicidade quanto ao nmero de camadas tambm tornou o TCP/IP
mais abrangente; o Modelo de Referncia OSI teve como finalidade a padronizao
para redes, onde inicialmente houve o desenvolvimento das camadas e
posteriormente a
implementao dos protocolos
da arquitetura, apresenta
complexidade na implementao de protocolos e definio de servios interrelacionados [TANENBAUM-03].

A figura 35 ilustra as camadas do modelo OSI e TCP/IP.
99
Figura 35: Camadas do Modelo OSI e TCP/IP

Esta soluo simples e prtica mostrou-se muito eficiente para a interconexo

de redes de sistemas abertos, oferecendo uma opo de soluo no proprietria. O
modelo TCP/IP passou a ser visto como padro de facto. Outro aspecto relevante a
Arquitetura TCP/IP est associado ao nmero de camadas; na subcamada de rede,
somente a utilizao do protocolo IP, cujo servio e datagrama no confivel,
trouxeram inflexibilidade na arquitetura neste nvel, sendo um dos motivos que
trouxeram xito arquitetura TCP/IP. [SOARES-99]
4.4.1
Camadas TCP/IP
A camada Host/Rede um grande vcuo, no sendo especificamente

determinado o que ocorre nesta camada que possibilita conectividade com diversos
tipos de redes.
A camada Inter-Rede, responsvel pela integrao da rede, oferece
transferncia de dados, recebe pedidos de transporte para transmitir os pacotes que
100
so encapsulados em um datagrama IP (que definido nesta camada) que

juntamente com algoritmos de roteamento determinam como as mensagens sero
entregues. A figura 36 abaixo ilustra a posio da camada de inter-rede e servios
oferecidos.
Figura 36: Camada de Rede - Servios

Fonte: [FOROUZAN-06]
A camada de Transporte tem como principal responsabilidade possibilitar que

as entidades (hosts) de origem e destino estabeleam comunicao. Nesta camada,
esto implementados dois protocolos que atuam para viabilizar a fluidez da
comunicao: o protocolo TCP e o protocolo UDP. O TCP oferece um servio de
circuito virtual, orientado conexo confivel, assegura a entrega sem erros de
bytes dentro da inter-rede; trata o fluxo de dados, impedindo que o receptor seja
sobrecarregado com um volume maior de informaes que possa manipular. O UDP
um protocolo sem conexo e sem confiabilidade, que utilizado em situaes que
no requerem controle do fluxo de informaes. tambm utilizado em
circunstncias em que a entrega imediata de informaes mais importante que a
preciso.
A figura 37 a seguir ilustra os servios executados na camada de transporte.
101
Figura 37: Servios executados na camada de transporte

Fonte: Adaptado de [FOROUZAN-06]
Na camada de Aplicao esto contidos os protocolos de nvel mais elevado da

arquitetura TCP/IP, onde so implementados as aplicaes e processos que utilizam
a rede; diversos protocolos foram implementados nesta camada para atender vrias
necessidades, TELNET, FTP (File Transfer Protocol), SMTP (Simple Mail Transfer
Protocol), DNS (Domain Name System), HTTP (Hypertext Transfer Protocol), entre
outros.
4.4.2
Protocolo TCP
Conforme expe [HANCOCK-03], o TCP um protocolo duplex completo

orientado por conexo, que desempenha funes como: transmisso confivel de
dados, deteco e correo de erros, garantia de transmisso de dados na ordem
correta, retransmisso de dados no recebidos, garantia de no duplicao de
dados entre os ns origem e destino.
O formato e contedo do cabealho TCP so apresentados na figura 38 a
seguir.
102
Figura 38: Estrutura do segmento TCP

Fonte: Adaptado de [ROSS-06]
O TCP/IP utiliza na comunicao entre entidades de rede o processo

conhecido por three-way handshake1, que envolve uma estao inicial (cliente)
requisitando que um link seja estabelecido com o servidor para iniciar a
comunicao. O TCP caracterizado como um protocolo tipo PAR (positive
acknowledgment with retransmission) e prov tambm controle de fluxo fim-a-fim,
onde utiliza buffers para controle de dados: transmitidos, recebidos e no
confirmados.
Em comparao as redes locais, as redes destinadas grandes distncias
possuem latncia elevada, a janela de 16 bits que inicialmente implementava o TCP
restringe o fluxo de dados entre ns. Esta restrio foi corrigida com a introduo da
opo escala de janela definida nas RFCs 1072 e 1323.
Outra modificao relevante ocorrida TCP foi a funo time-stamp (tempo de
espera de confirmao). O PAR do TCP requer que o emissor retransmita todos os
segmentos de dados no confirmados, se as confirmaes no chegarem aps
tempo definido. A especificao de time-stamp apropriado consta na RFC 1323.
[HANCOK-03]
1
Comunicao em trs fases: 1) o cliente inicia uma solicitao de conexo para o servidor; 2) o
servidor confirma o pedido; 3) o cliente confirma a confirmao do servidor. [HANCOCK-03]
103
O nmero de seqncia para um segmento do TCP tambm sofreu

modificaes por meio da RFC 2018, com a incluso de confirmao seletiva, onde
se houver um intervalo entre grupos de segmentos recebidos, o receptor envia
confirmaes de dados recebidos especificando os dados recebidos fora de ordem.
4.4.3
Protocolo UDP
O protocolo UDP (User Datagram Protocol) um protocolo no orientado

conexo que prov um servio de datagrama no confivel, esta definido na RFC
768. [ROSS-06].
A figura 39 abaixo ilustra estrutura do segmento UDP.
Figura 39: Estrutura do segmento UDP

Fonte: Adaptado de [ROSS-06]
O protocolo UDP apresenta estrutura simples, cujo propsito a rapidez na

entrega de segmentos, entretanto, no executa deteco e / ou correo de erros,
no retransmite os dados que eventualmente no foram entregues e tambm no
executa controle de erros ou fluxo de dados.
Estas caractersticas representam rapidez na entrega de mensagens, porm
atribui aos nveis de aplicao a tarefa pelo controle de erros e controle de fluxo de
pacotes.
Conforme expe [PETERSON-04], embora o UDP no implemente controle de
fluxo confivel, o mesmo assegura a exatido da mensagem pela utilizao de uma
soma de verificao, conforme figura 39. A soma de verificao, na Internet baseada
em IPv4 opcional, porm, passar a ser obrigatrio na Internet IPv6.
104
4.4.4
Protocolo IP
O protocolo IP esta definido na RFC 791; foi desenvolvido para possibilitar a

interconexo de redes baseados na tecnologia de comutao de pacotes
(datagramas IP). Na arquitetura TCP/IP o ambiente inter-redes (camada de atuao
do protocolo IP) consiste em hosts conectados a redes que por sua vez so
interligados por meio de gateways (roteadores).
O IP um protocolo
no orientado conexo, sua funo possibilitar a
transferncia de datagramas do host origem para o host destino. O protocolo

tambm prov servios de fragmentao e remontagem de datagramas longos.
A figura 40 abaixo apresenta datagrama IP.
Figura 40: Formato de datagrama Internet TCP/IP

Fonte: [COMER-06]
Algumas das principais caractersticas do protocolo IPv4 so: [SOARES-99]
Servio de datagrama no confivel;
Endereamento hierrquico;
Facilidade de fragmentao e remontagem de pacotes;
Identificao da importncia do datagrama e do nvel de confiabilidade

exigido;
Identificao da urgncia de entrega e da ocorrncia futura ou no de

pacotes na mesma direo (pr-alocao, controle de congestionamento);
105
Campo especial indicando qual o protocolo de transporte a ser utilizado no

nvel superior;
Roteamento adaptativo distribudo nos gateways;
Descarte e controle de tempo de vida dos pacotes inter-redes no gateway.
Os endereos IPv4 so compostos por 32 bits. Os endereos IP podem ser

utilizados para redes e para host individual. O protocolo IP utiliza trs classes de
endereos para redes distintas: classe A, classe B e classe C.
Conforme expe [HANCOCK-03], o controle de endereos IP foi elaborado
inicialmente pelo IANA (Internet Assigned Numbers Authority), que na ocasio
possua autoridade sobre os nmeros utilizados na Internet. O IANA integrou o
Instituto de Cincia da Informao da University of Southem Califrnia. A partir de
1999, foi constituda nos Estados Unidos a organizao ICANN (Internet Corporation
for Assigned Names and Numbers) para assumir e conduzir as atribuies do IANA.
As atribuies de endereo IP so administradas de forma distribuda e
hierrquica por meio de um sistema de Registros da Internet (IR Internet Registry),
o qual possui uma estrutura com vrias organizaes em diversos pases.
Os endereos IP so utilizados para identificao de hosts na Internet.
Atualmente predominante na Internet o IPv4. Conforme expe [HANCOCK-03], o
processo de resoluo de nomes mais eficiente desempenhado por servidores de
nomes de domnios.
As limitaes impostas ao IPv4 devido ao crescimento da Internet nas ltimas
dcadas culminaram no desenvolvimento do IPv6 descrito na RFC 1752, que foi
projetado para substituir o IPv4, solucionar os problemas de endereamento de IPv4
e prover novas funes para suprir as demandas com as diversas aplicaes de
endereo IP. Com a utilizao de endereos de 128 bits, o IPv6 disponibiliza vrios
tipos de endereos: unicast (uma origem e um destino), anycast (define um nico
computador) e multicast (uma origem e muitos destinos); prov suporte roteamento
prioritrio, oferece configurao e reconfigurao automticas de endereos e
mecanismos relacionados
segurana como: autenticao, privacidade e
confidencialidade de dados via criptografia. [FOROUZAN-06]

A figura 41 a seguir ilustra formato dos cabealhos IPv4 e IPv6.
106
Figura 41: Formatos dos cabealhos IPv4 e IPv6

Fonte: Adaptado de [HANCOCK-03] e [ROSS-06]
Segundo [DOMINGUES-02], que aponta a consolidao de redes como

soluo para integrao entre arquiteturas distintas, como SNA e TCP/IP, onde cita:
todos os recursos e tcnicas tendentes consolidao SNA/IP no so
excludentes, o que significa dizer; que no h um projeto padro de integrao
apontando para o uso de uma tcnica ou outra. Todas as formas podem ser
utilizadas.
107
5. AUTOMAO INDUSTRIAL
A Automao Industrial pode ser definida como um conjunto de tcnicas e de
sistemas de produo, principalmente fabris, baseado em mquinas e dispositivos
(sensores, atuadores, transdutores, etc.) que atualmente interagem de forma
integrada com capacidade de executar tarefas previamente definidas pelo homem e
de controlar seqncias de operaes sem a interveno humana.
A Automao Industrial tem como objetivo a produtividade, qualidade e
segurana na execuo de processos.
5.1 Evoluo do Controle Industrial

A Revoluo Industrial ocorrida no sculo XIX alavancou os meios de produo
da sociedade moderna, transformando os processos industriais e formas de
produo em sistemas complexos, capazes de atuar sobre diversas variveis, a
figura 42 abaixo ilustra a atual classificao de sistemas de automao.
Figura 42: Classificao geral dos sistemas de automao

Fonte: [MORAES-07]
108
Conforme expe
[PEREIRA-03], os primeiros passos para a automao
industrial e a formao das atuais redes industriais, tiveram incio durante a

Revoluo Industrial, no final do sculo XIX.
medida que a produtividade de mquinas e equipamentos crescia com o
aumento do consumo das sociedades, tornou-se necessrio o conseqente
surgimento de sistemas que possibilitassem aumento de produo, com tarefas
repetitivas que se tornaram cada vez mais produtivas.
Em 1568, Jacques Besson, engenheiro francs desenvolveu o primeiro torno
de abrir roscas que se tem notcia; em 1770, surgiram os mecanismos automticos
de produo em serie que revolucionaram a indstria, James Watt desenvolveu os
primeiros reguladores mecnicos em 1788. Desde ento o desenvolvimento e
aperfeioamento de novos equipamentos e sistemas tm sido contnuo, passando
por sistemas cada vez mais confiveis, como o controle numrico, que comeou a
implementar as mquinas de bens de consumo da dcada de 1950, chegando aos
robs das atuais linhas de produo, que utilizavam chaves fim-de-curso e cames,
que foram introduzidos comercialmente em 1959 pela Planet Corporation.
[SILVEIRA-98]
A tecnologia com robtica baseada no conceito de automao programvel
passou a ser incorporada aos meios e processos de produo. Estas tecnologias de
processo de produo passaram a ser utilizadas pelas indstrias automobilsticas a
partir da dcada de 1960, quando a Ford Motor implementa seu processo produtivo
com rob Unimate.
O conceito de automao baseada em controladores programveis foi um
avano em relao ao controle numrico. Esta tecnologia passou a ser
definitivamente incorporada aos processos industriais, substituindo quadros de
comando a reles. [SILVEIRA-98]
No final dos anos 60, com o desenvolvimento da eletrnica, os circuitos
integrados possibilitaram o surgimento de sistemas microprocessados que foram
utilizados para controle de processos industriais.
Em 1969, baseados numa
especificao da General Motors, surgiram os primeiros Controladores Lgicos

Programveis (CLP).
109
O CLP foi idealizado, entre outros requisitos, para atender a necessidade de

alterao de linhas de produo e industrializao sem que fossem realizadas
grandes modificaes mecnicas e eltricas em instalaes, no havendo
necessidade de impactos prolongados e paralisaes de produo e sem grandes
modificaes no layout das fbricas. O CLP surgiu originalmente para atender a
demanda da indstria automobilstica, especificamente na Hydronic Division da
General Motors, sob o comando do engenheiro Richard Morley. O objetivo inicial do
CLP foi de reunir em um nico equipamento as seguintes caractersticas funcionais:
[MORAES-07]
Facilidade de programao;
Facilidade de intervenes para manuteno;
Confiabilidade;
Robustez, devido aos ambientes industriais;
Possibilidade de reduo de painis e componentes eltricos;
Possibilidade de envio de dados para processamento e superviso

centralizada;
Possibilidade de expanso modular.
Ao longo do surgimento e desenvolvimento, os CLPs puderam ser classificados

em funo do sistema de programao utilizado e posteriormente pela interligao
entre os dispositivos em redes de comunicao. Os equipamentos de 1 gerao
foram caracterizados pela programao, sendo que nesta gerao de dispositivos
estava intimamente ligada arquitetura do hardware do equipamento; nesta fase a
linguagem utilizada era o Assembly, que variava de acordo com o processador
utilizado na arquitetura do hardware do CLP, havendo a necessidade de
conhecimento do circuito eletrnico do equipamento para a tarefa da programao
do CLP; nesta gerao, os dispositivos eram geralmente programados em fbrica,
por meio da implementao do programa diretamente no equipamento. Com a
evoluo das linguagens de programao, surge ento a 2 gerao, onde a
linguagem de programao estava menos dependente do hardware, devido
incluso de programas que realizavam a compilao das instrues de programa.
Atualmente, devido aos modernos sistemas operacionais e s linguagens de
110
programao de alto nvel, as metodologias de programao so desenvolvidas de

forma independente do hardware.
Os controladores lgicos de 3 gerao passaram a dispor de dispositivos
externos para comunicao porttil, que possibilitavam a programao via teclados
ou por consoles.
A popularizao dos microcomputadores ocorrida com o surgimento do PC
IBM (Personal Computer) fez com que surgisse a 4 gerao, onde os CLPs
dispunham de porta serial de entrada, que com auxlio dos microcomputadores
viabilizou a programao, que passou a ser realizado no prprio equipamento. Nesta
fase iniciou-se a utilizao de computadores nos processos de automao industrial.
O
desenvolvimento acelerado
das comunicaes industriais aliado
necessidade de padronizao dos protocolos utilizados pelos dispositivos de

automao caracterizou a 5 gerao, que passaram a dispor de redes de
comunicao industrial que possibilitaram a interligao de dispositivos, compondo
arquiteturas de automao.
Necessidades provenientes dos processos econmicos de globalizao
ocorridos na dcada de 1990 fizeram com as corporaes buscassem formas mais
flexveis de integrao de processos produtivos.
Com a consolidao da tecnologia de controladores lgicos programveis, dos
sistemas de comunicao e transmisso de dados, a busca pelo desenvolvimento de
novos recursos a serem implementados nos sistemas de controle tem sido constante
com o objetivo de aumentar a eficincia no monitoramento e controle de processos.
Atualmente as principais caractersticas atualmente implementadas nos modernos
controladores lgicos programveis so: [MORAES-07]
Linguagem de programao de alto nvel;
Simplificao de quadros eltricos;
Confiabilidade operacional;
Possibilidade de implementao de funes matemticas avanadas;
Possibilidade de interconexo por meio de redes de comunicao;
111
Possibilidade de interligao a sistemas de superviso e gerenciamento

centralizado.
Tais caractersticas tornaram os sistemas de automao confiveis e

produtivos, sendo utilizados para controle em diversos segmentos, principalmente na
indstria.
Conforme expe [PRUDENTE-07], o mercado de CLP cresceu de um volume
de cerca de 120 milhes de dlares em 1978 para cerca de 100 bilhes de dlares
nos primeiros anos da dcada de 1990 e continua em crescimento.
5.2 Arquitetura de Automao Industrial

A arquitetura de automao industrial pode ser descrita como qualquer
sistema, apoiado em tecnologia computacional, que substitua o trabalho humano, e
que vise solues rpidas e econmicas para atingir os complexos objetivos das
industriais e dos servios de automao. [MORAES-07]
Este conceito aborda de forma abrangente todos os sistemas que podem ser
otimizados por meio de processos automatizados, podendo ser aplicado aos
diversos sistemas e setores que utilizam automao, tais como industrial, bancrio,
comercial, etc., visando produtividade, confiabilidade e eficincia de processos.
Conforme expe [STEMMER-01], verifica-se tendncia de descentralizao da
capacidade decisria dos componentes do sistema de automao industrial,
aproximando-os do processo, sem, entretanto perder as vantagens da superviso e
controle centralizados.
Em automao industrial, os atuais controladores programveis disponveis,
permitem o controle lgico e dinmico de variveis do processo com grandes
vantagens e relativa simplicidade de programao e reprogramao, devido s
linguagens utilizadas atualmente, conforme Norma IEC 61131-3, baseados em
linguagens grficas e textuais.
A figura 43 a seguir ilustra estas linguagens.
112
Figura 43: Linguagens de programao IEC 61131-3

Fonte: [PRUDENTE-07]
Nos atuais processos de automao so utilizados computadores de

processos, que permitem a coleta e processamento de informaes dos sistemas
controlados,
que possibilitam
implementao
de
modelos matemticos de
engenharia de controle, simulando desempenho do sistema, regras de segurana,

operaes em tempo real, alm de facilitar a interface com sistemas de superviso e
gerenciamento, conforme expe [MORAES-07].
A utilizao dos atuais sistemas automatizados implica necessariamente
tambm na aplicao de sistemas interligados, monitorados e que possam ser
supervisionados. As redes de comunicao surgem como forma vivel de assegurar
o acompanhamento dos processos. Estas redes de comunicao podem ser
implementadas por sistemas supervisrios, sistemas de gerenciamento de falhas,
sistemas de interface homem-mquina; com o objetivo de facilitar a interpretao de
dados, possibilitando integrao entre equipamentos e usurios. Esta integrao por
meio de redes assegura o monitoramento do desempenho dos sistemas produtivos e
equipamentos utilizados para a automao destes sistemas.
Conforme expe [MORAES-07], os sistemas de automao que envolvem a
informatizao apresentam vantagens significativas que so fundamentais para a
competitividade
das
corporaes,
como
possibilidade
de
expanso
comunicao, com utilizao de recursos de fcil acesso, sem os quais, as plantas
113
industriais podem apresentar uma grande quantidade de alarmes, por exemplo,

inviabilizando a atuao do operador de tais sistemas e equipamentos.
No mbito industrial, a automao atende s necessidades como maiores
nveis de qualidade de conformao e de flexibilidade aos processos. Esta
viabilizao na utilizao da automao pode ser mensurada por menores custos
nos processos produtivos, reduo ou at mesmo extino de retrabalhos
ocasionados por desconformidades no processo.
O planejamento adequado dos meios de produo assegura reduo de
perdas de matrias primas, reduo do custo de capital pela gesto eficiente de
estoques e recursos humanos; o maior controle de informaes relativas ao
processo e servir de subsdio para decises de planejamento e controle dos
processos de produo.
Uma gesto corporativa eficiente compreende o gerenciamento de todas as
etapas do processo produtivo. Devido ao grau de desenvolvimento das redes
industriais e das redes corporativas de dados esta tarefa pode ser atingida,
possibilitando o acompanhamento eficiente da planta, isto atualmente possvel
devido aos avanos ocorridos nas reas de tecnologia de automao e tambm nos
segmentos voltados tecnologia da informao.
A automao industrial contempla a realizao de vrias tarefas e funes que
tem suas atribuies definidas em nveis de interligao e atribuio de forma
hierarquizada, onde estas tarefas podem ser definidas em um organograma, definido
como Pirmide de Automao [MORAES-07], com diferentes nveis de automao
encontrados numa planta industrial, conforme figura 44 a seguir:
114
Figura: 44 Estrutura da Pirmide de Automao

Fonte: Adaptado de [MORAES-07] e [STEMER-01]
A utilizao de sistemas supervisrios aplicados aos controladores lgicos

programveis permitiu que fossem integrados os sistemas produtivos, fazendo com
que houvesse intercambio de informaes entre diferentes processos em setores
distintos de uma empresa, otimizando o tempo e recursos despendidos para
confeco de bens e/ou produtos.
Dentre as razes para a aplicao de sistemas automatizados, podem-se citar
algumas, tais como: [MORAES-07]
Tarefas que exigem grande repetibilidade e qualidade;
Execuo de tarefas agressivas;
Possibilidade de reduo de custos de produo;
Restabelecimento rpido do processo produtivo;
115
Possibilidade de introduo de sistemas produtivos integrados;
Utilizao de computadores tipo PC na programao dos dispositivos.
Conforme expe [TOVAR-03], que aborda a integrao como a soluo para

interligar as Automated Islands aos segmentos administrativos, ou seja, a
possibilidade de os subsistemas da empresa poderem interagir por meio de sistemas
de comunicao de dados comuns.
A figura 45 ilustra interao entre subsistemas e base de dados comum.
Figura 45: Base de Dados Comum

Fonte: Adaptado de [TOVAR-03]
Empresas do segmento de desenvolvimento solues para automao

industrial tm focado esforos no aprimoramento de produtos e de sistemas que
possibilitem a integrao de sistemas computacionais com confiabilidade e robustez
aplicada aos nveis de fabricao (controladores lgicos programveis). A integrao
dos processos produtivos associados aos sistemas corporativos possibilitou o
surgimento de sistemas integrados de gesto empresarial, conhecidos por ERP
(Enterprise Resource Planning) que tem sido utilizado na gesto de empresas. Os
116
sistemas ERP surgiram a partir da evoluo dos sistemas MRP (Material Resource
Planning). Os sistemas ERP so compostos por uma base de dados nica e por
mdulos que suportam diversas atividades das empresas.
Um dos principais desafios da automao industrial eficiente esta voltado para
o preenchimento da lacuna existente entre os processos de gesto e os processos
fabris quanto disponibilidade de modelos eficazes para interao e troca de
informaes entre estes sistemas. Conforme expe [CUNHA-04], as dificuldades
para integrao entre redes industriais so muitas, dentre as quais:
Falta de viso integrada das empresas;
Projetos refletem falta de viso integrada;
Os sistemas no esto preparados para esta integrao;
Faltam padres para facilitar a integrao;
Justificativas econmicas tradicionais;
Falta de experincia e metodologia para essa integrao.
5.3 Modelo para Troca de Informaes

As arquiteturas para trfego de dados aplicados aos sistemas de automao e
sistemas informatizados baseiam-se na troca de informaes entre diversos
dispositivos de campo, tais como sensores, controladores lgicos programveis e
sistemas de superviso e monitoramento.
Os principais modelos utilizados para troca de informaes em redes industriais
so: [LOPES-00] [MORAES-07]
Mestre/escravo, conceito baseado em hierarquia de comunicao;
Cliente / servidor, conceito baseado em filas;
Produtor / consumidor, conceito baseado em tabelas de comunicao;
Distribuio de relatrios, conceito baseado em filas.
A tabela 11 a seguir apresenta estes modelos de comunicao relacionados

com DLL (Data Link Layer) da arquitetura de redes de campo.
117
Tabela 11: Modelos de comunicao industrial
Modelo
Cliente-Servidor
Distribuio de relatrio
Produtor-consumidor
Data Link Layer DLL

Enfileirada
Enfileirada
Bufferizada
Programado por
Usurio
Usurio
Rede
Direo
Bidirecional
Unidirecional
Unidirecional
Fonte: Adaptado de [LOPES-00]
No modelo cliente/servidor, a comunicao ocorre de forma enfileirada no

escalonada. Enfileirada implica que as mensagens so enviadas na ordem fornecida
para a transmisso, onde estabelecida e obedecida prioridade para transmisso
sem que seja sobrescrita das mensagens anteriores. No protocolo de comunicao
de cada estao, implementado um conjunto de filas para envio e recebimento de
arquivos, fazendo com que uma estao leia o valor registrado por um sensor de
campo e direcione uma mensagem para sua interface de comunicao ler esta
varivel do processo em outra estao, ocorrendo seguinte seqncia: [LOPES00]
A mensagem solicitada aguarda numa fila de sada e ser lanada para a

rede na prxima vez que a outra estao se comunicar;
O sensor de campo recebe a solicitao, que ficar aguardando em uma fila

de recepo;
O sensor define o valor de tempo solicitado e retorna este valor utilizando a

mesma seqncia.
Este modelo assegura a preservao da seqncia de tempo, sendo

apropriado para o trfego de grande volume de dados que so transmitidos em
pequenos pacotes.
O tempo de espera torna-se o fator determinante, uma vez que uma estao
com baixo desempenho refletir na performance do sistema inteiro, por isto,
conforme expe [LOPES-00], sistemas cliente/servidor so de difcil configurao.
O modelo produtor/consumidor apresenta como principal caracterstica a
comunicao via buffer, onde apenas a ltima verso da informao mantida, o
dado mais recente sobrescreve o anterior. Este sistema conceituado como sendo
118
um sistema que utiliza grupo de buffers no caminho de comunicao de cada

estao, sendo que cada buffer: [LOPES-00]
Corresponde a uma varivel da aplicao;
identificado dentro do grupo de aplicao por um rtulo lgico;
Mantm o valor de uma varivel da aplicao, esperando para ser

transmitido via rede, para ser utilizado pela aplicao no processo.
Este mtodo de comunicao de dados complementado por 03 processos

distintos: o produtor, a rede e o consumidor; que so independentes entre si, que
podem operar no modo cclico ou no modo dirigido por evento. [LOPES-00]
Sistemas com esta concepo apresentam facilidade de configurao; a
principal aplicao esta no nvel de controle e superviso, conforme expe [LOPES00], porm possui limitao no gerenciamento de eventos e tambm para
transmisso de quantidades elevadas de informaes crticas.
Segundo [MORAES-07] expe que estes sistemas possuem economia na
transmisso de dados e oferece determinismo ao sistema, visto que o tempo de
entrega de dados independe do nmero de dispositivos que os solicitam.
No padro Fieldbus Foundation, a subcamada FAS (Fieldbus Access Sub
Layer) utiliza os mtodos de comunicao entre dispositivos cliente/servidor,
produtor/consumidor e distribuio de relatrio. A camada FAS utiliza funes DLL.
Estes servios esto previstos por VCRs (Virtual Communication Relationship) no
padro Fieldbus.
O mtodo Distribuio de Relatrio (Report Distribution) utiliza comunicao
por filas, no escalonada para comunicao entre dispositivos no padro Fieldbus
Foundation.
119
6. REDES DE CAMPO INDUSTRIAIS

As redes de campo ou barramento de campos para aplicao em plantas
industriais foram desenvolvidas com intuito de interligar dispositivos aplicados na
automao industrial, como: sensores, atuadores, mdulos de I/O (input/output),
controladores lgicos, sistemas de superviso e monitoramento. O conceito inicial foi
estabelecer um ambiente que pudesse ser compartilhado, agregando flexibilidade,
distribuio de processamento nos dispositivos no parque fabril.
O controle industrial que inicialmente era centralizado, que com a evoluo das
redes de campo passou a ocorrer de forma distribuda nos CLPs, definindo os
Sistemas de Controle Distribudos. [ALBUQUERQUE-07]
Nas ltimas dcadas, os processos de instrumentao e automatizao
migraram de sistemas pneumticos, chegando aos atuais sistemas baseados em
microprocessadores. No incio dos anos da dcada de 1940, eram utilizados sinais
de presso de 3 a 15 PSI para aplicaes industriais. Na dcada de 1960, os
sistemas de controle industrial passaram a aplicar sinais eltricos analgicos de 4 a
20 mA para instrumentao e controle. Esta tcnica trouxe diversas vantagens aos
sistemas industriais, como reduo de rudo e melhoria na confiabilidade dos
dispositivos, diminuio do tempo intervenes para manuteno, e agilidade nos
processos de expanso e implementao de equipamentos da fbrica.
Durante a dcada de 1970, com o desenvolvimento da eletrnica digital, os
processadores passaram a serem utilizados para o monitoramento e controle de
vrios dispositivos de controle e automao.
Na dcada de 1980 foram desenvolvidos e implementados sensores que
possuam capacidade de processamento (dispositivos inteligentes) para aplicaes
no controle digital. Estes sensores conseguiram aliar baixo custo com relativa
flexibilidade de instalao. Entretanto, tornava-se evidente a necessidade de
padronizao para os dispositivos e sistemas de automao, estas necessidades
levaram a realizao de fruns de mbito internacional que objetivaram a
padronizao entre as tecnologias desenvolvidas.
120
As organizaes ISA (Instrumentation Society of Amrica), IEC (International

Electrotechnical Commission), Profibus (German National Standard) e FIP (French
National Standard), formaram o comit IEC/ISA SP50 (Standards & Practices 50),
com o objetivo desenvolver um padro de integrao para a grande variedade de
instrumentos de controle e automao; providenciarem interfaces para operao
simultnea de vrios dispositivos e suportar um protocolo de comunicao para
todos os dispositivos e redes de campo.
Em 1992, o mercado de instrumentos voltados para automao industrial era
liderado por dois grandes grupos, que lideravam solues para integrao dos
dispositivos e sistemas de automao, a ISP (Interoperable Systems Project) e a
WorldFIP (Factory Instrumentation Protocol). Em 1994, a ISP e WordFIP uniram-se e
criaram a Fieldbus Foundation; esta iniciativa teve como objetivo agilizar o processo
de padronizao das redes de campo. [STEMMER-01]
Conforme expe [ALBUQUERQUE-07], as quatro principais camadas do
Fieldbus Foundation foram padronizadas pelo ISA SP 50 em 1996, ou seja,
camadas: fsica, enlace de dados, subcamada de acesso fieldbus e especificao de
mensagem fieldbus; e sua constituio bsica demonstrada na figura 46, que
ilustra as camadas Fieldbus e a relao destas camadas com o modelo OSI.
Figura 46: Camadas Fieldbus Foundation e Modelo de Referncia OSI

Fonte: [FOUNDATION-07]
121
6.1 Camada Fsica

A camada fsica, proposta na ISA SP 50 define o meio de transmisso utilizada
na
interligao de dispositivos,
compondo-se
de outras 03
subcamadas:
[STEMMER-01]
DIS (Data Independent Sublayer), atuao como interface com a camada

de enlace, recebe e repassa solicitaes de servios;
MDS (Mdium Dependent Sublayer), atuao na codificao dos dados que

sero enviados em formato compatvel com meio fsico de transmisso;
MAU (Mdium Attachment Unit), descreve o transceptor para o meio fsico.
Conforme expe [ALBUQUERQUE-07], o nvel fsico define o meio para

transporte das mensagens, sendo definidos trs meios fsicos para o Fieldbus
Foundation: cabos, fibra ptica e sinal de radio (ISA -550-02).
6.2 Camada Link de Dados (Enlace)

Esta camada detecta erros de transmisso, monitorando a comunicao,
assegurando integridade de mensagem por meio de CRC (Cyclical Redundancy
Check); oferece tambm quatro classes de funes a serem implementadas nas
estaes, conforme estas implementaes sejam requeridas, sendo as funes de:
[STEMMER-01]
Responder, estao atua como estao escrava, respondendo as

solicitaes;
Initiator, estao utiliza o meio de acesso (por meio de token), enviando e

requisitando dados a outras estaes;
Link-Master, atuao semelhante ao barramento FIP, incluindo as funes

de Responder e Initiator utilizando tambm token e tempo interno do
sistema;
Bridge, estao atua com capacidade de interligar outras entidades de

enlace diferentes.
122
A camada de link de dados atua tambm fornecendo quatro classes de

servios camada de aplicao: gerenciamento de buffers e filas, transferncia de
dados com conexo, transferncia de dados sem conexo e o escalonamento de
transaes.
Conforme aborda [ALBUQUERUQUE-07], o acesso ao meio e definido pelo
LAS (Link Active Scheduler), por meio de uma requisio de token por dispositivos
conectados ao barramento, onde o LAS transmite o token a outro dispositivo
requisitante, via pr-configurao ou escalonamento.
6.3 Camada de Aplicao

Nesta camada so definidas as formas de transmisso das mensagens de
dados, ou seja, modos: cclico, acclico ou requisitadas pelo consumidor (tempo
real); para que todos os dispositivos conectados possam interagir, fornecendo os
servios de controle aplicados aos processos. Nesta camada esto previstos os
servios de: [STEMMER-01]
MCSE (Message Common Service Element);
MSE (Industrial Message Service Element);
DDM (Distributed Database Maintenance).
A camada de aplicao prove levantamento estatstico da rede, com deteco

de falhas, adio e remoo de estaes na rede.
6.4 Camada de Apresentao (Usurio)

Na camada de apresentao, tambm designada como camada de usurio,
conforme define [ALBUQUERQUE-07] estabelecido a estrutura de mensagens
para implementaes estratgicas de controle por meio de conexes em blocos
funcionais. Conforme aborda [FOUNDATION-07], que complementa citando que os
Blocos Funcionais representam as funes de automao bsicas, que so
executadas por aplicaes do bloco funcional. Cada bloco funcional processa
parmetros de entrada, de acordo com um algoritmo especfico e um conjunto
interno de parmetros de controle.
123
7. ARQUITETURAS DE REDES INDUSTRIAIS

As arquiteturas de padres de Redes Industriais destinam-se a integrar os
componentes de um sistema de automao e so caracterizadas em funo do
protocolo utilizado, e pela atuao nos nveis da cadeia produtiva (sensores,
processo,
controle);
possuem
caractersticas
especficas
para
atender
as
necessidades determinadas do ambiente e do processo, tais como:
Comportamento temporal;
Confiabilidade;
Conectividade;
Requisitos de meio ambiente.
A integrao de componentes e sistemas de automao atende as aplicaes

de CIM (Computer Integrated Manufacturing).
7.1 FieldBus
O protocolo Fieldbus foi desenvolvido pela Fieldbus Foundation, foi um padro
desenvolvido para automao de sistemas industriais, elaborado pela Fieldbus
Foundation e normalizado pela ISA SP 50 (International Society for Measurement
and Control) e pela IEC 61158.
Este padro tem como objetivo a interligao de instrumentos e dispositivos de
controle e automao de processos industriais. O Fieldbus interliga dispositivos
primrios de automao, por meio de uma linha de comunicao serial, de forma
bidirecional a um sistema integrado de automao e controle, conforme ilustra a
figura 47 a seguir.
O protocolo Fieldbus pode ser utilizado com sistemas supervisrios de
aquisio de dados conhecidos por SCADA (Supervisory Control and Data
Acquisition).
124
Figura 47: Arquiteturas das Redes Fieldbus

O tipo de trfego de dados no Fieldbus determinstico para variveis de

processo e no determinstico para parametrizao e diagnsticos. O padro
Fieldbus foi desenvolvido com base no padro OSI, porm nem todas as camadas
do Fieldbus foram implementadas. Segue na figura 48, comparao entre o Modelo
OSI e o Fieldbus.
Figura 48: Comparao entre o Modelo OSI e o padro Fieldbus.

125
O padro Fieldbus esta dividido em 02 nveis principais:
Nvel fsico;
Nvel software.
7.1.1
Nvel Fsico
Nvel responsvel pela interligao fsica entre os dispositivos e instrumentos

de campo, controladores lgicos programveis e sistemas de superviso e aquisio
de dados (SCADA). So definidos tambm neste nvel os padres eltricos para
ligaes, com suas respectivas caractersticas eltricas que estaro integrando a
rede Fieldbus.
Neste nvel tambm definido a diviso de velocidade de transmisso, sendo:
[CUNHA-04]
H1 (Lower Speed Fieldbus) com 31,25 Kbps;
H2 (Higher Speed Fieldbus) com 100 Mbps ou 1Gbps.
O padro Fieldbus H1 de 31,25 Kbps podem operar nas mesmas instalaes

onde so utilizados os padres 4-20 mA, permitindo atualizao gradual do sistema
de automao da planta, utilizado para transmisso de dados em tempo real de
comunicao com equipamentos e instrumentos.
O padro H1 um protocolo interopervel, suportado por grande parte dos
fornecedores de instrumentos, sendo vinte e cinco vezes mais rpido que a maioria
dos protocolos dedicados para transmissores inteligentes. A figura 49 a seguir ilustra
comparao entre o Modelo OSI e o padro Fieldbus H1.
126
Figura 49: Comparao entre Modelo OSI e padro Fieldbus H1.

O padro Ethernet foi incorporado pela Foundation Fieldbus na especificao

do padro H2. A rede utiliza o padro UDP/IP (User Datagram Protocol / Internet
Protocol) sobre as camadas de enlace Ethernet. O padro foi definido como HSE e
opera nas aplicaes de nvel mais elevado dentro da rede Fieldbus e com
velocidade de 100 Mbps, sendo que o padro H1 destina-se aos dispositivos de
campo.
A interligao entre a rede padro H1 e o padro H2 Fieldbus feito por meio
de linking device, que realiza converso entre os dados na rede H1 em mensagens,
utilizando os protocolos padres da Ethernet.
A especificao dos padres definida pela ANSI/ISA - Fieldbus Standard for
Use in Industrial Control System Part 2 Physical Layer Specification and Service
Definition.
Alguns itens da especificao so destacados no padro devido a sua
relevncia:
Transmisso de dados somente de forma digital;
Comunicao na forma bi-direcional;
Utilizao do cdigo Manchester;
Modulao de voltagem;
127
Transmisso com ou ser energizao;
Trfego determinstico para variveis de processo e no determinstico para

parametrizao e diagnsticos.
Especificaes quanto tolerncia de falhas, redundncias, segurana,

velocidade, bem como aplicaes em funcionamentos crticos so tambm tratados
pela norma, conforme alguns tpicos relacionados abaixo:
Segurana intrnseca, impedncia maior que 400 ohms para freqncia

variando de 7,8 a 39 KHz; e por meio de barreiras e equipamentos
intrinsecamente seguros de acordo com o padro FISCO (Fieldbus
Intrinsically Safe Concept);
No pode ocorrer interrupo no funcionamento da rede Fieldbus durante a

conexo/desconexo de qualquer dispositivo;
Redundncia de fonte, de host, de condicionador de sinal e de Link Active

Scheduler (LAS), redundncia via acopladores redundantes;
Na ocorrncia de falhas em elementos de transmisso, a comunicao no

poder ser prejudicada por mais de 1ms.
7.1.2
Nvel de Software
Este nvel do padro Fieldbus tratado pelo software supervisrio de aquisio

de dados (SCADA), transparente para o usurio, que se divide em camadas:
Subnvel de enlace (data link layer); neste subnvel assegurada a

transmisso da mensagem ao destinatrio, onde corrigido e garantido o
controle de rede e roteamento de mensagens
e definio das
transmisses;
Subnvel de aplicao (application layer); neste subnivel definida a sintaxe

das mensagens e modo de transmisso de cada mensagem podendo ser
cclica, imediata, uma nica vez ou quanto for requisitada;
Subnvel do usurio (user layer); neste subnvel definida a forma pela qual
pode ser feito o acesso a informaes dentro de equipamentos Fieldbus,
podendo-se distribuir as informaes para outros dispositivos da rede.
128
7.2 Profibus
O Profibus (Process Fiel Bus) DIN 91, barramento de campo lder na Europa,
foi desenvolvido pelo projeto Fieldbus com participao do Ministrio Alemo de
Investigao e Tecnologia. Sua tecnologia foi desenvolvida e administrada pela
Profibus User Organization, cujos membros formam a Profibus International.
O padro esta definido pelas normas EN50170 e EN50254, que asseguram a
independncia de fabricante, sendo considerado sistema aberto e pelo IEC 61158 e
IEC 61784 e pela DIN 19245 (padro alemo).
O Profibus, segundo sua prpria definio, especifica as caractersticas
tcnicas e funcionais de um sistema fieldbus serial no qual controladores digitais
descentralizados podem ser interligados do nvel de campo ao nvel de clula.
A arquitetura do Profibus esta baseada no modelo OSI, sendo utilizadas
apenas as camadas 1, 2 e 7, ou seja, fsicas, enlace e de aplicao,
respectivamente. A figura 50 ilustra as camadas do padro Profibus
Figura 50: Arquitetura do protocolo Profibus.

Fonte: [PROFIBUS-06]
A camada fsica do padro Profibus esta baseado na norma EIA RS-485 (EIA
Eletronic Industries Association), sendo que a interligao dos dispositivos pode
ocorrer por meio de par tranado blindado, podendo ser utilizado tambm fibra
129
ptica. Podem ser conectados no barramento at quatros segmentos, sendo que

cada segmento pode ter at trinta e dois dispositivos.
De acordo com a aplicao, pode-se utilizar como meios de transmisso os
seguintes padres:
RS 485 para utilizao universal, em especial sistemas de automao de

manufatura;
IEC 61158-2 para aplicaes em sistemas de automao em controle de

processo;
Fibra ptica para aplicaes em sistemas que requerem grande imunidade

a interferncias e grandes distncias.
A tabela 12 abaixo mostra as possveis velocidades de transmisso com suas

respectivas distncias correspondentes.
Tabela 12: Velocidades de transmisso Profibus DP
Baud rate (Kbit/s)

Distncia/segmento (m)
9.6
1200
19.2
1200
93.75
1200
187.5
1000
500
400
1500
200
12000
100
A codificao utilizada no padro binria NRZ. Na camada de enlace, o

Profibus define outras duas subcamadas:
Subcamada de controle e acesso ao meio (MAC);
Subcamada de controle de ligao lgica (LLC).
A especificao MAC (Medium Access Control) combina dois mtodos

determinsticos de acesso ao meio e assegura que somente uma estao tem o
direito de transmisso de dados a cada intervalo de tempo; durante a comunicao
entre controladores lgicos programveis complexos deve ser assegurado tempo
suficiente para que sejam executadas tarefas dentro de intervalo de tempo definido e
que a transmisso de dados em tempo real de forma cclica deve ser
complementada em velocidade e simplicidade na comunicao entre dispositivos
mestre e escravo.
130
O protocolo utilizado uma mistura de token-passing com o mestre-escravo.

Entre os dispositivos controladores (PCs e CLPs), um token fica circulando, criando
um anel lgico; e cada dispositivo controlador comanda os outros dispositivos (ditos
passivos) atravs do mtodo mestre-escravo.
A figura 51 ilustra este processo.
Figura 51: Acesso ao meio do protocolo Profibus

Fonte: [ALBUQUERQUE-07]
Na camada de aplicao foi definido subconjunto do MMS (Manufacturing

Message Specification), onde foram utilizadas primitivas especificas para atender as
caractersticas do barramento.
A camada de aplicao foi subdivida em:
Fieldbus Message Specification (FMS);
Lower Layer Interface (LLI);
Application Layer Interface (ALI).
Os servios oferecidos na camada de aplicao podem ser descritos em:
Servios de aplicao;
Servios de administrao;
Servios de gerenciamento de rede.
131
O padro Profibus possui grande aceitao na Europa e possui as seguintes

verses:
Profibus-DP (Descentralized Periphery);
Profibus-PA (Process Automation);
Profibus-FMS (Fieldbus Message Specification);
Profinet (Powerfull Real-time Open Flexible Integrated Net Convergence

Enterprisewide Transparent).
7.2.1
Profibus - DP
Verso Profibus que rene caractersticas de alta velocidade com baixo custo.
As funes bsicas do Profibus DP so resumidas na tabela 13 a seguir, sendo:
[PROFIBUS-06].
132
Tabela 13: Resumo de funes padro Profibus DP
Tecnologia de
transmisso
RS-485 (par tranado cabo de dois fios) ou fibra ptica

Baudrate de 9,6 Kbits/seg. a 12 Mbits/seg.
Acesso ao BUS
Procedimento de passagem de token entre mestres e procedimento de

mestre-escravo para escravos
Possveis sistemas mono-mestre ou multi-mestre
Comunicao
Dispositivos mestre e escravo, mximo de 126 estaes em um barramento

de comunicao
Peer-to-peer (transmisso de dados de usurio) ou multicast (comandos de
controle)
Transmisso de dados do usurio mestre-escravo cclica e transmisso de
dados no cclica mestre-escravo
Operate: transmisso cclica de entrada e sada de dados
Modos de operao
Clear: entradas so lidas, e sadas so mantidas em estado seguro

Stop: transmisso de dados s possvel em mestre-mestre
Sincronizao
Comandos de controle permitem sincronizao de entradas e sadas

Sync mode: sadas so sincronizadas
Freeze mode: (modo de congelamento) entradas so sincronizadas
Funcionalidade
Transmisso de dados cclica entre mestre DP e escravo(s) DP

Ativao ou desativao dinmica de escravos individualmente
Verificao da configurao do escravo DP
Poderosas funes de diagnsticos, 3 nveis hierrquicos de mensagens de
diagnsticos.
Sincronizao de entradas e/ou sadas
Designao de endereos para escravos DP via o barramento
Configurao de mestre DP (DPM1) sobre o bus
Maximo de 246 bytes de entrada e sada por escravo DP
Funes de segurana Todas as mensagens so transmitidas com Hamming distance HD=4

e proteo
Watchdog timer no escravo DP
Proteo de acesso para I/O (input/output) dos escravos DP
Tipos de dispositivos
Monitorao da transmisso de dados com temporizados configurveis pelo

Mestre
Class-2 DP master (DPM2): programao/configurao/DP diagnstico de
dispositivos
Class-1 DP master (DPM1): controlador programvel central tai com PLCs,
PCs, etc.
DP slave: dispositivo com I/O (input/output) binrio ou analgico, drivers,
vlvulas, etc.
Fonte: Adaptado de [PROFIBUS-06]
O Profibus DP utilizado principalmente para transferncia rpida de dados

cclicos entre controladores centrais (PCs e CLPs) e dispositivos de I/O
descentralizados e distribudos (vlvulas, atuadores, drivers, etc), utilizado tambm
para transmisses paralelas com 24 V ou 0-20 mA.
133
7.2.2
Profbus - PA
O padro Profibus PA foi desenvolvido especialmente para automao de

processos, permite que sejam conectados sistemas de automao e sistemas de
controle de processo com os dispositivos de campo (tais como transmissores de
presso, temperatura e nvel). Em comparao com mtodos convencionais
proporciona reduo em torno de 40%, possibilita tambm que sensores e atuadores
possam ser conectados a um barramento comum em rea de segurana intrnseca.
O padro Profibus PA possui segurana intrnseca por meio da utilizao dos
modelos EX para os padres DP/PA (link/couplers), de acordo com modelo FISCO.
O padro Profibus PA foi elaborado juntamente com usurios de indstrias de
processos e possui os seguintes requisitos especiais para atuao nas reas de
aplicao:
Perfil de aplicao padronizado para automao e controle de processo;
Possibilita insero e remoo de estaes e dispositivos, em reas de

segurana intrnseca sem afetar outras estaes;
Alimentao eltrica dos dispositivos via prprio barramento, conforme

padro IEC 61158-2, que possibilita a comunicao de dados e transporte
de energia no mesmo barramento. Utiliza par-tranado blindado ou sem
blindagem;
Permite utilizao em reas com potencial explosivo;
Permite topologia em barramento ou rvore. O padro utiliza velocidade de

31,25 Kbps, com at trinta e duas estaes por segmento e um mximo de
cento e vinte e sete estaes (com repetidores).
O padro Profibus PA foi preparado com base no perfil de comunicao DP. A

descrio das funes e comportamentos dos dispositivos esta baseada no modelo
de Blocos Funcionais (Function Block Model). As definies do padro PA torna-o
um substituto para sistemas que utilizam transmisso analgica 4 a 20 mA ou HART.
A figura 52 a seguir ilustra a aplicao do Profibus PA em sistema de automao de
processo.
134
Figura 52: Configurao tpica de sistema Profibus em automao de processo.

O padro Profibus PA oferece intercambiabilidade e interoperabilidade aos

dispositivos de campo PA de fabricante diferentes por meio da utilizao de blocos
funcionais que descrevem os parmetros e funes do dispositivo, tais como:
Bloco Fsico (Physical Block) contm informaes gerais do dispositivo;
Bloco Transdutor (Transducer Block) contm dados especficos do

dispositivo;
Bloco de Entrada Analgica (Analog Input Block AI) fornece o valor

medido pelo sensor, com estado e escala;
Bloco de Sada Analgica (Analog Output Block AO) fornece o valor da

sada analgica;
Bloco de Entrada Digital (Digital Input Block DI) fornece o valor da entrada
digital para o sistema;
Bloco de Sada Digital (Digital Output Block DO) fornece o valor da sada
digital para o sistema de controle.
7.2.3
Profibus-FMS
O Profibus FMS considerado uma soluo de uso geral para tarefas extensas
em comunicao, utilizado para comunicao em nvel de clula. O padro FMS
135
oferece um amplo leque de aplicaes com grande flexibilidade, sendo utilizado na

comunicao entre controladores lgicos programveis.
As verses Profibus DP e FMS podem ser utilizadas simultaneamente no
mesmo cabo, o que traz grande flexibilidade para o padro em termos de expanses
da planta. Ambos os padres (DP e FMS) podem ainda executar o mesmo
dispositivo de campo. No Profibus FMS so implementadas as camadas 1,2 e 7 e
so de extrema importncia. O padro FMS define uma ampla seleo de servios
de comunicao mestre-mestre ou mestre-escravo.
A camada de aplicao (nvel camada 7) do padro FMS e composta por:
Fieldbus Message Specification (FMS);
Lower Layer Interface (LLI).
O modelo de comunicao do padro FMS permite que aplicaes distribudas

sejam unificadas em um processo comum por meio da utilizao de relacionamentos
de comunicao, a parte da aplicao situada no dispositivo de campo pode ser
acessada via comunicao denominada de dispositivo virtual de campo (VFD
Virtual Fiel Device). Os objetos de comunicao de dispositivos FMS so registrados
em um dicionrio de objetos. Os objetos de comunicao podem ser classificados
em 02 tipos:
Objetos de comunicao esttica so registrados no dicionrio de objetos

estticos e configurados uma nica vez e no podem ser alterados durante
a operao;
Objetos de comunicao dinmica so registrados na seo dinmica do

dicionrio de objetos e podem ser modificados durante a operao.
Os servios do padro FMS so um subconjunto dos servios MMS, que foram

otimizados e estendidos, esto divididos nos seguintes grupos:
Servios de gerenciamento do contexto;
Servios de acesso a variveis;
Servios de gerenciamento do domnio;
Servios de gerenciamento de chamada de programa;
Servios de gerenciamento de eventos;
136
Servios VFD Support para identificao e status;
Servios de gerenciamento OD para dicionrio de objetos.
Alm dos servios citados acima, o padro FMS dispe de funes de

gerenciamento de rede FMA7 (Fieldbus Management Layer 7), que podem ser
ativadas de forma local ou remota. As funes de gerenciamento permitem:
Gerenciamento do contexto, utilizado para estabelecer ou desconectar uma

conexo;
Gerenciamento
da
configurao,
utilizado
para
acessar
variveis,
contadores e parmetros das camadas 1 e 2;
Gerenciamento de falha, utilizado para indicar eventos, falhas e reiniciar

dispositivos.
7.2.4
Profinet
Para a elaborao do PROFINET (Powerfull Real-time Open Flexible Integrated

Net Convergence Enterprisewide Transparent), vrios esforos foram conduzidos no
sentido de reunir em uma nica soluo de automao as caractersticas do padro
Profibus e da versatilidade da arquitetura TCP/IP.
O Profinet foi definido em conformidade com o Physical Layer ISO/IEC 8802-3,
cujo datalink layer esta de acordo com o TCP/UDP/IP/Ethernet, conforme expe
[PROFIBUS-06]. A figura 53 abaixo ilustra estrutura de dispositivo Profinet.
Figura 53: Estrutura de dispositivo Profinet

137
O Profinet foi o resultado do desenvolvimento de um padro que atende:
Roteamento direto do TCP/IP para Profibus;
Configurao e monitoramento de dispositivos Profibus via Ethernet e

Internet (TCP/IP);
Acesso de dados de dispositivos de campo em ambientes de TI;
Suporte a todas as configuraes Fieldbus;
Acessibilidade e utilizao de ferramentas de ambiente TI em dispositivos

de campo;
Comunicao em protocolo considerado totalmente aberto. A figura 54 ilustra a

aplicao de padro Profinet com acesso aos dispositivos via TCP/IP e Ethernet.
Figura 54: Integrao Profibus com Ethernet e TCP/IP

A comunicao pelo padro Profinet suporta 03 nveis de atuao:
Dados de engenharia e dados no urgentes so transmitidos pelo padro

Ethernet e TCP/IP. Esta comunicao padro ocorre entre dois dispositivos
de campo inteligentes em estrutura de automao distribuda;
Para transmisso de dados de processo urgentes, existe canal disponvel

de Tempo Real;
Para aplicaes de mecanismos sincrnicos tais como controle de

movimento, existe uma comunicao de tempo real que, uma taxa de
138
pulso horrio de menos de 1milisegundo, suporta uma taxa de exatido de

salto de 1microsegundo.
O Profinet considerado o primeiro padro aberto da Ethernet Industrial com
segurana integrada para aplicaes seguras tipo sem-fio (Wireless) que podem ser
adotadas em WLAN Industrial. [PROFIBUS-06]
7.3 Modbus
O padro Modbus um protocolo de comunicao de dados orientado
caracter, utilizado em sistemas de automao industrial. Foi desenvolvido pela
Modicon Industrial Automation Systems, atual Schneider, na dcada de 1970.
O Modbus tem sido largamente utilizado para redes de industriais pela
simplicidade e facilidade de implementao. A Schneider Electric disponibilizou as
normatizaes que definem o padro para domnio pblico, difundindo a tecnologia
do padro.
O padro Modbus apresenta como caractersticas:
Utiliza RS 232, RS 485 ou Ethernet TCP/IP para transmisso;
Estrutura de troca de mensagens/comunicao mestre/escravo entre

dispositivos inteligentes;
Possui comandos para envio de dados discretos (entradas e sadas digitais) ou

numricos (entradas e sadas analgicas).
No modelo de comunicao mestre/escravo, um nico dispositivo mestre inicia
a comunicao, solicitando aos demais dispositivos (considerados escravos) dados
e informaes requisitadas. Geralmente o dispositivo mestre o sistema
supervisrio.
A figura 55 a seguir apresenta o fluxo de troca de informaes no padro
Modbus.
139
Figura 55: Transaes entre dispositivos Modbus

Fonte: [ALBUQUERQUE-07]
No padro Modbus existem 02 modos de transmisso de dados:
ASCII (American Code for Information Interchange);
RTU (Remote Terminal Unit).
No modo ASCII, cada byte de mensagem encaminhado como dois caracteres

ASCII. A tabela 14 apresenta o formato da mensagem no modo ASCII.
Tabela 14: Formato mensagem ASCII
Start
(0x3A)
Endereo
2 chars
Funo
2 chars
Dados
N chars
CRC
2 chars
End
CRLF
Fonte: Adaptado de [ALBUQUERQUE-07]
No modo RTU, cada byte de mensagem enviado como dois caracteres

hexadecimais de 4 bits. A tabela 15 mostra o formato da mensagem no modo RTU.
Tabela 15: Formato mensagem RTU
Start
3..5 chars
Endereo
8 bits
Funo
8 bits
Dados
N x 8 bits
CRC
16 bits
End
3..5 chars
Fonte: Adaptado de [ALBUQUERQUE-07]
O Modbus esta baseado no modelo mestre-escravo, onde o dispositivo mestre

requisita informaes s estaes escravo. No modo requisio/resposta, o
dispositivo mestre encaminha uma requisio ao dispositivo escravo especfico.
O padro Modbus sofreu variaes, que foram feitas para integr-lo com outros
meios de transporte, tais como:
140
Modbus TCP/IP;
Modbus PLUS.
No padro Modbus TCP/IP, o Modbus esta implementado na camada de

aplicao da arquitetura TCP/IP. Quando o Modbus/TCP utilizado, o mecanismo
de controle e acesso o CSMA/CD e as estaes utilizam o modelo cliente/servidor.
[ALBUQUERQUE-07].
A figura 56 ilustra esta implementao.
Figura 56: Modbus TCP/IP

Fonte: [MODBUS-06]
Neste modelo, os dados so encapsulados em formato binrio, em frames TCP

para a utilizao do meio fsico Ethernet. O algoritmo de controle de acesso ao meio
de transmisso utilizado o CSMA/CD. [ALBUQUERQUE-07]
O padro ModbusPLUS dispe de recursos adicionais para roteamento,
diagnostico e endereamento, o modelo utilizado para controladores de processo,
para comunicao entre controladores lgicos programveis. O meio fsico de
utilizado o RS 485 com controle de acesso por meio do HDLC (High Level Data
Link Control) com taxas de transmisso de 1Mbps.
141
7.4 HART
O protocolo HART (Highway Addressable Remote Transducer) foi desenvolvido
pela Fisher Rosemount durante a dcada de 1980. O padro HART uma forma de
transmisso de dados em alta fidelidade para grandes distncias.
O protocolo foi aberto comunidade em 1990, definido pela norma HFC 5.0
[CUNHA-04]. Em 1993, foi criada a organizao HFC (Hart Communication
Foundation) para difundir a tecnologia.
A comunicao do protocolo HART tradicional (analgico) ocorre por meio de
sinal de 4 a 20 mA e por sinal digital, baseado em FSK (Frequency Shift Key
padronizao telefnica 202 Bell).
A topologia do padro HART possibilita diversos modos de comunicao: multimestre, mestre/escravo, multidrop, conforme expe [ALBUQUERQUE-07].
A figura 57 abaixo ilustra formato padro do comando HART.
Figura 57: Formato padro do Comando HART

Fonte: Adaptado de [HART-03].
A especificao do protocolo HART esta baseado no Modelo de Referncia

OSI; a camada fsica possilibita transmisso de bits entre dispositivos da rede e na
camada de aplicao definem-se os comandos do protocolo.
A figura 58 a seguir ilustra o as camadas do padro HART.
142
Figura 58: Camadas do padro HART.

Fonte: Adaptado de [HART-03]
O padro HART, inseriu a tecnologia wireless para o padro que ficou definido
como WirelessHART, sendo composto pelas camadas: fsica, enlace, rede,
transporte e aplicao e opera na faixa de freqncia de 2,4 GHz a 250Kbps.
Conforme
expe
[CAMPOS-09],
subcomit
ISA100.12
analisa
possibilidade do WirelessHART ser adotado como padro ISA100 para instrumentos

de campo.
7.5 WorldFip
O padro WorldFIP (World Factory Instrumentation Protocol) foi elaborado para
interligar sensores e atuadores; o desenvolvimento do padro levou a elaborao da
Norma Francesa NFC 46-600.
A proposta permite a interligao de sensores e atuadores, levando em
considerao as restries de tempo real impostas por um grande nmero de
aplicaes em nvel de cho-de-fbrica. No padro, definiu-se o modo de
transmisso produtor/consumidor, que possui mecanismo de controle centralizado
na comunicao. O padro possui as caractersticas de um barramento de campo.
Atualmente, o WorldFIP um padro europeu (EN50170) e utiliza o padro da
camada fsica IEC 1158-2, possuindo ainda um padro de mensagem MMS da ISO.
O padro utiliza as trs primeiras camadas do modelo OSI, ou seja, camada fsica,
camada link de dados e camada de rede.
143
Na camada fsica, o padro tem como meio de transmisso par tranado

(blindado ou no) e fibra ptica. O nmero de host por controlador pode ser de
sessenta e quatro por segmento, com at quatro segmentos com repetidores, os
cabos devem ser terminados em cada extremidade e a redundncia opcional.
O modo de transmisso sncrono e o mtodo de acesso ao meio
centralizado. Conforme
expe [STEMMER-01], para o par tranado esto
padronizadas trs velocidades de transmisso de dados:
S1: 31,25 Kbps, distncia de at 2000 m;
S2: 1 Mbps, distncia de at 500 m, com par tranado blindado;
S3: 2,5 Mbps, distncia de at 200 m, com par tranado blindado.
Para utilizaes com fibra tica, a velocidade permitida de 5 Mbps.

A velocidade S2 padro do modelo, as velocidades S1 e S3 so utilizadas
apenas para aplicaes especiais, onde S1 e utilizada em rea sujeitas exploso e
o S3 utilizado em aplicaes de desempenho elevado.
O padro suporta at duzentas e cinqenta e seis estaes e o barramento
principal pode ser decomposto em segmentos, podendo ser interligado por
repetidores. A camada de enlace do WorldFIP no faz uma distino formal entre as
subcamadas LLC e MAC, como proposto na norma IEEE 802.
O mtodo de acesso ao meio baseado na difuso (broadcasting), organizada
por uma entidade centralizada denominada rbitro do barramento. O padro
WorldFIP teve como base o fato de que a informao em rede industrial pode ser
compartilhada para varias outras estaes na rede. A maioria dos dados
transmitidos pelo barramento de campo representada por objetivos variveis com
um nico nome no sistema. Um objeto definido por um nico transmissor,
classificado pelo modelo de transmisso como produtor e os receptores da rede so
definidos como consumidores, sendo que a comunicao ocorre quando:
[STEMMER-01]
Num primeiro momento, o rbitro difunde na rede o nome da varivel

(objeto) a ser transmitida (quadro de identificao);
O produtor da varivel difunde, em seguida, a informao ligada ao

identificador (quadro de dados);
144
Todos os consumidores interessados passam a copi-la na fase final.

Devido utilizao da difuso, os endereos de transmissores e receptores
no precisam ser conhecidos pela aplicao. Cada estao completamente
autnoma e o nico requisito imposto s estaes o de difundir, por solicitao do
rbitro de barramento, as variveis por elas produzidas.
A transmisso de mensagens atende a norma IEEE 802.2 LLC (protocolo
desenvolvido para controle de transmisses de dados no nvel de enlace do
protocolo MAC, inclui sistema de endereamento e verificao de erros) tipos 1 e 3.
A figura 59 ilustra o formato do frame FIP.
Figura 59: Formato do frame FIP

Fonte: [STEMMER-01]
Na camada de enlace, so especificados os seguintes servios: [STEMMER01]
Atualizao cclica de dados;
Atualizao no peridica de dados;
Transferncia de mensagem com ACK;
Transferncia de mensagem sem ACK.
Na camada de aplicao do padro WorldFIP, foi proposto implementao de

um subconjunto do MMS, onde foram definidos servios para mensagem industrial,
alm da criao de uma segunda classe de servios, a MPS (Message Periodic /
Aperiodic Services).
145
O WorldFIP possui tambm implementaes de gerenciamento de rede, que

permitem configurar rede, implementaes de testes, deteco e correo de falhas,
atualizaes de lista de objetos e tabelas alm de funes de gerenciamento de
operaes de partida e parada.
7.6 EtherNet/IP (Ethernet Industrial Protocol)

O protocolo EtherNet/IP (Ethernet Industrial Protocol) foi desenvolvido pelo
ODVA (Open DeviceNet Vendor Association).
Conforme expe [SOUSA-03], o protocolo define o modelo de comunicao
entre dispositivos produtor/consumidor. O padro esta baseado na Ethernet, definida
pela especificao IEEE 802.3 juntamente com protocolo CIP (Control Information
Protocol).
A figura 60 abaixo ilustra a estrutura do protocolo EtherNet/IP.
Figura 60: Arquitetura EtherNet/IP

Fonte: Adaptado de [ODVA-07b]
Na arquitetura EtherNet/IP, as mensagens so encapsuladas via protocolos

TCP ou UDP na camada de transporte. Conforme expe [ODVA-07a], devido ao
mtodo cclico possuir melhor desempenho, o EtherNet/IP comumente utiliza o UDP
para transporte de mensagens.
A figura 61 a seguir ilustra a estrutura de encapsulamento de mensagens.
146
Figura 61: Encapsulamento de mensagens EtherNet/IP

Fonte: Adaptado de [ODVA-07a]
No cabealho de encapsulamento de mensagens no disposto campo para

distino entre mensagens de requisio e mensagens de respostas, portanto as
transmisses so definidas em: [LUGLI-07]
Implcitas, que utilizam o UDP e a camada CIP;
Explcitas, que utilizam o TCP e a camada CIP.
Conforme expe [FELSER-04]1 [ETHERNET-01]2 apud [LUGLI-07], a camada

de aplicao CIP no oferece comunicao com a camada de aplicao Profinet,
no havendo, portanto, interoperabilidade entre as diversas redes Ethernet.
7.7 CAN
O CAN foi normalizado pela ISO em 1993 e esta implementado em larga
escala em diversos produtos comerciais, onde o padro ISO 11898 (at 1 Mbits/seg)
destinado para comunicao serial de alta velocidade e o padro ISO 11519 (at
125 Kbits/seg) utilizado em baixas velocidades. [ALBUQUERQUE-07]
FELSER, Max; SAUTER Thilo. Standardization of Industrial Ethernet the Next Battlefield?
th
IEEE Article, 6 IEEE International Workshop on Factory Communication Systems, Vasteras,
Sweden, 2004, 413-421 p. [FELSER-04]
2
Ethernet/IP Specification Release 1.0 June, 2001. Norma Ethernet/IP. ODVA, 2001.
[ETHERNET-01].
147
Conforme expe [CABRAL-05], o protocolo CAN implementa um mecanismo

de acesso ao meio MAC (Medium Access Control), do tipo CSMA-CA (Carrier Sense
Multiple Access Colision Avoidance), onde o barramento deve estar livre para a
estao iniciar a transmisso, livre de colises.
O mecanismo de resoluo de coliso baseado no campo Arbitration Field. O
barramento utiliza o NRZ (non-return to zero) para bit-stuffing1.
A estrutura do protocolo CAN ilustrada na figura 62 abaixo.
Figura 62: Estrutura do protocolo CAN

Fonte: Adaptado de [CABRAL-05]
O protocolo CAN serviu como base para o desenvolvimento do padro

DeviceNet.
O DeviceNet foi elaborado pela Allen Bradley e possui especificao aberta,
define uma rede baseada no mtodo de transmisso produtor/consumidor.
[STEMMER-01].
Para o desenvolvimento de hardware baseado no protocolo DeviceNet, os
fabricantes devem ser licenciados pelo ODVA (Open DeviceNet Vendor Association).
No caso de protocolos orientados a bit, a tcnica Bit Stuffing permite que o usurio envie qualquer
seqncia de bits como informaes que contenham seqncias de bits de flag no sejam
confundidas com os delimitadores da mensagem. [http://penta.ufrgs.br/tp951/protocolos/6bitstu.html]
148
A figura 63 abaixo as camadas do protocolo DeviceNet.
Figura 63: Camadas do padro DeviceNet.

Fonte: Adaptado de [STEMMER-01]
O padro DeviceNet prove trfego de dados por meio de comunicao:

produtor/consumidor, polling, cyclic, multi-master e multicast.
7.8 LONWorks
A rede operacional local LONWorks (LON Local Operating Network) foi
desenvolvida pela Echlon em 1990. O protocolo possui grande utilizao na
automao predial e de sistemas de escritrios (edifcios). Conforme expe
[CHERMONT-07], a arquitetura de protocolos LonWorks, define uma arquitetura
aberta.
As redes LonWorks so caracterizadas como redes peer-to-peer.
Os principais componentes da de LONWorks so: [ALBUQUERQUE-07]
Protocolo de LonTalk;
Chips Neurais;
Transceptores;
Administrao de cadeia;
Software de aplicao.
149
O protocolo LonTalk esta especificado pela norma ANSI/EIA/CEA 709.1, sendo

um conjunto de servios que viabilizam a comunicao entre os dispositivos da rede
LON. Conforme expe [STEMMER-01], o protocolo LonTalk esta baseado no
Modelo de Referencia OSI e implementa as sete camadas previstas.
Conforme cita [LONWORKS-09], em 2009, o protocolo LonWorks foi ratificado
como um padro global para sistemas de controle em edificaes, sendo definida a
norma ISO / IEC 14908-1.
O protocolo prov um conjunto de servios que possibilita que um programa de
aplicao do dispositivo enviar e receber mensagens de e para outros dispositivos
de rede sem a necessidade de conhecer a topologia da rede ou a outros dispositivos
nomes, endereos ou funes.
O protocolo LonWorks (ISO/IEC14908-1) e as redes LonWorks, podem ser
implementadas atravs de qualquer meio fsico, incluindo a linha de fora, par
tranado, rdio freqncia (RF), infravermelho (IR), cabos coaxiais e fibras pticas.
7.9 BACNet
O padro BACNet (Building Automation and Control NETworks) foi elaborado
em 1987. O protocolo esta especificado pela normas ISO16484 e ANSI/ASHRAE
135/1995, tendo sido definido inicialmente pela ASHRAE (American Society of
Heating, Refrigerating and Air-Conditioning Engineers), definido como um protocolo
aberto e de alto desempenho.
A comunicaao BACNet baseada no modelo cliente/servidor; o equipamento
denominado cliente envia um pedido de alguma funo para o servidor que a
processa e envia de volta o resultado obitido. As redes BACNet definem trinta e
cinco tipos de mensagens divididas em cinco grupos de classes que vo desde
alarmes, eventos e funes definidas.
O padro BACNet opera a taxas de 9600 a 76800 bps, com possibilidade de
ate 127 dispositivos por segmento. As principais aplicaes do padro so
realizadas em automao predial, sistemas de climatizao, inversores de
freqncia e instrumentao.
150
Os diversos protocolos e padres para comunicao industrial foram

desenvolvidos para aplicaes especficas destinadas ao trfego de dados no
ambiente industrial. Nota-se o surgimento de vrios padres que incorporaram a
Ethernet e o TCP/IP em suas arquiteturas como forma de torn-los flexveis quanto a
atender todos os nveis para o trfego de informaes, inclusive no ambiente
corporativo.
A figura 64 ilustra e situam alguns padres citados neste trabalho dentro do
contexto corporativo e industrial.
Figura 64: Aplicao de redes industriais

Fonte: Adaptado de [GEORGINI-00]
151
8. SISTEMAS DE AQUISIO DE DADOS

Os sistemas de monitoramento dedicados automao industrial tm como
objetivo a elevao do desempenho dos dispositivos interligados ao sistema
automatizado, assegurando modularidade e escalabilidade da planta industrial, alm
de facilidades de programao e integrao de novos dispositivos aliados
segurana, confiabilidade e robustez do sistema industrial.
Os elementos que compem o sistema de automao: sensores, transdutores,
atuadores, dispositivos de aquisio de dados, unidades remotas, CLPs; devem ser
supervisionados para que tais objetivos possam ser atingidos. Confome define
[ALBUQUERQUE-07], o controle supervisrio denota o processo de monitorar
distncia uma atividade, transmitindo diretrizes de operao aos controladores
localizados distncia e recebendo de volta a indicao da realizao das aes de
controle.
Em sistemas baseados em redes de barramentos de campo, so utilizados
sistemas de controle e aquisio de dados (SCADA Supervisory Control & Data
Acquisition Systems) para esta finalidade.
A figura 65 ilustra uma aplicao de
sistema supervisrio.
Figura 65: Aplicao de Sistema Supervisrio

Fonte: [SILVA-05]
152
A evoluo dos sistemas SCADA esta ligada ao desenvolvimento dos atuais

sistemas de informao e computao, e conforme expe [NCS-04], os sistemas
SCADA podem ser classificados em trs geraes, sendo:
Primeira gerao - sistemas monolticos;
Segunda gerao - sistemas distribudos;
Terceira gerao - sistemas Networked.
Os sistemas SCADA monolticos esto associados ao conceito de computao

centralizada no mainframe, oferecendo poucas possibilidades de comunicao com
outros sistemas; a figura 66 ilustra este tipo de sistema.
Figura 66: Gerao de sistemas SCADA monolticos

Fonte: [NCS-04]
Os sistemas SCADA distribudos evoluram a partir dos sistemas monolticos

com utilizao das redes LAN, onde a maioria dos protocolos de comunicao
utilizados eram proprietrios. A utilizao de sistemas distribudos permitiu a
elevao da capacidade de processamento, aumento da confiabilidade com
utilizao de tcnicas de redundncia.
A figura 67 a seguir ilustra este tipo de sistema.
153
Figura 67: Gerao de sistemas SCADA distribudos

Fonte: [NCS-04]
Os atuais sistemas de terceira gerao caracterizam-se pelas arquiteturas

abertas de comunicao, utilizando padres abertos de comunicao, que possibilita
que mltiplos sistemas compartilhem dos recursos de estaes master.
A incluso de sistemas SCADA em arquiteturas abertas de comunicao
tornou possvel a expanso destes sistemas em redes WAN e no apenas em LAN
com utilizao de protocolos IP (Internet Protocol) e redes Ethernet. A figura 68
mostra este tipo de arquitetura, que permitiu aumento da confiabilidade dos sistemas
por meio de alternativas de roteamento de comunicao.
Figura 68: Gerao de sistemas SCADA Networked

Fonte: [NCS-04]
154
Nos sistemas atuais sistemas SCADA a interao com o usurio obtida por
meio de interface grfica que representa a planta ou processo industrial monitorado,
sendo necessrios hardware e software especficos para esta finalidade.
Implementaes realizadas em sistemas SCADA definem a prxima gerao
de sistemas supervisrios que se baseiam no modelo de Orientao Objeto, que
possui abordagem promissora para especificao de arquiteturas complexas, visto
que: [ZOLDAN-04]
Um sistema baseado em modelo orientado objetos pode ser descrito

como uma rede de dispositivos interconectados, provendo uma arquitetura;
As propriedades do modelo orientado objeto podem ser herdadas de outro

objeto, fundamentais para o desenvolvimento de arquiteturas complexas,
que caracteriza o recurso da herana.
O conceito de orientao objeto no desenvolvimento de sistemas industriais

de tempo real tem sido utilizado, uma vez que permite a estruturao de informaes
de forma lgica para sistemas complexos. Conforme expe [ZOLDAN-04], o reuso
de software a principal vantagem na orientao a objetos, eliminando a
redundncia de cdigo, que uma das principais dificuldades dos implementadores
ou mantenedores de softwares CLP e SCADA.
As arquiteturas convencionais de sistemas supervisrios SCADA provem
suporte duas hierarquias de rede, sendo:
Redes de Informao;
Redes de controle.
O sistema supervisrio convencional possibilita que informaes do processo

produtivo possam ser monitoradas, coletadas por meio de dispositivos de aquisio
de dados e os dados manipulados, analisados e armazenados em banco de dados
para posterior utilizao de usurios do sistema. Um sistema supervisrio deve
apresentar funcionalidades bsicas, entre as quais se destacam: [PINHEIRO-06]
Aquisio de dados, processo que envolve a coleta e transmisso de dados

desde a planta industrial (estaes remotas) at as estaes centrais de
monitorao;
155
Visualizao de dados consiste na apresentao das informaes atravs

de interfaces grficas. A figura
69 ilustra exemplo de visualizao de
processo industrial [JURIZATO-02];
Figura 69: Tela grfica SCADA

Fonte: [JURIZATO-02]
Processamento de alarmes, onde os alarmes so classificados por nveis

de prioridade em funo da sua gravidade. Na ocorrncia de falha do
servidor ou da rede de comunicaes, possvel efetuar o armazenamento
das mensagens de alarme em buffer;
Tolerncia a falhas, para atingir nveis aceitveis de tolerncia a falhas

usual a existncia de informao redundante na rede e de estaes de
monitoramento.
Os controladores lgicos programveis espalhados na planta industrial enviam

sinais eltricos para o sistema supervisrio SCADA, por meio de TAGs (mensagens
digitais). As mensagens digitais TAGs podem ser do tipo: [MORAES-07]
Device; significa que os dados se originaram de CLPs para o sistema

supervisrio;
DDE (Dynamic Data Exchange); significa que os dados se originaram de um

servidor;
Memory; mostra que os dados existem localmente no sistema supervisrio.
Os sistemas supervisrios SCADA operam, conforme expe [MORAES-07] de

forma geral em dois modos: o modo de desenvolvimento (Development Time) e o
modo de execuo (Run Time).
156
8.1 Componentes de Sistemas Supervisrios SCADA

Os principais componentes fsicos de um sistema supervisrio SCADA podem
ser descritos como: [SILVA-05]
Sensores;
Atuadores;
Estaes remotas, (RTU - Remote Terminal Units), onde ocorre o

processamento dos dados colhidos. Os CLPs desempenham funes
anlogas s RTUs: a coleta, processamento e armazenamento das
informaes em base de dados no controle central do sistema SCADA.
Sistemas de comunicao, definido pelas redes de comunicao, que

constitui a plataforma por onde as informaes do sistema so transferidas
para o controle central.
Estao de controle central, (estao master), que executa a superviso e

monitoramento do sistema SCADA, constituindo-se na unidade principal do
sistema.
Existem trs componentes de software para a estao master: o sistema

operacional, a plataforma SCADA e o aplicativo de superviso. As estaes master
podem ser centralizadas em nico computador ou distribudas em rede,
possibilitando compartilhamento de recursos do sistema.
A figura 70 a seguir ilustra integrao de sistemas SCADA.
157
Figura 70: Integrao de sistema SCADA

Fonte: [EFACEC-06]
Conforme expe [SILVA-05], os sistemas SCADA podem ter divididas as

principais tarefas em blocos ou mdulos, que vo permitir maior ou menor
flexibilidade e robustez, de acordo com a soluo desejada. Em linhas gerais, estas
tarefas podem ser divididas em:
Ncleo e sistema de processamento;
Comunicao com outros sistemas SCADA e com CLPs/RTUs;
Lgicas de programao interna (Scripts) ou controle;
Comunicao com clientes externos / sistemas externos;
Protocolos de comunicao.
O funcionamento dos atuais sistemas SCADA parte dos processos de

comunicao com os equipamentos de campo, cujas informaes so enviadas ao
sistema que constitui o ncleo principal do software. A comunicao tambm
possibilita a troca de dados entre estaes do sistema, compartilhamento de dados,
alm de acesso a outras redes.
O ncleo principal (estao master) responsvel por distribuir e coordenar o
fluxo de informaes para os demais mdulos, at atingirem a forma desejada pelo
158
operador do sistema, geralmente em forma grfica; as estaes master utilizam

sistemas operacionais, que podem ser UNIX, LINUX, DOS e Windows.
Conforme expe [NCS-04], atualmente, no segmento industrial existem
diversos protocolos de comunicao para sistemas supervisrios SCADA, dentre os
quais o IEC 60870.5 (International Electrotechnical Commission) e o DNP 3
(Distributed Network Protocol version 3.0).
O protocolo IEC foi elaborado com base no modelo OSI, tendo sido publicado
em 1995 como padro IEC 60870.5; o DNP 3, considerado como protocolo aberto,
conforme expe [NCS-04], desenvolvido em novembro de 1993, e publicado pela
Harris Distributed Automation Products, o protocolo transporta dados de valores
genricos, com conjunto extensivo de funes tendo sido desenvolvido inicialmente
para sistemas de distribuio de energia eltrica, que posteriormente teve aceitao
na industrial, atuando em diversos sistemas SCADA.
8.2 Modos de Comunicao SCADA

A comunicao de um sistema SCADA convencional est diretamente
relacionada troca de informaes entre os dispositivos de campo e estaes
mster, por meio de protocolos abertos ou proprietrios, que podem ser: [MORAES07]
Comunicao com IED (Intelligent Electronic Devices, CLP/RTU);
Comunicao com outras estaes SCADA;
Comunicao com outros sistemas.
Os protocolos de comunicao entre estaes master e dispositivos de campo

atendem a dois mtodos: por polling ou por interrupo (tambm designado por
Report by Exception).
A comunicao pelo mtodo polling (master/slave) faz com que a estao
central
(master)
tenha
controle
absoluto
das
comunicaes,
efetuando
seqencialmente o polling aos dados das estaes remotas (slave), que apenas
respondem estao central aps a recepo da solicitao, ou seja, em halfduplex. O mtodo traz simplicidade no processo de aquisio de dados devido
reduo de colises no trfego da rede; define comportamento determinstico;
159
facilidade na deteco de falhas de ligao e uso de estaes remotas sem

processamento. [MORAES-07]
No mtodo de comunicao por interrupo (Report by Exception), ocorre
quando um IED (CLP ou RTU) monitora os seus parmetros de entrada e, ao
detectar alteraes significativas de valores que ultrapassem os limites definidos,
envia as informaes para a estao central. Isto evita a transferncia de informao
desnecessria, diminuindo o trfego na rede, alm de permitir uma rpida deteco
de informao urgente e a comunicao entre estaes remotas escravo para
escravo (slave-to-slave). [MORAES-07].
8.3 Sistema Supervisrio SCADA Orientado Objeto

Conforme expe [ZOLDAN-04], a partir de 1989 iniciaram-se estudos para o
desenvolvimento de sistemas de controle orientado objetos. Projetos de
desenvolvimento foram conduzidos na Europa pela ERSF (European Synchrotron
Radiation Facility) e deram origem ao TACO (Telescope and Accelerator Controller
with Objects).
Utilizando
tecnologias consolidadas como RPC (Remote Procedure Call) o
TACO props a aplicao de um sistema de controle orientado objeto.

Com base no padro CORBA (Common Object Request Broker Architecture),
foi elaborado o sistema TANGO (Taco Next Generation Object), baseado em
linguagens Java e C++, o TANGO atua nas plataformas Linux, NT, entre outros
sistemas operacionais.
Baseado na programao orientada objeto, foram desenvolvidos , conforme
aborda [ZOLDAN-04], sistemas supervisrios como EPICS (Experimental Physics
and Industrial Control System), IOC (Input-Output Controller) e SCADA ++.
Utilizando linguagem de programao de alto nvel, o SCADA++ se difere dos
sistemas SCADA convencionais que utilizam linguagens de baixo nvel.
O SCADA++ esta especificado no IEEE C37.1 para aplicao em sistemas
supervisrios e de automao.
A tabela 16 a seguir ilustra as principais caractersticas do sistema supervisrio
SCADA++.
160
Tabela 16: Caractersticas de Supervisrios SCADA++
Fonte: Adaptado de [ZOLDAN-04]
A figura 71 abaixo ilustra interface grfica desenvolvida por meio de packages

do JAVA, que implementa o sistema supervisrio SCADA++.
Figura 71: Interface grfica SCADA++

Fonte: [ZOLDAN-04]
161
9. GERENCIAMENTO DE REDES
O gerenciamento de redes se constitui num sistema de extrema importncia
para o rastreamento e correo de problemas oriundos em redes de transmisso de
dados e em seus componentes, bem como monitorar o desempenho da rede de
comunicao; possibilita a gerao de grficos e relatrios para anlises e
implementaes.
O modelo clssico de gerenciamento de redes pode ser sintetizado em 03
etapas, sendo: [CARVALHO-93]
Coleta de dados: consiste no processo de monitoramento dos recursos

disponveis na rede;
Diagnstico: etapa que realiza a anlise e tratamento a partir de dados

coletados;
Ao ou controle: uma vez detectado e diagnosticado o evento, o

gerenciamento deve possibilitar ao corretiva sobre o dispositivo
gerenciado.
Devido
ao
crescente
desenvolvimento
de
redes
heterogneas
de
computadores e diversidade de arquiteturas de redes, a tarefa de gerenciamento

torna-se imprescindvel. Vrios esforos tm sido intensificados desde os anos de
1980 para definio de arquiteturas para gerenciamento de redes heterogneas de
computadores em ambientes de TI de forma padronizada e aberta e que ofeream
confiabilidade.
O gerenciamento de dispositivos de rede muito amplo, envolvendo reas
funcionais de:
Gerenciamento de falhas;
Gerenciamento de configurao;
Gerenciamento de contabilizao;
Gerenciamento de desempenho;
Gerenciamento de segurana.
162
Conforme expe [CARVALHO-93], o gerenciamento de redes deve coordenar

os recursos materiais, hardwares (equipamentos, estaes, switches, hub, etc.) e
recursos lgicos, softwares, (protocolos de arquiteturas, protocolos de comunicao,
aplicativos, sistemas operacionais, etc.) assegurando confiabilidade, tempos de
resposta aceitveis e segurana s informaes. A arquitetura de gerenciamento
que esteja incumbida de gerenciar redes e seus dispositivos deve incorporar as
seguintes caractersticas:
O gerenciamento deve ser parte integrante da rede;
Possibilitar vrios pontos de acesso ao gerenciamento da rede (estaes de

controle e/ou gerenciamento);
Disponibilizar informaes sobre a rede, estatsticas do desempenho,

eventos ocorridos, sejam estes normais ou com problemas, devero ser
passveis de obteno de forma centralizada e organizados para facilitar a
compreenso;
Possibilitar adoo de esquema de tratamento prioritrio que possibilite que

as mensagens de controle da rede precedam outros tipos de trfego;
Possibilitar existncia de mecanismos de segurana que limitem e controle

e acesso a rede e detectem uso no autorizado rede;
Possibilitar
que
funes
de
gerenciamento
de
rede
operem
independentemente do meio de transmisso utilizado;
Deve possibilitar existncia de banco de dados que contenha informaes

sobre todos os componentes e dispositivos da rede e de seus usurios;
Alteraes e redirecionamentos na rede devem ser efetivados de forma flexvel

e simples.
Para que o gerenciamento de redes torne-se ser eficiente, este deve permitir o
gerenciamento em ambientes diversos e heterogneos, independente dos
dispositivos que compem tal sistema. O gerenciamento de falhas utiliza hardware e
software implementados, que possibilitem o gerenciamento para alertar os
administradores (ou programas gerentes, que so aplicativos implementados com
atribuio de gerenciamento propriamente dito em uma rede) a respeito de falhas e
auxiliar no reparo.
163
A figura 72 abaixo ilustra sistema de gerenciamento em arquitetura distribuda.
Figura 72: Arquitetura de sistema de gerenciamento tipicamente distribudo.

Fonte: Adaptado de [STALLINGS-99]
Conforme expe [OLIFER-08], a disponibilidade de vrios gerentes possibilita

que a carga seja distribuda, permitindo a escalabilidade do sistema. Normalmente
so utilizados dois tipos de enlaces para a conexo de gerentes: no hierrquico e
hierrquico.
A figura 73 a seguir ilustra estas conexes.
164
Figura 73a: Conexes no hierrquicas (peer-to-peer) entre gerentes
Figura 73b: Conexes hierrquicas entre gerentes

Em virtude da complexidade que as redes possam atingir, bem como a

diversidade de dispositivos implementados, o sistema de gerenciamento deve
permitir que sejam utilizados sistemas de tolerncia a falhas e/ou redundncias de
hardware e software, que podem continuar a oferecer servios na rede, mesmo na
ocorrncia de eventual falha da rede. [CARVALHO-93] cita que as principais
ferramentas utilizadas para gerenciamento de falhas devem atender as seguintes
caractersticas:
Sistema de gerenciamento da rede, composto por hardware e software que

possibilite monitorar funcionamento dos componentes da rede;
Analisador de protocolo, constitudo por implementaes de hardware e

software que monitorem o trfego de rede;
165
Implementao que possibilite verificar meio fsico de transmisso;
Sistemas redundantes de hardware e software;
Implementaes
para
gerenciamento
de
desempenho;
enquanto
gerenciamento de falhas possui caracterstica reativa, o gerenciamento de

desempenho possui um aspecto ativo essencial, visto que coleta e
interpreta informaes peridicas de indicadores de desempenho, avaliando
tendncias do sistema;
Implementaes para gerenciamento de segurana, que consiste em

proteger dados e seus respectivos equipamentos, sejam hardware e
software.
A integrao de implementaes e funes de gerenciamento de redes no

pode ser tratada somente como adio de recursos aos equipamentos, mas como
aes necessrias que agregaro segurana, eficincia e confiabilidade aos
sistemas.
Nas arquiteturas de redes a estratificao de funes em nveis, onde o
gerenciamento deve ser parte das funes inerentes para cada nvel. Conforme
expe [CARVALHO-93], avanos da rea de gerenciamento de rede ocorreram com
a utilizao de sistemas especialistas; na rea de gerenciamento de falhas, por
exemplo, sempre que um problema ocorre o sistema tenta tomar decises, analisa o
histrico de ocorrncias do sistema, reduz o trabalho rotineiro executado por
operadores de rede.
Por meio de anlise de trfego das redes, o sistema sugere alteraes que
visam aperfeioar os custos das redes, mantendo disponveis os nveis de servio.
Algumas solues de gerenciamento de redes utilizam ferramentas e
aplicativos proprietrios, de diferentes fornecedores, que no se comunicam entre si,
aumentando os custos e ineficincia do gerenciamento de redes, fazendo com que a
integraes entre tais sistemas tornem-se onerosas e pouco eficientes devido
abrangncia dos recursos que estaro sendo disponibilizados para integrao.
Os sistemas de gerenciamento de um nico fornecedor trabalham de forma
integrada, porm, com limites de abrangncia, fazendo com que os usurios utilizem
somente os produtos deste fornecedor independente de custos e eficincia tcnica.
166
Uma maneira de resolver o problema de abrangncia, em que apenas um nico

fornecedor tende a gerenciar o sistema seria a adoo de APIs (Application Program
Interfaces) ou sistemas que atenuem a heterogeneidade.
A utilizao de APIs trouxe, alm de uma soluo para o problema de
integrao, a possibilidade dos usurios se adaptarem aos sistemas proprietrios de
gerenciamento e suas caractersticas. Evidente que, nenhum sistema de
gerenciamento de redes atende s diferentes necessidades especficas de usurios
e suas respectivas peculiaridades, portanto a utilizao de APIs possibilita que cada
usurio elabore seu ambiente de gerenciamento atendendo estas necessidades.
Os esforos para o desenvolvimento de APIs so enormes, visto que cada
componente e dispositivo de rede apresenta caractersticas diferentes, que
adicionado a rede implica no desenvolvimento de uma nova API. Cabe, contudo
salientar que as limitaes do sistema como um todo esto sempre relacionadas ao
componente de menor capacidade em fornecer dados. Como forma de contornar
este problema, muitos fornecedores desenvolveram aplicaes baseadas em
padres de facto de mercado.
Dentre vrias solues que foram desenvolvidas, entretanto, as que se
destacaram devido aceitao foram o SNMP (Simple Network Management
Protocol), protocolo aplicado arquitetura TCP/IP e o CMIP (Common Management
Information Protocol), baseado na arquitetura OSI.
Para a implementao de um sistema de gerenciamento, uma das primeiras
etapas a anlise da arquitetura de rede de comunicao existente e a seleo do
modelo de gerenciamento.
O protocolo CMIP atua no nvel de aplicao do modelo OSI, sendo protocolo
orientado a conexo, utiliza servios do ASCE (Association Control Service
Element), ROSE (Remote Operations Service Element). O padro CMIP para
gerenciamento no modelo OSI tem sido apoiado pela OSF/DME (Open Software
Foundation / Distributed Management Environment).
A figura 74 a seguir ilustra modelo de gerenciamento OSI/CMIP.
167
Figura 74: Modelo de gerenciamento OSI

O sistema de gerenciamento CMIP esta baseado em modelo orientado

conexo, utiliza filosofia de aquisio de informaes dos dispositivos gerenciados
por polling e por tcnica de notificao. Para realizar atividades de gerenciamento o
CMIP necessita de maior capacidade de processamento e memria em relao a
outras solues de gerenciamento como o SNMP. [CARVALHO-93]
O SNMP opera no padro TCP/IP e Ethernet, com modo de acesso no
orientado a conexo e possui comandos que permitem ao usurio requisitar
informaes de seus objetos ou ate mesmo agir sobre eles. A arquitetura SNMP
pressupe a existncia de estaes de gerenciamento, onde as aplicaes de
gerenciamento e elementos gerenciados da rede (roteadores, estaes e
dispositivos de comunicao) operam. Pela concepo, a aquisio de informaes
no SNMP feito por polling, isto , periodicamente indaga cada recurso sobre o seu
status, adicionalmente definido o mecanismo de TRAP, por meio do qual um
recurso informa ao gerente que precisa ser submetido ao polling.
168
As implementaes em SNMP tendem a ser rpidas, visto pouca capacidade

de processamento e memria.
O SNMP no um padro internacional de jure, embora tenha se tornado de
facto, e os fabricantes verificam suas implementaes somente por meio de testes
de interoperabilidade.
Os primeiros a implementarem a soluo SNMP foram os fabricantes de
gateways, bridges, switches e roteadores. Atualmente esta soluo implementa
vrios dispositivos como no-breaks, sistemas de automao, como CLPs e sistemas
de telemetria.
9.1 Protocolo de Gerenciamento SNMP

Uma interligao de redes heterogneas necessita de um sistema de
gerenciamento que possibilite aos administradores detectar problemas, controlar o
trfego de informaes e localizar componentes que estejam violando os padres e
parmetros estabelecidos. Estas atividades so fundamentais no gerenciamento,
alm de permitir a troca de informaes e dados entre os dispositivos que compe a
rede.
O protocolo SNMP atende s necessidades de gerenciamento de redes
baseadas no padro TCP/IP e Ethernet. O protocolo realiza o gerenciamento
utilizando associao com MIB (Management Information Base).
Muitas redes incluam implementaes de gerenciamento como parte de seus
protocolos na estrutura de gerenciamento de redes. Ao contrrio das redes remotas,
uma interligao em redes TCP/IP no possui um nico protocolo no nvel de enlace.
Em vez disto, a interligao em redes consiste em vrias redes fsicas
interconectadas por meio de roteadores IP, onde os roteadores formam os
comutadores ativos que os administradores precisam analisar e controlar. Como os
roteadores conectam-se redes heterogneas, os protocolos para gerenciamento
da interligao em redes operam em nvel de aplicao e para sua comunicao
utilizam os protocolos de nvel da camada de transporte TCP/IP.
Conforme expe [CARVALHO-93] existem trs tipos de gerenciamento:
gerenciamento de sistemas, gerenciamento de camada e operao da camada. Por
169
meio da utilizao de protocolos de gerenciamento de sistemas da camada de

aplicao que se realiza o gerenciamento de sistemas.
A atuao de gerenciamento com software aplicados ao nvel de camada de
aplicao apresenta algumas vantagens. Os protocolos podem ser desenvolvidos
sem levar em considerao o hardware bsico da rede, uma pilha de protocolos
pode ser utilizada para todas as redes. Ainda, os protocolos podem ser projetados
sem considerar o hardware do equipamento gerenciado, eles podem ser utilizados
para todos os dispositivos gerenciados. [TOVAR-96]
O protocolo de gerenciamento de redes SNMP foi lanado em 1988 para
atender a necessidade cada vez maior de um padro para gerenciar os dispositivos
IP. O SNMP prov ao usurio um conjunto de operaes simples que possibilitam o
gerenciamento remoto destes dispositivos implementados com arquiteturas TCP/IP e
Ethernet.
Inicialmente, o SNMP esteve associado ao gerenciamento de roteadores,
switches, racks de modem, entre outros equipamentos, entretanto, a arquitetura do
protocolo permite que possa ser pode ser utilizado para gerenciar vrios tipos de
dispositivos, como sistemas de energia, no-breaks e controladores lgicos
programveis. A figura 75 ilustra a aplicao do SNMP.
Figura 75: Aplicao do protocolo SNMP

Fonte: [LOPES-02]
170
O SNMP difundiu-se e popularizou-se nas dcadas de 1980 e 1990, essa

popularizao conduziu a reavaliao de suas deficincias, principalmente ligadas
falta de implementaes de mecanismos de segurana, autenticao e privacidade;
as implementaes levaram ao desenvolvimento do protocolo com a verso 3 do
SNMP.
O SNMP um protocolo destinado ao gerenciamento de redes, que permite de
forma simples, em tempo real conhecer o status da rede e dispositivos conectados.
A arquitetura inicial SNMP derivou do SGMP (Simple Gateway Management
Protocol), protocolo desenvolvido para gerenciar roteadores e equipamentos de
interconexo de uma rede TCP/IP. A primeira verso do SNMP apresentava
informaes para gerenciamento e controle desses dispositivos de interconexo, o
que determinou as escolhas dos elementos componentes da arquitetura SNMP.
O protocolo esta implementado na camada de aplicao da arquitetura TCP/IP,
e utiliza o UDP (definido na RFC 768) como protocolo de transporte na comunicao
entre cliente e servidor. O SNMP um protocolo no orientado conexo, uma vez
que utiliza o TCP em sua arquitetura, que por no ter nenhuma conexo ponto-aponto estabelecida entre agentes e gerente da rede.
Conforme expe [SCHMIDT-01], o protocolo utiliza a porta 161 do UDP para
enviar e receber solicitaes e a porta 162 para receber traps (mensagens de
alarmes/eventos) de dispositivos gerenciados.
Todo dispositivo que implementa o SNMP deve utilizar estes nmeros como
portas default, porm alguns fornecedores permitem modificar as portas na
configurao do agente. Quase todos os fabricantes de computadores, estaes de
trabalho, roteadores, hubs, etc., oferecem a soluo SNMP como ferramenta de
gerenciamento.
A tabela 17 a seguir apresenta a lista de RFCs que especificam o SNMPv1.
171
Tabela 17: RFCs relacionadas com SNMPv1
RFC
1155
Data
Mai/90
1157
1212
1213
Mai/90
Mar/91
Mar/91
1643
Jul/94
Titulo
Structure and Identification of Management Information
(SMI) for TCP/IP based Internet
A Simple Network Management Protocol (SNMP)
Concise MIB Definitions
Management Information Base for Network
Management of TCP/IP based Internet: MIB II
Definition of Managed Objects for the Ethernet-like
Interface Types
Fonte: Adaptado de [SCHMIDT-01]
O funcionamento do protocolo SNMP basicamente esta relacionado com a

troca de informaes entre 02 dispositivos da rede, ou seja, o gerente (software
implementado na estao de gerenciamento) e o agente (software implementado em
estaes gerenciadas).
A figura 76 ilustra o modelo de troca de informaes entre estas entidades
Figura 76: Troca de informaes SNMP

Fonte: [STALLINGS-98]
O SNMPv1 utiliza o conceito de comunidades para definir uma confiabilidade

entre gerenciadores e agentes. Um gerente (manager) pode ser descrito como um
programa executado em uma estao servidora que possibilita a obteno e envio
172
de informaes de gerenciamento junto aos dispositivos gerenciados. O agente

um programa executado na estao gerenciada que responsvel pela manuteno
das informaes da estao gerenciada. Um agente configurado com trs nomes
de comunidade: Read-only, Read-write e Trap.
A comunidade read-only permite ler os valores de dados sem modific-los. A
comunidade read-write possibilita ler e modificar o valor de dados, sendo tambm
possvel ler contadores, e redefinir seus valores; a comunidade trap possibilita o
recebimento de notificaes assncronas dos agentes.
Ao contrrio de outras solues de gerenciamento, o protocolo SNMP
apresenta
um
conjunto
resumido
de
comando
baseado no
conceito
de
busca/alterao. Este conceito apresenta basicamente duas operaes, uma que

permite ao usurio alterar atributos de um objeto de uma MIB (Operao Set) e outra
para obter os valores dos atributos de um objeto (Operao Get). Existem tambm
as operaes Trap e Get-Next. A operao Get-Next utilizada para ler o valor da
prxima varivel, o gerente fornece o nome de uma varivel e o cliente obtm o valor
e nome da prxima varivel; a operao Trap utilizada para comunicao de um
evento previamente definido.
A figura 77 a seguir demonstra o formato das mensagens no protocolo SNMP.
Apesar da boa aceitao, o protocolo SNMPv1 apresentava deficincias
relacionadas segurana, visto que as mensagens no eram criptografadas e no
utilizavam qualquer tipo de autenticao, alm disto, o SNMP no se enquadrava
para o gerenciamento de grandes redes de computadores devido s limitaes de
desempenho para obteno de requisies explicitas e por falta de suporte para
troca de informaes gerente-gerente.
Em funo da necessidade de implementaes em segurana, foi desenvolvido
em 1993, a verso 2 do protocolo, o SNMPv2, com vrios avanos, tais como:
Estrutura de informao;
Primitivas de comunicao;
Comunicao gerente-gerente;
Implementaes de segurana.
173
Figura 77: Formato de mensagens SNMP

Fonte: Adaptado de [SCHMIDT-01]
A verso 2 do SNMP (SNMPv2) procurou corrigir deficincias da verso1

(SNMPv.1). Ele basicamente surgiu da evoluo do SNMPv1 e do RMON (Remote
Monitoring). Utiliza a SMI 2 (Structure of Management Information), que permite a
presena de novos tipos de ASN.1 (Abstract Syntax Notation)1.
Meio de especificar o modo como os dados so representados e transmitidos entre gerenciadores e

agentes no contexto SNMP [SCHMIDT-05]
174
Alm disto, possibilita a criao e excluso de objetos, juntamente com a

comunicao entre gerentes (Manager to Manager MIB).
A tabela 18 demonstra as RFCs que foram relacionadas com a verso 2 do
protocolo SNMP.
RFC
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
Data
1993
1993
1993
1993
1993
1993
1993
1993
1993
1993
1993
1993
Titulo
Introduction to SNMPv2
SMI for SNMPv2
Textual conventions for SNMPv2
Conformance Statements for SNMPv2
Administrative model for SNMPv2
Security Protocols for SNMPv2
Party MIB for SNMPv2
Protocol Operations for SNMPv2
Transport mappings for SNMPv2
MIB for SNMPv2
Manager to manager MIB
Coexistance Between SNMPv1 and SNMPv2
Fonte: Adaptado de [SCHMIDT-05] e [STALLINGS-99]
A edio realizada em 1993 para o SNMPv2 incluiu vrias implementaes de

segurana, porm estas no foram aceitas extensamente por causa de falta do
consenso entre os grupos responsveis pela analise do SNMP. Uma edio revisada
de SNMPv2 foi emitida dentro 1996, com os realces funcionais e operacionais, mas
sem as facilidades de segurana implementadas da verso anterior.
A tabela 19 a seguir relaciona as RFCs vinculadas verso SNMPv2c.
175
Tabela 19: RFCs relacionadas com SNMPv2c
RFC
1901
1902
Data
Jan/96
Jan/96
Titulo
Introduction to Community-based SNMPv2
Structure of Management Information for SNMPv2
1903
1904
1905
1906
1907
1908
Jan/96
Jan/96
Jan/96
Jan/96
Jan/96
Jan/96
Textual Conventions for SNMPv2

Conformance Statements for SNMPv2
Protocol Operations for SNMPv2
Transport Mappings for SNMPv2
Management Information Base for SNMPv2
Internet-Standard Network Management
Framework
Para compensar a falta de implementaes e corrigir problemas relacionados

com a segurana na verso SNMPv2c, foram elaboradas as verses SNMPv2u e
SNMPv2*. As mensagens e a segurana foram melhor desenvolvidas e
implementadas nestas verses (denominadas SNMPv2u e SNMPv2*), tambm foi
implementada a segurana feita por usurio (User-Based), o que s permite a
realizao de operaes por usurios especficos, impedindo o acesso de qualquer
usurio. Estas duas propostas foram unificadas, dando origem a verso 3 do
protocolo em 1998, o SNMPv3.
A tabela 20 ilustra as RFCs relacionadas com a verso 3 do SNMP.
RFC
2271
Data
Jan/98
2272
Jan/98
2273
2274
2275
Jan/98
Jan/98
Ago/98
Titulo
Architecture for Describing SNMP Management
Frameworks
Message Processing and Dispatching for SNMP
SNMPv3 Applications
User Based Security Model for SNMPv3
View-Based Access Control Model (VACM) for
SNMPv3
176
O desenvolvimento da verso 3 do SNMP (SNMPv3) trouxe aspectos

relevantes relacionados segurana, que implementa mecanismos para evitar a
alterao das mensagens enviadas; alm disto, barra-se o acesso a elementos
estranhos execuo de operaes de controle, que so realizadas por meio de
uma operao SetRequest. Evita-se tambm a leitura das mensagens por parte de
elementos no autorizados, alm de se assegurar ao gerente o direito de alterao
da senha dos agentes.
A segurana conseguida por meio da implementao de mecanismos de
criptografia com o DES (Data Encryption Standard) e de algoritmos de autenticao
que podem ser tanto o MD5 quanto o SHA (Secure Hash Algorithm); posteriormente,
as tcnicas de criptografia foram atualizadas com utilizao de AES (Advanced
Encryption Standard RFC 3826). [STALLINGS-08]. Portanto, as implementaes
definidas para SNMPv3 esto relacionadas a:
Autenticao;
Privacidade;
Controle de acesso.
A verso 3 do protocolo SNMP encapsula as PDUs (Protocol Data Unit) das

verses anteriores, ou seja, SNMPv1 e SNMPv2, a figura 78 abaixo descreve o
relacionamento entre as diferentes verses do SNMP por meio dos formatos
elaborados.
Figura 78: Relacionamento entre verses do SNMP

Fonte: Adaptado de [STALLINGS-99]
177
9.2 MIB (Management Information Base)

No gerenciamento em uma rede baseado na pilha de protocolos TCP/IP, as
MIBs que podem ser consideradas como bancos de dados de objetos gerenciados e
so utilizados para obter informaes de servidores e estaes SNMP. Os dados
so obtidos por requisies de estaes gerente a um ou mais estaes agentes da
rede utilizando os servios do protocolo de transporte UDP para enviar e receber
suas mensagens pela rede.
Dentre as variveis que podem ser requisitadas, as MIBs, so a base de
informaes de gerenciamento. Todo tipo de informao sobre o status ou estatstica
acessado pela NMS (Network Management Stations). Uma NMS responsvel
pela operao de polling e por receber traps de agentes na rede, esta definida em
uma MIB. [SCHMIDT-05].
Conforme expe [SCHMIDT-01], um agente pode implementar vrias MIBs,
porm todos os agentes implementam uma MIB especfica, a MIB II, definida na
RFC 1213, onde o principal objetivo desta MIB fornecer informaes gerais sobre o
gerenciamento de dispositivos em rede TCP/IP. Vrios padres de MIBs foram
desenvolvidos para redes, como ATM (MIB - RFC 2515), Frame Relay (DTE
Interface Type MIB RFC 2115), DNS (Server MIB RFC 1611) entre outros.
O gerenciamento de rede utilizando o SNMP permite que seja realizado o
acompanhamento simples e fcil do estado em tempo real, da rede, podendo ser
utilizado para gerenciar diferentes tipos de sistemas.
Cada estao gerenciada pelo SNMP deve possuir um agente e uma base de
informaes MIB. Conforme expe [SCHMIDT-05], um objeto gerenciado a viso
abstrata de um recurso real do sistema; desta forma, todos os recursos da rede que
devem ser gerenciados so modelados e as estruturas dos dados resultantes so os
objetos gerenciados.
Os objetos gerenciados podem ter permisses para serem lidos ou alterados,
sendo que cada leitura representar o estado real do recurso e, cada alterao
tambm ser refletida no prprio recurso. Dessa forma, a MIB o conjunto dos
objetos gerenciados, que procura abranger todas as informaes necessrias para a
gerncia da rede.
178
A RFC 1066 apresentou a primeira verso da MIB, a MIB I. Este padro definiu
a base de informao necessria para monitorar e controlar redes baseadas na pilha
de protocolos TCP/IP. A evoluo aconteceu com o RFC 1213 que props uma
segunda MIB, a MIB II, para uso baseado na pilha de protocolos TCP/IP.
Basicamente so definidos trs tipos de MIBs: MIB II, MIB experimental, MIB
privada.
A MIB II, considerada uma evoluo da MIB I, fornece informaes gerais de
gerenciamento sobre um determinado equipamento gerenciado. Atravs das MIB II
podem ser obtidas informaes como nmero de pacotes transmitidos, estado da
interface, entre outras.
A MIB experimental definida em virtude de seus componentes (objetos) esto
em fase de desenvolvimento e teste, em geral, eles fornecem caractersticas mais
especficas sobre a tecnologia dos meios de transmisso e equipamentos utilizados.
MIB privada aquela em que seus componentes fornecem informaes
especficas dos equipamentos gerenciados, como configurao, colises e tambm
possvel reinicializar, desabilitar uma ou mais portas de um roteador.
As regras de construo das estruturas da MIB so descritas atravs da SMI
(Structure of Management Information).
A SMI define com exatido como os objetos gerenciados so nomeados e
especifica os respectivos tipos de dados associados. Os objetos so organizados em
uma hierarquia em rvore e so reconhecidos por um OID (Object Identifier). Essa
estrutura forma a base do esquema de atribuio de nomes do SNMP. Um OID de
objeto formado por uma seqncia de inteiros baseada nos ns das rvores,
separada por pontos (.).
A figura 79 a seguir ilustra a subrvore MIB-II.
179
Figura 79: Subrvore MIB II:

Fonte: [SCHMIDT-01].
180
Conforme cita [OLIFER-08] a especificao RMON MIB melhora a capacidade

de comunicao remota com a MIB e implementa acrscimo aos recursos funcionais
do SNMP, o banco de dados RMOM MIB contm informaes agregadas sobre o
dispositivo e que no requer que grandes volumes de informaes trafeguem na
rede.
Foram especificados dois padres para RMON: RMON 1 e RMON2. O RMON
1 atua na camada MAC (Media Access Control) e o RMON 2 opera na camada de
rede e em camadas superiores (RFCs 1513, 1757, 2021 e 2074). [STALLINGS-99]
A RMOM MIB possui independncia do protocolo da camada de rede, diferente
dos padres MIB I e MIB II, sendo conveniente para redes heterogneas que
utilizam vrios protocolos na camada de rede, finaliza [OLIFER-08].
A figura 80 abaixo apresenta resumo comparativo entre MIBs.
Figura 80: Resumo comparativo MIBs

Fonte: [GABOS-09]
181
Devido versatilidade do protocolo de gerenciamento SNMP que passou a ser

integrado em diversas plataformas com a utilizao de APIs. Conforme expe
[MELLQUIST-94], o desenvolvimento destas APIs requerem a utilizao de
biblioteca de funes com as quais o programador deve estar familiarizado, onde
estas APIs definem uma plataforma especfica, resultando em um cdigo especfico
no oferecendo portabilidade para a soluo.
O SNMP passou a dispor do SNMP++ que prov programao orientada
objeto com um conjunto de classses de objetos C++ e bilbliotecas de classes
reutilizveis. O protocolo utiliza os mecanismos existentes em outras APIs aliadas as
vantagens da programao orientada objetos para aplicaes de gerenciamento
SNMP.
Conforme expe [MELLQUIST-94] esta soluo prov:
Facilidade de utilizao;
Portabilidade;
Extensibilidade;
Segurana.
Utilizando o conceito de programao orientada objeto em solues de

gerenciamento e inspirado no SNMP++ foi desenvolvido o SNMP4J API Java1.
www.snmp4j.org/
182
10. MODELO DE GESTO CORPORATIVA

Segundo expe [BIO-08], que define sistema de gesto como conjunto,
interdependente, dos processos decisrio-gerenciais (planejar, organizar, controlar,
etc.) que visa levar a empresa aos resultados desejados. O sistema de informao,
por meio das informaes gerenciais, interage com o sistema de gesto, ao suportar
os processos decisrios por meio de tais informaes.
Ainda conforme [BIO-08], as empresas definem modelos de gesto ao optarem
por metodologias administrativas que podem variar de um modelo nico (aplicado
comumente s empresas de grande porte e multinacionais) ou mesmo pela
competncia individual dos dirigentes das empresas. Basicamente, os componentes
que compem o Modelo de Gesto Corporativa so:
Filosofia empresarial;
Viso dos dirigentes sobre os resultados empresariais;
Estrutura organizacional;
Processo gerencial de planejamento/direo/controle;
Informaes gerenciais geradas pelo sistema de informao.
A figura 81 abaixo apresenta o inter-relacionamento entre estes componentes.
Figura 81: Elementos componentes de processo de gesto

Fonte: [BIO-08]
183
Os Sistemas de Informao Gerencial constituem o elo entre o Processo

Gerencial alm de subsidiar diretamente os resultados empresariais. Conforme
aborda
[BIO-08],
os
Sistemas
de
Informao
envolvem:
informaes
mercadolgicas, informaes de produo e informaes econmico-financeiras.

Segundo expe [LAUDON-98], sistemas de informao podem ser definidos
tecnicamente como um conjunto de componentes inter-relacionados que coletam (ou
recuperam), processam, armazenam e distribuem informao com a finalidade de
dar suporte tomada e controle em uma organizao. Os sistemas de informao
podem auxiliar gerentes e trabalhadores a analisar problemas....
O crescimento de uma empresa, conseqentemente acarretar no aumento de
volume de informaes que devem ser sistematizadas e distribudas pela
organizao, facilitando o compartilhamento e processamento.
Segundo expe [CAIARA-08], um Sistema de Informao parte integrante
da empresa e um produto de trs componentes: Tecnologia, Organizao e
Pessoas. No se pode entender ou usar SI em empresas de forma eficiente sem o
conhecimento de suas dimenses em termos de organizao e de pessoas, assim
como suas dimenses tecnolgicas.
Os sistemas de informao (SI) podem ser classificados de vrias formas,
dentre as maneiras comumente utilizadas, tem-se a classificao de acordo com a
rea funcional e de acordo com o nvel hierrquico. [CAIARA-08].
A classificao em funo da rea funcional compreende sistemas de
informao: financeira, contbil (controladoria), industrial (produo), marketing
(vendas) e
de recursos humanos. Outra forma de classificao so os nveis
hierrquicos, que abrange e define os nveis: operacional, ttico e estratgico.

(LAUDON-98]
A figura 82 a seguir ilustra a distribuio dos Sistemas de Informao e
respectivos nveis hierrquicos de uma empresa.
184
Figura 82: Distribuio dos Sistemas de Informao nos nveis hierrquicos

Fonte: Adaptado de [LAUDON-98]
Segundo expe [CAIARA-08], grande parte das organizaes so orientadas

por funes, ou seja, cada processo empresarial suportado por um sistema.
Esta separao entre processos leva ao desenvolvimento de solues de
gesto baseadas em sistemas de informao que no possibilitem a comunicao
entre segmentos da empresa.
Ainda conforme [CAIARA-08], a integrao dos sistemas de informao
acaba com as barreiras existentes entre os prprios departamentos e entre as sedes
e os departamentos, e reduz a duplicao de esforos.
Segundo [CUMMINS-02], cita que a automao do processo de negcio,
definido por gerenciamento de fluxo de trabalho, dinamiza as comunicaes entre
os sistemas e as pessoas.
185
10.1 ERP (Enterprise Resource Planning)

Conforme expe [MARANGONI-08], sistemas ERPs (Enterprise Resource
Planning) podem ser definidos como:
Um conjunto integrado de softwares que proporcionam o gerenciamento e a
viso completa das empresas, facilitando a integrao de reas que, mesmo
sendo alvos de tratamentos distintos, podem trabalhar em conjunto,
gerando uma maior sinergia empresa, como finanas, recursos humanos,
compras e vendas.
O ERP atua alm do planejamento, provm controle e suporte a todos os

segmentos operacionais, administrativos e comerciais de corporaes. Possibilita a
integrao com todos os segmentos da empresa oferecendo um Sistema Integrado
de Informao que se comunicam e utilizam a mesma base de dados.
A necessidade de processos eficientes de solicitao e gesto de materiais na
indstria deu origem na dcada de 1969 ao Material Requeriment Planning (MRP).
Os sistemas MRP eram "pacotes que interagiam entre si" e, desta forma
possibilitavam o planejamento da utilizao de insumos e a administrao das
diversas etapas dos processos produtivos. [MARANGONI-08]
Esta tcnica mostrou-se eficiente na gesto de inventrios, conforme expe
[MIO-07], quando na dcada de 1980, ocorreu a aprimoramento deste sistema e o
surgimento do MRP II.
O desenvolvimento acentuado das redes de computadores a partir da dcada
de 1980 tornou evidente a necessidade de sistemas mais abrangentes. A partir da
dcada de 1990, surgem os sistemas ERP com a finalidade de integrao entre os
diversos setores corporativos.
A arquitetura de um sistema ERP, conforme define [DAVENPORT-98]
constitudo utilizando-se arquitetura cliente-servidor.
A figura 83 a seguir ilustra estrutura tpica de sistema ERP.
186
Figura 83: Estrutura tpica de sistema ERP

Fonte: Adaptado de [DAVENPORT-98]
Conforme aborda [MARANGONI-08], com o acelerado crescimento da internet,

a evoluo do ERP tradicional foi o ERP II.
Devido ao rpido crescimento na demanda por solues de integrao, a partir
da dcada de 1990, desenvolvedores e fornecedores focaram esforos em sistemas
ERP voltados Internet, fazendo com que os mdulos pudessem ser atualizados
pela Web, e que usurios remotos conseguissem acessar e suprir o sistema.
[MARANGONI-08].
As principais caractersticas de sistemas ERP so: [SOUZA-00]
Pacotes comerciais de software;
Desenvolvidos a partir de modelos-padro de processos;
Sistemas ERP so integrados;
Possuem grande abrangncia funcional;
Utilizam um banco de dados corporativo;
Requerem procedimentos de ajuste.
O ERP II prov a integrao alm dos sistemas corporativos, enfatizou a

colaborao comercial com a internet, definindo o e-commerce. Alm de desenvolver
187
produtos e formas de comercializao especficas, o ERP II possibilita o incremento

do fluxo de informaes entre corporaes, interligando sistemas e mdulos ERPs.
Segundo [MIO-07], a distribuio entre os fornecedores de sistemas ERP,
com base em dados do IPM1 (Impacta Pesquisa Peridica de Mercado abril/2005),
apresenta a distribuio entre as plataformas de mercado, conforme ilustra a figura
84 abaixo.
Figura 84: Distribuio de fornecedores de sistemas ERP

1
Fonte: (IPM Impacta Pesquisa Peridica de Mercado, 2005)
Conforme aborda [MIO-07], o processo de planejamento para implementao

de sistemas ERP prov etapas de planejamento prvio, para que a implementao
seja bem sucedida. Estes processos esto ilustrados na figura 85 a seguir e so
compreendidos de:
Levantamento das necessidades de informao;
Definio das informaes a serem extradas do sistema;
Entendimento da abrangncia dos vrios mdulos do sistema;
IPM - Impacta Pesquisa Peridica de Mercado, mantm informaes sobre as pesquisas que realiza
a respeito do Mercado de Tecnologia da Informao no Brasil. [http://www.impacta.com.br/aimpacta/pesquisa-mercado.php]
2
A SAP foi fundada na Alemanha em 1972, desenvolveu o conceito original de ERP com o produto
R/2. [CAIARA-08]
188
Figura 85: Fases de planejamento de sistemas ERP

Fonte: Adaptado de [MIO-07]
Identificao das simplificaes e eliminaes dos vrios mdulos do

sistema;
Definio da seqncia de implantantao, resultados e prazos;
Estabelecimento de responsabilidades;
Treinamento;
Preocupao com relao ao Middleware.
[MIO-07] cita a importncia do middleware como elemento essencial na

integrao de sistemas de gesto ERP.
189
10.2 MES (Manufacturing Execution System)

Conforme cita [SHIRASUNA-08], o conceito de
Manufacturing Execution
System (MES), foi inserido em 1992 pela empresa AMR Research Inc1.
Um MES coleta e rene informaes dos processos de cho-de-fabrica e as
realimenta para o sistema de planejamento localizado na camada ERP/MRP II.
Segundo a AMR, o MES representa a camada de execuo que existe entre a rea
corporativa e o sistema de controle que prov funcionalidades de controle e
visibilidade.
Segundo aborda [CORREA-08], a Manufacturing Execution System Association
International2 (MESA International) designa o sistema MES como sistema de chode-fabrica orientado para a melhoria de desempenho que complementa e aperfeioa
os sistemas integrados de gesto (planejamento e controle) da produo.
O MES foi desenvolvido para servir de elo entre o sistema de planejamento e a
fbrica, ainda conforme expe [CORREA-08], o MES/SFC (Shop Floor Control)
cumpre dois papis: controle da produo, comparando o que efetivamente foi
produzido com o planejamento, e libera ordens de produo.
As principais funcionalidades do MES, conforme modelo elaborado pela MESA
International so: [SHIRASUNA-08]
Alocao de recursos e status;
Operaes/Programao Detalhada;
Unidades de Produo e Despacho;
Controle de Documento;
Coleta de Dados/Aquisio;
Gerenciamento de mo-de-obra;
AMR Research Inc. empresa de consultoria com foco em supply chain (cadeia de suprimentos)
[www.amrresearch.com]
2 MESA INTERNACIONAL (Manufacturing Execution System Association International) grupo de
empresas desenvolvedoras e fornecedoras de sistemas MES [www.mesa.org]
190
Gerenciamento de Qualidade;
Gerenciamento de Processo;
Gerenciamento de Manuteno;
Rastreabilidade de Produto e Genealogia;
Anlise de Performance.
O MES esta especificado pela norma ISA S95, que define cinco nveis nas
empresas industriais. A figura 86 abaixo ilustra os nveis propostos na normatizao.
[SHIRASUNA-08].
Figura 86: Nveis propostos para normatizao das empresas industriais MES
Fonte: Adaptado de [SHIRASUNA-08]
Apesar de ocorrem desenvolvimentos com foco na integrao entre processos

administrativos e produtivos, a falta de elementos padronizados, o surgimento de
novos projetos e o desenvolvimento de sistemas inadequados levam a falta de
integrao entre as estruturas de gesto. Conforme expe [NEVES-08], que cita que
na busca pelo aumento da eficincia dos processos produtivos, o setor industrial
realizou nos ltimos anos grandes investimentos na automao e informatizao do
cho-de-fbrica.
191
Ainda, conforme complementa [NEVES-08], se de um lado as mquinas

inteligentes passam a dominar a manufatura, as outras reas da produo e da
empresa tambm investem na modernizao, automao e implantao de TI; no
entanto, a implantao geralmente se d de forma desordenada, localizada e com
TIs que nem sempre conversam entre si...
Esta falta de integrao entre processos (gesto administrativa e processos
produtivos) estabelece uma lacuna que leva a conseqente falta de eficincia na
gesto da Informao.
A figura 87 abaixo ilustra lacuna entre processos de gesto.
Figura 87: Pirmide de automao sem integrao

Fonte: Adaptado de [FERNANDES-06]
O MES tem a funo de realizar o elo entre a gesto produtiva e os sistemas

ERP, provendo arquitetura integrada e eficiente. Entretanto, conforme cita
[SHIRASUNA-08] existe uma participao reduzida de sistemas MES nos processos
de integrao, e complementa mencionando que esta reduo deve-se :
Nvel de automao das empresas;
Desconhecimento do MES;
Barreiras culturais entre engenharia e TI;
Custo de investimento em MES;
Complexidade para implantar o MES.
192
[SHIRASUNA-08], finaliza citando os inmeros benefcios obtidos com a

implantao de sistemas MES em plantas indstrias, e salienta que alm dos fatores
citados,
atribui
falta
de
convergncia
entre
os
departamentos
de
Engenharia/Manuteno e TI para a reduzida implantao destes sistemas.

Segundo aponta [CERRI-04], deixa evidente que os sistemas de informao
ou tecnologia da informao no devem ser tratados isoladamente, isto , sem que
se busque atender aos negcios da organizao.
Conforme expe [SEIXAS-09] cita que a norma ISA-95 define o termo MOM
(Manufacturing Operations Management) em substituio a designao feita pela
empresa ARM e expe que a abrangncia do MES/MOM possui atribuies que
compreendem alm da produo, operaes de: produo, manuteno, qualidade
e inventrio.
Segundo [SEIXAS-09], deve ser elaborado mapa de funcionalidades da
planta, analisando as interfaces do MES/MOM com o ERP, e estabelece que este
seja um dos parmetros que deve ser considerado na adoo do sistema adequado
a planta industrial.
Devido ao contexto atual de convergncia de tecnologias no ambiente
produtivo, prover a gesto adequada dos processos e operaes fabris passou a ser
discernido como ponto de fundamental relevncia. Conforme aborda [PAVA-09], que
as modernas solues de Gerenciamento de Operaes (MOM), devem ser capazes
de atender:
Escalabilidade Uma abordagem em plataforma de soluo;
Flexibilidade Convergncia de TA e TI no contexto da manufatura;
Especializao solues focadas por indstria;
Inteligncia Operacional Enterprise Manufacturing Intelligence (EMI).
193
11. INTEGRAO EM APLICAES DISTRIBUDAS

As tecnologias de informao surgidas a partir de solues desenvolvidas
utilizando objetos distribudos tem sido implementadas por diversas empresas
possibilitando a rpida troca de dados e informaes, aproximando filiais de
empresas, criando alternativas cmodas para clientes e reduzindo custos de
logstica para clientes e fornecedores; integrando enfim, a cadeia produtiva,
logstica, administrativa, entre outros segmentos que compem empresas.
Conforme expe [CUMMINS-02], a tecnologia de objetos distribudos oferece
suporte ao desenvolvimento de componentes distribudos que interagem como
objetos que trocam mensagens em uma rede. Os objetos podem ser servios ou
objetos compartilhados de uma aplicao de negcio.
Os objetos podem ser distribudos em uma srie de computadores dispostos na
rede onde a comunicao ocorre por meio de middleware, definido como requisitor
de objetos, conforme complementa [SOMMERVILLE-07].
A figura 88 abaixo ilustra uma aplicao tpica de objetos distribudos.
Figura 88: Aplicao tpica de objetos distribudos

Fonte: Adaptado de [CUMMINS-02]
As aplicaes distribudas podem ser vistas atualmente no ambiente

corporativo, em implementaes tais como:
Sistema de gesto via web;
e-Commerce;
e-Banking;
e-Business
Outros.
194
Nota-se, portanto, a expanso de atividades em um ambiente heterogneo

como a Internet. Segundo [CUMMINS-02], o comercio eletrnico basicamente a
integrao corporativa que se prolonga para clientes e parceiros de negcios.
Ainda, conforme menciona [CUMMINS-02], na dcada de 1990, as aplicaes
de integrao corporativas foram baseadas em produtos definidos por COSTS
(Commercial-Off-the-Shelf), tais como sistemas Data WareHouse, Data Mart e Data
Mining, porm, necessidades de adaptao e integrao aliadas expanso
inerentes das corporaes associados baixos custos tornou-se uma necessidade.
Conforme expe [SOMMERVILLE-07], as vantagens do modelo de objetos
distribudos so:
Possibilita que o projetista do sistema posponha decises sobre onde e

como os servios devem ser fornecidos, ou seja, os objetos que fornecem
servios podem ser executados em qualquer n da rede;
Sistema de arquitetura aberta, que permite que novos recursos sejam

adicionados quando necessrio;
Sistema flexvel e escalonvel;
Possibilita reconfigurar dinamicamente o sistema com objetos que migram

atravs da rede, conforme necessrio.
Os sistemas computacionais distribudos possuem como caractersticas serem

heterogneos e escalonveis, onde a escalabilidade pode ocorrer de diversas
formas por meio de vrias plataformas de computao. Conforme expe [CUMMINS02], com padres de interoperabilidade apropriados e o middleware, as aplicaes
podem interoperar, mesmo que estejam sendo executadas em diferentes
plataformas, usando diferentes gerenciadores de banco de dados e escritos em
diferentes linguagens.
Os sistemas de objeto distribudo so a base de arquiteturas de trs camadas,
na qual a lgica de apresentao ou primeira camada reside em um cliente, a lgica
central comercial reside em uma camada central e o banco de dados (back end)
reside na terceira camada. A tecnologia de objetos distribudos estende a camada
central, permitindo a acessibilidade para vrios objetos de aplicativo, em vez de
somente apenas um.
195
O middleware desempenha papel essencial para assegurar a comunicao

contnua de objetos, em uma arquitetura de objetos distribudos, onde os objetos
podem ser implementados em linguagens de programao diversas. Conforme
complementa [SOMMERVILLE-07], o middleware atua em dois nveis para apoiar a
comunicao, sendo:
Nvel de comunicao lgica, o middleware fornece a funcionalidade que

possibilita aos objetos de diferentes computadores trocarem informaes de
dados e de controle;
Nvel
de
componente,
middleware
prove
uma
base
para
desenvolvimento de componentes compatveis, possibilita implementaes

com mtodos padronizados.
Conforme menciona [CUMMINS-02] h trs principais tecnologias de objetos
distribudos:
A CORBA (Common Object Request Broker Architecture);
O COM+ (Component Object Model);
O EJB (Enterprise JavaBeans).
Conforme expe [COULOURIS-07], existem atualmente vrios padres de

middleware orientados objetos, dentre os quais:
O CORBA;
RMI Java;
Web Services;
DCOM (Distributed Component Object Model).
Os protocolos de objeto distribudo so construdos na mesma arquitetura

bsica que tem por base uma camada de comunicao de rede que compreende
trs partes: [NIRVA-01]
O servidor de objeto;
O skeleton;
O stub.
196
O servidor de objeto e o skeleton comumente residem na camada central. O

stub reside na camada cliente e manipula a comunicao entre processos entre o
objeto no lado do cliente e no lado do servidor; agindo como proxy no cliente e
responsvel por comunicar pedidos do cliente para o servidor de objeto, por meio do
skeleton.
O stub e o skeleton so responsveis por fazer o servidor de objeto (que pode
ficar na camada central ou na terceira camada) parecer como se a execuo
estivesse ocorrendo na estao do cliente.
Para encaminhar dados entre diferentes espaos de endereos, o stub e o
skeleton utilizam dois processos, definidos por marshaling1 e unmarshaling2.
Conforme expe [COULOURIS-07] os sistemas de objetos distribudos podem
adotar a arquitetura cliente/servidor; os objetos so gerenciados pelos servidores e
seus clientes invocam seus mtodos utilizando invocao a mtodo remoto (RMI Remote Method Invocation). A invocao realizada pela execuo de um mtodo
do objeto no servidor e o resultado e retornado para o cliente em outra mensagem.
Outros mtodos e modelos de arquiteturas podem ser impostas objetos
distribudos, sendo: [COULOURIS-07]
Replicar os objetos, elevando as vantagens de tolerncia falhas;
RMI concorrentes, a partir de objetos em diferentes computadores;
Cada processo contm um conjunto de objetos, alguns dos quais podem

receber invocaes remotas e locais. [COULOURIS-07] define as invocaes
mtodos entre objetos em diferentes processos, estejam estes na mesma estao
ou no, como invocaes a mtodos remotos e finaliza mencionando que as
invocaes a mtodos no mesmo processo so invocaes a mtodos locais.
1
marshaling empacota os parmetros de uma chamada de mtodo ou valores de retorno em um

formato padro para transmisso. [NIRVA-01]
2
unmarshaling operao inversa do marsaling, desempacota o formato padro de uma

apresentao de dados no espao de endereo de um processo receptor. [NIRVA-01]
197
Tratar o estado compartilhado de um programa distribudo como um conjunto

de objetos e que estes podem ser acessados via RMI ou mesmo serem copiados em
um cache local trazem grandes vantagens para sistemas heterogneos, visto que
diferentes formatos de dados podem ser utilizados em instalaes divergentes sem
que estes formatos sejam notados pelos clientes que utilizam RMI para acessar
estes objetos. [COULOURIS-07].
A figura 89 abaixo ilustra a invocao mtodos locais e remotos.
Figura 89: Invocao mtodos locais e remotos

Fonte: Adaptado de [COULOURIS-07]
11.1 Tecnologias em aplicaes distribudas

A arquitetura CORBA (Common Object Request Broker Architecture) foi
desenvolvida na dcada de 1990 pela OMG (Object Management Group) baseado
em um modelo de abstrao definido por OMA (Object Managemet Architecture) que
utiliza um ORB (Object Request Broker) para criar e gerenciar a comunicao entre
objetos no lado do cliente e no lado do servidor; o acesso realizado por meio do
protocolo IIOP (Internet Inter-ORB), que torna possvel que programas escritos em
diferentes linguagens de programao se comuniquem atravs da Internet.
Os objetos e interfaces CORBA so especificados utilizando a OMG IDL (OMG
Interface Definition Language), que possibilitam a operao mtua entre objetos no
lado do cliente e no lado do servidor, escritos em diferentes linguagens de
programao; conforme cita [BORSOI-04], a utilizao do padro CORBA possibilita
ter aplicaes completamente distribudas com partes do software sendo executado
em diferentes plataformas e com localizao em rede.
O EJB (Enterprise JavaBeans) um modelo de componente que permite aos
desenvolvedores distriburem componentes no servidor (servidores de aplicativos e
198
servidores de banco de dados). Em aplicativos EJB, a ativao remota segue a

especificao RMI (Remote Method Invocation), porm os fornecedores no esto
limitados ao protocolo de transporte RMI. Os componentes EJB so componentes
Java que so executados em um servidor (servidor de aplicativos ou de banco de
dados), que podem funcionar ou serem executados em qualquer ambiente que
possua um interpretador Java (JVM Java Virtual Machine) e um continer EJB. O
Enterprise JavaBeans possibilita aos aplicativos se comunicarem em ambientes de
cliente e servidor de vrias camadas e atravs da Internet e de estruturas de
intranet.
O RMI (Remote Method Invocation) Java foi desenvolvido pela empresa Sun
Javasoft e possibilita que um objeto Java sendo executado em uma JVM (Java
Virtual Machine) chame mtodos presentes em outro objeto Java sendo executado
em outra JVM. Quando ocorre a invocao de um mtodo de um objeto remoto, o
cliente RMI atua sobre um objeto local como se fosse um objeto remoto; este objeto
local chamado stub e age como um proxy do objeto remoto, provendo ao cliente a
transparncia na comunicao. O stub gerado a partir de um compilador RMIC
(Remote Method Invocation Compiler).
Conforme expe [BORSOI-04], o RMI constitui uma interface que possibilita a
intercomunicao entre objetos Java localizados em diferentes hosts; cada objeto
remoto implementa uma interface remota que especifica quais mtodos podem ser
invocados remotamente pelos clientes, da mesma forma que realizada a invocao
remota.
O RMI utiliza o JRMP (Java Remote Method Protocol) para chamadas de
ativao remotas e foi projetado para operar no ambiente Java. Em 1999, a Sun
desenvolveu o RMI atravs da especificao IIOP (RMI-IIOP), que foi elaborado em
conjunto com a IBM, possibilita que objetos Java se comuniquem com objetos
CORBA.
O
DCOM
(Distributed
desenvolvida pela Microsoft
Component
Object
Model)
uma
arquitetura
para aplicaes distribudas. O DCOM uma
extenso do COM que suporta a comunicao entre objetos em computadores

distintos.
199
O COM+ (Component Object Model), possibilita que os clientes ativem servios

fornecidos por componentes compatveis com COM. Os objetos e interfaces COM
so especificados utilizando a IDL (Interface Definition Language) da empresa
Microsoft por meio de uma coleo de objetos ActiveX.
Os WebServices so aplicaes de software identificadas por um URI (Uniform
Resource Identifier) e esto enquadrados como qualquer tipo de servio disponvel
na internet e que utiliza o XML (Extensible Markup Language) de forma
independente de sistema operacional ou linguagem de programao.
O XML utilizado para possibilitar que clientes se comuniquem com servios
web e para definir as interfaces e outras propriedades deste mesmo servio. O XML
possui a propriedade de ser extensvel (as tags so definidas pelos usurios) em
contraste com o HTML (Hypertext Markup Language), que possui conjunto de tags
fixo.
Os WebServices utilizam em sua arquitetura protocolos abertos como HTTP
(Hypertext Transfer Protocol) e SOAP (Simple Object Access Protocol). Para
representao e estruturao das mensagens recebidas e enviadas utilizado o
XML; as operaes incluindo os parmetros de entrada e sada so codificadas no
protocolo SOAP. Em WebServices, os servios de operao, mensagens,
parmetros so descritos utilizando a linguagem baseada em XML definida por
WSDL (Webservice Description Language).
11.2 Middleware
Segundo definio de [COULOURIS-07] um middleware composto por um
conjunto de processos ou objetos, em um grupo de computadores, que interagem
entre si de forma a implementar comunicao e oferecer suporte para
compartilhamento de recursos distribudos.
A camada de software definida pelo middleware possibilita a comunicao
entre aplicaes distribudas, tendo por objetivo diminuir a complexidade e
heterogeneidade dos diversos sistemas existentes, provendo servios que realizam
a comunicao entre esta categoria de aplicaes de forma transparente. [MACIEL04]
200
A figura 90 abaixo ilustra a comunicao atravs de middleware.
Figura 90: Middleware para comunicao em sistema distribudo

Fonte: Adaptado de [SERIAN-02]
Conforme expe [SERIAN-02], middleware constitui uma estrutura de

comunicao que independente do sistema operacional e da natureza do sistema
de transmisso.
No modelo OSI que define os diferentes nveis de comunicao entre sistema
de informao, middleware esta localizado na parte superior e define os protocolos
de comunicao entre aplicaes.
A figura 91 ilustra este processo no Modelo de Referencia OSI.
Figura 91: Localizao de Middleware no Modelo OSI

Fonte: Adaptado de [SERIAN-02]
201
Na pilha de protocolos TCP/IP, a camada de abstrao middleware interage

com os protocolos de transporte UDP e TCP, viabilizando a comunicao entre
aplicaes e servios.
A figura 92 a seguir ilustra esta camada na arquitetura TCP/IP.
Figura 92: Middleware arquitetura TCP/IP

A interface de programa aplicativo para TCP fornece a abstrao de um fluxo

(stream) bidirecional entre pares de processos; a informao transmitida consiste
em um fluxo contnuo de dados sem dar a noo de limites de mensagem, os fluxos
fornecem um bloco de construo para a comunicao produtor-consumidor,
conforme expe [BACON-02]1 apud [COULOURIS-07].
Um produtor e um consumidor constituem um par de processos, onde a funo
do produtor produzir itens de dados para o consumidor.
Segundo ainda [COULOURIS-07], menciona que a interface de programa
aplicativo para UDP fornece uma abstrao de passagem de mensagem.
Definido na camada de middleware para comunicao TCP/IP existe os
protocolos de requisio e resposta, elaborados para prover comunicao
cliente/servidor nas formas de RMI (Remote Method Invocation) ou RPC (Remote
Procedure Call).
1 BACON, J. (2002). Concurrent Systems, terceira edio. Harlow, Inglaterra: Addison-Wesley.
202
Na comunicao com os protocolos de transporte TCP ou UDP, so utilizados

a abstrao de soquete1, para a comunicao entre processos, conforme aborda
[COULOURIS-07], que complementa citando que a comunicao entre processos
consiste em transmitir uma mensagem entre um soquete de um processo e um
soquete de outro processo.
A figura 93 abaixo ilustra este processo de comunicao.
Figura 93: Comunicao entre processos

Na comunicao por fluxo TCP, a API do protocolo TCP fornece a abstrao de

um fluxo de bytes no qual os dados podem ser lidos (receive) e escritos (send),
sendo ocultas pela abstrao de fluxo (stream) as seguintes caractersticas:
Tamanho das mensagens;
Mensagens perdidas;
Controle de fluxo;
Duplicao e ordenamento de mensagens;
Destinos de mensagens.
No protocolo UDP, a comunicao estabelecida com datagrama enviado pelo

protocolo UDP transmitido de um processo remetente para um processo destino,
sem necessidade de confirmaes, que define a forma mais simples de
comunicao entre processos, conforme expe [COULOURIS-07].
1 Soquete API de comunicao para sistemas UNIX BSD, foram desenvolvidas em linguagem C,
cujo objetivo viabilizar interface na transmisso TCP e UDP. [SOARES-99]
203
As plataformas de middleware formam uma engrenagem vital para a

construo de sistemas distribudos robustos; tais plataformas definem camadas de
abstrao que facilitam o desenvolvimento de sistema de software de larga escala,
aliviando a carga ao desenvolver aplicaes que exigem um nmero complexo de
servios de infraestrutura.
Cabe salientar, conforme expe [COULOURIS-07] que o desenvolvimento de
uma middleware para suportar sistemas peer-to-peer em escala global torna-se um
problema difcil, o conhecimento das localizaes dos objetos deve ser particionado
por toda a rede, onde cada n se responsabiliza por manter o conhecimento de tais
localizaes e objetos, portanto, manter os requisitos de escalabilidade e
disponibilidade tornam-se impraticveis, manter um banco de dados em todos os
ns clientes fornecendo tais localizaes.
Segundo [MAHMOUD-04], cita que as prximas geraes de sistemas de
sistemas distribudos iro requerer comportamento previsvel em reas tais como
thoughput, escalabilidade, dependabilidade e segurana.
As tcnicas adaptativas e reflexivas so apontadas por [MAHMOUD-04] como
um paradigma emergente fundamental para o desenvolvimento de plataformas
dinmicas de
middleware da prxima gerao. Estas tcnicas capacitam um
sistema
adaptar-se
para
automaticamente
ao
ambiente
para
cumprir
necessidades do usurio dentro das polticas definidas.

Um sistema adaptativo tem a capacidade de alterar seu comportamento e
funcionalidade. Segundo [MAHMOUD-04] um middleware adaptativo um software
cujo comportamento funcional pode ser modificado dinamicamente para aperfeioarse s alteraes nas condies ou exigncias ambientais.
[MAHMOUD-04] menciona ainda que tradicionalmente, as plataformas de
middleware so projetadas para um domnio especfico do aplicativo ou cenrio de
implantao. Na realidade, vrios domnios se sobrepem, e ambientes de
implantao so dinmicos e no estticos, a tecnologia de middleware atual no
fornece suporte para lidar com essas condies.
Conforme
aborda
[MACIAL-04],
middleware
adaptativo
deve
ser
reconfigurvel, possibilitar que novos servios sejam acoplados e ter as seguintes

caractersticas:
204
Suporte a aplicaes sensveis ao contexto e adaptativas;
Suporte em tempo de execuo de comunicaes ad hoc entre as

aplicaes;
Servios adaptativos especficos de aplicao;
Interoperabilidade com middleware de outros domnios.
[MAHMOUD-04] cita que nos ltimos anos, tm surgido plataformas que

suportam reconfigurabilidade, permitindo que plataformas sejam personalizadas
para uma tarefa especfica, este trabalho tem levado ao desenvolvimento de
plataformas de middleware adaptativo multiuso.
Um sistema reflexivo definido por [MAHMOUD-04] como aquele que pode
analisar e raciocinar sobre as suas capacidades e ambiente operacional, permitindo
que se autoadaptar em tempo de execuo. Ainda conforme expe [MAHMOUD04], o middleware reflexivo baseia-se no middleware adaptativo, fornecendo os
meios necessrios para permitir que um sistema seja manipulado e adaptado em
tempo de execuo.
Plataformas reflexivas suportam avanado comportamento adaptativo; a
adaptao pode ocorrer de forma autnoma, com base no status do sistema, do
ambiente, ou nas polticas definidas de seus usurios ou administradores, conforme
expe [MAHMOUD].
Um middleware reflexivo utiliza o conceito da refletividade computacional, ou
seja, uma aplicao pode acessar algumas partes do estado do sistema logo abaixo
e modific-lo dinamicamente, modificando, ento, sua prpria semntica, conforme
aborda [AGHA-02]1 apud [MACIEL-04].
Os servios oferecidos pelas camadas de abstrao middleware comumente
so: [MACIEL-04]
AGHA, Gul A. Adaptive Middleware. Communication on the ACM. Junho, 2002 v. 45. n 6 pp. 3132.
205
Gerenciamento e apresentao;
Computao;
Gerenciamento de informao;
Comunicao;
Gerenciamento de sistema;
Sistema de entrega.
Segundo expe [SCHANTZ-01], para aplicaes distribudas, o middleware

Distributed Object Computing (DOC), atua como um protocolo de rede que possui
uma arquitetura decomposta em camadas, que prov:
Distribution middleware, define os modelos de programao de alto nvel

dos quais as APIs podem estender a capacidade de programao no
sistema operacional;
,Domain-specific middleware services, so servios especficos solicitados

por domnios determinados, que provm mecanismos de reutilizao. Os
servios oferecidos por esta camada permitem maior crescimento da
qualidade do sistema e diminuem o esforo de vida necessrios para o
desenvolvimento de aplicaes distribudas especificas;
Commom middleware service, define servios de alto nvel que podem ser
utilizados por programadores para construo de aplicaes distribudas.
Host Infrastructure middleware, encapsula a comunicao proveniente ao

sistema
operacional
programao distribuda.
estabelecendo
componentes
reutilizveis
de
206
12. ARQUITETURA PROPOSTA

Neste capitulo, ser abordada a arquitetura proposta que contempla a
necessidade de integrao no ambiente corporativo industrial, analisando as
ferramentas necessrias para aproximao entre a gesto dos processos
administrativos e a gesto produtiva.
O modelo proposto para a integrao em aplicaes distribudas contempla a
utilizao de abstrao middleware implementado nos nveis de:
Execuo (RTU e CLP);
Aquisio de dados (SCADA++)
Integrao industrial (MES);
Gerenciamento (SNMP4J);
Gesto/planejamento (ERP).
A figura 94 ilustra o modelo proposto.
Figura 94: Modelo proposto de gesto produtiva.
modelo
prope
adoo
de
controladores
lgicos
programveis
implementados com MIB (Management Information Basic), tornando-os agentes e

definindo uma arquitetura de gerenciamento de objetivos distribudos na planta
industrial, possibilitando o gerenciamento destes dispositivos, conforme ilustra a
figura 95 a seguir.
207
Figura 95: Arquitetura proposta
As atribuies de arquitetura de automao de processo, so definidas pelas

implementaes das lgicas de automao e controle, programadas nos dispositivos
CLPs/RTUs juntamente com os sistemas de superviso e aquisio de dados
(SCADA).
O modelo proposto adota como sistema de superviso e aquisio de dados o
SCADA++, desenvolvido como um sistema de controle baseado em programao
orientada objetos, onde o acesso aos recursos dos hardwares dispostos na rede
industrial passa a ser realizado via objeto, no mais por tags, como nos sistemas
convencionais, alm de assegurar a independncia em relao aos sistemas
operacionais dos computadores.
A plataforma de gerenciamento atuar no monitoramento de rede e dos
dispositivos
da
planta
industrial,
fornecendo
parmetros
relacionados
aos
dispositivos de automao (CLPs, RTUs, switches industriais) e parmetros de rede.

O gerenciamento prev a implementao de SNMP4J, por meio de API Java para
gerentes e agentes da arquitetura.
Como requisitos de segurana, o protocolo de gerenciamento dispe de
recursos de privacidade e autenticao.
208
O MES atuar na arquitetura de gesto, provendo a integrao industrial entre

os sistemas de aquisio de dados (SCADA); realizando coleta/aquisio de dados e
parmetros (processo industrial sensores e atuadores); no detalhamento e gesto
de ordens de servio e de produo; gesto de recursos materiais e humanos.
As atribuies de manuteno dos dispositivos de automao e da rede,
passaro a dispor de informaes e dados gerados a partir do gerenciamento
SNMP4J por meio dos dados obtidos das MIB implementadas nos controladores
lgicos programveis.
A figura 96 abaixo ilustra a esquema ERP obtido.
Figura 96: ERP com incluso de camada MES e SNMP4J
A camada de abstrao middleware proposta dever prover transparncia na

comunicao, independente dos protocolos de comunicao do sistema, das
plataformas e sistemas operacionais dos computadores, bem como de hardwares e
dispositivos empregados na arquitetura de gesto. O middleware ser baseado no
modelo de invocao e mtodo remoto RMI (Remote Method Invocation); este
mtodo de invocao, juntamente com uma API (Application Program Interface)
possibilita que o software de middleware chame mtodos de objetos remotos como
se estes fossem objetos locais, salientando que a invocao objetos remotos
possui maior latncia do que a invocao objetos locais.
O RMI prov suporte para registro, que possibilita aos clientes realizarem
monitoramento em um servio especifico.
A figura 97 a seguir ilustra detalhamento da arquitetura de abstrao proposta.
209
Figura 97: Camada Middleware
Como a arquitetura pressupe objetos remotos, a camada de abstrao prove

utilizao de nvel destinado a protocolos de requisio/resposta, para invocao
objetos remotos. Estes protocolos so elaborados para integrar as respostas s
correspondentes requisies.
A estrutura da mensagem do protocolo requisio/resposta ilustrada na figura
98 abaixo.
Figura 98: Estrutura da mensagem requisio/resposta

Fonte: [COLOURIS-07]
Na arquitetura proposta ser sugerido o Java RMI.

Conforme expe [COSTA-06] a tecnologia Java foi desenvolvida pela Sun
Microsystems para propiciar a escrita de software altamente confivel e robusto com
strong typing1.
1
strong typing tipagem forte viabiliza uma abrangente checagem em tempo de compilao para
evitar problemas em potencial no casamento dos tipos. [COSTA-06]
210
Os programas RMI apresentam uma arquitetura cliente-servidor, onde os

clientes invocam mtodos que atuam sobre objetos nos servidores, tanto dos
clientes RMI quanto os servidores RMI so codificados na linguagem Java.
[ALBUQUERQUE-01]
Ao invocar um mtodo sobre um objeto remoto, o cliente RMI atua na realidade
sobre um objeto local, que se faz passar por objeto remoto, este objeto local
definido como stub. O stub atua como um proxy do objeto remoto e esconde do
cliente
uso
dos
servios
providos
pelos
protocolos
de
transporte.
[ALBUQUERQUE-01].
A figura 99 abaixo ilustra a comunicao entre entidades RMI.
Figura 99: Comunicao entre entidades RMI

Fonte: Adaptado de [COSTA-08a] e [COSTA-06]
O programa cliente faz invocaes de mtodos pelo objeto proxy, o RMI envia
a requisio para JVM (Java Virtual Machine) remota e redireciona para a
implementao, qualquer valor retornado pela implementao devolvido ao proxy e
ento ao programa cliente.
A figura 100 a seguir ilustra a Invocao Remota.
211
Figura 100a: Invocao remota
Figura 100b: Interao entre componentes Invocao remota.
Ao invocar um mtodo remoto, um cliente RMI necessita identificar o objeto

remoto sobre o qual o mtodo atua. Para obter uma referncia para esse objeto, o
cliente recebe a referncia como o valor retornado por mtodo ou utiliza um servio
definido por registry, que utilizado tanto por clientes quanto servidores RMI. O
servidor de registro atende na porta 1099 (default), porm pode ser alterada.
Conforme expe [COSTA-08a], a operao RMI definida por um ambiente de
comunicao composto por trs elementos: cliente RMI, servidor RMI e servidor de
registro. Os mtodos so acessados pelos clientes no servidor RMI, onde este deve
definir uma interface contendo tais mtodos.
Ainda conforme [COSTA-08a], o servidor RMI atua como um servidor TCP,
embora os detalhes da conexo os detalhes da conexo no sejam percebidos
pelos usurios...
212
A figura 101 a seguir ilustra procedimento para construo de aplicao RMI.
Figura 101: Construo de aplicao RMI

Fonte: [ROCHA-03]
A etapa inicial consiste em estabelecer a interface que define os mtodos que

estaro disponveis para acesso remoto. Desta forma, fundamental criar uma
interface Java com relao de herana, declarando os mtodos visveis (pacote
Java.RMI).
A tabela 21 a seguir apresenta a lista dos mtodos mais utilizados da interface
Context.
213
Tabela 21: Mtodos utilizados da interface Context
Fonte: [COSTA-08b]
As
fases subsequentes consistem de implementar e compilar os objetos
remotos, gerar stubs e skeletons, implementar aplicaes servidor e cliente e

compila-los. (ROCHA-03)
Os servidores RMI possuem os objetos remotos com os quais os clientes RMI
interagem. Aps designados, os objetos remotos permanecem enquanto existirem
referncias para estes mantidas pelos clientes, conforme expe [ALBUQUERQUE01], alm dos mtodos remotos, os servidores contm o cdigo para:
Receber as chamadas dos clientes;
Identificar os mtodos a serem chamados;
Chamar os mtodos passando os parmetros necessrios;
Enviar os resultados aos clientes.
214
Para invocar um mtodo sobre um objeto remoto, o cliente RMI necessita

primeiro obter uma referncia para tal objeto; para isto, o cliente pode invocar o
mtodo lookup ( ) da classe java.rmi.Naming, informando o nome do servio
prestado pelo objeto remoto.
As interfaces propostas na arquitetura de infraestrutura de integrao e seus
respectivos sistemas de interao so apresentados na figura 102.
Figura 102: Arquitetura de infraestrutura de integrao
215
13. CONCLUSO E CONSIDERAES FINAIS

Um aspecto de fundamental relevncia observado no desenvolvimento desta
dissertao foi a aplicao de arquiteturas de sistemas distribudos utilizados em
diversos sistemas, especialmente no ambiente industrial; onde os padres de
barramentos de campo passaram a dispor em suas estruturas de implementaes
de Ethernet e TCP/IP. Conclui-se desta forma que os padres de gesto industrial e
corporativa
sero convergentes e abertos, possibilitando maior flexibilidade,
escalabilidade e interoperabilidade.
A rpida ascenso das arquiteturas de sistemas distribudos proporcionou o
surgimento de modelos de gesto empresariais dinmicos que necessitam de
dispositivos geis e que deem subsdios aos processos de tomada de decises com
rapidez e eficincia. A integrao da informao dentro do ambiente corporativo
torna-se fator de essencial proeminncia no contexto estratgico e decisrio das
corporaes.
A tecnologia da informao tem contribudo de forma incisiva neste processo
de integrao da informao compartilhada, ao dispor de modelos e de linguagens
computacionais que oferecem mecanismos que possam ser utilizados diretamente
em dispositivos fabris, proporcionando acompanhamento em tempo real destes
equipamentos com a possibilidade de integrao ao ambiente de dados das
corporaes.
A aplicao de programao orientada objeto atrelada aos dispositivos e
sistemas de automao, como sistemas de aquisio de dados, (SCADA++) e at
mesmo em sistemas direcionados inicialmente para ambientes de tecnologia da
informao como o gerenciamento de redes (SNMP++ e SNMP4J) mostram a
versatilidade e aplicabilidade deste paradigma na integrao e acesso de dados em
novas plataformas e em sistemas legados. Desta forma so asseguradas
caractersticas como encapsulamento, herana e polimorfismo programao de
sistemas de monitoramento industrial.
Diversas plataformas surgiram com o propsito de integrao, entretanto, a
linguagem Java esta sendo implementada por diversos fornecedores e poder ser a
principal arquitetura de objetos distribudos do futuro [CUMMINS-02].
216
O segmento de empresas de manufatura que dispem de sistemas

automatizados e informatizados demandar nos prximos tempos de solues que
visem a Inteligncia Operacional provendo a plena integrao de dados em tempo
real e de forma segura.
A utilizao de solues de integrao comercial como ERP, com mdulos
direcionados ao ambiente fabril como o MES implementados, com sistemas de
gerenciamento e camadas de abstrao (middleware) possibilitam acessibilidade e
o compartilhamento informaes e dados gerados.
Por meio da utilizao de middleware JavaRMI, torna-se possvel atingir a
integrao e interoperabilidade dos dispositivos da planta com robustez e
segurana. Esta relao pode ser estabelecida por meio da programao orientada
a objeto que um paradigma de programao avanado.
A integrao de dados e informaes subsidia a consolidao de arquiteturas
integradas como por exemplo SOA (Service-oriented architecture), conforme ilustra a
figura a seguir.
Legenda:
B2B Business to Business
CRM - Customer Relationship Management
Figura: Arquitetura orientada Servios
217
13.1 Trabalhos futuros

Como trabalhos futuros sugere-se a realizao de benchmark em dispositivos
no TI, como switches industriais e CLPs implementados com JavaRMI e outras
plataformas de middleware como DCOM e CORBRA. Recomenda-se avaliar a
aplicabilidade de middleware no somente para monitoramente e gerenciamento de
dados, mas tambm para controle em sistemas de automao.
Tambm se sugere a aplicao de virtualizao sobre os dados integrados,
que podero compor solues como CloudComputing.
218
14. REFERNCIAS
[ALBUQUERQUE-01]
ALBUQUERQUE,
Fernando.
TCP/IP
Internet
Programao de sistemas distribudos HTML,
JAVASCRIPT e JAVA. Rio de Janeiro: Axcel Books,
2001.
[ALBUQUERQUE-07]
ALBUQUERQUE, Pedro Urbano Braga de; ALEXANDRIA,

Auzuir Ripardo de. Redes Industriais. Fortaleza: Edies
Livro Tcnico, 2007.
[ALMEIDA-08]
ALMEIDA, Andr Gustavo Duarte. Um Ambiente MultiMiddleware para Desenvolvimento de Aplicaes

Distribudas. Dissertao (Mestrado). Universidade
Federal do Rio Grande do Norte, Natal, 2008.
[ALVES-04 ]
ALVES, Luiz Antonio Antunes. Gerador de Aplicaes:

Uma Ferramenta para Gerencia de Sistemas
Embutidos utilizando SNMP. Monografia (Graduao).
Universidade Estadual de Montes Claros, Montes Claros,
2004.
[ALVES-05]
ALVES, Jose Luiz Loureiro. Instrumentao controle e

automao de processos. Rio de Janeiro: LTC, 2005.
[ARAJO-07]
ARAJO, Erika Maria Teixeira; BATISTA, Mnica de

Lourdes Souza; MAGALHES, Teresinha Moreira de. Um
estudo sobre as ferramentas OLAP. Faculdades
Integradas Viana Junior, Juiz de Fora, 2007. Disponvel
em:
http://www.devmedia.com.br/articles/viewcomp_forprint.as
p?comp=6691 Acesso em 10 jan. 2010
[BARBOSA-01]
BARBOSA, lvaro Cesar Pereira. Middleware para

Integrao de Dados Heterogneos. Tese (Doutorado).
Pontifica Universidade Catlica do Rio de Janeiro, Rio de
Janeiro, 2001.
219
[BENNETT-98a]
BENNETT, Geoff. Internet working com TCP/IP:

protocolos, servios, segurana e performance. So
Paulo: IBPI PRESS ,1998.
[BENNETT-98b]
BENNETT, Geoff.
Internet working com TCP/IP:
Tecnologia e Infraestrutura. So Paulo: IBPI PRESS,
1998.
[BERNAL-02]
BERNAL, Paulo Sergio Milano; FALBRIARD, Claude.

Redes Banda Larga. Roteamento IP, ATM e
Interwoking em banda larga. So Paulo: rica, 2002.
[BERRY-97]
BERRY, Michael J. A.; LINOFF, Gordon. Data Mining

Techniques. New York: John Wiley, 1997.
[BIO-08]
BIO, Sergio Rodrigues. Sistema de Informao. Um

Enfoque Gerencial. So Paulo: Atlas, 2008.
[BORSOI-04]
BORSOI, Beatriz Terezinha; SCHULTZ, Rbia Eliza de

Oliveira. Estudo Comparativo entre CORBA e JAVA
RMI. Anais do Congresso Anual de Tecnologia da
Informao, CATI, 2004.
[BREBNER-05]
BREBNER, Paul. et al. Middleware benchmarking:

Approaches, results, experiences. Wiley InterScience,
2005.
[CABRAL-05]
CABRAL, Jose Manuel Tavares Vieira. Uma Arquitectura

para Adaptao de Trfego de Baixo Debito em
Aplicaes de Controlo. 2005. Tese (Doutorado)
Universidade do Minho, Portugal, 2005.
[CAMEIRA-03]
CAMEIRA, Renato Flrido. Arquitetura Integrada de

Sistemas: Modelo de Referencia em um Contexto de
(hiper) integrao de processos e sistemas nas
organizaes. Universidade Federal do Rio de Janeiro,
2003.
[CAMPOS, 2009]
CAMPOS Jr, Lellis do Amaral. WirelessHART

Tecnologia Wireless aplicada a instrumentos de
campo. Controle & Instrumentao, So Paulo, n. 144,
p.74-78, fevereiro 2009.
220
[CARMONA-05]
CARMONA, Tadeu; HEXSEL, Roberto A. Universidade

redes. So Paulo: Digerati Books, 2005.
[CARVALHO-93]
CARVALHO,
Tereza
Cristina
Melo
de
Brito.
Gerenciamento de Redes. Uma Abordagem de
Sistemas Abertos. So Paulo: Makron Books, 1993.
[CARVALHO-94]
CARVALHO, Tereza Cristina Melo de Brito. Arquiteturas

de redes de computadores OSI e TCP/IP. So Paulo:
Makron Books, 1994.
[CERRI-04]
CERRI, M. L.; CAZARINI, E. W. Diretrizes para

implantao de ERPs, in ENCONTRO NACIONAL DE
ENGENHARIA DE PRODUO, ENEGEP, Florianpolis,
2004.
[CISCO-09]
CISCO SNA. Technology Brief. Disponvel em

http://www.cisco.com/en/US/tech/tk331/tk341/tech_brief09
186a00800b4258.html Acesso em 10 de janeiro de 2010.
[CHERMONT-07]
CHERMONT,
Marlon
Gripp.
Proposta
de
Desenvolvimento de um Agente Proxy SNMP para
Gerenciamento de Redes LonWorks. Dissertao
(Mestrado). Universidade de So Paulo, So Paulo, 2007.
[CHOWDHURY-02]
CHOWDHURY, Dhiman D. Projetos avanados de

redes IP. Rio de Janeiro: Campus, 2002.
[COMER-06]
COMER, Douglas E. Interligao de redes com TCP/IP.

Princpios, protocolos e arquitetura. Rio de Janeiro:
Elsevier, 2006.
[CORNACHIONE-01]
CORNACHIONE, Jr. Edgard B. Sistemas Integrados de

gesto. So Paulo: Atlas, 2001.
[CORREA-08]
CORREA, Henrique Luiz; GIANESI, Irineu Gustavo

Nogueira; CAON, Mauro. Planejamento, Programao e
Controle da Produo. So Paulo: Atlas, 2008.
[CORREA-08]
CORREA, Henrique Luiz; GIANESI, Irineu Gustavo

Nogueira; CAON, Mauro. Planejamento, Programao e
Controle da Produo. So Paulo: Atlas, 2008.
221
[CORTES-03]
CORTES,
Pedro
Luz.
Sistemas
Fundamentos. So Paulo: rica, 2003.
Operacionais
[COSTA-05]
COSTA, Daniel Gouveia. SCTP Uma alternativa aos

tradicionais protocolos de transporte da Internet. Rio
de Janeiro: Cincia Moderna, 2005.
[COSTA-06]
COSTA, Luis Carlos Moreira. Java avanado. Rio de

Janeiro: Cincia Moderna, 2006.
[COSTA-08a]
COSTA, Daniel G. JAVA em rede. Programao

Distribuda na Internet. Rio de Janeiro: Brasport, 2008.
[COSTA-08b]
COSTA, Daniel Gouveia. Java em Rede: Recursos

Avanados de Programao. Rio de Janeiro: Brasport,
2008.
[COULOURIS-07]
COULOURIS, George; DOLLIMORE, Jean; KINDBERG,

Tim. Sistemas distribudos. Conceitos e Projetos.
Porto Alegre: Bookman, 2007.
[CUMMINS-02]
CUMMINS, Fred A. Integrao de Sistemas. EAI

Enterprise Application Integration: Arquiteturas para
integrao de sistemas e aplicaes corporativas. Rio
de Janeiro: Campus, 2002.
[CUNHA-04]
CUNHA, Judson Michel. Modelo de gerenciamento

integrado para ambientes de redes industriais.
Dissertao (Mestrado). Universidade Federal de Santa
Catarina, Florianpolis, 2004.
[CUSTODIO-95]
CUSTDIO, Joo. Novell NetWare 4.1 Planejamento,

Implementao e Gerenciamento. Rio de Janeiro:
Brasport, 1995.
[CYCLADES-04]
CYCLADES Brasil. Guia Internet de conectividade. So

Paulo: Editora SENAC, 2004.
[DAVENPORT-98]
DAVENPORT, Thomas H. Putting the enterprise into

the enterprise system. Harvard Business Review,
Boston, n.1, jul.1998. 13 p. Disponvel em:
http://www.hbsp.harvard.edu. Acesso em: 20 out. 2007.
222
[DATE-95]
DATE, C.J. An Introduction to database systems. 6.ed.

Reading: Addsison-Wesley, 1995, p. 2-9.
[DERFLER-95]
DERFLER, Frank J. Guia de Conectividade. Rio de

Janeiro: Campus, 1995.
[DEITEL-05]
DEITEL, H. M.; DEITEL, P. J.; CHOFFNES, D. R.

Sistemas Operacionais. 3 ed. So Paulo: Pearson
Pretince Hall, 2005.
[DIOGENES-01]
DIOGENES, Yuri. Certificao CISCO. Rio de Janeiro:

Axcel Books, 2001.
[DOMINGUES-02]
DOMINGUES, Edi; MILHOMEM, Fabiana. Integrando

redes SNA & TCP/IP. Rio de Janeiro: Alta Books, 2002.
[DOWNES-98]
DOWNES, Kevin; FORD, Merilee; LEW, H. Kim;

SPAINER, Steve; STEVENSON, Tim. Internetworking
Technologies Handbook. Indianapolis: Cisco Press,
1998.
[DONAHUE-08]
DONAHUE, Garry A. Redes Robustas. Rio de Janeiro:

Alta Books, 2008.
[EFACEC-06]
EFACEC Sistemas de Electronica. Automao de

Sistemas de Energia. Scatex. 2006. Disponvel em:
http://www.efacec.com.br/docs/TDSC_SCATEXEMS_PT.
pdf. Acesso em 30 mar 2007.
[EDWARDS-99]
EDWARDS, Jeri; HARKEY, Dan; ORFALI; Robert.

Client/Server Survival Guide. 3 Edition. New York:
Wiley, 1999.
[FERNANDES-06]
FERNANDES, V. Viso atual da TI no cho de fbrica

ERP, Automao e Controle, Anais Congresso e
Exposio Visual atual Internacional de Produo
Industrial, ProIndstria, 2006.
223
[FERREIRA-01]
FERREIRA, Claudio Lus. Maestro: Um Middleware para

Suporte a Aplicaes Distribuidas Baseadas em
Componentes de Software. Dissertao (Mestrado).
Escola Politcnica da Universidade de So Paulo, 2001.
[FOROUZAN-06]
FOROUZAN, Behrouz A. Comunicao de dados e

redes de computadores. Porto Alegre: Bookman, 2006.
[FOUNDATION-07]
FOUNDATION FIELDBUS Part 4 Communication. Smar

Automao
Industrial.
Disponvel
em:
http://www.smar.com/brasil2/fieldbus.asp . Acesso em: 24
fev 2007.
[FREITAS-04]
FREITAS, Clayton Arajo; MONTEIRO, Joo W. Alves.

Anlise de protocolos na rea de gerencia de redes
(SNMP/RMON). Monografia (Graduao). Universidade
Federal de Gois, Goinia, 2004.
[GABOS-09]
GABOS, Denis. Gerenciamento de Redes. Laboratrio

de Arquitetura e Redes de Computadores. Escola
Politcnica da Universidade de So Paulo, Notas de
aulas, 2009.
[GABRIEL-01]
GABRIEL, Torres. Redes de computadores: Curso

Completo. Rio de Janeiro: Axcel Books, 2001.
[GEORGINI-00]
GEORGINI, Marcelo. Automao Aplicada. Descrio e

Implementao de Sistemas Seqenciais com PLCs.
So Paulo, rica, 2000.
[GLOVER-07]
GLOVER, Bill; BHATT, Himanshu. Fundamentos de

RFID. Rio de Janeiro: Alta Books, 2007.
[HALL-99]
HALL, Jon. LINUX. Rio de Janeiro: Campus, 1999.
[HANCOCK-03]
HANCOCK, William M. GALLO, Michael A. Comunicao

entre computadores e tecnologias de rede. So Paulo:
Pioneira Thomson Learning, 2003.
[HARRISON-94]
HARRISON, Peter G.; PATEL, Naresh M. Performance

Modelling of Communication Networks and Computer
Architectures. Addison Wesley, 1994.
224
[HART-03]
O protocolo digital Hart, 2003. Disponvel em

http://www.smar.com/PDFs/ApplicationNotes/AppNotes_H
ART.pdf Acesso em 14 nov. 2009.
[HOPCROFT-02]
HOPCROFT, John; ULLMAN, Jeffrey D.; MOTWANI,

Rajjev. Introduo Teria de Autmatos, Linguagens e
Computao. Rio de janeiro: Elsevier, 2002.
[HUBBARD-03]
HUBBARD, John R. Programao em C++. Porto Alegre:

Bookman, 2003.
[JURIZATO-02]
JURIZATO, Luis Augusto; PEREIRA, Paulo Sergio R.

Sistemas Supervisrios. Network Technologies, Nova
Odessa, v.1/2, p. 105-114, 2002.
[KRISHNAMURTHY-01]
KRISHNAMURTHY, Balachander; REXFORD, Jennifer.

Redes para a Web. Rio de Janeiro. Campus. 2001.
[LAUDON-98]
LAUDON, Kenneth C.; LAUDON, Jane P. Management

Information Systems: New approaches to organization
& technology. 5 ed. New Jersey: Prentice Hall, 1998.p
280-282.
[LAUREANO-06]
LAUREANO, Marcos. Mquinas Virtuais e Emuladores.

Conceitos, Tcnicas e Aplicaes. So Paulo: Novatec
Editora, 2006.
[LEE-01]
LEE, Richard C.; TEPFENHART, William M. UML e C++

Guia Pratico de Desenvolvimento Orientado Objeto.
So Paulo: Makron Books, 2001.
[LOPES-00]
LOPES, Aldab Ricardo. Sistemas de redes para

controle e automao. Rio de Janeiro: Book Express,
2000.
[LONWORKS-09]
LonWorks Technology Overview, 2009. Disponvel em:

http://www.echelon.com/communities/energycontrol/devel
opers//lonworks/default.htm Acesso em 22 nov. 2009.
[LOPES-02]
LOPES, Raquel Vigolvino. Melhores Prticas para a

Gerncia de Redes de Computadores. Dissertao
225
(Mestrado). Universidade Federal da Paraba, Campina

Grande, 2002.
[LUGLI-07]
LUGLI,
Alexandre
Baratella.
Uma
Ferramenta
Computacional para Analise de Topologia e Trafego
para
Redes
Ethernet
Industriais.
Dissertao
(Mestrado). Universidade Federal de Itajub, Itajub,
2007.
[MACHADO-07]
MACHADO, Francis Berenger; MAIA, Luiz Paulo.

Arquitetura de sistemas operacionais. 4 ed. Rio de
Janeiro: LTC, 2007.
[MACIEL-04]
MACIEL, Rita Suzana Pitangueira; ASSIS, Semrames

Ribeiro de. Uma soluo para o desenvolvimento de
aplicaes distribudas, Salvador, 2004.
[MAHMOUD-04]
MAHMOUD, Qusay. Middleware for Communications.

USA: Wiley, 2004.
[MARANGONI-08]
MARANGONI, Matheus. Software de Gesto ERP.

Relatrio Completo. SEBRAE Servio Brasileiro de Apoio
s Micros e Pequenas Empresas, 2008.
[MELLQUIST-94]
MELLQUIST, Peter E. SNMP++ Na Object Oriented

Approach For Netowork Management Programming
Using C++. Revision 2.1.Hewlett Packard, 1994.
[MENASCE-02]
MENASCE, Daniel A.; ALMEIDA, Virgilio A. F.

Planejamento de capacidade para servios na Web.
Mtricas, Modelos e Mtodos. Rio de Janeiro: Campus,
2002.
[MIO-07]
MIO, Rodolfo. Implementao de Sistemas ERP

(Enterprise Resource Planning) SAP R/3 e suas
Tecnologias
Middleware.
Dissertao
(MBA).
Universidade de So Paulo, So Paulo, 2007.
[MODBUS-96]
Modicon Modbus Protocol Reference Guide, 1996.

Disponvel
em
http://www.modbus.org/docs/PI_MBUS_300.pdf
Acesso
em 05 de nov. 2009.
226
[MODBUS-06]
Modbus Application Protocol Specification v1.1b, 2006.

Disponvel
em
http://www.modbus.org/docs/modbus_application_protocol
_v1_1b.pdf. Acesso em 12 dez. 2009.
[MORAES-07]
MORAES, Ccero Couto de; CASTRUCCI, Plnio de

Lauro. Engenharia de Automao Industrial. 2 ed. Rio
de Janeiro: LTC, 2007.
[MOURA-86]
MOURA, J. A. B.; GIOZZA,W. F.; SAUV, J. P.; ARAJO,

J. F. M. de. Redes Locais de Computadores. So Paulo:
McGraw-Hill, 1986.
[MUELLER-02]
MUELLER, Stephen M. APIs AND PROTOCOLS FOR

CONVERGENT NETWORK SERVICES. New York:
McGraw-Hill, 2002.
[MULLENDER-95]
MULLENDER, Sape. Distributed Systems. New York:

Addsion-Wesley, 1995.
[NCS-04]
NCS TIB 04-1. TECHNICAL Information Bulletin 04-1,

2004. NATIONAL COMMUNICATIONS, SYSTEM SCADA Supervisory Control and Data Acquisition
Systems.
Disponvel
em:
http://www.ncs.gov/library/tech_bulletins/2004/tib_04-1.pdf
Acesso em: 17 set 2007.
[NETO-08]
NETO, Pedro Otvio Alves; SILVA, Robson Soares.

Tecnologias de Sistemas Distribuidos Implementados
em JAVA: Sockets, RMI, RMI-IIOP e CORBA. Anurio
da Produo Acadmica Docente, vol. II, n. 3, 2008.
[NEVES-08]
NEVES, Jos Manoel Souza das; SANTOS, Fernando

Csar Almada. Implantao de tecnologias de
informao utilizadas na integrao entre o cho-defbrica e os sistemas ERP. Controle & Instrumentao,
So Paulo, n. 143, p. 56-61, 2008.
[NIRVA-01]
NIRVA, Morisseau-Leroy. Oracle 8i Programao de

Componentes Java com EJB, CORBA e JSP. Rio de
Janeiro: Campus, 2001.
227
[ODVA-07a]
ODVA Profile File. Network Infrastructure for

EtherNet/IP: Introduction and Considerations. ODVA
Publication, 2007.
[ODVA-07b]
Especificao
EtherNet/IP.
Disponvel
em
http://www.odva.org/Portals/0/Library/Publications_Numbe
red/PUB00035R0_Infrastructure_Guide.pdf Acesso em 18
out. 2009.
[OLIFER-08]
OLIFER,
Victor;
OLIFER,
Natlia.
Redes
de
Computadores: Princpios, Tecnologias e Protocolos
para o Projeto de Redes. Rio de Janeiro: LTC. 2008.
[ORFALI-98]
ORFALI,
Robert;
HARKEY,
Dan.
Client/Server
Programming with JAVA and CORBA. 2 ed. New York:
Wiley, 1998.
[PAVA-09]
PAVA, Pablo; ELIAS, Fbio Henrique. MOM A terceira

gerao de sistemas ERP. InTech, So Paulo, n. 116, p.
26-29, 2009.
[PEREIRA-03]
PEREIRA, Carlos Eduardo. Evoluo dos Sistemas de

Controle. Porto Alegre, Brasil, 2003. Disponvel em:
http://www.eletro.ufrgs.br/~cpereira. Acesso em 22 out
2008.
[PETERSON-04]
PETERSON, Larry L. BRUCE S. Davie. Redes de

Computadores. Uma abordagem de sistemas. Rio de
Janeiro: Elsevier, 2004.
[PINHEIRO-06]
PINHEIRO, Jos Mauricio Santos. Introduo s Redes

de Superviso e Controle, 2006.
[PITANGA-04]
PITANGA, Marcos. Construindo supercomputadores

com Linux. 2 ed. Rio de Janeiro: Brasport, 2004.
[PRESSMAN-06]
PRESSMAN, Roger S. Engenharia de Software. So

Paulo: McGraw-Hill, 2006.
228
[PROFFITT-01]
PROFFITT,
Brian;
ZUPAN,
Ann.
XHTML
Desenvolvimento WEB. So Paulo: Makron Books,
2001.
[PRUDENTE-07]
PRUDENTE, Francesco. Automao Industrial. Rio de

Janeiro: LTC, 2007.
[PROFIBUS-06]
PROFIBUS Descrio Tcnica. Associao PROFIBUS

Brasil 2006. Disponvel em http://www.profibus.org.br.
Acesso em 12 mar. 2008.
[PUPO-02]
PUPO, Maurcio Santos. Interface homem - mquina

para superviso de um CLP em controle de processo
atravs da WWW. Dissertao (Mestrado) Escola
Politcnica Universidade de So Paulo, So Paulo, 2002.
[RALHA-04]
RALHA, Claudio. Segredos do Visual Studio.Net. So

Paulo: Digital Books, 2004.
[RENAUD-94]
RENAUD, Paul E. Introduo aos sistemas

cliente/servidor. Rio de Janeiro: Infobook, 1994.
[RISO-04]
RISO, Bernardo Gonalves; MACIEL, Cristiano; SOUZA,

Ivanise Volpato; ROSSI, Leila Lisiane; NOTARE, Mirela
Sechi Moretti; TONIN, Neilor Avelino. Engenharia de
Protocolos com LOTOS/ISO. Florianpolis: Editora
UFSC, 2004.
[ROCHA-03]
ROCHA, Helder da. Fundamentos de Objetos Remotos.

Java 2 Standard Edition, 2003. Disponvel em
http://www.argonavis.com.br: Acesso em 12 de jul 2010.
[RODRIGUES-07]
RODRIGUES, Gustavo Viana. Disponibilizaao de

Servios de Segurana para Sistemas Distribuidos
atravs de WebServices. Monografia (Graduao).
Universidade Regional de Blumenau, Blumenau, 2007.
[ROSRIO-05]
ROSRIO, Joo Mauricio. Princpios de Mecatrnica.

So Paulo: Prentice Hall, 2005.
229
[ROSS-06]
ROSS, Keith W.; KUROSE, James F. Redes de

Computadores e a Internet. Uma abordagem topdown. 3 ed. So Paulo: Pearson Addison Wesley, 2006.
[SANTOS-06]
SANTOS, Breno Henrique Vivarelli Diego Lima.

Automao e Controle da Usina Hidreltrica de Itaipu
utilizando o Sistema SCADA/MES. Monografia
(Graduao). Universidade Estadual de Ponta Grossa,
Ponta Grossa, 2006.
[SANTOS-07]
SANTOS, Alfredo Luiz dos. Integrao de Sistemas com

Java. Rio de Janeiro: Brasport, 2007.
[SCHACH-09]
SCHACH, Stephen. Engenharia de Software: Os

Paradigmas Classico & Orientado Objetos. 7 ed.
So Paulo: McGraw-Hill, 2009.
[SCHANTZ-01]
SCHANTZ, Richard E.; SCHMIDT, Douglas. Middleware

for Distributed Systems Evolving the Common
Structure for Network-centric Applications Encyclopedia of
Software Engineering, 2001.
[SCHATT-93]
SCHATT, Stan. Como Funcionam as REDES LOCAIS.

Rio de Janeiro: Berkeley, 1993.
[SCHMIDT-01]
SCHMIDT, Kevin J. SNMP essencial. Rio de Janeiro:

Campus, 2001
[SCHMIDT-05]
SCHMIDT, Kevin J.; DOUGLAS

Essential. USA: O`Reilly, 2005.
[SEIXAS-03]
SEIXAS, Constantino. Programao Concorrente em

Ambiente Windows. Uma Viso de Automao. Belo
Horizonte: Editora UFMG, 2003.
[SEIXAS-09]
SEIXAS, Constantino. MES. Funcionalidades. InTech,

So Paulo, n. 116, p. 20-25, 2009.
[SERAIN-02]
SERAIN,
Daniel.
Middleware
and
Enterprise
Application Integration. London: Springer, 2002
R. Mauro. SNMP
230
[SHELDON-93]
SHELDON, Tom. Novell NetWare 4: The Complete

Reference. Berkeley: McGraw-Hill, 1993
[SHIRASUNA-08]
SHIRASUNA, Mauro. MES: Situao presente e

expectativa do futuro. Controle & Instrumentao, So
Paulo, n. 143, p. 66-71, 2008.
[SIEGEL-96]
SIEGEL; J. CORBA: Fundamentals and Programming,

John Wiley & Sons Inc. 1996.
[SILBERSCHATZ-99]
SILBERSCHATZ,
Abraham;
KORTH,
Henry
F.;
SUDARSHAN, S. Sistema de Banco de Dados. So
Paulo: Makron Books, 1999.
[SILVA-03]
SILVA, Lino Sarlo. Virtual Private Network. So Paulo:

Novatec Editora, 2003.
[SILVA-05]
SILVA, Ana Paula Gonalves da; SALVADOR, Marcelo. O

que so Sistemas Supervisrios? Elipse, 2005.
[SILVA-06]
SILVA, Luiz Antonio Ferreira da. Anlise de

Desempenho de Protocolos de Transporte para Redes
de Alta Velocidade. Dissertao (Mestrado) Universidade Federal do Rio de Janeiro, Rio de janeiro,
2006.
[SILVEIRA-98]
SILVEIRA, Paulo R. da; SANTOS, Winderson Eugenio

dos. Automao e Controle Discreto. 6. Ed. So Paulo:
rica, 1998.
[SIPSER-07]
SIPSER, Michael. Introduo teoria da computao.

So Paulo: Thompson Learning, 2007.
[SIMCSIK-02]
SIMCSIK, Tibor; POLLONI, Enrico G. F. Tecnologia da

Informao Automatizada. So Paulo: Berkeley Brasil,
2002.
[SOARES-99]
SOARES, Luis Fernando Gomes; LEMOS, Guido;

COLCHER, Sergio. Redes de computadores das LANs
MANs e WANs as redes ATM. 2 ed. Rio de Janeiro:
Campus, 1999.
231
[SOMMERVILLE-07]
SOMMERVILLE, Ian. Engenharia de Software. 8 ed.

So Paulo: Pearson Addison-Wesley, 2007.
[SOUZA-00]
SOUZA, Cesar Alexandre de. Sistemas Integrados de

Gesto Empresarial. Dissertao (Mestrado). Faculdade
de Economia, Administrao e Contabilidade USP, So
Paulo, 2000.
[SOUSA-03]
SOUSA, Paulo Manuel Baltarejo de. EtherNet/IP.

Monografia (Graduao). Instituto Superior de Engenharia
do Porto, Portugal, 2003.
[SOUZA-05]
SOUZA, Rodrigo Barbosa. Uma Arquitetura para

Sistemas Supervisrios Industriais e sua Aplicao
em Processos de Elevao Artificial de Petrleo.
Dissertao (Mestrado). Universidade Federal do Rio
Grande do Norte, Natal, 2005.
[STALLINGS-98]
STALLINGS,
William.
SNMP
v3
A
Security
enhancement for SNMP. IEE communications Surveys &
tutorials, v.1, n.1, 1998. p.2-17. Disponvel em:
http://www.dl.comsoc.org/cocoon/consoc/html/index.htm
Acesso em: 20 dez. 2007
[STALLINGS-99]
STALLINGS, William. SNMP, SNMPv2, SNMPv3, RMON

1 and 2. New York: Addison Wesley, 1999.
[STALLINGS-08]
STALLINGS, Willian. Criptografia e Segurana de

Redes: Princpios e Prticas. So Paulo: Pearson
Prentice Hall, 2008.
[STEMMER-01]
STEMMER, Marcelo Ricardo. Sistemas Distribudos e

Redes de Computadores para Controle e Automao
Industrial. Universidade Federal de Santa Catarina, 2001.
[TAKAHASHI-90]
TAKAHASHI, Tadao; LIESEMBERG, Hans K. E.; XAVIER,

Daniel Tavares. Programaao Orientada Objetos:
Uma Viso Integrada do Paradigma de Objetos. So
Paulo: IME-USP, 1990.
[TANG-92]
TANG, Adrian; SCOGGINS, Sophia. Open Networking

with OSI. New Jersey: Pretince Hall, 1992.
232
[TANENBAUM-03]
TANENBAUM, Andrew S. Redes de computadores. 4.

Ed. Rio de Janeiro: Campus, 2003.
[TANENBAUM-07]
TANENBAUM, Andrew S.; STEEN, Maarten Van.

Sistemas distribudos. Princpios e paradigmas. 2 ed.
So Paulo: Pearson Prentice Hall, 2007.
[THIEME-05]
THIEME, Moises. Modelo de Governana em

Facilidades Prediais para Centros de Tecnologia da
Informao de Instituies Financeiras. Dissertao
(MBA). Universidade de So Paulo, So Paulo, 2005.
[THOMPSON-02]
THOMPSON, Marco Aurlio. Proteo e Segurana na

Internet. So Paulo: rica, 2002.
[TOVAR-96]
TOVAR, Eduardo. Introduo Informtica Industrial.

Lisboa: IPP-ISEP, 1996.
[TOVAR-03]
TOVAR,
Eduardo.
Produo
Integrada
por
Computador. Instituto Politcnico do Porto, Lisboa,
Portugal,
2003.
Disponvel
em:
http://www.dei.isep.ipp.pt/~emt/infind/apontamentos.html.
Acesso em 23 de jan. 2010.
[VIANA-08]
VIANA, Eliseu Ribeiro Cherene. Virtualizao de

servidores LINUX para redes corporativas. Rio de
Janeiro: Editora Cincia Moderna, 2008.
[YOURDON-99]
YOURDON, Edward; ARGILA, Carl. Anlise e Projeto

Orientados Objetos. Estudos de Casos. So Paulo:
Makron Books, 1999.
[WADLOW-00]
WADLOW, Thomas A. Segurana de redes. Projeto e

gerenciamento de redes seguras. Rio de Janeiro:
Campus, 2000.
[WANG-98]
WANG, Charles B. Techno Vision II. So Paulo: Makron

Books, 1998.
[WATANABE-06]
WATANABE, Edson Hiroshi. Aplicao de Software

Aberto em Redes Industriais. Dissertao (Mestrado).
Universidade Federal do Paran, Curitiba, 2006.
233
[ZOLDAN-04]
ZOLDAN, Alan David; S, Claudio Cesar; AGNOL,

Everson Dall; PARPINELLI, Rafael; DECKER, Rangel.
SCADA ++ A Distributed Object Oriented Control and
Data Acquisition System, Joinville, 2004.

Dissertacao Marcos Roberto Alves Martins

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Dissertacao Marcos Roberto Alves Martins

Transféré par

Droits d'auteur :

Formats disponibles

MARCOS ROBERTO ALVES MARTINS

INTEGRAO SISTMICA EM MIDDLEWARE

MARCOS ROBERTO ALVES MARTINS

INTEGRAO SISTMICA EM MIDDLEWARE

Este exemplar foi revisado e alterado em relao verso

Martins, Marcos Roberto Alves

Para Marcos Filho, que a criatividade e a dedicao

A todos os Professores que contriburam com conhecimento e dedicao.

A todos os colegas com os quais tive o privilgio de conviver durante o perodo de

minha famlia pela motivao e compreenso e pelas horas de ausncia.

Ao meu pai Osvaldo (in memorian) pelo exemplo de vida e perseverana.

minha esposa Antonia pela dedicao e companheirismo.

Ao meu filho Marcos pelo incentivo.

minha irm Djanira pela motivao e orientao.

A DEUS sobretudo, pelo grande milagre da Vida.

No basta ensinar ao homem uma

O presente trabalho estuda de forma analtica as diversas arquiteturas de redes

Palavras-chave: Middleware, Redes, Integrao.

Keywords: Middleware, Network Integration.

Splitting camada (N)

Pass-through dos servios de sesso

Relao entre processos, entidades e elementos de servio

Transmisso de dados no Modelo OSI

Sistema distribudo organizado como Middleware

Sistemas com mltiplos processadores

Arquitetura em camadas computao em grade

Camadas de software e hardware em sistemas distribudos

Arquitetura de sistema operacional de ncleo monoltico

Aplicao de banco de dados por arquivo compartilhado e

As ondas da arquitetura cliente/servidor

Estrutura de banco de dados hierrquico

Sistema corporativo e seus subsistemas

Tecnologia da informao e sistemas de informao

Comunicao entre cliente e servidor com Novell

Modelo Novell x Modelo OSI

Encapsulamentos existentes para IPX

Sliding Window - controle de fluxo em protocolo

Interface Shell da rede Novell

Modelo de Referncia OSI e arquitetura SNA

Modelo Rede SNA

Projeto original da Ethernet

Correspondncia entre protocolos modelo OSI e protocolos

Formato Frame Ethernet DIX V1.0 e IEEE 802.3

Variantes do Frame Ethernet

Estrutura dos padres IEEE 802.x

IEEE 802.3z e IEEE 802.3ab

Frames IEEE 802.3 e 802.3q

Camadas da arquitetura TCP/IP

Camadas do Modelo OSI e TCP/IP

Camada de Rede - Servios

Servios executados na camada de transporte

Estrutura do segmento TCP

Estrutura do segmento UDP

Formato de datagrama Internet TCP/IP

Formatos cabealhos IPv4 e IPv6

Classificao geral dos sistemas de automao

Linguagens de programao IEC 61131-3

Estrutura da Pirmide de Automao

Base de Dados Comum

Camadas Fieldbus Foundation e Modelo de Referncia OSI

Arquiteturas das Redes Fieldbus

Comparao entre o Modelo OSI e o padro Fieldbus

Comparao entre Modelo OSI e padro Fieldbus H1.

Arquitetura do protocolo Profibus.