apostila sobre modbus

5/8/2018 Apostila sobre ModBus - slidepdf.com

http://slidepdf.com/reader/full/apostila-sobre-modbus 1/62

Sérgio Queiroz de Medeiros

Especificação e Verificação Formal

do Modelo de Comunicação

do Projeto Automação de Poços

Natal

2004



Universidade Federal do Rio Grande do NorteBacharelado em Ciência da Computação

Especificação e Verificação Formaldo Modelo de Comunicação


Relatório Submetido à

Universidade Federal do Rio Grande do Nortecomo parte dos requisitos para a

obtenção do grau de Bacharel em Ciência da Computaçãocom ênfase em Computação Científica e especialização

em Sistemas em Tempo Real para Otimização e Automaçãono Setor Petróleo & Gás

Trabalho financiado pela Agência Nacional de Petróleo


Natal, março de 2004.



"Todos estes que aí estão

Atravancando o meu caminho,

Eles passarão. . .

Eu pasarinho"

Mário Quintana

ii



Agradecimentos

Ao povo lá de casa, o que inclui meu pai, minha mãe, minhas duas irmãs e até mesmo a gata.

Agradeço a Deus, apesar da pouca fé.

Aos meus amigos fora do curso, aos meus amigos do curso que me ajudaram muito a suportar este

tempo todo dentro da universidade e me ensinaram muito.

A todos os meus professores, de agora e de antes, que foram fundamentais no meu aprendizado.

iii



Resumo da Relatório apresentado à UFRN como parte dos requisitos necessários paraobtenção do grau de Bacharel em Ciência da Computação.

Especificação e Verificação Formal

do Modelo de Comunicação



Março/2004

Orientador: David Boris Paul DéharbeÁrea de Concentração: Métodos FormaisPalavras-chave: Métodos Formais, NuSMV, Engenharia de Software

Atualmente se encontra em desenvolvimento na UFRN o projeto Automação de Poços, que

visa aperfeiçoar as técnicas de automação de poços que utilizam métodos de elevação.Associado a este projeto, existe um modelo de comunicação que deve funcionar corretamente

para o bom andamento do sistema. Uma proposta atual é o uso de métodos formais emcomponentes críticos de sistemas. Desta forma, o objetivo deste trabalho é avaliar o uso datécnica de especificação formal conhecida como Symbolic Model Checking no contexto doprojeto Automação de Poços.

iv



Report presented to UFRN as a partial fulfillment of the requirements for the degree of Bachelor in Computer Science.

Formal Specification and Checking

of the Model Communication

in the Project Automação de Poços


March/2004

Advisor: David Boris Paul DéharbeArea of Concentration: Formal MethodsKey words: Formal Methods, NuSMV, Software Engineering

Automação de Poços is a project under development at UFRN that intends to improve oil

well automation techniques in wells using elevation methods.

Associated with this project, there is a communication model that must be correct. A currentapproach is to use formal methods in system critical components. So, our work intends to

evaluate the benefits of one formal method technique called Symbolic Model Checking in

the context of the Automação de Poços project.

v



Sumário

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

1 Introdução 1

2 Protocolo de Comunicação Modbus 4

2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Modos de Transmissão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Quadro Framing da Mensagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5 Campo Endereço do Escravo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.6 Campo Função Modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.7 Campo Dados para o Escravo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.7.1 Comandos sem Erro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.7.2 Comandos com Erro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.8 Campo Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.9 Funções Modbus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.10 Temporização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Protocolo de Comunicação Inter-redes 9

3.1 Interface de Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2 Identificação de Requisições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Funções PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.4 O Software de Supervisão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4.1 Funcionamento dos Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4.2 Funcionamento do Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 NuSMV 13

4.1 Lógica Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.1 CTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.2 LTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Modelagem da Comunicação Mestre/Escravo via Modbus Utilizando NuSMV 17

5.1 Módulo main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2 Módulo message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

vi



5.3 Módulo channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.4 Módulo application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.5 Módulo master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.6 Módulo slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.7 Propriedades do Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Modelagem da Comunicação Cliente Servidor Utilizando o PCI 23

6.1 Módulo main . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.2 Módulo message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.3 Módulo channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.4 Módulo buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.5 Módulo application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.6 Módulo server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.7 Módulo serverReader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.8 Módulo serverLocalProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.9 Módulo serverRemoteProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.10 Módulo serverWriter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.11 Módulo serverInternalProcess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.12 Módulo client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.13 Módulo clientSender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.14 Módulo clientReceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.15 Módulo clientVerifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.16 Propriedades do Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7 Conclusão 33

A Implementação da Comunicação Mestre/Escravo 34

A Implementação da Comunicação Cliente/Servidor 38

vii



Lista de Figuras

2.1 Exemplo de um Quadro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Exemplo de um Quadro de Requisição . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Exemplo de um Quadro de Resposta . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Estados das Requisições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1 Exemplo de Programa na Linguagem NuSMV . . . . . . . . . . . . . . . . . . . . . 13

5.1 Modelo Esquemático da Comunicação do Projeto Automação de Poços . . . . . . . 17

5.2 Representação Hierárquica dos Módulos do Sistema . . . . . . . . . . . . . . . . . . 185.3 Implementação do Módulo main . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.4 Implementação do Módulo message . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.5 Implementação do Módulo channel . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.6 Implementação do Módulo application . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.1 Representação Hierárquica dos Módulos do Sistema . . . . . . . . . . . . . . . . . . 24

6.2 Representação Hierárquica do Módulo server . . . . . . . . . . . . . . . . . . . . . 24

6.3 Representação Hierárquica do Módulo client . . . . . . . . . . . . . . . . . . . . . . 24

6.4 Implementação do Módulo main . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.5 Implementação do Módulo message . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.6 Implementação do Módulo channel . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.7 Implementação do Módulo buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.8 Implementação do Módulo application . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.9 Implementação do Módulo server . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.10 Implementação do Módulo serverWriter . . . . . . . . . . . . . . . . . . . . . . . . 29

6.11 Implementação do Módulo client . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.12 Implementação do Módulo clientVerifier . . . . . . . . . . . . . . . . . . . . . . . . 31

A.1 Implementação da Comunicação Mestre/Escravo . . . . . . . . . . . . . . . . . . . 35A.2 Implementação da Comunicação Mestre/Escravo . . . . . . . . . . . . . . . . . . . 36

A.3 Implementação da Comunicação Mestre/Escravo . . . . . . . . . . . . . . . . . . . 37

A.1 Implementação da Comunicação Cliente/Servidor . . . . . . . . . . . . . . . . . . . 39



viii










A.11 Implementação da Comunicação Cliente/Servidor . . . . . . . . . . . . . . . . . . . 49A.12 Implementação da Comunicação Cliente/Servidor . . . . . . . . . . . . . . . . . . . 50

ix



Lista de Tabelas

x



Capítulo 1

Introdução

O Departamento de Engenharia de Computação e Automação da UFRN tem participado de vários

projetos ligados à automação na área de petróleo, dentro os quais encontra-se o projeto Automação

de Poços, que possui como objetivo aperfeiçoar as técnicas de automação de poços que utilizam

métodos de elevação, particularmente no que diz respeito ao monitoramento [Mai03].

A idéia do projeto é que um operador localizado em Natal possa verificar o que está acontecendo

com um poço instalado em outro lugar, como a zona rural de Mossoró por exemplo, podendo até

parar ou partir o poço [Mai03].

Visto que nem todos os poços possuem o mesmo equipamento de monitoramento e estes equipa-

mentos possuem diferentes interfaces, é interessante utilizar um mediador , que possa oferecer uma

camada uniforme de comunicação com os equipamentos atrelados a cada poço.

Dessa forma o modelo de comunicação do projeto Automação de Poços pode ser dividido em

duas partes:

• Na primeira parte, acontece uma comunicação no estilo cliente/servidor, onde o cliente é, por

exemplo, a máquina de um operador do sistema, situada em Natal, que deseja saber algum dadosobre um poço que está localizado num campo na zona rural de Mossoró, e o servidor seria o

computador que está supervisionando os vários controladores daquele campo na zona rural de

Mossoró e que oferece uma camada uniforme de comunicação com os diferentes controladores.

• Na segunda parte, ocorre uma comunicação mestre/escravo, onde o mestre é o computador que

está supervisionando os poços, e que faz o papel de servidor na primeira parte da comunicação;

e o escravo é um equipamento controlador atrelado ao poço do qual desejamos saber alguma

informação. O mestre então traduz a requisição que recebeu do cliente na primeira parte da

comunicação para que possa se comunicar adequadamente com o equipamento controlador em

questão.

Podemos associar a cada parte do modelo de comunicação um tipo de rede distinto, onde a

primeira parte caracteriza-se como uma rede local de supervisão e a segunda como uma rede de

campo.

Na rede de campo, onde ocorre a comunicação mestre/escravo, o protocolo de comunicação uti-

lizado é o Modbus, o qual é bastante conhecido na indústria e será melhor descrito mais adiante. Já



ap u o . n ro uç o

na rede local de supervisão, onde ocorre comunicação cliente/servidor e o servidor tem a função de

interconectar as duas redes, faremos uso do Protocolo de Comunicação Inter-redes (PCI), o qual

oferece uma interface de comunicação capaz de integrar as duas redes e estabelece um padrão que

pode ser utilizado em qualquer rede de comunicação de sistemas supervisórios para processos físicos

industriais [dS04].

Este modelo de comunicação precisa funcionar corretamente para o bom andamento do sistema,

visto que falhas no processo de comunicação podem comprometer o bom supervisionamento dos

poços que estão localizados remotamente. Dessa forma, o processo de comunicação constitui-se deuma parte crítica da aplicação.

Uma proposta que ganhou força nos últimos anos é a aplicação de técnicas de especificação e

verificação formal na modelagem de sistemas críticos, podendo ser modelado o sistema como um

todo ou apenas as partes consideradas mais críticas do sistema.

Com o uso de técnicas de especificação formal podemos modelar, com o auxílio de alguma no-

tação matemática, várias propriedades importantes do sistema, e utilizando técnicas de verificação

formal podemos mostrar que estas propriedades vão ser respeitadas ao longo do tempo, evitando as-

sim possíveis falhas que poderiam passar despercebidas se usássesmos outras técnicas de engenharia

