DAS5306: Informática Industrial II

Trabalhos para 2008/1

Trabalhos entregues após a data estipulada perdem 10% da nota máxima
por dia de atraso, inclusive sábados e domingos.

Trabalhos entregues no dia correto mas depois do horário de aula também
perdem 10% da nota máxima.

Apresentações individuais podem ser solicitadas.

Uma sugestão para quem só tem Windows em casa é usar o MinGW.




T1 - Trabalho do simulador de sistemas a evento discreto

Re-implementar o motor de simulação fornecido em motor5.c, desta vez usando
uma tabela hash para armazenar as transições possíveis.

O único arquivo a ser alterado é motor5.c, todos os demais arquivos
permanecem exatamente como estão.

Avaliar qualitativamente o ganho em desempenho da nova solução.

Sistema simulado:

Considere o problema da Linha de Produção de Cervejas, como descrito no
capítulo 3 da apostila do Prof. Cury sobre "Teoria de Controle Supervisório
de Sistemas a Eventos Discretos", página 20.

http://www.das.ufsc.br/~cury/cursos/apostila.pdf

Os seguintes arquivos estão disponíveis:

envasilhamento5.pdf    Arquivo descrevendo a máquina de estados da planta

motor5.c    Exemplo do programa controlador a ser feito

motor5.h    Descrição das rotinas disponíveis no simulador da planta

envasilhamento5.c    Simulador da planta

envasilhamento5.h    Descrição das rotinas disponíveis no simulador da planta

controlador5.c    Controlador da planta


T2 - Trabalho de sincronização de relógios

Dados dois computadores quaisquer, determinar a diferença entre os relógios
desses computadores (skew) e também a variação desta diferença no
tempo (drift rate).

Implementar uma aplicação distribuída que usa o modelo cliente-servidor, e onde a comunicação entre
os processos seja feita através de mensagens, usando UDP como nos exemplos em udpcliente2008.c e
udpservidor2008.c .
   
Duas trocas de mensagens são possíveis entre um processo cliente e um processo servidor:
M1) Cliente manda uma mensagem TESTE para o servidor, que imediatamente responde com uma
mensagem OK.
M2) Cliente manda uma mensagem LEHORA para o servidor, que imediatamente responde com a
hora local em sua máquina.
  
O cliente é capaz de medir a diferença entre o seu relógio e o relógio do servidor, através de 3 etapas:
  
Passo 1) Cliente faz um TESTE e mede o tempo para uma mensagem ir e voltar do servidor, desta
forma estima o atraso da rede. Como o atraso na rede é variável, fazer várias medições e obter a média.

Passo 2) Cliente faz um LEHORA e obtém a hora do servidor, acrescenta o atraso estimado para
a rede e compara o seu relógio com o relógio do servidor.

Passo 3) Cliente faz operações de LEHORA periódicas, para determinar a variação do atraso no tempo,
considerando sempre os atrasos na rede. Fazer várias medições e obter a média.

O relatório técnico Trabalhando com o Tempo Real em Aplicações Sobre o Linux pode
ser consultado sobre funções Unix para manipular tempo.
  

T3 - Trabalho do controlador de sistema contínuo (Preliminar)

NOVA PLANTA SERÁ FORNECIDA

Implementar o controle do sistema descrito aqui.
 
Simulador é usado para simular uma unidade de caldeira e é chamado com:
      java -jar aquecedor2008_1.jar  <número-porta-escutada>

A caldeira possui instrumentação embutida e aceita os seguintes comandos:
"sta0"            lê valor de Ta
"st-0"            lê valor de T
"sti0"             lê valor de Ti
"sno0"           lê valor de No
"sh-0"           lê valor de H
"ani123.4"    define valor de Ni como 123.4
"aq-567.8"   define valor de Q como 567.8
 

Cuidado com a formatação dos valores em ponto flutuante.

Implementar um programa em C no Linux.

O programa CONTROLADOR deve incluir o controle em malha fechada
da temperatura da água e do nível da água.

A comunicação entre o CONTROLADOR e o simulador da caldeira será através
de sockets UDP/IP.
    
A tarefa de controle deve ser uma tarefa periódica com período de 100mS, implementada com
precisão e não com sleep fixo (ver apostila na página da disciplina).

Gerar um histograma com os valores utilizados como parâmetro do sleep.

T4 - Trabalho do servidor de dados do processo (Preliminar)

Implementar em C no Linux, utilizando a biblioteca das pthreads, um programa que
atue como servidor de dados do processo (SDP). O processo é o mesmo utilizado no
trabalho T3.

O SDP deverá definir uma "tag" (nome) para cada variável do chão de fábrica
que corresponde a um ponto de medição ou atuação.

O SDP atuará como servidor, recebendo "requests" pela rede de programas
clientes os quais poderão através dele acessar as variáveis do processo através
de seus tags.

Internamente, o SDP possui threads que automaticamente e periodicamente
mantém a consistência entre os valores armazenados por ele e aqueles que
estão presentes na planta.

O SDP busca suas informações junto ao controlador específico da
planta. Ele NÃO acessa diretamente a instrumentação da planta.

Será necessário alterar o programa controlador do trabalho 3 para que o
mesmo forneça ao SDP os valores das variáveis, conforme suas
solicitações. Definir protocolo específico para isto, de forma semelhante
ao protocolo usado entre controlador e planta.

O mapeamento entre "tag" e
(endereço de rede, número de porta, string de comando )
deverá ser feito via uma tabela hash. Exemplo de tabela hash em

tabhash.c


O SDP também deve oferecer uma interface que permita a
definição dos tags e seu mapeamento para endereços de rede.
Ou seja, o mapeamento entre "tag" e
(endereço de rede, número de porta, string de comando )
não está fixo no programa SDP, mas é recebido via rede
através do protocolo de configuração.

Os testes do SDP podem ser feitos através de um programa
tipo udpcliente, como fornecido na página da disciplina. A
configuração do SDP pode estar fixa no programa de testes.

T5 - Trabalho de supervisão do sistema completo (Preliminar)

Implementar um supervisório que utiliza o SDP implementado no trabalho T4.

O supervisório implementado como um programa em C no Linux, usando a biblioteca de pthreads,
deverá incluir as seguintes funcionalidades:

- Alarme associado com valores das variáveis amostradas;
- Armazenagem em arquivo de leitura periódicas dos sensores (arquivo de histórico);
- Informações periódicas na tela;
- Leitura de comandos e/ou valores a partir do teclado que alteram os valores de referência.

O programa NÃO pode acessar diretamente nem os controladores nem a instrumentação
no chão da fábrica. Ele acessa tão somente o SDP.

Outros requisitos:
    - Usar mutex para proteger as variáveis compartilhadas;
    - Usar variáveis condição para liberar as threads de alarme;
    - Atualização da tela pode ser com sleep simples de 1 segundo;
    - Usar buffer duplo para a gravação de dados em arquivos, feita por thread própria.