Om tollavgifter for budsjetterminen 2001 I

O protocolo MODBUS foi desenvolvido pela Modicon em 1979, que estabelece a ligação entre master-slave/cliente-servidor e garante a comunicação entre dispositivos inteligentes.

Inicialmente este protocolo trabalhava com a interface RS232, contudo, com a sua constante evolução passou a usar RS-422 ou RS-485 para maiores velocidades de comunicação e maiores distâncias, sendo para vários tipos de aplicações [22].

3.4.1 MODBUS (Standard)

O protocolo MODBUS (standard) ajusta-se à camada de aplicação (camada 7) do modelo OSI, sendo usualmente utilizado na comunicação entre master-slave. É habitual encontrar este protocolo nas comunicações assíncronas entre PLC e equipamentos com entrada e saída de dados, tais como, relés, sensores de pressão ou temperatura,

24 controladores de processo, válvulas, entre outros. Esta topologia tem duas opções físicas de uso possível:

 Ligação ponto a ponto por RS-232  Ligação multiponto por RS-485

Relativamente ao procedimento de envio das frames entre master-slave o protocolo tem a capacidade de determinar como o dispositivo construirá mensagem e a enviará.

O master pode endereçar as frames em broadcast3 ou individualmente. O slave apenas retorna uma resposta se houver uma frame com o seu endereço característico, pois o envio de frames em broadcast não retorna respostas por parte do slave.

Quando o master faz um pedido através do envio de uma frame, este informa o dispositivo que pretende comunicar (através de um endereço específico) e qual a ação que espera que seja realizada. Na frame são enviadas informações relativas ao registo inicial e a quantidade de registos a serem lidos. No campo de verificação de erro, todo o conteúdo será analisado e validado no caso de não haver erro na receção de dados.

Do lado do slave, é enviada uma resposta com os dados recolhidos pelo dispositivo ou com o seu estado. No caso de correr um erro de receção, será enviada uma resposta com o erro pela qual a receção não foi concluída com sucesso.

Na figura seguinte é possível verifica uma troca de frames entre master e slave.

Figura 14 - Troca de dados entre master e slave

Quanto aos modos de transmissão, este protocolo oferece duas alternativas, desde que os parâmetros de comunicação sejam iguais para todos os dispositivos. Existe o modo RTU onde cada byte possui dois dígitos hexadecimais e o modo ASCII onde cada byte contém caracteres ASCII entre 0 e 9, A e F.

3

25 Quando é usada a transmissão RTU, existe o benefício de termos uma troca de caracteres de maior densidade, permitindo uma maior fluidez de dados em relação ao ASCII para a mesma velocidade de comunicação. A vantagem do ASCII centra-se na possibilidade de fazer intervalos entre o primeiro caracter e o segundo, sem causar erro na frame [23].

3.4.2 MODBUS

PLUS

O protocolo MODBUS Plus é uma atualização do protocolo MODBUS padrão relativamente à forma como os dados são transacionados. Neste caso, a topologia de comunicação é realizada por peer-to-peer, admitindo que qualquer controlador é capaz de trocar dados com outros controladores e que o mesmo controlador tenha a função de master e slave.

A troca de dados é realizada por pacotes que contêm um conjunto de frames, independentemente do tipo de transmissão, ou seja, a informação de um dispositivo pode ser realizada conjuntamente por dois controladores. A gestão dos pacotes na rede é feita pelo próprio protocolo, que coloca automaticamente os limites de início e fim de cada frame, de cada pacote enviado, e, em simultâneo, verifica a entrega de dados evitando o endereçamento em cada frame.

3.4.3 MODBUS TCP/IP

Em 1999 foi acrescentada à norma MODBUS a norma MODBUS TCP/IP, adicionando uma nova funcionalidade ao protocolo original e adaptando-o às necessidades mais atuais.

A estrutura básica de uma frame Modbus TCP/IP consiste em três campos distintos: o cabeçalho, o function code pretendido e uma gama de informação adicional que está intrinsecamente ligada com o function code da mensagem.

26 O function code não é mais do que um código de dois bytes que identifica uma função que o destinatário deverá reconhecer. Os function code podem ser:

 Funções públicas – Funções que cumprem estritamente o que está definido pelo protocolo.

 Funções definidas pelo utilizador - São funções que, como o próprio nome indica, são implementadas pelo próprio utilizador, sem que se garanta a compatibilidade com outras, podendo mesmo existir funções diferentes com o mesmo código.

 Function code reservados - Funções atualmente utilizadas por algumas empresas e que detêm o direito exclusivo do seu uso. Como tal, não podem ser utilizadas pelo público em geral.