de software mais tradicionais.

O presente trabalho pretende avaliar o potencial da técnica de especificação formal conhecida

como Simbolic Model Checking, tendo como caso de estudo o sistema de comunicação do projeto

automação de poços.

Iremos modelar formalmente o sistema em duas etapas:

• Na primeira etapa, será feito um modelo da comunicação mestre/escravo;

• Na segunda etapa, iremos trabalhar no modelo cliente/servidor, tentando posteriormente re-

alizar a integração destes dois modelos.

Com a integração destes dois modelos, teremos então uma especificação formal completa donosso sistema.

Os capítulos seguintes deste texto encontram-se organizados da seguinte forma:

• O capítulo 2 trata do protocolo de comunicação Modbus [Alf00, MOD02, MOD96], utilizado

no projeto Automação de Poços.

• O capítulo 3 aborda o protocolo de comunicação inter-redes, explicando melhor o seu funciona-

mento;

• O capítulo 4 fala sobre NuSVM [ITC02, CCGR99], uma ferramenta de apoio à especificação

formal, que permite a verificação e a simulação de modelos formais.

• O capítulo 5 apresenta uma modelagem da parte do modelo de comunicação onde ocorre a

comunicação mestre escravo através do protocolo Modbus.

• O capítulo 6 apresenta uma modelagem da parte do modelo de comunicação onde ocorre a

comunicação cliente/servidor e é utilizado o protocolo de comunicação inter-redes.



ap u o . n ro uç o

• O capítulo 7 apresenta algumas conclusões e também faz uma análise dos resultados obtidos

com a modelagem formal do sistema.



Capítulo 2

Protocolo de Comunicação Modbus

2.1 Introdução

Modbus é um protocolo de transferência de mensagens da camada de aplicação, localizado no nível

7 do modelo de referência OSI, que provê comunicação no modo mestre/escravo entre dispositivos

conectados em diferentes tipos de redes e barramentos. Modbus é um protocolo do tipo requi-

sição/resposta e oferece serviços especificados por códigos de funções. É definida uma estrutura de

mensagens composta por bytes, a qual os dispositivos são capazes de reconhecer, independentemente

do tipo de rede utilizada.

Durante o processo de comunicação, o Modbus determina como cada dispositivo:

• identifica seu próprio endereço na rede;

• reconhece se uma mensagem é endereçada a ele;

• determina qual o tipo de ação a ser executada;

• obtém as informações necessárias para a execução da ação.

No caso de ser necessário devolver uma resposta ao comando recebido, o dispositivo elabora uma

mensagem e a envia, ou indica que ocorreu um erro no processo de comunicação.

2.2 Comunicação

Na comunicação mestre/escravo, um equipamente assume o papel de mestre, enquanto os demais se

comportam como escravos. Cabe ao mestre tomar a iniciativa do processo de comunicação, ficando

o escravo encarregado de responder às solicitações enviadas pelo mestre.

Quando se dá a comunicação entre o mestre e o escravo, há duas situações que podem ocorrer:

• O mestre deseja enviar/receber dados para/do escravo;

• O escravo deseja enviar/receber dados para/do mestre.

Na primeira situação, o mestre, como tem a possibilidade de iniciar a comunicação, pode enviar

quando desejar uma mensagem requisitando ao escravo a realização de uma função. O escravo, ao



ap u o . ro oco o e omun caç o o us

receber a mensagem enviada pelo mestre, executa a função e envia uma resposta ao mestre contendo

o resultado da função em questão. Este processo de comunicação é chamado de Select.

Já no segundo caso, visto que o escravo não pode iniciar um processo de comunicação, ele deve

esperar o mestre perguntar se ele deseja enviar/receber alguma mensagem, para só então enviar a sua

mensagem ao mestre. Este processo de comunicação recebe o nome de Pooling.

No Modbus, o mestre pode endereçar os escravos individualmente ou endereçar todos os escravos

da rede enviando mensagens em broadcast . Somente o escravo endereçado retorna uma resposta a

um pedido do mestre, sendo que mensagens enviadas em broadcast nunca são respondidas.No formato estabelecido pelo Modbus para as mensagens de pedido, são definidos:

• o endereço do escravo (ou código em caso de acesso broadcast );

• a função solicitada, com eventuais parâmetros;

• o campo de checksum, para verificar a integridade da mensagem.

De maneira similar, é gerada a resposta do escravo correspondente à função solicitada pelo mestre,

onde se define:

• a confirmação da função realizada;

• resultado da função realizada;

• o campo de checksum, para verificar a integridade da mensagem.

Se ocorrer um erro na comunicação, ou se o escravo não estiver apto a realizar a função solicitada

pelo mestre, ele monta uma mensagem específica, exception, justificando o seu não atendimento.

2.3 Modos de Transmissão

No protocolo Modbus são definidos dois modos de transmissão: o ASCII e o RTU. Todos os dispos-

itivos da rede devem estar em um mesmo modo de transmissão. O modo de transmissão basicamente

define como se dará o empacotamento dos dados na mensagem. Com o modo de transmissão definido,

deve-se definir então seu parâmetros de comunicação.

Modo ASCII: Ao se configurar o dispositivo nesse modo, para cada palavra de dados da mensagem

são enviados dois caracteres no padrão ASCII. A principal vantagem do modo ASCII é a

possibilidade de haver intervalos grandes entre o envio dos dados de uma mesma mensagem.

Modo RTU: Neste modo, para cada palavra de dados da mensagem é enviado apenas um caracterno padrão hexadecimal. A principal vantagem do modo RTU em relação ao ASCII é a maior

densidade de caracteres que é enviada numa mesma mensagem, aumentando o desempenho da

comunicação.




Início de Endereço Função Dados para Checksum Fim deQuadro do Escravo Modbus o Escravo Quadro

Figura 2.1: Exemplo de um Quadro

2.4 Quadro Framing da Mensagem

Durante o processo de transmissão de uma mensagem Modbus há identificadores que delimitam o

início e o fim de quadro, de acordo com cada modo de transmissão. Desta forma, os dispositivos da

rede são capazes de perceber o início da mensagem e ler todos os dados contidos nela até o seu final.

Na figura 2.1, podemos ver o exemplo de um quadro típico.

2.5 Campo Endereço do Escravo

A faixa de endereços válidos para os escravos é de 0 a 247, sendo o 0 reservado para acesso tipo

broadcast e os demais endereços realizando acesso individual sobre os escravos. Todo escravo con-

hece 2 endereços: o dele mesmo e o de broadcast .

2.6 Campo Função Modbus

A faixa de valores válidos para este campo varia de 1 a 255.

Quando um escravo recebe uma mensagem, este campo indica qual ação deve ser tomada por

ele, como por exemplo: ler e/ou programar um ou mais sensores, ler e/ou programar um ou mais

registradores, ler o estado do escravo etc.

Na resposta do escravo ao mestre, este campo é utilizado para informar este último se a ação foi

executada com sucesso ou se ocorreu algum tipo de erro (exception).

O mestre fica responsável por gerenciar e analisar mensagens de exception, reenviando a men-

sagem que originou o erro ou enviando uma função de diagnóstico para identificar melhor a causa do

erro.

2.7 Campo Dados para o Escravo

2.7.1 Comandos sem Erro

Nas mensagens do mestre para os escravos, as informações contidas neste campo estão relacionadas

ao tipo da função definida no campo função modbus, como por exemplo quantos sensores ou da-

dos devem ser lidos ou escritos, os dados a serem programados em determinados registradores, que

também são definidos neste campo, e a quantidade de bytes que estão sendo enviados na mensagem.

Nas mensagens dos escravos para o mestre, se não ocorrer erro na realização do comando, este

campo conterá as informações relativas ao comando enviado, caso contrário conterá um código de




exception, identificando o que ocasionou o erro e orientando o mestre na execução do próximo co-

mando.

2.7.2 Comandos com Erro

Quando envia uma mensagem para um escravo, o mestre aguarda uma resposta normal porém, pode

ocorrer algum erro durante o processo. Dependendo do tipo do erro o escravo responde ao mestre

com uma mensagem de exception ou nenhuma mensage é envidada para o mestre.

2.8 Campo Checksum

Há dois tipos de cálculo para verificar a integridade (checksum) de dados usados pelo protocolo Mod-

bus: verificação de paridade, que pode ou não ser aplicada para cada caractere da mensagem, e ver-

ificação do quadro, que pode ser do tipo LRC — aplicado a todos os campos de uma mensagem no

modo ASCII , ou do tipo CRC — aplicado ao conteúdo de toda a mensagem no modo RTU.

2.9 Funções Modbus

No projeto Automação de Poços, são utilizadas apenas algumas funções do Modubs. As funções

Modbus de nosso interesse, ou seja, aquelas utilizadas no projeto Automação de Poços, são descritas

a seguir. Lembrando apenas que registradores do tipo holding são aqueles que podem tanto ser aces-

sados para leitura como para escrita.

Leitura de Bloco de Registradores — Função 03: Esta função lê o conteúdo de um bloco de reg-

istradores tipo holding. Este comando não aceita acessos do tipo broadcast . A mensagem

enviada especifica o registrador inicial e a quantidade de registradores a serem lidos.

Escrita em Bloco de Registradores — Função 16: Esta função programa umbloco de registradorestipo holding sequencialmente. Para acessos tipo broadcast , este mesmo bloco de registradores

de todos os escravos da rede serão programados igualmente. A mensagem enviada pelo mestre

ao escravo especifica o bloco de registradores a ser programado. Caso o comando seja real-

izado com sucesso, a mensagem de resposta contém apenas o endereço do escravo, o código da

função Modbus, o endereço inicial do bloco de registradores e a quantidade de registradores

programados.

2.10 Temporização

Todo mestre é configurado para esperar por intervalo de tempo pré-determinado antes de abortar a

comunicação, sendo este intervalo chamado de time-out . Este time-out deve ser programado para

ser longo o bastante para dar tempo ao escravo de responder às requisições enviadas pelo mestre de

maneira normal.

Se o escravo detectar um erro de transmissão, a mensagem não será validada e também não será

enviada nenhuma resposta para o mestre, dessa forma, o time-out será atingido, o que permitirá ao




mestre gerenciar a ocorrência do erro. Devemos notar que uma mensagem endereçada a um dispos-

