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.
Um sistema de coleta de
dados é composto por um computador central e quatro
instrumentos
de campo.
Os instrumentos estão ligados ao computador através de uma rede local
UDP/IP. Os atrasos na rede
variam de instrumento para instrumento.
Cada instrumento opera
de forma autônoma, fazendo uma medição a cada segundo cheio, conforme o
seu relógio local. As medições são armazenadas temporariamente no
próprio instrumento, formando um
histórico (log) local.
O simulador fornecido
recebe como parâmetro o número da porta base. Cada instrumento i escuta
a porta "porta base + i".
O computador deve
periodicamente acessar cada instrumento e ler cada um dos logs locais. O
computador
deve entao consolidar todas as medições em um hiostórico global.
O relógio do computador
está sincronizado com a UTC, mas não existe sincronização entre os
relógios
dos instrumentos e a UTC.
Cada instrumento opera
no modelo cliente/servidor, aceitando os seguintes comandos:
"p" - Retorna a hora
local no instrumento (segundos e nanosegundos).
"a" - Apaga o último log
lido pelo computador, retorna "a".
"l" - Lê o último log
disponibilizado, retorna o log no formato
25453=25427.572428
25454=25428.571429
25455=25429.570430
25456=25430.569431
onde o primeiro valor
(int) é o segundo local na hora do instrumento
e o segundo valor
(double) é a medida obtida por aquele instrumento.
OBJETIVO:
Escrever o programa em C
sobre Linux para rodar no computador central o qual deve, para cada
instrumento:
- determinar o atraso na
rede
- determinar a diferença
entre os relógios
- esperar 10 segundos
- determinar a nova
diferença entre os relógios
- calcular o drift-rate
- obter o log
- corrigir os tempos de
medição para a hora padrão
Programas relacionados:
Implementar a simulação
em tempo real de um sistema físico qualquer,
proposto pelos alunos. O sistema precisa ter pelo menos duas variáveis
físicas sensoriadas e dois atuadores através dos quais elas podem ser
afetadas.
Pode ser multivariável.
A simulação ocorre no domínio do tempo. Os alunos deverão entregar um
desenho mostrando os aspectos físicos da planta, assim como a descrição
da sua dinâmica no domínio do tempo. Também precisam documentar a
interface da instrumentação (comandos aceitos).
Usar como base os programas
Aquecedor2006_2.java e Aquecedor2008_1.java
os quais usam a biblioteca
cp.jar
O aquecedor 2006/2 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
O aquecedor 2008/1 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
public Atraso(int iterações)
public ComparadorUmaEntrada (double inferior, double superior)
-1 <inferior
0 entre
+1 > superior
public ControladorPI(double inicial, double ganProp, double ganInteg)
public Derivador(double gan)
public Diferenca()
public Diferenca( double offset)
public DiferencaComGanho(double geMais, double geMenos)
public DisplayConsole(String s)
public DisplayMensagem( javax.swing.JTextArea am, String s)
public Divisor( double ganhoNumerador, double ganhoDenumerador)
public GanhoProporcional(double ganho)
public GeradorConstante(double valor)
public GeradorDegrau(long atraso, double valor)
public GeradorParametro(String nome, double minimo, double inicial,
double maximo, java.awt.Container c)
public GeradorPulso(long atraso, long duracao, double valor)
public GeradorRampa(long atraso, double inclinacao)
public GeradorRuido( long atraso, long duracao, double amplitude)
public GeradorSenoide( long atraso, double amplitude, double frequencia)
public GeradorTrem(long atraso, long duracao, double valor)
public Histerese(double histerese)
public Integrador(double inicial, double ganho)
public PrimeiraOrdem(double Yinicial, double numerador, double
denominador)
public Produtorio(double v1, double v2, double v3, double v4)
public Saturacao(double min, double max)
public Somador()
public Somatorio( double g1, double g2, double g3, double g4)
public ZonaMortaHorizontal(double zm)
public ZonaMortaVertical(double zm)
javac -cp cp.jar Aquecedor2006_2.java
java -classpath .:cp.jar
Aquecedor2006_2 12345
O propósito dos comandos via UDP é acessar a instrumentação da
planta simulada. Mostrar através de comandos UDP que a simulação feita
responde corretamente. Para isto, usar um programa cliente UDP
auxiliar qualquer, como aqueles fornecidos como exemplo.
Implementar o controle e a supervisão do sistema
criado no T2 por OUTRO GRUPO.
A planta do T2 deve possuir instrumentação embutida e
aceitar comandos para
acesso aos sensores e atuadores.
Implementar um programa em C no Linux, usando a biblioteca de pthreads.
O programa CONTROLADOR deve incluir as seguintes funcionalidades de
controle e
supervisão:
- Laço de controle como tarefa periódica;
- Detecção de valores fora do intervalo de valores válidos, geração de
alarme;
- Informações na tela sobre a situação corrente;
- Entrada através do teclado dos valores de referência para a planta;
- Armazenagem periódica dos valores lidos em arquivo, juntamente com um
carimbo de tempo.
Avaliação composta por:
- Código fonte;
- Texto explicando qual a função de cada thread,
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 thread de
alarme;
- Tarefas periódicas implementadas com
clock_nanosleep e não com sleep fixo;
- Período do controlador menor que 100ms, compatível
com a planta em questão;
- Atualização da tela pode ser com sleep simples de 1
segundo;
- Usar buffer duplo para a gravação de dados em
arquivos, a escrita no disco é feita
por thread própria.
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 ?
- A aplicação acessa teclado durante a execução, 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 ?
- Existe algum warning na compilação ?
- Elegância do design da solução e legibilidade do código.