Anlise do tempo de resposta de polticas de escalonamento com UPPAAL 4.

1
Jssyka Flavyanne Ferreira Vilela1, Jadsonlee da Silva S1 Colegiado de Engenharia da Computao Universidade Federal do Vale do So Francisco (UNIVASF) Av. Antonio Carlos Magalhes, 510 Santo Antonio 48.902-300 Juazeiro, BA Brasil
jessykaflavyanne@gmail.com, jadsonlee.sa@univasf.edu.br
1

Abstract. The analysis of response times of tasks in real-time systems is essential to verify the schedulability of these systems. In this work we proposed models for the evaluation of response times developed in the tool UPPAAL for the scheduling policies FPS and EDF. In addition, the proposed models were used to evaluate the response times of a given set of tasks. Resumo. A anlise dos tempos de resposta de tarefas em Sistemas em Tempo Real fundamental para verificar a escalonabilidade desses sistemas. Nesse trabalho so propostos modelos de verificao dos tempos de respostas desenvolvidos na ferramenta UPPAAL para as polticas de escalonamento FPS e EDF. Alm disso, os modelos propostos foram utilizados para avaliar os tempos de resposta de um determinado conjunto de tarefas.

1. Introduo
Os Sistemas em Tempo Real (STRs) so sistemas de computao que monitoram, respondem ou controlam um ambiente externo (SHAW, 2001). Esse ambiente est conectado ao sistema de computao atravs de sensores, atuadores e outras interfaces de entrada-sada (SHAW, 2001). Dentre as inmeras aplicaes e exemplos desse tipo de sistema pode-se citar: sistemas de controle de veculos, metrs, navios, ferrovias, trfego areo, telefone, rdio e comunicaes por satlite, sistemas mdicos, etc. Os STRs geralmente contm dois tipos de processos: peridicos ou espordicos (SHAW, 2001). Os processos peridicos so ativados de forma regular entre intervalos fixos de tempo. Por outro lado, processos espordicos so dirigidos a eventos, eles so ativados por um sinal externo ou uma mudana de alguma relao (SHAW, 2001). Esses sistemas so normalmente modelados por um conjunto de tarefas que utilizam recursos computacionais limitados e compartilhados para a realizao de atividades especficas sujeitas a requisitos de tempo. Nesse contexto, o problema de escalonamento em tempo real consiste em determinar quando e por quanto tempo uma tarefa deve ser executada. A ferramenta UPPAAL foi desenvolvida para o projeto, verificao, simulao de sistemas em tempo real que podem ser modelados como rede de autmatos temporizados estendido com variveis inteiras e tipos de dados definidos pelo usurio.

O objetivo deste trabalho verificar os tempos de resposta para um conjunto de tarefas de acordo com duas polticas de escalonamento (Fixed Priority Scheduling (FPS) e o Earliest Deadline First (EDF)) atravs da ferramenta UPPAAL. Os tempos de resposta foram analisados para verificar se as tarefas satisfazem suas restries de prazo-limite considerando um processador para a execuo das tarefas. Este artigo est estruturado da seguinte forma: a Seo 2 apresenta algumas definies e exemplos de polticas de escalonamento, na Seo 3 so descritas as funcionalidades da ferramenta UPPAAL, na Seo 4 so apresentados os modelos desenvolvidos no UPPAAL para anlise do tempo de resposta das polticas de escalonamento estudadas. Na Seo 5 so apresentados os resultados obtidos para um determinado conjunto de tarefas e, finalmente, na Seo 6 as concluses.

2. Polticas de Escalonamento
Uma poltica de escalonamento (scheduling) um procedimento responsvel por gerenciar a ordenao de tarefas na fila de pronto para execuo no processador. A ordenao segue uma poltica de escalonamento. Nos computadores atuais, utilizado o mtodo round-robin, no qual cada processo recebe uma fatia de tempo do processador (quantum) para executar. A poltica de escalonamento escolhida de forma a aumentar a produtividade do sistema e, ao mesmo tempo, diminuir o tempo de resposta observado pelos usurios. As restries temporais so traduzidas em prioridade de tarefas (SHAW, 2001). Estas podem ser explicitamente atribudas atravs de um atributo prioridade ou podem ser implcitas (SHAW, 2001). Na prioridade implcita, esta varia de acordo com algum critrio, como por exemplo, o instante de liberao, neste caso, quanto mais cedo a ativao, maior a prioridade da tarefa (SHAW, 2001). Quando os processos de um sistema possuem diferentes prioridades, essa prioridade pode ser utilizada para decidir qual processo executado a seguir. Em sistemas sem preempo, o processo que chega fila do processador respeita o ciclo do processador em andamento, sendo inserido na fila normalmente. O processo em execuo somente libera o processador no final do ciclo do processador. Por outro lado, nos sistemas com preempo, se o processo que chegar for mais importante que o processo em execuo, ou seja, possui maior prioridade, o processo recebe o processador imediatamente. Como exemplos de algoritmos de escalonamento existem o Fixed Priority Scheduling (FPS) e o Earliest Deadline First (EDF). 2.1 Fixed Priority Scheduling O algoritmo de escalonamento de prioridade fixa (Fixed Priority Scheduling FPS) tem sido amplamente estudado e utilizado em uma srie de aplicaes, principalmente devido a sua programao em tempo de execuo simples, resultando em pequeno overhead (DOBRIN; OZDEMIR; FOHLER, 2000).