Tabela 1- Exemplo das funções do protocolo Modbus TCP/IP

Descrição function code (em hexadecimal)

Ler entrada discreta 0x02

Ler saída 0x01

Escrever saídas simples 0x05

Escrever saídas múltiplas 0x0F

Ler registo de entrada 0x04

Ler registo “holding” 0x03

Escrever registo simples 0x06

Escrever registos múltiplos 0x10

Ler/escrever registos múltiplos 0x17

Na Figura 16 é possível observar o esquema para a troca de informação no protocolo MODBUS TCP/IP, onde no pedido inicial temos um primeiro campo incorporado pelo cabeçalho/endereço de destino, que é responsável por chamar uma função específica do lado do servidor. O segundo campo é reservado a dados adicionais relativos à respetiva função. Este segundo campo pode ser utilizado para enviar dados específicos a cada função ou para reportar erros de leitura na mensagem recebida por parte do servidor [24].

27

Figura 16 – Troca de informação no protocolo MODBUS TCP/IP

3.5. P

ROFIBUS

O protocolo de rede PROFIBUS (Process Fieldbus) foi idealizado a partir de 1987 e tem a capacidade de inter-relacionar equipamentos com processos industriais. Através de uma estrutura automatizada bem definida, consegue relacionar os níveis intermédios (também conhecidos como chão de fábrica – Field Level) com os níveis superiores (como por exemplo, gestão ou Cell Level).

A família Fieldbus está distribuída conforme o nível de aplicação, velocidade de comunicação e equipamentos a utilizar. Na Figura 17 é possível ver a distribuição definida pelo PROFIBUS para o uso dos diferentes sub-protocolos.

28

Figura 17 - Arquitetura PROFIBUS

Como característica geral, estamos perante um protocolo multi-mestre com capacidade para 127 nós.

Os dispositivos mestres coordenam a comunicação no meio do barramento e são capazes de enviar mensagens, independentemente de solicitações externas, desde que possuam ligação, sendo conhecidas como estações ativas.

Os dispositivos escravos são dispositivos externos e não possuem acesso direto ao barramento de comunicação. Apenas confirmam a receção de informação ou respondem a informações quando solicitadas pelas estações mestre, sendo que os dispositivos escravos também são conhecidos como estações passivas.

O principal controlo de acesso ao meio é fundamentado na lógica token bus4 entre os dispositivos mestres fundamentado no princípio master-slave, sendo que a eficiência do protocolo é baseada nos serviços existentes na camada de enlace do próprio protocolo (denominada FDL – FieldBus Data Link) [25].

4

29

3.4.1 PROFINET

O principal conceito do protocolo PROFINET baseia-se na comunicação entre equipamentos de controlo (PLC, DCS e PC) e equipamentos de campo (sensores, atuadores e sistemas produtivos), sendo que, ao contrário dos outros protocolos exige hierarquia entre os vários elementos da rede. Contudo, o protocolo define três tipos de dispositivos:

 IO-Controller: Pode ser denominado como cérebro do sistema. É responsável pela configuração e parametrização dos dispositivos dispostos na rede, controlando a transferência de dados ao longo do processo.

 IO-Device: Representa os dispositivos de campo, enviando ciclicamente dados para o processo, diagnósticos e alarmes referentes ao IO-Controller e vice-versa.

 IO-Supervisor: Desempenha a configuração ou diagnóstico dos dispositivos de rede.

A frame de dados enviados entre os dispositivos e controladores, é caracterizada pela verificação dos seis primeiros bytes da mensagem, relativas ao MAC address de destino. Estes bytes iniciais garantem a inexistência de colisões de mensagens sem atrasos na entrega, mas não asseguram a verificação de erros.

Quando a rede é iniciada, as relações lógicas denominadas Application Relationship (AR) entre IO-controller e IO-Devices são estabelecidas. De seguida, são criados canais denominados de Communication Relationship (CR) que auxiliarão a configuração dos alarmes e dos dados de processo que serão trocados. Neste momento, ambos os dispositivos (IO-Controller e IO-Device) estão prontos para trocar dados de forma contínua e bidirecional. Cada IO-Device envia uma frame para o IO-Controller com valores recebidos provenientes dos dispositivos de campo, enquanto o IO-Controller responde com frames que contem os valores de saída para os dispositivos de campo.

Na figura seguinte é possível verificar três tipos de comunicação segundo o modelo OSI:

1. Representa o canal de comunicação TCP/IP. Neste canal são configurados os IO-Devices e as aplicações que serão abertas. A comunicação é non-real time (nRT) e acíclica. As mensagens são longas e lentas.

