redes industriais gama filho (2).pdf

UNIVERSIDADE GAMA FILHO

GRADUAÇÃO 2013

REDES INDUSTRIAIS – CTA 157 Professor: William Paes da Silva

GRADUAÇÃO EM ENGENHARIA DE CONTROLE E AUTOMAÇÃO INDUSTRIAL GRADUAÇÃO TECNOLÓGICA EM AUTOMAÇÃO INDUSTRIAL GRADUAÇÃO EM ENGENHARIA ELÉTRICA COM ÊNFASE EM ELETRÔNICA

Estudo sobre o funcionamento, definição e tipos de redes utilizadas em Automação nas indústrias de diversos segmentos.

V1 .3 .1 .2013

AO ALUNO

Este material é destinado aos alunos do curso de Graduação em Engenharia de Controle e

Automação industrial, Graduação Tecnológica em Automação Industrial e Graduação em Engenharia Elétrica

com Ênfase em Eletrônica da Universidade Gama Filho.

Esta apostila tem um grande conteúdo de informações

que com certeza vai ajudar ao aluno ver de uma forma diferente o

ambiente que cerca a comunicação de dados industriais. Obviamente

não serão abordados todos os tipos de redes industriais do mercado,

mas com certeza as mais utilizadas e mais importantes terão

destaque. Este material foi feito de forma que o aluno compreenda o

funcionamento de uma rede industrial de dados. Também será

mencionada a utilização de Servidores OPC em redes industrias, já

que a difusão de informações se tornou um fator de extrema

importância nas empresas, independente da camada de atuação, seja

o chão de fabrica (Física) ou ERP (Aplicação).

A Universidade Gama Filho, mais especificamente a Coordenação de Engenharia de Controle e

Automação Industrial, inova mais uma vez e abordará esta disciplina de uma forma objetiva, clara e coerente,

com muita prática de laboratório. O grande desafio é diminuir a lacuna existente entre o ensinamento teórico

e a experiência prática.

William Paes da Silva

08 Fall

GRADUAÇÃO 2013 UNIVERSIDADE GAMA FILHO

ENGENHARIA DE CONTROLE E AUTOMAÇÃO INDUSTRIAL / TECNOLOGIA EM AUTOMAÇÃO INDUSTRIAL / ENGENHARIA ELÉTRICA COM ÊNFASE EM ELETRÔNICA

Redes Industriais Página 3 de 398

ÍNDICE

1 . INTRODUÇÃO ..................................................................................................................................... 16 1.1. A COMUNICAÇÃO .................................................................................................................................................. 16 1.2. SISTEMAS COMPUTACIONAIS .................................................................................................................................. 16 1.3. ARQUITETURAS DE COMPUTADORES ........................................................................................................................ 17 1.4. SISTEMAS DISTRIBUÍDOS ....................................................................................................................................... 17

2. REDES DE COMPUTADORES ............................................................................................................ 20 2.1. TOPOLOGIAS DE REDES ........................................................................................................................................ 20

2.1.1. Análise da Topologia Totalmente Ligada .................................................................................................. 21 2.1.2. Análise da Topologia em Anel .................................................................................................................... 22 2.1.3. Análise da Topologia Parcialmente Ligada ............................................................................................... 23 2.1.4. Troca de Mensagens .................................................................................................................................. 23 2.1.5. Análise da Topologia em Estrela ............................................................................................................... 24 2.1.6. Análise da Topologia em Anel “Fechado” ................................................................................................. 26 2.1.7. Análise da Topologia em Barra .................................................................................................................. 27

2.2. SINAIS ANALÓGICOS E DIGITAIS .............................................................................................................................. 28 2.2.1. Multiplexação .............................................................................................................................................. 29 2.2.2. Multiplexação na Frequência ...................................................................................................................... 30 2.2.3. Modulação ................................................................................................................................................... 30 2.2.4. Protocolos ................................................................................................................................................... 32

3. ESTRUTURAÇÃO DE UMA REDE DE COMPUTADORES ................................................................... 35 3.1. MODELO OSI ...................................................................................................................................................... 35 3.2. CONCENTRADORES E CHAVEADORES ....................................................................................................................... 38 3.3. DISTORÇÃO DE SINAIS .......................................................................................................................................... 39 3.4. DETECÇÃO DE ERROS ........................................................................................................................................... 40

4. COMUNICAÇÃO SERIAL RS-232(S INGLE-ENDED) ......................................................................... 43 4.1. INTRODUÇÃO ....................................................................................................................................................... 43 4.2. FUNDAMENTOS DA COMUNICAÇÃO SERIAL RS-232 (SINGLE-ENDED) ......................................................................... 44 4.3. ESPECIFICAÇÕES .................................................................................................................................................. 45 4.4. CARACTERÍSTICAS ELÉTRICAS ................................................................................................................................. 45 4.5. CARACTERÍSTICAS FUNCIONAIS ............................................................................................................................... 47 4.6. CARACTERÍSTICAS MECÂNICAS DA INTERFACE ........................................................................................................... 48 4.7. FUNCIONAMENTO ................................................................................................................................................ 49 4.8. COMUNICAÇÃO DE DADOS ..................................................................................................................................... 51 4.9. IMPLEMENTAÇÃO PRÁTICA DA RS-232 .................................................................................................................. 52 4.10. RS-232 EM APLICAÇÕES UTILIZANDO MODEMS ..................................................................................................... 53 4.11. RS-232 EM APLICAÇÕES COM INTERCÂMBIO (HANDSHAKING) MÍNIMO ...................................................................... 56 4.12. LIMITAÇÕES DA REDE RS-232 .............................................................................................................................. 57 4.13. GERAÇÃO DOS NÍVEIS DE TENSÃO RS-232 ............................................................................................................. 58 4.14. TAXA MÁXIMA DE DADOS ...................................................................................................................................... 58 4.15. COMPRIMENTO MÁXIMO DO CABO .......................................................................................................................... 58

5. COMUNICAÇÃO SERIAL RS-423A (S INGLE-ENDED) ...................................................................... 61 5.1. CARACTERÍSTICAS GERAIS ..................................................................................................................................... 61 5.2. TABELA COMPARATIVA ....................................................................................................................................... 61

6. COMUNICAÇÃO SERIAL RS-422 (D IFERENCIAL) ........................................................................... 63 6.1. INTRODUÇÃO ...................................................................................................................................................... 63 6.2. CARACTERÍSTICAS GERAIS ..................................................................................................................................... 63



6.3. TABELA COMPARATIVA ........................................................................................................................................ 64 7. COMUNICAÇÃO SERIAL RS-485 (D IFERENCIAL) ........................................................................... 66

7.1. INTRODUÇÃO ...................................................................................................................................................... 66 7.2. CARACTERÍSTICAS ............................................................................................................................................... 66 7.3. ATERRAMENTO .................................................................................................................................................... 69 7.4. BLINDAGEM (SHIELDING) .................................................................................................................................... 73 7.5. TOPOLOGIA ........................................................................................................................................................ 74 7.6. TERMINAÇÃO ...................................................................................................................................................... 75 7.7. POLARIZAÇÃO DO ESTADO INATIVO ........................................................................................................................ 77 7.8. TABELA DE ESPECIFICAÇÕES ................................................................................................................................ 78 7.9. COMPARAÇÃO ENTRE OS PADRÕES RS422 E RS485 ............................................................................................. 78 7.10. TABELA COMPARATIVA (RS232, RS423, RS422 E RS 485) ................................................................................. 79

8. REDES INDUSTRIA IS ......................................................................................................................... 81 8.1. REDE SENSORBUS - DADOS NO FORMATO DE BITS ................................................................................................... 84 8.2. REDE DEVICEBUS - DADOS NO FORMATO DE BYTES ................................................................................................... 84 8.3. REDE FIELDBUS - DADOS NO FORMATO DE PACOTES DE MENSAGENS ........................................................................... 84

9. REDE AS- I .......................................................................................................................................... 87 9.1. INTRODUÇÃO ...................................................................................................................................................... 87 9.2. CONECTIVIDADE .................................................................................................................................................. 89 9.3. USO DE VARIÁVEIS ANALÓGICAS ............................................................................................................................ 90 9.4. DETERMINISMO NO TEMPO .................................................................................................................................. 91 9.5. ACESSO À CAMADA FÍSICA ..................................................................................................................................... 92 9.6. MENSAGENS AS-I .............................................................................................................................................. 93

9.6.1. Data Exchange ........................................................................................................................................... 94 9.6.2. Write Parameter ......................................................................................................................................... 94 9.6.3. Definição do Endereço de um Nó ............................................................................................................. 95 9.6.4. Configuração de I/O ................................................................................................................................... 95 9.6.5. Read ID Code ............................................................................................................................................. 95 9.6.6. Read Status ................................................................................................................................................ 95

9.7. TOPOLOGIAS ....................................................................................................................................................... 99 9.8. FONTE AS-I ........................................................................................................................................................ 99 9.9. COMPRIMENTO DO CABO .................................................................................................................................... 100 9.10. BENEFÍCIOS (ECONOMIA) ................................................................................................................................... 101

10. HART .............................................................................................................................................. 103 10.1. INTRODUÇÃO ................................................................................................................................................... 103 10.2. O SINAL HART ................................................................................................................................................. 103 10.3. TOPOLOGIA ...................................................................................................................................................... 105 10.4. MODOS DE COMUNICAÇÃO .................................................................................................................................. 107 10.5. CABOS ............................................................................................................................................................. 109 10.6. COMANDOS HART .............................................................................................................................................. 109 10.7. DEVICE DESCRIPTION LANGUAGE ......................................................................................................................... 110 10.8. MULTIPLEXADORES ........................................................................................................................................... 110

11. DEVICENET .................................................................................................................................... 114 11.1. INTRODUÇÃO ................................................................................................................................................... 114 11.2. CARACTERÍSTICAS DO NÍVEL FÍSICO ....................................................................................................................... 116 11.3. COLOCAÇÃO DA FONTE DE ALIMENTAÇÃO ............................................................................................................... 122 11.4. DEVICENET ASSISTANT ...................................................................................................................................... 124 11.5. CONTROLE DE ACESSO AO MEIO – CAMADA DLL .................................................................................................... 124



11.6. ARBITRAGEM .................................................................................................................................................... 125 11.7. MODELO DE REDE ............................................................................................................................................. 126

11.7.1. Mestre/Escravo ..................................................................................................................................... 126 11.7.2. Peer to Peer .......................................................................................................................................... 127 11.7.3. Multi-Mestre ........................................................................................................................................... 127 11.7.4. Mudança do Estado do Lado ................................................................................................................ 128 11.7.5. Produção Cíclica de Dados ................................................................................................................... 128

11.8. MENSAGENS ..................................................................................................................................................... 129 11.8.1. Mensagens de Entrada / Saída ............................................................................................................ 129 11.8.2. Mensagens explícitas ............................................................................................................................ 130 11.8.3. Predefined Master / Slave Connection Set .......................................................................................... 131

11.9. O MODELO DE OBJETOS .................................................................................................................................... 132 11.9.1. Objeto Identidade .................................................................................................................................. 133 11.9.2. Objeto Roteador de Mensagens ........................................................................................................... 134 11.9.3. Objeto Assembly .................................................................................................................................... 134 11.9.4. Objetos de Conexão .............................................................................................................................. 134 11.9.5. Objetos de Parametrização .................................................................................................................. 135 11.9.6. Objetos de Aplicação ............................................................................................................................ 135

11.10. ELECTRONIC DATA SHEET (EDS) .................................................................................................................... 135 12. MODBUS ........................................................................................................................................ 138

12.1. INTRODUÇÃO ................................................................................................................................................... 138 12.1.1. Transações em Redes Modbus ............................................................................................................ 140 12.1.2. Transações em Outros Tipos de Redes ............................................................................................... 140 12.1.3. O Ciclo de Comunicação ........................................................................................................................ 142

12.2. OS DOIS MODOS DE TRANSMISSÃO SERIAL ........................................................................................................... 143 12.2.1. Modo ASCII ............................................................................................................................................. 144 12.2.2. Modo RTU ............................................................................................................................................... 145

12.2. FRAME DE MENSAGEM ..................................................................................................................................... 145 12.3.1. Frame ASCII ............................................................................................................................................ 146 12.3.2. Frame RTU ............................................................................................................................................. 147 12.3.3. Controle de Endereçamento ................................................................................................................. 148 12.3.4. Campo de Função .................................................................................................................................. 149 12.3.5. Campo de Dados ................................................................................................................................... 151 12.3.6. Campo de Verificação de Erros ............................................................................................................ 152 12.3.7. A Transmissão Serial de Caracteres ..................................................................................................... 152

12.3. MÉTODO DE VERIFICAÇÃO DE ERROS .................................................................................................................. 153 12.4.1. Verificação de Paridade ........................................................................................................................ 154 12.4.2. Verificação de LRC ................................................................................................................................. 155 12.4.3. Verificação de CRC ................................................................................................................................. 155

13. PROFIBUS ...................................................................................................................................... 159 13.1. INTRODUÇÃO .................................................................................................................................................... 159 13.2. PROFIBUS DP (DISTRIBUTED PERIPHERALS) ........................................................................................................ 160 13.3. PROFINET ........................................................................................................................................................ 160 13.4. PROFIBUS PA (PROCESS AUTOMATION) ............................................................................................................... 160 13.5. CARACTERÍSTICAS GERAIS ................................................................................................................................... 161 13.6. CARACTERÍSTICAS DO NÍVEL FÍSICO ...................................................................................................................... 162 13.7. PROFIBUS PA ................................................................................................................................................... 163

13.7.1. IEC 1158-2 ............................................................................................................................................. 165 13.7.2. Topologias .............................................................................................................................................. 168



13.7.3. Blocos de funções PA ........................................................................................................................... 170 13.7.4 Exemplo: Parâmetros do bloco de função AI ....................................................................................... 172

13.8. PROFIBUS DP .................................................................................................................................................. 173 13.8.1. Velocidade da Rede ............................................................................................................................... 174 13.8.2. Tempo de Ciclo ........................................................................................................................................... 177 13.8.3. Topologias ............................................................................................................................................ 178 13.8.4. Uso de Fibra Ótica ................................................................................................................................. 179 13.8.5. Protocolo de Acesso ao Meio ............................................................................................................... 180 13.8.6. Protocolo Token Passing ...................................................................................................................... 180

13.9. CONEXÃO DA REDE PROFIBUS PA À REDE PROFIBUS DP ..................................................................................... 181 13.10. ARQUIVO DE CONFIGURAÇÃO: GSD – GENERAL SLAVE DATA ................................................................................... 184 13.11. EXEMPLO GSD ................................................................................................................................................. 184 13.12. COMPARAÇÃO DE CUSTO PROFIBUS X 4…20MA .................................................................................................. 187 13.13. ORÇAMENTO 4... 20MA .................................................................................................................................... 187 13.14. ORÇAMENTO PROFIBUS–PA .............................................................................................................................. 188 13.15. PROFIBUS E ETHERNET (PROFINET) ................................................................................................................... 190

14. FOUNDATION F IELDBUS .............................................................................................................. 193 14.1. INTRODUÇÃO .................................................................................................................................................... 193 14.2. ARQUITETURA DO SISTEMA ................................................................................................................................. 198 14.3. CAMADA DE APLICAÇÃO E BLOCOS ........................................................................................................................ 199 14.4. BLOCOS AVANÇADOS ......................................................................................................................................... 202 14.5. CAMADA FÍSICA ................................................................................................................................................. 206 14.6. ELEMENTOS DE REDE ........................................................................................................................................ 210 14.7. CICLO DE OPERAÇÃO .......................................................................................................................................... 213 14.8. SINCRONIZAÇÃO NO TEMPO ................................................................................................................................. 214

14.8.1. Sincronização do Tempo de Datalink ................................................................................................... 214 14.8.2. Sincronismo do Time of Day ................................................................................................................. 215 14.8.3. Identificação dos Dispositivos ............................................................................................................... 215 14.8.4. Dicionário de Objetos ............................................................................................................................ 216 14.8.5. Comunicação Escalonada ...................................................................................................................... 217 14.8.6. Comunicação Não Escalonada .............................................................................................................. 217

14.9. A OPERAÇÃO DO LAS ........................................................................................................................................ 218 14.10. VIRTUAL COMMUNICATION RELATIONSHIPS (VCR) ................................................................................................. 219

14.10.1. Comunicação Cliente – Servidor ......................................................................................................... 219 14.10.2. Distribuição de Relatório (Report Distribution or Source and Sink) ................................................ 221 14.10.3. Produtor – Consumidor ...................................................................................................................... 222

14.11. VANTAGENS DA REDE H1 SOBRE PROFIBUS-PA ................................................................................................ 224 14.12. PERFORMANCE ................................................................................................................................................. 225 14.13. INTEGRAÇÃO COM REDE HSE ............................................................................................................................... 226

14.13.1. Exemplo – DFI 302 – Subsistema de I / O Fieldbus ........................................................................ 228 14.14. DEVICE DESCRIPTOR (DD) ................................................................................................................................ 229

15. ETHERNET ..................................................................................................................................... 231 15.1. INTRODUÇÃO .................................................................................................................................................... 231

15.1.1. Desenvolvimento da Rede Fieldbus HSE (High Speed Ethernet) ....................................................... 232 15.1.2. Ethernet / IP .......................................................................................................................................... 233 15.1.3. ProfiNet .................................................................................................................................................. 234 15.1.4. IEEE 1451 .............................................................................................................................................. 235 15.1.5. Modbus / TCP ........................................................................................................................................ 236

15.2. PRINCÍPIOS BÁSICOS ......................................................................................................................................... 237



15.2.1. Preâmbulo .............................................................................................................................................. 238 15.2.2. Endereço de destino ............................................................................................................................. 238 15.2.3. Endereço de origem .................................................................................................................................. 238

15.3. NÍVEIS FÍSICOS .................................................................................................................................................. 239 15.3.1. 10 BASE 5 .............................................................................................................................................. 239 15.3.2. 10 BASE 2 .............................................................................................................................................. 240 15.3.3. 10 BASE – T .......................................................................................................................................... 240 15.3.4. 10 BASE – F .......................................................................................................................................... 240

15.4. MELHORAMENTOS DA REDE ETHERNET ................................................................................................................ 241 15.5. EVOLUÇÃO ....................................................................................................................................................... 243 15.6. EVOLUÇÃO DO QUADRO ETHERNET ..................................................................................................................... 245 15.7. ARQUITETURA EM ANEL X BARRAMENTO ............................................................................................................... 248 15.8. ARQUITETURAS DE ROTEAMENTO ......................................................................................................................... 248 15.9. QUALITY OF SERVICE (QOS) ............................................................................................................................... 250

15.9.1. Prioritização Implícita ............................................................................................................................ 251 15.9.2. Prioritização Explícita ............................................................................................................................ 251 15.9.3. Vídeo sobre IP ....................................................................................................................................... 253

15.10. PERFORMANCE DE REDES ETHERNET .................................................................................................................... 254 15.11. CÁLCULO DO TEMPO DE LATÊNCIA ....................................................................................................................... 257 15.12. CÁLCULO DO TEMPO DE SCAN .............................................................................................................................. 257

16. ENDEREÇAMENTO IP ................................................................................................................... 264 16.1. REDES CLASSE A .............................................................................................................................................. 266 16.2. REDES CLASSE B .............................................................................................................................................. 267 16.3. REDES CLASSE C .............................................................................................................................................. 267 16.4. ENDEREÇOS ESPECIAIS ...................................................................................................................................... 268

16.4.1. Endereço do Computador ..................................................................................................................... 268 16.4.2. Endereço de Loopback ......................................................................................................................... 268 16.4.3. Endereço da Rede ................................................................................................................................. 268 16.4.4. Endereço de Broadcast ........................................................................................................................ 268

16.5. NOTAÇÃO DECIMAL COM PONTO .......................................................................................................................... 268 16.6. PROJETO DE SUBREDES ..................................................................................................................................... 271 16.7. ROTEAMENTO ................................................................................................................................................... 272 16.8. VARIABLE LENGTH SUBNET MASKS (VLSM) ....................................................................................................... 275 16.9. MELHOR APROVEITAMENTO DO ESPAÇO DE ENDEREÇAMENTO ................................................................................. 275 16.10. AGREGAÇÃO DE ROTAS ....................................................................................................................................... 276 16.11. DHCP – DYNAMIC HOST CONFIGURATION PROTOCOL ............................................................................................ 277

17. PRINC IP IOS DA COMUNICAÇÃO TCP- IP ...................................................................................... 280 17.1. TCP/IP ("TRANSMISSION CONTROL PROTOCOL / INTERNET PROTOCOL") .................................................................. 280 17.2. CAMADA IP ...................................................................................................................................................... 280 17.3. CAMADA TCP ................................................................................................................................................... 281 17.4. SERVIÇOS E UTILITÁRIOS DE ALTO NÍVEL .............................................................................................................. 283 17.5. APLICAÇÕES ..................................................................................................................................................... 283

17.5.1. DNS (Domain Name Service) ................................................................................................................ 283 17.5.2. TELNET ................................................................................................................................................... 284 17.5.3. Rlogin ..................................................................................................................................................... 285 17.5.4. RSH ......................................................................................................................................................... 285 17.5.5. FTP - File Transfer Protocol .................................................................................................................. 285 17.5.6. TFTP - Trivial File Transfer Protocol ..................................................................................................... 287 17.5.7. NFS - Network File System .................................................................................................................... 288



17.5.8. SMTP - Simple Mail Transport Protocol .............................................................................................. 288 17.6. PROGRAMANDO O SEU PRÓPRIO CLIENTE OU SERVIDOR .......................................................................................... 289

17.6.1. Performance .......................................................................................................................................... 290 17.6.2. Sockets ................................................................................................................................................... 290

17.7. PRINCÍPIO DE FUNCIONAMENTO ........................................................................................................................... 296 17.7.1. Porta ....................................................................................................................................................... 296 17.7.2. Visualizando os Portas Livres .............................................................................................................. 297 17.7.3. Mecanismo Cliente-Servidor Básico ..................................................................................................... 297 17.7.4. Aplicação Típica Sobre TCP no WNT: .................................................................................................... 298 17.7.5. Aplicação Típica Sobre UDP no WNT: ................................................................................................... 299

18. COMUNICAÇÃO OPC (AUTOMAÇÃO INDUSTRIAL) ...................................................................... 302 18.1. INTRODUÇÃO .................................................................................................................................................... 302

18.1.1. Plataforma Windows em Plantas Industriais ........................................................................................ 303 18.1.2. OPC: Surgimento e Evolução ................................................................................................................ 303 18.1.3. Objetivo e Estrutura .............................................................................................................................. 304

18.2. FUNDAMENTOS DO OPC ..................................................................................................................................... 305 18.2.1. A Tecnologia que Compõe o OPC ......................................................................................................... 305

18.2.1.1. Programação Orientada a Objetos ................................................................................................................................. 305 18.2.1.2. RPC e DCE ....................................................................................................................................................................... 306 18.2.1.3. DCOM ............................................................................................................................................................................... 307

18.2.2. O OPC ..................................................................................................................................................... 308 18.2.2.1. Arquitetura Básica .......................................................................................................................................................... 308 18.2.2.2. Principais Especificações ................................................................................................................................................ 309

18.2.2.2.1. OPC Data Access Specification (DA) .......................................................................................................................... 311 18.2.2.2.2. OPC Alarms and Events Specification (AE) ................................................................................................................ 314 18.2.2.2.3. OPC Historical Data Access (HDA) ........................................................................................................................ 318 18.2.2.2.4. OPC Unified Architecture (OPC-UA) ...................................................................................................................... 321

18.2.2.3. Outras Especificações ..................................................................................................................................................... 326 18.2.2.3.1. OPC XML-DA ............................................................................................................................................................... 326 18.2.2.3.2. OPC Compliance Test .................................................................................................................................................. 327 18.2.2.3.3. OPC Complex Data ...................................................................................................................................................... 328 18.2.2.3.4. OPC Data Exchange (DX) ........................................................................................................................................... 329 18.2.2.3.5. OPC Common Definitions and Interfaces .................................................................................................................... 330 18.2.2.3.6. OPC Security ............................................................................................................................................................... 330 18.2.2.3.7. OPC Batch ................................................................................................................................................................... 331

18.3. APLICAÇÕES E CARACTERÍSTICAS DO OPC ............................................................................................................. 333 18.3.1. Principais Conceitos .............................................................................................................................. 334

18.3.1.1. Aplicações em Tempo Real e Características de Desempenho ...................................................................................... 334 18.3.1.2. Otimização, Controle Avançado e Interoperabilidade de Redes Heterogêneas ............................................................ 335 18.3.1.3. Confiabilidade e Disponibilidade no OPC ........................................................................................................................ 335

19. WIRELESS ...................................................................................................................................... 338 19.1. INTRODUÇÃO .................................................................................................................................................... 338 19.2. PRINCÍPIO DE FUNCIONAMENTO ........................................................................................................................... 338 19.3. PADRÕES ......................................................................................................................................................... 338 19.4. CARACTERÍSTICAS DOS PADRÕES .......................................................................................................................... 339 19.5. O USO DA WIRELESS .......................................................................................................................................... 340 19.6. TECNOLOGIAS WIRELESS .................................................................................................................................... 341

19.6.1. IEEE 802.11b Wi-Fi ............................................................................................................................... 341 19.6.2. IEEE 802.15.1 Bluetooth ...................................................................................................................... 341 19.6.3. IEEE 802.15.4 ZigBee .......................................................................................................................... 341 19.6.4. Padrão Hart Wireless ............................................................................................................................. 342

19.7. COMPARATIVO ENTRE TECNOLOGIAS ...................................................................................................................... 342



20. S ISTEMAS GERÊNCIA DE INFORMAÇÃO INDUSTRIAL ............................................................... 345 20.1. MES (MANUFACTURING EXECUTION SYSTEM) ......................................................................................................... 345

20.1.1. O Conceito Básico .................................................................................................................................. 348 20.1.2. Aplicabilidade ......................................................................................................................................... 349

20.2. PIMS (PLANT INFORMATION MANAGEMENT SYSTEM) ............................................................................................ 351 21. DETECÇÃO DE ERROS .................................................................................................................. 354

21.1. TÉCNICAS PRIMITIVAS DE DETECÇÃO .................................................................................................................... 354 21.1.1. Paridade Simples ou Paridade Vertical ou TRC ................................................................................... 354 21.1.2. Paridade Horizontal ou LRC (Longitudinal Redundancy Check) ........................................................ 356

21.2. CÓDIGOS CÍCLICOS DE DETECÇÃO DE ERROS .......................................................................................................... 357 21.2.1. CRC – Cyclic Redundancy Code ............................................................................................................ 357

21.3. CÁLCULO DO CRC .............................................................................................................................................. 364 21.3.1. Cálculo do CRC Através de Hardware .................................................................................................. 365

21.4. CÁLCULO DO CRC BITWISE ................................................................................................................................. 373 21.5. CÁLCULO DO CRC BYTEWISE ............................................................................................................................... 376 21.6. CRC-32 .......................................................................................................................................................... 385 21.7. REVERTENDO O CRC ......................................................................................................................................... 386

22. CLASSIF ICAÇÃO ÁREAS ................................................................................................................ 391 22.1. INTRODUÇÃO .................................................................................................................................................... 391 22.2. CLASSIFICAÇÃO DE ÁREAS ................................................................................................................................... 391

22.2.1. Zonas .................................................................................................................................................... 392 22.2.2. Tipos de Proteção ................................................................................................................................ 392 22.2.3. Grupos ................................................................................................................................................... 393

22.3. CLASSIFICAÇÃO DE TEMPERATURAS ....................................................................................................................... 394 22.4. DESCRIÇÃO DOS TIPOS DE PROTEÇÃO ................................................................................................................... 395

22.2.3. À Prova de Explosão Ex d (Explosion Proof ou Flame Proof) .......................................................... 395 22.2.4. Segurança Aumentada Ex e (NBR 9883/87 e IEC 79-7) .................................................................. 396 22.2.5. Equipamento Elétrico Imerso em Óleo Ex o (NBR 8601 e IEC 60079-6) ....................................... 396 22.2.6. Equipamentos Pressurizados Ex p ...................................................................................................... 396 22.2.7. Equipamentos Imersos em Areia Ex q ................................................................................................ 397 22.2.8. Equipamento Elétrico Encapsulado Ex m ........................................................................................... 397 22.2.9. Equipamento de Segurança Intrínseca Ex i ........................................................................................ 397 22.2.10. Equipamento Elétrico não Acendível Ex n ........................................................................................ 398 22.2.11. Equipamento com Proteção Especial ............................................................................................... 398



LISTA DE F IGURAS FIGURA 1: TIPOS DE COMUNICAÇÃO ............................................................................................................................................................. 21 FIGURA 2: TOPOLOGIA TOTALMENTE LIGADA ................................................................................................................................................. 22 FIGURA 3: TOPOLOGIA EM ANEL .................................................................................................................................................................. 22 FIGURA 4: TOPOLOGIA PARCIALMENTE LIGADA .............................................................................................................................................. 23 FIGURA 5: TOPOLOGIA EM ESTRELA ............................................................................................................................................................. 24 FIGURA 6: TOPOLOGIA EM ANEL "FECHADO” ................................................................................................................................................. 26 FIGURA 7: TOPOLOGIA EM BARRA ................................................................................................................................................................ 27 FIGURA 8: CURVA GANHO X FREQUÊNCIA ...................................................................................................................................................... 29 FIGURA 9: BANDA DE FREQUÊNCIA .............................................................................................................................................................. 30 FIGURA 10: MULTIPLEXAÇÃO DA FREQÜÊNCIA ............................................................................................................................................... 30 FIGURA 11: MODULAÇÃO DE SINAL ............................................................................................................................................................. 31 FIGURA 12: MODELO OSI .......................................................................................................................................................................... 36 FIGURA 13: COMUNICAÇÃO ENTRE PCS ........................................................................................................................................................ 44 FIGURA 14: ESPECIFICAÇÕES DE NÍVEL LÓGICO ............................................................................................................................................. 46 FIGURA 15: PINAGEM DB25 ..................................................................................................................................................................... 48 FIGURA 16: PINAGEM DB9 ........................................................................................................................................................................ 49 FIGURE 17: BITS RS-232 ........................................................................................................................................................................ 50 FIGURE 18: COMUNICAÇÃO DE DADOS .......................................................................................................................................................... 51 FIGURA 20: COMUNICAÇÃO VIA MODEM ...................................................................................................................................................... 54 FIGURA 21: COMUNICAÇÃO HALF DUPLEX ..................................................................................................................................................... 57 FIGURA 22: CAPACITÂNCIA DO CABO ............................................................................................................................................................ 59 FIGURA 23: DRIVER EIA-RS-485 .............................................................................................................................................................. 67 FIGURA 24: GRÁFICO DE DISTÂNCIAS PARA EIA-RS-485 ............................................................................................................................... 68 FIGURA 25: TENSÃO ENTRE DRIVERS ........................................................................................................................................................... 69 FIGURA 26: REFERÊNCIA LOCAL SEM RUÍDO ................................................................................................................................................. 71 FIGURA 27: REFERÊNCIA LOCAL COM POSSÍVEL RUÍDO ................................................................................................................................... 71 FIGURA 28: REFERÊNCIA TERRA COM PROTEÇÃO A RUÍDO ............................................................................................................................... 72 FIGURE 29: CABO BLINDADO RS-485 ......................................................................................................................................................... 73 FIGURA 30: TIPOS DE TOPOLOGIAS ............................................................................................................................................................. 74 FIGURA 31: TERMINAÇÕES ......................................................................................................................................................................... 76 FIGURE 32: COMPARATIVO ENTRE LIGAÇÕES FÍSICAS ...................................................................................................................................... 78 FIGURA 33: DIVERSIDADE DE TECNOLOGIA EM INTEGRAÇÃO INDUSTRIAL ............................................................................................................ 82 FIGURE 34: CAMADAS DE UM SISTEMA DE AUTOMAÇÃO ................................................................................................................................... 82 FIGURE 35: CAMADAS REDES INDUSTRIAIS .................................................................................................................................................... 85 FIGURA 36: CARACTERÍSTICAS DA REDE AS-I ................................................................................................................................................ 87 FIGURA 37: FAIXA DE APLICAÇÃO ................................................................................................................................................................ 88 FIGURA 38: MANEIRAS DE CONECTAR A REDE AS-I ........................................................................................................................................ 89 FIGURA 39: ENVIO DE VALORES ANALÓGICOS ............................................................................................................................................... 90 FIGURA 40: TRANSMISSÃO DE VALOR ANALÓGICO .......................................................................................................................................... 91 FIGURA 41: MODULAÇÃO DE SINAL DA REDE AS-I ......................................................................................................................................... 92 FIGURA 42: FORMATO DA MENSAGEM AS-I .................................................................................................................................................. 93 FIGURA 43: TIPOS DE MENSAGENS .............................................................................................................................................................. 94 FIGURA 44: CONFIGURAÇÃO DE I/O ............................................................................................................................................................. 95 FIGURA 45: SIGNIFICADO DOS BITS ............................................................................................................................................................. 96 FIGURA 46: EXEMPLO DE CONECTOR ........................................................................................................................................................... 96 FIGURA 47: CAIXAS DE INTERLIGAÇÃO .......................................................................................................................................................... 96 FIGURA 48: TIPOS DE CONEXÕES ................................................................................................................................................................ 97 FIGURA 49: TIPOS DE SAÍDAS ..................................................................................................................................................................... 98 FIGURA 50: CABO DE INTERLIGAÇÃO ............................................................................................................................................................ 98 FIGURA 51: TOPOLOGIAS PARA LIVRE ESCOLHA ............................................................................................................................................. 99 FIGURA 52: FONTE AS-I ......................................................................................................................................................................... 100 FIGURA 53: COMPRIMENTO DO CABO PARA REDE AS-I ................................................................................................................................ 100 FIGURA 54: ECONOMIA COM O USO DE UMA REDE AS-I ............................................................................................................................... 101



FIGURA 55: SINAL HART SOBREPOSTO ..................................................................................................................................................... 104 FIGURA 56: CONEXÃO COM INSTRUMENTO HART ....................................................................................................................................... 105 FIGURA 57: CONEXÃO COM A SAÍDA .......................................................................................................................................................... 106 FIGURA 58: HART COM 2 MESTRES ......................................................................................................................................................... 106 FIGURA 59: CONFIGURADORES HART ....................................................................................................................................................... 106 FIGURA 60: CALIBRADORES HART ........................................................................................................................................................... 107 FIGURA 61: CONFIGURAÇÃO MESTRE ESCRAVO ........................................................................................................................................... 107 FIGURA 62: INSTRUMENTO EM MODO DE COMUNICAÇÃO .............................................................................................................................. 108 FIGURA 63: HART EM MULTIDROP .......................................................................................................................................................... 108 FIGURA 64: EXEMPLO DE MULTIPLEXADORES ............................................................................................................................................ 111 FIGURA 65: LIGAÇÃO CONVENCIONAL COM MULTIPLEXADOR ......................................................................................................................... 111 FIGURA 66: LIGAÇÃO EM SERIE ................................................................................................................................................................ 112 FIGURA 67: FAIXA DE APLICAÇÃO ............................................................................................................................................................. 114 FIGURA 68: DEVICENET E CAN - CAMADAS ................................................................................................................................................ 115 FIGURA 69: APLICAÇÕES DEVICENET ........................................................................................................................................................ 115 FIGURA 70: CAIXA DE CONEXÃO ABERTA E SELADA ..................................................................................................................................... 116 FIGURE 71: TOPOLOGIA DEVICENET ......................................................................................................................................................... 117 FIGURA 72: CÁLCULO DA DERIVAÇÃO CUMULATIVA ...................................................................................................................................... 118 FIGURA 73: CÁLCULO DAS DISTÂNCIAS MÁXIMAS DOS CABOS ........................................................................................................................ 118 FIGURE 74: FUNÇÃO / CORES DO CABO DEVICENET .................................................................................................................................... 119 FIGURE 75: TIPOS DE CABOS DEVICENET .................................................................................................................................................. 120 FIGURE 76: TIPOS DE CABOS DEVICENET 1 .............................................................................................................................................. 121 FIGURA 77: CÁLCULO DE QUEDA DE TENSÃO ............................................................................................................................................. 121 FIGURA 78: POSICIONAMENTO DA FONTE DE ALIMENTAÇÃO .......................................................................................................................... 123 FIGURA 79: TELA DO DEVICENET ASSISTANT ............................................................................................................................................. 124 FIGURA 80: QUADRO DE DADOS CAN ....................................................................................................................................................... 125 FIGURA 81: PROCESSO DE ARBITRAGEM .................................................................................................................................................... 125 FIGURA 82: MESTRE / ESCRAVO .............................................................................................................................................................. 126 FIGURA 83: PEER TO PEER ..................................................................................................................................................................... 127 FIGURA 84: MULTI – MESTRE ................................................................................................................................................................. 127 FIGURA 85: MUDANÇA DO ESTADO DO LADO .............................................................................................................................................. 128 FIGURA 86: PRODUÇÃO CÍCLICA DE DADOS ................................................................................................................................................ 129 FIGURA 87: IDENTIFICADOR ..................................................................................................................................................................... 130 FIGURA 88: QUADRO DE DADOS: FRAGMENTADA X NÃO FRAGMENTADA .......................................................................................................... 130 FIGURA 89: GRUPO DE MENSAGENS DEVICENET ......................................................................................................................................... 131 FIGURA 90: MENSAGENS PREDEFINIDAS MESTRE / ESCRAVO ........................................................................................................................ 132 FIGURA 91: INSTÂNCIA DE OBJETO IDENTIDADE .......................................................................................................................................... 134 FIGURA 92: MODELO DE OBJETOS DEVICENET ........................................................................................................................................... 135 FIGURA 93: APLICAÇÃO DO PROTOCOLO MODBUS ....................................................................................................................................... 139 FIGURE 94: ARQUITETURA MODBUS ......................................................................................................................................................... 141 FIGURA 95: CICLO DE COMUNICAÇÃO ENTRE MESTRE E ESCRAVO .................................................................................................................. 142 FIGURA 96: EXEMPLO DE REQUISIÇÃO DE DADOS ....................................................................................................................................... 143 FIGURA 97: EXEMPLO DE RESPOSTA DE DADOS ......................................................................................................................................... 143 FIGURA 98: EXEMPLO DE FRAME MODBUS ................................................................................................................................................ 146 FIGURA 99: FRAME DE MENSAGEM ASCII .................................................................................................................................................. 147 FIGURA 100: DIAGRAMA DE ATIVIDADE DE LINHA PARA SEQÜÊNCIA TÍPICA MODBUS ......................................................................................... 148 FIGURA 101: FRAME DE MENSAGEM RTU ................................................................................................................................................. 148 FIGURE 102: FUNÇÕES BÁSICAS MODBUS ................................................................................................................................................ 151 FIGURA 103: SEQUÊNCIA DE BITS EM MODO ASCII .................................................................................................................................... 153 FIGURA 104: SEQUÊNCIA DE BITS EM MODO RTU ...................................................................................................................................... 153 FIGURA 105: DIAGRAMA DE ESTADO DA VERIFICAÇÃO CRC .......................................................................................................................... 157 FIGURE 106: TOPOLOGIA TÍPICA DE REDES PROFIBUS ................................................................................................................................ 159 FIGURA 107: APLICAÇÃO DA REDE PROFIBUS ............................................................................................................................................ 160 FIGURA 108: FAIXA DE APLICAÇÃO ........................................................................................................................................................... 161 FIGURA 109: ARQUITETURA DOS PROTOCOLOS PROFIBUS ............................................................................................................................ 162



FIGURA 110: TOPOLOGIA DA REDE PROFIBUS PA ...................................................................................................................................... 163 FIGURE 111: DADOS PADRÃO PROFIBUS PA ............................................................................................................................................. 164 FIGURA 112: NÍVEL DE SINAL NA REDE PROFIBUS – PA ............................................................................................................................. 166 FIGURE 113: TIPOS DE RUÍDOS NO SINAL PROFIBUS ................................................................................................................................... 167 FIGURA 114: ALIMENTAÇÃO DE INSTRUMENTOS DE CAMPO .......................................................................................................................... 168 FIGURA 115: TOPOLOGIA DA REDE PROFIBUS ............................................................................................................................................ 168 FIGURE 116: COMPARATIVO ENTRE CABOS PROFIBUS ................................................................................................................................. 170 FIGURE 117: CARACTERÍSTICA DO CABO A (ROXO) PROFIBUS PA ................................................................................................................. 170 FIGURA 118: BLOCOS DE FUNÇÃO ........................................................................................................................................................... 171 FIGURE 119: ESTRUTURA DOS BLOCOS DE FUNÇÃO .................................................................................................................................... 171 FIGURA 120: EXEMPLOS DE PARÂMETROS DO BLOCO DE FUNÇÃO ................................................................................................................. 172 FIGURA 121: PARÂMETROS DE UM INSTRUMENTO NO PROFILE PA ................................................................................................................ 172 FIGURE 122: TIPOS DE PROFIBUS DP ...................................................................................................................................................... 174 FIGURE 123: SINAL PROFIBUS DP .......................................................................................................................................................... 175 FIGURA 124: CONECTORES PROFIBUS-DP ................................................................................................................................................ 176 FIGURE 125: COMPARATIVO ENTRE CABOS PROFIBUS ................................................................................................................................. 176 FIGURA 127: PERFORMANCE DA REDE PROFIBUS DP ................................................................................................................................. 177 FIGURE 128: EXEMPLO DE LIGAÇÃO PROFIBUS DP ..................................................................................................................................... 178 FIGURA 129: TOPOLOGIAS PARA REDE PROFIBUS ...................................................................................................................................... 178 FIGURA 130: REDE PROFIBUS EM ANEL FIBRA ÓTICA .................................................................................................................................. 179 FIGURE 131: TIPOS DE FIBRAS ÓTICAS ..................................................................................................................................................... 180 FIGURA 132: COMUNICAÇÃO TOKEN RING E POR POLLING ............................................................................................................................ 181 FIGURA 133: ACOPLADOR DP/PA ........................................................................................................................................................... 182 FIGURA 134: DP/PA LINK ..................................................................................................................................................................... 182 FIGURA 135: SISTEMA MONO MESTRE ..................................................................................................................................................... 183 FIGURE 136: ARQUITETURA MULTI-MESTRE .............................................................................................................................................. 184 FIGURA 137: COMPARAÇÃO PROFIBUS-PA X 4...20MA .............................................................................................................................. 187 FIGURA 138: EXEMPLO DE PAINÉIS COM E SEM REDE PROFIBUS .................................................................................................................. 188 FIGURA 139: PROFIBUS E ETHERNET TCP/IP ........................................................................................................................................... 191 FIGURA 140: REDES FIELDBUS H1 E HSE ............................................................................................................................................... 193 FIGURA 141: FAIXA DE APLICAÇÃO ........................................................................................................................................................... 195 FIGURE 142: ARQUITETURA H1 .............................................................................................................................................................. 195 FIGURA 143: CONEXÕES AO PROCESSO .................................................................................................................................................... 196 FIGURA 144: FUNÇÃO DE CONTROLE NA INSTRUMENTAÇÃO .......................................................................................................................... 197 FIGURA 145: BARREIRAS DE SEGURANÇA .................................................................................................................................................. 198 FIGURA 146: FIELDBUS H1 E MODELO OSI .............................................................................................................................................. 198 FIGURA 147: FORMAÇÃO DO QUADRO DE MENSAGEM ................................................................................................................................. 199 FIGURA 148: REPRESENTAÇÃO POR BLOCOS ............................................................................................................................................. 200 FIGURA 149: TIPOS DE BLOCOS .............................................................................................................................................................. 200 FIGURA 150: MALHA DE CONTROLE ENTRE DOIS INSTRUMENTOS .................................................................................................................. 202 FIGURA 151: BLOCO DE FUNÇÃO FLEXÍVEL ............................................................................................................................................... 203 FIGURA 152: BLOCO AI E SUA IMPLEMENTAÇÃO ......................................................................................................................................... 204 FIGURA 153: BLOCO AI E SIMULAÇÃO DE VALORES DE ENTRADA .................................................................................................................. 204 FIGURA 154: SUMARIO DOS BLOCOS DE CONTROLE .................................................................................................................................... 205 FIGURA 155: EXEMPLO DE CONFIGURAÇÃO DE MALHAS DE CONTROLE ........................................................................................................... 205 FIGURA 156: CODIFICAÇÃO MANCHESTER BIFASE-L .................................................................................................................................... 206 FIGURA 157: CARACTERES ESPECIAIS DE INICIO E FINAL DE QUADRO ............................................................................................................. 207 FIGURA 158: SINAL FIELDBUS ................................................................................................................................................................ 208 FIGURA 159: TOPOLOGIAS DA REDE FIELDBUS .......................................................................................................................................... 209 FIGURA 160: TERMINADOR E CABO DA REDE FF-H1 .................................................................................................................................. 210 FIGURA 161: CONFIGURAÇÃO BÁSICA DE UMA REDE FF-H1 ......................................................................................................................... 211 FIGURA 162: LIGAÇÃO NA CAIXA DE JUNÇÃO .............................................................................................................................................. 212 FIGURE 163: CAIXA DE JUNÇÃO FF ........................................................................................................................................................... 212 FIGURA 164: ELEMENTOS DE REDE FF (CONECTORES) ............................................................................................................................... 213 FIGURA 165: MACRO CICLO E ESCALONAMENTO DO BARRAMENTO ................................................................................................................. 213



FIGURA 166: DISPOSITIVO DE CAMPO VIRTUAL E SEUS DICIONÁRIOS DE OBJETOS ............................................................................................ 217 FIGURA 167: CICLO DE ATIVIDADE DO LAS ............................................................................................................................................... 218 FIGURA 168: MECANISMO CLIENTE - SERVIDOR ......................................................................................................................................... 220 FIGURA 169: DISTRIBUIÇÃO DO RELATÓRIO ............................................................................................................................................... 222 FIGURA 170: MECANISMO PRODUTOR - CONSUMIDOR ................................................................................................................................. 223 FIGURA 171: SUMARIO DE SERVIÇOS DA FAZ ............................................................................................................................................ 223 FIGURA 172: SUMARIO DE TIPOS DE COMUNICAÇÃO FF ............................................................................................................................... 224 FIGURA 173: TEMPOS DE PERFORMANCE TÍPICOS ...................................................................................................................................... 225 FIGURE 174: INTERLIGAÇÃO ENTRE REDES HSE E H1 ................................................................................................................................ 226 FIGURA 175: LINKING DEVICE HSE COM I/O LOCAL E COM INTERFACE MODBUS .............................................................................................. 227 FIGURA 176: BLOCO DE I/O SMAR DC 302 ............................................................................................................................................. 227 FIGURA 177: GATEWAY HART-FIELDBUS ................................................................................................................................................... 228 FIGURA 178: ESBOÇO ORIGINAL DA REDE ETHERNET FEITO POR METCALFE EM UM GUARDANAPO EM 1976 ....................................................... 231 FIGURA 179: FAIXA DE APLICAÇÃO ........................................................................................................................................................... 232 FIGURA 180: REDE HSE E REDE H1 ....................................................................................................................................................... 233 FIGURA 181: PROFIBUS E ETHERNET TCP/IP ........................................................................................................................................... 235 FIGURA 182: SENSOR INTERFACE IEEE 1451 .......................................................................................................................................... 235 FIGURA 183: INTRUMENTOS SERIAIS INTERLIGADOS VIA TCP/IP ................................................................................................................... 237 FIGURA 184: QUADRO ETHERNET ............................................................................................................................................................ 238 FIGURA 185: QUADRO IEEE 802.3 ........................................................................................................................................................ 238 FIGURA 186: DEGRADAÇÃO DA PERFORMANCE DE REDES CSMA COM AUMENTO DA CARGA ............................................................................... 242 FIGURA 187: LIMITAÇÕES DA REDE ETHERNET ........................................................................................................................................... 243 FIGURA 188: LAN`S ............................................................................................................................................................................. 244 FIGURA 189: EVOLUÇÃO DE ARQUITETURA ETHERNET ................................................................................................................................. 244 FIGURA 190: QUADRO ETHERNET SIMPLES E COM TAG MOSTRANDO PRIORIDADE ........................................................................................... 246 FIGURA 191: QUADRO ETHERNET SIMPLES E COM QUADRO IP, MOSTRANDO CAMPO TOS ................................................................................. 247 FIGURA 192: QUADRO ETHERNET COM QUADRO IP DE UDP / TCP .............................................................................................................. 247 FIGURA 193: ARQUITETURA EM ANEL E BARRAMENTO ................................................................................................................................. 248 FIGURA 194: REDE ETHERNET CONVENCIONAL .......................................................................................................................................... 249 FIGURA 195: REDE ETHERNET COM QOS IMPLICITO NO PROJETO .................................................................................................................. 249 FIGURA 196: REDE ETHERNET COM QOS EXPLICITO ................................................................................................................................... 250 FIGURA 197: QUADRO ETHERNET SIMPLES E COM QUADRO IP, MOSTRANDO CAMPO TOS ................................................................................. 252 FIGURA 198: VÍDEO SOBRE IP ................................................................................................................................................................ 254 FIGURA 199: PERFORMANCE COMPARATIVA DE REDES ETHERNET ................................................................................................................ 254 FIGURA 200: VELOCIDADE DE LINKS ........................................................................................................................................................ 256 FIGURA 201: MENSAGEM DE BROADCAST ................................................................................................................................................. 257 FIGURA 202: VELOCIDADE DE TX ............................................................................................................................................................. 257 FIGURA 203: TRAFEGO DE SCAN .............................................................................................................................................................. 258 FIGURA 204: TEMPO DE TRANSMISSÃO .................................................................................................................................................... 259 FIGURA 205: CÁLCULO DE VARIÂNCIA ....................................................................................................................................................... 260 FIGURA 206: CÁLCULO DO SCAN .............................................................................................................................................................. 260 FIGURA 207: TEMPO DE TRANSMISSÃO .................................................................................................................................................... 261 FIGURA 208: VARIÂNCIA DE RECEPÇÃO ..................................................................................................................................................... 261 FIGURA 209: TEMPO DE SCAN ................................................................................................................................................................ 262 FIGURA 210: "INTERNET ABRI UM NOVO MUNDO DE POSSIBILIDADES... ......................................................................................................... 264 FIGURA 211: TIPOS DE CLASSES ............................................................................................................................................................. 265 FIGURA 212: ENDEREÇOS ESPECIAIS ........................................................................................................................................................ 266 FIGURA 213: REDES /16 ....................................................................................................................................................................... 267 FIGURA 214: DIVISÃO DO ESPAÇO DE ENDEREÇAMENTO IPV4 PARA ENDEREÇOS CLASSFULL ............................................................................. 267 FIGURA 215: NOTAÇÃO DECIMAL ............................................................................................................................................................. 269 FIGURA 216: ENDEREÇAMENTO DA REDE E TABELA DE ROTEAMENTO ............................................................................................................ 270 FIGURA 217: NESTAT ............................................................................................................................................................................ 273 FIGURA 218: FORMATO ......................................................................................................................................................................... 273 FIGURA 219: ROTEAMENTO DE MENSAGENS ATRAVÉS DE UM GATEWAY .......................................................................................................... 274 FIGURA 220: DIVISÃO RECURSIVA DE UM PREFIXO DE REDE ......................................................................................................................... 276



FIGURA 221: AGREGAÇÃO DE ENDEREÇO .................................................................................................................................................. 277 FIGURA 222: STACK OSI/ISO X STACK TCP/IP ......................................................................................................................................... 280 FIGURA 223: DEPENDÊNCIA ENTRE PROTOCOLOS TCP/IP DE MAIS ALTO NÍVEL ............................................................................................. 281 FIGURA 224: ARQUITETURA DO PROTOCOLO TCP/IP SEGUNDO MICROSOFT .................................................................................................... 282 FIGURA 225: PACOTE UDP: HEADER DE 8 BYTES ..................................................................................................................................... 282 FIGURA 226: PACOTE TCP: HEADER DE 24 BYTES .................................................................................................................................... 283 FIGURA 227: TELNET ............................................................................................................................................................................ 285 FIGURA 228: FILE TRANSFER PROTOCOL (FTP) ........................................................................................................................................ 286 FIGURA 229: ARQUITETURA DE SOCKETS NO WINDOWS 2000 ...................................................................................................................... 292 FIGURA 230: DD FONTE DE DD BINÁRIO ................................................................................................................................................. 293 FIGURA 231: PORTAS E APLICAÇÕES ........................................................................................................................................................ 296 FIGURA 232: COMUNICAÇÃO FULL DUPLEX UTILIZANDO TCP ........................................................................................................................ 298 FIGURA 233: FLUXOGRAMA TCP NO WNT ................................................................................................................................................. 299 FIGURA 234: FLUXOGRAMA UDP NO WNT ................................................................................................................................................ 300 FIGURA 235: ARQUITETURA DO DCOM (MICROSOFT 1996) ....................................................................................................................... 307 FIGURA 236: ARQUITETURA BÁSICA DO OPC ............................................................................................................................................. 309 FIGURA 237: NAMESPACE E HIERARQUIA DE OBJETOS ................................................................................................................................. 313 FIGURA 238: ATRIBUTOS DE EVENTOS ..................................................................................................................................................... 316 FIGURA 239: SERVIDOR OPC AE E ÁREA DE EVENTOS ................................................................................................................................ 317 FIGURA 240: CLIENTE OPC-UA .............................................................................................................................................................. 322 FIGURA 241: SERVIDOR OPC-UA ............................................................................................................................................................ 323 FIGURA 242: INTERVENÇÃO ENTRE SERVIDORES OPC-UA ........................................................................................................................... 324 FIGURA 243: SERVIDORES OPC-UA ENTRE NÍVEIS HIERÁRQUICOS ................................................................................................................ 325 FIGURA 244: A PIRÂMIDE DA AUTOMAÇÃO ANTES E DEPOIS DOS SISTEMAS ERP E MES .................................................................................. 349 FIGURA 245: INTEGRAÇÃO PIMS E MES .................................................................................................................................................. 351 FIGURA 246: PARIDADE PAR E IMPAR ...................................................................................................................................................... 354 FIGURA 247: PARIDADE HORIZONTAL OU LRC ........................................................................................................................................... 357 FIGURA 248: CÁLCULO DO CRC PARA 110011 ........................................................................................................................................ 359 FIGURA 249: TRANSMISSÃO DA MENSAGEM ............................................................................................................................................... 360 FIGURA 250: CRC COM DIVISÃO POLINÔMIOS ............................................................................................................................................ 365 FIGURA 251: MENSAGEM 11001 – CRC = 1101 ................................................................................................................................... 368 FIGURA 252: CRC 12 ........................................................................................................................................................................... 369 FIGURA 253: CRC CCITT ....................................................................................................................................................................... 370 FIGURA 254: CRC 16 ........................................................................................................................................................................... 371 FIGURA 255: CRC 16 RECEPÇÃO ............................................................................................................................................................ 372 FIGURA 256: MENSAGEM ANTES DO CLOCK ............................................................................................................................................... 375 FIGURA 257: MENSAGEM APÓS O CLOCK .................................................................................................................................................. 375 FIGURA 258: MENSAGEM NO REGISTRADOR ............................................................................................................................................... 376 FIGURA 259: CRC BYTEWISE .................................................................................................................................................................. 377 FIGURA 260: CRC BYTEWISE .................................................................................................................................................................. 378 FIGURE 261: MENSAGEM ORIGINAL .......................................................................................................................................................... 386 FIGURA 262: MENSAGEM ALTERADA ........................................................................................................................................................ 387 FIGURE 263: CLASSIFICAÇÃO DAS ZONAS EX .............................................................................................................................................. 392 FIGURE 264: EXEMPLO DE ETIQUETA DE CLASSIFICAÇÃO ............................................................................................................................. 393 FIGURE 265: CLASSIFICAÇÃO DOS GRUPOS ................................................................................................................................................ 394 FIGURE 266: CLASSIFICAÇÃO DE TEMPERATURAS ........................................................................................................................................ 395



LISTA DE TABELAS TABELA 1: SINAIS DEFINIDOS PELA NORMA RS-232 ..................................................................................................................................... 47 TABELA 2: TABELA COMPARATIVA ENTRE RS-232 E RS-423 ........................................................................................................................ 61 TABELA 3: TABELA COMPARATIVA ENTRE RS-423 E RS-422 ........................................................................................................................ 64 TABELA 4: COMPARATIVO ENTRE EIA-RS-485 E EIA-RS-422 ...................................................................................................................... 78 TABELA 5: TABELA COMPARATIVA ENTRE RS-232, RS-423, RS-422 E RS-485 ............................................................................................ 79 TABELA 6: DISTÂNCIA MÁXIMA DE CABOS EM HART ................................................................................................................................... 109 TABELA 7: DISTÂNCIA MÁXIMA DO CABO X NÚMERO DE INSTRUMENTOS .......................................................................................................... 109 TABELA 8: COMANDOS UNIVERSAIS E ESPECÍFICOS ..................................................................................................................................... 110 TABELA 9: TRANSMISSÃO E COMPRIMENTO DE CABOS ................................................................................................................................. 117 TABELA 10: RESISTIVIDADE DE CABOS DEVICENET ..................................................................................................................................... 119 TABELA 11: COMPRIMENTO DO SEGMENTO DA REDE X CORRENTE MÁXIMA DE FONTE ÚNICA ............................................................................. 122 TABELA 12: ENDEREÇOS ........................................................................................................................................................................ 133 TABELA 13: CLASSE DE OBJETOS ............................................................................................................................................................ 133 TABELA 14: FONTES DE ALIMENTAÇÃO PADRÃO PARA TRANSMISSÃO ............................................................................................................. 169 TABELA 15: COMPRIMENTO MÁXIMO DO CABO PARA TRANSMISSÃO ............................................................................................................... 169 TABELA 16: TAXA DE TRANSMISSÃO E DISTÂNCIA ENTRE CABEAMENTOS. ........................................................................................................ 174 TABELA 17: TIPOS DE FIBRAS X DISTÂNCIAS .............................................................................................................................................. 179 TABELA 18: BLOCOS DE FUNÇÃO ............................................................................................................................................................. 201 TABELA 19: BLOCOS DE FUNÇÃO AVANÇADOS ........................................................................................................................................... 202 TABELA 20: BLOCOS DE FUNÇÃO AVANÇADOS 2 ........................................................................................................................................ 203 TABELA 21: COMPRIMENTO MÁXIMO DOS SPURS ........................................................................................................................................ 209 TABELA 22: TABELA COMPARATIVA REDE HSE X H1 .................................................................................................................................. 233 TABELA 23: CARACTERÍSTICAS BÁSICAS DAS REDES 802.3 ......................................................................................................................... 239 TABELA 24: TIPOS DE CABOS USADOS NAS PRINCIPAIS REDES ...................................................................................................................... 241 TABELA 25: NOVOS PADRÕES DO PADRÃO IEEE 802 ................................................................................................................................ 241 TABELA 26: CARACTERÍSTICAS DOS PADRÕES ............................................................................................................................................ 339 TABELA 27: PRINCIPAIS TECNOLOGIAS SEM FIO PARA AUTOMAÇÃO INDUSTRIAL .............................................................................................. 343 TABELA 26: TAMANHO DA RAJADA ........................................................................................................................................................... 363 TABELA 27: POLINÔMIOS MAIS UTILIZADOS ............................................................................................................................................... 363 TABELA 28: TABELA DE OPERANDOS PARA CÁLCULO DE CRC16 .................................................................................................................. 379 TABELA 29: TABELA DE OPERANDOS PARA CÁLCULO DE CRC CCITT ............................................................................................................. 381



1 . INTRODUÇÃO

1.1. A COMUNICAÇÃO

A comunicação é, sem dúvida, uma das grandes necessidades do ser humano desde o início de

sua existência. As civilizações ao redor do mundo ocuparam áreas geograficamente cada vez mais

distantes, desta forma a necessidade de uma comunicação que cobrisse longas distâncias era imperativa e

o seu estabelecimento um desafio efetivo. No passado, formas rudimentares de comunicação foram

utilizadas com a finalidade de encurtar as distâncias geográficas. Em 1838, Samuel F. B. Morse

estabeleceu uma nova etapa nas comunicações através de seu invento, o Telégrafo (código Morse – Um

gerador de pulsos elétricos manipulado por um operador transmitia as mensagens utilizando como meio de

transmissão fios elétricos sustentados por postes). A comunicação evoluiu desde então, surgiram o

telefone, o rádio, a televisão, e, mais recentemente, as redes de computadores (Ethernets, Intranets e

Internet). A utilização de satélites permitiu atingir cada ponto do planeta.

1.2. SISTEMAS COMPUTACIONAIS

Com o avanço das comunicações foram desenvolvidos diversos equipamentos para

armazenamento e processamento de informações, culminando com a chegada dos computadores em

1950.

Em 1960, terminais interligados a uma unidade central de processamento (time-sharing),

estabeleceram a união das tecnologias de armazenamento, processamento e comunicação. Na década de

70 surgiram os mini e micro computadores, facilitando o uso e acesso dos usuários aos sistemas de

computação. A necessidade de troca de informações e compartilhamento de programas, dados e

periféricos (unidades de armazenamento, impressoras, etc.) levou à interligação dos computadores em

rede.



1.3. ARQUITETURAS DE COMPUTADORES

Com o passar do tempo, viu-se a necessidade de melhorar a performance, o desempenho, a

modularidade e a confiabilidade dos sistemas computacionais, levando os pesquisadores a criar novas

arquiteturas baseadas na distribuição e paralelismo do processamento, em substituição ao modelo original

de Von Newmann, baseado na computação sequencial e utilizado nos projetos de computadores até a

década de 80.

Os sistemas de processadores múltiplos apresentam vantagens e desvantagens de acordo com a

aplicação e, geralmente são utilizados em sistemas com grandes exigências, tais como: alto grau de

modularidade, tarefas executadas de maneira concorrente, tempos de resposta baixos e garantidas, alta

disponibilidade do sistema, altos requisitos de vazão, etc.

1.4. SISTEMAS DISTRIBUÍDOS

De maneira geral, um sistema distribuído caracteriza-se por um sistema de comunicação

interligando diversos módulos de processamento, permitindo maior confiabilidade, desempenho e

compartilhamento de recursos. Alguns especialistas preferem atribuir a tarefa de compartilhamento de

recursos às Redes de Computadores, deixando aos Sistemas Distribuídos às funções de maior

confiabilidade e desempenho. Outros atribuem todas as funções aos Sistemas Distribuídos e os sub-

classificam em Máquinas de Arquitetura Distribuída e Redes de Computadores.

Uma Máquina de Arquitetura Distribuída pode ser vista como vários núcleos compostos por

processadores e/ou memórias, de número finito, porém ilimitado, os quais constituem entidades individuais

com capacidade de processamento concorrente, assíncrono e independente de qualquer tipo de hierarquia,

controlados por um único sistema operacional, o qual controla de forma integrada todos os recursos físicos

e lógicos, distribuindo seu núcleo e suas estruturas de dados entre as entidades individuais

(processadores e/ou memórias). Para o usuário a Máquina de Arquitetura Distribuída é apresentada como

um sistema único e real.



Uma Rede de Computadores é formada por um número finito, porém ilimitado, de módulos de

processamento com plena autonomia, assim como a Máquina de Arquitetura Distribuída, no entanto, as

tarefas de compartilhamento de recursos e troca de informações são independentes para cada modulo,

não havendo a necessidade de um único sistema operacional, mas sim a cooperação entre os diversos

sistemas para execução das tarefas citadas.



ANOTAÇÕES



2 . REDES DE COMPUTADORES

Uma rede de computadores baseia-se na interligação de módulos processadores com capacidade

de compartilhamento de recursos e troca de dados, realizados por um sistema de comunicação, o qual é

estabelecido por uma topologia (interligação dos módulos processadores através de enlaces físicos –

meios de transmissão) e um conjunto de regras (protocolos) com o intuito de criar a organização da

comunicação.

As Redes de Computadores onde os módulos de processamento encontram-se distantes entre si

de alguns poucos metros são chamadas de confinadas, as redes cujas distâncias encontram-se entre

alguns metros e poucos quilômetros são ditas redes locais (Local Área Networks – LANs), compreendendo

hoje, distâncias entre 1m e 25 Km. As Redes Locais operam hoje com velocidade de 10 ou 100Mbps.

Redes que cobrem áreas que ultrapassam os limites de cidades são ditas Redes Metropolitanas

(Metropolitan Area Networks – MANs) e, finalmente, as redes que cobrem distâncias maiores do que as

interurbanas são chamadas de Redes Geograficamente Distribuídas (Wide Area Networks – WANs),

utilizando em seus enlaces microondas e satélites.

A ligação dos computadores em rede permitiu assim uma maior eficiência dos sistemas

computacionais. As redes de computadores, hoje largamente utilizadas por empresas e universidades

(Ethernets e Intranets), além de usuários pessoais, estabeleceram uma forma de comunicação e

compartilhamento de informação que integraram o mundo (Internet), permitindo aos usuários fazer

consultas e pesquisas, reuniões de negócios, acesso a serviços corporativos e bancários, compra e venda

de produtos e serviços, etc.

2.1. TOPOLOGIAS DE REDES

A maneira de interligar os diversos módulos processadores de uma rede, através de enlaces

físicos, é o que chamamos de topologia da rede ou arranjo topológico. A definição da topologia está

diretamente ligada ao tipo da rede (LAN, MAN ou WAN) e sua escolha irá determinar o seu tipo, velocidade

e eficiência.



As ligações físicas podem ser Ponto a Ponto (somente dois pontos de comunicação para cada

enlace) e Multiponto (três ou mais dispositivos compartilham o mesmo enlace).

O tipo de comunicação do enlace pode ser:

• Simplex – O enlace é utilizado somente em um sentido.

• Half-Duplex – O enlace é utilizado nos dois sentidos, porém somente um sentido por vez.

• Full-Duplex – O enlace é utilizado nos dois sentidos, simultaneamente (não necessariamente no

mesmo fio ou par de fios).

F igura 1 : T ipos de Comunicação

2.1.1. Análise da Topologia Totalmente Ligada

Um exemplo de Topologia de Redes é a “Totalmente Ligada”, onde cada estação poderia ter um

enlace ponto a ponto com as demais, utilizando o tipo de comunicação Full-Duplex a fim de estabelecer

uma comunicação plena entre quaisquer pares de estações da rede. A troca de informação se dá de forma

direta através dos enlaces. Esta topologia se torna inviável quando se considera um grande número de

estações na rede, pois o custo de material e instalação de cabos e do Hardware de comunicação seria

muito alto.



F igura 2 : Topo log ia Tota lmente L igada

2.1.2. Análise da Topologia em Anel

A topologia em anel, apresentada abaixo, também se tornaria inviável, pois o número de ligações

(ponto a ponto) mínimo, com comunicação Simplex (único sentido de transmissão) estabelece uma

orientação única da transmissão. Isto faz com que a mensagem circule pelo anel até encontrar o seu

destino (estação). Considerando um grande número de estações é fácil verificar a existência de um retardo

de transmissão considerável ou até inaceitável, dependendo da velocidade de transmissão. Outro fator que

limita a utilização deste tipo de topologia é a ausência de caminhos alternativos para o tráfego de

mensagens.

F igura 3 : Topo log ia em Ane l



2.1.3. Análise da Topologia Parcialmente Ligada

A topologia parcialmente ligada, abaixo, é uma solução viável e utilizada na maioria das redes

geograficamente distribuídas. Nesta topologia caminhos alternativos estão disponíveis para o caso de

falhas e/ou congestionamentos. A fim de estabelecer a comunicação entre duas estações não

interligadas diretamente, a mensagem deverá ser encaminhada para uma estação conectada

(intermediária) que deverá se encarregar de sua entrega à estação destino.

F igura 4 : Topo log ia Parc ia lmente L igada

2.1.4. Troca de Mensagens

A comunicação entre duas estações da rede pode ser feita por chaveamento ou comutação de

circuitos, de pacotes ou de mensagens. No chaveamento de circuitos, similarmente a uma ligação

telefônica, é estabelecido um canal exclusivo entre a estação origem e a estação destino para o envio da

mensagem, este canal será utilizado até o fim do envio da mensagem, quando a conexão será então

desfeita.

Nos sistemas de chaveamento de mensagem, é estabelecida uma rota entre a fonte e o destino,

pela qual a mensagem é enviada, caso o caminho não seja direto (ponto a ponto), a mensagem será

armazenada em um nó intermediário (participante da rota) para, em seguida, ser enviada a um próximo nó

assim que o canal de transmissão que os une estiver disponível.



No chaveamento de pacotes a mensagem é “quebrada” em pacotes ou quadros, enviados

sucessivamente e reagrupados no destino.

Na comutação de mensagens e de pacotes não existe um canal específico para estabelecer a

comunicação. A função que determina o caminho que a mensagem ou pacote deve percorrer para o seu

envio da origem ao destino é chamada de Roteamento. A escolha de uma rota entre dois pontos pode ser

feita de forma prioritária ao envio da mensagem ou passo a passo, após cada trecho percorrido será

determinada à próxima rota – Roteamento adaptável. Existem vários algoritmos de roteamento, o

roteamento adaptável é mais eficaz, pois determina a rota de forma dinâmica, alocando os recursos

(rotas), tomando por base as condições da rede no tempo de transmissão. Isto permite que adversidades

como falhas de componentes ou sobrecarga de canais ou de dispositivos de comunicação sejam evitadas.

As estações ao receberem uma mensagem devem ter capacidade de identificar se a informação é

destinada a ela mesma ou a outra estação. Qualquer topologia (com exceção da Totalmente Ligada) deve

estabelecer mecanismos de endereçamento para o envio de mensagens. O endereçamento é uma forma

única de identificação de cada estação conectada a uma rede.

Nas redes locais (LANs) e metropolitanas (MANs) pode se estabelecer a um baixo custo,

mecanismos para otimização do desempenho da rede através da redução de taxas de erro nas

transmissões e aumento da velocidade do meio. As topologias Estrela, Anel e Barra são utilizados em LANs

e MANs, porém seriam inviáveis nas WANs.

2.1.5. Análise da Topologia em Estrela

F igura 5 : Topo log ia em Estre la



A estação posicionada no centro da figura acima representa o nó central, também chamada de nó

mestre da rede, os demais são escravos. O nó mestre tem como tarefa interligar as estações da rede e

gerenciar a comunicação.

Todas as mensagens passam pelo nó central, o qual tem a função de comutar as estações que

desejam se comunicar, por este fato ele é denominado Comutador ou Switch.

Esta topologia é aplicável em sistemas onde o processamento é executado pelo nó central, o qual

é alimentado pela informação dos nós escravos. A topologia em estrela também se aplica aos sistemas

onde o nó central tem a função de gerenciamento das comunicações e diagnóstico da rede.

Pelo fato de concentrar todas as mensagens no nó central, esta topologia não necessita do

Roteador. As redes em Estrela permitem a operação por difusão (Broadcasting), ou seja, todas as

informações enviadas pelo nó mestre são distribuídas aos nós escravos, aquela que se identificar como

destinatária copia a mensagem, as demais a ignoram. Caso a operação não seja por difusão, o nó central

estabelecerá o controle permitindo a comunicação de um nó escravo com outro por vez.

Outras funções podem ser atribuídas ao nó central, tais como compatibilizar a velocidade de

comunicação entre dois nós escravos e, caso as estações escravas trabalhem com protocolos diferentes, o

nó mestre poderia efetuar a conversão de protocolos. O nó central poderia também estabelecer a

segurança da rede através da verificação de acesso de um determinado usuário ao sistema. Informações

de diagnóstico da rede poderiam ser obtidas a partir do nó central.

A confiabilidade é um ponto crítico desta topologia, uma vez que uma falha do nó central

determinaria uma parada total do sistema. A redundância do nó mestre poderia solucionar a questão da

baixa confiabilidade, devendo-se avaliar o benefício obtido em relação ao custo necessário para

estabelecê-la. Uma falha ocorrida em uma das estações escravas teria um impacto mínimo no

funcionamento do sistema uma vez que todo o restante da rede (nó central e demais estações escravas)

continuaria funcionando.

A capacidade de expansão da rede (adição de nós escravos) é um ponto limitante, determinado

pelo nó mestre. A expansão da rede irá gerar uma carga maior de processamento e gerenciamento de

tráfego do nó central até o seu limite físico, a partir do qual, seria necessária a sua substituição.



2.1.6. Análise da Topologia em Anel “Fechado”

F igura 6 : Topo log ia em Ane l "Fechado”

A topologia da rede em anel é estabelecida através de um caminho fechado, o anel na verdade

não interliga as estações, mas sim repetidores, os quais interligam as estações ao anel. Teoricamente uma

rede em anel teria a possibilidade de comunicação bidirecional, porém, para efeitos de simplificação do

projeto dos repetidores e do protocolo de comunicação, ela normalmente é unidirecional. Isto evita também

o roteamento.

A fim de minimizar o retardo da comunicação, os repetidores são projetados com a capacidade de

transmitir e receber dados de forma simultânea. O protocolo utilizado define a forma de operação da rede:

A mensagem enviada por um nó irá circular no anel até ser retirada pelo nó destino, ou então até que ela

retorne ao nó origem, neste caso é permitida a operação por difusão (broadcast e multicast), onde a

informação é enviada de forma simultânea para diversas estações.

Os repetidores devem ter a capacidade de selecionar um pacote, retirá-lo da rede ou passá-lo

adiante. Pelo fato dos repetidores serem elementos ativos, ou seja, regenera o sinal, as redes em anel

podem atingir grandes distâncias (infinito – teoricamente).

A fragilidade desta topologia reside no fato de que uma quebra em um de seus enlaces ou falha

em um dos repetidores determinará a parada da rede até que o problema seja solucionado. Os repetidores

devem ser independentes (inclusive seu funcionamento) das estações, pois do contrário uma falha na



estação ou falta de alimentação determinaria a parada do repetidor, tornando o sistema ainda mais

vulnerável.

Existem propostas de redes baseadas nesta tecnologia, porém com anéis duplos, caminhos

alternativos, etc., a fim de minimizar a vulnerabilidade da rede, tornando-a mais confiável e praticamente

imune à falhas, porém o custo desta implementação comparado ao benefício obtido deverá ser avaliado,

podendo tornar-se inviável.

A utilização de concentradores (Hubs) permite o isolamento de uma estação que eventualmente

apresente falha e a adição de novas estações sem a necessidade de parada da rede. O caminho

alternativo, um segundo ou terceiro anel, estabeleceria uma maior confiabilidade ao sistema através de

caminhos redundantes, ou seja, caso ocorra uma falha no enlace entre dois concentradores, o caminho

alternativo seria automaticamente chaveado. Outra alternativa para minimizar a vulnerabilidade da

topologia é estabelecer vários anéis independentes interligados por pontes (bridges).

2.1.7. Análise da Topologia em Barra

F igura 7 : Topo log ia em Barra

A topologia em Barra (figura acima) interliga as estações através de uma configuração Multiponto.

Todas as estações conectadas à rede “escutam” as informações transmitidas, assim como numa

transmissão por radiodifusão. O controle de acesso à barra poderá se dar de forma centralizada ou

descentralizada.

A primeira é um tipo de multiplexação no tempo. Na forma descentralizada uma estação específica

determina o direito de acesso à barra, nesta forma a responsabilidade do acesso é distribuída entre todas

as estações.



As interfaces da Barra (transceptores – transmissor/receptor) podem ser compostas por circuitos

passivos e um sistema temporizado de prevenção (watch-dog timer) o qual tem a função de detectar e

desconectar o nó que apresenta falha (não pára de transmitir). Os transceptores se interligam aos

condutores da barra através de conectores elétricos. O transceptor deve apresentar alta impedância e

estar localizado próximo aos condutores da barra (garantindo assim a alta impedância), a fim de minimizar

as alterações nas características da transmissão.

Neste nó uma estação redundante pode ser um nó adicional na rede. As terminações de uma rede

em barra devem fazer uso de terminadores (dispositivos com carga ôhmica igual à impedância

característica da rede) a fim de minimizar os efeitos de reflexões expúrias.

O número de estações, a taxa de transmissão e o meio utilizado vão determinar o número de nós

suportados pela rede e a distância máxima entre nós. Repetidores ativos poderão ser utilizados a fim de

atingir distâncias maiores. Os concentradores (hubs) poderão ser utilizados facilitando a detecção e

isolamento de falhas e permitindo a adição ou retirada de estações sem ocasionar a parada da rede.

2.2. SINAIS ANALÓGICOS E DIGITAIS

Os termos analógicos e digitais são utilizados para definir a natureza e características de sinais

transmitidos em um determinado meio físico. Como exemplos de sinais analógicos, bem próximos de nós,

têm o som e a luz, estes sinais variam de forma contínua com o tempo. Os sinais digitais são compostos de

pulsos de amplitude fixa e período (também fixo) T. Para os sinais digitais, temos como exemplo os sinais

manipulados pelos computadores que processam, armazenam, codificam e decodificam dados na forma de

bits (sinais discretos de tensão ou corrente que, em função do seu patamar, assumem os níveis lógicos “0”

e “1”).

Os meios de transmissão apresentam propriedades físicas que atenuam o sinal, as amplitudes de

um sinal são transmitidas de f0 a uma frequência de corte fc (cuttof frequency), a partir da qual o sinal será

fortemente atenuado (atenuação da amplitude em função do aumento da frequência). Desta forma, o meio

de transmissão atua como um filtro, imputando perdas às componentes do sinal e causando distorções no

sinal resultante. Abaixo está representada a curva (hipotética) de um meio, relacionando o ganho com a

frequência.



F igura 8 : Curva Ganho x Frequênc ia

A banda passante de um sinal pode ser definida como a faixa de frequências que compõe o sinal.

No caso do meio é a faixa de frequências que o meio disponibiliza (útil) para transmissão de um sinal, sem

degradá-lo. Na figura acima, a banda passante é a faixa compreendida entre 625 Hz e 5KHz. A largura de

banda do sinal ou meio é a diferença entre a maior e a menor frequência, no nosso exemplo (meio):

5000Hz – 625Hz = 4375Hz.

2.2.1. Multiplexação

Normalmente a banda passante do meio físico acomoda a banda passante necessária para

transmissão de um sinal (figura abaixo). A banda passante do sinal é, na prática, bem menor do que a

banda passante do meio físico, desta forma poderia aproveitar a banda passante excedente do meio para

transmitir outros sinais.

Denomina-se Multiplexação à técnica que possibilita a transmissão de mais de um sinal utilizando

o mesmo meio físico. As técnicas de multiplexação são FDM (Frequency Division Multiplexing) –

Multiplexação na Freqüência e TDM (Time Division Multiplexing) – Multiplexação no Tempo.



F igura 9 : Banda de Frequênc ia

Banda Passante do Meio = 0 ~ 5KHz

Banda Passante do Sinal = 0 ~ 625Hz

2.2.2. Multiplexação na Frequência

Na figura abaixo, é representada graficamente, a Multiplexação na Frequência (FDM).

F igura 10: Mu l t ip lexação da Freqüênc ia

2.2.3. Modulação

A técnica que possibilita o deslocamento de frequências a fim de permitir a multiplexação destas

em um mesmo meio físico, é denominada Modulação. O princípio da Modulação implica no deslocamento do

sinal original (Modulador) até uma determinada frequência, designada Portadora. Para demodulação do

sinal transmitido, a sua faixa deverá ser previamente identificada pelo receptor e serão utilizados filtros a

fim de deslocar o sinal para a sua faixa de frequência original. Os dispositivos que realizam a modulação e

demodulação de sinais são conhecidos como MODEMs (MOduladores/DEModuladores).



As técnicas de Modulação são: AM (Amplitude Modulation) – Modulação por Amplitude; FM

(Frequency Modulation) – Modulação por Frequência e PM (Phase Modulation) – Modulação por Fase.

Para sinais digitais as técnicas utilizadas são: ASK (Amplitude Shift Keying) – Modulação por

Chaveamento da Amplitude; FSK (Frequency Shift Keying) – Modulação por Chaveamento da Frequência e

PSK (Phase Shift Keying) – Modulação por Chaveamento de Fase.

Abaixo estão representadas as técnicas de Modulação de Sinal Digital e suas resultantes:

ASK – A Frequência da portadora é mantida, a amplitude do sinal resultante será a da portadora

para nível lógico “1” e zero para nível lógico “0”.

FSK – A amplitude da portadora é mantida, a frequência varia em função do nível lógico do sinal

digital.

PSK – A amplitude e frequência da portadora são mantidas, uma inversão de fase (180º)

ocorrerá no sinal resultante sempre que houver uma transição no sinal digital de nível lógico “0” para nível

lógico “1” e nenhuma alteração na transição de “1” para “0”.

F igura 11: Modu lação de S ina l



2.2.4. Protocolos

O protocolo pode ser apresentado como a “linguagem” utilizada pelos componentes de uma rede

para a troca de dados. Para que isto ocorra, é necessário que os dispositivos envolvidos façam uso de

um mesmo protocolo. Algumas considerações importantes devem ser lembradas:

1. As comunicações normalmente são Half-Duplex – O enlace é utilizado nos dois sentidos, porém

somente um sentido por vez.

2. Na maioria das redes um mesmo caminho é utilizado para a comunicação, um mesmo meio físico

ou cabo é compartilhado pelas estações da rede. A utilização de Concentradores ou Hubs pode

mascarar visualmente este fato, de que uma mensagem enviada da estação 1 para a estação 2

será na verdade, enviada para todas as N estações interligadas a esta rede.

3. Tomando ainda por base um único meio físico (cabo), não poderão ocorrer trocas de dados

simultâneas, com excessão de utilização de trechos diferentes do cabo estabelecidos a partir do

uso de Chaveadores ou Switches, ou seja, duas estações trocariam dados utilizando um trecho do

cabo ao mesmo tempo em que outras duas comunicar-se-iam utilizando um outro trecho.

4. O tráfego na rede é um outro tipo de problema a ser enfrentado. A transferência de grandes

volumes de informação irá ocupar a rede por um tempo excessivo, não permitindo que outra

comunicação ocorra até a sua finalização.

5. Interferências diversas poderão ocorrer ao longo do percurso entre duas estações que estão

estabelecendo comunicação. Estas Interferências poderão se manifestar na forma de ruídos,

provocando a distorção na transmissão de sinais, ou seja, uma mensagem transmitida poderá

chegar ao destino com dados alterados por ação das interferências.

Os protocolos foram projetados para solucionar as limitações e problemas citados acima. Uma das

funções do protocolo é dividir uma mensagem em pequenos pacotes de tamanho fixo, minimizando desta

forma a taxa de ocupação do meio no envio de grandes mensagens e otimizando o uso da rede, permitindo

que outras estações tenham a oportunidade de transmitir seus dados. Obviamente cada pacote tem o seu

endereço de origem e destino previamente estabelecidos e incorporados ao pacote para que somente a



estação destino o aceite. As interfaces ou placas de rede têm uns endereços fixos e únicos, gravados em

hardware a fim de identificá-las em uma rede.

Através do endereço MAC (Medium Access Control) – Controle de Acesso ao Meio cada dispositivo de

interface ou placa de rede é identificado de forma única. Este endereço é composto por seis bytes (1 byte

= 8 bits), sendo os três primeiros designados OUI (Organizationally Unique Identifier) – Identificador Único

da Organização/Empresa, indicando o fabricante da placa e atribuído a este pelo IEEE (Institute of Electrical

and Electronics Engineers) – Instituto de Engenheiros Elétricos e Eletrônicos, mediante cadastramento. Os

três últimos bytes são designados e controlados pelo fabricante da placa de forma que não ocorram

repetições.

Nas redes de computadores diversos protocolos são utilizados, dentre eles podemos citar: NetBEUI,

SPX/IPX e o TCP/IP.



ANOTAÇÕES



3 . ESTRUTURAÇÃO DE UMA REDE DE COMPUTADORES

Um dos princípios de estruturação de uma rede baseia-se em um conjunto de camadas hierárquicas as

quais são construídas pela utilização de serviços e funções oferecidos pelas camadas ou níveis

imediatamente inferiores. Nesta arquitetura, cada camada é vista como um processo ou programa que

estabelece comunicação com o processo ou programa correspondente na outra estação. O conjunto de

regras que estabelecem e gerenciam a conversação entre dois níveis N (estações 1 e 2) é denominado

protocolo do nível N. A forma de transferência de dados entre dois níveis de mesma hierarquia (estações 1

e 2) não ocorre de forma direta (horizontalmente), mas sim pela passagem do pacote para o nível seguinte

(imediatamente abaixo) até que o nível 1 (meio físico) seja atingido. A informação trafega então pelo meio

físico e percorre os diversos níveis adjacentes da estação receptora, no sentido inverso, até atingir o nível

de destino.

A arquitetura desta rede é formada por níveis, interfaces (limites entre níveis adjacentes) e protocolos.

Na verdade mais de um protocolo pode ser utilizado para realização das funções que estabelecem os

serviços de um determinado nível. A arquitetura de protocolos em níveis apresenta-se muito eficiente, pois

uma vez conhecida a interface entre os níveis, uma determinada modificação poderá ser implementada no

nível sem causar impacto na estrutura global.

3.1. MODELO OSI

No passado, as arquiteturas de rede foram definidas por cada fabricante de forma independente e

particular, tornando este sistema proprietário, não permitindo a comunicação entre estações de diferentes

fabricantes. A necessidade de estabelecer esta comunicação, permitindo a troca de dados entre estações

de fabricantes diferentes levou-os à padronização de uma arquitetura única, assim foi criado pela ISO

(Internacional Organization for Standardization) – Organização Internacional para Padronização, modelo

OSI ou RM-OSI (Reference Model for Open System Interconnection) – Modelo de Referência para

Interconexão de Sistemas Abertos. A estrutura do modelo OSI baseia-se em sete níveis detalhados a seguir.

Este modelo é utilizado tanto em redes locais quanto em redes de longa distância. É importante lembrar

que a maioria dos protocolos existentes: NetBEUI, SPX/IPX e o TCP/IP, assim como os protocolos utilizados

em redes industriais, não seguem “à risca” o modelo OSI. Veremos que em muitos protocolos apenas



algumas camadas do modelo OSI são utilizadas, em outros é utilizada a filosofia de camadas, porém com

designações e funções diferentes do modelo OSI.

Como já descrito, o pacote de dados proveniente de uma camada superior é entregue à camada

seguinte (imediatamente inferior) a qual acrescenta informações inerentes a ela e entrega o conjunto de

dados para o próximo nível e assim sucessivamente até que seja atingido o último nível (físico). A tarefa de

acrescentar as informações da camada ao pacote de dados para enviar à camada seguinte é designada

encapsulamento.

. F igura 12: Mode lo OSI

• Camada 7 – Aplicação: Esta camada estabelece a interface entre um aplicativo que

solicitou comunicação (enviar ou receber dados) e o protocolo de comunicação. Um aplicativo

de e-mail fará contato com a camada de aplicação a fim de efetuar um pedido de

comunicação (envio ou recebimento de e-mail).

• Camada 6 – Apresentação: A camada de apresentação executa uma conversão do

formato de dados recebidos em um formato compatível com o protocolo. Dados em ASCII

poderão ser criptografados ou comprimidos nesta camada, como tarefa do protocolo para

envio à camada seguinte.



• Camada 5 – Sessão: Nesta camada, duas aplicações executadas em máquinas

diferentes, criam uma sessão de comunicação, definindo a forma de transmissão dos dados e

colocando sinalizadores nos dados transmitidos de forma a restabelecer a comunicação após

uma eventual falha. Alguns programas gerenciadores de Download restabelecem a tarefa do

ponto onde parou, após uma falha de comunicação.

• Camada 4 – Transporte: Na camada de Transporte o conjunto de dados recebidos da

camada Sessão é dividido em pacotes para posterior envio à camada de Rede. No lado do

receptor a camada de Transporte rearranja os dados recebidos da camada de rede para

entrega à camada de Sessão, nesta etapa é realizado o controle de fluxo e correção de erros.

• Camada 3 – Rede: Na camada de rede é realizado o endereçamento dos pacotes, a

partir dos endereços lógicos são gerados os endereços físicos, para que seja estabelecido de

forma correta o destino de cada pacote. Com base nas condições de tráfego da rede e na

prioridade, é estabelecida a rota de envio do pacote, obviamente aplicável para redes com

mais de um segmento.

• Camada 2 – Link de Dados: Esta camada, também conhecida como camada de enlace,

monta um quadro que contém, além dos dados recebidos da camada de Rede, os endereços

das placas de rede de destino e origem e o CRC. No lado do receptor, é verificada a

integridade da informação recebida através da comparação do CRC (calculado no receptor e

comparado com o CRC recebido do transmissor). Caso a informação recebida esteja

corrompida, a camada Link de Dados reenvia o quadro.

• Camada 1 – Física: A Camada física é responsável por converter a informação recebida

da camada Link de Dados em sinais compatíveis com o meio físico utilizado. Para um meio

físico que utiliza um cabo elétrico, a informação é convertida em sinais elétricos compatíveis

com o cabo. No caso de utilização de Fibra Ótica como meio de transmissão, os dados são

convertidos em sinais luminosos. A implementação desta camada é responsabilidade da placa

de rede.



3.2. CONCENTRADORES E CHAVEADORES

Os Concentradores (Hubs) são dispositivos cuja função é centralizar os pacotes de dados,

estabelecendo uma topologia em estrela (física – aparente) e barra (lógica – real), os Hubs atuam também

como repetidores, regenerando o sinal transmitido, ampliando assim, a extensão física da rede. Um pacote

a ser enviado de uma estação A para uma estação B, na verdade é transmitido a todas as estações

conectadas às portas do Hub. Analisando o seu funcionamento a partir do tráfego de informações, a

conexão das portas do Hub com as estações pode ser enxergada como uma topologia em barra. O

isolamento de uma estação ou segmento que apresente falha é uma das vantagens obtidas com a

utilização dos Hubs. Pelo fato de atuar na camada física do modelo OSI, os Hubs não têm capacidade de

identificar o destinatário de um pacote transmitido, minimizando o tráfego de dados e otimizando o

desempenho da rede. Os tipos de Hubs são basicamente: Passivos – Não alimentados, também chamados

de Patch Panels e utilizados no cabeamento estruturado; Ativos - Alimentado, como já descrito atuam como

repetidores genericamente designados Hubs; Inteligentes – Disponibilizam relatórios estatísticos, de falhas

e conflitos ocorridos via software e Empilháveis ou Cascateáveis (Stackables) – Permitindo a adição de

outras unidades através da conexão (cascata) de portas específicas. O cascateamento de Hubs é limitado.

Os chaveadores (Switches) atuam na camada de Link de dados do modelo OSI e desta forma são

capazes de identificar o endereço MAC do pacote de dados, enviando-o somente para a estação destino,

reduzindo o tráfego da rede, evitando conflitos e otimizando o seu desempenho, determinando desta forma

uma maior segurança. O Switch estabelece uma topologia de rede em estrela com as estações.

Comunicações simultâneas poderão ser estabelecidas, desde que não envolvam as mesmas estações

(origem e destino). Os Switches gravam em uma tabela o endereço MAC das placas de rede ligadas às suas

portas (associação do endereço com a porta), num primeiro instante de transmissão e, a partir daí,

consultará esta tabela para determinar a porta que receberá o pacote (estação). Caso o endereço MAC de

destino não seja conhecido (não se encontra gravado na tabela do dispositivo) o Switch atuará de forma

semelhante ao Hub, enviando o pacote para todas as estações, com exceção da estação destino. Após um

tempo determinado, sem receber o endereço MAC de uma porta, ele é automaticamente retirado da tabela.

Alguns switches permitem interligar estações com velocidades de comunicação diferentes.



3.3. DISTORÇÃO DE SINAIS

Diversos fatores determinam a distorção na transmissão de sinais, dentre eles podemos citar:

• Limitação da banda passante do meio físico;

• Ruídos provocados pela interferência de outros sinais:

o Térmico – gerado pela agitação de elétrons nos condutores;

o Intermodulação – provocada por sinais diferentes compartilhando um mesmo meio físico

(multiplexação na freqüência);

o Crosstalk (linha cruzada) – Ocorre com a indução de sinais entre condutores muito

próximos;

o Ruído Impulsivo – Pode ser gerado por diversas fontes tais como distúrbios elétricos e

falhos nos dispositivos, é de difícil prevenção, apresentando pulsos irregulares e de

grandes amplitudes, provocando maiores erros nas comunicações digitais.

• Ruídos devidos à Lei de Shannon – Um canal tem uma capacidade máxima de transmissão

limitada, a qual sendo transposta irá gerar ruído;

• Atenuação, com o aumento da distância do meio físico ocorre queda da potência do sinal

transmitido, as perdas são provocadas por radiação e perdas de energia por calor. As perdas são

maiores nas freqüências mais altas. Geralmente expressa em decibéis por unidade de

comprimento (p.ex. dB/m). O uso de repetidores, restabelecendo os níveis do sinal, soluciona os

problemas gerados pela atenuação;

• Ecos, a alteração na impedância de uma linha de transmissão determina a reflexão dos sinais que

voltarão para a linha, ocasionando conflitos com os sinais que estão sendo transmitidos.



3.4. DETECÇÃO DE ERROS

Evitar ou eliminar a distorção de sinais provocada pelos fenômenos listados acima nem sempre é

possível, desta forma o sistema de comunicação deve estar apto a detectar uma eventual falha no sinal

transmitido, a fim de recuperá-lo. Os métodos de detecção de erros baseiam-se na adição de bits na

informação transmitida.

Os bits da mensagem a ser transmitida “passam” por um algoritmo, o resultado da execução

deste algoritmo (bit ou bits) sobre os bits da informação é acrescentado à própria informação (pacote).

Após receber a informação, o receptor executa o mesmo algoritmo utilizado no transmissor, excluindo-se

obviamente o(s) bit(s) calculado(s) pelo algoritmo do transmissor. O resultado da verificação do receptor é

então comparado com o resultado do transmissor, ocorrendo diferença é detectada a ocorrência de um

erro na transmissão. Dentre as técnicas utilizadas para detecção de erros, podemos citar:

1. Paridade: Esta é a forma mais simples de detecção de erros em pacotes. Existem dois tipos de

paridade: Na paridade PAR (Even) será verificado o número de bits “1” a ser transmitido e será

acrescentado um bit com valor “1” ou “0” para tornar par o número de bits “1” do pacote. Na

paridade ÍMPAR (Odd) também será verificado o número de bits “1” a ser transmitido e será

acrescentado um bit com valor “1” ou “0” para tornar ímpar o número de bits “1” do pacote.

Tomemos como exemplo a transmissão do byte abaixo com paridade ímpar:

“10111011” - O número de bits “1” (6 bits) é par, desta forma o transmissor irá acrescentar um

bit com valor “1” para tornar o número de bits “1” ímpar (Paridade Ímpar). O receptor, ao receber a

mensagem, verificará o número de bits “1” e caso encontre um número ímpar, assumirá que a

transmissão foi realizada com sucesso.

É fácil notar a vulnerabilidade deste tipo de verificação, pois caso ocorra à inversão de dois bits da

informação, o receptor não terá condições de detectar o erro.

2. Checksum: Ou Verificação de Soma. Os bits do pacote são somados e o resultado é colocado no

próprio pacote. O receptor, ao receber a mensagem, efetuará também a soma de bits e irá

comparar com a soma realizada pelo transmissor (recebida no pacote). Caso os valores

coincidam, o receptor assumirá que a transmissão foi realizada com sucesso. A mudança



sucessiva do valor de um bit “1” para “0” e de outro bit de valor “0” para “1”, ocorridas no

mesmo pacote, não seria detectada pelo receptor.

3. CRC: Cyclical Redundancy Check (Verificação por redundância cíclica). Este tipo de verificação

apresenta-se mais eficiente. Uma informação de n bits é representada através de um polinômio em

X, cuja ordem é n-1. O coeficiente do termo Xi é estabelecido pelo (i+1)-enésimo bit do conjunto

de n bits. Um quadro composto pelos seguintes bits: 11000011 serão representados pelo

seguinte polinômio: X7+X6+X+1. O transmissor gera um polinômio de ordem k que será o divisor

do polinômio de ordem n-1. O resultado desta divisão (base 2) é um quociente e resto de ordem

k-1. Os dados a serem transmitidos são compostos pelos n bits (informação inicial) seguidos dos

bits correspondentes ao resto da divisão do polinômio em X pelo polinômio de ordem k. Estes bits

(resto da divisão) são designados FCS – Frame Check Sequence (Verificação de Seqüência de

Quadro). No receptor o procedimento será de forma análoga ao transmissor. Os n bits do quadro

inicial são divididos pelo mesmo polinômio de ordem de ordem k existente também no receptor. O

resto da divisão é então comparado com o FCS recebido do transmissor. Havendo diferença entre

os bits dos FCSs (transmissor e receptor), é detectado um erro. Diversos CRCs são utilizados e

padronizados para aplicações específicas.



ANOTAÇÕES



4 . COMUNICAÇÃO SERIAL RS-232(S ing le-ended)

4.1. INTRODUÇÃO

A maioria dos equipamentos de controle utilizada na automação comunica-se diretamente com

microcomputadores PC através de portas seriais, por este fato a maior parte dos PLCs existentes no

mercado baseia-se em conexões seriais para estabelecer comunicação com microcomputadores. Utilizando

diversas ferramentas de programação (softwares), fáceis de configurar, é possível criar conexões múltiplas

com diversos sistemas.

Muitas normas utilizadas hoje na automação foram baseadas em comunicações do tipo serial,

como exemplo pode citar o padrão Modicon Modbus.

Os Line Drivers e Receivers (chips) são normalmente utilizados para troca de dados entre dois ou

mais pontos (nós) de uma rede. Pode ser difíceis obter-se uma comunicação de dados confiável na

presença de ruído induzido, diferenças de níveis de aterramento e impedância, e outras falhas associadas

com a instalação de uma rede.

Diversas normas foram desenvolvidas para garantir a compatibilidade entre equipamentos

produzidos por diferentes fabricantes, e para permitir a transferência de dados a distâncias e/ou taxas

específicas com razoável sucesso. A EIA (Electronics Industry Association) criou as normas RS232, RS423,

RS422 e RS485. Diversas sugestões foram posteriormente enviadas a EIA a fim de solucionar problemas

práticos encontrados em uma rede típica. As normas EIA foram previamente designadas com o prefixo “RS”

(Recommended Standard) e hoje são geralmente precedidas das letras EIA para identificação da

organização que as criou. As normas procuram levar a uniformidade para a comunicação de dados, porém

muitas áreas não são especificamente cobertas, permanecendo sem especificação definida, exigindo que o

usuário descubra alguns detalhes por si mesmo (geralmente durante a implementação e/ou instalação da

rede).

As comunicações eletrônicas de dados entre dois ou mais elementos dividem-se em duas

categorias, definidas como single-ended (única extremidade) ou differential (diferencial). Estão inclusos na

categoria single-ended os padrões RS232 e RS423 e na categoria differential RS422 e RS485.



4.2. FUNDAMENTOS DA COMUNICAÇÃO SERIAL RS-232 (SINGLE-ENDED)

Apesar de sua relativa simplicidade e baixo custo de hardware (comparado com o interfaceamento

paralelo), as comunicações seriais são largamente utilizadas na indústria eletrônica. Dentre os padrões

mais utilizados de comunicação serial, o mais popular foi, certamente, o EIA/TIA-232-E. Esta norma foi

desenvolvida pela Electronic Industry Association – EIA (Associação da Indústria Eletrônica) e pela

Telecommunications Industry Association – TIA (Associação da Indústria de Telecomunicações).

Normalmente referimo-nos a este norma, de uma forma mais simples, como RS-232, onde RS significa

Recommended Standard (Norma Recomendada). O prefixo EIA/TIA é utilizado para identificar a origem ou

fonte da norma.

O nome oficial da norma EIA/TIA-232-E é “Interface Between Data Terminal Equipment and Data

Circuit-Termination Equipment Employing Serial Binary Data Exchange” (Interface entre Equipamento

Terminal de Dados e Equipamento Circuito Final de Dados, empregando troca Serial de Dados Binários).

Apesar do nome intimidante, esta norma é bastante simples, consistindo de uma comunicação serial entre

um sistema hospedeiro (host) (Data Terminal Equipment – DTE) e um sistema periférico (Data Circuit-

Termination Equipment – DCE), conforme o exemplo abaixo:

F igura 13: Comunicação entre PCs



A norma EIA/TIA-232-E foi introduzida em 1962 e desde então sofreu quatro atualizações

buscando melhorias nas aplicações de comunicação serial. A letra “E” (sufixo da norma) indica a sua

quinta revisão.

4.3. ESPECIFICAÇÕES

O RS-232 é uma norma completa, ou seja, organiza e garante, através das especificações citadas a

seguir, a compatibilidade entre um sistema host e um sistema periférico.

1. Tensões e níveis de sinais padronizados.

2. Pinagem de conectores padronizada.

3. Informações de controle mínimas entre o Sistema Host e o Periférico.

Diferentemente de muitos padrões que simplesmente especificam as características elétricas de uma

dada interface, o RS-232 especifica os padrões elétricos, funcionais e características mecânicas a fim de

buscar os três critérios citados acima. A seguir faremos uma discussão destes critérios.

4.4. CARACTERÍSTICAS ELÉTRICAS

A seção que trata das características elétricas da norma RS-232 inclui especificações para: Níveis

de Tensão, Taxa de Troca dos Níveis de Sinal e Impedância. Como já citado, a norma RS-232 foi

originalmente definida em 1962, bem antes da definição da Lógica TTL. Desta forma é fácil verificar porquê

não foram utilizados os níveis +5V e Terra (0V) na norma RS-232. No seu lugar são utilizados como nível

alto (saída do driver) tensões entre +5V e +15V e para nível baixo entre -5V e -15V. A lógica do receptor

foi determinada a fim de estabelecer uma margem de ruído de 2V. Desta forma o receptor “enxerga” um

nível alto com tensões entre +3V à +15V e nível baixo com tensões entre -3V à -15V. A figura abaixo

ilustra os níveis lógicos definidos pela norma RS-232.

É importante notar que o nível lógico baixo (-3V à -15V) na comunicação RS-232 é definido como

lógica “1” e também chamado de “marca” e o nível alto (+3V à +15V) é definido como lógica “0” e

também conhecido como “espaço”.



F igura 14: Espec i f i cações de N íve l Lóg ico

A norma RS-232 também limita o máximo slew rate na saída do driver. Esta limitação foi incluída

visando à redução de linha cruzada (Crosstalk) entre sinais adjacentes. Quanto menores os tempos de

ascensão e queda (rise/fall time), menor as chances de cruzamento de sinais (interferência de um sinal no

outro). Desta forma o máximo s lew-rate* permitido é de 30V/µs. Adicionalmente a esta limitação, foi

definida a taxa de transmissão de dados em 20Kbits/s, a fim de minimizar os efeitos de Crosstalk.

*S lew-rate é a máxima taxa de var iação da tensão de sa ída por un idade de

tempo, normalmente representado em V/µs. E le nos dá a “ve loc idade” de resposta do

d ispos i t ivo.

A impedância entre o driver e o receptor também foi definida. A carga vista pelo driver deve estar

compreendida entre 3KΩ e 7 KΩ. Na norma original (inicial) o comprimento máximo do cabo entre o driver

e o receptor também foi definido, e era de 15m. Na revisão D da norma (EIA/TIA-232-D) no lugar de

especificar o comprimento máximo do cabo, foi especificada a capacitância máxima do mesmo, o que é

claramente uma especificação mais adequada, uma vez que o comprimento máximo do cabo é determinado

pela sua capacitância por unidade de comprimento, a qual faz parte das especificações do cabo.



4.5. CARACTERÍSTICAS FUNCIONAIS

Uma vez que o RS-232 é uma norma completa, ela inclui mais do que especificações de características

elétricas. O Segundo aspecto coberto pela norma consiste na definição das características funcionais da

interface. Isto significa essencialmente que o RS-232 definiu as funções dos diferentes sinais que são

usados na interface. Estes sinais são divididos em quatro categorias diferentes:

1. Common (Comum)

2. Data (Dados)

3. Control (Controle)

4. Timing (Temporização)

Tabe la 1 : S ina is De f in idos pe la Norma RS-232

Como pode ser visto na tabela acima, existe um número muito grande de sinais definidos pela

norma, ela estabeleceu um grande número de sinais de controle e suporta canais de comunicação

primários e secundários. Felizmente, poucas aplicações ou praticamente nenhuma irá requerer todos estes

sinais de controle. Por exemplo, em uma aplicação típica com Modem, somente 8 sinais de controle são



utilizados. Aplicações mais simples requerem um total de 4 sinais (2 para dados e 2 para handshaking),

enquanto outras requerem somente sinais de dados (sem handshaking). Alguns exemplos de aplicações

reais da RS-232 serão apresentados adiante. A lista completa de sinais na tabela acima foi apresentada

apenas como uma referência. Somente será analisada a funcionalidade dos principais sinais.

4.6. CARACTERÍSTICAS MECÂNICAS DA INTERFACE

A terceira parte coberta pela norma RS-232 consiste da interface mecânica. A norma especifica um

conector de 25 pinos. Este tamanho de conector é o mínimo necessário para comportar todos os sinais

definidos na parte funcional da norma. A disposição dos pinos para este conector é mostrada na figura

abaixo:

F igura 15: P inagem DB25

O conector utilizado no DCE é do tipo fêmea e no DTE macho. Apesar de a norma especificar um

conector de 25 pinos, nem sempre ele é utilizado, devido ao fato de que a maioria das aplicações não

requer todos os sinais como ilustrado na figura acima. Desta forma o conector de 25 pinos seria sub

utilizado (maior do que o necessário) e assim, é normal que se utilizem outros tipos de conectores. Um dos

conectores mais utilizados é o DB9S, de 9 pinos ilustrado na figura a seguir:



F igura 16: P inagem DB9

Para aplicações de comunicação utilizando Modems, o conector de 9 pinos é suficiente para

acondicionar os sinais de transmissão e recepção e de controle.

4.7. FUNCIONAMENTO

Como qualquer dispositivo de transmissão serial, os bit são enviados um à um, sequencialmente, e

normalmente com bit menos significante primeiro (LSB). Por ser um protocolo assíncrono isto é, sem uma

linha de relógio (clock), é responsabilidade do transmissor e do receptor efetuarem controles de tempo

para saber quando cada bit inicia e finaliza.

Na sua forma padrão o RS-232 utiliza dois sinais de controle, o RTS (ready to send) e o CTS

(clear to send) para efetuar o controle de fluxo via hardware. Basicamente, quando o transmissor deseja

começar um envio ele sinaliza através do pino RTS. O receptor, ao perceber que o transmissor deseja

enviar algum dado, prepara-se para recebe-lo e seta o pino CTS. Apenas depois de receber o sinal CTS o

transmissor pode começar a transmissão.

Para cada byte existem bit de start e stop; o mais comum é utilizar-se 1 bit de início (start bit) e 1

bit de parada (stop bit), mas é possível encontrar aplicações que utilizam 1,5 ou 2 bit de início/parada. A

figura abaixo mostra como a transmissão de um byte ocorre:



F igure 17: B i ts RS-232

Como já citado anteriormente, esta transmissão é assíncrona. Tendo a velocidade de comunicação

ajustada nos dois dispositivos inicialmente, cada um deles sabe quanto tempo um bit demora para ser

transmitido, e é com base nisto que a identificação dos bit é possível.

No transmissor o envio basicamente resume-se à enviar um bit de início, aguardar um tempo, e

enviar os próximos 8 bit + bit de parada, com o mesmo intervalo de tempo entre eles.

No receptor, após a primeira borda de descida (nível lógico de "1" para "0") (start bit) o receptor

sabe que uma sequencia de mais 8 bit de dados + bit de parada chegará. Ele também conhece a

velocidade de transmissão, então tudo que ele precisa fazer é aguardar o tempo de transmissão entre

cada bit e efetuar a leitura. Após receber o bit de parada, a recepção encerra-se e ele volta à aguardar o

próximo start bit.

Nos microcontroladores modernos todo este trabalho normalmente é efetuado por uma UART

(Universal Asynchronous Receiver Transmitter). Este periférico encarrega-se de efetuar todo o controle e

apenas gerar interrupções quando um byte é recebido. No entanto, algumas vezes o microcontrolador

utilizado não possui uma UART, ou mesmo ela está sendo utilizada. Nestes casos é possível implementar

uma interface serial através de software, tratando a seqüência de transmissão e recepção descrita

anteriormente.

Na interface RS232 o nível lógico "1" corresponde à uma tensão entre -3V e -12V e o nível lógico

"0" à uma tensão entre 3V e 12V. Valores de tensão entre -3V e +3V são indefinidos e precisam ser

evitados. O estado idle da linha é 1 lógico (-V).



Porém a grande maioria dos periféricos que trabalham com portas seriais não utilizam o padrão

RS232 para níveis elétricos diretamente. Portanto é sempre necessário um circuito de conversão de nívels

TTL/RS232. O circuito integrado mais comum para efetuar esta conversão, de baixo custo, é o MAX232 que

possui alimentação TTL.

4.8. COMUNICAÇÃO DE DADOS

Quando não há comunicação na linha RS232, ela normalmente fica no seu estado de repouso, que

é no nível lógico 1 (de –3 A -18V no RS232). Quando inicia a comunicação o primeiro bit transferido é o

chamado bit de start, que mantém a linha de comunicação no intervalo de 1 período em nível baixo. Em

seguida vêm os 8 bits de dados do byte a ser transmitido e finalmente o bit de stop, que volta a deixar a

linha no seu estado de repouso. Na figura 3 está plotado um gráfico que permite observamos a

comunicação tanto na linha RS232 quanto na linha TTL transmitindo neste caso o byte 01001011.

1 2 3 4 5 6 7 8 9 10 11 12

F igure 18: Comunicação de dados

1. Repouso

2. Start Bit

3. Bit Dados

4. Bit Dados

5. Bit Dados

6. Bit Dados

7. Bit Dados

8. Bit Dados

9. Bit Dados

10. Bit Dados

11. Stop Bit

12. Repouso



4.9. IMPLEMENTAÇÃO PRÁTICA DA RS-232

A maioria dos sistemas projetados hoje não utiliza os níveis de tensão de operação da RS-232,

desta forma são necessárias conversões para implementação da comunicação. A conversão de níveis de

tensão é obtida pela utilização de ICs – Integrated Circuits (Circuitos Integrados) RS-232. Estes circuitos

integrados são compostos basicamente de line drivers (acionadores) que geram os níveis de tensão

requeridos pela RS-232 e line receivers (receptores) que estão aptos a receber os níveis de tensão RS-232

sem se danificar. Estes circuitos invertem os sinais a fim de representar a lógica “1” com um nível baixo de

tensão e a lógica “0” com um nível alto de tensão. A figura a seguir ilustra o funcionamento dos line

drivers/receivers em uma aplicação típica de Modem. Neste exemplo em particular, os sinais necessários

para a comunicação serial são gerados e recebidos por um chip designado UART – Universal Asynchronous

Receiver/Transmiter (Receptor/Transmissor Assíncrono Universal).

O UART realiza a “tradução” entre os níveis CMOS/TTL e a RS-232, ele implementa as tarefas

necessárias para estabelecer as comunicações seriais assíncronas.

F igure 19: Hos t Sys tem



Pela natureza da comunicação assíncrona ela normalmente requer que os bits de start e stop sejam

iniciados pelo sistema host para indicar ao sistema periférico quando a comunicação será iniciada ou

finalizada.

Bits de paridade também são empregados para certificar-se de que os dados enviados não foram

corrompidos.

O UART normalmente gera os bits de start, stop e paridade quando transmite dados e é capaz de

detectar erros de comunicação que eventualmente ocorram no recebimento de dados.

O UART também funciona como um circuito intermediário entre sistemas de comunicação byte-wide

(parallel) e bit-wide (serial). Em comunicações que utilizam longos campos de dados: bytes (paralelo) e bits

(serial) ele realiza conversões paralelo/serial e serial/paralelo. Um byte de dados é convertido em uma

seqüência de bits seriais para transmissão e uma seqüência de bits seriais recebidos é convertida em um

byte de dados.

É notório que uma aplicação RS-232 raramente segue a norma de forma precisa, talvez pelo fato

de que a maioria delas não requer a utilização de todos os sinais padronizados. Desta forma os sinais

desnecessários não são utilizados. Em muitas aplicações, tais como as que utilizam Modems, apenas 9

sinais são necessários (2 para dados, 6 para controle e 1 para aterramento). Algumas requerem somente 5

(2 para dados, 5 para handshaking e 1 para aterramento), enquanto outras utilizam somente os sinais de

dados e aterramento, ou seja, não utilizam o controle handshaking.

4.10. RS-232 EM APLICAÇÕES UTILIZANDO MODEMS

Uma das aplicações mais populares em RS-232 é a que utiliza Modems para estabelecer a

comunicação entre dois computadores. Na figura abaixo os Modems são os DTEs e os computadores os

DCEs (não mandatário). O meio de comunicação utilizado (Telecommunication) pode ser um cabo ou linha

telefônica, dentre outros.



F igura 20: Comunicação v ia MODEM

Como já foi dito anteriormente, as aplicações com Modems requerem somente 9 pinos, desta forma

o conector de 25 pinos seria super dimensionado uma vez que apenas 9 sinais são utilizados para interligar

o DTE ao DCE. Os nove sinais básicos utilizados nesta configuração estão representados na figura: Typical

RS-232 Modem Application. Verifica-se que, em relação ao DTE, são necessários 3 Drivers e 5 Receivers. A

funcionalidade destes sinais será descrita a seguir.

É importante lembrar que os sinais descritos como “On” referem-se ao nível alto em RS-232 (+5V

à +15V.) e representam a lógica “0” e os sinais descritos como “Off” referem-se ao nível baixo (-5V à –

15V), representando a lógica “1”.

TD – Transmitted Data (Dado Transmitido): Um dos sinais de dados, gerado pelo DTE e recebido

pelo DCE.

RD – Received Data (Dado Recebido): O outro sinal de Dados, gerado pelo DCE e recebido pelo

DTE.

RTS – Request to Send (Pedido de Envio): Quando o sistema Host (DTE) está pronto para

transmitir um dado para o sistema periférico (DCE) o sinal RTS é setado (On). Em sistemas de comunicação

Simplex e Duplex, esta condição mantém o DCE no modo recepção, em sistemas Half-duplex esta condição

mantém o DCE no modo recepção e desabilita o modo transmissão. A condição resetado para o RTS mantém



o DCE no modo transmissão. Após o posicionamento (set) do RTS, deverá ser setado o CTS para que seja

iniciada a comunicação.

CTS – Clear to Send (Pronto para Envio): O sinal CTS é utilizado em conjunto com o RTS a fim de

estabelecer o intercâmbio (handshaking) entre o DTE e o DCE. Após o DCE verificar o posicionamento (set)

do RTS, ele seta (On) o CTS, informando ao DTE que está pronto para iniciar a comunicação.

DSR – Data Set Ready (Conexão Estabelecida): Este sinal é setado pelo DCE para indicar que ele

está conectado ao meio físico (no nosso caso, à linha de telecomunicação).

DCD – Data Carrier Detect (Portadora de Dados Detectada): Este sinal é posicionado quando o DCE

está recebendo um sinal de um outro DCE (remoto).

DTR – Data Terminal Ready (Terminal de Dados Pronto): Este sinal indica a prontidão do DTE. Ele é

setado (On) quando o DTE está pronto para transmitir ou receber dados do DCE. O DTR deve ser setado

antes que DCE posicione o sinal DSR.

RI – Ring Indicator (Indicador de Anel - Link): Quando o RI é setado, indica que a solicitação de

comunicação está sendo recebida através do canal de telecomunicações.

Os sinais descritos acima estabelecem a base de uma comunicação com Modems, porém a melhor

maneira de entender como estes sinais interagem é, descrever através de um resumo passo a passo, o

exemplo de interfaceamento de um modem com um computador.

1. O PC local monitora o sinal RI – Ring Indicator, via software

2. Quando o Modem remoto quer se comunicar com o modem local, é gerado o sinal RI. Este sinal é

transferido ao PC local através do seu modem.

3. O PC local responde ao sinal RI efetuando o posicionamento (set) do sinal DTR (Data Terminal

Ready), indicando que está pronto para estabelecer a comunicação.



4. Após reconhecer o posicionamento do sinal DTR, o modem local responde através do

posicionamento do sinal DSR (Data Set Ready) indicando que está conectado à linha de

telecomunicação. O DSR indica ao PC que o modem está pronto para estabelecer as demais trocas

de sinais de controle com o DTE (PC) para iniciar a comunicação. Quando o DSR é posicionado, o

PC começa a monitorar o sinal DCD para obter indicação de que o dado está sendo enviado pela

linha de comunicação.

5. O Modem posiciona o sinal DCD (Data Carrier Detect) após a recepção de um sinal de portadora do

modem remoto.

6. Neste instante a transferência de dados pode começar. Se o Modem local suporta Full-duplex, O

sinal CTS (Clear to Send) e RTS (Request to Send) são mantidos setados. Se o Modem suporta

somente Half-duplex, os sinais CTS e RTS são manipulados (handshaking) de forma a controlar o

fluxo de dados nas direções e tempos corretos Finalmente, o dado é transferido através dos sinais

RD e TD.

7. Depois de finalizada a transferência de dados, o PC desabilita o sinal DTR. O Modem segue inibindo

os sinais DSR e DCD. Neste instante, o PC e o Modem estão em seu estado original, descrito no

passo 1.

4.11. RS-232 EM APLICAÇÕES COM INTERCÂMBIO (HANDSHAKING) MÍNIMO

A aplicação com Modems discutida acima é simplificada no que se refere ao número de sinais

necessários, segundo a norma RS-232. Porém ela é mais complexa do que o requerido para muitos

sistemas. Para a maioria das aplicações, dois sinais de dados e dois de controle para handshaking são

suficientes para estabelecer e controlar a comunicação entre um sistema principal e um sistema periférico.

Por exemplo, um sistema de controle que se interligar a um termostato, usando um esquema de

comunicação em Half-duplex. Em alguns instantes o sistema de controle deseja ler a temperatura do

termostato e outras vezes ele deseja alterar o ponto de disparo (trip) do termostato. Nesta aplicação

simplificada, somente 5 sinais são necessários (2 para dados, 2 para handshaking e 1 terra).



A figura a seguir ilustra uma interface de comunicação Half-duplex simples.

F igura 21: Comunicação Ha l f Dup lex

Como pode ser visto no diagrama, o dado é transferido pelos pinos TD (Transmit Data) e RD (Receive

Data). O intercâmbio (Handshaking) de controle é estabelecido pelos pinos RTS (Request to Send) e CTS

(Clear to Send). O RTS é acionado (suprido) pelo DTE para controlar a direção do dado. Quando o RTS é

posicionado, o DTE é colocado no modo transmissão. Quando o RTS é desabilitado (inibido/resetado), o DTE

é colocado no modo recepção. O CTS, gerado pelo DCE, controla o fluxo de dados. Quando posicionado

(setado) o fluxo de dados pode ser estabelecido, porém quando o CTS é inibido o fluxo de dados é

interrompido e a transmissão de dados será mantida neste estado (interrompida) até que o CTS seja

reposicionado (volte a ser setado).

4.12. LIMITAÇÕES DA REDE RS-232

Como já mencionado, a norma RS-232 foi introduzida em 1962. Após 4 décadas, a indústria

eletrônica tem mudado imensamente e é óbvio que existem limitações na norma RS-232. Uma das limitações

é o fato de terem sido definidos pela norma mais de 20 sinais. Estes sinais já foram utilizados e

conseqüentemente havia a necessidade do conector de 25 pinos. Aplicações mais recentes utilizam somente

alguns dos sinais padronizados, como foi visto anteriormente. Esta foi uma limitação simples de ser



corrigida, porém existem outras com nível de complexidade bem maior, inviabilizando muitas vezes, uma

determinada aplicação.

4.13. GERAÇÃO DOS NÍVEIS DE TENSÃO RS-232

Como visto na seção características elétricas, a norma RS-232 não utiliza os níveis de tensão

convencionais (0V e 5V), implementados nos projetos TTL e CMOS. São necessários Drivers para as tensões

+5V a +15V para representar o nível lógico “0” e -5V a -15V para representar a lógica “1”. Desta forma é

fácil verificar a necessidade de uma potência extra para suprir os níveis de tensão RS-232. Basicamente é

utilizada uma fonte de +12V / -12V para suprir as saídas RS-232. Isto se torna um grande inconveniente

em sistemas que não tem utilização para estes níveis de tensão. A fim de minimizar os problemas de

suprimento destes níveis de tensão, os fabricantes de Ics criaram componentes que geram os níveis de

tensão necessários para uma comunicação RS-232 à partir de uma tensão básica (+5V). Um deles

essencialmente dobra a tensão padrão +5V a fim de estabelecer a tensão necessária para representar o

nível lógico “0” em RS-232. O outro inverte a tensão, para suprir o nível capaz de representar a lógica “1”.

4.14. TAXA MÁXIMA DE DADOS

Outra limitação da RS-232 é a sua taxa máxima de dados. A norma define uma taxa máxima de

20Kbits/segundo (20Kbps). Esta taxa é excessivamente baixa para a maioria das aplicações atuais. Alguns

fabricantes criaram componentes capazes de atingir taxas típicas de 250Kbps, podendo chegar a 350Kbps.

Mesmo tendo multiplicado a taxa padrão por quase 20 vezes (350Kbps), estes componentes não atendem

aos requisitos atuais de taxa de transferência.

4.15. COMPRIMENTO MÁXIMO DO CABO

A limitação final a ser discutida refere-se ao comprimento máximo do cabo de comunicação. Como

foi visto na seção CARACTERÍSTICAS ELÉTRICAS. A especificação do comprimento máximo do cabo, incluída

na norma, foi substituída pela especificação da capacitância de carga máxima, que é de 2500pF. Para

determinar o comprimento máximo do cabo, é necessário determinar a capacitância total da linha. A figura

abaixo representa uma maneira aproximada de determinar a capacitância de linha total de um condutor.

Como se verifica no diagrama, a capacitância total é a soma das capacitâncias mútuas dos condutores de

sinal e do condutor Shield (ou capacitância estática no caso de cabo sem Shield).



F igura 22: Capac i tânc ia do Cabo

Como exemplo, vamos assumir que o usuário decidiu usar um cabo sem Shield para interligar os

equipamentos. A capacitância mútua do cabo (Cm) é encontrada na tabela de especificações do cabo.

Vamos assumir 65,62pF por metro. Assumindo que a capacitância do receptor é de 60pF, restaria ao

usuário 2440pF (2500pF – 60pF). A partir da equação representada acima, temos:

Cm = 65,62pF/m

Cs = 0,5 x Cm = 32,81pF/m (cabo sem Shield)

Cc = 65,62pF + 32,81pF = 98,43pF/m

Comprimento do cabo = 2440pF / 98,43pF/m = 24,79m

O valor da carga capacitiva equivalente de um cabo, também designada capacitância shunt é dada

em pF (picofarads) por unidade de comprimento m (metros) / ft (feet) e também faz parte da especificação

de um cabo. Como já foi dito a carga capacitiva é um fator limitante do comprimento total do cabo. Desta

forma os sistemas que necessitarão de longos trechos de cabo, deverão utilizar cabos com baixa

capacitância.



ANOTAÇÕES



5 . COMUNICAÇÃO SERIAL RS-423A (S ing le-ended)

5.1. CARACTERÍSTICAS GERAIS

O padrão RS423 é uma versão aperfeiçoada da norma RS232. A distância de operação foi

estendida para 1Km a uma taxa de 9.600 baud com o uso de receivers de alta sensibilidade. Apesar das

Inovações implementadas, esta norma também foi baseada em uma linha simples, não balanceada, devendo

utilizar como meio um cabo coaxial com malha de blindagem (Shield). Para prevenir a perda de informação

(corrupção de dados), o encaminhamento do cabo deve evitar locais onde fontes de ruído estão presentes.

Terminais e Interfaces RS232 e RS423 podem ser misturados (os dois padrões em uma mesma

linha) para distâncias de até 15m (limite para o padrão RS232).

A utilização do padrão RS423 na indústria não foi tão extensa quanto o padrão RS232, apesar dos

aperfeiçoamentos implementados.

5.2. TABELA COMPARATIVA

Tabe la 2 : Tabe la Comparat iva entre RS-232 e RS-423



ANOTAÇÕES



6 . COMUNICAÇÃO SERIAL RS-422 (D i ferenc ia l )

6.1. INTRODUÇÃO

A transmissão diferencial de dados (sinal diferencial balanceado) oferece uma performance superior

na maioria das aplicações. A linha de transmissão diferencial está sujeita a ruídos e interferências, porém

como o sinal é transmitido através de um cabo do tipo par trançado, a diferença de tensão (entre A e B)

devida a esta interferência é eliminada no estágio de entrada (diferencial) do amplificador do receiver. Esta

mesma proteção funciona para os efeitos de Crosstalk (interferência de outros sinais), assim como qualquer

outra fonte de interferência desde que não sejam excedidos os limites máximos de tensão de entrada do

circuito do receptor. Os sinais diferenciais ajudam a anular os efeitos de diferença nos níveis de aterramento

entre transmissor e receptor (devido a fontes de alimentação diferentes). O cabo do tipo par trançado junto

com as terminações correta, ajudam a eliminar os efeitos de reflexão e permitem transferências de dados

com taxas de até 10Mbps a distâncias de mais de 1Km. Dentre as desvantagens podemos relacionar:

circuitos mais complexos e conseqüentemente mais caros. As altas taxas de dados alcançadas requerem a

utilização correta de terminadores.


O padrão EIA/TIA-422-A foi idealizado para atender às distâncias maiores e operar em taxas de

dados superiores ao padrão RS232. Taxas de até 100Kbs e distâncias de aproximadamente 1,2Km podem

ser alcançadas no padrão RS422. A norma RS422 foi especificada para suportar aplicações em multi-drop,

onde um único driver é conectado em um barramento e transmite dados para até 10 receivers.

Os dispositivos RS422 não podem ser utilizados para construção de uma rede verdadeiramente

multi-ponto. Uma rede multi-ponto consiste de diversos drivers e receivers conectados em um único

barramento onde, qualquer nó pode transmitir ou receber dados.

Redes “quase” multi-drop (à 4 fios) são normalmente construídas com dispositivos RS422. Estas

redes são, geralmente, Half-duplex, onde um único mestre do sistema envia comandos para diversos

escravos. Basicamente um dispositivo (nó) escravo é endereçado por um computador (host), que receberá



a resposta deste dispositivo. Os sistemas do tipo Half-duplex à 4 fios são, normalmente utilizados, para

evitar problemas de colisão de dados em uma rede multi-drop.

Tanto o RS422 quanto o RS485 (como veremos a seguir), utilizam par trançado (2 pares para o

RS422) para transmissão do sinal e os mesmos níveis de tensão. A principal diferença entre eles é que,

enquanto o RS422 se aplica estritamente a comunicações ponto-a-ponto, ou seja, o driver está sempre

habilitado, O RS485 pode ser utilizado em sistemas verdadeiramente multi-drop (seus drivers ficam em tri-

state quando estão inativos).

A norma RS422 recomenda um cabo do tipo par trançado com bitola de 24 AWG, capacitância shunt

de 16pF/ft e impedância característica de 100Ω. A norma RS485 não faz nenhuma recomendação a

respeito do cabo a ser utilizado. No entanto a especificação para a norma RS422 pode ser aplicada à

RS485.

Abaixo é apresentada uma tabela comparativa entre as duas normas (RS423 – single-ended e

RS422 - differential), demonstrando as principais especificações de cada padrão.

6.3. TABELA COMPARATIVA

Tabe la 3 : Tabe la Comparat iva entre RS-423 e RS-422



ANOTAÇÕES



7. COMUNICAÇÃO SERIAL RS-485 (D i ferenc ia l )

7.1. INTRODUÇÃO

Quando se ouve a frase “rede multi-drop”, a RS485 é provavelmente a primeira coisa que vem em

mente. O RS485 foi adotado como um padrão desde 1983 e é utilizado em muitos equipamentos de pontos

de venda (registradoras e leitoras de códigos), assim como na automação industrial (largamente utilizado).

Apesar da aparente simplicidade, ou seja, interligar um par de fios entre cada nó da rede existe diversas

considerações e características cobertas pela norma e que devem ser atendidas para um perfeito

funcionamento de uma rede.

Atualmente a norma RS485 é designada oficialmente como TIA/EIA-485-A. A última revisão ocorreu

em 03 de março de 1988 através da associação da TIA – Telecommunications Industry Association com a

EIA – Electronic Industry Association. Apesar da norma TIA/EIA-485-A ter 17 páginas, ela trata somente das

características dos dispositivos (line drivers e receivers), nada é dito sobre linhas de transmissão e

topologias de rede. Existe um documento, também publicado pela TIA/EIA, designado “Application Guidelines

for TIA/EIA-485-A” que traz uma explanação de como interligar dispositivos definidos para o padrão RS485

em uma rede física.

7.2. CARACTERÍSTICAS

A RS485 é uma rede Multidrop, Half-duplex, ou seja, diversos transmissores e receptores podem

ser interligados em uma mesma linha. Somente um transmissor poderá estar ativo (transmitindo) por vez. A

norma não diz nada a respeito do protocolo a ser utilizado na rede, o usuário tem a liberdade de determinar

o protocolo a ser usado.

A linha de transmissão no padrão RS485 é diferencial por natureza. Existem dois fios – A e B. O

driver gera tensões complementares em A e B. A figura abaixo mostra como o RS485 define as tensões VOA,

VOB e VO. Quando VOA é baixo VOB é alto e vice-versa. Existe a capacidade de se implementar o tri-state para

A e B em algumas aplicações.



F igura 23: Dr iver E IA-RS-485

Como já dito, os sinais A e B são complementares, o que não implica que um seja o retorno do

outro, ou seja, o RS485 não é um loop de corrente. O driver e o receiver devem compartilhar um mesmo

ponto terra, esta é a razão pela qual o termo “two-wire network” (rede a dois fios) é utilizado para o padrão

RS485.

Os receivers são projetados para responder à diferença entre A e B, VO é a tensão diferencial. Os

receivers devem ser sensíveis para determinar uma diferença de tensão de 200mV entre VOA e VOB (tensões

menores que 200mV não são determinadas).

O RS485 é capaz de suportar redes com distâncias de até 1500m e com taxas de até 10Mbps. A

seguir é apresentado um gráfico que demonstra a curva que relaciona a taxa de dados (em bps) com o

comprimento do cabo (em pés / 1 pé = 30,48cm). Este gráfico representa uma expectativa, uma vez que

diversos fatores irão influenciar na performance da rede, tais como: tipo de cabo utilizado, terminação, tipos

de drivers e receivers utilizados, EMI - interferência eletromagnética acoplada ao sistema, geometria física da

rede, etc.



F igura 24: Grá f ico de D is tânc ias para E IA-RS-485

A norma TIA/EIA-485-A define uma unidade de carga, designada UL e estabelece que um driver

deve ser capaz de suportar 32 ULs. Desta forma uma rede RS485 poderia suportar até 32 nós.

Alguns fabricantes desenvolveram e comercializam transceivers com ¼ UL e até 1/8 UL. Assumindo

que cada nó representa uma carga de 1/8 UL para a linha de transmissão, uma rede RS485 compatível

poderia suportar até 256 nós (32 UL x 8 UL/nó).

Com a utilização de repetidores, múltiplas redes podem ser encadeadas para acomodar um número

virtualmente ilimitado de nós. Obviamente o tempo de propagação irá tornar-se significativamente longo nas

redes extensas, (com muitos repetidores e grandes extensões de linhas de transmissão), por este fato, as

taxas de dados poderão tornar-se inaceitáveis (excessivamente baixas).



Alguns drivers são projetados para ter baixos “edge times” (tempos de borda), normalmente em

drivers com slew-rate limitado, como vimos no capítulo sobre RS232, baixos tempos de borda são obtidos a

partir da limitação do slew-rate. Esta limitação impõe, no entanto, uma redução na resposta do dispositivo

para altas freqüências. Por outro lado, longos tempos de borda permitem a utilização de cabos mais

extensos e reduzem a quantidade de EMI emitida pela rede.

7.3. ATERRAMENTO

Um dos pontos mais importantes a serem considerados na construção de uma rede robusta é um

aterramento apropriado. A tensão de modo comum (VCM) é um dos parâmetros mais preocupantes em

relação ao aterramento. A figura abaixo mostra como a tensão VCM é definida.

F igura 25: Tensão entre Dr ivers

A norma TIA/EIA-485-A estabelece que a tensão VCM é a soma da diferença de potencial de terra

(entre driver e receiver), a tensão de offset* do gerador (driver) e a tensão de ruído acoplado

longitudinalmente. A tensão de ruído (Vnoise) é acoplada de forma idêntica em ambos os fios, o que nos leva



a designá-lo como ruído de modo comum. Em redes com cabeamento “twisted pair” (par trançado) é

comum simplificar a tensão de ruído Vnoise como sendo modo comum.

*A tensão de Of fset é resu l tado do uso de trans istores independentes no

estág io d i ferenc ia l de entrada do dr iver , como estes componentes não são idênt icos,

surge na sa ída uma tensão de Of fset mesmo sem s ina l na entrada.

Como visto na figura acima, a diferença de potencial de terra VGPD parece ser a que causa mais

problemas. O aterramento muitas vezes é tratado de forma simplificada como sendo um condutor perfeito

capaz de absorver energia infinita, o que está longe de ser verdade.

Em condições normais, o potencial de aterramento entre dispositivos numa instalação industrial

pode variar de muitos Volts. Estas tensões geralmente provocam uma fuga de corrente do equipamento

para o sistema de aterramento.

Durante a ocorrência de relâmpagos, os potenciais de terra de áreas diferentes podem atingir

momentaneamente tensões da ordem de milhares ou centenas de milhares de Volts.

Estes fatos nos levam a concluir que um aterramento feito de forma individual (cada dispositivo com

seu próprio aterramento no local de instalação) não é uma boa prática, podendo causar danos definitivos

aos dispositivos e influenciar de forma negativa no funcionamento da rede.

O melhor método para controlar a tensão VGPD é utilizar um terceiro fio o qual irá estabelecer uma

referência de aterramento para todos os dispositivos ligados na rede. A figura abaixo (a) exemplifica esta

ligação. Este é o melhor método para controle da tensão VGPD. Um método menos aconselhável, porém muito

utilizado é apresentado no item (b) da figura abaixo. Este método garante uma conexão de alta impedância

entre nós, porém pode acarretar em desvios mais tarde, permitindo níveis mais altos de VGPD, no entanto, se

as fontes locais não estão isoladas ou se os loops de terra são uma preocupação, a ligação (b) pode ser

utilizada como mecanismo de limitação da corrente. A figura abaixo (c) exemplifica ainda, uma ligação onde

cada dispositivo é aterrado (fisicamente), porém são utilizados como em (b) mecanismos de limitação de

corrente (resistor + fusível). Neste caso a tensão VGPD entre nós irá variar de acordo com a variação do

potencial através da instalação da rede.



F igura 26: Re ferênc ia Loca l sem Ru ído

F igura 27: Re ferênc ia Loca l com Poss íve l Ru ído



F igura 28: Re ferênc ia Terra com Proteção a Ru ído

A faixa de tensão VCM entre drivers e receivers em uma rede RS485, é de +12V à -7V.

Outro grave problema é a ocorrência de transientes no circuito de aterramento. Os transientes são

normalmente gerados por ESDs (Electrostatic Discharges) no aterramento próximo a um nó. Raios ocorridos

em regiões próximas (1,5Km) também podem provocar transientes. Sempre que a tensão VCM desvia de sua

faixa permitida (+12V à -7V), o funcionamento dos circuitos fica comprometido. Na verdade os drivers e

receivers poderão ser definitivamente danificados quando a tensão VCM atinge valores fora da faixa

permitida. Para evitar transientes, devem ser utilizados TVSs (Transient Voltage Suppressor). Os TVSs são

mecanismos não destrutivos, baseados em diodos zenners, que bloqueiam altas tensões, podendo dissipar

centenas ou milhares de watts sem se danificarem. MOVs (Metal Oxide Varistors) e fusíveis também podem

ser utilizados, porém com o incoveniente de serem componentes de sacrifício (são danificados para que o

transiente não chegue ao dispositivo).



7.4. BLINDAGEM (SHIELDING)

O cabo com blindagem é recomendado, pois funcionará, virtualmente, para todas as aplicações. É

melhor ter uma rede com cabo blindado e não precisar da blindagem do que ter uma rede sem blindagem e

descobrir que você precisa dela. É importante lembrar, no entanto que o cabo blindado é mais caro e mais

difícil de ser trabalhado, devido à sua espessura e rigidez.

Os receivers RS485 tem uma excelente característica de CMR (Common-Mode Rejection)*. Com o

uso de par trançado e na presença da pior fonte de ruído, a qual induzirá o ruído de forma similar em cada

condutor, pela natureza diferencial dos receivers TIA/EIA-485-A, eles funcionarão bem na presença de

grandes níveis de ruído de modo comum, presentes nos cabos de rede.

*CMR, ou Rejeição de Modo Comum é uma característica dos receivers diferenciais. Na presença de

uma fonte de ruído, os terminais de entrada diferencial seriam afetados por sinais indesejáveis de mesma

fase e amplitude. Esses sinais iriam se sobrepor aos sinais aplicados nas entradas e tenderiam a ser

amplificados e apareceriam na saída do receiver. O CMR é a propriedade que rejeita (atenua) qualquer sinal

de entrada aplicado, simultaneamente, às duas entradas do receiver.

Se o seu cabeamento de rede está protegido por conduites apropriados, ou devidamente

acondicionado em bandejas de encaminhamento, distantes dos sinais AC, a blindagem poderia ser

dispensada. Porém se o cabo de rede passa próximo ou termina em dispositivos RS485 para monitoramento

de máquinas de solda, esteiras de transporte, grandes motores, etc, o cabo blindado se faz necessário.

F igure 29: Cabo b l indado RS-485



7.5. TOPOLOGIA

Na figura abaixo são apresentadas diversas topologias. Somente na topologia “Daisy chain” é

possível gerenciar facilmente as reflexões que ocorrem em cada terminação. Não é impossível implementar

uma rede em estrela, porém seria difícil manter as reflexões sob controle. A topologia Daisy chain é a mais

robusta e confiável para implementar uma rede RS485.

F igura 30: T ipos de Topo log ias

Em cabos muito longos os efeitos de uma linha de transmissão começam a ocorrer. Uma maneira

de determinar se, em um cabo de rede que conecta dois ou mais dispositivos (drivers e receivers), se

aplicará os efeitos de uma linha de transmissão em função do seu comprimento é, determinar se o tempo de

elevação e/ou descida (rise/fall* time) é menor que 4 vezes o tempo de propagação (em um único sentido)

do cabo.



*r ise t ime = tempo necessár io para que um pulso e létr ico se e leve de um

déc imo (10%) para 9 déc imos (90%) de seu va lor tota l .

* fa l l t ime = tempo necessár io para que um pulso e létr ico ca ia de nove déc imos

(90%) para 1 déc imo (10%) de seu va lor tota l .

A maior ia dos cabos de par t rançado tem uma ve loc idade de propagação de

66% ~ 77% de c (c = ve loc idade da luz)

Velocidade de propagação (% de c) é a velocidade na qual um sinal elétrico trafega em um cabo. O

valor dado ou especificado (% de c) deve ser multiplicado pela velocidade da luz (c) para obter-se o valor

final em metros por segundo.

Ex. Um cabo cuja especificação da velocidade de propagação é 78% nos dará a seguinte

velocidade de propagação em m/s: 0,77 x 300 x 106 = 231 x 106 m/s

7.6. TERMINAÇÃO

Assumindo que o cabo de uma rede é longo o bastante para que surjam os efeitos de uma linha

de transmissão, que técnica de terminação deveria ser utilizada para atenuar as reflexões?

Uma rede sem terminação é simples de construir, de baixo custo e seu consumo é reduzido. As

desvantagens, naturalmente, são taxas de dados baixas ou a utilização de um cabo curto para que a rede

opere satisfatoriamente.

A terminação em paralelo oferece excelentes taxas de dados, mas é limitada para redes que

utilizam um único driver. O driver deve estar localizado em uma extremidade da rede e o resistor de

terminação na outra extremidade. O resistor deve ter o mesmo valor da impedância característica (Zo) da

linha de transmissão. Os fabricantes de cabo informam o valor Zo nas especificações dos cabos de rede.

Quanto maior o valor de Zo, menos potência será dissipada na forma de calor pelo resistor Rp (Rp = Zo).

A impedância característica (Ω) é um valor baseado na condutância, resistência, capacitância e

indutância inerentes de um cabo. Este valor representa a impedância de um cabo infinitamente longo, o que



significa dizer que a terminação do cabo com sua impedância dá ao cabo a “aparência” de ser infinitamente

longo, evitando as reflexões para o sinal transmitido.

A terceira técnica de terminação é a bidirecional, a qual oferece uma excelente integridade do

sinal. Com esta técnica os drivers poderão estar em qualquer lugar da rede, a desvantagem é o consumo de

potência. Esta é provavelmente a técnica mais confiável para terminação em redes RS485.

A quarta e última técnica são designadas terminação AC. A idéia é utilizar um capacitor como

elemento de bloqueio do sinal DC para reduzir o consumo de potência.

Na figura abaixo estão representadas as quatro técnicas de terminação citadas:

F igura 31: Terminações



O último assunto relacionado com terminação é o que fazer com os condutores não utilizados em

um cabo de dados (multicabo). Os condutores não usados serão auto-ressonantes e induzirão ruídos nos

cabos de dados. Se eles forem deixados abertos, induzirão toda a sorte de freqüências estranhas. Se eles

forem aterrados em uma extremidade irão ressonar L/2. Se forem aterradas em ambas as extremidades,

irão ressonar L/4.

O melhor método para minimizar os efeitos de energia em um condutor não utilizado é dissipar a

energia na forma de calor. O cabo deverá ser ligado à terra através de um resistor com valor ôhmico igual à

impedância característica da linha.

7.7. POLARIZAÇÃO DO ESTADO INATIVO

A polarização do estado inativo é também conhecida como polarização à prova de falhas. Redes

RS485 com diversos transmissores no mesmo canal de comunicação contam com a capacidade de colocar

os line drivers em tri-state, quando estes não estão transmitindo. Este arranjo permite que os condutores

flutuem (estado instável), o que pode causar uma leitura errada (dados falsos) nos line receivers.

Propositadamente a norma TIA/EIA-485-A reserva a região de tensão diferencial abaixo de 200mV

como estado indefinido.

Para solucionar este problema, são utilizados dois resistores para garantir nível alto em um dos

condutores e nível baixo no outro.

Dependendo da aplicação, seria melhor utilizar uma série de resistores, distribuídos através dos

diversos nós do que somente dois posicionados no final da linha.

Abaixo é apresentada uma tabela comparativa entre as duas normas (RS422 e RS485), demonstrando as

principais especificações de cada padrão.



7.8. TABELA DE ESPECIFICAÇÕES

Tabe la 4 : Comparat ivo entre E IA-RS-485 e E IA-RS-422

Um comparativo entre os dois padrões diferenciais, demonstrando as ligações físicas dos

dispositivos, será representado a seguir.

7.9. COMPARAÇÃO ENTRE OS PADRÕES RS422 E RS485

F igure 32: Comparat ivo entre L igações F ís icas



Finalmente, a seguir, é apresentada a tabela comparativa entre os padrões de comunicação serial

estudados, onde se podem verificar suas especificações e principais características.

7.10. TABELA COMPARATIVA (RS232, RS423, RS422 E RS 485)

Tabe la 5 : Tabe la Comparat iva entre RS-232, RS-423, RS-422 e RS-485



ANOTAÇÕES



8. REDES INDUSTRIA IS

Informação atualmente é a palavra-chave em muitas empresas mundo afora. Não só as que

trabalham diretamente com Informática, mas também as do ramo industrial estão sendo afetadas pelos

avanços nas tecnologias de transmissão de dados. A integração entre os diversos níveis de equipamentos e

sistemas de controle tem se tornado essencial para alcançar-se o aumento de eficiência, flexibilidade e

confiabilidade dos sistemas produtivos.

Tal como nos outros mercados de comunicação de dados (Telefonia, Rádios, Emissoras de

Televisão, Internet, etc), os sistemas de transmissão de dados nas indústrias começaram de forma bastante

simples, utilizando conexões do tipo serial RS-232 e RS-485. Porém, com o passar do tempo, as indústrias

foram desenvolvendo sistemas mais complexos, com tecnologias próprias, protocolos, softwares e

hardwares apropriados para suas necessidades.

Redes industriais são essencialmente sistemas distribuídos, ou seja, diversos elementos trabalham

de forma simultânea a fim de supervisionar e controlar um determinado processo. Tais elementos (sensores,

atuadores, CLP's, CNC's, PC's, etc), necessitam estar interligados e trocando informações de forma rápida e

precisa. Um ambiente industrial é, geralmente, hostil, de maneira que os dispositivos e equipamentos

pertencentes a uma rede industrial devem ser confiáveis, rápidos e robustos. Para implementar-se um

sistema de controle distribuído, baseado em redes, há a necessidade de estudos detalhados acerca do

processo a ser controlado, buscando-se o sistema que melhor se adéqüe às necessidades do usuário.

Os fabricantes de sistemas de integração industrial tendem a lançar produtos compatíveis com sua

arquitetura própria, o que leva a graves problemas de compatibilidade entre as diversas redes e sub-redes

presentes nos sistemas, em diversos níveis, equipamentos, dispositivos, hardware e software.

Essa é a vantagem das arquiteturas de sistemas abertos, que tendem a seguir padrões, de maneira

que o usuário pode encontrar diversas soluções diferentes para o mesmo problema.



F igura 33: D ivers idade de Tecno log ia em In tegração Industr ia l

F igure 34: Camadas de um S is tema de Automação

As redes industriais são padronizadas em 3 níveis hierárquicos responsáveis pela interconexão de

diferentes tipos de equipamentos.



O nível mais alto é geralmente o que interliga os equipamentos responsáveis pelo planejamento da

produção, scheduling, controles de estoque, estatísticas de qualidade, previsões de vendas, etc. Geralmente

é implementado utilizando-se softwares gerenciais, tais como sistemas SAP, Arena, etc. O protocolo TCP/IP,

com padrão ethernet é o mais utilizado nesse nível.

No nível intermediário, onde temos os CLP's e CNC's, principalmente, trafegam informações de

controle em nível de máquinas, ou seja, informações a respeito do status de equipamentos tais como robôs,

máquinas-ferramentais, transportadores, etc.

O terceiro nível, mais baixo, é o que se refere à parte física da rede, onde se localizam os sensores,

atuadores, contatores, etc.

Níveis de Redes Industriais Tipo de Equipamentos em cada Nível da Rede

A classificação das redes industriais é baseada em três níveis.

A divisão é mostrada a seguir.



8.1. REDE SENSORBUS - DADOS NO FORMATO DE BITS

A rede sensorbus conecta equipamentos simples e pequenos diretamente à rede. Os equipamentos

deste tipo de rede necessitam de comunicação rápida em níveis discretos e são tipicamente sensores e

atuadores de baixo custo. Estas redes não almejam cobrir grandes distâncias, sendo sua principal

preocupação manter os custos de conexão tão baixos quanto for possível. Exemplos típicos de rede

sensorbus incluem Seriplex, ASI e INTERBUS Loop.

8.2. REDE DEVICEBUS - DADOS NO FORMATO DE BYTES

A rede devicebus preenche o espaço entre redes sensorbus e fieldbus e pode cobrir distâncias de

até 500 m. Os equipamentos conectados a esta rede terão mais pontos discretos, alguns dados analógicos

ou uma mistura de ambos. Além disso, algumas destas redes permitem a transferência de blocos em uma

menor prioridade comparado aos dados no formato de bytes. Esta rede tem os mesmos requisitos de

transferência rápida de dados da rede de sensorbus, mas consegue gerenciar mais equipamentos e dados.

Alguns exemplos de redes deste tipo são DeviceNet, Smart Distributed System (SDS), Profibus DP, LONWorks

e INTERBUS-S.

8.3. REDE FIELDBUS - DADOS NO FORMATO DE PACOTES DE MENSAGENS

A rede fieldbus interliga os equipamentos de I/O mais inteligentes e pode cobrir distâncias maiores.

Os equipamentos acoplados à rede possuem inteligência para desempenhar funções específicas de

controle tais como loops PID, controle de fluxo de informações e processos. Os tempos de transferência

podem ser longos, mas a rede deve ser capaz de comunicar-se por vários tipos de dados (discreto,

analógico, parâmetros, programas e informações do usuário). Exemplo de redes fieldbus inclui IEC/ISA SP50,

Fieldbus Foundation, Profibus PA e HART.



F igure 35: Camadas Redes Industr ia is



ANOTAÇÕES



9 . REDE AS- i

9.1. INTRODUÇÃO

A rede AS-Interface - Actuator-Sensor-Interface foi inicialmente desenvolvida por um pool de

empresas alemãs e suíças capitaneadas pela Siemens para ser uma alternativa de rede para interligação de

sensores e atuadores discretos. Em 1998 a rede foi padronizada e recebeu o nome EN50295.

Suas principais características são:

F igura 36: Caracter ís t icas da Rede AS- i



F igura 37: Fa ixa de Ap l icação

A rede AS-Interface foi estendida recentemente e diversas novas funcionalidades foram adicionadas.

Os dispositivos compatíveis com a nova norma (3.0) são compatíveis com a norma anterior.

Os chips para a versão 3.0 da rede ASI são produzidos por dois consórcios distintos: Siemens e

Festo desenvolveram em conjunto o chip SAP4 1, pino a pino compatível com o chip SAP4, e o consórcio de

oito outros membros (Bosch, Hirschmann, ifm electronic, Leuze, Lumberg, Klockner Moeller, Pepperl+Fuchs

and Schneider Electric) desenvolveu o chip A2SI. Ambos os chips proporcionam todas as funcionalidades da

versão 2.1.

As novas funcionalidades acrescentadas na versão 2.1 são:

· Ampliação do número de escravos de 31 para 62. A capacidade máxima do Barramento foi ampliada para

248 + 186 I/O, mas o tempo de ciclo passou para 10ms.

· Um bit adicional no registro de status é utilizado para sinalizar erros de periféricos. A indicação de status

de funcionamento dos escravos foi padronizada e ampliada.



· O número de profiles de escravos foi ampliado de 15 para 225 com a adição de novos IDs codes.

· Melhor tratamento de sinais analógicos, ampliando o espectro de atuação das redes AS-i.

9.2. CONECTIVIDADE

A rede AS-i pode se conectar ao nível de controle principal de duas formas. A primeira forma é a

conexão direta. Neste caso, o mestre é parte de um PLC ou PC sendo executado dentro dos tempos de

ciclos determinados por esses dispositivos. Um mestre AS-i pode ser construído por qualquer fabricante uma

vez que se trata de um padrão aberto.

A segunda maneira de se conectar é através de um acoplador entre uma rede de mais alto nível e a

rede ASi. Hoje existem acopladores para as redes de campo mais importantes como: Profibus, Interbus, FIP,

DeviceNet, CAN, etc.

F igura 38: Mane i ras de Conectar a Rede AS- i



9.3. USO DE VARIÁVEIS ANALÓGICAS

Como cada escravo pode enviar apenas 4 bits por ciclo, palavras maiores devem ser divididas e

enviadas em diversos ciclos, até que o envio da mensagem seja completado.

F igura 39: Env io de Va lores Ana lóg icos

Pelo diagrama da figura anterior vimos que são necessários 7 ciclos para completar a transmissão

de um valor analógico de 16 bits. O quarto bit de cada telegrama do master ou escravo é um bit de controle.

Variáveis analógicas de 12 bits são transmitidas em 6 ciclos. Embora a leitura de cada variável analógica

demore 30 ms (6 ciclos de 5ms), todas as variáveis discretas continuam sendo lidas em ciclos de 5ms. Isto

acontece porque na rede AS-i o mestre continua interrogando os escravos a cada 5ms. Para a leitura de

uma analógica 6 ou 7 ciclos serão necessários.

O sistema permite o uso de até 4 variáveis analógicas por escravo.

Na versão 2.1 é possível ter 4 valores analógicos em um escravo, mais 60 escravos binários ou

124 (31*4) valores analógicos, mas nenhum valor binário.



F igura 40: Transmissão de Va lor Ana lóg ico

9.4. DETERMINISMO NO TEMPO

A rede AS-i é uma rede determinística. Como apenas um mestre pode estar presente e o acesso se

dá por polling cíclico, cada dispositivo é endereçado num tempo bem definido. Para uma rede completa de

31 escravos, o tempo de ciclo é de 5 ms. Este tempo será menor se menos escravos estiverem presentes.

Tempos de até 500ms são possíveis. Valores analógicos requerem vários ciclos de barramento,

mas não afetam o tempo de ciclo dos dispositivos.



9.5. ACESSO À CAMADA FÍSICA

É utilizada a modulação por pulsos alternados: Alternating Pulse Modulation (APM).

F igura 41: Modu lação de S ina l da Rede AS- i

Trata-se de um método de codificação em banda base cujas etapas de codificação podem ser

visualizadas na Figura 41. Inicialmente os bits de dados e sinal são codificados em codificação Manchester.

Esta codificação implica em um deslocamento de fase a cada bit transmitido. O sinal é traduzido em corrente

e depois cada subida de corrente irá implicar em um pulso negativo de tensão na rede e cada descida de

corrente em um pulso positivo. No receptor os bits são de novo convertidos em pulsos discretos, sem o uso

de indutores e o sinal é reconstituído.



A taxa bruta de transferência de dados na rede AS-i é de 167Kbps e a taxa líquida é de 53.3Kbps o

que fornece o valor de eficiência de transferência de 32%.

9.6. MENSAGENS AS-I

O ciclo de barramento é formado por quatro fases:

1. Pedido do mestre

2. Pausa do mestre

3. Resposta do escravo

4. Pausa do escravo

O formato de cada frame é mostrado na figura abaixo

F igura 42: Formato da Mensagem AS- i

ST Start bit

SB Control Bit:

0: dado ou parâmetro

1: comando

A4... A0 Endereço do escravo (5 bits)

I4... I0 Informação a ser transferida (5bits)

PB Bit de Paridade par

EB Bit final

Cada bit corresponde a um intervalo de 6ms.



F igura 43: T ipos de Mensagens

9.6.1. Data Exchange

É o tipo mais comum de mensagem. Serve para transferir um padrão de bits para uma saída e no

mesmo comando ler a resposta do escravo.

9.6.2. Write Parameter

Escreve uma palavra de configuração do comportamento do escravo.



9.6.3. Definição do Endereço de um Nó

Para definir um novo endereço de um nodo, dois comandos são necessários:

Delete_Operating_Address – apaga o endereço de um nodo. Isto é necessário porque o nodo deve

possuir o endereço 0 para poder receber um novo endereço Assign_Address

9.6.4. Configuração de I/O

A mensagem Read I/O Configuration é usada para ler a configuração de I/O de um dispositivo. Esta

configuração segue um dos padrões indicados na Figura abaixo.

F igura 44: Conf iguração de I /O

9.6.5. Read ID Code

Serve para ler o código do dispositivo. Este parâmetro é definido durante a fabricação do

componente e não pode ser mais mudado. Ele define o perfil daquele dispositivo.

9.6.6. Read Status

Lê os bits de status do dispositivo. O significado destes bits é:



F igura 45: S ign i f i cado dos B i ts

F igura 46: Exemplo de Conector

F igura 47: Ca ixas de In ter l igação



F igura 48: T ipos de Conexões

As saídas de um sensor podem ser transistores NPN ou PNP coletor aberto. Saídas NPN funcionam

como um dreno de corrente até certo valor limite. Saídas PNP funcionam como uma fonte de corrente. O

sensor NPN ao ser acionado vai jogar a carga (por exemplo, à entrada de um CLP) para a terra, enquanto

que um sensor PNP vai jogar a carga para VCC, em geral 24 VCC.

Em um sensor NPN, nós conectamos o coletor ao CLP e o emissor à terra. Caso se use fonte

diferente para o sensor e o CLP elas devem ter o mesmo terra.

No sensor PNP, nós ligamos o emissor ao VCC da fonte e o coletor à entrada do CLP. Se as fontes

forem diferentes devemos ligar o VCC de ambas. Internamente ao sensor o transistor funciona como uma

chave.



F igura 49: T ipos de Sa ídas

F igura 50: Cabo de In ter l igação



9.7. TOPOLOGIAS

F igura 51: Topo log ias para L iv re Esco lha

9.8. FONTE AS-I

A fonte é responsável também por balancear a rede AS-i. O AS-i é operado como um sistema

simétrico, não aterrado. Para imunidade a ruídos o cabo AS-i precisa ser instalado tão simétrico quanto

possível. Isso é possível através do circuito de balanceamento. A conexão de blindagem deve ser ligada num

ponto apropriado da máquina ou sistema. Apenas esse ponto pode ser conectado à terra do sistema (GND).



F igura 52: Fonte AS- i

9.9. COMPRIMENTO DO CABO

F igura 53: Compr imento do Cabo para Rede AS- i



9.10. BENEFÍCIOS (ECONOMIA)

F igura 54: Economia com o Uso de Uma Rede AS- i



ANOTAÇÕES



10 . HART

10.1. INTRODUÇÃO

O protocolo Hart foi introduzido pela Fisher Rosemount em 1980. Hart é um acrônimo de “Highway

Addressable Remote Transducer”. Em 1990 o protocolo foi aberto à comunidade e um grupo de usuários foi

fundado.

A grande vantagem oferecida por este protocolo é possibilitar o uso de instrumentos inteligentes

em cima dos cabos 4-20 mA tradicionais. Como a velocidade é baixa, os cabos normalmente usados em

instrumentação podem ser mantidos. Os dispositivos capazes de executarem esta comunicação híbrida são

denominados smart.

10.2. O SINAL HART

O sinal Hart é modulado em FSK (Frequency Shift Key) e é sobreposto ao sinal analógico de 4..20

mA. Para transmitir 1 é utilizado um sinal de 1 mA pico a pico na freqüência de 1200 Hz e para transmitir 0

a freqüência de 2200 Hz é utilizada. A comunicação é bidirecional.



F igura 55: S ina l Har t Sobreposto

Este protocolo permite que além do valor da PV outros valores significativos sejam transmitidos

como parâmetros para o instrumento, dados de configuração do dispositivo, dados de calibração e

diagnóstico.

O sinal FSK é contínuo em fase, não impondo nenhuma interferência sobre o sinal analógico. A

padronização obedece ao padrão Bell 202 Frequency Shift Keying.



10.3. TOPOLOGIA

A topologia pode ser ponto a ponto ou multidrop. O protocolo permite o uso de até dois mestres. O

mestre primário é um computador ou CLP ou multiplexador.

O mestre secundário é geralmente representado por terminais handheld de configuração e

calibração.

Deve haver uma resistência de no mínimo 230 ohms entre a fonte de alimentação e o instrumento

para a rede funcionar. O terminal handheld deve ser inserido sempre entre o resistor e o dispositivo de

campo conforme mostrado na figura a seguir.

F igura 56: Conexão com Inst rumento HART

O resistor em série em geral já é parte integral de cartões de entrada de controladores single loop

e cartões de entrada de remotas e, portanto não necessita ser adicionado. Outros dispositivos de medição

são inseridos em série no loop de corrente, o que causa uma queda de tensão em cada dispositivo.

Para a ligação de dispositivos de saída a uma saída analógica, não é necessário um resistor de

shunt.



F igura 57: Conexão com a Sa ída

F igura 58: HART com 2 Mestres

F igura 59: Conf iguradores HART



F igura 60: Ca l ib radores HART

10.4. MODOS DE COMUNICAÇÃO

O protocolo HART pode utilizar diversos modos de comunicação. O modo básico é o mecanismo

mestre-escravo. Cada ciclo de pedido e recebimento de valor dura cerca de 500 ms, o que implica na leitura

de dois valores por segundo.

F igura 61: Conf iguração Mestre Escravo

Na topologia ponto a ponto um segundo mecanismo de transferência de dados é possível. O

instrumento pode enviar de forma autônoma e periódica o valor de uma variável, por exemplo, a PV. No

intervalo entre estes envios o mestre pode executar um ciclo de pergunta e resposta. A taxa de transmissão

neste caso se eleva para 3 ou 4 por segundo. Este modo é denominado burst ou broadcast mode. O mestre



pode enviar uma mensagem para interromper este envio contínuo de mensagens de reply, segundo sua

conveniência.

Cada mensagem pode comunicar o valor de até quatro variáveis. Cada dispositivo HART pode ter

até 256 variáveis.

F igura 62: Ins t rumento em Modo de Comunicação

Quando usando uma topologia do tipo multidrop, a rede HART suporta até 15 instrumentos de

campo. Apenas o modo mestre escravo pode ser utilizado. Neste caso o valor da corrente é mantido no

seu nível mínimo de 4 mA e o valor da PV deve ser lido através de uma mensagem explícita.

F igura 63: HART em Mul t idrop

A grande deficiência da topologia multidrop é que o tempo de ciclo para leitura de cada device é de

cerca de meio segundo podendo alcançar um segundo. Neste caso para 15 dispositivos o tempo será de

7,5 a 15 segundos, o que é muito lento para grande parte das aplicações.



10.5. CABOS

A distância máxima do sinal HART é de cerca de 3000 m com cabo com um par trançado blindado e

de 1500 m com cabo múltiplo com blindagem simples.

Existem barreiras especiais de segurança intrínseca que permitem o tráfego do sinal HART.

Tabe la 6 : D is tânc ia Máx ima de Cabos em HART

O fator mais limitante do comprimento do cabo é sua capacitância. Quanto maior a capacitância e o

número de dispositivos, menor a distância máxima permitida:

Tabe la 7 : D is tânc ia Máx ima do Cabo x Número de Ins t rumentos

10.6. COMANDOS HART

Todos dispositivos HART devem aceitar um repertório mínimo de comandos denominados comandos

universais ou common practice commands. Para cada dispositivo existirão comandos particulares

denominados device specific commands. Os comandos universais asseguram a interoperabilidade entre os

dispositivos de campo.

A Tabela 8 mostra exemplos de comando universais e específicos:



Tabe la 8 : Comandos Un iversa is e Espec í f i cos

10.7. DEVICE DESCRIPTION LANGUAGE

Todo dispositivo HART é acompanhado de um device description (DD) que descreve todos os

parâmetros e funções do dispositivo. O objetivo final é reunir todas as características para que um host

possa comunicar plenamente com os dispositivos, assegurando desta forma, a total interoperabilidade entre

os dispositivos.

10.8. MULTIPLEXADORES

Os multiplexadores fazem parte de todo novo projeto envolvendo redes HART.

Os multiplexadores funcionam como um mestre primário que realiza a leitura de todas as variáveis

de processo e informação de status de todos os transmissores periodicamente, de forma independente do

hospedeiro. O host por sua vez lê as variáveis de processo do multiplexador. O host também pode enviar

comando e estabelecer uma conversação diretamente com um dispositivo de campo. O multiplexador é

essencial quando um dos objetivos do projeto é o controle dos ativos de instrumentação (Instrumentation

Asset Management). Em sistemas antigos onde se deseja implantar esta feature, multiplexadores podem ser

colocados em paralelo com as ligações convencionais para proporcionar a função de diagnóstico contínuo

dos instrumentos.



F igura 64: Exemplo de Mu l t ip lexadores

F igura 65: L igação Convenc iona l com Mul t ip lexador



Na figura acima é ilustrado um uso não convencional do protocolo HART. O instrumento é

programado tal que o sinal de 4...20 mA forneça o valor da variável manipulada, saída do algoritmo PID do

bloco implementado pelo instrumento.

Este sinal é usado para comandar diretamente a válvula. O canal HART é usado para realizar a

supervisão da malha.

A Figura a seguir enfatiza a ligação em série do instrumento e do atuador.

F igura 66: L igação em Ser ie



ANOTAÇÕES



11. DEVICENET

11.1. INTRODUÇÃO

A rede DeviceNet classifica-se como uma rede de dispositivo, sendo utilizada para interligação de

equipamentos de campo, tais como sensores, atuadores, AC/DC drivers e CLPs. Esta rede foi desenvolvida

pela Allen Bradley sobre o protocolo CAN (Controller Area Network) e sua especificação é aberta e

gerenciada pela DeviceNet Foundation. CAN, por sua vez, foi desenvolvida pela empresa Robert Bosch Corp.

Como uma rede digital para a indústria automobilística.

Hoje existem inúmeros fornecedores de chips CAN: Intel, Motorola, Philips/Signetics, NEC, Hitachi e

Siemens.




A figura a seguir ilustra a relação entre CAN e DeviceNet e o stack OSI/ISO:

F igura 68: Dev iceNet e Can - Camadas

Esta rede possui uma linha tronco de onde derivam as drop lines.

A rede DeviceNet permite a conexão de até 64 nos. O mecanismo de comunicação é peer to peer

com prioridade. O esquema de arbitragem é herdado do protocolo CAN e se realiza bit a bit. A transferência

de dados se dá segundo o modelo produtor consumidor.

F igura 69: Ap l icações Dev iceNet



11.2. CARACTERÍSTICAS DO NÍVEL FÍSICO

• Topologia física básica do tipo linha principal com derivações;

• Barramentos separados de par trançado para a distribuição de sinal e de alimentação (24VCC), ambos no

mesmo cabo;

• Inserção e remoção de nós a quente, sem necessidade de desconectar a alimentação da rede;

• Uso de opto acopladores para permitir que dispositivos alimentados externamente possam compartilhar o

cabo do barramento com os dispositivos alimentados pelo barramento;

• Usa terminadores de 121 ohms em cada fim de linha;

• Permite conexão de múltiplas fontes de alimentação;

• As conexões podem ser abertas ou seladas.

F igura 70: Ca ixa de Conexão Aber ta e Se lada



A partir de cada dropline vários dispositivos podem ser ligados em Daisy Chain.

F igure 71: Topo log ia Dev iceNet

As seguintes regras devem ser obedecidas para que o sistema de cabos seja operacional:

• A distância máxima entre qualquer dispositivo em uma derivação ramificada para a linha tronco não pode

ser maior que 6 metros (20 pés).

• A distância entre dois pontos quaisquer na rede não pode exceder a distância máxima dos cabos

permitida para a taxa de comunicação e tipo de cabo utilizado conforme a tabela abaixo. A distância se

refere à distância entre dois dispositivos ou resistores de terminação.

Tabe la 9 : Transmissão e Compr imento de Cabos



F igura 72: Cá lcu lo da Der ivação Cumula t iva

Examinando a figura 72:

O comprimento da derivação cumulativa é:

(4+1+1+4) + 2 + (3+2+3+3) + 3 + 5 + 4 = 35 m.

F igura 73: Cá lcu lo das D is tânc ias Máx imas dos Cabos



Derivação 1: Não é considerada porque seu comprimento é menor que a distância da linha tronco para

o resistor de terminação (1.5 m).

Derivação 2: É considerada, já que 5 > 1,5 + 1,5.

Derivação 3: Não é considerada.

Distância máxima dos cabos = (5 m + 50 m + 12 m) = 67 metros.

Uma outra maneira de se realizar este cálculo seria avaliar a perda de tensão na rede para que a

tensão na entrada de qualquer módulo não seja inferior a 21,6 V.

Para isso calculamos as quedas de tensão em cada cabo considerando a resistência linear típica

dos cabos, as distâncias entre os nodos e as correntes de consumo de cada equipamento. Usando Kircchoff

determinam-se as correntes em cada trecho e por conseqüência as quedas de tensão.

Tipo do cabo Resistividade

Tabe la 10: Res is t iv idade de Cabos Dev iceNet

F igure 74: Função / Cores do Cabo Dev iceNet



F igure 75: T ipos de Cabos Dev iceNet



F igure 76: T ipos de Cabos Dev iceNet 1

F igura 77: Cá lcu lo de Queda de Tensão



11.3. COLOCAÇÃO DA FONTE DE ALIMENTAÇÃO

A colocação da fonte de alimentação também segue uma série de regras. Aqui examinaremos

apenas alguns princípios básicos.

A corrente máxima suportada pela fonte, em um dado segmento, é função do comprimento máximo

do segmento e deve obedecer à tabela abaixo:

Tabe la 11: Compr imento do Segmento da Rede x Corrente Máx ima de Fonte Ún ica

Princípios gerais a serem observados para melhorar o posicionamento da fonte:

• Mover a fonte de alimentação na direção da seção sobrecarregada.

• Mover as cargas de corrente mais alta para mais próximo da fonte.

• Transferir os dispositivos de seções sobrecarregadas para outras seções.

• Diminuir o comprimento dos cabos.

Paul Araújo

Highlight

Paul Araújo

Highlight

Paul Araújo

Highlight



F igura 78: Pos ic ionamento da Fonte de A l imentação

Vamos determinar se a fonte de alimentação está sobrecarregada ou não:

1) Somatório das correntes dos dispositivos da Seção 1:

(1,10 + 1,25 + 0,50) = 2,85

2) Somatório das correntes dos dispositivos da Seção 2:

(0,25 + 0,25 + 0,25) = 0,75

3) O comprimento da seção 1 é de 86 metros. Consultando a tabela para 100 metros verificamos que a

corrente máxima permitida é de 2,93 A.

O comprimento da seção 2 é de 158 metros. Consultando a tabela para 160 metros encontramos

1,89 A.

Logo, toda a rede está operacional.



11.4. DEVICENET ASSISTANT

A Rockwell Automation desenvolveu um aplicativo que facilita a configuração de um barramento

DeviceNet. O software realiza os cálculos necessários para verificação de comprimentos de cabo, corrente,

etc.

F igura 79: Te la do Dev iceNet Ass is tant

11.5. CONTROLE DE ACESSO AO MEIO – CAMADA DLL

Utiliza protocolo CSMA/NBA – Carrier Sense Multiple Access with Non Destructive Bitwise

Arbitration ou CSMA/CD + AMP (Arbitration on Message Priority). Através deste protocolo qualquer nó pode

acessar o barramento quando este se encontra livre. Caso haja contenção, ocorrerá arbitragem bit a bit

baseada na prioridade da mensagem que é função do identificador de pacote de 11 bits.



F igura 80: Quadro de Dados CAN

11.6. ARBITRAGEM

Um nó só inicia o processo de transmissão, quando o meio está livre.

Cada nó inicia um processo de transmissão e escuta o meio para conferir bit a bit se o dado

enviado é igual ao dado recebido. Os bits com um valor dominante sobrescrevem os bits com um valor

recessivo.

F igura 81: Processo de Arb i t ragem



Suponha que os nós 1, 2 e 3 iniciem a transmissão simultaneamente. Todos os nós escrevem e

lêem o mesmo bit do barramento até que o nó 2 tenta escrever um bit recessivo (1) e lê no barramento um

bit dominante (0). Neste momento o nó 2 passa para o modo de leitura. Um pouco mais à frente o mesmo

acontece com o nó 1. Isto significa que o valor do identificador da mensagem 3 tem um menor valor binário

e, portanto uma maior prioridade que as demais mensagens.

Todos os nós respondem com a ACK, dentro do mesmo slot de tempo, se eles receberam a

mensagem corretamente.

11.7. MODELO DE REDE

Utiliza paradigma Produtor/Consumidor que suporta vários modelos de rede

Produtor/Consumidor

O Dado é identificado pelo seu conteúdo. A mensagem não necessita explicitar endereço da fonte e

destino dos dados. Também não existe o conceito de mestre.

Qualquer nó pode iniciar um processo de transmissão. Este modelo permite gerar todos os demais.

11.7.1. Mestre/Escravo

F igura 82: Mestre / Escravo



O PLC ou scanner possui a função de mestre e realiza um polling dos dispositivos escravos. Os

escravos só respondem quando são perguntados. Neste sistema o mestre é fixo e existe apenas um

mestre por rede.

11.7.2. Peer to Peer

F igura 83: Peer to Peer

Redes peer to peer não possuem um mestre fixo. Cada nó tem o direito de gerar mensagens para a

rede, quando de posse de um token. O mecanismo de passagem de token pode ser baseado na posição do

nó no anel lógico ou definido por um mecanismo de prioridades.

11.7.3. Multi-Mestre

F igura 84: Mu l t i – Mestre



Uma mensagem pode alcançar diversos destinatários simultaneamente. Na figura acima a referência

de posição do rack remoto #1 é enviada para o PLC1, PLC2 e para a MMI, ao mesmo tempo.

Numa segunda transação, o comando referência de velocidade é enviado aos três drivers ao

mesmo tempo.

11.7.4. Mudança do Estado do Lado

F igura 85: Mudança do Estado do Lado

Ao invés de termos um mestre realizando a leitura cíclica de cada dado, os dispositivos de campo

enviam os dados ao mestre quando houver variação de um valor em uma variável. Também é possível

configurar uma mensagem de heart beat. O dispositivo envia uma mensagem quando um dado variou ou

quando o sistema ficar sem comunicar por um período de tempo determinado. Desta forma sabemos se o

dispositivo está vivo ou não.

11.7.5. Produção Cíclica de Dados



F igura 86: Produção C íc l i ca de Dados

Os dispositivos de campo atualizam o mestre periodicamente em bases de tempo pré-

estabelecidas. O modo de operação: mudança de estado e produção cíclica são configuráveis nodo a nodo.

Nestes dois últimos tipos de mensagens o consumidor deve enviar uma ACK ao produtor. Para

gerenciar o envio de mensagens de múltiplos consumidores, o ACK handler object deve ser utilizado.

11.8. MENSAGENS

O identificador CAN é utilizado para estabelecer a prioridade do nó no processo de arbitragem e é

usado pelos nodos que recebem a mensagem para filtrar as mensagens do seu interesse.

A rede DeviceNet define dois tipos de mensagens: mensagens de entrada e saída e mensagens

explícitas.

11.8.1. Mensagens de Entrada / Saída

São dados de tempo crítico orientado ao controle. Elas permitem o trânsito de dados entre uma

aplicação produtora e uma ou mais aplicações consumidoras.

As mensagens possuem campo de dados de tamanho de 0 a 8 bytes que não contém nenhum

protocolo, exceto para as mensagens de I/O fragmentado, onde o primeiro byte da mensagem é usado para

o protocolo de fragmentação. O significado de cada mensagem é função do identificador CAN.



Antes que mensagens utilizando este ID possam ser enviadas, tanto o dispositivo emissor quanto o

receptor devem ser configurados.

F igura 87: Ident i f i cador

Quando a mensagem supera os 8 bytes, existe um serviço de fragmentação de mensagens que é

aplicado. Não existe limite no número de fragmentos.

11.8.2. Mensagens explícitas

São utilizadas para transportar dados de configuração e diagnóstico ponto a ponto.

Estas mensagens possuem baixa prioridade. Elas constituem uma comunicação do tipo

pergunta/resposta geralmente utilizada para realizar a configuração de nodos e o diagnóstico de problemas.

O significado de cada mensagem é codificado no campo de dados.

Mensagens explícitas também podem ser fragmentadas.

F igura 88: Quadro de Dados: Fragmentada x Não Fragmentada

A definição do comportamento de um dispositivo inserido na rede é definida pelo Device Profile.

DeviceNet divide os 11 bits do identificador CAN em quatro grupos:



Os três primeiros grupos contêm dois campos, um campo de 6 bits para o MAC ID (6 bits <-> 64

endereços) e o restante para o MESSAGE ID. Os dois campos combinados formam o CONECTION ID.

F igura 89: Grupo de Mensagens Dev iceNet

11.8.3. Predefined Master / Slave Connection Set

Em aplicações Master slave com dispositivos simples, não existe necessidade de configuração

dinâmica de conexões entre os dispositivos. Neste caso pode-se usar um conjunto especial de

identificadores conhecidos como Predefined Master/Slave Connection Set. O tipo e a quantidade de dados a

serem gerados por estes dispositivos simples é conhecido em tempo de configuração.

As mensagens do grupo 2 são utilizadas na definição destes identificadores. Neste grupo, o MAC ID

não é especificado como Source MAC ID, o que possibilita utilizá-lo como Destination ID. O group ID e o MAC

ID estão localizados nos primeiros 8 bits da mensagem o que permite sua filtragem por chips antigos do

protocolo CAN, que só trabalham com 8 bits.

Um mestre, desejando se comunicar com diversos escravos pode pedir emprestado o endereço do

destino da mensagem e usar o campo de MAC ID para este fim.



F igura 90: Mensagens Predef in idas Mestre / Escravo

11.9. O MODELO DE OBJETOS

O modelo de objetos fornece um gabarito e implementa os atr ibutos (dados), serv iços

(métodos ou procedimentos) e comportamentos dos componentes de um produto DeviceNet.

O modelo prevê um endereçamento de cada atributo consistindo de quatro números: o endereço

do nodo (MAC ID), o ident i f i cador da c lasse de objeto, a instânc ia , e o número do atr ibuto.

Estes quatro componentes de endereço são usados com uma mensagem explícita para mover dados de um

lugar para outro numa rede DeviceNet. A tabela a seguir indica o ranges que estes endereços podem

ocupar:



Tabe la 12: Endereços

As classes de objeto são identificadas por um número conforme tabela abaixo:

Tabe la 13: C lasse de Ob je tos

Os principais objetos definidos são:

11.9.1. Objeto Identidade

Cada produto DeviceNet terá uma única instância do objeto identidade. Os atributos serão:



F igura 91: Ins tânc ia de Ob je to Ident idade

11.9.2. Objeto Roteador de Mensagens

Cada produto DeviceNet terá uma única instância do objeto roteador de mensagem (Instância #1).

O componente roteador de mensagens é o componente de um produto que passa mensagens explícitas

para outros objetos. Ele em geral não possui nenhuma visibilidade externa na rede DeviceNet.

11.9.3. Objeto Assembly

Cada produto DeviceNet terá uma única ou múltiplas instâncias do objeto assembly. O propósito

deste objeto é agrupar diferentes atributos (dados) de diferentes objetos de aplicação em um único

atributo que pode ser movimentado com uma mensagem única.

11.9.4. Objetos de Conexão

Cada produto DeviceNet terá tipicamente pelo menos dois objetos de conexão.

Cada objeto de conexão representa um ponto terminal de uma conexão virtual entre dois nodos

numa rede DeviceNet. Uma conexão se chama Explicit Messaging e a outra I/O Messaging.

Mensagens explícitas contêm um endereço do atributo, valores de atributo e código de serviço

descrevendo a ação pretendida.

Mensagens de I/O contêm apenas dados. Numa mensagem de I/O toda a informação sobre o que

fazer com o dado está contido no objeto de conexão associado como a mensagem de I/O.



11.9.5. Objetos de Parametrização

Este objeto é opcional e será usado em dispositivos com parâmetros configuráveis. Deve existir

uma instância para cada parâmetro configurável. Uma ferramenta de configuração necessita apenas

endereçar o objeto de parametrização para acessar todos os parâmetros. Opções de configuração que

são atributos do objeto de parametrização devem incluir: valores, faixas, texto e limites.

11.9.6. Objetos de Aplicação

Todo dispositivo usualmente possui pelo menos um objeto de aplicação. Existem vários objetos de

aplicação padrões na biblioteca de objetos DeviceNet.

F igura 92: Mode lo de Ob je tos Dev iceNet

11.10. ELECTRONIC DATA SHEET (EDS)

Um fornecedor de um instrumento DeviceNet para obter seu certificado de conformidade, deve

fornecer as informações de configuração de um dispositivo de diversas formas:



• Uma folha de dados impressa;

• Uma folha de dados eletrônica (Electronic Data Sheets ou EDS);

• Lista de parâmetro dos objetos;

• Combinação das três alternativas anteriores Electronic Data Sheets são arquivos de especificação

associados a um dispositivo.

Seu objetivo é definir o conjunto de funcionalidades presentes em um dispositivo e permitir uma

rápida configuração dos sistemas computacionais de nível mais alto.

As ferramentas de configuração de alto nível fazem uso destes arquivos para tornar visíveis

informações de produtos de múltiplos fornecedores.

Estes arquivos têm formato ASCII e incluem a descrição de atributos essenciais do instrumento

como: nome, faixas de operação, unidades de engenharia, tipos de dados, etc. Alguns destes atributos

constituem requisitos mínimos para aquela classe de instrumento. Outros são atributos específicos de um

fornecedor.



ANOTAÇÕES



12. MODBUS

12.1. INTRODUÇÃO

O protocolo Modbus foi desenvolvido pela Modicon para comunicar seus PLC’s entre si e com

outros dispositivos em vários tipos de redes. Essas redes incluem as redes industriais Modbus e Modbus

Plus, e redes padronizadas como MAP e Ethernet. Redes são acessadas através de portas lógicas nos

controladores ou por adaptadores de rede, módulos de opção, e gateways.

Como todo protocolo, o Modbus define uma estrutura de mensagem, a qual os controladores

reconhecerão e usarão, independentes do tipo de rede que eles se comunicam. Basicamente, descreve o

processo que o controlador usa para pedir acesso a outro dispositivo, como responderá a pedidos dos

outros dispositivos, como serão descobertos erros e serão informados.

O protocolo Modbus provê o padrão interno que os controladores usam por analisar

gramaticalmente as mensagens e estabelece um formato padronizado para os campos de mensagem.

Durante comunicações em uma rede Modbus, o protocolo define como cada controlador saberá os

endereços dos dispositivos, como irá reconhecer uma mensagem se dirigida a ele, determina o tipo de ação

ser tomada, e extrai quaisquer dados ou outra informação contida na mensagem. Se uma resposta é

requerida, o controlador construirá a mensagem de resposta e a enviará usando o protocolo Modbus.

Em outras redes, mensagens que contêm protocolo Modbus são empacotadas na estrutura de

pacote que está sendo usado na rede. Por exemplo, Controladores de rede Modbus Plus ou MAP, rodando

aplicativos associados a bibliotecas de software e drivers, provêem a conversão entre a mensagem

encapsulada em protocolo Modbus e os protocolos específicos que essas redes usam para comunicar seus

dispositivos.



Esta conversão também pretende solucionar o problema de endereçamento, roteamento, e

métodos específicos de checagem de erro para cada tipo de rede. Por exemplo, endereços de dispositivos

contidos no “pacote” Modbus serão convertidos em endereços de nós de rede antes de transmissão das

mensagens. Os campos de checagem de erro também serão aplicados a pacotes de mensagem, consistente

com o protocolo de cada rede. No destinatário final da mensagem, um CLP, por exemplo, o conteúdo da

mensagem encapsulada, escrito em protocolo Modbus vai definir a ação a ser tomada.

A Figura abaixo mostra como poderiam ser interconectados dispositivos em uma hierarquia de

redes que empregam técnicas de comunicação distintas. Em transações de mensagem, o Modbus encapsula

suas mensagens na estrutura de pacote de cada rede que provê a maneira pela qual os dispositivos podem

trocar dados.

F igura 93: Ap l icação do Protoco lo Modbus



12.1.1. Transações em Redes Modbus

Porta padronizada de comunicação com protocolos Modbus usa a interface serial RS-232C que

define a pinagem dos conectores, cabeamento, níveis de sinal, taxas de transmissão em bauds, e verificação

de paridade. A conexão pode ser feita através de modem além de via rede.

Os controladores se comunicam usando a técnica de mestre-escravo em qual só um dispositivo

(mestre) pode iniciar transações (queries). Os outros dispositivos (escravos) respondem enviando os dados

pedidos pelo mestre, ou executando a ação requisitada. Tipicamente, Mestres típicos são os Processadores

Principais e os Painéis de Programação e os Escravos típicos são PLC’s.

O Mestre pode endereçar suas mensagens a escravos individualmente, ou pode iniciar uma

mensagem broadcast a todos os escravos. Por sua vez, os Escravos devolvem uma mensagem (resposta)

para requisições (queries) que são enviadas a eles individualmente. Não há respostas dos escravos para

mensagens de broadcast.

O protocolo Modbus estabelece o formato para a requisição do mestre colocando no quadro da

mensagem, o endereço do dispositivo (ou broadcast), um código de função que define a ação pedida,

quaisquer dados a serem enviados, e um campo de verificação de erro. A mensagem de resposta do

escravo que também usa protocolo Modbus é montada contendo campos que confirmam a execução da

ação, quaisquer dados a serem devolvidos, e um campo de verificação de erro. Se um erro acontece na

recepção da mensagem, ou se o escravo não puder executar a ação pedida, o próprio escravo construirá

uma mensagem de erro e a enviará como sua resposta.

12.1.2. Transações em Outros Tipos de Redes

Além do protocolo Modbus, alguns modelos de CLP’s podem se comunicar em redes Modbus Plus

que usam portas embutidas ou placas adaptadoras de rede, e em cima de MAP, usando adaptadores de

rede.

Nestas redes, os controladores usam a técnica de comunicação ponto-a-ponto na qual qualquer

controlador pode iniciar transações com os outros controladores. Assim, um controlador pode operar como



um escravo ou como mestre em transações separadas. Freqüentemente são criadas múltiplas rotas internas

para permitir atividade de processamento pelos mestres e transações normais entre escravos.

No nível de mensagem, o protocolo Modbus aplica ainda o princípio de mestre-escravo embora o

método de comunicação de rede seja ponto-a-ponto. Se um controlador originar uma mensagem, este a faz

como sendo um mestre, e espera uma resposta de um escravo. Semelhantemente, quando um controlador

recebe uma mensagem, este constrói uma resposta como sendo de um escravo e a envia para o controlador

de origem.

F igure 94: Arqu i te tura ModBus



12.1.3. O Ciclo de Comunicação

F igura 95: C ic lo de Comunicação entre Mestre e Escravo

A Requisição: O código de função diz ao escravo que tipo de ação deve ser executada. Os bytes de

dados que contêm qualquer informação adicional que o escravo precisará executar a função. Por exemplo, a

função código 03 solicita ao escravo que leia um tipo de registro e responda enviando o conteúdo destes. O

campo de dados contém a informação de que diz ao escravo qual o registro deve iniciar a leitura e quantos

registros deverão ser lidos. O campo de cheque de erro provê um método para o escravo validar a

integridade do conteúdo da mensagem.



F igura 96: Exemplo de Requ is ição de Dados

A Resposta: Se o escravo construir uma resposta normal, o código de função na resposta é um eco

do código de função na questão. Os bytes de dados contêm as informações colhidas pelo escravo, como

valores de registro ou estados. Se um erro acontecer, o código de função é modificado para indicar que a

mensagem é uma resposta de erro, e os bytes de dados contêm um código que descreve o erro. O campo

de cheque de erro permite que o mestre certifique-se que o conteúdo da mensagem é válido.

F igura 97: Exemplo de Resposta de Dados

12.2. OS DOIS MODOS DE TRANSMISSÃO SERIAL



Controladores podem ser configurados para comunicar-se em Redes Modbus utilizando um dos dois

modos de transmissão: ASCII ou RTU. Os próprios usuários selecionam o modo desejado, assim como os

parâmetros de comunicação de porta serial (taxa de bauds, modo de paridade, etc), durante a configuração

de cada controlador. O modo de transmissão e os parâmetros de comunicação devem ser os mesmos para

todos os dispositivos em uma Rede Modbus.

A possibilidade de seleção entre o modo ASCII ou modo RTU é uma característica exclusiva das

Redes Modbus. Define o conteúdo em bits dos campos de mensagem transmitido serialmente nessas redes.

Isso determina como serão empacotadas as informações nos campos de mensagem e como serão

decodificadas.

Em outras redes, como MAP e Modbus Plus, mensagens Modbus são colocadas em frames que não

são relacionados à transmissão serial. Por exemplo, um pedido para ler um registro pode ser controlado por

dois PLC’s em Modbus Plus sem levar em conta a configuração da porta serial Modbus de qualquer um dos

dois PLC’s.

12.2.1. Modo ASCII

Quando os controladores são configurados para comunicar em uma rede Modbus que usa o modo

ASCII, cada byte de 8 bits em uma mensagem é enviado como dois caracteres ASCII. A vantagem principal

deste modo é que permite intervalos de tempo de até um segundo entre caracteres sem causar um erro. O

formato para cada byte em modo ASCII é:

Sistema codificado:

Hexadecimal caráter ASCII [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F].

Cada caractere hexadecimal está contido em um caractere ASCII da mensagem.

Bits por Byte:

1 start-bit

7 bits de dados, LSB enviado primeiro

1 bit de paridade; nenhum bit se nenhuma paridade



1 stop-bit, em caso de haver paridade; 2 bits se nenhuma paridade foi usada

Campo de Checagem de Erro:

Longitudinal Redundancy Check (LRC)

12.2.2. Modo RTU

Quando os controladores são configurados para comunicar em uma Rede Modbus que usa o modo

RTU (Unidade Terminal Remota), cada byte de 8-bits em uma mensagem contém dois caracteres de 4 bits

em hexadecimal. A vantagem principal deste modo é que possui uma densidade maior de caracteres que

permite uma fluidez de dados melhor que o ASCII para a mesma taxa de bauds. Cada mensagem deve ser

transmitida em um fluxo continuo. O formato para cada byte em modo de RTU é:

Sistema codificando:

8 Bits binários, Hexadecimal [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F].

Dois caracteres em hexadecimal contidos em cada campo de 8 bits da mensagem

Bits por Byte:

1 start-bit

8 bits de dados, LSB enviado primeiro

1 bit de paridade; nenhum bit se nenhuma paridade

1 stop-bit, em caso de haver paridade; 2 bits se nenhuma paridade foi usada

Campo de Verificação de Erro:

Cyclical Redundancy Check (CRC)

12.2. FRAME DE MENSAGEM



Em qualquer um dos dois modos de transmissão serial (ASCII ou RTU), uma mensagem Modbus é

colocada, pelo dispositivo a transmitir, em um “quadro” que possui um início e um final conhecido. Isto

permite que os dispositivos receptores no início da mensagem leiam o endereço e determinem a qual

dispositivo é endereçado (ou todos os dispositivos, se a mensagem é de broadcast), e saber quando a

mensagem está completa. Podem ser detectadas mensagens parciais assim como fixar erros.

Em redes como MAP ou Modbus Plus, o protocolo de rede gerencia o empacotamento de

mensagens, com delimitadores de início e fim, específicos para cada rede. Esses protocolos também

controlam a entrega ao dispositivo de destino, fazendo o endereçamento Modbus encapsulado no protocolo

da rede desnecessário para esta transmissão. (O endereço Modbus é convertido em um endereço de rede e

roteados pelo controlador de origem ou pelo seu adaptador de rede).

F igura 98: Exemplo de Frame Modbus

12.3.1. Frame ASCII



No modo ASCII, as mensagens começam com o caractere de “dois pontos” (“:”), “3Ah" em ASCII, e

termina com um ”Carriage Return – Line Feed” (CRLF), “0D0Ah” em ASCII.

Os caracteres permitidos para transmissão para todos os outros campos são hexadecimais [0, 1, 2,

3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F]. Dispositivos de rede monitoram o barramento da rede continuamente

para o caracter “:”. Quando é recebido, cada dispositivo decodifica o próximo campo (endereço) para

descobrir se é o dispositivo de destino.

Intervalos de até um segundo podem acontecer entre caracteres dentro da mensagem. Se um

intervalo maior acontecer, o dispositivo receptor assume a ocorrência de um erro. A Figura a seguir mostra

um frame de mensagem típico.

F igura 99: Frame de Mensagem ASCI I

12.3.2. Frame RTU

Em modo RTU, mensagens começam com um intervalo silencioso de pelo menos 3,5 tempos de

caractere. Isto é implementado facilmente como um múltiplo de tempo de caractere na taxa de bauds

adotada na rede (mostrado como T1-T2-T3-T4 na figura a seguir). O próximo campo transmitido é o

endereço do dispositivo.

Os caracteres permitidos para transmissão em todos os campos são hexadecimais [0, 1, 2, 3, 4, 5,

6, 7, 8, 9, A, B, C, D, E, F]. Dispositivos de rede monitoram o barramento continuamente, até encontrarem o

intervalo de silêncio. Quando o primeiro campo (endereço) é recebido, cada dispositivo o decodifica para

descobrir se é “com ele que estão falando”.



F igura 100: D iagrama de At iv idade de L inha para Seqüênc ia T íp ica Modbus

Após o último caractere transmitido, um intervalo de silêncio semelhante ao de início, de pelo

menos 3,5 tempos de caractere, marca o fim da mensagem. Uma mensagem nova pode começar depois

deste intervalo. O frame inteiro da mensagem deve ser transmitido de maneira contínuo. Se um intervalo

silencioso de mais de 1.5 tempos de caractere acontecer antes de conclusão da mensagem, o dispositivo

receptor descarta a mensagem incompleta e assume que o próximo byte será o campo de endereço de uma

mensagem nova.

Semelhantemente, se uma mensagem nova começa antes do intervalo de 3,5 caracteres, o

dispositivo receptor considerará como continuação da mensagem anterior. Esta situação fixará um erro,

fazendo com que o valor no campo de CRC final não seja válido para as mensagens “superpostas”. O frame

típico de mensagem RTU é mostrado a seguir.

F igura 101: Frame de Mensagem RTU

12.3.3. Controle de Endereçamento



O campo de endereço no frame de mensagem contém dois caracteres (ASCII) ou oito bits (RTU).

Endereços de dispositivo de escravo válidos estão na gama de “0” a “247” decimal. Qualquer dispositivo

escravo individual pode receber um endereço de “1” a “247”, pois o endereço “0” é utilizado para

mensagens de broadcast. Um mestre se dirige a um escravo colocando o endereço deste escravo no campo

de endereçamento da mensagem. Quando o escravo enviar sua resposta, este coloca seu próprio endereço

no campo de endereçamento afim de que o mestre identifique qual escravo está respondendo.

Como a comunicação é feita ponto-a-ponto, não há necessidade da identificação do mestre no

frame de mensagem, até porque os escravos apenas respondem a solicitações do mestre.

Quando o protocolo Modbus for usado em redes de nível mais altas, a comunicação broadcast pode

não ser permitida ou pode ser substituída por outros métodos. Por exemplo, o Modbus Plus usa um banco

de dados global compartilhado que pode ser atualizado com cada ciclo do token.

12.3.4. Campo de Função

O campo de código de função no frame de mensagem contém dois caracteres (ASCII) ou oito bits

(RTU). Os Códigos válidos estão na gama de “1” a “255” decimal. A aplicabilidade de cada função específica

está vinculada ao modelo e tipo do controlador, alguns códigos foram reservados para uso futuro.

Quando uma mensagem é enviada de um mestre para um escravo, o campo de código de função

fala para o escravo que tipo de ação deve executar. Por exemplo, ler os estados de ON/OFF de um grupo de

variáveis discretos ou entradas; ler o conteúdo de dados de um grupo de registros; ler o diagnóstico do

escravo; escrever valores em variáveis discretas ou registros; ou permitir carregar, gravar, ou verificar o

programa dentro do escravo.

Quando o escravo responder ao mestre, usa o campo de código de função para indicar uma

resposta normal (isenta de erro) ou que algum tipo de erro aconteceu (resposta de exceção). Para uma

resposta normal, o escravo simplesmente repete o código de função original. Para uma resposta de

exceção, o escravo devolve um código que é equivalente ao código de função original com seu bit mais

significante fixado em nível alto.



Por exemplo, uma mensagem de mestre para escravo, para ler um grupo de registros teria o

código de função seguinte:

0000 0011 (03h)

Se o escravo executar a em ação pedida sem erro, devolve o mesmo código em sua resposta. Se uma

exceção acontecer, devolve:

1000 0011 (83h)

Além da modificação do código de função para uma resposta de exceção, o escravo coloca um

código específico no campo de dados da mensagem de resposta. Isto fala para o mestre que tipo de erro

aconteceu, ou a razão para a exceção.

O programa aplicativo do mestre tem a responsabilidade de controlar respostas de exceção.

Tipicamente, tenta-se re-enviar a mensagem seguidamente, solicitar informações de diagnóstico ao escravo,

e notificar os operadores.



F igure 102: Funções Bás icas ModBus

12.3.5. Campo de Dados

O campo de dados é construído usando combinações de dois dígitos em hexadecimal, na gama de

“00h” a “FFh”. Estes podem ser representados por um par de caracteres ASCII, ou por um caractere RTU,

de acordo com o modo de transmissão serial da rede.

O campo de dados enviado de um mestre para escravos contém informações adicionais que o

escravo tem que usar para executar a definida pelo código de função. Isto inclui endereços de registros e

variáveis discretas, a quantidade de itens serem controlados, e a contagem de bytes de dados do campo.

Por exemplo, se o mestre pede para um escravo que leia um grupo de registros (função código

“03h”), o campo de dados especifica o início do registro e quantos registros serão lidos. Se o mestre

escreve em um grupo de registros no escravo (código de função “10h”), o campo de dados especifica o

registro de início, quantos registros serão escritos a contagem de bytes do campo de dados, e os dados a

serem escritos nos registros.



Se nenhum erro acontecer, o campo de dados de uma resposta de um escravo para um mestre

contém os dados pedidos. Se um erro acontecer, o campo contém um código de exceção a fim de que a

aplicação que estiver rodando no mestre possa usar para determinar a próxima ação a ser executada.

O campo de dados pode ser inexistente (sem dados) em certos tipos de mensagens. Por exemplo,

em um pedido do mestre para um escravo responder com seu registro de eventos de comunicações (função

código “0Bh”), o escravo não requer informação adicional. O código de função especifica a ação por si só.

12.3.6. Campo de Verificação de Erros

Nas redes Modbus, são usados dois métodos de checagem de erro. O conteúdo do campo de

verificação de erros depende do método que está sendo usado.

Para o modo ASCII, o campo de verificação de erros contém dois caracteres ASCII. “Os caracteres

de checagem de erro são o resultado de um Cheque de Redundância Longitudinal (LRC), cálculo que é

executado no conteúdo da mensagem, excluindo-se o caractere de início” e o caractere de término (CRLF).

Os caracteres de LRC são colocados na mensagem no último campo imediatamente anterior ao CRLF.

Para o modo RTU, o campo de verificação de erros contém uma informação de 16 bits

implementados como dois bytes (8-bits). O valor da checagem de erro é o resultado de um cálculo de

Cheque de Redundância Cíclico (CRC) executado no conteúdo da mensagem. O campo de CRC é posicionado

como o último campo na mensagem. No final, o byte de mais baixa ordem do campo passa a ser o primeiro,

seguido pelo byte de mais alta ordem, que é o último byte a ser enviado na mensagem.

12.3.7. A Transmissão Serial de Caracteres

As mensagens Modbus transmitidas através de redes seriais, cada caractere ou byte é enviado na

ordem descrita a seguir (da esquerda para a direita):

Bit Menos Significativo (LSB) → Bit Mais Significativo (MSB)



F igura 103: Sequênc ia de B i ts em Modo ASC I I

F igura 104: Sequênc ia de B i ts em Modo RTU

12.3. MÉTODO DE VERIFICAÇÃO DE ERROS

Redes Seriais Modbus usam dois tipos de verificação de erros. A verificação de paridade (par ou

ímpar), opcionalmente, pode ser aplicada a cada caractere. A verificação do frame (LRC ou CRC) é aplicada à

mensagem inteira. Todas essas são geradas pelo dispositivo mestre e aplicadas ao conteúdo da mensagem

antes da transmissão. O escravo confere cada caractere e o frame da mensagem inteira durante o

recebimento.

O mestre é configurado pelo usuário para esperar por um intervalo de tempo predeterminado antes

de abortar a transação (timeout). Este intervalo é fixado para ser longo o suficiente para qualquer escravo

poder responder normalmente. Se o escravo descobrir um erro de transmissão, a mensagem não será



executada. Neste caso, o escravo não enviará uma resposta ao mestre. Assim o intervalo expirará e

permitirá que o programa do mestre faça o controle do erro. Uma mensagem direcionada a um escravo

inexistente na rede, provocará também um timeout.

Outras redes como MAP ou Modbus Plus utilizam a verificação de frame em um nível acima do

Modbus. Nessas redes, o campo LRC ou CRC da mensagem Modbus não são aplicáveis. No caso de um erro

de transmissão, os protocolos de comunicação específicos dessas redes notificam o dispositivo de origem

que um erro ocorreu, e de acordo com sua configuração, permite que este retransmita ou aborte o

processo. Se a mensagem é entregue, mas o dispositivo de escravo não pode responder, um erro de

timeout pode acontecer e ser detectado pelo programa do mestre.

12.4.1. Verificação de Paridade

Os próprios usuários podem configurar os controladores para controlar paridade par ou ímpar ou

para não verificar paridade. Assim, determinar-se-á como o bit de paridade será fixado em cada caractere.

Tanto para paridade par ou ímpar, a quantidade de bits “1” será contada na parte de dados de cada

caractere (sete bits para modo ASCII, ou oito para RTU). O bit de paridade será fixado então a um “0” ou

“1” para resultar em um total par ou ímpar de bits em nível alto (“1”).

Por exemplo, estes oito bits de dados estão contidos em um frame de caracteres RTU:

1100 0101

A quantidade total de bits “1” no frame é quatro. Se a paridade é par estiver sendo usada, o bit de

paridade da armação será “0”, para que a quantidade total de bits “1” permaneça par (4). Já para o caso

dede paridade ímpar, o bit de paridade será um “1”, para que o total de bits “1” resulte em um número

ímpar, no caso 5.

Quando a mensagem é transmitida, o bit de paridade é calculado e adicionado ao frame de cada

caractere. O dispositivo receptor conta a quantidade de bits “1” e indica um erro se eles não

corresponderem ao configurado para aquele dispositivo. Todos os dispositivos de uma rede Modbus devem

usar o mesmo método de verificação de paridade.



É importante notar que a verificação de paridade pode detectar um erro, apenas se um número

ímpar de bits foram “invertidos” durante transmissão. Por exemplo, se a verificação de paridade ímpar

estiver sendo empregada, e dois bits “1” são invertidos, de um caractere que contém três bits “1”, o

resultado ainda é um número ímpar de bits “1”.

Caso a verificação de paridade não esteja sendo executada, nenhum bit de paridade é transmitido.

Nesse caso, um stop-bit adicional é transmitido para preencher o frame do caractere.

12.4.2. Verificação de LRC

No modo ASCII, as mensagens incluem um campo de verificação de erro que é baseado no método

de Cheque de Redundância Longitudinal (LRC). O campo de LRC confere o conteúdo da mensagem, exceto o

bit inicial e último par CRLF. É aplicado independente de qualquer método de cheque de paridade usado

para os caracteres individuais da mensagem.

O campo de LRC contém um valor binário de 8 bits. O valor de LRC é calculado pelo dispositivo

transmissor que o adiciona à mensagem. O dispositivo receptor calcula o LRC durante o recebimento da

mensagem e compara o valor calculado com o valor que recebeu no campo de LRC. Se os dois valores não

forem iguais, é acusado um erro. O LRC é calculado somando-se sucessivamente os bytes (8 bits) da

mensagem, descartando as portadoras. Em lógica ladder, a função de checksum (“CKSM”) calcula um LRC

dos conteúdos de mensagem.

12.4.3. Verificação de CRC

No modo RTU, as mensagens incluem um campo de verificação de erro que está baseado no

método de Cheque de Redundância Cíclico (CRC). O campo de CRC verifica o conteúdo da mensagem inteira.

É aplicado independentemente de qualquer método de verificação de paridade usado para os caracteres

individuais da mensagem.

O campo de CRC é composto por dois bytes, contendo um valor binário de 16 bits. O valor de CRC é

calculado pelo dispositivo transmissor que adiciona este campo à mensagem. O dispositivo receptor

recalcula o CRC durante o recebimento da mensagem, e compara o valor calculado ao valor que recebeu no

campo de CRC. Se os dois valores não forem iguais, resulta em erro.



O CRC começa colocando os primeiros 16 bits do registro em nível alto (“1”). Inicia-se um processo

que atribui sucessivamente 8 bits da mensagem aos conteúdos atuais do registro. Somente os oito bits de

dados em cada caractere são usados para gerar o CRC. Start-bits, Stop-bits, e bits de paridade, não se

aplica ao CRC.

Durante geração do CRC, é executada uma operação de OU EXCLUSIVO de cada caractere de 8 bits

com os conteúdos de registro. O resultado é “deslocado” na direção do bit menos significativo (LSB),

preenchendo com um zero na posição do bit mais significativo (MSB). O LSB é extraído e é examinado. Se o

LSB for “1”, faz-se-á uma operação OU EXCLUSIVO do registro com um valor pré-definido. Caso o LSB fosse

“0”, não se faz a operação de OU EXCLUSIVO.

Este processo se repete até que sejam executados oito “deslocamentos”. Depois do oitavo, os

próximos 8 bits sofrem uma operação OU EXCLUSIVO com o valor atual do registro, e o processo se repete

para mais oito deslocamentos como descrito acima. Depois de aplicar a todos os bytes da mensagem, o

conteúdo final dos registros, é o valor de CRC. Quando o campo de CRC é agregado à mensagem, o byte de

mais baixa ordem passa a ser o primeiro seguido pelo byte de mais alta ordem.



F igura 105: D iagrama de Estado da Ver i f i cação CRC



ANOTAÇÕES



13. PROFIBUS

13.1. INTRODUÇÃO

Profibus é hoje um dos standards de rede mais empregados no mundo. Esta rede foi concebida a

partir de 1987 em uma iniciativa conjunta de fabricantes, usuários e do governo alemão. A rede está

padronizada através da norma DIN 19245 incorporada na norma europea Cenelec EN 50170.

F igure 106: Topo log ia T íp ica de Redes Pro f ibus



F igura 107: Ap l icação da Rede Pro f ibus

A rede Profibus é na verdade uma família de três redes ou communication profiles no jargão

Profibus.

13.2. PROFIBUS DP (DISTRIBUTED PERIPHERALS)

Esta rede é especializada na comunicação entre sistemas de automação e periféricos distribuídos.

13.3. PROFINET

É uma rede de grande capacidade para comunicação de dispositivos inteligente tais como

computadores, CLPs ou outros sistemas inteligentes que impõem alta demanda de transmissão de dados. A

comunicação percorre o meio físico Ethernet TCP/IP.

13.4. PROFIBUS PA (PROCESS AUTOMATION)



É uma rede para a interligação de instrumentos analógicos de campo tais como transmissores de

pressão, vazão, temperatura, etc. Esta rede possui uma grande fatia do mercado de barramentos de campo

geralmente chamados de fieldbus.



Profibus é uma rede multi-mestres. A especificação fieldbus distingue dois tipos de dispositivos:

D ispos i t ivos Mestres:

Um mestre é capaz de enviar mensagem independente de solicitações externas quando tiver a

posse do token. São também chamados de estações ativas.

D ispos i t ivos Escravos:



Não possuem direito de acesso ao barramento e podem apenas confirmar o recebimento de

mensagens ou responder a uma mensagem enviada por um mestre. São também chamadas de estações

passivas. Sua implementação é mais simples e barata que a dos mestres.

13.6. CARACTERÍSTICAS DO NÍVEL FÍSICO

Existem atualmente três physical profiles que definem os métodos de transmissão disponíveis para o

Profibus:

- RS-485 para aplicações gerais da automação da manufatura.

- IEC 1158-2 para uso na automação de processos.

- Fibra ótica para maior imunidade a ruído e maiores distâncias.

A Prof ibus sobre uma rede Ethernet 10Mbps ou 100 Mbps, des ignada PROFINET

F igura 109: Arqu i te tura dos Protoco los Pro f ibus



O protocolo DP utiliza as camadas 1 e 2 e a camada de usuário. Esta arquitetura otimizada

assegura uma transmissão de dados eficiente e rápida. A suíte Profinet possui apenas as camadas 1, 2 e 7.

A camada 7 corresponde a Profinet (Fieldbus Message Specification (FMS)).

13.7. PROFIBUS PA

F igura 110: Topo log ia da Rede Pro f ibus PA

A rede Fieldbus PA é uma rede para interligar válvulas, transmissores de pressão diferencial, etc.,

portanto geralmente dispositivos escravos. A alimentação dos dispositivos pode se dar pela própria rede.

Caso se deseje interligar esta rede de baixa velocidade a uma rede de alta velocidade (DP) ou a um CLP,

deve-se utilizar um acoplador.

O protocolo é muito simples, o que facilita a interoperabilidade.

A distribuição do controle depende sempre de um mestre externo. O mestre deve ler as PVs dos

transmissores, executar os algoritmos de controle e definira abertura da válvula de controle.



A Profibus PA permite ligar 32 dispositivos por segmento sem segurança intrínseca (IS) ou até 9

dispositivos com segurança intrínseca Ex ia/ib IIC ou até 23 dispositivos com segurança intrínseca Ex ia/ib

IIB.

Os dispositivos podem ser conectados e desconectados para manutenção com a rede em operação,

mesmo quando operando em áreas classificadas.

F igure 111: Dados Padrão Pro f ibus PA



F igura 112: Conectores Pro f ibus PA, Ca ixa de Junção e Acop lador

13.7.1. IEC 1158-2

A rede Profibus-PA obedece ao padrão IEC 1158-2 que utiliza como meio de transmissão um par

trançado blindado, e apresenta a velocidade de 31.25 kbit/s.

Este padrão de nível físico é o mesmo da rede H1 da Foundation Fieldbus.

Ele permite alimentar os dispositivos diretamente, usando o barramento de dois fios e apresenta

segurança intrínseca. Esta rede pode ser usada em áreas classificadas e atende ao modelo FISCO (Fieldbus

Intrinsically Safe Concept) definido pelo Federal Physical Technical Institute da Alemanha.

Os princípios fundamentais são:

- Cada segmento deve ter uma única fonte de potência: a fonte de alimentação.

- Nenhuma potência é alimentada no barramento quando a estação está enviando dados.

- Cada dispositivo de campo consume uma potência fixa conhecida em regime.



- Os dispositivos de campo funcionam como consumidores passivos de corrente.

- A terminação passiva de linha é realizada nos dois extremos da linha.

- Topologias linear, árvore e estrela são permitidas.

O consumo de corrente em regime permanente é de 10 mA. O nó que envia dados deve sobrepor

uma modulação de +/- 9 mA à corrente básica.

A Figura a seguir tem uma demonstração do sinal Profibus baseado na codificação Manchester Bi-

Fase L e em seguida tipos de ruídos encontrados em sinais Profibus

F igura 112: N íve l de S ina l na Rede Pro f ibus – PA



F igure 113: T ipos de Ru ídos no s ina l Pro f ibus



F igura 114: A l imentação de Ins t rumentos de Campo

13.7.2. Topologias

F igura 115: Topo log ia da Rede Pro f ibus



Profibus-PA & FF (H1)

Daisy Chain a <= 1900m

T-plug IP66 dependendo do número de derivações

Bus b <=120m

Tree Caixa de Junção

b <=120m

Em aplicações de segurança intrínseca uma drop line (stub ou spur em inglês, ou spur em alemão)

não pode ser maior que 30m.

Para se determinar o comprimento máximo da linha, uma série de fatores devem ser analisados,

mas uma regra básica seria calcular a potência necessária a cada dispositivo a ser conectado e a

classificação da área de processo. As tabelas 1 e 2 são usadas para este cálculo.

Tabe la 14: Fontes de A l imentação Padrão para Transmissão

Tipo Aplicação Tensão

Alimentação

Corrente

Máxima

Potência

Máxima

Número

Estações

I Ex ia/ib IIC 13,5 V 110 mA 1,8 W 9

II Ex ib IIC 13,5 V 110 mA 1,8 W 9

III Ex ib IIB 13,5 V 250 mA 1,8 W 23

IV Não Classificada 24,0 V 250 mA 1,8 W 32

A tabela acima supõe que cada dispositivo irá consumir no máximo 10 mA.

Tabe la 15: Compr imento Máx imo do Cabo para Transmissão

Fonte Alimentação Tipo I Tipo II Tipo III Tipo IV Tipo IV Tipo IV

Tensão de Alimentação V 13,5 13,5 13,5 24,0 24,0 24,0

Necessidade Potência mA <= 110 <= 110 <= 250 <= 110 <= 250 <= 500

Comp. Total Cabo 0,8mm2 m <= 900 <= 900 <= 400 <=1900 <=1300 <= 650

Comp. Total Cabo 1,5mm2 m <=1000 <=1500 <= 500 <=1900 <=1900 <=1900



F igure 116: Comparat ivo entre Cabos Pro f ibus

F igure 117: Caracter ís t ica do Cabo A (Roxo) Pro f ibus PA

13.7.3. Blocos de funções PA

O profile PA suporta a intercambialidade e interoperabilidade de dispositivos de campo PA de

diferentes fornecedores.



As funções parâmetros de cada dispositivo são descritas através modelo de blocos de função. Os

parâmetros de entrada e saída dos blocos de função são utilizados diretamente pelas aplicações.

Principais blocos de função:

F igura 118: B locos de Função

F igure 119: Est ru tura dos B locos de Função



13.7.4 Exemplo: Parâmetros do bloco de função AI

F igura 120: Exemplos de Parâmetros do B loco de Função

F igura 121: Parâmetros de um Inst rumento no Pro f i le PA



13.8. PROFIBUS DP

É uma rede de alta velocidade e multi mestres utilizando o padrão RS 485.

Os mestres podem ser de duas categorias:

C lasse 1: são mestres que realizam comunicações cíclicas tais como CLPs.

C lasse 2: São mestres que trabalham com mensagens assíncronas como estações de operação e de

configuração.

A rede Profibus DP permite a conexão de até 32 dispositivos por segmento, até o máximo de 4

segmentos, através de 3 repetidores. O número máximo de nós deve ser 126. A distância máxima é de 1.2

km utilizando interface RS- 485. A rede pode ser estendida com repetidores até 15 km com fibra ótica.

A rede é terminada por um terminador ativo no começo e fim de cada segmento. Ambos os

terminadores devem ser alimentados.

F i gure 121: C l asse de Mest res Rede Pro f ibus DP



F igure 122: T ipos de Pro f ibus DP

13.8.1. Velocidade da Rede

A velocidade da rede é única e é determinada pelo escravo mais lento. Hoje a velocidade máxima da

rede Profibus DP é 12 Mbps. A velocidade default é de 1.5 Mbps.

A velocidade de transmissão irá depender do comprimento do cabo no segmento:

Tabe la 16: Taxa de Transmissão e d is tânc ia entre cabeamentos .



É importante ressaltar também, que os cabos de comunicação da rede devem manter uma certa

distância de fontes que possam causar qualquer tipo de interferência no sinal. Além de mantê-los separados,

é aconselhável utilizar bandejamentos ou calhas metálicas fechadas e aterradas, observando as distâncias

acima descritas

F igure 123: S ina l Pro f ibus DP



F igura 124: Conectores Pro f ibus-DP

F igure 125: Comparat ivo entre Cabos Pro f ibus



Os dispositivos mais comuns nesta rede são:

- Computadores;

- Drivers AC e DC (acionamentos);

- Sensores e Atuadores;

- Controladores Programáveis, entre outros.

13.8.2. Tempo de Ciclo

O tempo de ciclo desta rede é função da velocidade da rede, que por sua vez é função da distância

máxima e do número de nodos da rede.

F igura 127: Per formance da Rede Pro f ibus DP

F igure 126: Cabo A Pro fi bus DP



13.8.3. Topologias

F igure 128: Exemplo de l igação Pro f ibus DP

F igura 129: Topo log ias para Rede Pro f ibus

Daisy Chain a<= 1200m

Bus T-Plug IP 40

b<= 500 m



13.8.4. Uso de Fibra Ótica

F igura 130: Rede Pro f ibus em Ane l F ibra ó t ica

Fibra ótica pode ser utilizada para aumentar a imunidade ao ruído ou para alcançar maiores

distâncias. Segmentos Profibus utilizando fibra ótica como meio físico devem adotar uma topologia em

estrela ou anel. Alguns fabricantes oferecem ainda redes redundantes com a troca automática de rota em

caso de falha. Existem também acopladores entre rede de fibra ótica e RS485, o que permite trocar de meio

de transmissão sempre que desejado. A Hirschmann oferece uma arquitetura de rede em anel utilizando o

repetidor OZD Profibus.

O tipo da fibra irá determinar a distância máxima a ser alcançada.

Tabe la 17: T ipos de F ibras x D is tânc ias



F igure 131: T ipos de F ibras Ót icas

13.8.5. Protocolo de Acesso ao Meio

O protocolo de acesso ao meio é implementado pela camada 2, que no caso do Profibus é

denominado Fieldbus Data Link (FDL). A camada MAC no Profibus opera segundo dois princípios básicos:

- Na comunicação entre sistemas de automação complexos (mestres) deve-se buscar que cada

estação tenha tempo suficiente para realizar suas tarefas de comunicação dentro de intervalos de

tempo estabelecidos. Para este tipo de comunicação é adotado o protocolo token passing.

- Na comunicação cíclica entre um mestre tal como um CLP e seus periféricos (escravos), a

transmissão deve ser o mais simples e rápida possível. Neste tipo de transação utiliza-se o

protocolo mestre-escravo.

13.8.6. Protocolo Token Passing

O token é passado para cada estação segundo sua posição no anel lógico (endereços crescentes)

dentro de um tempo bem determinado. O tempo de retenção da ficha por cada mestre é determinado pelo

tempo de rotação do token, que é configurável.



A comunicação em Profibus é independente de conexão, o que permite executar uma comunicação

broadcast (uma estação envia uma mensagem sem reconhecimento para todas as demais, mestres ou

escravos) ou multicast (uma estação ativa envia uma mensagem sem reconhecimento para um determinado

grupo de estações (mestre ou escravos).

F igura 132: Comunicação Token R ing e por Po l l ing

13.9. CONEXÃO DA REDE PROFIBUS PA À REDE PROFIBUS DP

Existem duas maneiras de se realizar a conexão das duas redes: via acoplador de segmento e via

DP/PA link. Acopladores são conversores de sinais que adaptam os sinais RS-485 para o nível de sinal do

IEC 1158-2, não possuem endereço de rede e permitem endereçar os dispositivos das sub redes

diretamente. Sua maior desvantagem é limitar a velocidade da rede DP a 93.75 kbps (na verdade em 45.4

kbps para a maioria dos fabricantes, somente Pepperl+Fuchs dispunha de solução a 93.75kbps em 2001).

Alguns fornecedores do mercado limitam esta velocidade para um valor ainda menor.

Já o link é um equipamento que se conecta na rede DP a 12Mbps e na Profibus PA na velocidade

nominal da rede H1 (31.25 kbps). O link possui um endereço na rede DP e é um dispositivo inteligente. Eles

representam todos os dispositivos conectados à rede IEC 1158-2 como um único escravo no segmento RS-

485.



F igura 133: Acop lador DP/PA

F igura 134: DP/PA L ink



F igura 135: S is tema Mono Mestre

Cada dispositivo ligado na rede pode fornecer 246 bytes de dados de entrada e 246 bytes de

dados de saída.

Numa arquitetura típica, a rede teria apenas um mestre, como por exemplo, um CLP. Numa

arquitetura multi-mestres, cada mestre pode ler variáveis de cada dispositivo escravo, porém cada escravo

está dedicado a um mestre determinado. Este mestre é responsável pela sua inicialização e configuração. Se

o mestre de alguns escravos não está presente, então não se consegue realizar a leitura das variáveis deste

mestre. Apenas um mestre de cada vez pode escrever num dispositivo escravo.



F igure 136: Arqu i te tura Mu l t i -Mestre

13.10. ARQUIVO DE CONFIGURAÇÃO: GSD – GENERAL SLAVE DATA

Profibus definiu uma folha de dados eletrônica denominada GSD que são proporcionados pelo

fabricante do dispositivo Profibus. O GSD se divide em três partes: especificações gerais, informações

relacionadas ao mestre (para dispositivos mestres), informações relacionadas ao escravo.

As especificações gerais definem informações do fabricante, velocidade de comunicação, pinagem

de conectores, etc.

As especificações do mestre definem o número máximo de escravos permitidos e opções de upload e

download.

As especificações do escravo definem os parâmetros do escravo: número e tipo de canais de I/O,

especificação de textos de diagnósticos, etc. Um editor de GSDs está disponível no sítio oficial da rede

Profibus. GSDs são visíveis até o nível de controle e são usados pelas ferramentas de configuração para

visualizar os dados do instrumento.

13.11. EXEMPLO GSD



13.12. COMPARAÇÃO DE CUSTO PROFIBUS X 4…20mA

A rede Profibus tem se mostrada muito efetiva em custo para uma grande gama de aplicações.

Vamos mostrar um comparativo de custo para um projeto de um tanque de fermentação e armazenamento

de uma cervejaria extraído de um exemplo da Endress Hauser.

F igura 137: Comparação Pro f ibus-PA x 4 . . .20mA

13.13. ORÇAMENTO 4... 20MA

2pcs External Racks S5-EG 183U 7.100

20pcs Analogue Input Cards 16AE 20.448

6pcs Analogue Output Cards 8AA 12.926

2pcs Cabinets with analogue terminals 11.000

28.270m Cable LIYCY 4x0,5 (incl. mounting) 97.814

357x2 Cable connections 9.246

Planning (179 sheets) 20.000

Mounting 10.710

Setup 12.500

Tota l 1 (133%) 201.744

48pcs Level+Density analogue devices 168.000

2pcs Planning (60 sheets) 8.000

Tota l 2 (204%) 381.744



13.14. ORÇAMENTO PROFIBUS–PA

357pcs Additional costs PA devices 24.656

357pcs T-Connectors for PA connection 28.560

8pcs PROFIBUS-DP Interface Cards IM308C 13.520

20pcs DP/PA Segment Couplers 23.600

28pcs Profibus Connectors 2.240

1pcs Cabinet DP/PA Coupler 2.000

3.940m PROFIBUS-PA cable (incl. mounting) 18.557

357x2 Cable connections 9.246

Planning (29 sheets) 8.000

Mounting 10.710

Setup 10.000

Tota l 1 (100%) 151.089

Software Level + Density 36.000

Tota l 2 (100%) 187.089

F igura 138: Exemplo de Pa iné is com e sem Rede Pro f ibus



Os principais ganhos de se utilizar o Profibus contra o 4..20mA tradicionais podem ser resumidos como:

Redução do custo de engenhar ia através:

- Redução do número de equipamentos;

- Redução da documentação.

Redução do custo de insta lação e comiss ionamento:

- Redução do custo com cabos (40%), caixas de terminais, bandejamento e dutos, gabinetes e

espaço na sala elétrica;

- Fácil modificação, geralmente sem a necessidade de troca de fiação;

- Dispositivos multifuncionais reduzem o número de taps de processo.

Redução do custo de operação:

- Melhor capacidade de diagnóstico, redução do tempo de parada;

- Informação disponível em maior quantidade e qualidade facilitando a análise do processo e

otimização.

Redução do custo de Manutenção:

- Menor número de equipamentos implica em redução da quantidade de falhas.



13.15. PROFIBUS E ETHERNET (PROFINET)

Existe um esforço em se buscar o acoplamento transparente entre as redes Profibus e Ethernet. O

que se busca é uma redução dos custos de engenharia e a promoção de uma comunicação mais uniforme

entre aplicativos de alto nível e dispositivos de campo.

Os principais objetivos são:

- Mapear todos os serviços de engenharia do PROFIBUS para TCP/IP, incluindo acesso ao status das

variáveis de processo, dados de diagnóstico, parametrização e a definição de interfaces relevantes

de SW com base em OPC. O usuário poderá monitorar dispositivos localmente ou remotamente

através da Ethernet/Internet;

- Roteamento direto de TCP/IP para Profibus. Uma das idéias é se permitir o uso de web server em

dispositivos de campo;

- Dispositivos de campo complexos serão representados como sistemas orientados a objeto

distribuídos.

Outro grande objetivo do projeto Profibus é maior suporte para as funções de motion control.



F igura 139: Pro f ibus e Ethernet TCP/ IP



ANOTAÇÕES



14. FOUNDATION F IELDBUS

14.1. INTRODUÇÃO

A rede Foundation Fieldbus (FF) é uma rede digital cuja padronização levou mais de dez anos para

ser concluída. Existem duas redes FF, uma de baixa velocidade concebida para interligação de instrumentos

(H1 - 31,25 kbps) e outra de alta velocidade utilizada para integração das demais redes e para a ligação de

dispositivos de alta velocidade como CLPs (HSE - 100 Mpbs).

F igura 140: Redes F ie ldBus H1 e HSE



A rede H1 possui velocidade de 31,25 Kbps e proporciona grandes vantagens para substituir a

instrumentação convencional de 4..20mA:

· Redução do cabeamento, painéis, borneiras, fontes de alimentação, conversores e espaço na sala de

controle;

· Alimentação do instrumento pelo mesmo cabo de sinal;

· Opções de segurança intrínseca;

· Grande capacidade de diagnóstico dos instrumentos;

· Suporte para asset management: capacidade de realizar funções de diagnóstico, configuração, calibração

via rede permitindo minerar dados de instrumentação em tempo real. Estas funções irão permitir a

implementação da manutenção proativa, centrando os recursos onde eles são mais necessários;

· Capacidade de auto sensing (auto reconhecimento) do instrumento permitindo fácil instalação e download

de parâmetros;

· Redução dos custos de engenharia, instalação e manutenção;

· Sinal de alta resolução e livre de distorções assegura precisão do sinal recebido aumentando a

confiabilidade do sistema de automação.

A rede Foundation Fieldbus tem como principais concorrentes às redes Profibus - PA e o protocolo

HART.

O estudante deve se esforçar para não confundir o nome rede Foundation Fieldbus com o da

fundação que a criou e a mantém esta sim denominada Fieldbus Foundation.




Uma das grandes revoluções da rede FF foi estender a visão da área de processo até o

instrumento e não até o último elemento inteligente então existente que era o CLP ou remota do SDCD.

F igure 142: Arqu i te tura H1



F igura 143: Conexões ao Processo

A outra revolução da rede FF foi permitir a migração das estratégias de controle do controlador,

antes representado por uma remota ou CLP para o elemento de campo, representados pelos transmissores

de temperatura, pressão, etc. e pelos atuadores em sua maior parte válvulas de controle. Isto irá permitir

que dois ou mais instrumentos estabeleçam malhas de controle, que uma vez configuradas remotamente

irão operar de forma completamente independente do controlador externo. Estas estratégias de controle

constituem os chamados blocos de controle.

Os blocos mais conhecidos são os de Analog Input (AI), Analog Output (AO), Controlador PID (PID),

Digital Input (DI) e Digital Output (DO).



F igura 144: Função de Contro le na Ins t rumentação

Outra vantagem da rede FF é a redução de equipamentos necessários para instalar os

instrumentos em uma área classificada.



F igura 145: Barre i ras de Segurança

14.2. ARQUITETURA DO SISTEMA

A tecnologia Fieldbus H1 foi baseada no modelo OSI da ISO.

F igura 146: F ie ldBus H1 e Mode lo OSI



O sistema H1 é formado de três camadas: a camada física, o stack de comunicação e a camada de

usuário. Fazendo a correspondência com o modelo OSI/ISO, a camada física corresponde à camada física do

modelo OSI. O stack de comunicação contém a camada de acesso ao meio, a camada de aplicação que é o

Fieldbus Message Specification (FMS) e o Fieldbus Access Sublayer (FAS) que mapeia o FMS nas funções da

DLL. A camada de usuário do fieldbus é inexistente no modelo OSI.

A Figura 147 mostra a formação do quadro fieldbus entre as diversas camadas do stack.

F igura 147: Formação do Quadro de Mensagem

14.3. CAMADA DE APLICAÇÃO E BLOCOS

A camada de aplicação utiliza o conceito de blocos para realizar todas suas funções. Existem três

tipos de blocos básicos: blocos de recursos e blocos de transdutores, utilizados para configurar os

dispositivos e blocos de função, utilizados para construir a estratégia de controle.



F igura 148: Representação por B locos

F igura 149: T ipos de B locos

Os blocos de transdutor servem para desacoplar os blocos de função das funções de interface com

o sensor de campo. Eles podem executar a uma freqüência superior à dos blocos de função. Apesar de

visíveis eles não podem ser linkados via ferramenta de configuração. Estes blocos não podem ser

escalonados pelo sistema de gerenciamento. Os blocos de recurso descrevem as características físicas do

dispositivo. Eles contem configurações gerais para o FVD. Eles também são visíveis externamente, mas não

podem ser interligados nem participar do escalonamento estabelecido pelo LAS. Alguns de seus parâmetros

são: ID do fornecedor, versão do dispositivo, características, capacidade de memória, etc.



Os blocos de função determinam o comportamento do sistema. As entradas e saídas dos blocos de

função podem ser interligadas para configurar uma estratégia de controle. A execução de cada bloco de

função pode ser precisamente escalonada pelo sistema.

Os dez principais blocos de função são:

Tabe la 18: B locos de Função

Transmissores simples de temperatura, pressão, etc., possuem um único bloco AI.

Uma válvula de controle pode conter um bloco PID além do bloco AO.

E x e m p l o:

Na figura abaixo, uma malha de controle foi definida usando apenas os blocos de controle contidos

em dois dispositivos: um medidor de vazão que fornece o bloco AI e uma válvula que fornece os blocos AO e

PID.



F igura 150: Ma lha de Contro le entre Do is Ins t rumentos

14.4. BLOCOS AVANÇADOS

A especificação FF-892 introduz novos blocos de controle:

Tabe la 19: B locos de Função Avançados

A especificação FF-893 introduziu os blocos múltiplos ou multiple I/O (MIO):



Tabe la 20: B locos de Função Avançados 2

A grande inovação veio a seguir. A especificação FF-894 permite a criação de um bloco de

aplicação livre pelo próprio usuário usando a norma IEC 61131-3. Este bloco recebeu o nome de Flexible

Function Block (FFB).

F igura 151: B loco de Função F lex íve l

Um bloco mantém controle da comunicação com outros blocos. Se houver perda de comunicação o

dado de entrada é considerado velho (stale) e o bloco sinaliza o problema.



F igura 152: B loco A I e sua Imp lementação

F igura 153: B loco A I e S imu lação de Va lores de Entrada

Um bloco AI, por exemplo, tem várias funcionalidades fora ler um dado do campo e o disponibilizar

como um valor digital para outros blocos. O bloco AI é capaz de aplicar um alarme da saída por faixa e até

de simular uma entrada analógica que esteja com status ruim baseado em seus valores anteriores (Figura

153).



F igura 154: Sumar io dos B locos de Contro le

F igura 155: Exemplo de Conf iguração de Ma lhas de Contro le



14.5. CAMADA FÍSICA

Tanto a FF-H1 como a rede Profibus-PA tem sua camada física padronizada pela norma IEC

611582. Os sinais H1 são codificados utilizando codificação Manchester Bifase-L. Trata-se de uma

comunicação síncrona que envia os sinais de dados combinados com o relógio.

F igura 156: Cod i f i cação Manchester B i fase-L

Observe que o sinal resultante corresponde à função XOR negada dos sinais de clock e dados. Uma

transição positiva do sinal combinado no meio do período correspondente a um bit será considerada 0 e

uma transição negativa é lida como 1. Para sincronizar o clock do receptor com o do transmissor um

preâmbulo formado por uma seqüência de 0s e 1s é inicialmente transmitido.



Para delimitar os quadros são utilizados sinais especiais correspondentes a violações dos códigos

acima. Os sinais N+ e N- não apresentam uma transição no meio do tempo correspondente a um bit.

F igura 157: Caracteres Espec ia is de In ic io e F ina l de Quadro

O transmissor irá modular o sinal variando a corrente de ±10mA a uma freqüência de 31,25 Kbps

sobre uma carga equivalente de 50 ohms para criar uma modulação de 1.0 Volt pico a pico sobre o sinal

da fonte de alimentação. O valor da tensão da fonte de alimentação pode variar de 9 a 32 Volts.

Aplicações de segurança intrínseca (SI) possuem outros requerimentos.



F igura 158: S ina l F ie ldBus

As regras básicas para validação de uma rede FF-H1 são:

· A rede é formada por uma linha troco com stubs ou spurs. A linha tronco deve ser terminada por um

terminador passivo.

· O comprimento máximo da linha tronco e da soma de todos os stubs é de 1900m.

· O número de instrumentos na rede pode ser: 2 a 32 instrumentos numa conexão não intrinsecamente

segura com fonte de alimentação separada do sinal de alimentação. 1 a 12 instrumentos quando a aplicação

não requer SI e os instrumentos são alimentados pelo cabo de sinal. 2 a 6 instrumentos para aplicações de

SI quando os instrumentos recebem a sua alimentação diretamente do cabo de comunicação.

· Repetidores podem ser utilizados para regenerar o sinal após excedida a especificação de distância

máxima. O número máximo de repetidores é quatro. A distância máxima entre dois instrumentos quaisquer

não deve exceder 9500 m.



· O cabo fieldbus é polarizado. Inverter a polarização pode causar danos a todos os instrumentos

conectados à rede. Alguns fornecedores garantem instrumentos livres de polarização.

· O comprimento dos spurs deve ser calculado obedecendo aos dados da tabela abaixo:

Tabe la 21: Compr imento Máx imo dos Spurs

F igura 159: Topo log ias da Rede F ie ldBus



14.6. ELEMENTOS DE REDE

Os principais elementos na rede fieldbus são:

· A fonte de alimentação;

· O módulo condicionador de potência;

· O terminador de barramento;

A ligação de dispositivos à rede pode se dar através de conectores Ts ou de caixas de junção.

F igura 160: Terminador e cabo da Rede FF-H1



A fonte de alimentação é um equipamento de segurança não-intrínsica com uma entrada AC

universal e uma saída de 24Vdc, isolada, com proteção contra sobre corrente e curto-circuito, ripple e

indicação de falha, apropriada para alimentar os elementos do Fieldbus. Exemplo: Fonte DF52 da Smar.

O módulo condicionador de potência é um equipamento de controle de impedância ativo, não-

isolado, de acordo com o padrão IEC 1158-2. Este equipamento apresenta uma impedância de saída que,

em paralelo com os dois terminadores de barramento (um resistor de 100Ω em série com um capacitor de

1µF) atendendo ao padrão, resulta em uma impedância de linha puramente resistiva para uma ampla faixa

de freqüência. Exemplos: os módulos DF49 (dois canais) e módulo DF53 (quatro canais) da Smar. Estes

módulos não podem ser utilizados em áreas que exigem especificações de segurança intrínseca.

O terminador de barramento é um elemento passivo formado por um de 100Ω em série com um

capacitor de 1µF acondicionado em um invólucro vedado.

F igura 161: Conf iguração Bás ica de uma Rede FF-H1



F igura 162: L igação na Ca ixa de Junção

F igure 163: Ca ixa de junção FF



F igura 164: E lementos de Rede FF (Conectores)

14.7. CICLO DE OPERAÇÃO

F igura 165: Macro c ic lo e Esca lonamento do Barramento



O escalonamento é executado periodicamente em um período de tempo denominado macrocycle.

Cada dispositivo do barramento é sincronizado com precisão de 1ms e obedece a um escalonamento pré-

determinado. O scheduler determina quando os blocos de função de cada dispositivos são executados e

quando comunicações escalonadas e não escalonadas ocorrem no barramento. As atividades de máxima

prioridade que devem acontecer ciclicamente são denominadas operações escalonadas. As operações não

escalonadas ocorrem quando o primeiro tipo de comunicação não está sendo executado. e outras

operações denominadas comunicações não escalonadas poderão executar. Por exemplo, as transferências

de dados entre blocos de malhas de controle executam na parte escalonada.

O LAS (Link Active Scheduler) é o dispositivo que controla a comunicação no barramento.

Pelo padrão FF existem três tipos de dispositivos:

· O Link Master que é capaz de suportar as funções de LAS;

· Básico que não é capaz de suportar as funções de LAS;

· Linking device que além de ter a capacidade de ser Link Master possui a funcionalidade de conectar

segmentos H1.

Apenas um link master executando como LAS pode controlar a comunicação no barramento FF-H1.

Caso este dispositivo saia do ar outro link master irá tentar assumir o papel de LAS. Deve existir pelo menos

um link master por segmento capaz de assumir o papel de LAS. Durante a partida o link master com menor

número de nó assume o papel de LAS.

14.8. SINCRONIZAÇÃO NO TEMPO

Existem várias sincronizações a serem efetivadas em uma rede FF-H1:

14.8.1. Sincronização do Tempo de Datalink

A primeira função é proporcionar a sincronização no tempo de cada dispositivo no barramento.

Cada instrumento é um computador e com o tempo os relógios dos diversos instrumentos passam a



apresentar um erro de fase (drift error). Como a comunicação deve ser determinística com precisão de 1 ms

os relógios devem ser sincronizados periodicamente. O LAS é responsável por este serviço de sincronização

do tempo de barramento ou data link time. Ele envia uma mensagem denominada TD (time distribution)

periodicamente no barramento.

14.8.2. Sincronismo do Time of Day

Outro sincronismo importante é o do relógio de hora do dia utilizado para aplicar o time stamp em

cada dado lido e nos eventos e alarmes ocorrido. Esta hora é denominada application time e deve ser

sincronizada para todos os dispositivos.

Este sincronismo é obtido através da Clock Message enviada por um dispositivo denominado Time

Master através de uma mensagem do tipo DT (Data Transfer) enviada. O Time Master pode ser qualquer

dispositivo do barramento incluindo o host que também executa o papel de LAS ou qualquer instrumento.

Esta mensagem não é considerada parte do ciclo de manutenção do enlace de dados.

14.8.3. Identificação dos Dispositivos

A manutenção de enlace de dados inclui outras atividades como a identificação de novos

instrumentos inseridos na rede. Isto proporciona a importante capacidade de plug and play da rede. O LAS

mantém uma lista com todos os endereços de dispositivos ativos no barramento. Esta lista é chamada de

Live List ou lista de dispositivos ativos.

Uma mensagem especial denominada PN (Probe Node) é utilizada para identificar novos

dispositivos. O LAS periodicamente envia mensagens PN para os nodos que não estão na Live List. Se um

dispositivo está presente no endereço ele responde com a mensagem PR (Probe Response). O LAS inclui o

dispositivo na Live List e confirma a ativação do dispositivo através da mensagem NodeActivation.

Cada dispositivo é identificado por três valores:

· Device ID: Número de série definido pelo fabricante do instrumento. Por exemplo: 31416ACME93293;

· Device Name (TAG): definido pelo usuário. Por exemplo: TT-01;



· Device Address: endereço único no segmento. Por exemplo: 33.

Todo o endereçamento é configurado por comandos do barramento sem o uso de jumpers ou dip-

switches.

A sequência para se designar um novo endereço para um dispositivo é a seguinte:

· Um novo dispositivo é conectado ao barramento e usa um endereço default randômico entre 248-251;

· Uma ferramenta de configuração rodando no host atribui um nome físico ao dispositivo (PD TAG);

· Uma ferramenta de configuração rodando no host designa um endereço permanente não utilizado ao

dispositivo. O dispositivo se lembrará deste endereço mesmo após uma queda de alimentação.

14.8.4. Dicionário de Objetos

Todo dado dos dispositivos accessível via rede é descrito pelo Object Dictionary (OD) que depende

do dispositivo.

O Virtual Field Device (VFD) contem todos os objetos e descritores de objetos que podem ser

utilizados por um usuário de comunicação. Todo dispositivo de campo geralmente tem duas VFDs:

· Uma FFD para blocos de função;

· Uma Management Information Base (MIB) que retrata aplicações de gerenciamento de rede e do sistema;

Toda aplicação de controle consiste de blocos de função interconectados. Blocos são conectados

através de objetos de ligação (linking objects) da VFD de blocos de função. Um objeto de ligação irá

conectar dois blocos de função no mesmo instrumento ou um bloco de função para uma VCR para produtor

ou consumidor.



F igura 166: D ispos i t i vo de Campo V i r tua l e Seus D ic ionár ios de Ob je tos

14.8.5. Comunicação Escalonada

A comunicação escalonada é usada para transferir dados cíclicos de malhas de controle entre os

blocos de função. O LAS possui uma lista com os tempos para transmissão de todos os blocos de todos os

dispositivos que necessitam ser transmitido ciclicamente.

Quando chega a hora de um dispositivo enviar um buffer o LAS envia uma mensagem do tipo

Compel Data (CD) para o dispositivo. Ao receber o CD o dispositivo publica ou broadcasts o dado para todos

os dispositivos no barramento. Todo dispositivo que estiver configurado para receber o dado é chamado de

assinante ou consumidor. O LAS reserva um tráfego exclusivo para realizar as comunicações escalonadas.

14.8.6. Comunicação Não Escalonada

Todos os dispositivos do barramento têm a chance de transmitir informações não escalonadas

entre os ciclos de transmissão de mensagens cíclicas.

O LAS garante uma permissão para um dispositivo usar o barramento emitindo uma mensagem do

tipo PT (Pass Token) para o dispositivo. Quando o dispositivo percebe o token ele tem o direito de usar o

barramento até terminar ou até o tempo máximo de manutenção do token ter sido alcançado.



14.9. A OPERAÇÃO DO LAS

O LAS realiza ciclicamente as seguintes operações:

F igura 167: C ic lo de At iv idade do LAS

A programação de CD contém uma lista de atividades que estão programadas para serem

executadas ciclicamente. Na hora especificada o LAS envia uma mensagem CD (Compel Data) para um buffer

de dados em um dispositivo FF. O dispositivo publica a mensagem. Esta atividade tem prioridade máxima.

Todas as demais atividades acontecem entre este tipo de transferências. O LAS passa a enviar PTs para

todos os nodos na Live List. O dispositivo que responder corretamente a mensagens PT continua na Live

List. Se o dispositivo ao receber o token não transmitir uma mensagem ou devolver o token por três vezes

consecutivas, será tirado da Live List. Depois o LAS deve enviar mensagem PN (Probe Node) a pelo menos

um nodo fora da Live List. Toda vez que o LAS altera a Live List ele realiza o broadcast das alterações na

Live List para que todos os nodos possam ter uma cópia atualizada da Live List.

A mensagem TD (Time Distribution) é enviada periodicamente a todos os nós.



14.10. VIRTUAL COMMUNICATION RELATIONSHIPS (VCR)

A comunicação escalonada e não escalonada é uma função da camada DLL (Data Link Layer). A

camada FAS (Fieldbus Access Sub layer) utiliza estas funções para proporcionar um serviço à camada FMS

(Fieldbus Message Specification).

Estes serviços são descritos por VCRs (Virtual Communication Relationship), relações virtuais de

comunicação.

O VCR é como uma abreviatura de acesso, uma pequena estrutura que resume um conjunto maior

de dados pré-armazenados.

As principais VCRs são:

14.10.1. Comunicação Cliente – Servidor

Utilizada para comunicação enfileirada, não escalonada, iniciada pelo usuário, um para um, entre

dispositivos no fieldbus.

Enfileirada implica que as mensagens são enviadas na ordem fornecida para transmissão,

respeitada suas prioridades, sem sobrescrita das mensagens anteriores. Quando um dispositivo recebe um

token ele coloca uma mensagem no barramento. Ele é dito cliente da comunicação e o destino da

mensagem é o servidor. Quando o servidor recebe o token do LAS ele responde à pergunta recebida.

Exemplos: Mudança de set point pelo operador, sintonia de malhas e parâmetros, reconhecimento

de alarmes e download e upload do dispositivo.

A Figura 168 mostra um exemplo de mecanismo cliente servidor implementado com comunicação

não escalonada:



F igura 168: Mecan ismo C l iente - Serv idor

O mecanismo pode ser sumarizado como:

1. O Cliente necessita de dado do servidor

2. O Cliente coloca uma mensagem Data Transfer Request na fila.

3. Cliente recebe o token do LAS.

4. Cliente envia Data Transfer Confirmed Request para o Servidor.

5. O Servidor coloca dado solicitado na fila de mensagem.

6. Servidor recebe token do LAS.

7. Servidor envia Data Transfer Confirmed Response para o Cliente.



8. Cliente recebe e decodifica dado solicitado.

9. LAS continua a cuidar de outras comunicações do barramento.

14.10.2. Distribuição de Relatório (Report Distribution or Source and Sink)

Utilizada para comunicação enfileirada, não escalonada, iniciada pelo usuário, um para muitos,

entre dispositivos no fieldbus.

Quando um dispositivo com um evento ou relatório de tendência recebe o token do LAS, ele envia a

mensagem para um grupo de endereços representado pelo VCR. Dispositivos interessados em receberem a

mensagem identificada pelo VCR irão receber o evento ou relatório.

Exemplo: Envio de eventos e alarmes (non solicited messages) para estações de supervisão.



F igura 169: D is t r ibu ição do Re la tór io

14.10.3. Produtor – Consumidor

É utilizado para comunicação buferizada de um para muitos. Bufferizado quer dizer que apenas a

última versão da informação é mantida. O dado mais recente sobrescreve o dado anterior.

Quando um dispositivo recebe a mensagem CD do LAS, ele transmite uma mensagem. Este

dispositivo é chamado de produtor. Todos os dispositivos interessados no dado irão recebê-lo. Estes

dispositivos são os assinantes ou consumidores.

A mensagem Cd pode ser escalonada no LAS ou enviada aos assinantes de forma não escalonada.

Um atributo do VCR irá determinar quais dos dois mecanismos serão utilizados.

Exemplo:

É utilizado para publicar de forma escalonada e cíclica os valores das PVs e MVs das malhas de

controle para os instrumentos e para as estações de operação.



F igura 170: Mecan ismo Produtor - Consumidor

F igura 171: Sumar io de Serv iços da FAZ



F igura 172: Sumar io de T ipos de Comunicação FF

14.11. VANTAGENS DA REDE H1 SOBRE PROFIBUS-PA

São vantagens da rede H1 sobre a rede Profibus-PA:

· A rede FF-H1 possibilita o auto reconhecimento do instrumento instalado a quente possibilitando uma

operação plug and play.

· Na rede FF_H1 o controle é realizado no instrumento mudando a estratégia de controle para FCS (Field

Control System).

· Na rede FF-H1 o acesso aos dados de E/S é determinístico no tempo.

· A rede FF-H1 permite configurar o dispositivo remotamente sem o uso de dip-switches.

· A rede FF-H1 permite o envio de diagnóstico e mensagens de status pelo instrumento.



· A rede FF-H1 implementa o conceito de produtor-consumidor que além de diminuir os requisitos de banda

promovem uma total transparência de dados entre as diversas camadas do sistema de controle.

· A rede FF_H1 permite que o instrumento armazene dados de tendência histórica, que depois são

transferidos para o mestre.

14.12. PERFORMANCE

Em 2002 houve um estudo que mostrou uma estatística de desempenho dos principiais blocos de

controle. Não necessariamente as funções de malha PID precisam ser executadas de forma distribuída na

instrumentação. Elas podem ser executadas também um nível acima como em um SDCD tradicional.

F igura 173: Tempos de Per formance T íp icos



14.13. INTEGRAÇÃO COM REDE HSE

A rede H1 possui certas limitações. O número de instrumentos na rede não pode crescer muito estando

limitado pelos recursos de faixa exigidos por cada instrumento. É normal que apenas 5 ou 7 instrumentos sejam

colocados em um mesmo segmento. Para interligar diversos segmentos FF-H1 a solução ideal é o uso da rede HSE

operando na velocidade de 100 Mpbs.

A rede HSE é compatível com os protocolos da rede H1, permitindo o intertravamento de instrumentos

localizados em diferentes segmentos de rede. Além disso, permite a interligação de dispositivos que requerem

grande capacidade de rede como CLPs e computadores host e instrumentos especializados que necessitam

transferir grandes blocos de dados como espectrofotômetros.

A rede HSE evita a existência de diversos níveis de hierarquia reduzindo qualquer configuração a dois

níveis apenas.

F igure 174: In ter l igação entre Redes HSE e H1

Além de servir de gateway entre a rede HSE e a rede H1 os device links realizam outra função

importante: eles podem ter pontos de I/O locais para permitir a interligação de sinais discretos oferecendo

uma boa solução para aplicações de natureza híbrida. Outros device links possuem interfaces para outros



protocolos como o Modbus para facilitar a interligação de inversores de freqüência e outros tipos de

dispositivos inteligentes orientados a byte.

F igura 175: L ink ing Dev ice HSE com I /O Loca l e com In ter face Modbus

Existem blocos de I/O remotos que podem ser ligados na rede H1 para um pequeno número de

sinais de entrada e saída como o Smar DC302 I/O Block.

F igura 176: B loco de I /O Smar DC 302

Recentemente foram introduzidos no padrão H1 blocos de função múltiplos capazes de manipular

até oito variáveis digitais e analógicas. São os blocos MAI, MAO, MDI, MDO. Todas as oito variáveis podem

ser lidas ou escritas nestes blocos em uma transação única. A funcionalidade MVC (Multi Variable Container)

também introduzida recentemente permite acessar todas as variáveis de diferentes blocos de um mesmo

dispositivo em uma transação única, diminuindo o número de comunicações para lerem variáveis de

instrumentos complexos.

Existem também gateways para sinais Hart, permitindo a ligação em Daisy chain de até quatro

gateways totalizando 32 canais Hart. Os instrumentos Hart são visíveis na rede H1 como se fossem



instrumentos H1 só que com as limitações impostas pela tecnologia HART. Exemplo de gateway Hart-FF-H1

é o Smar HI302.

F igura 177: Gateway Har t-F ie ldBus

Para mapear os instrumentos em uma rede estrangeira para a rede FF-H1 pode-se utilizar os

blocos flexíveis FFB. A lógica do FFB é definida pelo usuário. O FFB irá permitir também que uma ferramenta

de configuração FF default possa ser utilizada para configurar os parâmetros da rede estrangeira.

14.13.1. Exemplo – DFI 302 – Subsistema de I / O Fieldbus

Cada módulo DFI302 permite a conexão de até quatro redes H1 a uma rede HSE. Desta forma este

dispositivo funciona como um linking device. Ele também opera como uma bridge entre diferentes canais H1,

permitindo a comunicação entre instrumentos localizados em segmentos diferentes. Ele também opera como

um gateway permitindo a conexão de dispositivos estrangeiros através dos protocolos Modbus RTU e

Modbus TCP/IP às redes FF-HSE e FF-H1. Cada módulo pode gerenciar uma rede Modbus completa. O

DFI302 pode operar como master ou slave da rede. Como mestre de uma rede Modbus o DFI302 permite a

conexão de sistemas legada ao sistema 302. Como escravo ele possibilita conectar um sistema fieldbus

Smar a um SDCD mais antigo que não suporta o padrão FF.

O FDI302 pode funcionar como LAS para quatro redes H1 diferentes. Ele também pode fazer o

papel de uma RTU de SDCD executando 37 blocos de função FF diferentes, com cerca de 100 blocos por

módulo, o que é útil quando não se quer realizar as funções de controle no instrumento e mantê-las

centralizadas como nos SDCDs antigos.

Este dispositivo também permite o uso de cartões de I/O convencional para a programação de

sistemas híbridos onde a função de intertravamento discreto é importante. Tanto entradas analógicas 4..20



mA são disponíveis entradas discretas, e de pulso. Para implementar esta função o DFI302 oferece Blocos

de função flexíveis (FFB). Para programar a lógica existe uma linguagem textual e está sendo desenvolvido

um módulo em ladder. Desta forma ele desempenha a função de um CLP.

Dois FDI302 podem ser colocados em paralelo para assegurar dois canais redundantes para a sala de

controle e LAS redundantes para as redes H1.

14.14. DEVICE DESCRIPTOR (DD)

A Device Description é uma descrição textual do dispositivo de campo produzida pelo fabricante do

instrumento para uso dos sistemas host. A definição é feita para os protocolos HART, Profibus e Foundation

Fieldbus, utilizando uma linguagem universal denominada DDL – Device Descriptor Language. Esta

linguagem é normalizada através da norma IEC 61 804 partes 1 e 2 Function Block Application and EDDL e

CENELEC 50391 – Network Oriented Application Harmonization Electronic Device Description Language. O

texto fonte é denominado DD Source. Este texto pode ser convertido para uma notação mais compacta

denominada DD binário por um software denominado tokenizer.



ANOTAÇÕES



15. ETHERNET

F igura 178: Esboço Or ig ina l da Rede Ethernet fe i to por Metca l fe em um Guardanapo em 1976

15.1. INTRODUÇÃO

A rede Ethernet passou por uma longa evolução nos últimos anos se constituindo na rede de

melhor faixa e desempenho para uma variada gama de aplicações industriais. A Ethernet foi inicialmente

concebida para ser uma rede de barramento multidrop (100Base-5) com conectores do tipo vampiro

(piercing), mas este sistema mostrou-se de baixa praticidade. A evolução se deu na direção de uma

topologia estrela com par trançado. As velocidades da rede cresceram de 10 Mbps para 100 Mbps e agora

alcançam 1 Gbps (IEEE802.3z ou Gigabit Ethernet). A Gigabit Ethernet disputa com a tecnologia ATM o

direito de ser a espinha dorsal (backbone) das redes na empresa. A outra evolução se dá no uso de hubs

inteligentes com capacidade de comutação de mensagens e no uso de cabos full duplex em substituição aos

cabos half duplex mais comumente utilizados. Isto faz com que a rede se torne determinística e reduzem a

probabilidade de colisão de dados.




Outras iniciativas visam utilizar a rede Ethernet para como substrato para outras aplicações.

Algumas iniciativas nesta direção são:

15.1.1. Desenvolvimento da Rede Fieldbus HSE (High Speed Ethernet)

A Fieldbus Foundation incorporou a rede Ethernet dentro de sua especificação H2. Esta rede não

visa substituir a rede H1, mas estender seu espectro de aplicação para a interligação de dispositivos como

CLPs e sistemas de supervisão. Esta rede usa UDP/IP sobre as camadas de enlace Ethernet.



F igura 180: Rede HSE e Rede H1

Tabe la 22: Tabe la Comparat iva Rede HSE x H1

A rede HSE suporta todas as funcionalidades das camadas de enlace de dados da especificação H1.

Isto teve de ser feito para possibilitar o sincronismo de uma ligação em cascata entre malhas localizadas

entre segmentos H1 independentes. A interligação entre uma rede H1 e rede HSE se dá através de um

“linking device” que converte o dado de diversos segmentos H1 em mensagens, utilizando os protocolos

standards da Internet. Os instrumentos de campo também podem bypassar o protocolo H1 e transmitir

usando o protocolo HSE diretamente.

15.1.2. Ethernet / IP



Ethernet/Ip é o nome comercial da especificação da camada de aplicação Control Net sobre

TCP/UDP/IP sobre Ethernet. A especificação foi gerada pela ControlNet International e agora está sendo

adotada pela ODVA (Open Device Net Vendors Association). A especificação da ControlNet consiste do

Control and Information Protocol (CIP) rodando sobre a camada CTDMA (Concurrent Time Domain Multiple

Access). O protocolo DeviceNet é uma especialização do CIP rodando sobre CAN. Ethernet/IP é uma

especialização do protocolo CIP rodando sobre TCP/UDP/IP, que por sua vez roda sobre a rede Ethernet.

15.1.3. ProfiNet

Existe um esforço em se buscar o acoplamento transparente entre as redes Profibus e Ethernet. O

que se busca é uma redução dos custos de engenharia e promover uma comunicação mais uniforme entre

aplicativos de alto nível e dispositivos de campo.

Os principais objetivos são:

. Mapear todos os serviços de engenharia do PROFIBUS para TCP/IP, incluindo acesso ao status das

variáveis de processo, dados de diagnóstico, parametrização e a definição de interfaces relevantes de SW

com base em OPC. O usuário poderá monitorar dispositivos localmente ou remotamente através da

Ethernet/Internet.

. Roteamento direto de TCP/IP para Profibus. Uma das idéias é se permitir o uso de web server em

dispositivos de campo.

. Dispositivos de campo complexos serão representados como sistemas orientados a objeto distribuídos.

Outro grande objetivo do projeto Profibus é maior suporte para as funções de motion control.



F igura 181: Pro f ibus e Ethernet TCP/ IP

15.1.4. IEEE 1451

Esta iniciativa visa ligar sensores e atuadores diretamente à redes de controle incluindo a Ethernet,

que devido ao baixo custo do chip reduziria muito o custo comparado com outros tipos de conexões. Um

dos grandes suportadores desta solução é a HP que combina este tipo de conexão com embedded Java e o

uso de um web browser por instrumento. Com a miniaturização e a redução do custo dos web browsers esta

tecnologia pode se tornar muito atrativa.

F igura 182: Sensor In ter face IEEE 1451



15.1.5. Modbus / TCP

Esta rede une o protocolo de camada de aplicação mais popular com o stack de transporte/rede

mais utilizados na indústria. Na verdade o protocolo Modbus rivaliza em popularidade com o protocolo DF1

da Rockwell Automation, mas é mais difundido. Uma das vantagens do protocolo TCP/IP é a facilidade de se

usar diversas camadas de aplicação diferentes. No port 1000 estamos tratando requisições de serviço do

protocolo Modbus, enquanto no port 1001 tratamos um protocolo DF1, por exemplo.

Este tipo de aplicação visa mais interligar dispositivos de campo orientados a byte, mais simples,

como equipamentos de laboratório, medidores de energia CA/CC, relés inteligentes, etc. As empresas que

atuam nesta área defendem que não se pode fazer uma revolução e trocar todos os standards de uma só

vez, como feito no passado, quando se definiu o padrão MAP/TOP. O que se deve fazer é procurar uma

evolução gradativa do que é usado de fato em direção a padrões mais abrangentes e de melhor

desempenho.

Outra tecnologia emergente nesta área é o que se chama “comm port redirection”. Um dispositivo

serial está ligado numa rede Ethernet TCP/IP. Um computador cliente acessa seus dados utilizando o

protocolo Modbus. Um device driver rodando em Windows permite enxergar o dispositivo na rede como se

estivesse ligado a uma porta serial do micro, digamos a uma COM3 ou COM4. Isto permite continuar

utilizando aplicações do legado, por exemplo, um programador ladder, mesmo utilizando uma conexão

moderna em rede do instrumento.



F igura 183: In t rumentos Ser ia is In ter l igados v ia TCP/ IP

15.2. PRINCÍPIOS BÁSICOS

A rede Ethernet nasceu dos laboratórios Palo Alto Research Center (PARC) da Xerox nos anos 70,

inicialmente como uma rede de 2.94 Mbps, utilizando uma linha troco com cabo grosso e tecnologia de

derivações tipo piercing. Em 1980 a Intel, Digital e Xerox publicaram o padrão DIX V1. 0, estabelecendo a

velocidade de 10 Mbps. Em 1985 o comitê IEEE 802.3 publicou a Norma IEEE802.3 Carrier Sense Multiple

access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. Esta tecnologia

é chamada 802.3 CSMA/CD e não Ethernet. Na verdade os frames definidos pela norma 802.3 CSMA/CD e

DIX V2. 0 são diferentes.



F igura 184: Quadro Ethernet

F igura 185: Quadro IEEE 802.3

15.2.1. Preâmbulo

O preâmbulo DIX consiste de 64 bits de “1s” e “0s” alternados e terminando com dois “1s”. O

preâmbulo 802.3 é idêntico, apenas o último byte recebe o nome de start of frame delimiter (SFD).

15.2.2. Endereço de destino

Um endereço de destino todo preenchido com 1’s implica em uma transmissão em broadcasting.

15.2.3. Endereço de origem

É inserido na mensagem para uso de protocolos de mais alto nível. Este campo não é necessário

para acesso ao meio. O endereço de origem é baseado na identificação do fabricante, que é um número de

24 bits único: Organizationally Unique Identifier (OUI) administrado pelo IEEE. Os outros 24 bits formam um

número seqüencial definido pelo fabricante.



Por exemplo:

O fabricante Hirshmann produz placas com o seguinte endereço:

00: 80: 63: Xx . Yy . Zz

Quadros DIX e quadros IEEE são idênticos quanto ao comprimento total e ao número de bits de

cada campo, mas não são interoperáveis. Todos os protocolos TCP/IP para Ethernet usam quadros DIX e

não quadros 802.3. Observe que o tamanho mínimo do frame de dados é de 46 bytes.

15.3. NÍVEIS FÍSICOS

Vários meios físicos são utilizados na rede Ethernet dependendo das distâncias envolvidas.

As implementações do 802.3 são codificadas segundo a seguinte sintaxe:

<Velocidade> <Classe do Meio> <Distância>

Megabits/s Baseband ou Broadband Centenas de metros.

As principais implementações são:

Tabe la 23: Caracter ís t icas Bás icas das Redes 802.3

15.3.1. 10 BASE 5

Esta é Ethernet original já fora de moda em nossos dias. O Ethernet grosso necessita de

transceptores denominados MAU (Medium Attachment Unit) para efetuar o acoplamento do cabo grosso ao



computador. As MAUs devem ser instaladas em taps espaçados de 2.5 metros. De cada MAU parte um cabo

AUI (Attachment Unit Interface) até o cartão de interface no computador. A conexão se dá via um conector

DB-15. Cada cabo AUI pode ter no máximo 50 metros. Vencidos os 500 m máximos de comprimento do

cabo, um repetidor deve ser instalado até um comprimento máximo total de 2000 m. Esta tecnologia não

suporta o padrão fast Ethernet.

15.3.2. 10 BASE 2

O Ethernet fino ou Thinnet ou Cheapernet irá utilizar conectores BNC de baixo custo, fácil aplicação

e ótima conformação mecânica e cabo coaxial tipo RG-58/u. O Ethernet fino continua a ser uma rede do tipo

barramento. No máximo 30 estações podem ser interligadas até um comprimento máximo de 185 metros

por segmento. Segmentos podem ser estendidos até o comprimento total de 740 metros. Também foram

eliminados do mercado pelo advento da rede 10Base- T. Não suporta Fast Ethernet.

15.3.3. 10 BASE – T

Transforma a arquitetura de rede em barramento em árvore. A ligação de cada computador é feita

a um hub. Cada conexão não pode exceder a 100 metros. O Ethernet 10Base-T pode usar conector AUI-

DB15 de 15 pinos ou conectores RJ45 de 4 vias grimpados. A última opção é a mais utilizada. Esta

tecnologia deu origem ao Fast Ethernet.

15.3.4. 10 BASE – F

Existem três padrões de mídia:

. 10BASE-FL: substitui o padrão FOIRL.

. 10BASE-FB: padrão para backbones pouco utilizado.

. 10BASE-FP: tecnologia utilizando hubs passivos, pouco populares.

O padrão 10BASE-FL requer fibra ótica duplex 62.5mm para cada link. É possível interligação em

distâncias até 2 km, full duplex.



Tabe la 24: T ipos de Cabos usados nas Pr inc ipa is Redes

15.4. MELHORAMENTOS DA REDE ETHERNET

A rede Ethernet teve que receber várias modificações para se tornar mais adaptada ao ambiente

industrial.

Foram criados diversos novos padrões:

Tabe la 25: Novos Padrões do Padrão IEEE 802

Para reduzir o número de colisões e a consequente degradação de performance da rede Ethernet,

o que a inviabiliza para algumas aplicações industriais, muitos melhoramentos foram realizados. O simples

aumento da banda de 10 Mbps para 100 Mbps foi um fator significativo. O uso de switches é o segundo

ponto importante. Se cada dispositivo estiver ligado a uma porta de um switch que pode bufferizar a

mensagem antes de retransmiti-la a outro nó, as colisões ficariam reduzidas ao caso em que um mesmo nó



deseja transmitir e receber uma mensagem. Finalmente através de uma ligação full duplex entre o dispositivo

e switch, o problema é completamente solucionado.

F igura 186: Degradação da Per formance de redes CSMA com Aumento da Carga

As deficiências da rede Ethernet, a partir de agora denominada de Ethernet compartilhada são:

· Largura de banda é compartilhada e não dedicada;

- Compartilhamento necessita de arbitragem do barramento sem o conceito de prioridade.

- Compartilhamento resulta em colisões quando 2 ou mais dispositivos desejam transmitir

simultaneamente.

- Colisões bloqueiam a rede e impedem outros dispositivos de transmitir.

· Mais dispositivos em um segmento aumentam a probabilidade de colisão;

· Broadcast de mensagens consumiria grande banda;

· Não existe como diferenciar o tráfego de alta e de baixa prioridade;



· Não existe como assegurar um caminho de baixo atraso para o tráfego de tempo real.

Estas limitações estão ilustradas na Figura 187.

F igura 187: L im i tações da Rede Ethernet

15.5. EVOLUÇÃO

Na rede A todos os dispositivos compartilham o mesmo meio físico. Para aumentar a performance

três passos são necessários:

· Colapsar o backbone;

· Incrementar links com servidores;

· Micro segmentar a rede.



F igura 188: LAN`s

Cada segmento de rede está ligado a uma porta de um switch. Com a redução do custo e aumento

do throughput dos switches tornou-se possível ligar cada nodo em uma porta individual. Quando os

requerimentos por banda são baixos, podem-se ligar vários dispositivos a um segmento.

F igura 189: Evo lução de Arqu i te tura Ethernet

Com a adoção da arquitetura cliente servidor, tornou-se necessário utilizar canais Fast Ethernet full

duplex, propiciando largura de faixa de até 200 MHz para cada servidor.

Os usuários passaram a utilizar canais com autodetecção de 10/100 Mbps.

A micro-segmentação implica em dar a cada usuário um canal dedicado, sem compartilhamento

com outros dispositivos.



Com a micro-segmentação tornou-se possível o uso de interfaces full duplex também para os

usuários, o que inibe eliminar a arbitragem do barramento e permite a comunicação na velocidade nominal

da rede.

Isto implica também na duplicação da velocidade do barramento de 10/100Mbps para

20/200Mbps.

Sistematizando os seguintes fatores contribuíram para a construção de um rede Ethernet industrial:

· Uso de switches para evitar a arbitragem de barramento;

· Uso de canais dedicados de 10 Mbps a 100 Mbps;

· Padrão IEEE802. 1p/Q que acrescenta campos de prioridade e de Quality of Service (QoS) ao frame

Ethernet tradicional;

· Canal full duplex para eliminar colisões;

· Rede Fast Ethernet no backbone levando a velocidade a até 200 Mbps.

QoS (quality of service) é uma maneira de alocar recursos em switches e roteadores de tal forma

que os dados cheguem ao seu destino de forma rápida, consistente e confiável.

15.6. EVOLUÇÃO DO QUADRO ETHERNET



F igura 190: Quadro Ethernet S imp les e com TAG mostrando Pr ior idade

O standard 802.1p (e IEEE 802.1Q) propicia 8 níveis de prioridades. Entretanto a maior parte dos

switches de mercado possui apenas de 2 a 4 filas de mensagens.

Alguns switches podem não tratar o campo de tag. Neste caso, apenas quadros de até 1518 bytes,

fora o preâmbulo e o SFD, serão enviados. O quadro estendido de 1522 bytes não será passado à frente. A

prioridade 6 será reservada para aplicações de áudio, a prioridade 5 para aplicações de vídeo e a prioridade

0 para e-mails.

Os switches que tratam este quadro são os switches de camada 2. Outros switches irão trabalhar

com campos de informação de prioridade pertencentes às camadas 3 (IP) e 4 (UDP ou TCP).



F igura 191: Quadro Ethernet S imp les e com Quadro IP , mostrando Campo ToS

F igura 192: Quadro Ethernet com Quadro IP de UDP / TCP



15.7. ARQUITETURA EM ANEL X BARRAMENTO

A rede em anel traz como vantagem uma economia de cabos quando implementando redes com

redundância.

F igura 193: Arqu i te tura em Ane l e Barramento

15.8. ARQUITETURAS DE ROTEAMENTO

A Figura 194 e a Figura 195 mostram a evolução de uma rede Ethernet convencional para uma

rede com QoS implícito, isto é, obtido através de uma engenharia cuidadosa na atribuição de portas

exclusivas a cada dispositivo e na escolha das bandas de passagem. O último estágio é o QoS explícito, em

que a aplicação solicita serviços que garantem um caminho de comunicação livre de atrasos e de erro.



F igura 194: Rede Ethernet Convenc iona l

F igura 195: Rede Ethernet com QoS Imp l ic i to no Pro je to



F igura 196: Rede Ethernet com QoS Exp l ic i to

15.9. QUALITY OF SERVICE (QOS)

A responsabilidade de determinar o desempenho de uma aplicação é dividida entre o

desenvolvedor da aplicação e a pessoa que define a arquitetura da rede. Antes o projetista da aplicação

considerava que a performance da rede não era problema seu e considerava que a banda disponível era

infinita. Hoje existem formas explícitas de se requisitar serviços especiais para a rede para atender

aplicações críticas no tempo.

Prioritização do tráfego.

O tempo de latência de switch é o tempo que um switch detém um pacote de dados, até liberá-lo ao

destino. Prioritização de dados é o nome dado ao processo de aceleração da passagem de pacotes de

dados de alta prioridade.

A prioritização de dados pode ser explícita ou implícita.



15.9.1. Prioritização Implícita

Um switch Ethernet ou a rede inteira aloca automaticamente níveis de serviços baseado em critérios

especificados pelo administrador da rede tais como: tipo da aplicação, protocolo, ou endereço fonte. Cada

pacote recebido é filtrado para verificar se ele obedece a um destes critérios.

QoS implícito deve ser engenheirado na rede e oferece recursos de fácil implementação. Um switch

Ethernet pode priorizar tráfego baseado no endereço fonte ou destino ou no porte físico, por exemplo. Este

tipo de solução é, entretanto mais difícil de ser modificado, atendendo às mudanças de necessidade das

aplicações.

15.9.2. Prioritização Explícita

No QoS explícito, uma aplicação requisita uma certa qualidade de serviço e os switches e

roteadores tentarão cumprir o especificado.

Várias técnicas estão hoje disponíveis:

IP Type of Serv ice ( IP ToS)

Esta é a técnica que vem ganhando maior popularidade atualmente, principalmente devido ao seu

uso para aplicações de Voice Over IP (VOIP). ToS Faz parte da definição da norma IPv4. É reservado um

campo de 8 bits no pacote IP para especificação do tempo de atraso, throughput e confiabilidade.

Padrões mais recentes conhecidos como serviços diferenciados (RFC 2474), participam o campo

em dois sub campos: DSCP(6 bits) e CU (2 bits). O DSCP define 64 códigos de prioridade divididos em 3

classes:

Pool 1: DSCP = [0... 31] reservado para ações padrões (por exemplo, VOIP).

Pool 2: DSCP = [32... 47] reservado para uso local ou experimental.



Pool 3: DSCP = [48... 63] reservado par uso local ou experimental.

Estes campos já podem ser definidos pela função set sockopt () da última versão da biblioteca

Winsock. Hoje este protocolo tem sido mais utilizado em aplicações multimídia. O cabeçalho Ipv6 possui um

campo correspondente denominado classe de tráfego. Este campo tem a mesma função e localização do

campo ToS.

F igura 197: Quadro Ethernet S imp les e com Quadro IP , mostrando Campo ToS

Resource Reservat ion Protocol (RSVP)

RSVP possui os seus próprios mecanismos de comunicação de uma aplicação com a infra-estrutura

de rede. RSVP implica em um overhead de processamento que pode degradar a performance do sistema

como um todo.

Integrated Serv ice over Spec i f ic L ink Layers ( ISSLL)



Especifica extensões da arquitetura IP que permite a uma aplicação requisitar e receber um certo

nível de serviço da infra-estrutura de rede. ISSSLL pode, por exemplo, definir como pedidos RSVP serão

mapeados em prioridades 802.1p/Q.

Uma vez que o dado é priorizado utilizando um mecanismo implícito ou explícito, filas e algoritmos

de gerenciamento são utilizados nos equipamentos de rede para garantir o QoS. As filas são área de

memória dentro de roteadores ou switches e contém pacotes de diversas prioridades. Deve-se

proporcionar uma melhor qualidade de serviço aos pacotes de maior prioridade enquanto se assegura que

os pacotes de menor prioridade continuem a receber algum serviço.

Se houver um congestionamento, não haverá garantia de que os pacotes irão chegar a seu destino

dentro do tempo especificado. Apenas se garante que os pacotes de maior prioridade serão encaminhados

antes dos de mais baixa prioridade.

Uma maneira de se implementar isto é se reservar uma banda de passagem para o tráfego de alta

prioridade. Se o tráfego exceder esta reserva, mais banda poderá ser retirada das aplicações de baixa

prioridade.

Os algoritmos mais básicos tratam os pacotes de uma fila por ordem de chegada. Isto faz com que

grandes pacotes possam atrasar o envio de pacotes pequenos de dados de mesma prioridade.

Em geral, os switches hoje disponíveis no mercado oferecem poucas filas para organizar o tráfego

de dados. A Hirshman, por exemplo, possui um algoritmo denominado Real Time Queueing (RTQ) que

garante que uma fila de tempo real será sempre atendida antes de uma fila de baixa prioridade. No pior

caso, se uma transmissão de baixa prioridade já estiver sendo realizada quando um pacote de alta

prioridade chegar, ele vai ter que esperar apenas o equivalente a um quadro Ethernet (1519 bytes).

15.9.3. Vídeo sobre IP

A rede Ethernet também é usada hoje para transmissão de vídeo em tempo real a taxas

moderadas.



F igura 198: V ídeo sobre IP

15.10. PERFORMANCE DE REDES ETHERNET

F igura 199: Per formance Comparat iva de Redes Ethernet

Vamos comparar a performance de uma rede Ethernet Industrial com uma rede Fieldbus

convencional.



Vamos considerar uma rede Profibus DP na sua velocidade máxima: 12 Mbps.

Na verdade a velocidade desta rede depende do seu comprimento total e de outros fatores. Nós

consideramos a existência de um mestre (CLP) e de 31 dispositivos escravos. Esta rede pode alcançar um

tempo de scan de 1 ms para transmissão de 8 bytes de dados de entrada e 8 bytes de saída.

Na rede Ethernet não existe compromisso entre comprimento da rede e velocidade.

Dois parâmetros serão usados na avaliação das redes:

· Tempo de scan;

· Variância de recepção.

Tempo de scan:

Corresponde ao tempo total desde o envio de uma pergunta a um certo número de dispositivos de rede

e o recebimento de todas as respostas.

Var iânc ia de recepção:

Tempo de atraso entre o primeiro e o último dispositivo recebendo o mesmo datagrama. Neste caso

será o atraso de recepção do dado pelo nodo 31 em relação ao nodo 1. Esta é uma constante de rede

derivada de uma combinação de tempo de latência de equipamento e topologia de rede.

Serão estudados quatro cenários que dependem da velocidade de cada tipo de link na rede

Ethernet:



F igura 200: Ve loc idade de L inks

Vamos considerar que:

· A rede é formada de 4 clusters de 8 dispositivos cada. O primeiro cluster contém um mestre (CLP) e sete

escravos;

· Vamos considerar um payload mínimo de 46 bytes nesta aplicação, mesmo que nem todos os bytes

estejam sendo usados;

· O protocolo utilizado na transferência de dados será o TCP/IP;

· O tempo necessário para o escravo responder uma recebida uma requisição é 0;

· Parte do payload será utilizada para o transporte de 20 bytes de cabeçalho do protocolo IP e 8 bytes de

UDP.

· O pacote Ethernet completo possui 72 bytes;

· Para comunicar com todos os blocos simultaneamente será usada uma mensagem de broadcast.



F igura 201: Mensagem de Broadcast

15.11. CÁLCULO DO TEMPO DE LATÊNCIA

Cons iderações:

Tempo para t ransmit i r 72 bytes pe lo meio f ís ico (576 b i ts) :

T = 576 bits / 10 * 106 bits/s = 57,6 ms

Os tempos para transmitir 72 bytes pelo meio físico, incluindo o gap entre quadros é:

F igura 202: Ve loc idade de Tx

O tempo de latência do switch será considerado de 4 ms.

15.12. CÁLCULO DO TEMPO DE SCAN

· Será enviada uma mensagem de multicast para todos os nados e recebidas as respostas dos 31

dispositivos;

· Estamos assumindo que não existe tráfego adicional na rede.



F igura 203: Tra fego de Scan

Estamos admitindo que os tempos críticos sejam-nos 4 hops principais:

Hop 1: Mestre para rede:

A mensagem de ENQ sai do mestre e vai para todos os blocos de I/O. A mensagem é de um para

muitos e não há gargalo.

Hop 2: Rede para escravo:

A mensagem vai da rede para cada escravo através de um link de 10 Mbps. A relação é de uma

para um e não gargalo. O tráfego interno na rede está sendo desprezado.

Hop 3: Escravo para rede:

Cada escravo responde para a rede através de uma mensagem. A relação é de um para um e não

há gargalo.

Hop 4: Rede para mestre:



A rede deve entregar 31 mensagens para o mestre através de uma única porta. A relação é de

muitos para um e haverá enfileiramento de dados. O tempo de scan aproximado é dado por:

(tempo de transmissão do quadro na velocidade de cada hop).

Neste caso em que os hops são em 10 Mbps:

Tempo de scan = 4 * 67.2 ms = 268,8 ms.

Observe que foi utilizado o tempo de transmissão considerando o gap entre quadros.

F igura 204: Tempo de Transmissão

Para os cálculos de variância será considerado o tempo de atraso de transmissão de 57,6ms ao

invés de 67,2 ms (10 Mbps).



F igura 205: Cá lcu lo de Var iânc ia

O valor da variância de recepção é de 148,3 – 119,2 = 29,1 µs.

Cálculo aproximado do tempo de scan:

F igura 206: Cá lcu lo do Scan

Tempo de scan = 34 * 67,2 µs = 2285 µs



F igura 207: Tempo de Transmissão

F igura 208: Var iânc ia de Recepção

O valor da variância de recepção é de 96,46 – 67,36 = 29,1 µs.



Cálculo aproximado do tempo de scan:

F igura 209: Tempo de Scan

Tempo de scan = 2 * 67,2 ms + 32 x 67,2 µs = 349,4 µs.



ANOTAÇÕES



16. ENDEREÇAMENTO IP

F igura 210: " In ternet abr i um Novo Mundo de Poss ib i l idades . . .

O protocolo TCP/IP utiliza três esquemas para encaminhar dados através das redes até o hospedeiro:

1. Endereçamento: O endereço IP que identifica cada host na Internet.

2. Roteamento: Gateways encaminham dados para a rede correta.

3. Mult ip lexação: Protocolo e número do port encaminham dados ao módulo correto de SW no

host.

Neste capítulo estudaremos de forma prática o endereçamento IP.

O endereço IP foi estabelecido pela norma IP versão 4 (IPv4) como um endereço de 32 bits

possibilitando 232 (4 294 967 296) diferentes endereços. Este endereço é totalmente abstrato e define um

endereço único para cada host ligado numa rede heterogênea independente do hardware e do sistema

operacional utilizados. A camada IP utiliza este endereço, inserindo-o como destinatário em cada pacote de

dados enviado.

O endereço é constituído de duas partes: Número da rede e Número do Host.



A fim de propiciar a flexibilidade necessária para suportar diferentes tamanhos de rede, os

endereços foram divididos em 3 classes principais de endereços (classful addressing):

F igura 211: T ipos de C lasses

Pode-se também falar de uma classe D reservada como endereço de multicasting.

Este assunto foge ao escopo desta apostila. Maiores detalhes sobre IP multicasting podem ser

encontrados na referência [IPMI 97].O prefixo nesta "classe" é 1110.

A classe E tem prefixo 1111 e está reservada para uso experimental.

Noções de multicasting

Para suportar IP multicasting tanto os computadores que enviam e recebem as mensagens como

switches e roteadores devem suportar este tipo de atividade. Os computadores devem suportar o protocolo



IGMP (Internet Group Management Protocol), os cartões de interface de rede devem ser capazes de

reconhecer endereços da classe E deve haver disponibilidade de software aplicativo para este fim como por

exemplo aplicativos para vídeo conferência. Todos os roteadores e switches devem ser multicasting enable.

Um host desejando participar de uma conversação deve realizar um jo in a um host group, um grupo de

computadores identificados por um único endereço classe D. Quando terminar a conversação um host pode

abandonar um grupo efetuando uma operação de leave. Um host pode ser membro de mais de um grupo

ao mesmo tempo. Um mesmo endereço de grupo pode ser utilizado em diversas sessões simultaneamente,

em diferentes números de ports, em diferentes sockets, em uma ou diversas aplicações. Diversas aplicações

em um host podem utilizar um único group address.

Os endereços IPs são associados com interfaces de rede e não com os computadores em si. Um

gateway é visto pelas duas redes que o compartilham através de endereços diferentes. Um roteador possui

diversos endereços.

16.1. REDES CLASSE A

Cada endereço de rede da classe A possui 8 bits de prefixo de rede com o bit mais significativo definido para

0 e um número de rede de 7 bits, seguido por um número de host de 24 bits. Mais modernamente redes de

Classe A são chamadas de /8 (pronuncia-se barra 8) porque apresentam prefixos de rede 8 bits.

F igura 212: Endereços Espec ia is



16.2. REDES CLASSE B

Cada endereço de rede da classe B possui 16 bits de prefixo de rede com os dois bits mais

significativos definidos para 10 e um número de rede de 14 bits, seguido por um número de host de 16 bits.

Mais modernamente redes de Classe B são chamadas de /16 porque apresenta prefixo de rede 16 bits. Os

endereços de classe B têm-se esgotado rapidamente.

F igura 213: Redes /16

16.3. REDES CLASSE C

Cada endereço de rede da classe C possui 24 bits de prefixo de rede com os três bits mais

significativos definidos para 110 e um número de rede de 21 bits, seguido por um número de host de 8 bits.

Mais modernamente redes de Classe C são chamadas de /24 porque apresentam prefixos de rede 24 bits.

F igura 214: D iv isão do Espaço de Endereçamento IPv4 para Endereços C lass fu l l



O padrão Ipv6 pressupõe a extensão do endereçamento IP para 128 bits.

16.4. ENDEREÇOS ESPECIAIS

Alguns endereços são reservados e não podem ser utilizados para endereçar computadores na

rede:

16.4.1. Endereço do Computador

O endereço 0.0.0.0/8 significa “este computador”. Este endereço é usado pelo protocolo de start

up de um computador para obter o endereço IP do próprio host. Como o próprio protocolo IP é utilizado

para este fim e este protocolo exige um endereço fonte o endereço 0.0.0.0/8 é utilizado.

16.4.2. Endereço de Loopback

O endereço cujo prefixo é 127/8 é utilizado para testar uma aplicação TCP/IP no próprio

computador. Dois programas que querem se comunicar via rede podem ser testados desta forma. Toda

mensagem enviada para o endereço de prefixo 127. Por exemplo, 127.0.0.1 é roteado para o outro

programa tentando receber do mesmo endereço.

16.4.3. Endereço da Rede

O endereço que começa com um prefixo de rede e é seguido de zeros serve para designar o prefixo

atribuído à rede e não os computadores da rede. Por exemplo, o endereço 150.164.0.0/16 serve para

designar a rede, que recebeu o prefixo 150.164.

16.4.4. Endereço de Broadcast

O endereço prefixo seguido de 1s serve para enviar um pacote para todos os hosts de uma rede

(endereço de broadcast).

16.5. NOTAÇÃO DECIMAL COM PONTO

Ao invés de representar o endereço IP por 32 bits binários é melhor representar cada byte por um

número decimal, apenas para facilitar a interface com humanos.



F igura 215: Notação Dec ima l

Problemas do endereçamento por classes puras:

a) Esgotamento dos endereços IP, principalmente os da classe B.

b) Aumento do tamanho das tabelas de roteamento nos roteadores.

Como as tabelas de roteamento estavam crescendo e os administradores tinham que pedir novos

números de rede à Internet toda vez que necessitavam instalar uma nova rede em seu site, foi criado um

segundo nível na hierarquia de endereços IP. Esta arquitetura em 3 níveis se chamou de subnetting.

Subnetting divide um único endereço de rede em vários endereços de subrede de tal forma que cada rede

física tenha seu próprio endereço.

Hierarquia de 2-níveis (Classful):

Hierarquia em três níveis (Subnet):



Subnetting resolveu o problema da expansão das tabelas de roteamento, garantindo que a

estrutura de subrede de uma rede não é visível fora da rede privada da organização. A rota da Internet

para qualquer subrede de um dado endereço IP é a mesma, independente de em qual subrede o host

esteja. Os roteadores dentro da organização é que irão diferenciar entre as subredes individuais. Na

tabela do roteador da Internet todas as subnets da organização estarão mapeadas em uma entrada

única.

F igura 216: Endereçamento da Rede e Tabe la de Roteamento

Os roteadores da Internet utilizam somente o prefixo de rede do endereço de destino para rotear

uma mensagem para uma subnet. Os roteadores locais dentro do ambiente da subnet utilizam o prefixo de

rede estendido para rotear o tráfego até o host local.

Endereço de Rede Estendido = Network-Prefix + Subnet-Number:

Existem duas maneiras de se identificar o prefixo de rede estendido: pela máscara de subrede

(tradicional) ou pelo número de bits que forma o prefixo (notação CIDR).

Exemplo

Se você recebeu o endereço /16: 130.5.0.0 e você deseja usar o terceiro byte para representar o

endereço de sub rede, então devemos usar a máscara: 255.255.255.0



Pre f i xo de rede Número subrede Número host

Endereço IP: 130.5 .5 .25 10000010.00000101. 00000101. 00011001

Máscara subrede: 255.255.255.0 11111111.11111111. 11111111. 00000000

Notação CIDR (Classless Interdomain Routing)

Ao invés de usar o endereço IP mais a máscara de sub rede como acima, podemos escrever

apenas: 130.5.5.25/24. O número 24 designa o número de bits no prefixo de rede.

Embora a notação de endereço acima seja a mais moderna, os protocolos da Internet ainda exigem

a máscara de subrede.

16.6. PROJETO DE SUBREDES

Inicialmente responda às seguintes perguntas:

1) Qual o número de subredes existentes na organização hoje ?

2) Qual o total de subredes necessárias na organização no futuro ?

3) Qual o número de hosts existentes na organização hoje ?

4) Qual o número de hosts necessários na organização no futuro ?

Reserve o número de bits necessários para cada campo deixando uma margem para expansão

futura.

Exemplo

Uma organização possui o endereço 193.1.1.0/24 e necessita de 6 subredes. O número máximo de

hosts a serem suportados é 25.

Número de bits para subredes: 3

Número de bits para hosts: 5



193.1.1.0/24 = 11000001.00000001.00000001.00000000

Máscara: 11111111.11111111.11111111.11100000 = 255.255.255.224

Endereço estendido: 193.1.1.0/27

Base Net: 11000001.00000001.00000001.00000000 = 193.1.1.0/24

Subnet #0: 11000001.00000001.00000001. 000 00000 = 193.1.1.0/27

Subnet #1: 11000001.00000001.00000001. 001 00000 = 193.1.1.32/27

Subnet #2: 11000001.00000001.00000001. 010 00000 = 193.1.1.64/27

Subnet #3: 11000001.00000001.00000001. 011 00000 = 193.1.1.96/27

Subnet #4: 11000001.00000001.00000001. 100 00000 = 193.1.1.128/27

Subnet #5: 11000001.00000001.00000001. 101 00000 = 193.1.1.160/27

Subnet #6: 11000001.00000001.00000001. 110 00000 = 193.1.1.192/27

Subnet #7: 11000001.00000001.00000001. 111 00000 = 193.1.1.224/27

Def in ido o endereço de broadcast para cada subnet :

O endereço de broadcast da subnet é o endereço estendido da subnet com todos os bits de host

setados para 1.

Exemplo

Endereço de broadcast para subnet 6:

Subnet #6: 11000001.00000001.00000001. 110 11111 = 193.1.1.223/27

16.7. ROTEAMENTO

Quando o host destino está na mesma rede local, o dado é enviado ao host.

Quando o host destino está numa rede remota, o dado é enviado a um gateway local.



O protocolo IP toma decisões de roteamento baseado na porção network do endereço. Se a rede

destino for a rede local, a máscara de subrede local é aplicada ao endereço destino.

As decisões de roteamento são tomadas após consulta à tabela de roteamento.

Para exibir a tabela de roteamento em sistema UNIX:

Netstat - nr (routing / numeric form)

Exemplo

Netstat - nr

Routing tables

F igura 217: Nesta t

Formato:

F igura 218: Formato



Observar :

- A primeira entrada da tabela é a rota loopback para o host local. Todo sistema usa esta rota para enviar

datagramas para si mesmo.

- A entrada default serve para constituir a rota default que é buscada quando nenhuma rota específica

atende um endereço de rede. Neste caso a mensagem é enviada pelo gateway default.

- Este host está conectado à rede 128.66.12.0 já que a entrada para esta rede na tabela não especifica um

gateway externo (Flag G não está ativada).

Exemplo

F igura 219: Roteamento de Mensagens Através de um Gateway

Suponha que o host 128.66.12.2 queira se comunicar com o host 128.66.1.2.

Para determinar o endereço de rede do nodo destino, o host fonte aplica a subnet mask

255.255.255.0 ao endereço 128.66.1.2.

O endereço da rede destino será, portanto: 128.66.1.0 Consultando a tabela, vemos que para

enviar dado para a rede 128.66.1.0 devemos enviá-lo ao gateway 128.66.12.3. Este gateway reenvia a

mensagem através da interface 128.66.1.5.



A tabela de roteamento apenas aponta para o próximo gateway (nexthop).

16.8. VARIABLE LENGTH SUBNET MASKS (VLSM)

Quando uma rede IP permite o uso de mais de uma máscara de subnet, ela considerada uma rede

com tamanho variável de máscaras de subrede, uma vez que os prefixos estendidos de rede possuem

diferentes comprimentos. Protocolo RIP-1:

Permite apenas uma máscara de subrede, porque ele não provê informação de submáscara como

parte de suas mensagens de atualização de tabela.

As vantagens de se usar múltiplas máscaras de subrede são:

- Permite um melhor aproveitamento o espaço de endereçamento IP.

- Permite maior agregação de rota, o que pode reduzir significamente a quantidade de informação de

roteamento trafegando no backbone.

16.9. MELHOR APROVEITAMENTO DO ESPAÇO DE ENDEREÇAMENTO

Uma submáscara única implicava em se ter um número fixo de subredes, cada uma com um

tamanho fixo.

E x e m p l o

Endereço IP: 130.5.0.0/16

Prefixo estendido de rede: /22

Prefixo de rede subnet host number

130.5.0.0/22 = 10000010. 00000101. 00000000 00000000

São permitidas 64 subredes, cada uma com 1022 hosts.



Existem na organização algumas subredes pequenas de 20 ou 30 hosts.

Usando um endereço /22 cerca de 1000 endereços serão desperdiçados por subrede.

Solução: usar mais de uma máscara de subrede.

Por exemplo, suponha que seja possível usar uma segunda máscara /26.

Pre f i xo de rede subnet host number

130.5.0.0/26 = 10000010. 00000101. 00000000 .00000000

Esta nova máscara permite usar 1024 subredes cada qual com 62 endereços. O prefixo /26 é ideal

para pequenas subnets com menos de 60 hosts enquanto o prefixo /22 é melhor para subnets grandes

contendo até 1000 hosts.

16.10. AGREGAÇÃO DE ROTAS

VLSM permite uma divisão recursiva do espaço de endereçamento para que ele seja agregado de

forma a reduzir a quantidade de informação de roteamento no nível superior. Esta divisão permite que

informação de um grupo de subrede seja escondida de roteadores em outro grupo de subrede.

F igura 220: D iv isão Recurs iva de um Pre f ixo de Rede



F igura 221: Agregação de Endereço

A Figura 221 ilustra como uma alocação correta de VLSM reduz o tamanho das tabelas de rotas da

organização. O roteador D pode sumarizar todas as 6 subredes através dele em um único endereço de

propaganda (11.1.253.0/24) e o roteador B pode agregar todos os seus endereços na propaganda

11.1.0.0/16. O roteador C sumariza os seus endereços no endereço 11.253.0.0/16 e finalmente, uma vez

que a estrutura do subnet não é visível fora da organização, o roteador A injeta uma única rota na tabela de

roteamento global da Internet: 11.0.0.0/8 (ou 11/8).

16.11. DHCP – DYNAMIC HOST CONFIGURATION PROTOCOL

Este protocolo permite a um servidor configurar dinamicamente os endereços IP em uso em uma

rede aliviando o administrador da rede da tarefa de configurar cada host individualmente. Ao invés de

configurar para cada nó o endereço IP, a máscara de subrede, o endereço do gateway padrão, chamado

quando um endereço não pertence à subrede, e às vezes o endereço dos servidores de WINS (Windows

Name Server) e DNS (Domain Name Server), pode utilizar um protocolo aberto padrão que irá configurar

automaticamente todos estes parâmetros. O servidor DHCP deve ser informado de uma faixa de endereços

IPs disponível denominado escopo DHCP.

Isto traz grandes vantagens:



- Se um host for mudado de subrede, o servidor DHCP desta subrede irá associar um novo endereço IP a

este nó.

- Toda a configuração é feita em um ponto central eliminando a necessidade do administrador ir a cada

máquina para configura-la. O administrador também é capaz de visualizar todas as informações de cada

máquina individualmente remotamente.

- DHCP previne que dois hosts tenham o mesmo endereço IP.

- Existe redução da chance de erros de digitação.

Quando o cliente é inicializado, o TCP/IP parte e o cliente solicitam um endereço ao servidor DHCP

através do pacote DHCPDISCOVER. O servidor oferece ao host um dos endereços válidos do seu escopo

através da mensagem DHCPOFFER. O cliente aceita o primeiro endereço de um host DHCP e envia a

mensagem DHCPREQUEST com o endereço recebido. O servidor envia uma mensagem de confirmação

DHCPACK e aluga o endereço por certo tempo ao host. Após 50% de o tempo ter expirado e até 87.5% do

tempo, o host solicita uma renovação do aluguel. Caso o servidor não responda o cliente é obrigado a

abandonar o endereço e recomeçar o processo de obtenção de um endereço IP.



ANOTAÇÕES



17. PRINCIP IOS DA COMUNICAÇÃO TCP- IP

17.1. TCP/IP ("TRANSMISSION CONTROL PROTOCOL / INTERNET PROTOCOL")

TCP/IP é na verdade o nome genérico para uma família de protocolos e utilidades também

conhecido por Internet Protocol Suite, onde suite designa uma pilha (stack) de protocolos. Estes protocolos

originalmente faziam parte Internet, uma WAN (Wide Area Network) que evoluiu a partir da ARPANET

(Advanced Research Projects Agency Network) criada pelo United States Department of Defense (DoD), para

interligar centros de pesquisa que trabalhavam para o governo.

TCP/IP é hoje o padrão de facto na interligação de redes heterogêneas locais (LAN), a grande

distância (WAN) e na Internet.

Comparado ao padrão OSI/ISO os protocolos TCP e IP correspondem aos níveis de transporte e de

rede. Assim a suite Internet pode rodar no topo das redes tradicionais como Ethernet, IEEE 802.3, token-

ring, etc.

F igura 222: S tack OSI/ ISO x S tack TCP/ IP

17.2. CAMADA IP

Os serviços proporcionados por esta camada se referem basicamente ao endereçamento e

roteamento e a segmentação de pacotes de modo a compatibilizá-los com os padrões adotados pelas duas

entidades comunicantes. O serviço básico proporcionado é o de datagrama.



Endereçamento: Os endereços dos pacotes IP possuem 32 bits para fonte e destino. Os 3 bits mais

significativos indicam como os 29 bits restantes serão interpretados (divisão entre endereço da rede e

endereço da estação na rede).

Roteamento: Para o roteamento, a estação fonte irá determinar se a estação destino faz parte da

rede local. Neste caso o pacote é enviado diretamente ao destino. Se o destino não pertencer a mesma rede

local, uma tabela é consultada para verificar para qual gateway o pacote deve ser enviado. O gateway deverá

conduzir o pacote ao seu destino final.

17.3. CAMADA TCP

É responsável pela integridade da comunicação fim-a-fim. O TCP utiliza o conceito de ports para

implementar múltiplas sessões. Cada porta promove uma conexão virtual com a aplicação. Os pacotes

possuem um número de seqüência.

Quando todos os pacotes são recebidos na ordem correta, uma confirmação é emitida. O usuário

pode escolher entre o uso do pacote TCP que possui 38 bytes de controle mais dados ou de um pacote UDP

(User Datagram Protocol) que possui apenas 8 bytes de endereçamento e controle. Somente o pacote TCP

possui mecanismos que garantem a integridade da transmissão.

F igura 223: Dependênc ia Entre Protoco los TCP/ IP de ma is A l to N íve l



F igura 224: Arqu i te tura do Protoco lo TCP/ IP segundo Microso f t

F igura 225: Pacote UDP: Header de 8 Bytes



F igura 226: Pacote TCP: Header de 24 Bytes

17.4. SERVIÇOS E UTILITÁRIOS DE ALTO NÍVEL

Os utilitários da suite TCP/IP permitem realizar basicamente 5 funções:

• Transferência e compartilhamento de arquivos;

• Login remoto;

• Enviar e receber mensagens;

• Spool de impressora;

• Enviar e receber mensagens via rede.

17.5. APLICAÇÕES

17.5.1. DNS (Domain Name Service)

Trata-se de um protocolo de nomes que traduz os nomes das máquinas na rede para um endereço

IP de 32 bits. A estrutura de nomes é hierárquica, sendo cada nome formado por labels espaçados por

pontos:



Exemplo: www.ugf.br

Os nomes podem seguir uma orientação geográfica, departamental, etc. Um processo cliente

denominado de name resolver se encarrega de comunicar com os names servers que são processos

acessando as tabelas de endereços distribuídas pela rede também de forma hierárquica.

17.5.2. TELNET

TELNET propicia uma comunicação bidirecional orientada a byte entre dois nodos da rede. Sua

maior utilização reside na emulação de terminais remotos.

TELNET permite a um usuário estabelecer uma conexão TCP com um servidor de login remoto e

depois passar a ele todas as teclas acionadas no terminal como se tivessem sido introduzidos em um

terminal conectado à máquina remota.

TELNET envia a resposta da máquina remota diretamente ao terminal do usuário.

Para acessar a máquina remota, o usuário precisa conhecer o seu nome de domínio ou o seu

endereço IP.

Para conseguir o efeito de transparência o TELNET define um formato intermediário denominado

NVT (Network Virtual Terminal). O processo cliente traduz os caracteres enviados para NVT sem precisar

conhecer os detalhes de implementação do terminal remoto.



F igura 227: Te lnet

Normalmente o formato NVT usa apenas os 7 bits correspondentes ao código ASCII padrão. Os

bytes com MSb setado servem para indicar código de comandos. A sequência CR-LF é utilizada para final de

linha.

O caractere 0xFF é utilizado como caractere de escape para introduzir uma sequência de

comandos. Alguns destes comandos são usados para negociar opções no início do processo. Qualquer um

dos dois lados pode iniciar o processo de negociação.

17.5.3. Rlogin

No sistema operacional UNIX existe um utilitário que permite ao usuário possuir contas em várias

máquinas que podem ser logadas sem a exigência de password.

17.5.4. RSH

Este comando também é limitado ao OS UNIX e permite executar comando em outra máquina sem

login.

Exemplo: rsh nome_máquina p.s.

17.5.5. FTP - File Transfer Protocol

Controla o acesso e a troca de arquivos entre dois hospedeiros



F igura 228: F i le Trans fer Protoco l (FTP)

Entre as facilidades proporcionadas pelo FTP temos:

a) Acesso interativo:

Existem diversos comandos que permitem acessar o nodo remoto, por exemplo, para consultar um diretório.

b) Formatação:

O usuário pode especificar o formato dos dados nos arquivos (ASCII, binary).

c) Controle de autenticação:

O cliente deve entrar com o seu nome de login e senha para ter acesso a funções no nodo remoto.

FTP irá empregar duas conexões TCP/IP para realizar esta tarefa. Uma para trocar comandos e

respostas (control connection) e outra para movimentar arquivos (data transfer connection).

Para cada arquivo a ser trocado será criada mais uma conexão de dados, mas a conexão de

controle é única para toda a sessão e persiste após a transferência de arquivos.

Exemplo1 de uma sessão FTP

$ ftp

ftp> help

****** os comandos disponíveis são apresentados

ftp> help ls



ls list contents of remote directory

ftp> help cdup

cdup change remote working directory to parent directory]

ftp> help bell

bell beep when command completed

ftp> bell

Bell mode on

Exemplo 2 de uma sessão FTP

%ftp Arthur.cs.purdue.edu

Connected to arthur.cs.purdue.edu.

220 arthur.cs.purdue.edu FTP server (DYNIX V3.0.12) ready

Name (arthur:usera): anonymous

331 Guest login ok, send ident as password.

Password: guest

230 Guest login ok, access restriction apply.

ftp> get pub/comer/tcpbook.tar bookfile

200 PORT command okay.

150 Opening data connection for /bin/ls (128.10.2.1,2363) (7897088 bytes)

226 Transfer complete.

8272793 bytes received in 98.04 seconds (82 Kbytes/s)

ftp> close

221 Goodbye

ftp> quit

17.5.6. TFTP - Trivial File Transfer Protocol

É uma alternativa menor e mais simples de protocolo que propicia apenas transferência de arquivos

sem autenticação. Este tipo de protocolo pode ser colocado na EPROM de uma estação diskless para



bootstrap via rede. TFTP ao contrário do FTP não depende de um sistema de transporte confiável e pode

funcionar sobre UDP utilizando timeout e retransmissão para garantir a integridade dos dados. O nodo

servidor transfere arquivos em blocos de 512 bytes e espera confirmação de chegada bloco a bloco.

17.5.7. NFS - Network File System

Foi desenvolvido pela Sun Microsystems Inc. para proporcionar um compartilhamento de arquivos

"on-line", transparente e integrado.

O usuário pode fazer acesso a qualquer arquivo na rede, usando o nome do arquivo diretamente

sem distinguir se este é remoto ou local. Quando uma aplicação do usuário faz um acesso a disco, o sistema

de acesso a arquivos aceita a solicitação e automaticamente passa o pedido para o sistema de arquivos

local ou para o cliente NFS se o arquivo for remoto. Quando o servidor remoto responde, o resultado é

passado de volta a aplicação. Por exemplo, eu posso montar o diretório /home/ops de uma máquina remota,

na minha estação local com o nome /seixas/home/ops. Ao dar o comando ls /seixas/home/ops eu estarei

examinando o diretório do nodo remoto. Tudo de forma transparente.

O NFS foi construído sobre dois outros protocolos:

RPC (Remote Procedure Ca l l )

Permite fragmentar uma aplicação em parte local e procedimentos remotos.

Quando um procedimento remoto é acessado, uma mensagem é enviada pela rede, o procedimento remoto

é ativado e a resposta retorna via uma nova mensagem.

XDR (eXterna l Data Representat ion)

Permite troca de dados entre máquinas heterogêneas. XDR define uma representação interna de

dados. Um usuário pode chamar um procedimento XDR que irá converter os dados da sua forma de

representação para a forma intermediária. Os dados serão enviados a outra máquina e então convertidos

para a forma de representação remota. Requer o uso de um compilador especial XDR.

17.5.8. SMTP - Simple Mail Transport Protocol



Trata-se de um protocolo orientado para transferência de textos ("correio eletrônico"). Na verdade

os usuários transferem mais arquivos usando este protocolo do que usando qualquer outro utilitário TCP/IP.

Cada mensagem é composta basicamente de um cabeçalho contendo destinatário, remetente, assunto, etc e

o corpo formado por um texto ASCII. O cabeçalho é especificado pela referência 822.

O processo de envio de uma correspondência se dá em background. O processo cliente mapeia o

nome do destinatário no endereço IP e tenta estabelecer uma conexão TCP. Tendo sucesso, uma cópia da

mensagem é enviada para o servidor remoto, que a armazena na área de spool. Uma vez que cliente e

servidor concordem que a mensagem foi aceita e armazenada, o cliente irá remover a cópia local. Se a

conexão não for estabelecida, o processo de transferência anota a hora da tentativa e termina. O processo

em background examina a área de spool regularmente. Se ele achar uma mensagem pendente, ou se o

usuário depositar uma nova mensagem, ele tentará enviá-la de novo. Se uma mensagem permanecer muito

tempo como não expedida, uma mensagem será enviada para o emitente.

Outros protocolos:

ARP - Address reso lut ion protocol

Protocolo TCP/IP usado para ligar dinamicamente um endereço IP de alto nível com um endereço de

hardware de baixo nível.

RARP - Reverse Address Resolut ion Protocol

Protocolo TCP/IP usado por uma estação diskless para encontrar o seu endereço IP a partir do seu

endereço físico.

17.6. PROGRAMANDO O SEU PRÓPRIO CLIENTE OU SERVIDOR

O usuário pode programar diretamente a sua própria aplicação em C utilizando os recursos da rede.

Para usar o TCP, o usuário deve criar um socket e, associar endereços a ele, usá-lo através de primitivas de

leitura e escrita, e finalmente fechá-lo como se fosse um arquivo. Cada sistema operacional vem

acompanhado de uma biblioteca de funções conhecida no jargão UNIX como sockets library. Écomum o

fornecimento de um administrador que se encarrega de formatar os pacotes, enviá-los e recebê-los.



17.6.1. Performance

Numa comunicação implementada sobre uma rede nativa utilizando um sistema operacional de

tempo real como o QNX de ambos os lados, conseguimos obter cerca de 90% da faixa disponível. Usando-

se o protocolo TCP/IP, apenas cerca de 30% do trhoughput disponível é geralmente alcançado, já que

torna-se necessário converter os padrões nos extremos da rede para um padrão comum.

17.6.2. Sockets

A API WinSocks é baseada na API Berkeley sockets introduzida em 1982, inicialmente para o S.O.

UNIX. Os sockets BSD emulam descritores de arquivos como uma extensão do sistema de entrada e saída

por arquivos do UNIX. Através desta biblioteca pode-se utilizar funções padrões tais como read() e write(),

em Unix, para receber e transmitir dados. Os dois programas podem estar na mesma máquina, em máquinas

diferentes numa mesma rede, ou conectadas através da Internet. A comunicação através de sockets tem

grandes vantagens em relação à comunicação utilizando tecnologias baseada em camadas como CORBA e

DCOM, mais recentes e de maior apelo comercial,

• É mais eficiente;

• Permite execução em ambientes heterogêneos envolvendo diferentes plataformas: Windows, UNIX, etc;

• Desfrutam de grande aceitação no mercado. Grande parte dos protocolos utilizados na Internet (http, nntp

e smtp) utilizam a biblioteca de sockets.

Sockets suportam tanto protocolos orientados a conexão (stream sockets) quanto protocolos sem

conexão (datagram sockets).

Protocolos orientados a conexão:

• Utilizam circuito virtual (TCP no domínio Internet);

• Possuem transferência de dados buferizada;



• Proporcionam conexão full-duplex;

• Servidor atende a múltiplos clientes

Protocolos sem conexão:

• Baseado em datagramas (UDP no domínio Internet);

• Não são buferizados;

• São half-duplex;

• Mensagens podem ser perdidas, duplicadas ou chegar fora da ordem de envio;

• Servidor atende a um cliente por vez.

Existe um tipo especial de datagram socket denominado raw socket utilizado para controles e

protocolos de erros de roteamento, Raw sockets normalmente utilizam o protocolo ICMP (Internet Control

Message Protocol).

No WNT os protocolos de transporte não têm uma interface direta de sockets com a camada TCP/IP,

como em outros sistemas operacionais. O Winsock kernel model driver (afd.sys), que emula as funções de

sockets, ao invés disso, enxerga os protocolos de transporte através da Transport Driver Interface (TDI)

trazendo grande independência à aplicação em relação aos níveis inferiores de comunicação. A afd.sys

gerencia os buffers para a aplicação que quer falar com a camada de transporte. Quando o usuário emite

um WSASend() os dados são copiados para os buffers internos da AFD.SYS e a função WSASend() retorna

imediatamente, desde que o tamanho do buffer seja inferior ao limite máximo dado por SO_SNDBUF. O

mesmo mecanismo se aplica na recepção através de WSARecv() ou recv().

Se o usuário desabilitar a bufferização, fazendo SO_SNDBUF e SO_RCVBUF iguais a 0, a instrução

de envio, por exemplo, só se completará quando o outro lado da conexão aceitar todo o buffer. Isto causará

uma grande queda de performance à aplicação.



F igura 229: Arqu i te tura de Sockets no W indows 2000

Outros fatores limitadores de performance:

• Largura de banda da rede;

• Respeitar limites de recursos do sistema operacional;

• Gerenciamento da memória virtual utilizada pela aplicação. Manter o servidor sempre alocado em memória

RAM através de footprint pequeno, e cuidado na alocação dinâmica de memória. Pode-se aumentar a

quantidade de memória física usada por uma aplicação através de SetWorkingSetSize();

• Não manter um grande número de páginas locked na memória, para não esgotar os recursos para as

demais aplicações e causar crash de todo o sistema (máximo recomendado = 1/8 da RAM do sistema). Se

não usar o bufferização no envio ou recebimento de mensagens, os buffers da aplicação ficarão locked na

memória física;

• Respeitar o limite para a área do non paged pool (memória não paginada).

Os drivers do WNT e Windows2000 têm a habilidade de alocar memória de pool de memória não

paginada, que nunca é paged out a fim de ser usada por componentes do kernel. Criar um socket, abrir um



arquivo, realizar operação de binding ou conexão a um socket, operações de leitura e escrita pendentes,

tudo isso aloca memória no pool não paginado.

Se sua aplicação receber erros do tipo WSA ENOBUFS ou ERROR INSUFFICIENT RESOURCES:

• Aumente o Working Set da aplicação;

• Verifique se você não excedeu a largura de faixa do meio;

• Verifique se você não tem muitas operações de send e receive pendentes;

• Se não adiantar é porque você excedeu o limite de non paged pool. Feche algumas das conexões

pendentes e espere que a situação transiente termine.

F igura 230: DD Fonte de DD B inár io

A descrição do equipamento é interpretada por um software no computador host que traduz todas

as informações numa linguagem mais amigável. Este software é denominado serviço de descrição de



dispositivo ou DDS (Device Descriptor Services). O DD independe do sistema operacional utilizado pelo

sistema de controle.

Já está sendo desenvolvida uma padronização suplementar com o nome de EDDL (Electronic Device

Description Language) com o objetivo de tornar a apresentação dos dados do DD mais atraentes e

compatíveis com os padrões da Web.



17.7. PRINCÍPIO DE FUNCIONAMENTO

Programas baseados em sockets são geralmente aplicações cliente-servidor. O servidor espera

pedidos de seus clientes, os processa e retorna os resultados ao cliente. O cliente estabelece uma conexão

com o servidor, conectando-se a uma porta do servidor na máquina onde o servidor está sendo executado.

É preciso saber qual o número da porta de uma aplicação antes de se iniciar um processo de conexão.

17.7.1. Porta

Corresponde a um valor inteiro de 16 bits que serve para identificar aplicações, em um computador,

que utilizam serviços de conexão. As portas de 1 a 1023 são chamados de números de ports well known e

são reservados para os serviços padrões da Internet. Estes números são designados e controlados pela

IANA (Internet Assigned Numbers Authority).

Portas de 1024 a 5000 são denominados portas efêmeros e são geralmente usados por clientes.

Eles têm existência curta porque existem somente durante o período de tempo em que o serviço associado

está em uso.

Portas acima de 5000 são destinados a servidores que não estão conectados à Internet. As portas

de 1024 a 63535 estão livres para uso das aplicações do usuário.

Em geral utilizamos um endereço acima de 10000.

Valores reservados típicos:

F igura 231: Por tas e Ap l icações



17.7.2. Visualizando os Portas Livres

Para visualizar quais as portas utilizados em um computador local, use o programa netstat do WNT.

17.7.3. Mecanismo Cliente-Servidor Básico

Em aplicações de automação industrial, os protocolos orientados a conexão são os mais usados,

por questões de segurança. Apesar de serem mais lentos, propiciam uma confirmação fim a fim essencial a

este tipo de aplicação. Cliente e servidor necessitam realizar um ritual de conexão, troca de dados e

desconexão.

O bit SYN do cabeçalho TCP é usado para sinalizar que uma conexão está se iniciando e é

acompanhado do número inicial de sequência. No diagrama abaixo a estação A envia o quadro com SYN

ativado e o número de sequência que no caso é 10 para a estação B. B responde enviando uma

confirmação com o valor 11 que é o sequencial do próximo quadro que B espera receber. A estação B envia

o seu próprio número de sequência que no caso é 30 para a estação A que confirma o recebimento

enviando 31. Isto estabelece duas conexões. O envio passa a se dar simultaneamente nos dois sentidos

(comunicação full duplex).



F igura 232: Comunicação Fu l l Dup lex Ut i l i zando TCP

O fluxograma a seguir ilustra os principais passos de uma aplicação típica.

17.7.4. Aplicação Típica Sobre TCP no WNT:



F igura 233: F luxograma TCP no WNT

17.7.5. Aplicação Típica Sobre UDP no WNT:



F igura 234: F luxograma UDP no WNT



ANOTAÇÕES



18. COMUNICAÇÃO OPC (Automação Industr ia l )

O protocolo OPC foi desenvolvido primariamente para solucionar problemas de interoperabilidade

em sistemas de automação industrial, integrando dados entre os diversos níveis de suas redes.

Basicamente, consiste em um protocolo aberto, composto por diversas especificações em constante

desenvolvimento, tecnologicamente bastante ligado à tecnologia DCOM da MicrosoftTM. Nesta apostila é

apresentada uma introdução aos principais aspectos das comunicações em ambiente industrial, descrevem-

se as características fundamentais do protocolo OPC e apresentam-se estudos, teóricos e práticos, do seu

emprego em situações diversas. Os resultados encontrados nesses estudos são analisados e comparados.

Espera-se dessa forma disponibilizar uma fonte de consulta para profissionais de automação e controle que

necessitem entender o protocolo, suas funcionalidades e a viabilidade do seu emprego no problema que se

busca solucionar.

18.1. INTRODUÇÃO

O emprego de redes de supervisão e controle baseadas em protocolos de comunicação digital tem

crescido nas mais variadas plantas industriais. A diversidade desses protocolos e dos equipamentos

baseados nos mesmos (OPC FOUNDATION, 1998; PROFIBUS STANDARD, 2006; DEVICENET, 2006), bem

como a evolução de suas aplicações na indústria, acabou por gerar sistemas de automação de grande

complexidade, compostas por sub-redes heterogêneas de difícil interoperabilidade. A dificuldade de se

especificar todo um sistema empregando equipamentos de um único fabricante, comunicando-se através de

um mesmo protocolo, também tem contribuído nesse sentido. Além de ser virtualmente impossível em alguns

casos, tal abordagem não é desejável do ponto de vista de mercado, pela dependência que se cria de um

mesmo fornecedor.

Diante dessa realidade, o emprego de um sistema global de controle passa necessariamente por

ter-se um mecanismo de comunicação que guarde certa independência do protocolo empregado pelos

elementos finais de supervisão e controle, ou seja, dos instrumentos de campo. O OPC (OLE for Process

Control) surge como um protocolo de comunicação padronizado e aberto, desenvolvido por um grupo de

fabricantes de equipamentos em cooperação com a Microsoft, criadora do Windows, dedicado à promoção

da integração de redes industriais heterogêneas. Seu objetivo primário é permitir a troca transparente de

dados entre diversos tipos de aplicações, tanto gerenciais quanto de chão de fábrica (OPC FOUNDATION,

1998).



18.1.1. Plataforma Windows em Plantas Industriais

A crescente popularização do sistema operacional Windows e sua maciça presença em sistemas de

informática empresariais, acabaram por motivar os principais fabricantes de equipamentos e softwares para

controle industrial a desenvolverem sistemas baseados nessa plataforma. Tal fato contribuiu para diminuir o

abismo até então existente, sobretudo no aspecto interface homem-máquina, entre os sistemas de

automação e administração das indústrias. Pelo fato de aplicativos Windows já serem bastante utilizados nas

tarefas coorporativas (correio eletrônico, editores de texto, planilhas etc.), a própria operação dos sistemas

do ponto de vista do usuário médio foi facilitada.

Vencida tal etapa, o próximo passo seria o desenvolvimento de um padrão de comunicação capaz de

integrar verticalmente todos os níveis hierárquicos relacionados ao controle da produção (gerenciamento,

supervisão de processos, controle e equipamentos no chão de fábrica), facilitando o acesso à informação de

forma a acelerar tomadas de decisão. A solução aparentemente mais adequada consistia em adaptar-se

para controle de processos a tecnologia OLE/DCOM (Object Linking and Embedding/Distributed Component

Object Model), nativa do Windows, orientada a objeto e já bastante difundida em seus aplicativos.

Basicamente, a tecnologia OLE/DCOM permite encapsular componentes escritos em C/C++ (por exemplo,

drivers de comunicação) como interfaces padronizadas para serem utilizadas em programas de outras

linguagens de programação, eventualmente mais simples de serem utilizadas.

A presença dessa facilidade como interface entre programas motivou o desenvolvimento do padrão

OPC fortemente baseado no ambiente Windows. Nele especifica-se como uma aplicação pode acessar dados

de um processo independente de sua origem, o que permite que uma mesma aplicação atue em diferentes

barramentos de campo sem modificações.

18.1.2. OPC: Surgimento e Evolução

Antes do OPC, caso uma aplicação-cliente (sistema supervisório, por exemplo) requeresse acesso a

uma determinada fonte de dados do sistema, o próprio fabricante deveria desenvolver o driver necessário, o

que gerava os seguintes problemas:

• Duplicação de esforços: fabricantes de software desenvolvendo drivers distintos para o mesmo

hardware;



• Inconsistências entre drivers: funcionalidade do hardware indisponível da mesma forma por drivers de

fabricantes diferentes;

• Suporte a mudanças de funcionalidades de hardware: mudança de funcionalidade do hardware

levando drivers antigos à incompatibilidade;

• Conflitos de acesso: dois drivers independentes não podem (geralmente) acessar um mesmo

dispositivo simultaneamente.

Atentos a esses problemas, em 1995 alguns fabricantes de softwares de automação reuniram- se e

desenvolveram, com o suporte da Microsoft, o OPC. Sua primeira especificação (OPC Specification Version

1.0) foi apresentada em agosto de 1996. Nos anos seguintes, vários fabricantes aderiram ao padrão, o que

gerou a necessidade de modificações e acréscimos de funcionalidades cada vez maiores. Para que isso

ocorresse de forma coordenada, foi criada a OPC Foundation, uma entidade sem fins lucrativos destinada

exclusivamente à manutenção e divulgação do padrão OPC.

A estratégia adotada pela fundação para adição de novas especificações, atualizações, modificações

e manutenção da compatibilidade com versões anteriores, foi a de criar extensões à especificação original.

Em 1997 a primeira atualização da especificação foi liberada. Denominada OPC Data Access Specification

1.0A, tal especificação já refletia o novo modelo de extensões adotado.

Por conta do modelo de extensões, o OPC é hoje entendido não como uma especificação, mas sim

como um conjunto delas.

18.1.3. Objetivo e Estrutura

Esta apostila tem por objetivo apresentar um panorama da aplicação do protocolo OPC em redes

industriais como alternativa para integração e interoperabilidade de plantas heterogêneas.

No Capítulo 18.2. é apresentada uma descrição mais detalhada do protocolo OPC, sendo

aprofundados alguns conceitos computacionais envolvidos na sua criação. São também apresentadas e

discutidas as motivações e características de suas principais especificações.



No Capítulo 18.3. são apresentadas algumas aplicações do protocolo OPC em ambiente industrial,

discutindo-se vantagens e desvantagens observadas por seus realizadores nas situações descritas.

O Capítulo 18.4. traz algumas considerações sobre as perspectivas futuras para o emprego do

protocolo OPC em ambiente industrial.

18.2. FUNDAMENTOS DO OPC

18.2.1. A Tecnologia que Compõe o OPC

Nas próximas seções são apresentadas algumas das tecnologias utilizadas na implementação do

OPC, de forma a deixar mais claros alguns conceitos bastante empregados neste e nos próximos capítulos.

18 .2 .1 .1 . Programação Or ien tada a Ob je tos

A Programação Orientada a Objetos (POO) é um modelo de programação que procura descrever

entidades, reais ou abstratas, da forma como as vemos e percebemos, dentro de um determinado contexto

ou problema a ser resolvido.

Na POO, para cada entidade, os dados (também chamados de atributos) e procedimentos (também

chamados de métodos ou serviços) são agrupados (ou encapsulados) em um só elemento básico, chamado

de classe ou objeto.

As várias classes/objetos pertencentes a um mesmo sistema, se relacionam entre si através de

interfaces. Para uma interface é uma convenção precisa entre um cliente e um servidor, que dita como os

métodos devem ser chamados. Assim, um determinado objeto que necessite dos serviços de outro, não

precisa saber como este último implementa o código para realizar tal tarefa (como ele faz), apenas deve

conhecer a sua interface (o que ele faz).



Esta última propriedade é também conhecida como encapsulamento, e leva a uma das principais

vantagens da POO: a reusabilidade de código, que permite reduzir o tempo de desenvolvimento do software,

e, consequentemente, aumentar a produtividade.

18 .2 .1 .2 . RPC e DCE

Na década de 80, com o intuito de tornar possível a computação distribuída num ambiente multi-

plataforma para diversos aplicativos, um consórcio de companhias criou a OSF (Open Software Foundation),

que acabou por gerar um conjunto de especificações reunidas sob o termo DCE (Distributed Computing

Environment), em uso até os dias de hoje.

Os mecanismos de comunicação definidos pela OSF, também chamados de RPC (Remote Procedure

Call) ou Chamada de Procedimento Remoto, definem como os aplicativos podem se comunicar e como cada

um pode chamar funções ou métodos de outro, empregando para isso serialização (marshalling) e

desserialização (demarshalling). Tais procedimentos consistem basicamente na codificação e decodificação,

respectivamente, de parâmetros dependentes de um processo e sistema operacional específicos, em

parâmetros independentes dos mesmos, de forma que possam ser transportados em diferentes tipos de

rede.

O proxy é o componente deste sistema responsável pela serialização, enquanto o stub realiza a

operação inversa (desserialização). O cliente não chama um procedimento remoto no servidor, mas interage

diretamente com o proxy, que realiza a serialização e repassa a chamada ao stub. Este por sua vez

desserializa a chamada e a repassa diretamente ao servidor, onde o procedimento é realmente

implementado. A resposta do servidor (callback) é feita da mesma forma, na direção oposta. Isto permite

que toda a operação de chamada e resposta seja transparente ao cliente/servidor. Assim, através do RPC é

garantida ao usuário a flexibilidade para implementar-se procedimentos onde seja mais conveniente na rede,

de forma a atingir determinados objetivos de desempenho e/ou confiabilidade.

Na época do surgimento do RPC, a POO ainda não era o modelo de programação mais utilizado, o

que levou a Microsoft a adaptar esta tecnologia para o conceito de POO, já com interesse no

desenvolvimento do DCOM. O resultado desta adaptação resultou na designação ORPC (Object RPC).



F igura 235: Arqu i te tura do DCOM (Microso f t 1996)

18 .2 .1 .3 . DCOM

O DCOM nasceu a partir da tecnologia OLE (Object Linking and Embedding), que surgiu no início da

década de 90, para permitir a integração de dados entre aplicações no Windows. Isto permitia, por exemplo,

inserir uma planilha Excel em um documento do Word e, a partir deste último, acessar e editar de forma

dinâmica, todos os dados da primeira.

A abordagem do OLE foi estendida para outros tipos de aplicativos, na forma de um modelo orientado

a objetos disponível a todas estas aplicações, através dos chamados componentes. Esta tecnologia foi

batizada de Component Object Model (COM), em 1995 .

A necessidade de compartilhar estes componentes através da rede levou ao desenvolvimento do

DCOM, resultado da união das tecnologias COM e DCE RPC (mais especificamente, o ORPC).

Surgido em 1996, o DCOM utiliza o formato cliente-servidor e permite o acesso, através de

conexões e serviços, tanto de um servidor por vários clientes, quanto de um cliente por vários servidores.

Como no RPC, é transparente aos clientes a localidade de execução do componente do qual se utilizam os

serviços.

Como um modelo orientado a objetos, que também herda funcionalidades do RPC, o DCOM se

constitui basicamente de:

!"#

#

!"#$%&'()*'+%,$"-.-$%&'/0'1234'54627383!9:'*;;<='

()*)(! 1234'

$#%&$'#()*+,-#)#.)/01/#2)#0,+(34351)#$67#8!"#$%&'()*+)*,'-*.'/0"$..)*,9:#;-,#*-/51-#(3#

1(<+13#2)#2=+)2)#2,#">:#.)/)#.,/?101/#)#1(0,5/)@A3#2,#2)23*#,(0/,#).41+)@B,*#(3#C1(23D*E#F*03#

.,/?101):#.3/#,G,?.43:#1(*,/1/#-?)#.4)(14H)#7G+,4#,?#-?#23+-?,(03#23#C3/2#,:#)#.)/01/#2,*0,#

I401?3:#)+,**)/#,#,210)/#2,#J3/?)#21(K?1+):#0323*#3*#2)23*#2)#./1?,1/)#8FCLMFNO:#!>>!9E#

L#)P3/2)5,?#23#$67#J31#,*0,(212)#.)/)#3-0/3*#01.3*#2,#).41+)01Q3*:#()#J3/?)#2,#-?#?32,43#

3/1,(0)23#)#3PR,03*#21*.3(<Q,4#)#032)*#,*0)*#).41+)@B,*:#)0/)Q=*#23*#+H)?)23*#>[email protected]#

7*0)# 0,+(34351)# J31# P)01S)2)# 2,# 12032*$*&' !"#$%&' 42.$5' 8&$'9:# ,?# T""U# 8FCLMFNO:#

!>>!9E#

L#(,+,**12)2,#2,#+3?.)/014H)/#,*0,*#+3?.3(,(0,*#)0/)Q=*#2)#/,2,#4,Q3-#)3#2,*,(Q34Q1?,(03#

23#%&$':# /,*-40)23#2)#-(1A3#2)*# 0,+(34351)*#&$'#,#%&7#VW&# 8?)1*# ,*.,+1J1+)?,(0,:# 3#

$VW&9#8FCLMFNO:#!>>!9E#

X-/5123#,?#T""Y:#3#%&$'#-0141S)#3#J3/?)03#+41,(0,Z*,/Q123/#8[15-/)#\ET9#,#.,/?10,#3#)+,**3:#

)0/)Q=*#2,#+3(,GB,*#,#*,/Q1@3*:#0)(03#2,#-?#*,/Q123/#.3/#Q]/13*#+41,(0,*:#;-)(03#2,#-?#+41,(0,#

.3/#Q]/13*#*,/Q123/,*E#&3?3#(3#VW&:#=#0/)(*.)/,(0,#)3*#+41,(0,*#)#43+)412)2,#2,#,G,+-@A3#23#

+3?.3(,(0,#23#;-)4#*,#-0141S)?#3*#*,/Q1@3*#8'F&V$X$[N:#T""Y9E#

#

#



• Classes, Métodos e Interfaces. Com a IDL (Interface Definition Language) todas as classes (objetos

DCOM), métodos e interfaces são descritos e convertidos em bibliotecas C, que por sua vez são compiladas

e associadas a uma DLL do sistema Windows;

• Proxy/Stub. É a DLL resultante da compilação, responsável pela serialização e desserialização, utilizada

pelos clientes e servidores DCOM em tempo de execução;

• Identificadores. Também chamados de GUIDs (Globally Unique Identifiers), são valores de 128 bits

que identificam unicamente as partes de um sistema baseado no DCOM. Podem aparecer na forma de: CLSID

(Class Identifier), para identificar unicamente uma classe ou objeto DCOM; IID (Interface Identifier), para

identificar unicamente uma interface; ou CATID (Category Identifier), para identificar categorias específicas de

um mesmo componente. Todos estes identificadores são cadastrados no registro (registry) do sistema

operacional.

Através da IDL e do GUID, as interfaces são protegidas contra modificação e identificadas

unicamente, garantindo a compatibilidade dos objetos (mesmo no caso de modificações de versão),

independente do ambiente em que foram criados.

18.2.2. O OPC

Herdando todas as características das tecnologias descritas anteriormente, o OPC utiliza um modelo

cliente-servidor, onde o servidor oferece interfaces para os objetos OPC e os gerencia. Dessa forma, existem

interfaces, métodos e classes especialmente voltadas para as necessidades de controle de processos,

reunidas na forma de especificações, cada uma delas implementando um conjunto específico de

funcionalidades. Conforme estas necessidades evoluem, as especificações também o fazem, sendo este um

dos principais motivos da constante atualização de versões das especificações.

18 .2 .2 .1 . Arqu i te tura Bás ica

O OPC é uma especificação para dois conjuntos de interfaces: as interfaces OPC Custom e OPC

Automation. Apenas a OPC Custom deve ser implementada obrigatoriamente em todos servidores, sendo a

OPC Automation um conjunto de interfaces de implementação opcional.



As interfaces OPC Custom são projetadas para serem utilizadas com linguagens de programação

que empregam ponteiros, como C/C++, enquanto que, para linguagens mais simples, como Visual Basic,

Delphi e VBA, devem ser utilizadas as interfaces OPC Automation. Nestas últimas existe um componente a

mais no servidor OPC, chamado Automation Wrapper, que encapsula e gerencia as chamadas entre as

linguagens sem ponteiros e a interface OPC Custom, conforme apresentado na Figura a seguir.

F igura 236: Arqu i te tura Bás ica do OPC

Também é esperado que o servidor consolide e otimize as requisições de acesso a dados de vários

clientes, promovendo comunicações eficientes com os dispositivos de campo. Para leitura, os dados

retornados pelos dispositivos são armazenados em um buffer para distribuição assíncrona ou coleta

síncrona por vários clientes OPC. Para escritas, o servidor OPC atualiza os dados nos dispositivos físicos,

independente dos clientes OPC.

Entre a memória cache do servidor OPC e o dispositivo de campo pode existir qualquer meio físico

e/ou protocolo de comunicação, e a comunicação é feita por protocolos que podem ser proprietários ou não.

Desta forma, é transparente ao cliente OPC qual protocolo está sendo utilizado num nível mais baixo, já que

o mesmo só se comunica através do servidor, o que padroniza a comunicação no nível superior.

18 .2 .2 .2 . Pr inc ipa is Espec i f i cações

A seguir estão listadas as especificações atualmente disponíveis:

• OPC Common Definitions and Interfaces. Fornece e descreve definições, interfaces e serviços comuns

!"#

$# %&'()'# *+,(&# ,+-./0# ,./# *+,1')(&,# &,# %')21)%&),# +,%+1)3)1&-4+,# */# 567# 2&,# ,8&,# 9+',4+,#

9):+2(+,# &(8&;<+2(+# =>+?+<@'/# ABBCD0# 1/<# /# /@E+()9/# *+# 382*&<+2(&'# &# &2F;),+# *+#

&%;)1&@);)*&*+#3+)(&#<&),#&*)&2(+G##

!"#"$! %&'()*+*(&,-./0)1,--

5#567#H#8<&#+,%+1)3)1&-./#%&'&#*/),#1/2E82(/,#*+# )2(+'3&1+,I#&,# )2(+'3&1+,#!"#-#$%&'(#+#

!"#)*$&'(+&,'-G#$%+2&,#&#!"#$#%&'()#*+9+#,+'#)<%;+<+2(&*&#/@'):&(/')&<+2(+#+<#(/*/,#

,+'9)*/'+,0#,+2*/#&#!"#$*%'()+',(-#8<#1/2E82(/#*+#)2(+'3&1+,#*+#)<%;+<+2(&-./#/%1)/2&;G##

$,# )2(+'3&1+,# !"#$ #%&'()# ,./# %'/E+(&*&,# %&'&# ,+'+<# 8();)?&*&,# 1/<# ;)2:8&:+2,# *+#

%'/:'&<&-./# J8+# +<%'+:&<# %/2(+)'/,0# 1/</# 7K7LL0# +2J8&2(/# J8+0# %&'&# ;)2:8&:+2,# <&),#

,)<%;+,0# 1/</# M),8&;# N&,)10# >+;%O)# +# MN$0# *+9+<# ,+'# 8();)?&*&,# &,# )2(+'3&1+,# !"#$

*%'()+',(-G# P+,(&,# Q;()<&,# +R),(+# 8<# 1/<%/2+2(+# &# <&),# 2/# ,+'9)*/'# 5670# 1O&<&*/#

*$&'(+&,'-) ./+001/2# J8+# +21&%,8;&# +# :+'+21)&# &,# 1O&<&*&,# +2('+# &,# ;)2:8&:+2,# ,+<#

%/2(+)'/,# +# &# )2(+'3&1+# !"#$ #%&'()0# 1/23/'<+# &%'+,+2(&*/# 2&# S):8'&# !GA=567#

S5TP>$UV5P0#ABB!&DG#

#

#

2)3(&,-!"#-%&'()*+*(&,-./0)1,-45-678-9678-26:;<%=>6;?-#@@!,A-

U&<@H<#H#+,%+'&*/#J8+#/#,+'9)*/'#1/2,/;)*+#+#/()<)?+#&,#'+J8),)-4+,#*+#&1+,,/#&#*&*/,#*+#

9F')/,# 1;)+2(+,0# %'/</9+2*/# 1/<82)1&-4+,# +3)1)+2(+,# 1/<# /,# *),%/,)()9/,# *+# 1&<%/G# 6&'&#

;+)(8'&0# /,# *&*/,# '+(/'2&*/,# %+;/,# *),%/,)()9/,# ,./# &'<&?+2&*/,# +<# 8<# .%//01# %&'&#



a todas especificações;

• OPC Data Access (DA). Principal especificação do OPC, fornece a funcionalidade de transferência de

dados de tempo real e contínua de CLPs, SDCDs e outros, para IHMs, sistemas supervisórios e similares;

• OPC Alarms & Events (AE). Fornece notificações de alarmes e eventos sob demanda, como alarmes

de processo, ações do operador, auditagem etc;

• OPC Historical Data Access (HDA). Fornece mecanismos consistentes e uniformes de acesso a dados

de histórico já armazenados;

• OPC Batch. Traz a filosofia do OPC às aplicações de processamento em batelada processamento em

batelada (batch processing), permitindo mecanismos de troca de informações e condições operacionais

atuais em equipamentos que implementam este tipo de controle. É uma extensão da OPC-DA;

• OPC Data exchange (DX). É uma extensão do OPC-DA, e fornece mecanismos para troca de dados

entre diferentes servidores OPC-DA através de redes de campo heterogêneas, incluindo serviços de

configuração, diagnóstico, monitoração e gerenciamento remotos;

• OPC Security. Fornece mecanismos de controle de acesso a informações de processo e proteção

contra modificações não autorizadas de parâmetros do mesmo;

• OPC XML-DA (XMLDA). Extensão da OPC-DA, fornece mecanismos consistentes e flexíveis para

apresentação dos dados de chão de fábrica usando a linguagem XML, permitindo sua apresentação em

navegadores Web via Internet/Intranet;

• OPC Complex Data: Outra extensão da OPC-DA, permite aos servidores a descrição e representação

de formatos de dados mais complexos, tais como estruturas binárias, arrays e outros. Vem sempre

associada à DA ou à XMLDA.

Vale ressaltar que estão atualmente em desenvolvimento novas especificações que permitem

incorporar novas funcionalidades, motivadas por tendências de mercado e necessidades de muitos usuários

do padrão OPC. Das especificações, merece destaque especial um novo conjunto, nomeado de OPC Unified



Architecture (UA). Este conjunto visa, entre outros objetivos, tornar todas as especificações atuais melhor

adaptadas aos serviços Web, além de tornar o OPC independente do DCOM e, portanto, suportado em

outras plataformas não- Windows, como GNU/Linux, Unix e outros.

Com todas estas funcionalidades disponíveis no padrão OPC, os fornecedores de diversos produtos

hoje disponíveis no mercado introduzem as seguintes vantagens:

• Padronização das interfaces de comunicação entre os servidores e clientes de dados de tempo real,

facilitando a integração e manutenção dos sistemas;

• Eliminação da necessidade de drivers de comunicação específicos (proprietários);

• Melhoria do desempenho e otimização da comunicação entre dispositivos de automação;

• Interoperabilidade entre sistemas de gestão empresarial (Enterprise Resource Planning - ERP), de

execução de manufatura (Manufacturing Execution System - MES) e aplicações Windows (Excel, etc.);

• Redução dos custos e tempo para desenvolvimento de interfaces e drivers de comunicação, com

conseqüente redução do custo de integração de sistemas;

• Facilidade de desenvolvimento e manutenção de sistemas e produtos para comunicação em tempo real;

• Facilidade de treinamento.

Nas próximas seções é realizada uma descrição mais detalhada das especificações mais utilizadas

na prática (OPC-DA, OPC-AE e a OPC-HDA) e da nova especificação (OPC-UA). As demais são agrupadas em

só uma seção e descritas de forma sucinta. São abordadas somente as interfaces do tipo Custom, já que as

do tipo Automation são baseadas nelas.

18.2.2.2.1. OPC Data Access Specification (DA)

Conceitos, Modelos e Objetos



Atualmente na versão 3.0, a OPC Data Access Specification, ou OPC-DA, foi a primeira das

especificações a ser lançada, em 1996. Naquela época, em sua versão 1.0, era chamada simplesmente de

OPC Specification. Pelo novo conceito de extensões adotado, foi renomeada em 1997 para OPC Data Access

Specification e a versão atualizada para 1.0A.

Basicamente, a OPC-DA fornece interfaces, objetos e métodos que permitem o acesso a dados de

chão de fábrica em tempo real. É a principal e mais básica entre as especificações. Qualquer sistema que

necessite monitorar dados de campo em tempo real deve, no mínimo, dispor de um servidor e um cliente

que implemente a OPC-DA. Nela existe uma hierarquia com três objetos principais no servidor:

• OPCServer. Realiza todo o gerenciamento de conexão com o cliente e retorno dos dados, fornece

navegação pelos objetos disponíveis no servidor, métodos para gerenciamento (ex: criação/destruição), pelo

cliente, de objetos OPCGroup, entre outros;

• OPCGroup. Realiza o agrupamento lógico e gerenciamento de objetos OPCItem, gerenciamento de

estado dos grupos (groups), disponibiliza métodos de escrita/leitura nos itens, etc;

• OPCItem. Representa o dado de campo propriamente dito, também chamado de item, e é totalmente

gerenciado pelo objeto OPCGroup.

O objeto OPCItem não é um objeto “real”, pois não possui métodos e interfaces próprias para seu

gerenciamento. Isto ocorre porque, na prática, existem muitos itens a serem lidos/escritos ao mesmo tempo

e o gerenciamento feito através dos grupos é mais eficiente, pois permite que a operação seja feita em

apenas uma chamada.

A hierarquia de objetos mostrada permite flexibilidade aos clientes, pois cada um deles pode criar seu

conjunto de itens e grupos, definindo sua própria visão do processo.

Outro conceito utilizado pelos servidores OPC-DA é o de espaço de nomes (namespace), que nada

mais é do que outra hierarquia criada e configurada no servidor para representar a topologia de todos os

dispositivos monitorados pelo servidor. Ela é composta por itens com identificadores chamados ItemIDs, que

identificam unicamente um dispositivo de campo.



Diferentemente da hierarquia de objetos, o namespace é único para cada servidor, e pode se

associar com várias hierarquias de objeto ao mesmo tempo. A Figura 3.3 mostra um exemplo desta

associação: à esquerda está o namespace e à direita os objetos do servidor. Nota-se que dois objetos

OPCItem podem estar associados a um mesmo item do namespace, através de seu ItemID, ilustrando a

flexibilidade da hierarquia de objetos, já comentada.

Para finalizar, vê-se também, no namespace, duas informações associadas ao item

Raiz.Andar_2.Temp. Estas são chamadas de propriedades e representam informações relativamente

estáticas relacionadas ao item do namespace, que também podem ser cadastradas no mesmo, durante a

configuração do servidor.

F igura 237: Namespace e H ierarqu ia de Ob je tos

Principais Funcionalidades:

• Escrita/Leitura Síncrona e Assíncrona: Na escrita/leitura síncrona, o cliente requisita os dados e os

recursos de sistema só são liberados quando os valores são retornados pelo servidor. É mais simples de

implementar, mas pouco eficiente, ocupando muitos recursos de rede quando existem muitos dados a

trafegar. No modo assíncrono, o cliente se “cadastra” (subscribe) no servidor para receber determinada

quantidade de dados e libera os recursos logo após a chamada. Após esta etapa, os dados solicitados são

enviados ao cliente à medida que o servidor os tiver disponíveis. É mais eficiente para grandes quantidades

de dados. Adicionalmente, a leitura/escrita pode ser feita tanto através da memória cache do servidor,

quanto diretamente no dispositivo. Alguns exemplos de interface são: OPCGroup::IOPCSyncIO,

OPCGroup::IOPCAsyncIO entre outras (OPC FOUNDATION, 2003a);

!"#

#

!"#$%&'()('*&+,-.&/,','0",%&%1$"&'2,'345,67-'89:;*9<=>'?@@?A#

B%"C/".&"-'!$C/"7C&D"2&2,-'83BE'!3F*G;<93*'>'?@@(&A'

!! H-/%"6&IJ,"6$%&' KLC/%7C&' ,' ;--LC/%7C&M' $%# &'()*+%,-&*+.)%# '/0()10%2# 1# (-*&0+&#

)&3.*'*+%# 1'# 4%41'# &# 1'# )&(.)'1'# 4&# '*'+&5%# '6# '71# -*8&)%41'# 3.%041# 1'# 9%-1)&'# '71#

)&+1)0%41'# :&-1# '&)9*41);# <# 5%*'# '*5:-&'# 4&# *5:-&5&0+%)2# 5%'# :1.(1# &=*(*&0+&2#

1(.:%041#5.*+1'#)&(.)'1'#4&#)&4&#3.%041#&>*'+&5#5.*+1'#4%41'#%#+)%=&?%);#$1#5141#

%''/0()1012#1# (-*&0+&# '&# @(%4%'+)%A# B!"#!$%&#'C# 01# '&)9*41)#:%)%# )&(&8&)# 4&+&)5*0%4%#

3.%0+*4%4&# 4&# 4%41'# &# -*8&)%# 1'# )&(.)'1'# -1?1# %:6'# %# (D%5%4%;#E:6'# &'+%# &+%:%2# 1'#

4%41'#'1-*(*+%41'#'71#&09*%41'#%1#(-*&0+&#F#5&4*4%#3.&#1#'&)9*41)#1'#+*9&)#4*':10/9&*';#

<#5%*'#&=*(*&0+&#:%)%#?)%04&'#3.%0+*4%4&'#4&#4%41';#E4*(*10%-5&0+&2#%#-&*+.)%,&'()*+%#

:14&# '&)# =&*+%# +%0+1# %+)%9G'# 4%# 5&56)*%# $($)'* 41* '&)9*41)2# 3.%0+1# 4*)&+%5&0+&# 01#

4*':1'*+*91;# E-?.0'# &>&5:-1'# 4&# *0+&)=%(&# '71H# # +,-.%/"0112+,-345$2+6*

+,-.%/"0112+,-7!45$2+*&0+)&#1.+)%'*BIJK#LIM$NEOPI$2#QRR!%CS#

!! N&C2&'O7%6&M'J1)#8%04%#51)+%#B8'(8#(58C2#&0+&04&T'&#.5%#=%*>%#4&#9%-1)&'#B)&-%+*9%#

%1#%(59'#4&#-&*+.)%C#0%#3.%-#9%)*%UV&'#071#(%.'%5#&09*1#4&#4%41'#:%)%#1#'&)9*41);#P'+1#

:&)5*+&#&(1015*%#4&#)&(.)'1'#4&#)&4&2#WX#3.&#1#'&)9*41)#071#:)&(*'%#&09*%)#1'#9%-1)&'#

%# (%4%# 5.4%0U%2# '15&0+&# 3.%041# 9*1-%)&5# %# 8%04%# 51)+%;# E# (10=*?.)%U71# 4&'+&#

:%)Y5&+)1# +1)0%# :1''/9&-# 1# &09*1# :1)# &>(&U71# 4&# 9%-1)&'# %0%-6?*(1';# E# *0+&)=%(&#

4*':10/9&-# 0%# IJKTNE# :%)%# ?&)&0(*%5&0+1# 4%# 8%04%# 51)+%# G#

+,-.%/"0112+,-:'(8;(58<9=>*

!! !7%+&67'2,'G&27-M#$%#IJKTNE2#(%4%#*+&5#4&#4%41#+&5#+)Z'#(15:10&0+&'#8X'*(1'H#1#

P&D7%#:)1:)*%5&0+&#4*+12#41#+*:1#[E\PE$O#B(15#'.8+*:1'#L-1%+2#P0+&?&)#&+(CS#%#%Q6$D7'

2,' 6,+.7# B=&?'!=(?0C# 01# =1)5%+1# MOK# B@5&A'%!(B* C&?'* -/8'C2# 3.&# )&:)&'&0+%# %#

*0=1)5%U71#41#+&5:1#B(15#)&'1-.U71#4&#]RR0'C#&5#3.&#1#'&)9*41)#)&(&8&.#1#4%41#4&#



• Banda Morta: Por banda morta (deadband), entende-se uma faixa de valores (relativa ao range de

leitura) na qual variações não causam envio de dados para o servidor. Isto permite economia de recursos de

rede, já que o servidor não precisa enviar os valores a cada mudança, somente quando violarem a banda

morta. A configuração deste parâmetro torna possível o envio por exceção de valores analógicos. A interface

disponível na OPC-DA para gerenciamento da banda morta é OPCGroup::IOPCDeadBandMgt;

• Formato de Dados: Na OPC-DA, cada item de dado tem três componentes básicos: o valor

propriamente dito, do tipo VARIANT (com subtipos Float, Integer etc); a rótulo de tempo (timestamp) no

formato UTC (Universal Time Code), que representa a informação do tempo (com resolução de 100ns) em

que o servidor recebeu o dado de um dispositivo; e dois bytes que representam a qualidade associada ao

dado (ex: “Bom”,”Ruim” e “Indefinido”);

• Envio por Exceção: Permite o envio de dados ao cliente assim que há mudança de valores (acima da

banda morta configurada) ou qualidade dos mesmos. Implementado pelo método (do cliente)

IOPCDataCallback::OnDataChange;

• Ativação/Desativação de Itens e Grupos: Permite ativar/desativar a monitoração dos grupos e itens,

para realizar a manutenção em algum dispositivo, por exemplo. Implementado por métodos como:

IOPCGroupStateMgt::SetState e IOPCItemMgt:: SetActiveState.

18.2.2.2.2. OPC Alarms and Events Specification (AE)


A Alarms and Events Specification, ou OPC-AE, descreve objetos e interfaces que são implementadas

por servidores OPC-AE que fornecem mecanismos para os clientes OPC serem notificados de condições de

alarme e eventos específicos, além de serviços que permitem ao cliente saber os tipos de eventos e

condições suportadas pelo servidor, bem como seus estados atuais. Para serem notificados, os clientes se

“cadastram” (subscribe) no servidor para receber os eventos que atendam a um determinado critério.

Existem dois conceitos importantes: o de condição e o de subcondição. Uma condição basicamente

reflete um estado do servidor OPC-AE, ou dos objetos que o compõem, que é de interesse de um

determinado cliente. Por exemplo, um alarme de nível associado a um determinado equipamento de campo é



uma condição. A subcondição representa um detalhe maior da condição. No nosso exemplo, o estado “Nível

Alto” representaria uma subcondição da condição “Alarme de nível”. Assim, uma condição pode ter várias

subcondições associadas, como “Baixo”, “Alto”, “Muito Baixo”, “Muito Alto”. A cada condição e subcondição

estão associados atributos que fornecem um detalhamento maior do estado atual e outras informações.

Para manter uma padronização mínima, existem atributos que são obrigatórios e definidos na especificação.

Os demais são chamados de “específicos de fabricante”.

Nesse contexto, a especificação define um alarme como um caso especial de uma condição, ou seja,

uma condição anormal, enquanto que um evento é definido como uma ocorrência detectável que seja

significativa para o servidor, o dispositivo que o representa, e os clientes associados. Não necessariamente

todos os eventos estão associados a condições: ações do operador, mudanças de configuração, entre

outros.

A especificação prevê três tipos de eventos:

• Eventos Simples: São eventos mais básicos, que não exigem ações de reconhecimento pelo operador

(ex: “bomba ligada”);

• Eventos Relacionados a Rastreamento (auditoria): Possuem os mesmos atributos dos eventos

simples, com um atributo adicional, chamado ActorId, para permitir rastreabilidade dos dados (ex:

identificação de que operador realizou uma ação);

• Eventos Relacionados à Condição: São os eventos mais complexos, que estão associados com condições e

subcondições da planta, têm mais atributos, e exigem uma ação de reconhecimento, pelo operador, da

ativação de uma subcondição (alarme).

A Figura 238 ilustra os três tipos de evento com alguns dos atributos mais comuns. Vale ressaltar o

atributo Severity, representado por um número de 1 a 1000, que indica o nível de severidade (urgência) de

uma subcondição. Conforme a especificação, cada fabricante de servidor é responsável por mapear os

valores de severidade (caso existam) específicos dos seus protocolos proprietários naquela faixa de valores.

Como na OPC-DA, os servidores da OPC-AE também implementam uma hierarquia para representar

como estão dispostos os eventos no campo ou chão de fábrica. Esta hierarquia é chamada de área de



eventos ou EventArea. Nela existem as fontes de evento, associadas geralmente aos dispositivos de campo

que os geram, agrupadas em áreas, que representam as áreas físicas reais da planta. Como vemos adiante,

o servidor OPC-AE implementa interfaces e métodos específicos para navegação na área de eventos.

F igura 238: A t r ibutos de Eventos

Um último conceito na OPC-AE é o de filtragem, que permite que os clientes se cadastrem no servidor

para receber os eventos atendendo a determinados critérios de interesse, como por exemplo, eventos com

uma severidade específica, de uma área específica. Também são vistas adiante algumas interfaces que o

servidor fornece para possibilitar a filtragem.

Os objetos que compõem um servidor OPC-AE são três:

• OPCEventServer. Gerencia as conexões com clientes, cria e gerencia os objetos OPCEventSubscription,

ativa/desativa determinadas condições/subcondições, fornecem os mecanismos para filtragem e filtros

disponíveis no servidor entre outros;

• OPCEventSubscription. Representa o cadastramento (subscription) dos clientes para receber os

eventos e fornece os métodos para realizar a filtragem dos mesmos. Cada objeto deste tipo está associado

!"#

#

!"#$%&'()*'+,%"-$,./'01'2314,./'567+869:;'<==<>'

$%#&'()%*#+*,+-)(*#,.#/01234#5#*#6-#?"@,%&#1A7#89-#:-;%)(-#89-#*<#+')-,(-<#<-#+.6.<(;-%#

,*#<-;=)6*;#:.;.#;-+->-;#*<#-=-,(*<#.(-,6-,6*#.#6-(-;%),.6*<#+;)(5;)*<#6-#),(-;-<<-7#+*%*#:*;#

-?-%:'*7#-=-,(*<#+*%#9%.#<-=-;)6.6-#-<:-+@A)+.7#6-#9%.#B;-.#-<:-+@A)+.C#D.%>5%#<E*#=)<(.<#

.6).,(-#.'F9%.<#),(-;A.+-<#89-#*#<-;=)6*;#A*;,-+-#:.;.#:*<<)>)')(.;#.#A)'(;.F-%C#

/<#*>G-(*<#89-#+*%:H-%#9%#<-;=)6*;#/01234#<E*#(;I<J#

!! !"#$%&'()&*%&*+, K-;-,+).# .<# +*,-?H-<# +*%# +')-,(-<7# +;).# -# F-;-,+).# *<# *>G-(*<#

!"#$%&'()*+,-./0(/1'23 .()=.L6-<.()=.# 6-(-;%),.6.<# +*,6)MH-<L<9>+*,6)MH-<7#

A*;,-+-%#*<#%-+.,)<%*<#:.;.#A)'(;.F-%#-#A)'(;*<#6)<:*,@=-)<#,*#<-;=)6*;#-,(;-#*9(;*<N#

!! !"#$%&'()-./0*12(13'43O-:;-<-,(.#*#+.6.<(;.%-,(*#P,*+,-./0(/1'Q#6*<#+')-,(-<##:.;.#

;-+->-;#*<#-=-,(*<#-#A*;,-+-#*<#%5(*6*<#:.;.#;-.')R.;#.#A)'(;.F-%#6*<#%-<%*<C#1.6.#

*>G-(*#6-<(-#():*#-<(B#.<<*+).6*#<*%-,(-#.#9%#A)'(;*N#

!! !"#$%&'(4*&56*37/&*4# S*;,-+-#%-+.,)<%*<# :.;.# ,.=-F.ME*# 6*# +')-,(-# ,.# B;-.# 6-#

-=-,(*<7#:*<<)>)')(.,6*#89-#-'-#+*,T-M.#89.)<#-=-,(*<#-<(E*#6)<:*,@=-)<#,*#<-;=)6*;C#



somente a um filtro;

• OPCEventAreaBrowser. Fornece mecanismos para navegação do cliente na área de eventos,

possibilitando que ele conheça quais eventos estão disponíveis no servidor.

A Figura 239 mostra o exemplo de um servidor com seus objetos associados a uma área de

eventos.

F igura 239: Serv idor OPC AE e área de Eventos

Principais Funcionalidades

• Envio através de cadastramento (subscription) e notificações: Conforme já mencionado, esta

funcionalidade permite que os clientes se cadastrem no servidor para o recebimento de notificações de

todos os tipos de evento. Exemplos de interfaces e métodos são: IOPCEventServer::CreateEventSubscription

!"#

$#%&'()*#+,-#./01)*#/#232.45/#62#(.#02)7&6/)#8/.#02(0#/9:21/0#*00/8&*6/0#*#(.*#;)2*#62#

272<1/0,##

#

!"#$%&'()*'+,%-"./%'012345','6%,&'.,'5-,78/9':;<4=;>?@'ABBAC'

1%"7D"E&"9'!$7D"/7&F".&.,9':012'!0G=H4>;0=@'ABBAC'

!! 57-"/' &8%&-I9' .,' D&.&98%&J,78/' :!"#!$%&'(&)*+, ,' 7/8"K"D&LM,9N# =/<>/).2# :;#

.2<8&/<*6/?#201*#>(<8&/<*5&6*62#42).&12#@(2#/0#85&2<120#02#8*6*01)2.#</#02)7&6/)#4*)*#

/# )2829&.2<1/#62#</1&>&8*AB20#62# 1/6/0#/0# 1&4/0#62#272<1/,#C32.45/0#62#&<12)>*820#2#

.D1/6/0# 0E/F# !"#$%&'()*'+&'+,,$+'-)'%&'()*./01+23)24(5 4*)*# )2*5&G*)# /#

8*6*01)*.2<1/# </# 02)7&6/)# 2# !"#$%&'()*2(6,,"(%&'()5 H.D1/6/# 6/# 85&2<12I# 4*)*#

42).&1&)#/#)2829&.2<1/#62#</1&>&8*AB20#425/#85&2<12J#

!! O,D/7P,D"J,78/'.,'&F&%J,9N#K2).&12#@(2#/#85&2<12#)28/<L2A*#*0#8/<6&AB20#*</).*&0#

85*00&>&8*6*0# 8/./# *5*).2# 6()*<12# *# 8/<>&'()*AE/# 6/# 02)7&6/),# M#.D1/6/# 4*)*# 201*#

>(<8&/<*5&6*62#D#/#!"#$%&'()*'+&'+,,716$4(82)24(95

!! 4$."8/%"&N# %/)<282# /# )*01)2*.2<1/# <28200;)&/# 4*)*# 6212).&<*6/0# 272<1/0?#

*).*G2<*<6/#/#&62<1&>&8*6/)#6/#85&2<12#MK=N$C#@(2#&<&8&/(#(.#272<1/#)25*8&/<*6/#*#

)*01)2*.2<1/,# O.452.2<1*6*# 425/# *1)&9(1/# 71)4+!85 6/0# 272<1/0# )25*8&/<*6/0# *#

)*01)2*.2<1/J#



para realizar o cadastramento no servidor e IOPCEventSink::OnEvent (método do cliente) para permitir o

recebimento de notificações pelo cliente;

• Reconhecimento de alarmes: Permite que o cliente reconheça as condições anormais classificadas

como alarme durante a configuração do servidor. O método para esta funcionalidade é o

IOPCEventServer::AckCondition;

• Auditoria: Fornece o rastreamento necessário para determinados eventos, armazenando o identificador

do cliente OPC-AE que iniciou um evento relacionado a rastreamento. Implementada pelo atributo ActorId

dos eventos relacionados a rastreamento;

• Pesquisa através de filtros: Permite que o cliente pesquise os atributos de evento e restrinja o

recebimento de notificações para um subconjunto que atenda a determinados critérios desejados.

Exemplos de métodos:

IOPCEventServer::QueryAvailableFilters

IOPCEventSubscriptionMgt::SetFilter/Get Filter;

• Ligação de eventos com itens da OPC-DA: Os servidores OPC-AE podem existir isolados ou em

conjunto com servidores OPC-DA. Neste último caso, pode ser desejável para a aplicação-cliente saber, além

do estado de alarme de uma condição, o valor de tempo real associado à mesma, que pode estar disponível

em um servidor OPC-DA. Para isso, existe no servidor OPC-AE o método IOPCEventServer ::

TranslateToItemIDs;

• Ativação/Desativação de Eventos e/ou Áreas: Pode ser desejável a ativação/desativação das notificações

de um ou mais eventos, para fins de manutenção. Para este caso, existem, por exemplo, os seguintes

métodos: IOPCEventServer::Enable/DisableConditionByArea e IOPCEventServer::Enable/

DisableConditionBySource.

18.2.2.2.3. OPC Historical Data Access (HDA)




A Historical Data Access Specification, ou OPC-HDA, descreve objetos e interfaces necessários ao

acesso (escrita e leitura) a bases de dados históricas. Ao implementar estas interfaces, os fabricantes de

servidores OPC-HDA tornam este acesso transparente aos clientes, permitindo a integração deste tipo de

dados em todos os níveis de uma empresa, independente do mecanismo (engine) de armazenamento que

se utilize em níveis mais baixos de camada de software.

As bases de dados históricas são ferramentas poderosas utilizadas por especialistas ou até

gerentes para análise dos dados de uma planta, auxiliando nas decisões. Nelas, cada variável fica

armazenada como uma série de valores (também chamada de vetor, array ou dado de tendência), sendo

registrada sua variação numa determinada faixa de tempo, e permitindo seu acesso posterior pelos

usuários.

Os principais tipos de servidores suportados por esta especificação são:

• Servidores simples de tendência. Armazenam os dados de forma bruta (raw data), na forma de uma

tupla, cada um com informações de tempo, valor e qualidade (similar ao formato utilizado na OPC-DA);

• Servidores complexos de compressão e análise de dados. Fornecem compressão de dados, bem

como armazenamento bruto. Os mesmos são capazes de fornecer dados sumarizados (também chamados

de agregados ou funções de análise dos dados) como médias, mínimos ou máximos etc.

Além disso, podem suportar atualização dos dados (e o histórico destas atualizações) e anotações

do usuário.

Vale ressaltar que algumas das funcionalidades desses servidores são implementadas através de

interfaces opcionais (apesar de previstas na especificação), ou seja, os fabricantes de servidores podem não

implementá-las por conveniência. Isso exige do usuário uma observação mais atenta na hora da aquisição

de um servidor histórico que satisfaça as suas necessidades.

Alguns termos e conceitos utilizados freqüentemente na especificação são:

• Atributos. Qualificadores adicionais que um item em particular tem associado com ele. Ex: o tipo de



dados, flags para identificar se o mesmo suporta interpolação ou se o dado está sendo gravado, etc;

• Agregados (Aggregates). Métodos que sumarizam os dados, como médias, mínimos e máximos

(todos sobre intervalos de tempo). Estes métodos são executados sempre durante a recuperação dos

dados;

• Anotações. Comentários inseridos por um operador ou usuário em relação ao um determinado item,

geralmente em uma determinada instância de tempo;

• Valores de limite (Bounding Values). São os valores requeridos pelo cliente para determinar os

pontos inicial e final de um determinado período de tempo. Se um valor de dado existe em um destes

pontos, o mesmo é considerado o valor de limite. Se o valor não existe, o próximo valor fora da faixa de

tempo especificada é considerado o limite;

• Dados Interpolados. Dado derivado dos dados arquivados, para o qual não há valor armazenado.

Geralmente, é derivado linearmente de dois pontos adjacentes ao rótulo de tempo solicitado, que não está

armazenado. Também, pode ser derivado da extrapolação dos dados arquivados, por um método mais

complexo;

• ItemID. Uma string que referencia unicamente o item de dados no endereçamento do servidor. É

similar ao ItemID da OPC-DA;

• Valor Modificado. Valor que foi alterado após o seu armazenamento no servidor;

• Dados brutos (Raw Data). Dados efetivamente armazenados no servidor. Podem ser comprimidos ou

não, dependendo das regras de armazenamento definidas durante a gravação;

• Domínio de tempo. Intervalo de tempo definido pelos tempos inicial e final. Os dados dentro deste

domínio podem estar na ordem direta ou inversa, dependendo se o tempo inicial é menor ou maior do que o

final, respectivamente.

Vale ressaltar que, em relação aos agregados, a especificação define requisitos comuns e específicos

de cada tipo de agregado, de forma a uniformizar a recuperação deste tipo de dados no caso de utilização



de servidores de diferentes fabricantes.

A seguir estão listados os dois objetos de um servidor OPC-HDA:

• OPCHDA_Server. Fornece as interfaces de gerenciamento da conexão com os clientes, escrita, leitura e

atualização dos dados históricos, anotações e playback;

• OPCHDA_Browser. Fornece a interface para navegação (pelo cliente) no espaço de endereços do

servidor (address space). Este espaço é semelhante ao namespace descrito na OPC-DA. A diferença é que,

na OPC-HDA, a interface para navegação é obrigatória.


• Leitura (Read) e atualização (Insert. Delete, Replace) Síncrona e Assíncrona: Existem interfaces para

leitura e atualização (inserção, exclusão e reescrita) síncrona e assíncrona dos dados históricos. Todas as

interfaces assíncronas e a interface de atualização síncrona são opcionais. Exemplos de interface:

IOPCHDA_SyncRead, IOPCHDA_SyncUpdate, IOPCHDA_AsyncRead, IOPCHDA_AsyncUpdate;

• Anotações: As interfaces, a seguir, fornecem mecanismos para criação e gerenciamento de anotações

no servidor. Vale ressaltar que esta funcionalidade é opcional. IOPCHDA_SyncAnnotations,

IOPCHDA_AsyncAnnotations;

• Playback: O mecanismo de playback permite que se retorne um conjunto inicial de dados e,

posteriormente, este conjunto seja atualizado continuamente. IOPCHDA_Playback (opcional);

• Agregados: O método IOPCHDA_Server::GetAggregates permite ao cliente saber quais agregados

são suportados pelo servidor.

18.2.2.2.4. OPC Unified Architecture (OPC-UA)




Atualmente em draft, a OPC Unified Architecture Specification, ou simplesmente OPC-UA, é uma

implementação multi-plataforma, onde vários tipos de sistemas e dispositivos podem se comunicar através

de mensagens entre clientes e servidores em vários tipos de redes, suportando uma comunicação robusta e

segura que garante a identidade dos clientes e dos servidores.

O modelo de arquitetura dos sistemas OPC-UA trata os clientes e servidores OPC-UA como parceiros

que interagem de diversas formas, cada sistema pode conter diversos clientes e servidores. Cada cliente

OPC-UA pode interagir com um ou mais servidores OPC-UA e cada servidor OPC-UA pode interagir com um

ou mais clientes OPC-UA. Uma aplicação possível consiste em combinar componentes de servidor e de

cliente para permitir interação entre servidores.

A aplicação cliente é um código que implementa a função de cliente , utilizando o OPC-UA Client API

para enviar e receber solicitações do OPC-UA Service ao OPC-UA Server como mostra a Figura 240.

F igura 240: C l iente OPC-UA

O OPC-UA Client API é uma interface interna que isola o código da aplicação cliente da pilha de

comunicação – OPC-UA Communication Stack. As requisições da aplicação cliente são feitas ao OPC-UA Client

API, sendo que a OPC- Communication Stack converte estas chamadas em mensagens que são enviadas ao

servidor OPC-UA via rede de comunicação. Da mesma forma ocorre, no sentido inverso, o recebimento das

mensagens originadas no servidor OPC-UA, é realizado pela OPC-UA Communication Stack e enviadas via

OPC-UA Client API para a aplicação cliente.

!"#

$#%&'()&#'(#*+,-./(/-+*#'&0#0.0/(%*0#$12345#/+*/*#&0#6).(7/(0#(#0(+8.'&+(0#$12345#6&%&#

9*+6(.+&0# ,-(# .7/(+*:(%# '(# '.8(+0*0# ;&+%*0<# 6*'*# 0.0/(%*# 9&'(# 6&7/(+# '.8(+0&0# 6).(7/(0# (#

0(+8.'&+(0=#2*'*#6).(7/(#$12345#9&'(#.7/(+*:.+#6&%#-%#&-#%*.0#0(+8.'&+(0#$12345#(#6*'*#

0(+8.'&+#$12345#9&'(#.7/(+*:.+#6&%#-%#&-#%*.0#6).(7/(0#$12345=#4%*#*9).6*>?&#9&00@8()#

6&70.0/(# (%# 6&%A.7*+# 6&%9&7(7/(0# '(# 0(+8.'&+# (# '(# 6).(7/(# 9*+*# 9(+%./.+# .7/(+*>?&# (7/+(#

0(+8.'&+(0#9&+#(B(%9)&#C$12#D$4EF5GH$E<#IJJKAL=#

5#*9).6*>?&#6).(7/(#M#-%#6N'.:&#,-(#.%9)(%(7/*#*#;-7>?&#'(#6).(7/(#<#-/.).O*7'&#&#!"#$%&'

#()*+,'&"-'9*+*#(78.*+#(#+(6(A(+#0&).6./*>P(0#'&#!"#$%&'.*/0)1*#*&#!"#$%&'.*/0*/#6&%&#

%&0/+*#*#D.:-+*#Q=K=##

#

!"#$%&'()*'+,"-./-'01+234'501+'!036748906:';<<*=>'

$#!"#$%&'#()*+,'&"-#M#-%*#.7/(+;*6(#.7/(+7*#,-(#.0&)*#&#6N'.:&#'*#*9).6*>?&#6).(7/(#'*#9.)R*#

'(#6&%-7.6*>?&#S#!"#$%&'#2334+)15,)2+'.,516=#50#+(,-.0.>P(0#'*#*9).6*>?&#6).(7/(#0?&#

;(./*0# *&# !"#$%&' #()*+,' &"-<# 0(7'&# ,-(# *# !"#$' #.//0+)12,).+' 3,214# 6&78(+/(# (0/*0#

6R*%*'*0#(%#%(70*:(70#,-(#0?&#(78.*'*0#*&#0(+8.'&+#$12345#8.*#+('(#'(#6&%-7.6*>?&=#F*#

%(0%*#;&+%*#&6&++(<#7&#0(7/.'&#.78(+0&<#&#+(6(A.%(7/&#'*0#%(70*:(70#&+.:.7*'*0#7&#0(+8.'&+#

$12345<# M# +(*).O*'&# 9()*# $12345##.//0+)12,).+' 3,214# (# (78.*'*0# 8.*#!"#$%&'#()*+,'

&"-#9*+*#*#*9).6*>?&#6).(7/(#C$12#D$4EF5GH$E<#IJJKAL=#

5#*+,-./(/-+*#'&#0(+8.'&+#$12345#%&'()*#*0#;+&7/(.+*0#'*#*9).6*>?&#0(+8.'&+#(#*0#.7/(+*>P(0#

0(+8.'&+T6).(7/(=#5#D.:-+*#Q=U#.)-0/+*#*#*9).6*>?&#0(+8.'&+#$12345=#

$0#7*5('!89*1,:#0?&#&AV(/&0<#;@0.6&0#&-#'(#0&;/W*+(<#,-(#0?&#*6(00@8(.0#'*#*9).6*>?&#0(+8.'&+#

&-#%*7/.'*0#.7/(+7*%(7/(<#-%#'.09&0./.8&#;@0.6&#&-#6&7/*'&+(0#'(#'.*:7N0/.6&<#9&+#(B(%9)&=#



A arquitetura do servidor OPC-UA modela as fronteiras da aplicação servidor e as interações

servidor/cliente. A Figura 241 ilustra a aplicação servidor OPC-UA.

Os Real Objects são objetos, físicos ou de software, que são acessíveis da aplicação servidor ou

mantidas internamente, um dispositivo físico ou contadores de diagnóstico, por exemplo.

O OPC-UA Server Application é o código que executa a função de servidor, utiliza o OPC- UA Server

API para enviar e receber mensagens, OPC-UA Messages, para o cliente OPC-UA.

F igura 241: Serv idor OPC-UA

O OPC-UA Server API é uma interface que isola o código da aplicação servidor da pilha de

comunicação – OPC-UA Communication Stack, esta pode ser uma implementação padrão fornecida pela OPC

Foundation ou uma implementação específica de um fornecedor.

!"#

$#!"#$%&'()*+)*'&,,-./01.23#%#&#'()*+&#,-.#./.'-01#1#2-345&#).#6.78*)&79#-0*:*;1#&#!"#$

%&'()*+)*'&"4#<171#.38*17#.#7.'.=.7#>.361+.369#!"#$%&'5)6607)69#<171#&#':*.30.#$?@ABC#

D$?@#E$BFGCHI$F9#JKK"=LM#

#

#

!"#$%&'()*'+,%-"./%'012345'6012'!047859:07;'<==>?@'

$#!"#$%&'()*+)*'&",#%#->1#*30.721'.#,-.#*6&:1#&#'()*+&#)1#1<:*'145&#6.78*)&7#)1#<*:N1#).#

'&>-3*'145&# O#!"#$%&' #-../012341-0' (43259# .601# <&).# 6.7# ->1# *><:.>.30145&# <1)75&#

2&73.'*)1#<.:1#$?@#E&-3)10*&3#&-#->1#*><:.>.30145&#.6<.'P2*'1#).#->#2&73.'.)&7M#

$# .6<14&# ).# .3).7.4&# O#!"#$%&'&8*)66(,0/)9# &-# 6*><:.6>.30.#&6*)77(832)9# %# ).2*3*)&#

'&>&# -># '&3Q-30&# ).# 3(6# D928)6L# 1'.66P8.*6# <.:&# ':*.30.# -613)&# &# !"#$%&' ()*+12)7#

D*30.721'.6#.#>%0&)&6LM#$6#3(6#3&#&6*)77(832)#65&#-61)&6#<171#7.<7.6.3017#&=Q.0&6#7.1*69#6-16#

).2*3*4R.6#.#6-16#7.2.7S3'*16#.307.#6*M#

1%"AB"C&"D'!$AB"/A&E".&.,D'6012'!047859:07;'<==>?@'

!! FA-"/' .,' 7/G"H"B&IJ,DT# U601# 2-3'*&31:*)1).9# 6&:*'*01)1# 8*1# !"#$%&' ()*+./)'

431)*:0/)9#'&36*60.#3&#.38*&#).#3&0*2*'14R.6#<.7*()*'16#1&6#':*.30.69#*3':-*3)&#.8.30&69#

1:17>.6#.#07&'1#).#)1)&6V#



O espaço de endereço – OPC-UA AdressSpace, ou simplesmente AdressSpace, é definido como um

conjunto de nós (Nodes) acessíveis pelo cliente usando o OPC-UA Services (interfaces e métodos). Os nós

no AdressSpace são usados para representar objetos reais, suas definições e suas referências entre si.


• Envio de Notificações: Esta funcionalidade, solicitada via OPC-UA Service Interface, consiste no envio de

notificações periódicas aos clientes, incluindo eventos, alarmes e troca de dados;

• Interações Servidor-Servidor: Interações entre servidores na qual um servidor comporta-se como um

cliente de outro servidor. Estas interações entre servidores permitem a implementação de servidores que

trocam informações com outros servidores (Figura 242), incluindo redundância ou servidores remotos e

envio de dados de chão de fábrica para aplicações no nível de planta (Figura 243);

F igura 242: In tervenção entre Serv idores OPC-UA

!"#

!! !"#$%&'($)* +$%,-./%0+$%,-./%$# %&'()*+,(-# (&')(# -()./01)(-# &*# 23*4# 35# -()./01)#

61571)'*8-(# 6151# 35# 64/(&'(# 0(# 13')1# -()./01)9# :-'*-# /&'()*+,(-# (&')(# -()./01)(-#

7()5/'(5# *# /574(5(&'*+;1# 0(# -()./01)(-# 23(# ')16*5# /&<1)5*+,(-# 615# 13')1-#

-()./01)(-#=>/?3)*#@9ABC#/&643/&01#)(03&0D&6/*#13#-()./01)(-#)(51'1-#(#(&./1#0(#0*01-#

0(#6E;1#0(#<FG)/6*#7*)*#*74/6*+,(-#&1#&H.(4#0(#74*&'*#=>/?3)*#@9IBJ#

#

1-23%&*456*!"#$%&'7/*$"#%$*+$%,-./%$)*89:0;<*=89:*18;>?<@!8>A*BCCDEF*

#

1-23%&*45G*+$%,-./%$)*89:0;<*$"#%$*>H,$-)*I-$%J%K3-L/)*=89:*18;>?<@!8>A*BCCDEF*

!! ?-)M/"-E-N-.&.$* ./)* .&./)* $O* ,J%-/)* P/%O&#/)Q# K-# 0*01-# 710(5# -()#

0/-71&/G/4/L*01-# (5# 0/.()-1-# <1)5*'1-C# /&643/&01# (-')3'3)*-# G/&F)/*-# (# 01635(&'1-#

MNO9# P15# 1#!""#$%%&'()$C# 1# 64/(&'(# 710(# )(23/-/'*)# *1# -()./01)# 1#!"#$%$#$# 23(#

0(-6)(.(#1# <1)5*'1#01-#0*01-9#:5#53/'1-#6*-1-C#1-#64/(&'(-#5(-51#-(5#61&E(6()#1#

<1)5*'1# 01-# 0*01-C# 710(5# 0('()5/&*)# 1# <1)5*'1# (# 3'/4/L*)# 61))('*5(&'(# 1-# 0*01-#

0/-71&H.(/-# &1# -()./01)9# %-'1# 7()5/'(# *# 3'/4/L*+;1# 01# KQP8RS# '*&'1# (5# *5G/(&'(-#

T(G# =510(41#MNOB#23*&'1# (5# )(0(-# /&03-')/*/-# 416*/-# =510(41# G/&F)/1BC# (5#23(# 1#

)(23/-/'1#0(#'(571#0(#)(-71-'*#U#5*/-#(V/?(&'(J#



F igura 243: Serv idores OPC-UA entre N íve is H ierárqu icos

• Disponibilidade dos dados em vários formatos: Os dados podem ser disponibilizados em diversos

formatos, incluindo estruturas binárias e documentos XML. Com o AddressSpace, o cliente pode requisitar ao

servidor o Metadata que descreve o formato dos dados. Em muitos casos, os clientes mesmo sem conhecer

o formato dos dados, podem determinar o formato e utilizar corretamente os dados disponíveis no servidor.

Isto permite a utilização do OPC-UA tanto em ambientes Web (modelo XML) quanto em redes industriais

locais (modelo binário), em que o requisito de tempo de resposta é mais exigente;

• Modelo de segurança personalizado: Os procedimentos de segurança podem ser selecionadas e

configuradas para cada aplicação, incluindo mecanismos e parâmetros de segurança padronizados, é

definido um número mínimo de perfis de segurança que todos servidor OPC-UA deve implementar. Quando

uma seção é estabelecida, as aplicações do cliente e do servidor negociam um canal de comunicação seguro

!"#

!! !"#$%&'($)* +$%,-./%0+$%,-./%$# %&'()*+,(-# (&')(# -()./01)(-# &*# 23*4# 35# -()./01)#

61571)'*8-(# 6151# 35# 64/(&'(# 0(# 13')1# -()./01)9# :-'*-# /&'()*+,(-# (&')(# -()./01)(-#

7()5/'(5# *# /574(5(&'*+;1# 0(# -()./01)(-# 23(# ')16*5# /&<1)5*+,(-# 615# 13')1-#

-()./01)(-#=>/?3)*#@9ABC#/&643/&01#)(03&0D&6/*#13#-()./01)(-#)(51'1-#(#(&./1#0(#0*01-#

0(#6E;1#0(#<FG)/6*#7*)*#*74/6*+,(-#&1#&H.(4#0(#74*&'*#=>/?3)*#@9IBJ#

#

1-23%&*456*!"#$%&'7/*$"#%$*+$%,-./%$)*89:0;<*=89:*18;>?<@!8>A*BCCDEF*

#

1-23%&*45G*+$%,-./%$)*89:0;<*$"#%$*>H,$-)*I-$%J%K3-L/)*=89:*18;>?<@!8>A*BCCDEF*

!! ?-)M/"-E-N-.&.$* ./)* .&./)* $O* ,J%-/)* P/%O&#/)Q# K-# 0*01-# 710(5# -()#

0/-71&/G/4/L*01-# (5# 0/.()-1-# <1)5*'1-C# /&643/&01# (-')3'3)*-# G/&F)/*-# (# 01635(&'1-#

MNO9# P15# 1#!""#$%%&'()$C# 1# 64/(&'(# 710(# )(23/-/'*)# *1# -()./01)# 1#!"#$%$#$# 23(#

0(-6)(.(#1# <1)5*'1#01-#0*01-9#:5#53/'1-#6*-1-C#1-#64/(&'(-#5(-51#-(5#61&E(6()#1#

<1)5*'1# 01-# 0*01-C# 710(5# 0('()5/&*)# 1# <1)5*'1# (# 3'/4/L*)# 61))('*5(&'(# 1-# 0*01-#

0/-71&H.(/-# &1# -()./01)9# %-'1# 7()5/'(# *# 3'/4/L*+;1# 01# KQP8RS# '*&'1# (5# *5G/(&'(-#

T(G# =510(41#MNOB#23*&'1# (5# )(0(-# /&03-')/*/-# 416*/-# =510(41# G/&F)/1BC# (5#23(# 1#

)(23/-/'1#0(#'(571#0(#)(-71-'*#U#5*/-#(V/?(&'(J#



e seus softwares de certificação – Software Certificates – identificam o cliente e o servidor em questão, bem

como sua capacidade disponível, utilizando este canal de comunicação seguro, os usuários precisam ser

autenticados uma única vez, quando a aplicação é estabelecida;

• Unificação de modelos: Cada uma das especificações anteriores do OPC (DA, HDA e AE) definiu seu

próprio modelo de espaço de endereço e seu próprio conjunto de serviços. A OPC-UA unifica todos os

modelos em um único espaço de endereço com um único conjunto de serviços. Com a compatibilidade entre

servidores OPC-UA e servidores OPC que utilizam tecnologia Microsoft (COM/DCOM), os dados existentes em

servidores OPC (DA, HDA e AE) podem ser facilmente utilizados por servidores OPC-UA. Assim os

fornecedores podem escolher migrar seus produtos nativos para o OPC-UA ou usar encapsuladores externos

para converter o OPC DCOM para a OPC- UA e vice-versa;

• Soluções para redundância: Esta especificação permite que os fornecedores desenvolvam clientes e

servidores redundantes de forma consistente, esta redundância pode ser utilizada para obter: alta

disponibilidade, tolerância falhas e distribuição de processamento.

18 .2 .2 .3 . Outras Espec i f i cações

18.2.2.3.1. OPC XML-DA

A XML-DA oferece métodos e interfaces para mapeamento dos serviços disponíveis na OPC- DA

através do protocolo SOAP (Service Oriented Access Protocol), tornando as interfaces e métodos de acesso

a dados do OPC disponíveis em ambiente Web. Segundo o (W3C, 2003), o SOAP é um protocolo destinado à

troca de informações estruturadas em um ambiente distribuído e descentralizado. Ele utiliza a tecnologia

XML para definir uma estrutura de troca de mensagens, e as conexões HTTP para tornar as informações

disponíveis na Internet, independente de protocolos de nível mais baixo. O SOAP é um protocolo aberto,

gerenciado pelo W3C (World Wide Web Consortium). Assim, a adoção do SOAP como tecnologia de base para

a XML-DA, mantém a filosofia de abertura adotada pela OPC Foundation.

A linguagem XML (abreviatura de Extensible Markup Language) utiliza uma estrutura de tags parecida

com a HTML para definir estruturas hierárquicas de dados, objetos e atributos. Diferentemente da HTML, na

XML, as tags podem ser livremente criadas pelo usuário, o que torna esta linguagem ideal para descrever

estruturas de dados, num formato simples e de fácil entendimento.



As conexões HTTP são um padrão utilizado já há bastante tempo na World Wide Web e permitem que

sejam utilizados os serviços da XML-DA por qualquer computador que tenha acesso à Internet, inclusive

através de firewalls. Com isso, a OPC-DA vem atender uma necessidade já pleiteada há algum tempo por

muitos usuários, permitindo a monitoração de dados de uma planta externamente à empresa e até num

contexto mundial. Outra vantagem é que este padrão de conexão, por ser praticamente universal, permite a

utilização de clientes rodando em outros sistemas operacionais.

Como a XML-DA está associada aos serviços da OPC-DA, é natural concluir que ela também é utilizada

para acesso a dados em tempo real. Alguns exemplos de métodos (serviços) implementados pela XML-DA

são descritos a seguir:

• GetStatus: para verificar a disponibilidade e estado do serviço;

• Browse: para navegar no namespace do servidor;

• Read/Write: Escrita/Leitura;

• Subscribe: definir inscrição para recepção de dados do servidor;

• SubscriptionPolledRefresh: polling iniciado pelo cliente para os dados já inscritos.

18.2.2.3.2. OPC Compliance Test

As especificações OPC são regras eficazes que garantem a interoperabilidade. Para assegurar que

estas regras sejam seguidas, a OPC Foundation fornece ferramentas próprias de certificação e workshops de

interoperabilidade. Estas ferramentas de certificação incluem um processo, completo e específico, para teste

de conformidade com o padrão.

A OPC Foundation também realiza workshops, onde os fornecedores podem verificar, por longos

períodos, a interoperabilidade entre seus produtos e entre produtos de outros fornecedores. Este método

disponibiliza um sólido processo para assegurar que as especificações OPC sejam soluções para

interoperabilidade.



O ponto essencial para interoperabilidade é a conformidade com as interfaces dos servidores. As

aplicações clientes só podem verdadeiramente confiar na interoperabilidade entre fornecedores distintos se

estes servidores implementam interfaces e métodos conforme as especificações.

Este processo de verificação de compatibilidade pode ser realizado de várias formas. Porém,

necessitam de extensiva intervenção humana. A OPC Foundation produz ferramentas para simplificar esta

tarefa. Estas ferramentas de conformidade, as chamadas Compliance Test Tools, são um conjunto de testes

definidos e reproduzíveis executado para assegurar a correta implementação das interfaces e métodos.

Os membros da OPC Foundation utilizam as Compliance Test Tools para testar, depurar e certificar

seus servidores. Estes testes são realizados, por duas vezes, em diversas condições e caso todos sejam

aprovados, as informações são armazenados em uma base de dados criptografada. São gerados relatórios

automaticamente, em seguida são enviados para a OPC Foundation para publicação, em seu site, na lista de

todos os servidores certificados – Compliant Server.

18.2.2.3.3. OPC Complex Data

A especificação OPC Complex Data, disponibilizada em dezembro de 2003, descreve uma nova

forma de transmitir dados de um servidor OPC-DA para outro, tornando fácil para fornecedores,

desenvolvedores, fabricantes de equipamentos e usuários finais conectarem dispositivos novos e

inteligentes.

A especificação atual do OPC-DA requer dados simples ou matrizes de dados simples. Assim, os

servidores OPC-DA representam os dados como uma seqüência de bytes, atualmente não há como

descrever a estrutura destes bytes. Os clientes não são capazes de interpretar os dados estruturados

recebidos sem que o servidor forneça os itens de dados ou matrizes de dados simples.

Complex Data são itens de dados de um servidor OPC-DA que têm uma estrutura definida. Esta

especificação define uma forma para descrever estruturas de dados complexas contidas dentro do

NameSpace de um servidor OPC-DA, fornecendo um mecanismo para representar estruturas complexas

como itens simples de servidores OPC-DA.



Os itens Complex Data podem incluir, por exemplo, itens estruturados e não estruturados,

elementos e itens abstratos, strings, inteiros, seqüências dos bytes (BLOB’s) e dados XML. Cada item de

dados é acompanhado de uma descrição do tipo de dado, que define a estrutura deste item, e um dicionário

contendo todas as informações que o cliente OPC-DA necessita para entender o Complex Data recebido.

18.2.2.3.4. OPC Data Exchange (DX)

A OPC Data Exchange (OPC-DX) permite troca horizontal de dados entre servidores, sem a

necessidade de clientes no meio do caminho. Como uma extensão da OPC-DA, a OPC-DX utiliza e

implementa:

• O conceito de conexão DX (DX Connection), para permitir a conexão e troca de dados entre os

servidores;

• O conceito de item de origem/destino (Source/Target Item), que consistem nos fontes/destino de

dados de uma conexão;

• O conceito de configuração DX (DX Configuration), que representa o conjunto de conexões disponíveis

em um servidor;

• Um cliente para permitir a definição, configuração, visualização e monitoração das conexões entre os

servidores;

• Funcionalidades de cliente e servidor OPC-DA, para permitir a visualização dos dados em tempo real

entre os vários servidores (DA ou DX);

• Um Namespace similar ao da OPC-DA, acrescido de nós para representar as conexões, com atributos

de configuração, status e itens de fonte/destino de dados.

No que se refere à transferência de dados, a mesma pode ser feita de duas formas:

• Utilizando a OPC-DA, ou seja, pelo mecanismo tradicional do DCOM, de criação de objetos e itens em

um servidor OPC-DA, e comunicação por conexões de callback para resposta;



• Utilizando a XML-DA, através dos mecanismos de comunicação definidos nesta última especificação

(SOAP).

18.2.2.3.5. OPC Common Definitions and Interfaces

Esta especificação compila definições, indicações e interfaces comuns a todas as outras

especificações, de forma a criar um padrão mínimo para o desenvolvimento das mesmas, incluindo:

• A interface IOPCCommon, que gerencia a utilização de diferentes idiomas nas mensagens e

mensagens de erro;

• A interface IOPCShutDown (no lado do cliente), que possibilita a notificação (aos clientes) e o

gerenciamento de shutdown do servidor;

• Definições de instalação dos servidores e componentes, e descrição de seus identificadores (CLSID,

CATIDs etc) e configurações no registro do sistema operacional (registry);

• O OPCServerBrowser, que fornece uma interface para informar aos clientes OPC a existência de

servidores OPC em computadores remotos. Esta interface deve ser obrigatoriamente disponibilizada pelo

servidor OPC;

• Os arquivos proxy/stub, para serialização/desserialização;

• O Automation Wrapper;

• A definição de interfaces obrigatórias e opcionais.

18.2.2.3.6. OPC Security

Esta especificação está focada na identificação do cliente, que troca credenciais confiáveis, sendo

utilizadas pelo servidor OPC para autorização de acesso. Entender esta especificação é útil para analisar,



inicialmente, o modelo de referência da segurança.

A Especificação OPC Security diz respeito ao método de implementação de recursos de segurança.

Sua principal desvantagem é uma possível ocorrência de problemas de interoperabilidade caso utilize-se

uma forma não especificada.

Compatível com o modelo de segurança do Windows NT, o OPC Security permite vários níveis de

segurança para manter compatibilidade com o conjunto de aplicações OPC e disponibilizar capacidade de segurança

maximizada.

Um servidor OPC pode implementar um dos seguintes níveis de segurança:

• Disable Security: Nenhum item de segurança é reforçado, todos os servidores OPC possuem

permissões de acesso, todos os clientes possuem as mesmas permissões acesso. O servidor OPC não

controla o acesso de objetos de segurança individualmente para cada desenvolvedor;

• DCOM Security: Somente a segurança do NT DCOM é reforçada, permissões de início e acesso são

limitados a clientes selecionados, assim como as permissões de acesso para ligações do cliente. Entretanto,

o servidor OPC não controla o acesso de qualquer objeto de segurança de fornecedores específicos. Este é

o nível padrão de segurança do DCOM;

• OPC Security: O Servidor OPC serve como um monitor de referência para o controle de acesso para

objetos de segurança de fornecedores específicos que são disponibilizados pelo servidor OPC. Um servidor

OPC pode implementar o OPC Security de forma complementar ao DCOM Security ou implementá-lo sozinho.

Os Servidores OPC que disponibilizam o OPC Security devem implementar ao menos uma das

interfaces IOPCSecurityNT e IOPCSecurityPrivate. Estas interfaces permitem aos clientes OPC determinarem

se o OPC Security está implementado no servidor OPC em questão e quais tipos de certificados de acesso

são suportados com segurança.

18.2.2.3.7. OPC Batch

A especificação OPC-Batch é uma extensão do modelo da OPC-DA para o caso de processamento em



batelada (batch processing). Uma batelada (ou batch) consiste em diferentes procedimentos que descrevem

a manufatura de um determinado produto. Na execução de uma batelada, uma troca de dados é realizada

com os dispositivos envolvidos no processo. Os dados dos procedimentos são enviados e dados de relatório

são recebidos em resposta. Todos os mecanismos do processamento em batelada são padronizados pela

norma IEC 61512, e os produtos de mercado que fornecem esta solução seguem a mesma. Desta forma, a

OPC-Batch não descreve a solução para os problemas de controle da batelada, mas a possibilidade de

operar simultaneamente as soluções dos diferentes fabricantes, trazendo a interoperabilidade para este

meio.

Para possibilitar o atendimento à norma IEC 61512, a OPC-Batch utiliza as interfaces obrigatórias

definidas na OPC-DA (incluindo a interface de navegação), acrescidas basicamente de:

• Suporte a interfaces OPC adicionais (IOPCBatchServer), para implementar algumas funcionalidades

necessárias;

• Um namespace bem definido, seguindo a hierarquia e conceitos previstos na norma IEC 61512. Vale

ressaltar que este namespace pode ser bastante grande, dada a natureza das informações criadas e

trocadas no processamento em batelada.

A norma IEC 61512 define quatro tipos de informação de batelada: características de equipamento

(que descrevem os dispositivos que executam a batelada), condições de operação atuais, conteúdo histórico

e conteúdo dos procedimentos.

No caso da OPC-Batch, estão definidos objetos e interfaces para permitir a troca de informações dos

dois primeiros tipos de informação de batelada citados anteriormente. Para descrever o primeiro, utiliza-se o

modelo físico (physical model) definido na norma, e, para o segundo tipo, são utilizados a lista de batelada

(batch list) e o modelo de batelada (batch model), também definidos na norma IEC 61512.

O modelo físico representa a subdivisão de uma determinada planta em diferentes níveis, incluindo

áreas, células, unidades, módulos de dispositivo e módulos de controle procedural (procedural control

modules). Este último descreve o módulo que realiza um determinado procedimento automatizado,

incluindo: informações de procedimento, procedimento da unidade, operação e fase.



O modelo de batelada segue uma hierarquia similar aos módulos de controle procedural, e descreve

as informações das ações que compõem a batelada, incluindo: unidade, procedimentos, operações e fases.

As listas de batelada (batch lists) permitem saber informações sobre quais processos estão sendo

executados, quais estão em espera e quais estão terminados.

Todos estes modelos são mapeados no namespace do servidor OPC-Batch, através dos nós, ramos

e suas propriedades.

18.3. APLICAÇÕES E CARACTERÍSTICAS DO OPC

Grande parte da literatura sobre OPC trata-o como uma solução para se obter dados de redes

heterogêneas de modo uniforme, ou seja, como um protocolo desenvolvido num contexto onde os processos

são controlados individualmente por sistemas especializados e baseados em comunicação digital. No

entanto, sua aplicação tem se mostrado mais ampla, como demonstram os estudos de casos apresentados

neste capítulo.

A concentração de dados de um sistema no seu nível de controle mais elevado tem sido bastante

desejada. A forma mais simples de se obter tal concentração é alocar em uma mesma sala de controle as

estações de trabalho relativas aos subsistemas, permitindo aos operadores uma visão geral do processo.

Quando tal solução não é viável, sistemas auxiliares de comunicação (telefones, rádio, intranet ou internet)

são usados.

O OPC tem se mostrado desde o início uma solução para esse problema, disponibilizando dados para

camadas mais elevadas de aplicação de forma integrada, permitindo assim um maior aproveitamento das

informações na forma de relatórios de produção, estatísticas de falhas etc.

Apesar de se desviarem do seu objetivo primário, diversas funções um pouco mais elaboradas

surgiram para o OPC. O protocolo poderia ser usado como elo entre equipamentos de fabricantes distintos

em malhas de controle, como meio de comunicação para sistemas de controle avançado ou mesmo como

camada base para sistemas de supervisão mais amigáveis. É nesse contexto que se inicia a discussão sobre

os requisitos necessários ao correto funcionamento do protocolo em comparação às redes industriais

típicas.



Este capítulo trata de alguns casos de aplicação, de testes de fabricantes e também de trabalhos

teóricos, sob o ponto de vista dos requisitos tratados no Capítulo anterior.

18.3.1. Principais Conceitos

18 .3 .1 .1 . Ap l i cações em Tempo Rea l e Carac ter ís t i cas de Desempenho

Como citado no Capítulo anterior, o bom desempenho da rede é essencial. Requisitos básicos de uma

rede industrial de controle são boa velocidade e bom fluxo de dados. No entanto, o que define se um

sistema de comunicação é veloz o suficiente é sua aplicação.

Para um sistema de controle industrial, uma rede veloz é aquela na qual o tempo gasto para as

informações transitarem entre suas diversas partes é suficientemente menor que as constantes de tempo

envolvidas no processo. Em sistemas de controle em tempo real, a presença de um atraso significativo entre

quaisquer dos elementos de uma malha pode inviabilizar sua sintonia. Nesses casos o desempenho da

comunicação em termos de tempo de atraso é um item fundamental a ser avaliado. Além disso, a rede

também deve ser capaz de suportar todo o fluxo de dados sem que nenhum dos seus elementos seja

sobrecarregado, impedindo a comunicação efetiva.

A principal desvantagem do OPC em termos de desempenho está na criação de outra camada de

comunicação no sistema, utilizando um modelo cliente-servidor. Outro ponto relevante é a utilização de

redes estatísticas (ethernet) como meio de comunicação, o que pode gerar alguns inconvenientes:

• Atrasos de comunicação devido ao processamento das mensagens pelo servidor;

• Tempos de comunicação variáveis devido à utilização do sistema operacional Windows, que não foi

desenvolvido para aplicações true real-time;

• Diminuição da robustez pela centralização do tráfego de informações em servidores;

• Tempos variáveis pela característica estatística das redes ethernet.



Os exemplos mostram argumentos qualitativos e quantitativos sobre o desempenho e aplicabilidade

do OPC em casos específicos. Nos estudos, são focadas duas características principais:

• Latência ou tempo de atraso – tempo que uma informação solicitada ou enviada por um dispositivo

leva para ficar completamente disponível para uso;

• Fluxo de dados – quantidade de dados que pode ser transmitida por segundo entre os servidores e

clientes. A unidade utilizada é itens/s por representar melhor os diversos tipos de dados geralmente

disponíveis nos sistemas.

18 .3 .1 .2 . O t im ização , Contro le Avançado e In teroperab i l idade de Redes Heterogêneas

Interconectar malhas de controle de diferentes fabricantes muitas vezes é indispensável para otimizar

uma planta e torná-la lucrativa. No entanto, essa integração pode tornar-se uma tarefa árdua e custosa.

Utilizar o OPC como ferramenta de integração pode viabilizar a interoperabilidade de modo simples e sem

prejuízo significativo de desempenho.

A utilização do OPC para esse propósito parece ser extremamente viável. Seu propósito é permitir

que, através de um sistema cliente-servidor, todos os equipamentos distintos possam se comunicar

utilizando uma mesma interface. É como se o OPC criasse uma linguagem universal, permitindo que os

equipamentos troquem informações de maneira simples, barata e eficiente.

18 .3 .1 .3 . Con f iab i l idade e D ispon ib i l idade no OPC

A confiabilidade e disponibilidade das redes de comunicação industrial são itens muito importantes.

Na maioria dos casos os sistemas de controle industrial tratam de equipamentos e processos com grande

acúmulo de energia, que em caso de falha podem causar grandes perdas materiais e humanas. Apesar do

protocolo ter sido desenvolvido para controle industrial, as primeiras especificações do OPC não discutem

esses itens.

Um ponto fraco apontado no OPC é a sua dependência do Windows e do DCOM. Nas suas primeiras

versões, o protocolo está intimamente associado ao sistema operacional da Microsoft, sistema que

historicamente tem características de confiabilidade e disponibilidade discutíveis.



Nos casos estudados adiante são apresentadas soluções que contornam algumas dessas limitações, como a

redundância de servidores e o emprego de programas para monitoramento da qualidade da comunicação.



ANOTAÇÕES



19. WIRELESS

19.1. INTRODUÇÃO

A rede wireless (wire = fio, less = sem) é um sistema de transmissão de dados flexível que pode ser

utilizado como alternativa para as redes cabeadas. É uma tecnologia que permite a conexão entre

equipamentos sem uma conexão física. As redes locais sem fio são baseadas no padrão 802.11,

especificado pelo Institute of Eletrical and Eletronics Engineers (IEEE), e compostas de um conjunto de

estações que trocam informações, utilizando a propagação das ondas eletromagnéticas. Entretanto,

equipamentos de comunicação de dados wireless podem utilizar-se também de luz infravermelha ou laser,

apesar das ondas de rádio (eletromagnéticas) ser o meio mais difundido.

19.2. PRINCÍPIO DE FUNCIONAMENTO

Toda a comunicação sem fio é baseada no seguinte princípio: quando os elétrons se movem, criam

ondas eletromagnéticas que podem se propagar através do espaço livre. O número de oscilações por

segundo de uma onda eletromagnética é chamado de frequência que é medida em Hz. Quando se instala

uma antena com o tamanho apropriado, as ondas eletromagnéticas podem ser transmitidas e recebidas com

eficiência por receptores localizados a uma distância que depende de vários fatores, como por exemplo:

frequência, potência do transmissor, etc.

19.3. PADRÕES

O primeiro padrão, chamado de IEEE 802.11 foi publicado em 1997. Este apenas serviu de base

para padrões posteriores, sendo que atualmente nem se fabricam mais produtos compatíveis com tal

tecnologia.

Dois anos mais tarde, em 1999, a IEEE efetuou algumas mudanças na camada física e lançou a

especificação 802.11b, concebida com o objetivo de atender a necessidade de maior velocidade de

transmissão imposta pelo mercado.

No mesmo ano surgiu a especificação 802.11a, a qual teve como principal característica o aumento

da velocidade para um máximo de 54 Mbps, além da alteração da freqüência para a faixa de 5 GHz, menos



suscetível a interferências.

Embora o padrão 802.11a seja semelhante ao 802.11b, não é compatível com este, uma vez que

utiliza uma banda diferente no espectro de freqüências.

Entretanto, a idéia de conseguir taxas próximas a 54 Mbps animava a utilização do padrão

802.11a. Com esse intuito foi aprovado, em 2003, o padrão 802.11g, o qual mantinha total compatibilidade

com o padrão 802.11b por operar na mesma faixa de frequência (2.4 GHz) e ainda transmitia a taxa máxima

de 54 Mbps, idêntico ao padrão 802.11a.

19.4. CARACTERÍSTICAS DOS PADRÕES

A tabela a seguir aponta as principais características e diferenças entre os padrões wireless.

Tabe la 26: Caracter ís t icas dos Padrões

Embora diversos barramentos de dados estejam presentes em um ambiente industrial, as conexões

wireless são uma opção bastante interessante. Mesmo sem a necessidade de obras de infra-estrutura, a

facilidade de alteração de layout sem preocupação com cabeamento e a alta taxa de transferência de dados

possibilitada pela tecnologia wireless são fatores que devem ser considerados .

59

A tabela 3.7 aponta as principais características e diferenças entre os padrões wireless.

Tabela 3.7 Características dos padrões (Adaptado de ENGST, FLEISHMAN, 2005).

Padrão Freqüência Velocidade Máxima Tendência de adoção

802.11b 2,4 GHz 11 Mbps

Diminuindo em computadores, avançando

na eletrônica mais barata.

802.11a 5GHz 54Mbps Empresas adotando lentamente, sem

consumidores.

802.11g 2,4 GHz 54 Mbps Avançando em todos os segmentos.

Embora diversos barramentos de dados estejam presentes em um ambiente industrial, as

conexões wireless são uma opção bastante interessante. Mesmo sem a necessidade de obras

de infra-estrutura, a facilidade de alteração de layout sem preocupação com cabeamento e a

alta taxa de transferência de dados possibilitada pela tecnologia wireless são fatores que

devem ser considerados (CUNHA, 2006/2007).

O uso de comunicação sem fio já é utilizada em aplicações industriais em função das

seguintes vantagens sobre os sistemas convencionais:

�! Mobilidade e liberdade de movimento;

�! Sem desgaste mecânico do meio de transmissão;

�! Instalação e colocação em funcionamento rápida e fácil;

�! Alta flexibilidade com poucas alterações na instalação;

�! Integração simples de dispositivos na rede;

�! Ultrapassar “territórios problemáticos”.

Ou seja, ela pode e deve ser usada todas as vezes em que o custo de passagem de cabos e dos

sistemas associados ao mesmo sejam mais altos que os custos do sistema wireless

correspondente.

As diferenças relevantes na forma de utilização da tecnologia wireless em ambiente industrial

estão associadas a:

�! Distância a ser coberta pelo sistema;

�! Quantidade de dados trafegando por unidade de tempo (largura de banda);



19.5. O USO DA WIRELESS

O uso de comunicação sem fio já é utilizada em aplicações industriais em função das seguintes

vantagens sobre os sistemas convencionais:

• Mobilidade e liberdade de movimento;

• Sem desgaste mecânico do meio de transmissão;

• Instalação e colocação em funcionamento rápida e fácil;

• Alta flexibilidade com poucas alterações na instalação;

• Integração simples de dispositivos na rede;

• Ultrapassar “territórios problemáticos”.

Ou seja, ela pode e deve ser usada todas as vezes em que o custo de passagem de cabos e dos

sistemas associados ao mesmo sejam mais altos que os custos do sistema wireless correspondente. As

diferenças relevantes na forma de utilização da tecnologia wireless em ambiente industrial estão associadas

a:

• Distância a ser coberta pelo sistema;

• Quantidade de dados trafegando por unidade de tempo (largura de banda);

• Taxa de atualização de informação requerida pelo processo (tempo de ciclo);

• Atraso máximo aceito do momento em que uma informação está disponível em um ponto do sistema

até que ela esteja presente no seu destino (tempo de latência).



19.6. TECNOLOGIAS WIRELESS

Existem algumas tecnologias que se encaixam no perfil, e entre elas as mais interessantes são:

Wireless Ethernet, Zigbee, Bluetooth e HART Wireless.

19.6.1. IEEE 802.11b Wi-Fi

Atualmente, este é o padrão para as redes locais sem fio (Wireless LAN). Use a faixa de 2,4 GHz e

pode transmitir Ethernet em taxas relativamente altas (> 10 Mbps). Esse padrão foi desenvolvido para as

redes comerciais, domésticas e corporativas. Sendo assim, Wi-Fi não é adequado para os ambientes

industriais pela sua susceptibilidade às interferências eletromagnéticas e pela distância limitada (< 50 m).

Com o uso de antenas apropriadas é possível chegar a mais de 100 m, mas a cobertura não é unidirecional.

19.6.2. IEEE 802.15.1 Bluetooth

Esse padrão foi desenvolvido especificamente para conectar computadores pessoais, telefones

celulares e outros periféricos tais como câmeras e fones de ouvido. Bluetooth também usa a faixa de 2,4

GHz mas com velocidades inferiores ao Wi-Fi, sendo dessa forma menos vulnerável às interferências.

Novamente, a distância alcançada compromete algumas das aplicações industriais (< 30 m para classe 2 e

< 100 m para classe 1).

19.6.3. IEEE 802.15.4 ZigBee

Desenvolvido originalmente para aplicações em aquecimento, ventilação e condicionadores de ar

(HVAC) como uma alternativa ao uso do Bluetooth. Esse padrão preza pelo baixo consumo, o que confere

maior autonomia para equipamentos alimentados por baterias. Além disso, foi desenvolvido para ser

embarcado diretamente nos sensores e atuadores. Sua camada física possui também melhores

características para operação em temperaturas extremas. Opera em taxas mais baixas, sendo bem mais

robusto contra interferências no sinal que o Wi-Fi e o Bluetooth. Contudo, devido à baixa potência

empregada pelos seus transmissores, a distância também é limitada pouco mais de 100m.



19.6.4. Padrão Hart Wireless

O protocolo HART é de longe o mais conhecido e utilizado na automação industrial para o controle de

processos. Ele permite que um sinal digital modulado em FSK seja subreposto ao sinal convencional de 4-20

mA, trafegando dados em modo half- duplex a uma taxa de 1200 bps.

Pela sua fácil integração aos sistemas de controle e facilidade de uso tornou-se um padrão mundial

na indústria. Apesar do crescimento de tecnologias como FOUNDATION Fieldbus e Profibus PA, quando o

assunto é controle de processos contínuos, mais de 70% de todos os instrumentos instalados ao redor do

mundo ainda são 4-20 mA + HART.

Essa é a principal razão pela qual a HART Communication Foundation (HCF), sediada nos EUA, lançou

em 2004 o desafio de criar um padrão sem fio para comunicação HART. O resultado esperado é uma

tecnologia confiável que garanta interoperabilidade entre os produtos e novas alternativas de conectividade

para a instrumentação industrial.

O protocolo HART é um bom candidato para os padrões emergentes sem fio, pois não exige altas

taxas de comunicação e nem um controle tão preciso das latências na camada física.

19.7. COMPARATIVO ENTRE TECNOLOGIAS

A tabela a seguir compara resumidamente as três principais tecnologias-padrão que estão sendo

usadas atualmente nas aplicações wireless industriais e comerciais.

É possível observar que estas são tecnologias complementares ao invés de competir entre si, cada

uma se presta a diferentes objetivos.



Tabe la 27: Pr inc ipa is Tecno log ias Sem F io Para Automação Industr ia l

61

O padrão Hart Wireless: O protocolo HART é de longe o mais conhecido e utilizado na

automação industrial para o controle de processos. Ele permite que um sinal digital modulado

em FSK seja subreposto ao sinal convencional de 4-20 mA, trafegando dados em modo half-

duplex a uma taxa de 1200 bps.

Pela sua fácil integração aos sistemas de controle e facilidade de uso tornou-se um padrão

mundial na indústria. Apesar do crescimento de tecnologias como FOUNDATION Fieldbus e

Profibus PA, quando o assunto é controle de processos contínuos, mais de 70% de todos os

instrumentos instalados ao redor do mundo ainda são 4-20 mA + HART (MATA 2006).

Essa é a principal razão pela qual a HART Communication Foundation (HCF), sediada nos

EUA, lançou em 2004 o desafio de criar um padrão sem fio para comunicação HART. O

resultado esperado é uma tecnologia confiável que garanta interoperabilidade entre os

produtos e novas alternativas de conectividade para a instrumentação industrial.

O protocolo HART é um bom candidato para os padrões emergentes sem fio, pois não exige

altas taxas de comunicação e nem um controle tão preciso das latências na camada física.

(MATA, 2006).



ANOTAÇÕES



20. SISTEMAS GERÊNCIA DE INFORMAÇÃO INDUSTRIAL

O desenvolvimento de software para automação industrial foi grandemente impulsionado pela adoção

dos protocolos digitais, tanto sob a forma de software embarcado, dada a necessidade de drivers de

comunicação para os dispositivos, quanto de ferramentas de software para supervisão, controle, calibração

e configuração remota de instrumentos de campo. Surgiu também a oportunidade de criação de programas

para tratamento da grande quantidade de dados que passou a ser transmitida do campo para a sala de

controle, bem como para geração de informações úteis para outros setores da empresa.

Os sistemas de gerência de informação industrial, que são englobados com o termo geral de

Enterprise Production Systems (EPS), onde estão incluídos os Plant Information Management System (PIMS)

e os Manufacturing Execution Systems (MES) atuam como um “intermediário” entre o chão-de-fábrica e os

sistemas corporativos de gestão da planta, Enterprise Resource Planning (ERP), responsáveis pela

transformação desses dados em informações de negócio. Apesar de serem responsáveis, em suma, pela

coleta e disponibilização de dados do chão-de-fábrica, eles são diferentes, isto é, desempenham diferentes

papéis nesse contexto, embora alguns sistemas comerciais de PIMS e MES hoje disponíveis no mercado

apresentem, de forma “errônea”, algumas sobreposições funcionais, o que cria dificuldades adicionais

posteriores de integração e mesmo de compreensão dos conceitos.

20.1. MES (MANUFACTURING EXECUTION SYSTEM)

MES (Manufacturing Execution System) ou Sistema de Execução da Manufatura foi criado em 1990

por Bruce Richardson da Advance Manufacturing Research (AMR). Controla todo o fluxo produtivo, incluindo

estoques de matérias-primas, produtos em processamento e disponibilidade de máquinas. Através do MES,



podem ser calculados os indicadores chave de desempenho (Key Performance Indicators - KPI), que

contribuem para a melhoria do desempenho da planta local.

Surgiu da necessidade de se constituir um nível intermediário entre os sistemas integrados de

gestão empresarial (Enterprise Resource Planning - ERP) e o chão de fábrica. Devido a natureza dos dados

lhe interessam, os MES são mais voltados a indústrias de processos discretos, por batelada.

MES (Sistemas de Execução da Produção), são soluções tecnológicas que tem o objetivo de

gerenciar todas as etapas de produção. A importância destes sistemas vem da lacuna que normalmente

existe entre o ERP (Entreprise Resource Planning) e os softwares específicos da linha de produção.

O MES pode importar dados do ERP e integrá-los com o dia-a-dia da produção, gerenciando e

sincronizando as tarefas produtivas com o fluxo de materiais. Considerando que na cadeia de suprimento o

maior valor agregado costuma estar na produção, faz todo sentido investir em sistemas que otimizem o

fluxo, controle e qualidade do material.

Estas são algumas das funções que os sistemas MES costumam ter:

• Importação de dados do sistema ERP: itens, BOMs, estações de trabalho, armazenagem, estoque,

planos da qualidade, dados de funcionários, etc;

• Importação de parâmetros para a produção, como pedidos e prioridades de manufatura;

• Emissão automatizada de instruções para que o armazém entregue o material nas células de

trabalho;

• Exibição da fila de trabalho, instruções e documentação específica para a célula de trabalho, em

função das prioridades definidas anteriormente;

• Armazenamento das informações de atividades da produção: tempos de operação (por operador),

tempos de máquinas, componentes usados, material desperdiçado, etc;

• Instruções para reposição de material na linha de produção;



• Armazenamento e divulgação dos dados de qualidade;

• Instruções para que a continuidade do fluxo de materiais pela linha;

• Monitoramento da produção em tempo real, e ajustes em todas as etapas conforme seja

necessário;

• Análise de métricas e desempenho da produção.

Os principais benefícios que podem ser obtidos na implementação do MES são:

• Redução do desperdício (excesso de produção, tempos de espera, inventário desnecessário,

defeitos);

• Redução dos tempos de produção;

• Redução dos custos de mão de obra e treinamento;

• Apoio à manufatura enxuta;

• Apoio à melhoria contínua;

• Melhora a confiabilidade do produto final (melhor qualidade);

• Aumenta a visibilidade das atividades do chão de fábrica, assim como dos custos do processo de

manufatura.



20.1.1. O Conceito Básico

Para a tomada de decisões empresariais é necessário que o tomador de decisão possua

informações precisas do que esta ocorrendo em sua produção, na cadeia de suprimentos, no custo de seu

produto final, nos pedidos que entram e nos estoques atuais, logísticas de entrega, enfim, toda a cadeia

produtiva precisa estar em conformidade com os resultados que a companhia está buscando.

Um exemplo simples de problemas neste sentido ocorre quando um cliente coloca um pedido, o

vendedor possui uma informação de disponibilidade do produto, porém esta disponibilidade não é atualizada

on-line e o produto na realidade não estará disponível no prazo previsto, gerando a necessidade de novo

contato com o cliente, muitas vezes gerando a perda da venda e descontentamento do cliente final.

Atualmente, a grande maioria das empresas divulga seus produtos na internet e muitas já utilizam

alguma forma de comércio via rede mundial de computadores. Trata-se de um processo irreversível e que

tem ajudado muito os consumidores a explorar cada vez mais opções antes da compra de um produto ou

serviço. Por outro lado, as empresas necessitam cada vez mais de automatizar seus processos para

responder com mais agilidade e competitividade às exigências do cliente. Neste contexto a automação

focalizada no negócio e nos resultados a serem alcançados consiste no alicerce para se atingir esta

competitividade. A disponibilidade de informações atualizadas e precisas é fundamental para termos êxito

nesta tarefa.

A palavra chave é integrar as informações do chão de fábrica com os sistemas de tomada de

decisão. Esta não é uma tarefa fácil e instantânea. Os processos devem ser sistematizados antes de serem

automatizados. É necessária uma equipe multidisciplinar e também muita discussão para se achar a melhor

solução custo benefício. A Figura 244 mostra os componentes da pirâmide de automação com a introdução

dos sistemas de gestão empresarial denominados ERP (enterprise resource Planning) e MES (Manufacturing

Execution System).



F igura 244: A P i râmide da Automação Antes e Depo is dos S is temas ERP e MES

20.1.2. Aplicabilidade

Um sistema MES coleta e acumula informações do realizado no chão de fábrica e as realimenta para o

sistema de planejamento. O MES cumpre dois papéis: um é o de controlar a produção, ou seja, considera o

que foi efetivamente produzido e como foi produzido e permite comparações com o que estava planejado

para, em caso de não coincidência, permitir o disparo de ações corretivas. O outro papel é de liberar as

ordens de produção, tendo a preocupação de detalhar a decisão de programação da produção definida pelo

MRP (manufacturing resources planning), ou seja, garantir que o plano definido pelo MRP seja cumprido.

Com isso, é possível saber exatamente a capacidade do chão de fábrica dentro de um determinado

horizonte de planejamento.

A necessidade de automatizar os processos para responder com mais agilidade e competitividade às

exigências do cliente é uma preocupação para as empresas. Neste contexto, a automação focalizada no

negócio e nos resultados a serem alcançados consiste no alicerce para se atingir esta competitividade. A

disponibilidade de informações atualizadas e precisas é fundamental para se ter êxito nesta tarefa.

Integrar as informações do chão de fábrica com os sistemas de tomada de decisão não é uma

tarefa fácil e instantânea. Os processos devem ser sistematizados antes de serem automatizados. É

necessária uma equipe multidisciplinar e também muita discussão para se achar a melhor solução custo

benefício. A figura 244 mostra os componentes da pirâmide de automação com a introdução dos sistemas



de gestão empresarial denominados ERP (Enterprise Resource Planning) e MES (Manufacturing Execution

System) .

O grande desafio da automação é em primeiro lugar estabelecer um amplo diálogo com a equipe de

produção e a equipe de tomada de decisões para entender bem o processo produtivo e as informações

necessárias para depois propor o que precisa ser feito em termos de arquitetura do sistema. O conceito é

transformar uma “montanha” de dados aquisitados em informação útil para tomada de decisões.

O uso do MES é devido a sua capacidade de ajudar na eficiência do processo industrial. Utilizando

estes indicadores chave de desempenho, a performance on-line poderá ser monitorada, acessada e

melhorada, além de outras áreas como a análise das eficiências global de equipamentos e da planta, do

inglês Overall Equipment Efficiency e Overall Plant Efficiency, respectivamente.

A performance pode ser medida em tempo real com relatórios resumidos que permitem que ações

instantâneas ou planejadas sejam tomadas de forma que a qualidade seja mantida ou melhorada, este é o

principal objetivo de um sistema MES e os principais motivos para a utilização de um sistema de execução de

manufatura são:

• Redução do tempo de ciclo de produção;

• Aumentar a qualidade do produto;

• Otimização dos recursos empregados na produção;

• Prevenir erros de produção;

• Simplificar o processo de produção;

• Diminuir custos de produção.

No âmbito de soluções MES, existe uma organização internacional chamada MESA (Manufacturing

Enterprise Solution Association), que tenta criar modelos, guidelines, especificações e métricas para

sistemas MES, que contribui com a ISA (Modelo ISA-95) (RABELO, 2009).



20.2. PIMS (PLANT INFORMATION MANAGEMENT SYSTEM)

Software utilizado para armazenamento de todas as informações relevantes de processo. Coleta

informações dos sistemas de supervisão, sistemas de controle e sistemas legados (já existentes) e os

armazena em uma base de dados, que se distingue dos bancos de dados convencionais por ter grande

capacidade de compactação e alta velocidade de resposta a consulta local.

PIMS são sistemas que adquirem dados de processo de diversas fontes, os armazenam num banco

de dados históricos e os disponibilizam através de diversas formas de representação. O PIMS nasceu na

indústria de processos contínuos, mais propriamente na indústria química e petroquímica para resolver o

problema da fragmentação de dados e proporcionar uma visão unificada do processo.

A implantação de um PIMS facilita a implantação de outros módulos de software como reconciliador

de dados, sistema especialista, MES, Supply Chain Manager e facilita a integração de sistemas ERP com o

chão de fábrica. A principal função de um PIMS é concentrar a massa de dados e permitir transformar dados

em informação e esta informação em conhecimento. Para um engenheiro de processo é a ferramenta

fundamental que permite tirar conclusões sobre o comportamento atual e passado da planta, que permite

confrontar o comportamento recente com o de dias atrás ou com o melhor já observado no sistema.

F igura 245: In tegração P IMS e MES

70

5.2 PIMS (Plant Information Management System)

Software utilizado para armazenamento de todas as informações relevantes de processo.

Coleta informações dos sistemas de supervisão, sistemas de controle e sistemas legados (já

existentes) e os armazena em uma base de dados, que se distingue dos bancos de dados

convencionais por ter grande capacidade de compactação e alta velocidade de resposta a

consulta local (GUTIERREZ; PAN, 2008).

Segundo SEIXAS FILHO (2003c), PIMS são sistemas que adquirem dados de processo de

diversas fontes, os armazenam num banco de dados históricos e os disponibilizam através de

diversas formas de representação. O PIMS nasceu na indústria de processos contínuos, mais

propriamente na indústria química e petroquímica para resolver o problema da fragmentação

de dados e proporcionar uma visão unificada do processo. A implantação de um PIMS facilita

a implantação de outros módulos de software como reconciliador de dados, sistema

especialista, MES, Supply Chain Manager e facilita a integração de sistemas ERP com o chão

de fábrica (figura 5.2). A principal função de um PIMS é concentrar a massa de dados e

permitir transformar dados em informação e esta informação em conhecimento. Para um

engenheiro de processo é a ferramenta fundamental que permite tirar conclusões sobre o

comportamento atual e passado da planta, que permite confrontar o comportamento recente

com o de dias atrás ou com o melhor já observado no sistema.

Figura 5.2 Integração PIMS e MES (SEIXAS FILHO, 2003c).

Segundo CARVALHO et al.(2005), os benefícios gerados pela implantação de um sistema

PIMS são muitos, entre eles destacam-se:

�! Centralização dos dados de processo, já que os sistemas PIMS centralizam toda a

informação em uma única base de dados;



Os benefícios gerados pela implantação de um sistema PIMS são muitos, entre eles destacam-se:

• Centralização dos dados de processo, já que os sistemas PIMS centralizam toda a informação em

uma única base de dados;

• Democratização da informação, já que o sistema permite que todos os usuários tenham acesso aos

dados da planta instantaneamente;

• Visualização do processo produtivo em tempo real, seja através de gráficos de tendências, relatórios,

telas sinóticas, aplicações Web, etc;

• Maior interatividade com os dados do processo, permitindo realizar cálculos, estudos estatísticos e

lógica de eventos, utilizando os dados do processo;

• Histórico de dados, capaz de armazenar até 15 anos de dados de processo graças a eficiência de

seu algoritmo de compressão;

• Receita de Processo, que permite identificar e armazenar os dados correspondentes ao melhore

resultado obtido na produção, para que estes sirvam como referência para as interações futuras.

Na sua forma clássica, os sistemas PIMS acessam as fontes de dados localizadas no Nível 1, onde

estão os sistemas de supervisão e aquisição de dados (SCADA) e sistema digital de controle distribuído

(SDCD). Porém, há algumas implementações que (também) acessam dados diretamente do Nível 1, por

exemplo dos CLPs



ANOTAÇÕES

.



21. DETECÇÃO DE ERROS

Erros de transmissão de dados podem ter diversas causas:

Ruídos • Branco

• Impulsivo

Distorções • Atenuação em amplitude

• Retardo de fase

• Deslocamento de frequência

Ruídos em geral ocorrem em rajadas (bursts):

Imagine uma rajada de 10 ms sobre uma comunicação de 9600 bps:

96 bits de dados serão atingidos.

A natureza de erros em rajada é muito importante para a detecção de erros.

21.1. TÉCNICAS PRIMITIVAS DE DETECÇÃO

21.1.1. Paridade Simples ou Paridade Vertical ou TRC

A cada caractere adicionamos um bit de paridade.

F igura 246: Par idade Par e Impar



Seja o caractere:

01001100

Vamos calcular o bit de paridade ímpar:

Determine a expressão para cálculo do bit de paridade ímpar em uma palavra de 8 bits:

Pi =

Determine a expressão para cálculo do bit de paridade par em uma palavra de 8 bits:

Pp =

Vamos calcular a eficiência de utilização de bits para este código:

Em geral este bit é calculado pelo hardware de transmissão de dados (USART) e é recebido,

verificado e retirado pelo hardware de recepção.

Qual a capacidade de detecção de erros deste algoritmo?

Apenas erros em um número ímpar de bits são detectados.

Exemplo 1

Caractere transmitido:



Caractere recebido:

A paridade calculada na recepção é 1 o que contraria o valor do último bit da palavra e o erro é

detectado.

Exemplo 2

Caractere transmitido:

Caractere recebido:

Existem dois bits trocados. O valor do bit de paridade calculado na recepção é 0.

Como o último bit da palavra que corresponde ao bit de paridade recebido também é 1, o erro não

é detectado.

21.1.2. Paridade Horizontal ou LRC (Longitudinal Redundancy Check)

Considere o bloco de dados a serem transmitidos:



F igura 247: Par idade Hor izonta l ou LRC

O último caractere representa a paridade dos caracteres anteriores calculada na vertical bit a bit.

Eficiência de utilização de bits para este código:

Supondo um bloco de 5 caracteres:

A eficiência aumenta quando aumentamos o tamanho do bloco.

Dois erros em caractere são detectados.

Dois erros em bits de mesma ordem em dois caracteres não são detectados.

Outros códigos de detecção longitudinal de erros são normalmente implementados em automação.

A maior parte não usa bits de paridade, mas uma palavra gerada pela soma de todos as demais

palavras da mensagem. Esses códigos são conhecidos pelo nome genéricos de Checksum .

21.2. CÓDIGOS CÍCLICOS DE DETECÇÃO DE ERROS

21.2.1. CRC – Cyclic Redundancy Code

• São capazes de detectar uma grande faixa de erros de transmissão, isolados ou em rajadas.

• Possuem algoritmo de cálculo mais complexo.



• Podem ser calculados por hardware ou software.

Princípio

1. Cada bit da mensagem m codificada em binário é considerado como um coeficiente de um

polinômio M(X) base 2.

2. A mensagem é deslocada para a esquerda de r posições, onde r é o número de bits do CRC (ordem

do polinômio verificador = número de bits da representação do polinômio verificador – 1).

3. A mensagem deslocada é dividida por um polinômio característico G(X).

4. O resto da divisão é somado à mensagem deslocada para formar a mensagem composta T(X).

5. T(X) é transmitida.

6. O receptor divide T(X) por G(X).

7. Se o resultado for 0, existe grande probabilidade de a mensagem estar correta, caso contrário,

existe um erro.

Exemplo

Seja a mensagem: 110101 e o polinômio correspondente é:

A palavra foi invertida julgando que a mensagem seria transmitida do LSb para o MSb (LSb

primeiro).



Exemplo 2

No próximo exemplo vamos considerar a transmissão no sentido inverso: MSb primeiro.

Cálculo do CRC:

F igura 248: Cá lcu lo do CRC para 110011

Como o resto foi 0, nenhum erro foi detectado.

Análise Matemática

Seja M(X) a mensagem a ser transmitida e seja G(X) o polinômio verificador.



F igura 249: Transmissão da Mensagem

Formação da mensagem

Observe que em módulo 2 as operações + e – se equivalem.

T(x) é equivalente à nossa mensagem composta.

Transmissão

Na recepção

Polinômios verificadores



Os polinômios são projetados para detectar erros que possuem certas características.

A referência [Peterson 61] apresenta todos os teoremas, demonstrando as propriedades destes

polinômios.

Erros simples

Teorema 1:

Um polinômio G(X) com mais de um termo é capaz de detectar qualquer erro simples.

G(X) = X + 1 // G(X) com dois termos

E = 2i ↔ E(X) = Xi

i é a ordem do bit contada a partir da direita. i=0 para o LSB.

Demonstração:

Para que ocorra detecção de erros simples, é necessário que G(X) não divida X i.

(X+1) não divide X i, assim como nenhum polinômio de grau maior de 1.

Número ímpar de erros

Teorema 2:

Todo polinômio divisível por X + 1 tem um número par de termos.



A consequência é que X+1 detecta não só qualquer erro simples como também qualquer número

ímpar de erros.

Demonstração: (por absurdo)

E(X) tem um número ímpar de termos.

Vamos supor E(X) seja divisível por (X+1):

E(X) = (X+1) Q(X)

Para X = 1 => E(1) = (1+1) Q(1) = 0 . Q(X).

E(1) = 0

Mas E(X) =1 para X = 1 porque E(X) tem um número ímpar de termos.

Logo, chegamos a um absurdo.

Erro de 2 bits

E = 2i + 2j (i > j e i – j = k)

E(X) = Xj ( Xi-j + 1 )

G(X) não deve dividir Xk + 1

Erro sem rajada (burst)

Def in ição: Rajada de tamanho k: qualquer padrão de erro no qual o número de símbolos entre o

primeiro e o último erro, incluindo estes erros é k.

E(X) = Xj +...+ XI j>i

Comprimento da rajada = k = j – i + 1



E(X) = X3 + X6 + X7

= 0 0 0 1 0 0 1 1 0 0 0 0 0 0 0

O comprimento da rajada acima é k = 5.

E(X) = Xi (Xj-i +...+ 1)

E(X) = Xi E1 (X)

G(X) não pode ser um divisor de E1 (X).

Tabe la 28: Tamanho da Ra jada

Polinômios mais utilizados

Tabe la 29: Po l inômios ma is Ut i l i zados



21.3. CÁLCULO DO CRC

O método de divisão polinomial que serviu de referência a este estudo não é usado na prática por

ser muito trabalhoso.

Seja a mensagem: M(X) = 000000000000001

Considerando que vamos enviar o LSB primeiro, a mensagem fica:

MLSB(X) = 100000000000000

Polinômio: G(X) = CRC16 = 11000000000000101

Cálculo do CRC através de divisão polinomial



F igura 250: CRC com D iv isão Po l inômios

21.3.1. Cálculo do CRC Através de Hardware

Pode-se projetar um circuito formado por um registrador de deslocamento (shift register) de r bits,

sendo r o número de bits do CRC, realimentado por portas XOR. Este tipo de circuito é denominado máquina

sequencial linear.

As teorias dos circuitos sequenciais lineares são utilizadas para projetar circuitos capazes de

realizar a multiplicação e divisão polinomial em diversas bases numéricas.

Cada estágio de um registrador de deslocamento representa um atraso no sinal de entrada.

Seja o circuito que sintetiza a função: z(t) = x(t) + x(t-1) + x(t-3)



Usando o operador de atraso D (Delay) podemos escrever:

z = x + Dx + D3x ou

z/x = D3 + D + 1

O circuito que sintetiza esta função é denominado de registrador de deslocamento feedforward:

Este circuito também realiza a multiplicação polinomial base 2.

A máquina que realiza a divisão polinomial (função inversa) é dada por:

A função realizada é:

Observe que neste circuito z é a entrada e x a saída.

O circuito utilizado na prática traduz o algoritmo de divisão polinomial e é dado por:



Para obter este circuito:

P(X) = X3 + X + 1

Representação binária: P = 1 0 1 1

Inverte-se a seqüência: Q = 1 1 0 1

Elimina-se o bit menos significativo: Qr = 1 1 0

Cada 1 marca o início de um registrador de deslocamento (shift register).

O valor a ser usado em nossos futuros algoritmo será justamente Qr = 1 1 0, que marca as

posições das portas ou-exclusivo no registrador de deslocamento de ordem 3 (3 posições). A este valor

chamaremos de Operando.

Este circuito realiza a divisão polinomial base 2 e é o circuito utilizado para o cálculo do CRC.

Exemplo

Mensagem = 10100001 (LSB primeiro)

Polinômio = 11001



F igura 251: Mensagem 11001 – CRC = 1101

CRC = 1101

Em seguida vamos apresentar os circuitos de cálculo de CRC para os principais polinômios

utilizados.



CRC 12

F igura 252: CRC 12

O registrador é inicialmente zerado.

A string de dados é combinada bit a bit com o conteúdo do registrador de deslocamento. A cada bit

as operações de xor são realizadas e o conteúdo do registrador é deslocado de uma posição para a direita.

Quando todos os bits da mensagem tiverem sido processados, o conteúdo do registrador é anexado ao final

da mensagem (LSB primeiro). A operação XOR deve ser realizada antes do deslocamento.



CRC CCITT

F igura 253: CRC CC ITT



CRC 16

F igura 254: CRC 16



CRC 16:RECEPÇÃO

F igura 255: CRC 16 Recepção



21.4. CÁLCULO DO CRC BITWISE

Os algoritmos de cálculo do CRC por software bit a bit são denominados algoritmos bitwise.

Estes algoritmos em geral simulam a ação da implementação por hardware.



O algoritmo 2 sintetiza exatamente o algoritmo fornecido por McNamara, emulando o circuito com

os registradores de deslocamento.

Observe que aplicar um clock no registrador de deslocamento eqüivale a realizar um shift para a

direita do valor que representa o conteúdo do registrador e em seguida realizar um XOR do bit mais

significativo do registro com o bit que alimenta a cadeia (XOR do dado com LSB do registrador):

Situação antes do pulso de clock:

F igura 256: Mensagem Antes do C lock

Situação após o pulso de clock:

F igura 257: Mensagem Após o C lock



Simulação através de registrador:

F igura 258: Mensagem no Reg is t rador

Alimentar 1 em um registrador de deslocamento = shift right + XOR 1000...

O primeiro algoritmo é mais eficiente pois combina o byte de dados com o CRC uma única vez e

depois toma a decisão de combinar o operando com o CRC apenas em função do conteúdo do CRC.

21.5. CÁLCULO DO CRC BYTEWISE

Um algoritmo mais eficiente foi publicado pela primeira vez na referência [Perez 83] e passou a ser

adotado em todas as implementações práticas por oferecer um algoritmo muito mais eficiente.

Vamos observar passo a passo o cálculo do CRC 16 e o conteúdo do shif register após cada

operação:

Convenção:

Conteúdo inicial do registrador de deslocamento: C0..C15

Mensagem de entrada: M0..M7



F igura 259: CRC Bytew ise



F igura 260: CRC Bytew ise

A lgor i tmo:

Para todos os bytes da mensagem faça:

1. Calcule Xi = Low(CRC ⊕ Mensagem)

2. Deslocar o CRC oito bits para a direita.

3. Calcular o valor combinado da função dos Xis abaixo da linha horizontal

4. Realizar o ou exclusivo do CRC com o valor calculado



Observe que uma vez escolhido X (existem 256 possibilidades), o valor calculado no passo 3 fica

determinado. Logo podemos pré calcular estes valores e guardá-los em uma look up table.

Tabe la 30: Tabe la de Operandos para Cá lcu lo de CRC16

Propr iedades:

Da observação de como Tab[X] é calculado acima, podemos tirar algumas conclusões. Estamos

supondo que o valor inicial do CRC é 0.

a) Observe que Tab[X] = CRC (X) onde X é um valor correspondendo a um byte: X7 .. X0. X varia de 0

a 255.

b) CRC(0) = Tab[0] = 0, independente do polinômio, pois o resto da divisão de 0 por qualquer

polinômio é 0.



c) CRC(0xFF) = Tab[0xFF] = T15 .. T0, onde Ti = XORNúmero_Par_de_Termos (1) = 0, ou Ti = XOR

Número_Impar_de_Termos (1) = 1. Observe que para o CRC16, CRC(0xFF) terá valor 1 apenas nos bits nas

posições 6 e 14 onde o número de termos Xj combinantes é ímpar. Portanto CRC16(0xFF) =

0x4040.

d) CRC(not M) = CRC(M ⊕ 0xFF) = CRC(M) ⊕ CRC(0xFF), onde M é uma mensagem de um byte.

Imagine que conhecemos o CRC(M) = T15 ..T0. O CRC(not M) terá o mesmo valor do CRC de M para

os bits em que o número de termos de Xi = Mi for par e terá o valor complementar ao de M onde o número

de termos de Xi = Mi for ímpar. A máscara que determina onde o número de bits combinantes de Xi é para

ou ímpar é exatamente o CRC(0xFF). Logo devemos trocar os bits do CRC(M) nestas posições onde

CRC(0xFF) tem um bit igual a 1, ou seja basta realizar o ou exclusivo de CRC(M) com o CRC(0xFF).

Exemplo:

Seja calcular o CRC(254).

CRC(254) = CRC(1) r CRC(0xFF) = 0xC0C1 r 0x4040 = 0x8081.

Esta propriedade implica que precisamos calcular apenas metade das posições da tabela, pois a

outra metade é determinada diretamente pela equação acima.



Tabe la 31: Tabe la de Operandos para Cá lcu lo de CRC CC ITT

A lgor i tmo f ina l :

Para todos os bytes da mensagem faça:

1. Calcule Xi = Low(CRC ⊕ Mensagem).

2. Deslocar o CRC oito bits para a direita.

3. Realizar o ou exclusivo do CRC com o valor da tabela indexado por X.

Esta tabela pode ser calculada para qualquer polinômio automaticamente através de um programa, que

é mostrado no exemplo completo que se segue:



21.6. CRC-32

Este polinômio possui maior capacidade de detecção de erros que os polinômios de 16 bits, sendo

usado na rede Ethernet, WinZip e PKZIP, etc.

O polinômio utilizado é:



21.7. REVERTENDO O CRC

Este é um assunto academicamente interessante, principalmente se você for um hacker. Vamos

discutir como alterar um conjunto de bytes em uma string de bytes de modo que o CRC não seja alterado.

Este problema pode ser formulado da seguinte maneira:

Considere que uma mensagem possui N bytes e que o seu CRC calculado utilizando o polinômio de

16 bits P16 é dado por:

CRC 16 (Mn) = K

Mensagem Original

F igure 261: Mensagem Or ig ina l

Parte desta mensagem será substituída por x novos bytes a partir da posição k



Mensagem Alterada

F igura 262: Mensagem A l terada

Os últimos bytes da modificação, posições mx-1 e mx conterão dois bytes de ajuste que

chamaremos de b e a respectivamente.

O problema consiste em calcular a e b de tal forma que o CRC final da mensagem seja K.

Considerações

1. Evidentemente o CRC da posição 1 até a posição k- 1 é o mesmo para as duas mensagens. Vamos

chamá-lo de K1.

2. A influência dos bytes da posição k+x até a posição N será a mesma nos dois casos.

3. Temos que fazer com que os CRCs ao chegar na posição k+x+1 seja o mesmo nos dois strings.

4. O valor inicial no registrador de CRC ao chegar na posição k será K1.

Ao calcular o CRC da mensagem modificada, ao chegar em k+x-3 teremos:

CRC (b1..bk-1, m1..mx-2) = R = RH | RL

Onde o símbolo | indica concatenação. RH é o byte mais significativo no CRC e RL o byte menos

significativo.

Para conservar o valor do CRC devemos ter:



R o x o y = K2

O operador “o” indica uma combinação segundo o algoritmo do cálculo do CRC do valor do

registrador quando acabamos de processar o patch com os bytes x e y em sequência.

Como calcular x e y?

Nós conhecemos R e K2.

Segundo o algoritmo bytewise que deduzimos temos:

Após processar o byte x:

Temp = (R >> 8) ⊕ Tab[ (R ⊕ x) & 0xFF]

Temp = RH ⊕ Tab[ (RL ⊕ x)]

Vamos supor que a posição apontada por RL ⊕ b contenha o dado: bH | bL

Temp = bH | RH ⊕ bL

Após processar o byte y:

CRC = (Temp >> 8) ⊕ Tab[ (Temp ⊕ y) & 0xFF] = K2

CRC = bH ⊕ Tab[RH ⊕ bL ⊕ y] = K2

Vamos supor que a posição apontada por RL ⊕ bL ⊕ y contenha o dado: cH | cL

CRC = cH | bH ⊕ cL = K2 = K2H | K2L

Logo pela equação acima nós deduzimos o valor de cH :

cH = K2H



Sabendo este valor nós podemos procurar na tabela por uma entrada de índice Ic tal que os seus

bytes mais significativos seja o valor desejado (K2H). Assim determinamos cL.

Como bH ⊕ cL = K2L temos que bH ⊕ cL ⊕ cL = K2L ⊕ cL

Logo daí determinamos: bH = K2L ⊕ cL

Devemos novamente procurar na tabela por uma entrada de índice Ib cujo byte mais significativo

coincida com bH.

Desta forma bL também fica determinado.

Já conhecemos b e c e também os índices destas posições: Ib e Ic.

RH ⊕ bL ⊕ y = Ic

Logo y = bL ⊕ RH ⊕ Ic

RL ⊕ x = Ib Logo x = RL ⊕ Ib



ANOTAÇÕES



22. CLASSIF ICAÇÃO ÁREAS

22.1. INTRODUÇÃO

A presença de equipamentos elétricos em áreas com atmosferas explosivas constituem uma das

principais fontes de ignição dessas atmosferas, quer pelo centelhamento normal como na abertura e

fechamento de contatos, como devido a temperatura elevada atingida pelo mesmo em operação normal ou

em falhas.

Esta apostila apresenta uma visão resumida da classificação de áreas segundo as normas

IEC/ABNT.

22.2. CLASSIFICAÇÃO DE ÁREAS

Áreas perigosas (Hazardous Areas) são locais onde existe ou pode existir uma atmosfera

potencialmente explosiva ou inflamável devido à presença de gases, vapor, poeiras ou fibras.

Na Europa e atualmente no Brasil a classificação das áreas perigosas é feita usando- se o conceito

de:

ZONAS – usadas para definir a probabilidade da presença de materiais inflamáveis;

TIPOS DE PROTEÇÃO – que denota o nível de segurança para um dispositivo e;

GRUPOS – que caracterizam a natureza inflamável do material.



22.2.1. Zonas

F igure 263: C lass i f i cação das Zonas Ex

22.2.2. Tipos de Proteção

Ex d - Tipo de Proteção A Prova de Explosão

Ex p - Tipo de Proteção Pressurizado

Ex m - Tipo de Proteção Encapsulado

Ex o - Tipo de Proteção Imerso em Óleo

Ex q - Tipo de Proteção Imerso em Areia

Ex i - Tipo de Proteção Intrínseca

Ex e - Tipo de Proteção Segurança Aumentada

Ex n - Tipo de Proteção Não Acendível



Ex s - Tipo de Proteção Especial

F igure 264: Exemplo de Et iqueta de C lass i f i cação

22.2.3. Grupos

GRUPO I

Para operação em mineração subterrânea suscetíveis a exalação de grisu

GRUPO IIA

Para operação em instalações de superfície onde pode existir perigo devido ao grupo do propano.

GRUPO IIB

Para operação em instalações de superfície onde pode existir perigo devido ao grupo do etileno.

GRUPO IIC

Para operação em instalações de superfície onde pode existir perigo devido aos grupos do hidrogênio e acetileno.



F igure 265: C lass i f i cação dos Grupos

22.3. CLASSIFICAÇÃO DE TEMPERATURAS

Para equipamentos elétricos do GRUPO I, a temperatura máxima de superfície não deve exceder:

• -150°C sobre qualquer superfície onde possa formar uma camada de pó de carvão;

• 450oC quando o risco acima é evitado, por exemplo, através de vedação contra poeira ou

por ventilação.

As normas (NBR 9518) também classificam as temperaturas máximas de superfície para

equipamentos elétricos do Grupo II.



As CLASSES DE TEMPERATURA identificam a máxima temperatura de superfície que uma parte

qualquer de um equipamento pode atingir em operação normal ou de sobrecarga prevista, considerando a

temperatura ambiente máxima igual a 40°C, ou em caso de defeito. Essas classes de temperatura devem ser

menores que a temperatura de ignição dos gases e vapores do meio circundante ao equipamento.

F igure 266: C lass i f i cação de Temperaturas

22.4. DESCRIÇÃO DOS TIPOS DE PROTEÇÃO

22.2.3. À Prova de Explosão Ex d (Explosion Proof ou Flame Proof)

Invólucro à prova de explosão: é um sistema suficientemente resistente e vedado para não

propagar uma explosão, e cuja temperatura superficial não provoque a ignição de uma atmosfera explosiva.

Isto implica uma construção robusta, com tampas roscadas ou parafusadas. Esses invólucros são

construídos de forma a, ocorrendo a ignição de uma mistura dentro dele, resistir mecanicamente à pressão,

impedindo que a explosão se propague para o meio externo.

A NBR 5363 especifica os interstícios máximos entre as peças dos invólucros blindados (entre a

tampa e a caixa, ou entre o eixo e o furo da tampa do invólucro de um comutador, por exemplo). Tais

interstícios auxiliam no alívio da pressão interna ao invólucro, quando de uma explosão no interior deste. A

largura e comprimento destes interstícios (limitados aos valores normalizados) devem ser suficientes para

que o gás se resfrie antes de alcançar o ambiente externo.

Ap l icação: Zonas 1 e 2.



22.2.4. Segurança Aumentada Ex e (NBR 9883/87 e IEC 79-7)

Equipamento elétrico de segurança aumentada é aquele que “sob condições normais de operação

não produz arcos, faíscas ou aquecimento suficiente para causar ignição da atmosfera explosiva para a qual

foi projetado, e no qual são tomadas as medidas adicionais durante a construção, de modo a evitar com

maior segurança, que tais fenômenos ocorram em condições de operação e de sobrecarga previstas”.

Equipamentos típicos com segurança aumentada são os motores de gaiola, transformadores de potência e

de medição, luminárias e caixas de distribuição e de ligação.


22.2.5. Equipamento Elétrico Imerso em Óleo Ex o (NBR 8601 e IEC 60079-6)

O equipamento elétrico é imerso em óleo de tal modo que não inflame uma atmosfera inflamável

acima do líquido ou na parte externa do invólucro. Este tipo de proteção é aplicável somente para

equipamentos fixos.


22.2.6. Equipamentos Pressurizados Ex p

Neste tipo de proteção uma pressão positiva superior à pressão atmosférica, é mantida no interior

do invólucro de modo a evitar a penetração de uma atmosfera explosiva que venha a existir ao redor do

equipamento.

São definidos três tipos de pressurização que reduz a classificação no interior do invólucro

pressurizado de:

• px – Zona 1 para não classificada ou Grupo I para não classificada;

• py – Zona 1 para Zona 2;



• pz – Zona 2 para não classificada. Aplicação: Zonas 1 e 2.

22.2.7. Equipamentos Imersos em Areia Ex q

Neste tipo de proteção as partes que podem inflamar uma atmosfera explosiva são imersas por

uma material de enchimento de modo a evitar a ignição de uma atmosfera explosiva externa. Este tipo de

proteção só se aplica a equipamentos com corrente nominal menor ou igual a 16A; que consumam potência

menor ou igual a 1000VA cuja tensão de alimentação não seja superior a 1000V.


22.2.8. Equipamento Elétrico Encapsulado Ex m

As partes que podem causar ignição são encapsuladas por uma resina de modo a não conseguir

inflamar uma atmosfera explosiva externa.


22.2.9. Equipamento de Segurança Intrínseca Ex i

São aqueles que em condições normais (isto é, abertura e fechamento do circuito) ou anormais

(curto circuito, falta à terra) não liberam energia suficiente para inflamar a atmosfera explosiva. Os

equipamentos elétricos de segurança intrínseca são classificados em duas categorias: “ia” – estes são

projetados de tal forma que não são capazes de causar uma ignição em operação normal e mesmo com

aplicação de duas falhas evidentes mais as falhas não evidentes; e “ib” – que são aqueles incapazes de

causar uma ignição em operação normal e com a aplicação de uma falha evidente mais a aplicação das

falhas não evidentes.

Ap l icação: “ ia” – Zona 0;

Ap l icação: “ ib” – Zonas 1 e 2.



Nota:

Falha evidente é aquela que está em conformidade com os requisitos (regras de construção da norma IEC

60079-11) de construção básicos do tipo de proteção; e as falhas não evidentes são aquelas não em

conformidade com essas regras.

22.2.10. Equipamento Elétrico não Acendível Ex n

Equipamentos que, em condições normais de operação e sob determinadas condições anormais

especificadas, não causam a ignição da atmosfera explosiva de gás existente no ambiente.

Ap l icação: Zona 2

22.2.11. Equipamento com Proteção Especial

Não há uma definição neste tipo de proteção, que foi previsto para permitir o desenvolvimento de novos

tipos de proteção pelos fabricantes.

redes industriais gama filho (2).pdf

Documents