itivo escravo que não está presente na rede, encontra-se danificado, por exemplo, também acarretará

num time-out .



Capítulo 3

Protocolo de Comunicação Inter-redes

Neste protocolo, o envio ou a solicitação de informações sempre deve começar por uma requisição,

que será processada pelo servidor, que é a estação que interliga a rede de campo e a rede local de

supervisão.

Ao receber uma requisição, o servidor deve enviar uma resposta intermediária (RI) ao solicitante

da requisição indicando se processará ou não aquela requisição, ou seja, o servidor deve enviar uma

mensagem de acknowledge ou de not acknowledge. Caso decida processar a requisição do cliente,

posteriormente o servidor deverá mandar uma resposta definitiva (RD) ao mesmo, indicando o resul-

tado do processamento da requisição.

Associada a cada tipo de requisição existe um tempo de espera máximo que deve ser respeitado.

Para as respostas intermediárias (RIs) este tempo é de 200ms e de 5s para as respostas definitivas

(RDs).

3.1 Interface de Comunicação

O tipo de quadro utilizado no envio de requisições pode ser visto na figura 3.1, onde cada um doscampos possui o seguinte significado:

• ID: representa o identificador único para cada requisição enviada. Este campo possui um

tamanho de 4 bytes.

• Função: indica a função lógica que deve ser executada pelo servidor. O tamanho deste campo

é de 4 bytes.

• Estação: informa a estação da rede de campo que deve ser acessada. Possui um tamanho de 4

bytes.

• Dados: transmite os eventuais parâmetros que serão utilizados pelo servidor na execução da

função solicitada. Este campo não possui um tamanho fixo.

No envio de respostas, o modelo de quadro utilizado está representado na figura 3.2. Os campos

deste quadro possuem significado similar aos do quadro de requisição, sendo que o campo Dados

contém agora o resultado da função executada pelo servidor.



ap u o . ro oco o e omun caç o n er-re es

ID (4 bytes) Função (4 bytes) Estação (4 bytes) Dados (n bytes)

Figura 3.1: Exemplo de um Quadro de Requisição

ID (4 bytes) Função (4 bytes) Dados (n bytes)

Figura 3.2: Exemplo de um Quadro de Resposta

3.2 Identificação de Requisições

O campo ID representa o identificador único de cada requisição. Sempre que a requisição for gerada

por uma estação cliente, o valor deste campo será positivo, e quando chegar uma resposta para a req-

uisição enviada, confronta-se o ID da mensagem recebida com o da mensagem enviada para verificar

se é o mesmo e se ele deve aceitar aquela resposta. No caso de requisições geradas pelo servidor,

o valor deste campo é negativo. Neste caso, quando chegar uma resposta para o cliente com um ID

negativo ele sabe que aquela requisição foi gerada pelo servidor e pode aceitar a resposta.

3.3 Funções PCI

As funções lógicas PCI representam a essência da requisição, pois definem que tipo de informação

está sendo solicitada ou enviada, e podem ser classificadas, de acordo com a finalidade, em:

• funções de controle;

• funções utilitárias.

As funções de controle são aquelas usadas no gerenciamento da troca de dados e são geradas

exclusivamente pelo servidor.

Quando o servidor recebe uma requisição, ele deve mandar uma RI para a origem da requisição.

Neste caso, o campo Função da RI deve conter o código PCI_ACK caso o servidor for processar a

requisição, ou PCI_NACK se o processamento da requisição não for possível. Existem também outros

códigos para este campo, como PCI_ERROR e PCI_WARN .

As funções utilitárias representam os serviços oferecidos pelo servidor e são utilizadas pelos

clientes. No uso destas funções os clientes devem enviar uma requisição contendo o código da função

e receber uma RI e uma RD correspondentes à requisição que as originou. Assim, as funções util-itárias devem ser enviadas através de requisições externas.

Podemos dividir as funções lógicas PCI de acordo com a forma de execução no servidor como:

• locais;

• remotas.




Estado Descrição

PCI_WAIT_RI Aguardando réplica intermediária ( ACK ou NACK )PCI_WAIT_RD Aguardando resposta definitiva

Figura 3.3: Estados das Requisições

As locais são executadas no servidor, enquanto que as remotas exigem a comunicação com a redede campo para a sua execução. Neste caso, será necessário acessar uma estação da rede campo, que

são identificadas por um número inteiro positivo, onde o endereço zero significa o acesso a todas as

estações da rede de campo.

3.4 O Software de Supervisão

A arquitetura proposta para o sistema de supervisão sugere um modelo para implementação de soft-

ware capaz de acessar os dados do processo físico, remotamente, utilizando o PCI.

3.4.1 Funcionamento dos Clientes

A aplicação cliente deve ser capaz de enviar requisições ao servidor e tratar as respostas enviadas

por ele. Assim, sugere-se a utilização de três processos paralelos. O primeiro, denominado processo

transmissor, deve aguardar solicitações dos usuários do software, gerar uma requisição para esta so-

licitação, enviá-la para o cliente e inserir uma cópia da requisição em um buffer de requisições sem

resposta, chamado BC1. O segundo processo, denominado receptor, deve aguardar a chegada de re-

postas, repassar o resultado ao usuário e retirar a sua requisição correspondente de BC1. O terceiro

processo, chamado de processo de verificação, percorre continuamente o buffer BC1, avaliando o

tempo decorrido desde o envio de cada requisição, garantindo a aplicabilidade dos timeouts exigidosno PCI.

As cópias das requisições devem ser armazenadas em BC1 juntamente com o momento do ar-

mazenamento e o estado da requisição. O estado de uma requisição indica se o cliente já recebeu

alguma resposta correspondente. Na figura 3.3 podemos ver os estados possíveis para as requisições

em BC1.

O processo tranmissor é responsável por armazenar as requisições em BC1. Para cada requisição

enviada ao servidor, o processo transmissor deve armazenar em BC1 uma cópia da requisição no seu

estado inicial. O estado inicial de uma requisição deve indicar que nenhuma resposta foi recebida

ainda e, portanto, uma RI é esperada (PCI_WAIT_RI).

O processo receptor é responsável pelo controle interno de recebimento das respostas, modifi-

cando o estado das requisições e retirando-as de BC1. Quando uma RI do tipo PCI_ACK é recebida,

o estado da requisição correspondente deve ser alterado de modo a indicar que uma RD é aguardada

(PCI_WAIT_RD). Caso a RI seja do tipo PCI_NACK , a requisição deve ser eliminada de BC1, pois

indica que o servidor não será capaz de processá-la, e o usuário deve ser notificado. No recebido

de um RD, o resultado deve ser repassado ao usuário e a sua requisição correspondente deve ser




eliminada de BC1. O recebimento de uma RD para uma requisição no estado PCI_WAIT_RI viola o

protocolo de comunicação e, portanto, a resposta deve ser descartada. O mesmo deve acontecer no

recebimento de uma RI para uma requisição no estado PCI_WAIT_RD. A busca por uma requisição

correspondente às respostas deve ser feita comparando-se o campo ID dos quadros PCI. A inexistên-

cia de uma requisição em BC1 correspondente a uma resposta recebida com um ID positivo deve fazer

com que o cliente despreze tal resposta. As respostas com ID negativo devem ser processadas sem a

busca por uma requisição correspondente, pois são originadas de requisições internas do servidor que

podem indicar a ocorrência de aviso ou alarmes.O processo de verificação deve percorrer BC1 a cada 10 ms e avaliar o tempo decorrido desde a

chegada de cada requisição no buffer . Se a requisição estiver esperando uma RI ou RD e tiver ocorrido

um timeout , o usuário deve ser notificado disto.

3.4.2 Funcionamento do Servidor

A aplicação do servidor precisa armazenar, processar e responder às requisições que têm origem no

cliente ou no próprio servidor. A separação das funções em locais e remotas dá-se pelo fato de que a

velocidade de processamento das funções locais é bem maior do que das funções remotas, que sofrem

com a baixa velocidade de transmissão de dados entre o mestre e os escravos. Desta forma, tratandoestas funções de forma diferente, evitamos que a lentidão na execução de funções remotas prejudique

o tempo de resposta das requisições que possuem funções locais.

Para realizar suas funções, o servidor utiliza cinco processos distintos e paralelos. O primeiro,

denominado de leitor, recebe as requisições, envia as RIs para os seus emissores e armazena as requi-

sições. Se a requisição contém alguma função local, ela é armazenada em um buffer de requisições,

denominado de BS1. Caso a requisição contenha alguma função remota, ela é armazenada em outro

buffer de requisições, chamado BS2. O segundo processo, chamado de processo local, processa as

requisições em BS1 retirando-as do buffer , executando a função solicitada ao servidor e armazenando

a RD em um buffer de respostas, chamado de BS3. O terceiro processo, chamado de processo remoto,processa as requisições em BS2 retirando-as do buffer, comunicando-se com alguma estação da rede

de campo e armazenando a RD em BS3. O quarto processo, denominado processo escritor, retira as

RDs de BS3 e as envia aos clientes. O quinto processo, chamado de processo interno, é utilizado para

gerar as requisições internas. Portanto, pode ser utilizado na geração de alarmes e avisos.

Novamente, a criação de buffers distintos para as funções locais e remotas deve-se ao fato de que

o processamento das funções locais é mais rápido, e tratar estas funções da mesma forma introduziria

um atraso desnecessário no tempo de resposta a requisições processadas rapidamente.



Capítulo 4

NuSMV

NuSMV é um verificador de modelos simbólicos, de código aberto, originado a partir de SMV [McM92],

o verificador de modelos baseado em BDD desenvolvido na Carnegie Mellon University [McM93].

NuSMV foi projetado para ser robusto, atender aos padrões requeridos pela indústria e ser fácil de

manter e modificar, sendo escrito em ANSI C e tendo seu código fonte dividido em vários módulos.

A linguagem de entrada de NuSMV permite a descrição de Máquinas de Estado Finitas (MEFs),

sendo capaz de descrever processos síncronos e assíncronos bem como condições de não determin-

ismo.

O propósito inicial da entrada de NuSMV é descrever as relações de transição das MEFs, onde

estas relações descrevem as evoluções válidas do estado das MEFs e, conseqüentemente, do sistema