Segundo esse algoritmo, cada tarefa possui um atributo extra denominada atributo e as tarefas que esto no estado pronto so executadas de acordo com a maior prioridade (DAVID et al., 2009). 2.2 Earliest Deadline First Segundo David et al. (2009), neste algoritmo, as tarefas prontas so adicionadas a uma lista ordenada e executadas de acordo com o menor deadline. Assim, a tarefa que possuir o prazo-limite (futuro) mais cedo tem a maior prioridade (SHAW, 2011).

3. UPPAAL
UPPAAL uma ferramenta, desenvolvida em conjunto com a Universidade Uppsala e Universidade Aalborg, para verificao de sistemas em tempo real (BEHRMANN, DAVID, LARSEN, 2011). A ferramenta foi projetada para verificar sistemas que podem ser modelados como redes de 1 autmatos temporizados com as seguintes caractersticas adicionais (BEHRMANN, DAVID, LARSEN, 2011): Expresses: so usadas com os seguintes rtulos: o Guarda: uma expresso particular que satisfaz as seguintes condies: no possui efeito colateral, avalia a expresso e retorna um valor booleano; somente clocks, variveis inteiras e constantes so referenciados (ou matrizes destes tipos); clocks e diferenas no clock so apenas comparadas em relao a expresses inteiras; guardas sobre relgios so essencialmente conjunes (disjunes so permitidas sobre as condies inteiro). o Sincronizao: o rtulo de sincronizao pode ser na forma de expresso!, expresso? ou um rtulo vazio. A expresso deve ser sem efeito colateral, avaliar um canal e s se referir a nmeros inteiros, constantes e canais. o Atribuio: uma lista de expresses separada por vrgulas com um efeito colateral; expresses devem se referir apenas a relgios, variveis inteiras, constantes e atribuir apenas valores inteiros para clocks. o Invariante: uma expresso que satisfaz as seguintes condies: sem efeito colateral; somente clocks, variveis inteiras e constantes so referenciadas; um conjunto de condies da forma x <e ou x <= e, onde x um relgio de referncia e avaliado como um inteiro. Templates: Os autmatos so definidos com um conjunto de parmetros que podem ser de qualquer tipo (por exemplo, int, chan). Estes parmetros so substitudos por um argumento na declarao de processo. Constantes: so declaradas como const nome valor. Constantes, por definio, no podem ser modificadas e deve ter um valor inteiro. Limites de variveis inteiras: so declaradas como int [min, max] nome, onde min e max so os limites inferior e superior, respectivamente.
1

Autmato temporizado uma mquina de estado finito estendida com variveis do tipo clock (relgio).

