Software Supervisório CDS Projeto Módulo Supervisório

Transcrição

1 Software Supervisório CDS Projeto Módulo Supervisório Cruzeiro do Sul Desenvolvimento Revisão de março de Especificações de projeto O módulo de comunicação do software supervisório CDS se comunicará com os controladores CDS através do protocolo Modbus-RTU pelo meio físico RS-485. O módulo de comunicação é responsável por aquisitar as amostragens feitas pelos controladores periodicamente e enviar comando ao mesmos. As aquisições e os resultados dos comandos são então gravados em banco de dados para posterior visualização. Segundo o projeto do software supervisório, o módulo visual se relaciona com o módulo de comunicação de acordo com a lista abaixo: O módulo visual é responsável pela configuração do módulo de comunicação, parâmetrizando a porta serial usada, o estado da comunicação (comunicando/não comunicando) e adicionando controladores. O módulo visual envia objetos de comando ao módulo de comunicação que devem ser enviados para os controladores. O resultado do comando é enviado para o módulo visual através de evento. O módulo de comunicação sinaliza ao módulo visual através de evento que uma período de aquisição está completo e os novos dados já estão disponíveis no banco de dados. O módulo de comunicação sinaliza ao módulo visual através de evento que houve erros críticos na comunicação. As aquisições e os resultados das requisições são gravados em banco de dados que é acessado através do módulo banco de dados. A cada ciclo de amostragem o módulo de comunicação grava os dados obtidos. 2 Classes O módulo é composto pelas seguintes classes e interfaces 1 : 1 Algumas classes desse módulo já são usadas em outros módulos. Será aqui detalhado somente a parte dessas classes que relacionam-se com o módulo em questão. 1

2 Communications Scheduler Protocol Formatter Command Controller Request SampleRequest DeviceID SupervisorEvent 2.1 Communications É a classe principal do módulo que possui todas as outras classes do módulo e organiza o fluxo de execução. Esta classe é derivada de Thread. Um objeto Communications possui uma lista de Controller aos quais o objeto deve se comunicar e uma lista de Command que o objeto deve realizar. Possui um objeto Scheduler, um objeto Protocol e um objeto Formatter. A classe possui os seguinte métodos públicos: startcommunications(): inicializa aa comunicação com os controladores ( se já não estiver sido iniciada ). stopcommunications(): para a comunicação com os controladores. setserialport( SerialPort ): configura os parâmetros da porta serial usada. setsampleperiod( float ): configura o tempo do ciclo de atualização das variáveis. docommand( Command ): adiciona o comando na fila de comandos a serem feitos. DeviceID initializecontroller( int IP ): procura na rede um controlador com o IP dado e faz a requisição para esse controlador de seu DeviceID. Retorna um objeto DeviceID com as informações obtidas. Retorna null em caso de falha na requisição ou caso não encontrar o controlador na rede. O método só devolve o controle ao chamador quando a requisição do DeviceID do controlador for completada. addcontroller( Controller ): adiciona um controlador na lista de Controller. boolean removecontroller( Controller ): remove um controlador da lista de Controller. Retorna true se a remoção for bem-sucedida. 2