sendo modelado, dessa forma, podemos identificar as possíveis configurações futuras de um sistema

a partir do seu estado atual.

De um modo geral, qualquer expressão no cálculo proposicional pode ser usada para definir as re-

lações de transição, o que provê uma grande flexibilidade e ao mesmo tempo requer um certo cuidado

adicional para evitar inconsistências, como por exemplo a presença de uma contradição lógica, que

pode resultar em um deadlock .Na figura 4.1, ilustramos um simples programa na linguagem NuSMV.

O espaço de estados das MEFs é determinado pela declaração das variáveis de estado, que no

MODULE main

VAR

request : boolean;

state : {ready, busy};

ASSIGN

init(state) := ready;

next(state) :=

case

state = ready & request = 1 : busy;

1 : {ready, busy};

esac;

Figura 4.1: Exemplo de Programa na Linguagem NuSMV



ap u o . u

exemplo acima são request e state. A variável request é declarada como sendo do tipo pré-definido

boolean. Isto significa que ele pode assumir os valores inteiros 0 e 1. A variável state é uma variável

escalar, que pode tomar os valores simbólicos ready e busy. A operação seguinte atribui ready como

o valor inicial da variável state. Já o valor inicial de request não é especificado, ou seja, ele pode ser

ou 0 ou 1.

A relação de transição das MEFs é representada através da definição do valor das variáveis na

próximo estado (i.e. depois de cada transição), dado o valor das variáveis no estado atual (i.e. antes

da transição).O segmento case atribui o próximo valor da variável state para o valor busy se o seu valor atual é

ready e request é 1 (verdadeiro). Caso contrário (o 1 antes do dois pontos), o próximo valor para state

pode ser qualquer um no conjunto {ready,busy}. A variável request não é atribuída, isto significa

que não há restrições quanto ao seu valor, e portanto ela pode assumir qualquer valor. request é então

considerada uma entrada irrestrita (unconstrained ) para o sistema.

NuSMV também possui algumas características interessantes, como a possibilidade de reutilizar

módulos definidos anteriormente.

Pretendemos então utilizar NuSMV para modelar o sistema de comunicação utilizado no projeto

de Automação de Poços, e iremos testar a corretude do modelo especificado utilizando funcionali-

dades de NuSMV como a simulação e a verificação de modelos.

4.1 Lógica Temporal

O principal objetivo de um verificador de modelos é verificar que um modelo satisfaz um conjunto de

propriedades desejadas especificadas pelo usuário. Em NuSMV, as propriedades podem ser definidas

utilizando-se duas lógicas temporais diferentes: Lógica de Árvore de Computação, ou Computation

Tree Logic (CTL); e Lógica Temporal Linear, ou Linear Temporal Logic (LTL). Especificações CTL

e LTL são avaliadas por NuSMV visando determinar a sua verdade ou falsidade na MEFs. A seguir,

falaremos um pouco sobre especificações em NuSMV utilizando CTL e LTL.

4.1.1 CTL

Utilizando CTL nós podemos descrever a evolução de uma MEFs como uma árvore infinita, onde os

nós são os estados da MEFs e as arestas correspondem às transições entre estados. A estrutura de

árvore deve-se ao não-determinismo possível nas definições das transições. Os caminhos na árvore

que iniciam em um dado estado são as possíveis evoluções da MEFs a partir daquele estado. Em CTL

é possível expressar propriedades que devem ser satisfeitas para todos os caminhos iniciando num

estado, bem como propriedades que devem ser satisfeitas apenas para algum dos caminhos.

Considere a fórmula AF p, que expressa a condição que para todos os caminhos (A) iniciando num

estado, em algum momento no futuro (F), a condição p deve ser satisfeita. Isto é, todas as evoluções

possíveis do sistema futuramente alcançarão um estado satisfazendo a condição p. Já a fórmula CTL

EF p, requer que exista algum caminho (E) que em algum estado futuro satisfaz p.

Analogamente, a fórmula AG p requer que a condição p é sempre, ou globalmente, verdadeira

em todos os estados de todos os possíveis caminhos, enquanto a fórmula EG p requer que exista



ap u o . u

alguma caminho ao longo do qual a condição p é continuamente verdadeira.

Operadores CTL podem ser aninhados de modo arbitrário e podem ser combinados usando oper-

adores lógicos (!, &, |, ->, <->, ...). Exemplos típicos de fórmulas CTL são:

• AG !p

A condição p está ausente em todas as evoluções.

• AG EF p

É sempre possível alcançar um estado onde a condição p é satisfeita.

• AG (p -> AF q)

Cada ocorrência da condição p é seguida por uma ocorrência da condição q.

• A [ p U q ] e E [ p U q ] A condição p será verdadeira até que seja alcançado um estado

onde a condição q é verdadeira

• AX p e EX p

A condição p é verdadeira em todos ou em alguns dos próximos estados que podem ser al-

cançados a partir do estado atual

Em NuSMV uma especificação CTL é dada como uma fórmula CTL introduzida pela palavra

chave SPEC. Se uma especificação CTL é processada, NuSMV verifica se a fórmula é verdadeira em

todos os estados iniciais do modelo. Se este não é o caso, então NuSMV gera um contra-exemplo, ou

seja, uma trilha de execução (finita ou infinita) que exibe um comportamento válido do modelo que

não satisfaz a especificação. Trilhas de execução são muito úteis para identificar erros no programa

(ou na especificação) que levam ao comportamento errado.

Também é possível em NuSMV, restringir a atenção a algumas trilhas de execução, chamadas de

trilhas de execução justa, colocando-se uma restrição de justiça. Assim, ao avaliar as expressões, o

verificador de modelos considera que os quantificadores de caminho são aplicados somente às trilhasde execução justa.

Uma declaração de justiça consiste de uma fórmula f que é assumida ser freqüentemente ver-

dadeira em todos os caminhos justos. Um caminho será considerado justo então se e somente se ele

satisfaz a todas as declarações de justiça.

4.1.2 LTL

Enquanto especificações CTL expressam propriedades sobre a árvore de computação das MEFs (abor-

dagem de ramificação com o tempo), LTL caracteriza cada caminho linear induzido pelas MEFs

(abordagem linear com o tempo). As duas lógicas possuem em geral um poder expressivo diferente,mas também possuem vários pontos em comum, os quais incluem a maioria das propriedades usadas

na prática. Operadores CTL típicos são:

• F p

Em algum instante de tempo no futuro a condição p será satisfeita



ap u o . u

• G p

A condição p é satisfeita em todos os intantes de tempo no futuro

• p U q

A condição p é satisfeita até que seja alcançado um estado onde a condição q é satisfeita

• X p

A condição p é verdadeira no próximo estado

Devemos lembrar que, diferentemente de CTL, os operadores temporais de LTL não possuem

quantificadores de caminho. De fato, fórmulas LTL são avaliadas sobre caminhos lineares, e uma

fórmula é considerada verdadeira em um modelo se ela é verdadeira para todos os caminhos iniciando

num dos estados iniciais daquele modelo.



Capítulo 5

Modelagem da Comunicação

Mestre/Escravo via Modbus Utilizando

NuSMV

Como descrito anteriormente, o modelo de comunicação do projeto Automação do Poços pode serdividido em duas partes: uma parte cliente/servidor e uma parte mestre/escravo, que utiliza o proto-

colo de comunicação Modbus. Um modelo esquemático da comunicação do sistema pode ser visto

na figura 5.1.

Tomando como base o modelo de comunicação descrito, foi proposta uma primeira modelagem

utilizando NuSMV para a segunda parte da comunicação, onde ocorre o modelo mestre/escravo e é

utilizado o protocolo de comunicação Modbus. Para realizar esta primeira modelagem, foram feitas

algumas abstrações tais como: o não tratamento do conteúdo das mensagens; e a falta de temporiza-

ção, visto que NuSMV não oferece recursos para a simulação de tempo, sendo necessário programar-

se a simulação do tempo explicitamente.

No modelo proposto, existem 6 módulos: main, message, channel, application, master e slave.

A figura 5.2 nos mostra uma representação hierárquica dos módulos do sistema, os quais irão ser

detalhados a seguir.

Operador

Cliente−Servidor

Equipamento Supervisorio

Mestre−Escravo

Bombeio Mecanico comEquipamento Controlador

Figura 5.1: Modelo Esquemático da Comunicação do Projeto Automação de Poços



ap u o . o e agem a omun caç o es re scravo v a o us zan o u

slave master

application

main

message

channel

Figura 5.2: Representação Hierárquica dos Módulos do Sistema

MODULE main

VAR

app : application;

Figura 5.3: Implementação do Módulo main

5.1 Módulo main

Módulo bastante simples, possui apenas uma instância do módulo application, como pode ser visto

na figura 5.3.

5.2 Módulo message

Representa as mensagens que são trocadas entre os escravos e o mestre, sendo composto pelas

seguintes variáveis:

• slaveAddress: representa o endereço do escravo com o qual o mestre deseja se comunicar. Ovalor zero indica que a mensagem será enviada para todos os escravos;

• functionCode: indica a função a ser executada pelo terminal escravo.

A figura 5.4 nos mostra a implementação deste módulo.

5.3 Módulo channel

Neste módulo, cuja implementação pode ser vista na figura 5.5, estão representadas as propriedades

do canal de comunicação utilizado pelos escravos e pelo mestre. O módulo channel é composto pelasseguintes variáveis:

• messageForMaster: indica que há uma mensagem para o mestre no canal;

• messageForSlave: indica que há uma mensagem para o escravo no canal;

• msg: a mensagem que trafega pelo canal.

Inicialmente não existem mensagens nem para o mestre nem para os escravos.




MODULE message

VAR

slaveAddress : 0..3;

functionCode : 1..4;

ASSIGN

init(slaveAddress) := 0;

init(functionCode) := 1;

Figura 5.4: Implementação do Módulo message

MODULE channel

VAR

messageForMaster : boolean;

messageForSlave : boolean;

msg : message;

ASSIGN

init(messageForMaster) := FALSE;

init(messageForSlave) := FALSE;

Figura 5.5: Implementação do Módulo channel

5.4 Módulo application

Este módulo possui uma instância do módulo channel, uma instância do módulo master e várias

instâncias do módulo slave. A instância do módulo channel é passada como parâmetro para as in-