Guardas, invariantes e atribuies podem conter expresses que variam ao longo do limite das variveis inteiras. Os limites so checados aps a verificao e aqueles que violam o limite so descartados (em tempo de execuo). Se os limites forem omitidos, o intervalo padro de -32.768 a 32768 usado. Canais de sincronizao binrios: so declarados como chan c. Um arco rotulado com c! sincroniza com outro rotulado com c?. Um par de sincronizao escolhido no-deterministicamente se vrias combinaes esto habilitadas. Canais de transmisso: so declaradas como broadcast chan c. Em uma transmisso broadcast, um c! pode sincronizar com um nmero arbitrrio de receptores c?. Qualquer receptor que pode sincronizar no estado atual deve fazlo. Se no houver receptores, em seguida, o remetente pode ainda executar uma ao c!, isto , o envio de transmisso nunca bloqueado. Canais de sincronizao urgentes: so declarados prefixando a declarao do canal com a palavra urgent. Atrasos no devem ocorrer se uma sincronizao de transio em um canal urgente for ativada. Arcos que utilizam canais urgente no podem ter restries de tempo, ou seja, nenhum guarda. Locais urgentes: so semanticamente equivalentes a adicionar um clock x extra, que zerado em todos os arcos e possuem uma invariante x <=0 sobre o local. Por isso, o tempo no incrementado quando o sistema est em um local urgente. Locais comprometidos: so ainda mais restritivos execuo do que os locais urgente. Um estado comprometido, se qualquer um dos locais do estado comprometido. Um estado comprometido no pode atrasar a prxima transio e deve envolver um arco de sada de pelo menos um dos locais comprometidos. Vetores: so permitidos para clocks, canais, constantes e variveis inteiras. Estes so definidos acrescentando-se um tamanho para o nome da varivel, por exemplo: cchan [4]; clock[2]; int [3,5]; e u [7];. Inicializadores: so usados para inicializar variveis inteiras e matrizes de variveis inteiras. Por exemplo, int i: = 2; ou int i [3]: = {1, 2, 3};. Tipos de dados: so declarados com o struct como em C. Tipos personalizados: so definidos com a construo typedef semelhante ao C. O usurio pode definir qualquer tipo personalizado baseado em outros tipos bsicos, tais como registros. Funes de usurio: so definidas globalmente ou localmente para os templates. Os parmetros dos templates so acessados a partir de funes locais. A sintaxe semelhante ao C exceto que no h ponteiro.

3.1 Viso geral do UPPAAL

Segundo (Behrmann, David e Larsen, 2011), a idia do UPPAAL modelar um sistema com autmatos temporizados atravs de um editor grfico, simul-lo para validar se ele se comporta conforme esperado, e finalmente verificar se ele est correto em relao a um conjunto de propriedades. Sua interface est dividida em trs partes principais: editor, simulador e verificador (BEHRMANN, DAVID, LARSEN, 2011).

O editor composto por duas partes: um painel no formato de rvore para acessar os diferentes templates e declaraes e um editor do autmato. A rvore no lado esquerdo proporciona acesso a diferentes partes do sistema: 1. Declarao global: contm variveis globais inteiras, relgios, canais de sincronizao e constantes. 2. Templates: contm declaraes de variveis locais, canais e constantes. 3. Declaraes do sistema: local onde ocorre o instanciamento dos templates. O simulador pode ser usado de forma manual ou aleatria (BEHRMANN, DAVID, LARSEN, 2011). Na forma manual, o usurio pode executar o sistema manualmente e escolher quais as transies executar. Por outro lado, no modo aleatrio, o sistema funciona por conta prpria. No simulador, possvel visualizar todos os automatos do sistema instanciados e locais ativos do estado atual (BEHRMANN, DAVID, LARSEN, 2011). No verificador devem ser adicionadas queries que o UPPAAL verificar se so verdadeiras. O resultado da verificao das propriedades pode ser: propriedade satisfeita (verde), propriedade pode no ser satisfeita (amarelo) e propriedade no satisfeita (vermelho).

4. Modelos Propostos
4.1 Template de Tarefa O template de tarefa, apresentado na Figura 1. Template de Tarefa.Figura 1, foi adaptado do framework proposto por David et al. (2009).

Figura 1. Template de Tarefa.

O template pode ser utilizado tanto para a verificao de tarefas peridicas quanto no-peridicas. Para isto, basta especificar na varivel global do tipo bool denominada Periodica. O template composto pelos seguintes locais: Inicial: a tarefa est esperando o offset a fim de estar pronta para executar. Pronto: a tarefa pode estar tanto executando quanto aguardando para executar no processador. Erro: a tarefa no conseguiu concluir a execuo antes do fim do prazo. Finalizada: a tarefa foi concluda dentro de seu prazo. Concluda: a tarefa executou dentro do prazo, mas no peridica. PeriodoConcluido: a tarefa peridica e fica neste local aguardando chegar o prximo perodo. Quando o template for instanciado, um parmetro constante do tipo identificador deve ser utilizado para informar o cdigo/identificador da tarefa (cod_tarefa). Esse identificador do tipo inteiro que pode assumir o valor zero at o valor mximo de tarefas do sistema subtrado de uma unidade (num_tarefas - 1) e usado para indexar a matriz de tarefas. Cada tarefa possui os seguintes atributos (DAVID, et al., 2009): Offset: tempo decorrido at a ativao da primeira instncia de uma tarefa. Perodo: tempo entre sucessivas instncias das tarefas. Deadline: nmero de unidades de tempo dentro do qual uma tarefa deve terminar a execuo aps sua liberao. Bcet: tempo de execuo do melhor caso da tarefa. Wcet: tempo de execuo do pior caso da tarefa. Prioridade: prioridade da tarefa.