3 mutecontroller( Controller ): para de se comunicar com o Controller indicado. talktocontroller( Controller ): volta a se comunicar com o Controller indicado. A classe lança SupervisorEvents que possuem que podem ser de três tipos (de acordo com o método getevent- Type()): CommandDone: é lançado quando um comando é feito pelo módulo. Passa como parâmetro o objeto Command que foi completado. AcquisitonCompleted: é lançado quando é completado um ciclo de atualização das variáveis. CommunicationExceptionDetected: é lançado quando é detectado uma exceção na comunicação. Passa como parâmetro o código da exceção, uma string contendo a mensagem da exceção e um objeto qualquer que contém mais informações sobre a exceção. 2.2 Scheduler O Scheduler é responsável pela organização e escalonamento da fila de comunicação. Ele organiza a fila de comunicação dando alto prioridade para os comando e prioridade baixa para as aquisições. O Scheduler é ainda responsável por analisar as variáveis de cada controlador e criar objetos Request que contém códigos Modbus para a aquisição de um número ótimo de variáveis. O Scheduler possui referência para a lista de Controller a para a lista de Command do objeto Communications pai e essas referências devem ser passadas como parâmetro no construtor. A classe possui os seguintes métodos públicos: setsamplecycleperiod( float ): configura o tempo do ciclo de atualização das variáveis. Request getlastrequest(): organiza a fila de comunicação e retorna o primeiro objeto Request da fila. boolean issamplecycleexpired(): retorna uma flag que sinaliza se o ciclo de atualização de variáveis já está completo. restartsamplecycle(): reinicia o ciclo de atualização das variáveis. hassamplerequestinqueue( Controller ): retorna false caso não houver mais amostragens daquele Controller a serem feitas naquele ciclo de atualização das variáveis. Este flag deve ser conferido a cada requisição feita, e caso false, deve-se gravar as novas amostragens no banco de dados. O Scheduler possui um timer interno que estoura a cada período do ciclo de atualização. Se o timer estourar antes do ciclo de atualização estar completo, o ciclo seguinte é adiado para o próximo estouro do timer para que o supervisório consiga ler todas as variáveis. Isso pode causar que as variáveis não se atualizem sempre no tempo configurado para o período do ciclo de atualização. 3

4 2.3 Protocol A classe Protocol é responsável pelo envio das requisições de amostragem e comandos pela porta serial. A classe Protocol envia as requisições, aguarda que o resultado pela porta serial. Caso a requisição for um comando, o Protocol envia o frame de comando para o dispositivo, e espera uma confirmação. Caso a confirmação for recebida, um evento SupervisorEvent do tipo CommandDone é gerado para o módulo Visual. Caso não acontecer uma confirmação ou o dispositivo comandado retornar um frame de exceção, um evento SupervisorEvent do tipo CommunicationExceptionDetected é gerado para o módulo Visual. Caso a requisição for de amostragem, o Protocol envia o frame de requisição de amostragem para o dispositivo e espera que o este envia uma resposta que contenha a amostragem. Caso o frame de resposta for válido, o objeto Protocol insere as aquisições recebidas pela porta serial no objeto SampleRequest usando o método setdata de SampleRequest. A classe possui os seguintes métodos públicos: Request sendrequest( Request ): envia uma requisição de amostragem ou um comando pela porta serial e captura a sua resposta. Retorna o objeto Command ou objeto SampleRequest atualizados com a resposta obtida. setserialport( SerialPort ): configura os parâmetros da porta serial usada. 2.4 Formatter A classe Formatter é responsável por fazer a conversão entre os dados de 16 bits recebidos dos dispositivos para dados de ponto flutuante de acordo com um mapeamento definido em um objeto Controller. A classe possui um método estático chamado formatdata( SampleRequest ) que usa os dados de 16 bits contidos no objeto SampleRequest para atualizar as variáveis contidas no objeto Controller associado ao objeto SampleRequest. O método utiliza as informações sobre cada variável contidas no objeto Controller associado ao objeto SampleRequest para fazer a conversão adequadamente. O método não retorna nenhum valor ( os resultados são armazenados no objeto Controller ) e pode lançar uma Exception caso for detectado algum erro. 2.5 Controller A classe Controller 2 agrega as informações sobre cada controlador CDS. Um objeto Controller possui as seguintes informações: IP do controlador. Vetor de SampleInfo que contém as informações sobre cada variável interna do controlador. A classe Controller possui os seguinte métodos públicos: 2 Ver mais no documento de projeto do módulo Visual 4

5 setip( byte ) e getip(): retornam e setam o endereço no barramento do controlador. SampleInfo [] getvariables(): retornam um vetor de SampleInfo que contém todas as informações das variáveis. 2.6 SampleInfo A classe SampleInfo contém todas as informações da variável. Um objeto SampleInfo possui as seguintes informações: Nome da variável. Tipo da variável (VariableType). Código ModBus da variável. Última amostragem. Vetor com histórico de amostragens. Potência de 10. Caso a variável for uma variável analógica, a informação que vem pelo protocolo Mod- Bus é um dados do tipo short de 16 bits que tem sua magnitude variando de 0 a Esse dado é multiplicado por 10 P otencia 10 para chegar-se ao valor em unidades físicas. Flag de sinal: True representa uma variável signed e False representa uma variável unsigned VariableType Discrete Input. Coils. Input Register. Holding Register. 2.7 Request Interface para objetos que são enviadas para os dispositivos na rede. A interface Request provê métodos para a construção do frame de requisição no protocolo Modbus. A interface possui os seguintes métodos: byte[] getrequestframe(): retorna o frame Modbus de requisição. Controller getsourcecontroller(): retorna o controlador associado à requisição. 5