stâncias dos outros módulos. Também é passado como parâmetro para os escravos o número do seu ID. A figura 5.6 nos mostra a implementação deste módulo.

5.5 Módulo master

O módulo master modela o comportamento do mestre, que possui 6 estados diferentes:

• idle: o mestre está ocioso e decide se deseja mandar ou não uma mensagem;

• packing: o mestre está empacotando a mensagem que deseja enviar;

• sending: aqui o mestre está enviando a mensagem para o canal de comunicação;

• waiting: este estado denota que o mestre está esperando uma resposta de um dos terminais

escravos;

• receiving: o mestre está recebendo uma mensagem;

• processing: o mestre está processando a mensagem recebida.




MODULE application

VAR

c : channel;

m1 : master(c);

s1 : slave(c, 1);

s2 : slave(c, 2);

s3 : slave(c, 3);

ASSIGN

next(c.messageForMaster) :=

case

m1.stateMaster = processing : {FALSE};

m1.currentSlave = 0 : {FALSE};

m1.currentSlave = 1 & s1.stateSlave = idle : {FALSE};

m1.currentSlave = 1 & s1.stateSlave = receiving : {FALSE};

m1.currentSlave = 1 & s1.stateSlave = processing : {FALSE};

m1.currentSlave = 1 & s1.stateSlave = sending : {TRUE};



m1.currentSlave = 2 & s2.stateSlave = processing : {FALSE};m1.currentSlave = 2 & s2.stateSlave = sending : {TRUE};



m1.currentSlave = 3 & s3.stateSlave = processing : {FALSE};

m1.currentSlave = 3 & s3.stateSlave = sending : {TRUE};

1 : c.messageForMaster;

esac;

Figura 5.6: Implementação do Módulo application




No início, o mestre encontra-se no estado idle.

Além disto, o módulo master possui o seguinte conjunto de variáveis:

• msgMaster: indica que o mestre deseja enviar uma mensagem;

• currentSlave: indica o escravo para o qual a mensagem deve ser enviada;

• timeout: indica se ocorreu timeout na espera por uma mensagem de resposta.

5.6 Módulo slave

O módulo slave, analogamente, modela o comportamento do escravo, que possui 4 estados diferentes

os quais são descritos a seguir:

• idle: neste estado o escravo verifica se há alguma mensagem no canal enderaçada a ele;

• receiving: o escravo está recebendo uma mensagem do canal;

• processing: aqui o escravo está processando a mensagem recebida;

• sending: o escravo está enviando uma mensagem para o mestre através do canal de comuni-cação.

O estado inicial de todos os escravos é idle.

O módulo slave também possui as seguintes variáveis:

• idSlave: identificador do escravo;

• msgSlave: indica se o escravo recebeu a mensagem do canal;

• res: indica se o escravo efetuou o processamento e gerou uma resposta;

• currentId: indica para qual escravo destinava-se a mensagem que o escravo recebeu do canal.Os dois possíveis valores para esta variável são: idSlave e zero.

5.7 Propriedades do Modelo

Após a construção do modelo, passamos a tentar verificar uma série de propriedades a respeito do

mesmo, tendo obtido grande sucesso nesta etapa, podendo extrair, dentre outras, as seguintes pro-

priedades usando CTL:

• Quando o mestre está ocioso e deseja enviar uma mensagem, ele sempre consegue fazê-lo;• Após receber uma mensagem, o mestre sempre a processa e fica ocioso;

• Quando o mestre está esperando por uma resposta do escravo e ocorre um timeout , o mestre

sempre vai para o estado ocioso na próxima transição;

• Se o mestre está esperando uma resposta e não ocorre timeout , ele continuará esperando até

começar a receber a resposta ou até que ocorra um timeout ;




• Sempre que há uma mensagem para o escravo no canal, o escravo a recebe;

• Quando a mensagem é endereçada especificamente àquele escravo, o escravo sempre responde

ao mestre;

• O escravo somente recebe mensagens que são endereçadas a ele ou que são enviadas em broad-

cast ;

• Sempre que o mestre manda mensagens para um escravo o escravo recebe a mensagem enviada;

• Sempre que o escravo responde e não ocorre timeout o mestre recebe a resposta enviada pelo

escravo;

• Sempre que o mestre está esperando e o escravo recebe a mensagem que o mestre enviou,

ocorrerá timeout ou o mestre receberá a resposta do escravo.



Capítulo 6

Modelagem da Comunicação Cliente

Servidor Utilizando o PCI

O segundo modelo formal, visa representar a comunicação entre os clientes e o servidor utilizando

o PCI. Para este propósito, definimos 15 módulos NuSMV para representar o sistema. Uma repre-

sentação hierárquica dos módulos do sistema pode ser vista nas figura 6.1, enquanto a figura 6.2 nos

mostra a composição mais detalhada do módulo server e a figura 6.3 representa o módulo client em

detalhes.

Na representação formal do sistema, tentou-se seguir as diretrizes de implementação do software

cliente e do software servidor que foram descritas no capítulo sobre o PCI.

Iremos agora descrever cada um dos módulos, explicando o seu funcionamento.

6.1 Módulo main

Este módulo é bastante simples, ele apenas contém uma instância do módulo application. A figura 6.4

nos mostra a implementação deste módulo.

6.2 Módulo message

Representa as mensagens que são trocadas entre os clientes e o servidor, sendo composto pelas

seguintes variáveis:

• idClient: representa o identificador do cliente com o qual aquela mensagem está relacionada.

Este campo pode receber os valores 1 e 2, visto que estamos supondo a existência de dois

clientes;

• idMessage: significa o identificar único daquela mensagem, visto que nosso buffer possui duas

posições, esta variável pode assumir o valor negativo de −1 e dois valores positivos;

• idFunction: representa a função solicitada.

A figura 6.5 nos mostra a implementação do módulo message.



ap u o . o e agem a omun caç o en e erv or zan o o

channel

main

application

serverclient

message

buffer

Figura 6.1: Representação Hierárquica dos Módulos do Sistema

server

serverReader

serverLocalProcess serverRemoteProcess

serverWriter serverInternalProcess

Figura 6.2: Representação Hierárquica do Módulo server

client

clientSender clientReceiver clientVerifier

Figura 6.3: Representação Hierárquica do Módulo client

MODULE main

VAR

app : application;

Figura 6.4: Implementação do Módulo main




MODULE message

VAR

idClient: 1..2;

idMessage: -1..1;

idFunction: 1..4;

-1 representa funcao local e 2 funcao remota

-3 representa PCI_NACK e 4 PCI_ACK

Figura 6.5: Implementação do Módulo message

MODULE channel

VAR

messageForClient : boolean;

messageForServer : boolean;

msgClient : message;

msgServer : message;

ASSIGN

init(messageForClient) := FALSE;

init(messageForServer) := FALSE;

Figura 6.6: Implementação do Módulo channel

6.3 Módulo channel

Neste módulo, cuja implementação pode ser vista na figura 6.6 representamos as propriedades do

canal de comunicação utilizado pelos clientes e pelo servidor, que é composto das seguintes variáveis:

• messageForClient: indica que há uma mensagem para o cliente no canal;

• messageForServer: indica que há uma mensagem para o servidor no canal;

• msgClient: a mensagem para o cliente propriamente dita;

• msgServer: a mensagem para o servidor propriamente dita.

No início do processo, não há mensagens nem para o cliente nem para o servidor.

6.4 Módulo buffer

Descreve o buffer de mensagens que tanto os clientes como o servidor possuem. O buffer é compostopelos seguintes campos:

• msgBufferN: esta é uma instância do módulo message, e o módulo buffer possui tantas var-

iáveis deste tipo quantas forem as posições do buffer ;

• statusN :: indica o estado de cada posição do buffer : se está ocupada, esperando resposta

intermediária ou esperando resposta definitiva;




MODULE buffer

VAR

msgBuffer1 : message;

msgBuffer2 : message;

currentSize : 0..2;

status1 : 0..2;

status2 : 0..2;

ASSIGNinit(currentSize) := 0;

init(status1) := 0;

init(status2) := 0;

Figura 6.7: Implementação do Módulo buffer

MODULE application

VAR

c : channel;s : server(c);

c1 : client(c, 1);

c2 : client(c, 2);

Figura 6.8: Implementação do Módulo application

• currentSize: indica o número de posições atualmente ocupadas do buffer .

No início, o tamanho do buffer é zero e todas as posições estão livres. A implementação deste

módulo pode ser vista na figura 6.7.

6.5 Módulo application

Este módulo possui uma instância do módulo channel, uma instância do múdulo server e várias

instâncias do módulo client , como pode ser visto na figura 6.8. Aqui, a instância do módulo channel é

passada como parâmetro para as instâncias dos outros módulos. Também é passado como parâmetro

para os clientes o número do seu ID.

6.6 Módulo server

Representa o servidor e possui três instâncias do módulo buffer : BS1, BS2 e BS3. Também possui

instâncias dos módulos: serverReader , serverLocalProcess , serverRemotreProcess , serverWriter e

serverInternalProcess. A implementação deste módulo pode ser vista na figura 6.9.




MODULE server(c)

VAR

BS1 : buffer;

BS2 : buffer;

BS3 : buffer;

lockBS3 : boolean; -trava para acessar o buffer BS3

reader : process serverReader(c, BS1, BS2);

local : process serverLocalProcess(BS1, BS3, lockBS3);

remote : process serverRemoteProcess(BS2, BS3, lockBS3);writer : process serverWriter(c, BS3);

internal : process serverInternalProcess(c);

ASSIGN

init(lockBS3) := FALSE;

Figura 6.9: Implementação do Módulo server

6.7 Módulo serverReader

Neste módulo representamos o processo leitor do servidor. Ele fica escutando o canal de comunicaçãoe verificando se existe alguma mensagem para o servidor no canal. Quando chega uma mensagem o

servidor deve decidir processá-la ou não e mandar uma RI para o cliente que enviou a mensagem. Os

parâmetros deste módulo são o canal de comunicação e os buffers BS1 e BS2.

Os seguintes estados descrevem o funcionamento deste módulo:

• idle: neste estado o processo fica escutando o canal de comunicação, verificando a chegada de

novas mensagens para o servidor;

• asking: aqui o servidor decide se vai processar ou não a requisição e manda a RI para o cliente