Para cada atributo da tarefa, existe uma funo local para acessar cada atributo na matriz global de tarefas. Assim, a funo offset() retorna tarefa[codigo_tarefa].offset, periodo() retorna tarefa[codigo_tarefa].periodo e assim sucessivamente. Alm disso, cada tarefa utiliza duas variveis do tipo clock denominadas relogio e x, onde relogio representa o tempo desde o incio do perodo atual e x representa o tempo no qual a tarefa foi executada no perodo atual. A varivel x uma varivel local enquanto que relogio global e, assim, indexada por cod_tarefa. Devido ao uso de autmatos temporizados, a taxa de progresso de x definida como zero em todos os locais exceto no local Pronto. Em Pronto, deve-se determinar se a tarefa est atualmente em execuo no recurso. Isto realizado atravs da funo executando(): int[0,1] executando() { return (buffer.elemento[0] == cod_tarefa? 1 : 0); } Por outro lado, relogio est sempre correndo e redefinida a cada perodo, para que quando o tempo exceder o deadline, a tarefa passe para o local Erro. Ao entrar em Pronto, a tarefa atualiza a varivel tarefa_pronta com o cod_tarefa para indicar qual

tarefa tem um sinal para o determinado recurso. Esse cdigo utilizado pelo recurso ao inserir a tarefa na fila para a execuo. As funes novo_periodo() e concluida() so responsveis por atualizar a varivel completa[cod_tarefa] para false e true respectivamente. 4.2 Template de Recurso O template de recurso, apresentado na Figura 2 e adaptado do framework proposto por David et al. (2009), possui como parmetro um valor do tipo bool que o usurio deve utilizar para informar se o escalonador ser preemptivo ou no.

Figura 2. Template de Recurso.

O template possui dois locais principais Livre e EmUso para indicar o estado do recurso. O local Livre indica que o recurso est ocioso e aguardando a chegada de tarefas. O canal pronta utilizado pela tarefa para avisar ao recurso que ela est pronta para execuo. Dessa maneira, o recurso aguarda o recebimento do sinal a partir do local Livre ou em EmUso. Ao receber o sinal, o recurso consulta atravs da funo local fila_vazia() o tamanho de seu buffer. Se o buffer estiver vazio, a tarefa colocada na primeira posio do buffer, caso contrrio, o recurso envia o sinal inserir_tarefa! para o template da poltica de escalonamento que realiza a insero e envia a resposta atravs do canal inserida. A insero de uma tarefa no buffer realizada atravs da funo global inserir_em() que tem como argumentos a posio que a tarefa ocupar no buffer e o cdigo da tarefa. Se houver pelo menos uma tarefa no buffer do recurso, a poltica de escalonamento determina a posio na qual a tarefa pronta ser inserida. A poltica de escalonamento precisa de informaes sobre a tarefa, se o recurso preemptivo, a fim determinar onde colocar a tarefa no buffer. Esta informao transferida atravs da funo set_parametros() que copia esta informao para variveis meta que pode ser lido pelo escalonador.

O recurso permanece no local comprometido esperando o sinal inserida que indica que a tarefa foi inserida no buffer do recurso de acordo com a poltica de escalonamento. O local de espera garante que todas as inseres de tarefa devem ser uma operao atmica. Se a poltica de escalonamento no obedece a esta restrio, o sistema entra em deadlock. Aps inserir a tarefa no buffer, o recurso se move para o local EmUso. O recurso permanece nesse local at que a execuo da tarefa atual seja concluda ou que chegue alguma tarefa no estado de Pronto. No primeiro caso, o recurso remove a tarefa da primeira posio de seu buffer obtida atravs da funo frente() com a funo local retira_fila(). O recurso pode ir para o local Livre se o buffer estiver vazio ou em EmUso caso existam tarefas a serem executadas. No ltimo caso, o recurso repete o processo de insero descrito acima. Esse modelo de recurso pode ser usado para modelar diferentes tipos de recursos e suporta uma maneira fcil de implementar diferentes polticas de escalonamento com mnimo overhead. 4.3 Template das polticas de escalonamento Os templates das polticas FPS e EDF foram adaptados do framework proposto por David et al. (2009). 4.3.1 FPS

