Sistemas de Tempo Real com Três Threads

Prévia do material em texto

Sistema de Tempo Real com Três Threads
Número do Grupo
201016725 – Estêvão Naoto Rosa Suzuki
20961011 – Pedro Chagas Pestana
20565200 – Thiago Menezes 
Sistema de tempo Real Tolerantes à Falha–Prof. Fernando Chagas
Resumo
Apresentaremos a implementação do microcontrolador ARDUINO UNO para demonstrar o escalonamento de atividades de um sistema com dois receptores e dois atuadores utilizando a política adotada pelo sistema RTOS – Real-Time Operating System – e o framework Cheddar 2.1 para os testes de viabilidade das operações em tempo real. Os dois receptores – dois sensores de temperatura LM35 – e os dois atuadores – dois LED’s – serão conectados à placa Arduino para recepção dos dados de presença para alteração e controle da temperatura da água do chuveiro em até 35°C.
Palavras-chave: Sistema, Tempo Real, Microcontrolador, Escalonamento, framework, receptor, atuador.
Introdução
Sistemas de Tempo Real são sistemas computacionais que monitoram, respondem e controlam o ambiente externo. Nesse caso o ambiente se limita a dois sensores, dois atuadores e um microcontrolador. Nesse estudo de caso utilizaremos o RTOS: um software que gerencia os recursos de um sistema computacional com o objetivo de garantir a execução de todos os eventos dentro das suas respectivas restrições temporais e da forma mais eficiente possível.
Um sistema de tempo real deve ser previsível, interativo, preemptivo, e escalonável, possuir deadlines específicos, restrições temporais, correções lógicas e temporais e concorrência, para atender aos eventos sem perda de rendimento do processador.
RTOS – Sistema Operacional de Tempo Real em atuação:
O Sistema Operacional de Tempo Real interage com as interfaces de entrada e saída – nesse caso, sensores e atuadores – e mantêm o controle e envia respostas aos estímulos captados pela atuação do ambiente em tempo hábil para execução das tarefas escalonadas.
Previsibilidade: 
Capacidade de antecipar o comportamento do sistema independente das falhas, sobrecargas, variações de hardware, exceções etc.
Interatividade:
 Define a relação entre o ambiente e o sistema, quanto maior a habilidade do sistema de permitir a influência do ambiente, maior será a interatividade.