correspondente através do canal de comunicação;

• copying: copia a mensagem para BS1 ou BS2, dependendo se a função requerida é local ou

remota, e incremeta o tamanho atual do buffer correspondente, atualizando também o estado

daquela posição do buffer que se encontra ocupada.

Inicialmente, este processo encontra-se no estado idle.

6.8 Módulo serverLocalProcess

Representa o processo que realiza as requisições de funções locais. Recebe como parâmetros o canal

de comunicação e os buffers BS1 e BS3. Este processo possui os seguintes estados:

• idle: o processo verifica se há novas requisições em BS1 e se há espaço disponível para a

reposta em BS3;

• copying: a mensagem de resposta à requisição é copiada em BS3. Além disto, BS1 tem o

seu tamanho atual decremento e BS3 tem o seu incrementado. As posições correpondentes do

buffer de BS1 e BS3 também têm seu estado atualizado.




Incialmente, o processo encontra-se no estado idle.

6.9 Módulo serverRemoteProcess

Este módulo possui uma estrutura bastante similar a do anterior, recebendo porém BS2 ao invés de

BS1 como um de seus parâmetros. Num estágio futuro, este módulo deve comunicar-se com o módulo

master do modelo mestre/escravo, integrando assim os dois modelos.

6.10 Módulo serverWriter

A implementação deste módulo pode ser vista na figura 6.10. Ele simboliza o processo escritor do

servidor, possuindo como parâmetros o canal de comunicação e o buffer BS3. Possui os seguintes

estados:

• idle: o processo verifica se há mensagens em BS3 a serem enviadas para os clientes;

• writing: tenta-se acessar o canal de comunicação e transmitir os dados para o mesmo. O

tamanho atual de BS3 também é decrementado de uma unidade e o estado da posição do buffer

cuja mensagem foi enviada é indicado como livre.

No início, este módulo está no estado idle.

6.11 Módulo serverInternalProcess

As funcionalidades referentes a este módulo ainda não foram implementadas.

6.12 Módulo client

Representa um cliente, possuindo uma instância do módulo buffer , BC1, e instâncias dos módulos:

clienteSender , clientReceiver e clientVerifier . Sua implementação pode ser vista na figura 6.11.

6.13 Módulo clientSender

Este módulo possui como parâmetros o canal de comunicação, o identificador do cliente e o buffer

BC1. O cliente inicialmente encontra-se ocioso e então começa a gerar requisições para serem envi-

adas ao servidor.

Os estados que representam este módulo são os seguintes:

• idle: o cliente encontra-se ocioso e sairá deste estado quando decidir enviar uma mensagem

para o servidor e encontrar uma posição livre em BC1;

• copying: o processo copia a mensagem para BC1, incrementando o seu tamanho atual e atual-

izando o estado da posição onde a mensagem foi copiada;

• sending: tenta acessar o canal de comunicação para enviar a mensagem ao servidor.




MODULE serverWriter(c, BS3)VAR

state : {idle, writing};

ASSIGNinit(state) := idle;next(state) :=

casestate = idle & (BS3.status1 = 1 | BS3.status2 = 1) : {writing};state = writing & c.messageForClient : {writing};state = writing : {idle};

1 : state;esac;

next(c.msgClient.idMessage) :=case

state = writing & !c.messageForClient & BS3.status1 = 1 :BS3.msgBuffer1.idMessage;


1 : c.msgClient.idMessage;esac;

next(c.msgClient.idClient) :=case

state = writing & !c.messageForClient & BS3.status1 = 1 :

BS3.msgBuffer1.idClient;state = writing & !c.messageForClient & BS3.status2 = 1 :BS3.msgBuffer2.idClient;

1 : c.msgClient.idClient;esac;

next(c.msgClient.idFunction) :=case

state = writing & !c.messageForClient & BS3.status1 = 1 :BS3.msgBuffer1.idFunction;


1 : c.msgClient.idFunction;esac;

next(c.messageForClient) :=casestate = writing & !c.messageForClient : TRUE;1 : c.messageForClient;

esac;

next(BS3.currentSize) :=case

state = writing & BS3.currentSize > 0 : {BS3.currentSize - 1};1 : BS3.currentSize;

esac;

next(BS3.status1) :=case

state = writing & BS3.status1 = 1 : 0;1 : BS3.status1;

esac;



esac;

FAIRNESSrunning

Figura 6.10: Implementação do Módulo serverWriter




MODULE client(c, idClient)

VAR

BC1 : buffer;

sender : process clientSender(c, idClient, BC1);

receiver : process clientReceiver(c, idClient, BC1);

verifier : process clientVerifier(BC1);

Figura 6.11: Implementação do Módulo client

6.14 Módulo clientReceiver

Representa o processo leitor do cliente, possuindo os mesmos parâmetros do módulo clientSender .

Possui os seguintes estados:

• idle: o processo verifica se há novas mensagens no canal para este cliente;

• processing: aqui verifica-se se há em BC1 uma mensagem com o mesmo identificador da

mensagem que foi recebida agora. Caso exista, atualiza-se o estado da posição do buffer corre-

spondente: se a mensagem é uma RI, o estado agora vai indicar que se está esperando uma RD;

caso seja uma RD, a posição do buffer deve ser liberada e o tamanho do mesmo decrementado.

Inicialmente, este processo encontra-se no estado idle.

6.15 Módulo clientVerifier

Neste módulo representam-se as restrições de timeout do PCI. Ele possui como parâmetro apenas o

buffer BC1 e é descrito pelos seguintes estados:

• testing: o processo testa se existem mensagens em BC1 esperando por uma RI ou por uma RD

e se o timeout correspondente foi alcançado;

• removing: aqui removem-se de BC1 as mensagens cujo timeout foi alcançado, atualizando-se

o tamanho atual do buffer e o estado das suas posições.

No início este módulo encontra-se no estado testing, como pode ser visto na sua implementação,

mostrada na figura 6.12.

6.16 Propriedades do Modelo

A construção deste modelo revelou-se bem mais complexa do que a do modelo mestre/escravo, desta

forma, sofremos muito com as limitações das técnicas de model checking quando aplicadas a sistemas

maiores.

Ainda não foi possível verificar muitas propriedades do modelo, também devido ao fato que não

foi possível incluir as restrições de justiça que gostaríamos. Dentre as propriedades que conseguimos

verificar utilizando CTL encontram-se as seguintes:




MODULE clientVerifier(BC1)VAR

state : {testing, removing};remove1 : boolean;remove2 : boolean;

ASSIGN

init(state) := testing;next(state) :=

casestate = testing : removing;state = removing : testing;1 : state;

esac;

init(remove1) := FALSE;next(remove1) :=

casestate = testing & BC1.status1 != 0 : {TRUE, FALSE};state = testing : FALSE;1 : remove1;

esac;init(remove2) := FALSE;next(remove2) :=


esac;

next(BC1.status1) :=case

state = removing & remove1 : 0;1 : BC1.status1;

esac;



esac;

next(BC1.currentSize) :=case

state = removing & remove1 & remove2 & BC1.currentSize > 1 :{BC1.currentSize - 2};

state = removing & (remove1 | remove2) & BC1.currentSize > 0 :{BC1.currentSize - 1};

1 : BC1.currentSize;

esac;

FAIRNESSrunning

Figura 6.12: Implementação do Módulo clientVerifier




• Sempre que o servidor está ocioso e há uma mensagem para ele no canal ele recebe esta men-

sagem;

• Sempre que o cliente envia uma mensagem o servidor a recebe;

• O servidor sempre fornece uma RI para os clientes;

• Sempre que existem respostas no buffer BS3 o servidor as envia para os clientes.



Capítulo 7

Conclusão

O uso de métodos formais permitiu-nos verificar propriedades importantes de subsistemas, princi-

palmente na parte onde ocorre comunicação mestre/escravo. A modelagem formal do modelo de

comunicação também é útil como uma forma de documentação do sistema.

Devido a grande complexidade do modelo da parte cliente/servidor, não foi possível ainda ver-

ificar muitas propriedades a respeito do mesmo. Visando solucionar este problema, foram feitos

vários refinamentos no modelo, buscando sempre diminuir a sua complexidade, como a eliminação

de variáveis, a redução do número de clientes e do tamanho dos buffers etc. Podemos concluir que a

construção de modelos formais para sistemas complexos é uma tarefa árdua, pois exige uma mode-

lagem que torne o modelo possível de ser verificado e ao mesmo tempo respresente da melhor forma

possível o sistema real.

Uma possível abordagem para tentar contornar este problema da complexidade do modelo seria a

utlização da lógica LTL, a qual poderia nos fornecer resultados mais significativos. Isto se deve ao fato

de que LTL nos permitiria verificar propriedades a respeito de cada módulo do sistema, permintindo-

nos então fazer inferências sobre o comportamento do sistema como um todo.

Em virtude de NuSMV não permitir a ligação de módulos declarados em arquivos distintos, fize-mos uso do pré-processador C para podermos trabalhar de forma mais modular, criando vários módu-

los em arquivos separados e usando diretivas include para formar um arquivo com todos os módulos.

Este procedimento foi utilizado tanto para a construção do modelo em si como para a verificação de

propriedades a respeito do mesmo, separando as propriedades em grupos, de acordo com o módulo a

que elas se referiam.

Como o modelo cliente/servidor ficou muito complexo, não foi possível a integração entre os dois

modelos, que era um dos objetivos iniciais deste trabalho.



Apêndice A

Implementação da Comunicação

Mestre/Escravo



p n ce . mp emen aç o a omun caç o es re scravo

MODULE mainVAR

app : application;

MODULE applicationVAR

c : channel;m1 : master(c);s1 : slave(c, 1);s2 : slave(c, 2);

s3 : slave(c, 3);

ASSIGN

next(c.messageForMaster) :=case

m1.stateMaster = processing : {FALSE};

m1.currentSlave = 0 : {FALSE};

m1.currentSlave = 1 & s1.stateSlave = idle : {FALSE};m1.currentSlave = 1 & s1.stateSlave = receiving : {FALSE};m1.currentSlave = 1 & s1.stateSlave = processing : {FALSE};m1.currentSlave = 1 & s1.stateSlave = sending : {TRUE};



1 : c.messageForMaster;esac;

MODULE messageVAR