O template da poltica de escalonamento FPS apresentado na Figura 3. Esse template aguarda o envio do sinal inserir_tarefa pelo recurso. Ao receber o sinal, este chama a funo inserir_tarefa_no_buffer()definida abaixo: void inserir_tarefa_no_buffer() { identificador cod = param.tarefa; int posicao = (param.preemptivo ? 0 : 1); while (posicao < buffer.tamanho tarefas[buffer.elemento[posicao]].prioridade >= tarefas[cod].prioridade ) { posicao++; } inserir_em(posicao,cod); } Essa funo considera a preempo ao definir o valor da varivel local posio. O valor dessa varivel determinado atravs da consulta a varivel preemptivo da estrutura param. Se o recurso preemptivo, a posio recebe o valor zero (sendo assim, a tarefa possuir maior prioridade), caso contrrio, ser atribudo o valor um. Esta comparao utiliza a pr-condio que o buffer tem pelo menos um elemento quando a funo chamada. Em seguida, a prioridade da tarefa de entrada comparada com as prioridades de cada tarefa no buffer atravs de uma iterao. No caso da tarefa de entrada possuir prioridade mais baixa que todas as tarefas no buffer, a iterao termina por chegar ao &&

final do buffer e insere a tarefa no final do mesmo. Obviamente, este mtodo requer que o buffer esteja ordenado. Contudo, como o mtodo usado para todas as inseres, exceto na primeira, o buffer permanece ordenado. Quando o local de insero estabelecido, a tarefa inserida atravs da funo inserir_em().

Figura 3. Template da poltica de escalonamento FPS.

4.3.2

EDF

O problema da poltica de escalonamento EDF determinar quo longe uma tarefa, i, estar do seu deadline. Para isto, necessrio analisar a diferena entre tarefa[cod_arefa].deadline e relogio[i]. Porm, o UPPAAL no permite esta comparao em chamada de funes j que requer operaes na estrutura de dados de relgio. Por outro lado, UPPAAL permite essas comparaes na expresso de guardas e, assim, a fim de encontrar a posio de uma tarefa de entrada no buffer do recurso, necessrio percorrer o buffer como transies no modelo comparando os deadlines usando guardas. UPPAAL permite apenas subtrao de constantes a partir dos valores de relgio e no o contrrio, por isto a expresso foi reescrita: tarefa[i].deadline relogio[i] < task[j].deadline - relogio [j] relogio [i] tarefa[i].deadline > relogio [j] - tarefa[j].deadline Esse template possui as variveis locais posicao (determina a posio que a tarefa ser inserida no buffer) e cod_tarefa (contm o identificador da tarefa) e funes para manter os parmetros que so transferidos do recurso. A funo lerParametros() define os valores das variveis locais, j a funo resetVars() atribui o valor zero para essas variveis aps a insero da tarefa. A Figura 4 apresenta o template para a poltica EDF. Ao receber o sinal inserir_tarefa do recurso, o template l os parmetros e define a varivel local posicao de acordo com o valor da varivel preemptivo. Em seguida, o deadline da tarefa de entrada comparado com o deadline da tarefa na posio da varivel posicao. Se posicao o ltimo elemento no buffer ou se a tarefa de entrada tem um deadline menor do que a tarefa em posicao, a tarefa de entrada inserida neste lugar no buffer com uma chamada a funo global inserir_em(). Caso contrrio, posicao incrementado e a verificao do deadline

realizada novamente. Em outras palavras, isto uma implementao de um loop while normal.

Figura 4. Template da poltica de escalonamento EDF.

5. Resultados Obtidos O objetivo deste trabalho determinar os tempos de resposta para o conjunto de tarefas cujos atributos so listados na Tabela 1. Todas as tarefas so peridicas e no possuem relao de dependncia entre elas.
Tabela 1. Conjunto de Tarefas avaliado.

Tarefa Offset Perodo Deadline Bcet Wcet Prioridade t1 t2 t3 3 4 5 30 50 100 20 30 80 10 15 20 10 15 20 3 2 1

