DAS5306: Informática Industrial II

Trabalhos para 2006/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 sobre controlador discreto

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

O objetivo neste trabalho é implementar um controlador para maximizar a
produção da planta, ou seja, manter todas as estações da linha
trabalhando simultaneamente a maior parte do tempo.

Os seguintes arquivos estão disponíveis:

controlador3.c    Exemplo do programa controlador a ser feito

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

envasilhamento3.c    Simulador da planta

Escrever um novo controlador3.c que seja automático (o fornecido é manual) e que
maximize a produtividade da planta, considerando a produção de um lote de N garrafas.

Comandos do controlador manual:
e - avança esteira
a - liga atuador
b - liga a bomba
t - liga o tampador
r - liga o robô

Todos eles desligam após realizar um ciclo de trabalho.

As rotinas do tipo acionaXYZ retornam -1 quando o dispositivo
está em operação, neste caso um novo pedido de acionamento é
ignorado até que o dispositivo retorne para o estado de repouso.


T2 - Trabalho sobre sincronização de relógios e mensagens via sockets

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 udpcliente2006.c e
udpservidor2006.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 sincronizar o seu relógio com o relógio do servidor, através de 3 trocas de mensagens:
  
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.
Passo 2) Cliente faz um LEHORA e obtém a hora do servidor, acrescenta o atraso estimado para
a rede e acerta o seu relógio pelo relógio do servidor.
Passo 3) Cliente faz um TESTE e calcula o erro residual entre o seu relógio e o relógio do servidor,
após a sincronização do seu relógio e considerando o atraso na rede.

Realizar 4 experiências:

Experiência 1) Medir a diferença entre os relógios de dois computadores, sem fazer sincronização.

Experiência 2) Sincronizar o relógio de um cliente com um servidor e medir o erro residual.

Experiência 3) Medir o erro residual sucessivamente, em intervalos de 30 segundos.

Experiência 4) Sincronizar o relógio do computador B com o relógio do computador A, medir erro
residual. Sincronizar o relógio do computador C com o relógio do computador A, medir erro residual.
Finalmente, medir o erro entre os relógios dos computadores B e C sem fazer sincronização.
  
Obs 1- O atraso na rede é variável, fazer várias medições e obter a média.
  
Obs 2- Se alterar o relógio do computador for uma operação restrita, criar uma função no programa
le_relógio_corrigido que implementa um mecanismo de correção.
  
Obs 3 - 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 sobre tabelas e pthreads

Implementar uma tabela hash na forma de um módulo (arquivo .c separado), o qual exporta
as funções de acesso "inserir", "consultar" e "remover". Este módulo deve ser implementado
seguindo a filosofia dos monitores, ou seja, deve usar variáveis mutex para garantir
exclusão mútua entre diferentes threads que chamam estas rotinas simultaneamente. Além disto,
quando uma thread chama a rotina "remover" mas o ítem em questão não existe na tabela,
ela fica bloqueada até que o ítem seja inserido e então possa ser removido. Usar para isto uma
variável condição.
   
Não usar recursividade na solução. Acordar uma thread bloqueada somente quando a condição
esperada estiver satisfeita, mesmo quando várias threads estão esperando pelo mesmo registro ou
por registros diferentes. Usar um pseudo-registro para saber quando existe uma thread
esperando pela inserção de um dado registro. Este pseudo-registro pode ter um pointer para
a variável condição na qual a thread esperando está bloqueada.

Os ítens na tabela são do tipo abaixo, usar a matrícula como chave. É obrigatório usar o tratamento
de colisão apresentado no exemplo tabhash.c da página da disciplina.

struct aluno{
        long matricula;
        char nome[40];
        double media;
        char sexo;
        int ingresso;
        pthread_cond_t *esperando;
};

Implementar um segundo módulo (outro arquivo .c), onde são criadas 9 threads recorrentes,
as quais fazem inserções, remoções e consultas variadas. Usar "sleep" para testar se uma
remoção antes da inserção efetivamente bloqueia a thread.

Todo o trabalho deve ser feito em C, no Linux, usando a biblioteca das pthreads.


T4 - Trabalho do controlador completo

Implementar o controle do sistema descrito aqui.
 
Simulador é chamado com:
      java -jar aquecedor2006_1.jar
escuta a porta 4545.

Aceita os 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 usando a biblioteca de pthreads que inclua
as seguintes funcionalidades:

- Laços de controle como tarefa periódica para temperatura e nível;
- Alarme associado com valores das variáveis amostradas;
- Armazenagem em arquivo de leitura periódicas dos sensores;
- 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 em si deve ficar no arquivo "controle.c" e deve ser composto por várias threads
que colaboram entre si através de variáveis compartilhadas.

A planta será simulada por um outro programa, cujo código executável será
fornecido. A comunicação entre o controle e o simulador será através
de sockets UDP/IP.

Avaliação composta por:
    - Código fonte;
    - Texto explicando qual a função de cada thread e quais variáveis compartilhadas cada uma acessa;
    - Apresentação individual do trabalho.

Outros requisitos:
    - Usar mutex para proteger as variáveis compartilhadas;
    - Usar variáveis condição para liberar as threads de alarme;
    - Tarefas periódicas implementadas com precisão e não com sleep fixo (ver apostila na página da disciplina);
    - Período do controlador de temperatura deve ser 150ms;
    - Período do controlador de nível deve ser 200ms;
    - 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;
    - Dados são gravados efetivamente no disco a cada 3 segundos, pode ser sleep simples.

Alguns aspectos para a composição da nota do trabalho do controlador:
- Fez no Linux, em C, usando a biblioteca das pthreads ?
- Foi usado um mutex para cada estrutura compartilhada ?
- A aplicação possui alarme disparado via variável condição ?
- A aplicação apresenta valores dos sensores na tela ?
- A aplicação possui laços de controle para temperatura e nível ?
- A aplicação acessa teclado durante a execução do controlador, afeta valor de referência ?
- A aplicação grava leituras em arquivo utilizando buffer duplo e thread própria ?
- As tarefas de controle são realmente periódicas ?
- Foram utilizados os períodos corretos para controle e gravação de arquivos ?
- Elegância do design da solução e legibilidade do código.