slaveAddress : 0..3;functionCode : 1..4;

ASSIGNinit(slaveAddress) := 0;

init(functionCode) := 1;

MODULE channelVAR

messageForMaster : boolean;messageForSlave : boolean;msg : message;

ASSIGNinit(messageForMaster) := FALSE;

init(messageForSlave) := FALSE;

MODULE master(c)VAR

stateMaster : {idle, packing, sending, waiting, receiving,processing};

msgMaster : boolean;currentSlave : 0..3;timeout : boolean;

Figura A.1: Implementação da Comunicação Mestre/Escravo




ASSIGNinit(stateMaster) := idle;next(stateMaster) :=

casestateMaster = idle & msgMaster : packing;stateMaster = packing & !msgMaster : sending;stateMaster = sending & c.messageForSlave & currentSlave != 0 :

waiting;stateMaster = sending & c.messageForSlave & currentSlave = 0 :

idle;stateMaster = waiting & timeout : idle;

stateMaster = waiting & c.msg.slaveAddress = 0 : idle;stateMaster = waiting & c.messageForMaster : receiving;stateMaster = receiving & msgMaster : processing;stateMaster = processing & !msgMaster : idle;1 : stateMaster;

esac;

init(msgMaster) := FALSE;next(msgMaster) :=

casestateMaster = idle : {FALSE, TRUE};stateMaster = packing : {FALSE};stateMaster = sending : {FALSE};stateMaster = waiting : {FALSE};stateMaster = receiving : {TRUE};

stateMaster = processing : {FALSE};1 : msgMaster;esac;

next(c.messageForSlave) :=case

stateMaster = idle : {FALSE};stateMaster = packing : {FALSE};stateMaster = sending : {TRUE};stateMaster = waiting & !c.messageForMaster : {TRUE};stateMaster = waiting & c.messageForMaster : {FALSE};stateMaster = receiving : {FALSE};stateMaster = processing : {FALSE};1 : c.messageForSlave;

esac;

init(currentSlave) := 0;next(currentSlave) :=

casestateMaster = idle & msgMaster : {0,1,2,3};1 : currentSlave;

esac;

next(c.msg.slaveAddress) :=case

stateMaster = packing : {currentSlave};1 : c.msg.slaveAddress;

esac;

init(timeout) := FALSE;

next(timeout) :=case

currentSlave != 0 & stateMaster = waiting : {TRUE, FALSE};1 : timeout;

esac;

FAIRNESSstateMaster = sending





MODULE slave(c, id)VAR

stateSlave : {idle, sending, receiving, processing};idSlave : 1..3;msgSlave : boolean;res : boolean;

currentId : 0..3;

ASSIGNinit(idSlave) := id;next(idSlave) := idSlave;

init(stateSlave) := idle;next(stateSlave) :=

casestateSlave = idle & c.messageForSlave &

(c.msg.slaveAddress = idSlave | c.msg.slaveAddress = 0) :receiving;

stateSlave = receiving & msgSlave : processing;stateSlave = processing & currentId != idSlave : idle;stateSlave = processing & currentId = idSlave & res : sending;stateSlave = sending : idle;1 : stateSlave;

esac;

init(msgSlave) := FALSE;next(msgSlave) :=

casestateSlave = idle : {FALSE};stateSlave = receiving : {TRUE};stateSlave = processing : {FALSE};stateSlave = sending : {FALSE};1 : msgSlave;

esac;

init(res) := FALSE;

next(res) :=case

stateSlave = idle : {FALSE};stateSlave = receiving : {FALSE};stateSlave = processing & currentId = idSlave : {TRUE};stateSlave = processing & currentId != idSlave : {FALSE};stateSlave = sending & c.msg.slaveAddress = idSlave : {FALSE};1 : res;

esac;

init(currentId) := 0;next(currentId) :=

casestateSlave = idle &

(c.msg.slaveAddress = 0 | c.msg.slaveAddress = idSlave) :

c.msg.slaveAddress;1 : currentId;esac;




Apêndice A

Implementação da Comunicação

Cliente/Servidor



p n ce . mp e men aç o a omun c aç o en e erv or

MODULE mainVAR

app : application;

MODULE messageVAR

idClient: 1..2;idMessage: -1..1;idFunction: 1..4;-1 representa funcao local e 2 funcao remota

-3 representa not acknowledge e 4 acknowledge

MODULE channelVAR

messageForClient : boolean;messageForServer : boolean;msgClient : message;msgServer : message;

ASSIGNinit(messageForClient) := FALSE;

init(messageForServer) := FALSE;

MODULE bufferVAR

msgBuffer1 : message;msgBuffer2 : message;

currentSize : 0..2; -tamanho atual do buffer

status1 : 0..2; -indica o status da mensagem na posicao 1 do buffer- 0 -> posicao livre- 1, 2 -> posicao ocupada- no caso de BC1, temos o seguinte signficado- 1 -> aguardando resposta intermediaria- 2 -> aguardando resposta definitivastatus2 : 0..2; -indica o status da mensagem na posicao 2 do buffer

ASSIGNinit(currentSize) := 0;

init(status1) := 0;

init(status2) := 0;

MODULE applicationVAR

c : channel;s : server(c);c1 : client(c, 1);c2 : client(c, 2);

MODULE server(c)

VARBS1 : buffer;BS2 : buffer;BS3 : buffer;lockBS3 : boolean; -trava para acessar o buffer BS3reader : process serverReader(c, BS1, BS2);local : process serverLocalProcess(BS1, BS3, lockBS3);remote : process serverRemoteProcess(BS2, BS3, lockBS3);writer : process serverWriter(c, BS3);internal : process serverInternalProcess(c);

ASSIGNinit(lockBS3) := FALSE;

Figura A.1: Implementação da Comunicação Cliente/Servidor




MODULE serverReader(c, BS1, BS2)VAR

state : {idle, asking, copying};idInsert : 1..2;


casestate = idle & c.messageForServer : {asking};state = asking & ((BS1.currentSize < 2 &

c.msgServer.idFunction = 1) |(BS2.currentSize < 2 & c.msgServer.idFunction = 2)) &c.messageForClient : {copying};

state = asking & ((BS1.currentSize = 2 &c.msgServer.idFunction = 1) | (BS2.currentSize = 2 &c.msgServer.idFunction = 2)) & !c.messageForClient : {idle};

state = copying : {idle};1 : state;

esac;

-*********************************************-tira a mensagem do canalnext(c.messageForServer) :=

casestate = copying : FALSE;1 : c.messageForServer;

esac;

-*********************************************-respondendo ao cliente que recebeu a mensagem


state = asking & !c.messageForClient & ((BS1.currentSize < 2 &c.msgServer.idFunction = 1) | (BS2.currentSize < 2 &c.msgServer.idFunction = 2)) : {3};

state = asking & !c.messageForClient & ((BS1.currentSize = 2 &c.msgServer.idFunction = 1) | (BS2.currentSize = 2 &c.msgServer.idFunction = 2)) : {4};



state = asking & !c.messageForClient : {c.msgServer.idClient};1 : c.msgClient.idClient;

esac;


state = asking & !c.messageForClient : {c.msgServer.idMessage};1 : c.msgClient.idMessage;

esac;

next(c.messageForClient) :=case

state = asking & !c.messageForClient : TRUE;1 : c.messageForClient;

esac;

-terminou de responder ao cliente-********************************





-considerando a funcao 1 como funcao localnext(idInsert) :=

casestate = idle & BS1.currentSize < 2 &

c.msgServer.idFunction = 1 & BS1.status1 = 0 : {1};state = idle & BS1.currentSize < 2 &



c.msgServer.idFunction = 2 & BS2.status2 = 0 : {2};

1 : idInsert;esac;


state = copying & c.msgServer.idFunction=1 & idInsert=1 : 1;1 : BS1.status1;

esac;



esac;

next(BS2.status1) :=casestate = copying & c.msgServer.idFunction=2 & idInsert=1 : 1;1 : BS2.status1;

esac;



esac;

next(BS1.msgBuffer1.idMessage) :=case

state = copying & c.msgServer.idFunction = 1 & idInsert = 1 :c.msgServer.idMessage;

1 : BS1.msgBuffer1.idMessage;esac;

next(BS1.msgBuffer1.idFunction) :=case

state = copying & c.msgServer.idFunction = 1 & idInsert = 1 :c.msgServer.idFunction;

1 : BS1.msgBuffer1.idFunction;esac;



1 : BS1.msgBuffer2.idMessage;

esac;



















1 : BS2.msgBuffer2.idFunction;

esac;next(BS1.currentSize) :=

casestate = copying & c.msgServer.idFunction = 1 &

BS1.currentSize < 2 : {BS1.currentSize + 1};1 : BS1.currentSize;

esac;


state = copying & c.msgServer.idFunction = 2 &BS2.currentSize < 2 : {BS2.currentSize + 1};

1 : BS2.currentSize;esac;

FAIRNESSrunning

MODULE serverLocalProcess(BS1, BS3, lockBS3)VAR

state : {idle, copying};idBS1 : 1..2;idBS3 : 1..2;


casestate = idle & BS1.currentSize > 0 & lockBS3 = FALSE &

BS3.currentSize < 2 : {copying};state = copying : {idle};1 : state;

esac;

next(lockBS3) :=case

state = idle & BS1.currentSize > 0 & lockBS3 = FALSE &BS3.currentSize < 2 : TRUE;

state = copying : 0;1 : lockBS3;

esac;





init(idBS1) := 1;next(idBS1) :=

casestate = idle & BS1.status1 != 0 : {1};state = idle & BS1.status2 != 0 : {2};1 : idBS1;

esac;


case

state = idle & BS3.status1 = 0 : 1;state = idle & BS3.status2 = 0 : 2;1 : idBS3;

esac;


state = copying & idBS1 = 1 : 0;1 : BS1.status1;

esac;



esac;next(BS1.currentSize) :=

casestate = copying & BS1.currentSize > 0 : {BS1.currentSize - 1};1 : BS1.currentSize;

esac;


state = copying & BS3.currentSize < 2 : BS3.currentSize + 1;1 : BS3.currentSize;

esac;



esac;



esac;


state = copying & idBS3 = 1 : {BS1.msgBuffer1.idMessage};1 : BS3.msgBuffer1.idMessage;

esac;