As queries de consulta utilizadas no verificador do UPPAAL para determinar os tempos de resposta das trs tarefas para a poltica FPS sem considerar o offset foram: A[] Tarefa(0).Finalizada imply relogio[0]<10 A[] Tarefa(1).Finalizada imply relogio[1]<25 A[] Tarefa(2).Finalizada imply relogio[2]<80 Os tempos de respostas das tarefas foram determinados no UPPAAL atravs das queries acima. Ao execut-las, o UPPAAL informa como resposta que as propriedades podem no ser satisfeitas. Contudo, quando uma unidade foi adicionada a cada tempo (totalizando 11, 26 e 81 respectivamente), as propriedades so satisfeitas. Quando isto acontece, este valor limite o tempo de resposta da tarefa. Ao considerar o offset, os valores testados foram 13, 28 e 83. O mesmo procedimento foi empregado para verificar o tempo de resposta para a poltica EDF. Porm, com valores de tempo diferentes, isto , para as tarefas 1, 2 e 3

foram testados os valores 20, 25 e 55 sem considerar o offset. Quando o offset foi considerado, os valores 23, 28 e 58 foram testados. Os tempos de respostas para as duas polticas de escalonamento sem e com offset so apresentados na Tabela 2.
Tabela 2. Tempos de Resposta obtidos.

Tarefa FPS sem offset EDF sem offset FPS com offset EDF com offset t1 t2 t3 10 25 80 20 25 55 13 28 83 23 28 58

Alm dos tempos de resposta, duas outras queries foram verificadas no UPPAAL: A[] forall (i : identificador) not Tarefa(i).Erro A[] not deadlock A primeira query significa: "Para todos os caminhos possveis, nenhuma tarefa entra no local Erro?" Em outras palavras, deseja-se saber se alguma tarefa tem seu deadline excedido. J a segunda query significa: para todos os caminhos o sistema no entra em deadlock? Os resultados da execuo dessas queries so listados na Tabela 3.
Tabela 3. Propriedades de deadlock e local Erro das tarefas sem e com offset.

Poltica Sem offset FPS EDF FPS Com offset EDF

Deadlock Satisfeita Satisfeita Satisfeita

Local Erro Satisfeita Satisfeita Pode no ser satisfeita

Pode no ser Pode no ser satisfeita satisfeita

Um sistema de tarefas com restries de recursos e com polticas de escalonamento dito ser escalonvel se nenhuma execuo que satisfaa as restries do sistema viola o deadline (DAVID et al., 2009). Tendo em vista esse conceito, possvel afirmar que para as polticas FPS sem offset e EDF sem offset, o sistema escalonvel. Por outro lado, para o FPS com offset e EDF com offset, o sistema no escalonvel, pois no FPS, o tempo de resposta da tarefa t3 83 que maior que o seu deadline (80). J no EDF o tempo de t1 23 que maior que o deadline (20). Alm disso, em todas as situaes com exceo do EDF com offset, o sistema no entra em deadlock.

6. Concluso
O problema de escalonamento dos Sistemas em Tempo Real consiste em determinar quando e por quanto tempo uma tarefa deve ser executada. A ferramenta

UPPAAL foi desenvolvida para o projeto, verificao e simulao de sistemas em tempo real que podem ser modelados como rede de autmatos temporizados. Os templates de tarefa e recurso e das polticas de escalonamento FPS e EDF desenvolvidos no UPPAAL demonstraram ser eficientes e os tempos de respostas obtidos foram de acordo com o esperado para o conjunto de tarefas analisado. O EDF diminuiu consideravelmente o tempo da resposta t3 considerando ou no o offset. Por outro lado, o tempo de resposta da tarefa t1 aumentou. Nesse conjunto, concluiu-se que a adio do offset nas tarefas resultou na no-escalonabilidade do sistema.

Referncias
BEHRMANN, G.; DAVID, A.; LARSEN, K. G. A tutorial on UPPAAL. Disponvel em: < http://www.it.uu.se/research/group/darts/papers/texts/new-tutorial.pdf>. DAVID, A.; Illum, J.; Larsen, K. G.; Skou, A. Model-based framework for schedulability analysis using uppaal 4.1. In: Mosterman, Pieter J. (Hrsg.): ModelBased Design for Embedded Systems. CRC Press, Taylor & Francis Group, 2009 (Computational Analysis, Synthesis, and Design of Dynamic Models Series). 2009. p. 93119. DOBRIN, R.; OZDEMIR, Y.; FOHLER, G.; Task attribute assignment of fixed priority scheduled tasks to reenact off-line schedules. Real-Time Computing Systems and Applications, 2000. Proceedings. Seventh International. p.150-154. SHAW, A. C. SISTEMAS E SOFTWARE DE TEMPO REAL. So Paulo: John & Wiley, 2001. 240 p.