Escalonabilidade: 
Define-se pela capacidade sistêmica de ordenar as tarefas enfileiradas em estado de pronto – conjunto de tarefas disponíveis, em fila, para ocupação do processador –. É dependente das ações do Escalonador – componente responsável por produzir escalas de tarefas realizáveis, garantindo o cumprimento das restrições temporais das tarefas de tempo real – em tempo de execução pela gestão da Política de Escalonamento do processador. 
O Escalonamento pode ser definido como Estático ou Dinâmico. Quando o cálculo de escala utiliza parâmetros fixos – atribuídos às tarefas do conjunto em tempo de projeto – o escalonamento é Estático. Quando os parâmetros mudam de acordo com o tempo de execução com a evolução do sistema, o escalonamento é Dinâmico.
O Escalonamento de Tarefas Periódicas apresentam um melhor desempenho e flexibilidade do sistema por possuir prioridades atribuídas às tarefas do conjunto, que por sua vez, são derivadas de suas restrições temporais. Pode ser classificada em três tipos:
Taxa Monotônica:
Possuem prioridade de tarefas fixa, são dirigidos à prioridade e produz escalas de tempo a partir de escalonadores preemptivos – as prioridades são maiores para as tarefas de menor período –.
As tarefas definidas nesse modelo são:
As tarefas são periódicas e independentes – restritivo.
O deadline de cada tarefa coincide com seu período – restritivo.
O tempo de computação de cada tarefa é conhecido e constante –cenário de pior caso.
É nulo o tempo de chaveamento entre as tarefas.
Figura 1 - Análise de Escalonabilidade. Ci é o tempo de computação, Pi é o período e n o número de tarefas.
Fonte - http://www.das.ufsc.br/~romulo/livro-tr.pdf.
Verificação de Escalonabilidade sob a política de taxa monotônica:
Figura 2 - Utilização de tarefas periódicas.
Fonte - http://www.das.ufsc.br/~romulo/livro-tr.pdf.
Diagrama de Gantt gerando a Escala:
Figura 3 - Escala de Taxa Monotônica.
Fonte - http://www.das.ufsc.br/~romulo/livro-tr.pdf.
Deadline Monotônico:
Esse tipo de escalonamento estende o conceito do escalonamento Taxa Monotônico por possuir os deadlines relativos a cada tarefa menores ou igual aos períodos das tarefas. Essa política de escalonamento define atribuição estática de prioridades, dependentes dos deadlines relativos das tarefas: quanto maior o deadline, menor a prioridade. Novamente o Escalonamento é estático e online.
As tarefas definidas nesse modelo são:
As tarefas são periódicas e independentes – restritivo.
O deadline de cada tarefa é inferior ou igual ao seu período – restritivo.
O tempo de computação de cada tarefa é conhecido e constante –cenário de pior caso.
É nulo o tempo de chaveamento entre as tarefas.
Figura 4 - Escala Deadline Monotônico
Fonte - http://www.das.ufsc.br/~romulo/livro-tr.pdf.
Figura 5 - Cálculo de Escalonabilidade do Deadline Monotônico. Ri é o tempo máximo de resposta da tarefa com valor inicial zero. A Resposta deve ser menor que o Deadline. Pi é o período e Ci é o tempo de computação.
Fonte - http://www.das.ufsc.br/~romulo/livro-tr.pdf.
Earliest First:
Define-se pelo escalonamento baseado em prioridades dinâmicas, produz a escala de tempo em tempo de execução por um escalonador preemptivo dirigido a prioridades dinâmicas e escalonamento On-line – escalas em tempo de execução –. Esse processo de Escalonabilidade permite um maior volume de casos e, em contrapartida, possui maior complexidade de implementação.
As tarefas definidas nesse modelo seguem a mesma diretriz das tarefas de Taxa Monotônica:
As tarefas são periódicas e independentes – restritivo.
O deadline de cada tarefa coincide com seu período – restritivo.
O tempo de computação de cada tarefa é conhecido e constante –cenário de pior caso.
É nulo o tempo de chaveamento entre as tarefas.
Figura 6 - Teste suficiente e necessário para Earliest Deadline First.
Fonte - http://www.das.ufsc.br/~romulo/livro-tr.pdf.
Para um conjunto de tarefas escalonável em Earliest Deadline First não será possível escalonar o mesmo processo em Taxa Monotônica.
Figura 7 - Comparação de Escalonabilidade entre a Earliest Deadline First e Taxa Monotônica
Fonte - http://www.das.ufsc.br/~romulo/livro-tr.pdf.
Preempitividade:
Capacidade de interromper uma tarefa em execução por outra tarefa de maior prioridade sem perdas de desempenho sistêmico. Para ocorrer, precisa-se definir as prioridades de cada thread no sistema.
Deadlines:
Define-se pelo tempo crítico de execução das tarefas escalonadas – em estado de pronto –, ou seja, limite sobre o tempo absoluto ou relativo no qual a computação deve completar-se. Cada tarefa possui um deadline específico com a prioridade única para ser realizada no período devido e não haver perda de eficiência do sistema.
Restrições Temporais:
São distinções qualitativas de Sistema de Tempo Real, características que devem ser respeitadas para o comportamento temporal desejado. Ao concluir uma tarefa após o deadline, têm-se dois tipos de tarefas classificadas como Tolerantes (não-estritos) ou Rigorosos (estritos):
Tolerantes:
Sistemas Tolerantes de Tempo Real consideram o sucesso mesmo ao violar algumas restrições temporais. Essas violações implicam na diminuição de desempenho do sistema e os custos dessas falhas não são muito significativos.
Rigorosos: 
Sistemas Rigorosos de Tempo Real devem satisfazer a todas as restrições temporais, caso não ocorra, o sistema falha. As restrições são deterministas – expressas em números exatos ou fixos – e , quando não satisfeitas, podem causar falhas catastróficas no sistema.
Correções Lógicas e Temporais: 
Integridade dos resultados e valores de tempo em que são produzidos, respectivamente.
Concorrência:
Modelo de representação lógica para definir, a partir da implementação de interlocaçãode atividades em um único processador, o melhor caminho definir dentre a simultaneidade das ações paralelas para a execução de todas as tarefas respeitando as restrições temporais. 
Aspectos funcionais de STOR – Sistemas Operacionais de Tempo Real
São requisitos funcionais de STOR a escalonabilidade e eficiência do sistema, mantendo-se o hardware e valorizando a atuação do sistema simplificando o acesso aos periféricos e funções de gerenciamento de memória e processador. São definidas como Tarefas e Threads, que necessitam de comunicarem-se entre si, de tratadores de dispositivos e interrupções e temporizadores.
Tarefas e Threads 
As Tarefas são abstrações que possuem um espaço de endereçamento próprio, seja compartilhado ou não, formando o contexto de execução constituído pelo conjunto de registradores, ou seja, um conjunto de recursos. As Threads são tarefas leves que os registradores de processador possuem para controlar o contexto de execução, herdados da tarefa que se hospeda na thread, ou seja, fluxo de execução específico das tarefas. 
Um programa concorrente possui várias tarefas interativas executadas simultaneamente. Essas tarefas se comunicam seja sincronizando dados ou trocando informações. O tempo de chaveamento do processador e as várias tarefas é definido por um conjunto de atributos – arquivos abertos, direitos de acesso –, o tempo para mudar o conjunto de atributos em vigor. Ao utilizar as Threads, melhora-se a performance do sistema, pois uma thread agrega várias tarefas e ocupa o meso endereçamento de memória.
Figura 8 - Exemplificação dos Estados de uma Thread
Fonte - http://www.das.ufsc.br/~romulo/livro-tr.pdf.
Um programa concorrente possui trovas de mensagens e variáveis compartilhadas. A comunicação entre threads ocorre a parti da leitura e escrita do conjunto de dados compartilhado. A sincronização deve ser explícita: semáforos, monitores, etc. 
Configuração do Arduino UNO: Implementação e Análise de Teste de Escalonabilidade
O Arduino UNO foi desenvolvido na Itália por Massimo Banzi e David Cuartiellis, com a finalidade de introduzir, didaticamente, conceitos de eletrônica e programação de computadores. 
Consiste em uma placa de controle de entrada de dados (IN) – sensores – e saída de dados (OUT) – como motores e leds –. Possui componentes como: cristal oscilador de 16Mhz, um regulador de tensão de 5V, botão de reset, plugue de alimentação, pinos conectores, LEDs de verificação do funcionamento, porta USB que fornece alimentação enquanto estiver conectado ao computador, e regulador de tensão de que fornece alimentação variável de 7V a 12V, enquanto estiver desconectado.
De forma resumida, o Arduino UNO é um microporcessador com memória Flash – preserva os dados armazenadoa a longo prazo –, EEPROM – Memória programávael e não volátil – e SRAM – memória volátil de acesso aleatório –, possui características de microcontrolador – processador, memória e conexão com periféricos – capaz de receber variáveis do ambientes pelos terminais de entrada – sensores –, processar a informação e controlar / acionar o componente eletro-eletrônico conectado ao terminal de saída – atuadores –.
O Arduino possui inúmeras vantagens:
recebe as informações de várias formas, que são traduzidas para a linguarem Wiring – linguagem de programação baseada em C / C++ –. 
Baixo custo – comparado a placas programáveis mais sofisticadas –.
Software Multiplataforma – Multiplataforma: Windows, Linux, MAC –.
Estrutura de programação livre e apoio online.
Figura 9 - Placa Arduino UNO
Fonte: http://labdegaragem.com/profiles/blogs/tutorial-como-acender-leds-pelo-serial-monitor-com-arduino
Implementação dos sensores de temperatura LM35
Nesse estudo de caso utilizaremos dois sensores de temperatura LM35 – sensor de precisão desenvolvido pela National Semicondutores, apresenta saída de tensão linear variável de 0V a 5V proporcional à temperatura de leitura –, acoplados ao Arduino para medir as temperaturas de entrada no sistema, em seguida, compara-se o valor lido com o valor de um parâmetro especificado no código. Após a comparação dos valores, caso esse valor lido seja maior do que o parâmetro envia-se um sinal de ativação da porta lógica digital 13 (declarada na implementação do sistema). Em seguida, comparam-se novamente os valores – lido e de parâmetro –, no segundo sensor de temperatura, para ativação da porta lógica digital 12 (declarada na implementação), caso o valor lido seja menor que o valor de parâmetro. 
Representação da primeira Thread: 
A Finalidade da primeira thread é a leitura da temperatura do sensor1 a cada 10 milissegundos.
A prioridade é alta: valor 1.
//------------------------------------------------------------------------------
// Thread 1, alta prioridade para ler o sensor de temperatura 1.
//------------------------------------------------------------------------------
// 64 byte stack beyond task switch and interrupt needs.
static WORKING_AREA(waThread1, 64);
static msg_t Thread1(void *arg) {
 // Read data every 10 ms.
 systime_t wakeTime = chTimeNow();
 while (1) 
 {
 // Add ticks for 10 ms.
 wakeTime += MS2ST(10);
 chThdSleepUntil(wakeTime);
	//colocando nas variaveis os valores lidos pelos sensores
 int tmpX = analogRead(X_PIN);
 int tmpY = analogRead(Y_PIN);
 // Lock access to data.
 chMtxLock(&dataMutex);
 sensor1 = tmpX;
 sensor2 = tmpY;
 // Unlock data access.
 chMtxUnlock();
 }
 return 0;
}
Representação da segunda Thread:
A Finalidade da segunda thread é a análise da temperatura do sensor 1. Caso a temperatura lida seja maior que a temperatura imputada no sistema (22°C), a porta lógica digital 13 será ativada.
A prioridade é a menor: valor 3.
//------------------------------------------------------------------------------
//Thread 2, Avaliando a temperatura do sensor 1
//------------------------------------------------------------------------------
static WORKING_AREA(waThread2, 128);
static msg_t Thread2(void *arg) 
{
 systime_t wakeTime = chTimeNow();
 while (1)
 {
 wakeTime += MS2ST(400);
 chThdSleepUntil(wakeTime);
 if(sensor1 > 22)
 {
 digitalWrite(P_13, HIGH);
 }
 else
 {
 digitalWrite(P_13, LOW);
 }
 //
 }
 return 0;
}
Representação da terceira Thread:
A Finalidade da terceira thread é a análise da temperatura do sensor 2. Caso a temperatura lida seja menor que a temperatura imputada no sistema (40°C), a porta lógica digital 12 será ativada.
A prioridade é média: valor 2.
//------------------------------------------------------------------------------
// thread 3, Avaliando a temperatura do sensor 2
//------------------------------------------------------------------------------
static WORKING_AREA(waThread3, 128);
static msg_t Thread3(void *arg) 
{
 systime_t wakeTime = chTimeNow();
 while (1)
 {
 wakeTime += MS2ST(400);
 chThdSleepUntil(wakeTime);
 if(sensor2 < 40)
 {
 digitalWrite(P_12, HIGH);
 }
 else
 {
 digitalWrite(P_12, LOW);
 }
 //
 }
 return 0;
}
Teste de Escalonabilidade do sistema:
O Teste de Escalonabilidade define – por meio de algoritmos preemptivos, baseados em prioridade – que as tarefas tenham relações de precedência entre si ou que os deadlines assumam valores arbitrários. Considerando os cenários de pior caso, com os piores casos de tempo de computação (chamado Capacidade no framework Cheddar) os testes criados chegam próximo ao Instante Crítico – pior caso de ocorrência de tarefas na fila de pronto do processador –, no qual todas as tarefas implementadas estão prontas para ocupar o processador.
O framework Cheddar permite a verificação da Escalonabilidade das tarefas de um sistema em tempo real. Foi desenvolvido pela Ada Framework para estudos acadêmicos de comportamento temporal das atividades com resposta temporal, taxa de execução atendendo às deadlines descritos em cada atividade. A simulaçãoconsiste na comparação da utilização do processador em um determinado limite de tempo.
Para executar os testes precisa-se definir:
Deadlines
Períodos
Tempo de Execução – Capacidade
Figura 10 - Desing de Simulação
Com auxílio do framework Cheddar, é possível verificar se alguma atividade atingirá o deadline de uma thread sem executar as atividades da mesma, ou não finalizará a execução das tarefas no período específico.
A Política de Escalonamento utilizada nesse caso de teste será a Taxa Monotônica, pois as tarefas são periódicas, independentes, os deadlines de cada thread coincidem com os respectivos períodos, o tempo de computação é constante e conhecido e o tempo de chaveamento entre as tarefas é nulo.
Exemplificação do Teste de Escalonabilidade.
Fonte 1 - Teste de Escalonabilidade de Taxa Monotônica
Conclusão
A utilização das características de Sistemas de Tempo Real objetiva-se pela melhoria da performance do processador de acordo com as políticas de escalonamento empregadas para diminuição de falhas e tolerância às exceções. Para tanto, necessita-se definir a comunicação e sincronização entre as tarefas. No estudo de caso apresentado, obteve-se êxito na Política de Escalonabilidade de três threads com diferentes prioridades. Essas concorreram pela utilização do processador e foram executadas dentro do período delimitado, respeitando as restrições temporais implementadas no sistema.
Bibliografia Consultada:
[1] SHAW, ALAN C. Sistemas e Software de Tempo Real. 1ª Ed. 2011, Jonh Wiley and Sons – Universidade de Washington, Editora Bookman 2003.
[2] SANTOS, FERNANDO CHAGAS. Sistema de Tempo Real. Disponível em: <http://fernandochagas.webs.com/str-2013-2>; <https://dl.dropboxusercontent.com/u/68544260/2013-2/STR/SD03-STR_EscalonamentoTempoReal.pdf>; <https://dl.dropboxusercontent.com/u/68544260/2013-2/STR/SD06-STR_ProjetoTempoReal.pdf>; < https://dl.dropboxusercontent.com/u/68544260/2013-2/STR/SD02-STR_Introducao.pdf> ; <https://dl.dropboxusercontent.com/u/68544260/2013-2/STR/SD03-STR_EscalonamentoTempoReal.pdf>. Acesso em: 25 Nov. 2013.
[3] Autor desconhecido. Como Fazer as Coisas. Disponível em: <http://www.comofazerascoisas.com.br/projeto-arduino-com-display-lcd-sensor-de-temperatura-e-sensor-de-luz.html>. Acesso: 12 Nov. 2013.
[4] The Cheddar project : a free real time scheduling analyzer, Disponível em : <http://beru.univ-brest.fr/~singhoff/cheddar/>. Acesso: 24 Nov. 2013. Última atualização: Set. 2011.
[5] ANTÔNIO PEDRO; SANTOS, MAX; RENÓ, DEMÉTRIO. Análise de Escalonabilidade de tarefas no Kernel de Tempo Real S.HA.R.K. Disponível em : <http://shark.sssup.it/contrib/antoniopedro/ArtigoCBComp.pdf>. Acesso: 20 Nov. 2013.
[6] COVACEVICE, ALEKSEI VICTOR TREVELIN. Sistemas Operacionais de Tempo-Real. Unicamp. Outubro 2007. Disponível em: <http://www.ic.unicamp.br/~islene/2s2007-mo806/slides/rt.pdf>. Acesso: 06 Nov. 2013.
[7] FARINES, JEAN-MARIE; FRAGA, JONI DA SILVA; de OLIVEIRA, RÔMULO SILVA. Sistemas de Tempo Real. Departamento de Automação e Sistemas – Universidade de Santa Catarina. Julho 2000. Disponível em: <http://www.das.ufsc.br/~romulo/livro-tr.pdf>. Acesso: 08 Nov. 2013.
[8] MINAKAWA, RICCIELI; TIOSSO, LUIZ EDUARDO; dos SANTOS , WELLINGTON OLIVEIRA; da SILVA, LUCAS TSUTSUI. Introdução ao Arduino. Departamento de Talentos em Computação. Universidade Federal do Mato Grosso do Sul. 2012. Disponível em: <http://destacom.ufms.br/mediawiki/images/9/9f/Arduino_Destacom.pdf>. Acesso: 18 Nov. 2013.
[9] F. SINGHOFF, J. LEGRAND, L. NANA, L. MARC´E. Cheddar : a Flexible Real Time Scheduling Framework. Universidade de Brest. 14-18 Nov. 2004. Atlanta, Georgia. Acesso: 26 Nov. 2013