6 isdone(): flag que sinaliza que a requisição já foi feito ao controlador associado. haserrors(): flag que sinaliza que houve erros no envio da requisição. String geterrorlog(): retorna um String contendo informações sobre um eventual erro na comunicação. 2.8 Command Representa um comando do supervisório ao controlador, geralmente a parametrização de uma variável. Implementa a interface Request. Possui as seguinte informações adicionais: SampleInfo [] getvariables(): retorna um vetor que contém as variáveis que irão ser parametrizadas pelo comando. object [] getparameters(): retorna um vetor que contém o valor das parametrizações. 2.9 SampleRequest Representa a requisição de amostragens para um controlador. Depois que a requisição for feita o campo Última amostragem dos SampleInfo associados serão preenchidos. Implementa a interface Request. Possui as seguinte informações adicionais: SampleInfo [] getvariables(): retorna um vetor que contém as variáveis que irão ser parametrizadas pelo comando. object [] getparameters(): retorna um vetor que contém o valor das parametrizações DeviceID Representa as informações de inicialização de cada controlador. Possui as seguinte informações: Basic Device Identification. VendorName. MajorMinorRevision. 3 Seqüência de processamento Em construção... 6

7 4 Implementação Protocolo Modbus-RTU A implementação Modbus-RTU que será feita se restringirá à um conjunto específico de funções. Segundo a especificação do protocolo o frame de requisição e de resposta do controlador podem ter tamanho variável. Esse tamanho, para RS-485, é limitado em 256 bytes. Contrariando a especificação, a implementação do protocolo limitará o tamanho do frame em 64 bytes, já que os controladores CDS possuem número limitado de variáveis a serem aquisitadas e capacidade de processamento limitada. As seguintes funções serão implementadas: Read Discrete Inputs Write Single Coil Read Coils Write Multiple Coils 3 Read Input Registers Write Single Register Write Multiple Registers 4 Read Holding Registers Read Device Identification Read Exception Status 5 A função Read Device Identification será usada pelo supervisório para verificar a conexão com o controlador e para obter informações sobre seu modelo para a correta configuração do supervisório. O supervisório lerá o arquivo de configuração referente ao código do modelo do dispositivo retornado por essa função. Será implementado somente o Basic Device Identification da função e o único Read Device Code disponível será 0x01. O campo VendorName terá até 20 caracteres, o campo ProductCode terá até 10 caracteres e o campo MajorMinorRevision terá até 5 caracteres e indicará a versão do dispositivo. O campo ProductCode juntamente com o campo MajorMinorRevision definirão qual arquivo de configuração deverá ser carregado pelo supervisório. 4.1 Mapa de variáveis CTU Discrete Inputs - Entradas Digitais Não há nenhuma entrada digital no CTU Possivelmente optar-se-á por não implementar essa função. 4 Possivelmente optar-se-á por não implementar essa função. 5 Possivelmente optar-se-á por não implementar essa função. 7

8 4.1.2 Coils - Saída Digitais e Estados Internos Binários Saída relé 1 Saída relé 2 Saída alarme Ativação do sensor temperatura 1... Ativação do sensor temperatura N Ativação do sensor umidade Ativação do modo manual Input Registers - Entradas Analógicas Temperatura Umidade Sensor de temperatura 1... Sensor de temperatura N Índice da amostra Holding Registers - Saídas Analógicas e Registradores Internos Período de amostragem Ganho de calibração do sensor umidade Offset de calibração do sensor umidade Ganho de calibração do sensor temperatura 1 Offset de calibração do sensor temperatura 1... Ganho de calibração do sensor temperatura N Offset de calibração do sensor temperatura N 8

9 Set-point temperatura Set-point umidade Histerese temperatura Histerese umidade Limite superior de alarme de temperatura Limite inferior de alarme de temperatura Limite superior de alarme de umidade Limite inferior de alarme de umidade 9