state = copying & idBS3 = 1 : {BS1.msgBuffer1.idFunction};1 : BS3.msgBuffer1.idFunction;

esac;

next(BS3.msgBuffer1.idClient) :=case

state = copying & idBS3 = 1 : {BS1.msgBuffer1.idClient};1 : BS3.msgBuffer1.idClient;

esac;







esac;



esac;



esac;

FAIRNESSrunning

MODULE serverRemoteProcess(BS2, BS3, lockBS3)VAR

state : {idle, copying};idBS2 : 1..2;

idBS3 : 1..2;ASSIGN

init(state) := idle;next(state) :=

casestate = idle & BS2.currentSize > 0 & lockBS3 = FALSE &

BS3.currentSize < 2 : {copying};state = copying : {idle};1 : state;

esac;

next(lockBS3) :=case

state = idle & BS2.currentSize > 0 & lockBS3 = FALSE &BS3.currentSize < 2 : TRUE;

state = copying : 0;1 : lockBS3;

esac;


casestate = idle & BS2.status1 != 0 : {1};state = idle & BS2.status2 != 0 : {2};1 : idBS2;

esac;


case

state = idle & BS3.status1 = 0 : 1;state = idle & BS3.status2 = 0 : 2;1 : idBS3;

esac;



esac;







esac;


state = copying & BS2.currentSize > 0 : {BS2.currentSize - 1};1 : BS2.currentSize;

esac;


state = copying & BS3.currentSize < 2 : BS3.currentSize + 1;1 : BS3.currentSize;

esac;



esac;


state = copying & idBS3 = 2 : 1;1 : BS3.status2;esac;



esac;



esac;



esac;



esac;


state = copying & idBS3 = 2 : {BS2.msgBuffer2.idFunction};




esac;

FAIRNESSrunning





MODULE serverWriter(c, BS3)VAR

state : {idle, writing};


casestate = idle & (BS3.status1 = 1 | BS3.status2 = 1) : {writing};state = writing & c.messageForClient : {writing};state = writing : {idle};

1 : state;esac;




1 : c.msgClient.idMessage;esac;


state = writing & !c.messageForClient & BS3.status1 = 1 :

BS3.msgBuffer1.idClient;state = writing & !c.messageForClient & BS3.status2 = 1 :BS3.msgBuffer2.idClient;

1 : c.msgClient.idClient;esac;





next(c.messageForClient) :=casestate = writing & !c.messageForClient : TRUE;1 : c.messageForClient;

esac;


state = writing & BS3.currentSize > 0 : {BS3.currentSize - 1};1 : BS3.currentSize;

esac;



esac;



esac;

FAIRNESSrunning

MODULE serverInternalProcess





MODULE client(c, idClient)VAR

BC1 : buffer;sender : process clientSender(c, idClient, BC1);receiver : process clientReceiver(c, idClient, BC1);verifier : process clientVerifier(BC1);

MODULE clientSender(c, idClient, BC1)

VAR

state : {idle, copying, sending};idInsert : 1..2;


casestate = idle & BC1.currentSize < 2 : {idle, copying};state = copying : {sending};state = sending & c.messageForServer : {sending};state = sending & !c.messageForServer : {idle};1 : state;

esac;

init(idInsert) := 1;

next(idInsert) :=casestate = idle & BC1.status1 = 0 : 1;state = idle & BC1.status2 = 0 : 2;1 : idInsert;

esac;


state = copying & BC1.currentSize < 2 : BC1.currentSize + 1;1 : BC1.currentSize;

esac;

next(BC1.msgBuffer1.idClient) :=case

state = copying & idInsert = 1 : {idClient};1 : BC1.msgBuffer1.idClient;

esac;

next(BC1.msgBuffer1.idFunction) :=case

state = copying & idInsert = 1 : {1, 2};1 : BC1.msgBuffer1.idFunction;

esac;

next(BC1.msgBuffer1.idMessage) :=case

state = copying & idInsert = 1 &(BC1.status2 = 0 | BC1.msgBuffer2.idMessage != 0) : {0};

state = copying & idInsert = 1 &

(BC1.status2 = 0 | BC1.msgBuffer2.idMessage != 1) : {1};

1 : BC1.msgBuffer1.idMessage;esac;


state = copying & idInsert = 1 : 1;1 : BC1.status1;

esac;





next(BC1.msgBuffer2.idClient) :=case

state = copying & idInsert = 2 : {idClient};1 : BC1.msgBuffer2.idClient;

esac;

next(BC1.msgBuffer2.idFunction) :=case

state = copying & idInsert = 2 : {1, 2};1 : BC1.msgBuffer2.idFunction;

esac;

next(BC1.msgBuffer2.idMessage) :=case

state = copying & idInsert = 2 &BC1.msgBuffer1.idMessage != 0 : {0};

state = copying & idInsert = 2 &BC1.msgBuffer1.idMessage != 1 : {1};

1 : BC1.msgBuffer2.idMessage;esac;


state = copying & idInsert = 2 : 1;

1 : BC1.status2;esac;

next(c.messageForServer) :=case

!c.messageForServer & state = sending : TRUE;1 : c.messageForServer;

esac;

next(c.msgServer.idClient) :=case

state = sending & !c.messageForServer : idClient;1 : c.msgServer.idClient;

esac;

next(c.msgServer.idMessage) :=case

state = sending & !c.messageForServer & idInsert = 1 :BC1.msgBuffer1.idMessage;

state = sending & !c.messageForServer & idInsert = 2 :BC1.msgBuffer2.idMessage;

1 : c.msgServer.idMessage;esac;

next(c.msgServer.idFunction) :=case

state = sending & !c.messageForServer & idInsert = 1 :BC1.msgBuffer1.idFunction;

state = sending & !c.messageForServer & idInsert = 2 :BC1.msgBuffer2.idFunction;

1 : c.msgServer.idFunction;

esac;

FAIRNESSrunning

MODULE clientReceiver(c, idClient, BC1)VAR

state : {idle, processing};






casestate = idle & c.messageForClient &c.msgClient.idClient = idClient : processing;state = processing : {idle};1 : state;

esac;

next(c.messageForClient) :=

casestate = processing : FALSE;1 : c.messageForClient;

esac;


-a requisicao nao pode ser atendida pelo servidorBC1.status1 = 1 & state = processing &c.msgClient.idMessage = BC1.msgBuffer1.idMessage& c.msgClient.idFunction = 3 : {0};

-a requisicao vai ser atendida pelo servidorBC1.status1 = 1 & state = processing &c.msgClient.idMessage = BC1.msgBuffer1.idMessage &

c.msgClient.idFunction = 4 : {2};-recebeu resposta definitivaBC1.status1 = 2 & state = processing &c.msgClient.idMessage = BC1.msgBuffer1.idMessage : {0};



-a requisicao nao pode ser atendida pelo servidorBC1.status2 = 1 & state = processing &c.msgClient.idMessage = BC1.msgBuffer2.idMessage &c.msgClient.idFunction = 3 : {0};

-a requisicao vai ser atendida pelo servidorBC1.status2 = 1 & state = processing &c.msgClient.idMessage = BC1.msgBuffer2.idMessage &c.msgClient.idFunction = 4 : {2};

-recebeu resposta definitivaBC1.status2 = 2 & state = processing &c.msgClient.idMessage = BC1.msgBuffer2.idMessage : {0};



BC1.currentSize > 0 & BC1.status1 = 1 & state = processing &

c.msgClient.idMessage = BC1.msgBuffer1.idMessage &c.msgClient.idFunction = 3 : BC1.currentSize - 1;

BC1.currentSize > 0 & BC1.status1 = 2 & state = processing &c.msgClient.idMessage = BC1.msgBuffer1.idMessage :BC1.currentSize - 1;

BC1.currentSize > 0 & BC1.status2 = 1 & state = processing &c.msgClient.idMessage = BC1.msgBuffer2.idMessage &c.msgClient.idFunction = 3 : BC1.currentSize - 1;





BC1.currentSize > 0 & BC1.status2 = 2 & state = processing &c.msgClient.idMessage = BC1.msgBuffer2.idMessage :BC1.currentSize - 1;

1 : BC1.currentSize;esac;

FAIRNESSrunning

MODULE clientVerifier(BC1)VARstate : {testing, removing};remove1 : boolean;remove2 : boolean;

ASSIGN

init(state) := testing;next(state) :=

casestate = testing : removing;state = removing : testing;1 : state;

esac;



esac;



esac;



esac;



esac;


state = removing & remove1 & remove2 & BC1.currentSize > 1 :{BC1.currentSize - 2};

state = removing & (remove1 | remove2) & BC1.currentSize > 0 :{BC1.currentSize - 1};

1 : BC1.currentSize;esac;

FAIRNESSrunning




Referências Bibliográficas

[Alf00] Alfa Instrumentos. Protocolo de Comunicação Modbus RTU/ASCII , 2000.

[CCGR99] A. Cimatti, E.M. Clarke, F. Giunchiglia, and M. Roveri. NUSMV: a newSymbolic Model Verifier. In N. Halbwachs and D. Peled, editors, Proceed-ings Eleventh Conference on Computer-Aided Verification (CAV’99), num-ber 1633 in Lecture Notes in Computer Science, pages 495–499, Trento,Italy, July 1999. Springer.

[dS04] Rodrigo Barbosa de Souza. Uma Arquitetura Para Sistemas Supervisórios Industriais e sua Aplicação em Processos de Elevação Artificial de Petróleo.Mestrado em automação e sistemas, DCA/UFRN, Natal, 2004.

[ITC02] ITC-IRST. NuSMV 2.1 User Manual , 2002.

[Mai03] A. Maitelli. A ufrn e a automação na Área do petróleo. In Caderno DaVinci. UFRN, 2003.

[McM92] K. L. McMillan. The SMV System, 1992. Disponível emhttp://www.cs.cmu.edu/ modelcheck/smv/smvmanual.r2.2.ps. Acesso emmarço de 2004.

[McM93] K. L. McMillan. Symbolic Model Checking. Kluwer Academic Publishers,1993.

[MOD96] MODICON, Inc., Industrial Automation Systems. Modicon Modbus Proto-

col Reference Guide, 1996.[MOD02] MODBUS. Modbus Application Protocol Specification, 2002.

apostila sobre modbus

Documents