30 2. Os dados transmitidos são cíclicos. Estamos perante um canal de alto desempenho e denominado por real time (RT).

3. Permite a troca de dados sincronizada com um jitter5 de menos de 1 us, compreendendo tempos de ciclo à volta dos 31,25us [26].

Figura 18 - Protocolo PROFINET segundo o modelo OSI [26]

3.5.2 P

ROFI

B

US

DP(

DESCENTRALIZED PERIPHERICAL

)

O protocolo de comunicação PROFIBUS DP permite a troca de informação de forma cíclica ou acíclica mediante a configuração de utilização. No processo de comunicação entre o master e o slave, o master (PLC, PC ou DCS) interage ciclicamente com os slaves para receber dados dos mesmos. O slave que é invocado pelo master, recebe um pedido através de uma frame, que contem informação relacionada com a velocidade de transmissão, e com o tipo de valor que pretende receber.

Na perspetiva de otimizar o protocolo, foram desenvolvidas três versões de comunicação para diferentes tipos de aplicação: DP-V0, DP-V1 e DP-V2 (Figura 19).

A versão DP-V0 provém da elementar função de comunicação do protocolo. Inclui, em particular, comunicação cíclica, módulos e canais específicos de diagnóstico e

5

31 localização. São exemplos de aplicação a deteção de excesso de temperatura e de curtos de circuitos nas saídas.

A versão DP-V1 é um suplemento ao DP-V0 com funções acíclicas de comunicação, ou seja, funções de parametrização, operação, monitorização e alarme. O DP-V1 permite o acesso remoto através de ferramentas apropriadas.

O DP-V2 contém funções adicionais que fazem uma extensão do DP-V1, em particular, funções que requerem controlo. Estas funções possibilitam a sincronização cíclica e definição de tempos. [27]

Figura 19 - Níveis do protocolo PROFIBUS DP [27]

3.5.3 P

ROFI

B

US

PA(

PROCESS AUTOMATION

)

A rede ProfiBus PA foi especificamente definida para a automatização de processos e direcionada para áreas de elevado risco de explosão. Contudo, este protocolo de comunicação tem características de segurança essenciais tais como:

32

 Comunicação transparente através do barramento de automação do processo PROFIBUS PA e do barramento de automação industrial PROFIBUS-DP;

 Alimentação e transmissão de dados sobre o mesmo par de fios baseado na tecnologia IEC 61158-2.

Normalmente, a rede ProfiBus PA está ligada ao nível superior da rede ProfiBus DP utilizando acopladores ou PA links, sendo que, também é possível verificar ligação na parte de supervisão do processo à rede Ethernet. Na figura seguinte é possível ter a perceção de como é efetuada a ligação entre as duas diferentes redes através de um PLC.

Figura 20 - Exemplo de Arquitetura com ProfiBus PA [28]

A rede ProfiBus não deteta diferenças entre os diferentes protocolos, porque do ponto de vista de configuração, os acopladores ou PA links são transparentes na rede, não ocupam endereços e não precisão ser adicionados na rede. [28]

3.5.4 P

ROFI

B

US

FMS

No ProfiBus FMS as camadas 1, 2 e 7 do modelo OSI são essenciais. A camada de aplicação é composta por FMS (Fieldbus Message Specification) que define uma ampla

33 seleção de serviços de comunicação entre master-slave e do LLI (Lower Link Interface) que define a representação dos serviços FMS na transmissão de dados.

Neste protocolo de comunicação é criada uma lista com todos os dispositivos ligados. Esta lista contém a descrição, estrutura, tipo de dados e endereço associado de cada um. O ProfiBus FMS proporciona os seguintes serviços:

 Gestão de contexto (estabelecer ou encerrar conexões lógicas);

 Acesso a variáveis;

 Gestão de domínios (possibilita transmitir grandes quantidades de memoria);

 Gestão de eventos (envio de mensagens e alarmes);

 Suporte VFD (identificação de estado);

 Gestão da lista dos objetos (leitura e escrita na lista de dispositivos).

O mapeamento das camadas 2 e 7 é feito pelo LLI, que executa o controlo do fluxo e monitorização em relação ao estado da ligação. O LLI oferece vários tipos de associação de comunicação para a execução do FMS e dos serviços de gestão.

As associações com comunicação orientadas para as ligações representam uma ligação lógica ponto a ponto entre dois processos de aplicação, enquanto que, as associações com comunicação sem ligação possibilitam a um dispositivo comunicar simultaneamente com outras estações. [29]

In document kapitler som gjelder utbytte m.v. for 2001 (sider 192-199)