Faculdade de Tecnologia
FLAVIO RUBENS MASSARO JÚNIOR
PROPOSTA DE UM MODELO FLEXÍVEL E PROATIVO PARA
MUDANÇAS DE MODO EM SISTEMAS DE TEMPO REAL COM
CRITICALIDADE MISTA
PROPOSAL OF A FLEXIBLE AND PROACTIVE MODEL FOR MODE
CHANGES IN MIXED-CRITICALITY REAL-TIME SYSTEMS
LIMEIRA
2019
PROPOSTA DE UM MODELO FLEXÍVEL E PROATIVO PARA
MUDANÇAS DE MODO EM SISTEMAS DE TEMPO REAL COM
CRITICALIDADE MISTA
Tese apresentada à Faculdade de Tec-nologia da Universidade Estadual de Campinas como parte dos requisitos exi-gidos para a obtenção do título de Doutor em Tecnologia, na área de Sistemas de Informação e Comunicação.
Thesis presented to the School of Tech-nology of the University of Campinas in partial fulfillment of the requirements for the degree of Doctor in Technology, in the area of Information Systems and Communication.
Orientador: Prof. Dr. Paulo Sérgio Martins Pedro Co-orientador: Prof. Dr. Édson Luiz Ursini
ESTE EXEMPLAR CORRESPONDE À VERSÃO FINAL DA TESE DEFENDIDA PELO ALUNO FLAVIO RUBENS MAS-SARO JÚNIOR, E ORIENTADA PELO PROF. DR. PAULO SÉRGIO MARTINS PEDRO.
LIMEIRA
2019
Biblioteca da Faculdade de Tecnologia Felipe de Souza Bueno - CRB 8/8577
Massaro Júnior, Flavio Rubens,
M382p MasProposta de um modelo flexível e proativo para mudanças de modo em sistemas de tempo real com criticalidade mista / Flavio Rubens Massaro Júnior. – Limeira, SP : [s.n.], 2019.
MasOrientador: Paulo Sérgio Martins Pedro. MasCoorientador: Edson Luiz Ursini.
MasTese (doutorado) – Universidade Estadual de Campinas, Faculdade de Tecnologia.
Mas1. Sistemas de tempo real. 2. Escalonamento de processos. 3. Previsão. I. Martins Pedro, Paulo Sérgio, 1967-. II. Ursini, Edson Luiz, 1951-. III.
Universidade Estadual de Campinas. Faculdade de Tecnologia. IV. Título.
Informações para Biblioteca Digital
Título em outro idioma: Proposal of a flexible and proactive model for mode changes in mixed-criticality real-time systems
Palavras-chave em inglês: Real-time systems
Process scheduling Forecasting
Área de concentração: Sistemas de Informação e Comunicação Titulação: Doutor em Tecnologia
Banca examinadora:
Paulo Sérgio Martins Pedro [Orientador] George Marconi de Araújo Lima
Sarita Mazzini Bruschi Weiler Alves Finamore Ulisses Martins Dias
Data de defesa: 06-12-2019
Programa de Pós-Graduação: Tecnologia Identificação e informações acadêmicas do(a) aluno(a)
- ORCID do autor: https://orcid.org/0000-0003-2896-8067 - Currículo Lattes do autor: http://lattes.cnpq.br/6581012116833368
Abaixo se apresentam os membros da comissão julgadora da sessão pública de defesa de dissertação para o Título de Doutor em Tecnologia na área de concentração de Sistemas de Informação e Comunicação, a que submeteu o aluno Flavio Rubens Massaro Júnior, em 06 de dezembro de 2019 na Faculdade de Tecnologia - FT/UNICAMP, em Limeira/SP.
Prof. Dr. Paulo Sérgio Martins Pedro
Presidente da Comissão Julgadora
Prof. Dr. George Marconi de Araújo Lima
Universidade Federal da Bahia
Profa. Dra. Sarita Mazzini Bruschi
Universidade de São Paulo
Prof. Dr. Weiler Alves Finamore
Universidade Estadual de Campinas
Prof. Dr. Ulisses Martins Dias
Universidade Estadual de Campinas
Ata da defesa, assinada pelos membros da Comissão Examinadora, consta no SIGA/Sistema de Fluxo de Dissertação/Tese e na Secretaria de Pós Graduação da FT.
Flávio Neto e aos meus pais Flávio e Lenita. Eles foram minha fonte de motivação para a conclusão dessa jornada.
Gostaria de agradecer meu orientador Dr. Paulo Sérgio Martins Pedro e meu co-orientador Dr. Édson Luiz Ursini por me concederem a oportunidade de desenvolver minha Tese na Universidade Estadual de Campinas, e por seu contínuo apoio e interesse pelo meu trabalho. Eu também gostaria de agradecer-lhes pelas muitas horas de discussão e pela revisão do trabalho nesta dissertação. Sou grato aos meus colegas da Faculdade de Tecnologia por seu encorajamento. Finalmente, quero agradecer a minha esposa Vanessa por sua paciência e apoio durante os tempos difíceis.
A definição de modos de operação no projeto de um sistema de tempo real tem sido um recurso utilizado para se agregar benefícios ao sistema, dentre eles a adequação dinâmica da operação do sistema para uma determinada fase de operação. Tradicionalmente, as mudanças no modo de operação são realizadas de maneira reativa, ou seja, o sistema altera seu modo em resposta a um evento interno ou externo. Este trabalho apresenta uma proposta de um modelo proativo para mudanças de modo em sistemas de tempo real de criticalidade mista. Nesta abordagem foram integrados algoritmo de predição e lógica difusa ao escalonamento de mudanças de modo utilizando as políticas de escalonamento Earliest-Deadline-First (EDF) e Fixed-Priority Preemptive Systems (FPPS). Essa abordagem visa a programação proativa de mudanças de modo baseada em valores observados e preditos de variáveis de estado como a lassidão de pior caso das instâncias das tarefas em espera ou em estado de execução a fim de minimizar a perda de prazo das tarefas de baixa criticalidade. Para avaliação de viabilidade, a abordagem proposta foi moldada em um modelo de simulação por eventos discretos que posteriormente fora validado com um modelo analítico (análise de escalonabilidade de pior caso). Oito estudos de caso foram implementados para avaliar o impacto das mudanças de modos proativas na perda de prazo das tarefas. Os resultados mostraram ganhos na adoção da abordagem de previsão para ambos os paradigmas de escalonamento, apresentando uma redução significativa no número de prazos perdidos para tarefas de baixa criticidade.
Palavras-chave: sistemas de tempo real; análise de escalonabilidade em mudança de modo;
The definition of modes of operation in the design of a real-time system has been a fea-ture used to add benefits to the system, such as the dynamic adaptation of the system’s operation to a specific phase of operation. Traditionally, the changes in mode of operation have been accomplished in a reactive manner, i.e. the system changes its mode in response to an internal or external event. This work presents a proposal for proactive mode-changes in mixed-criticality real-time systems. In this approach, prediction algorithms and fuzzy were integrated into mode-changes using Earliest-Deadline-First (EDF) and Fixed-Priority Preemptive Systems (FPPS) scheduling policies. The aim of this approach is the proactive scheduling for mode-changes based on observed and predicted values of the state variables such as the worst-case laxity of waiting or running tasks. For feasibility evaluation, the pro-posed approach was modeled on a discrete event simulation model that was later validated with an analytical model (worst case scalability analysis). Eight case studies were imple-mented to assess the impact of proactive mode-changes on missed deadlines of tasks. The results showed that the approach using prediction for both scheduling paradigms represented a significant reduction in the number of missed deadlines for low-criticality tasks.
Keywords: real-time systems, schedulability analysis of mode-changes, mixed-criticality,
Figura 1 – Modelo simplificado de arquitetura de um sistema de tempo real . . . . 23
Figura 2 – Modelo conceitual . . . 27
Figura 3 – Modelo de mudança de modo . . . 36
Figura 4 – Modelo utilizado pelo Filtro de Kalman . . . 42
Figura 5 – KSL-X: submodelo dinâmico KSL-D (verde), modelo estático KSL-S (azul), elementos comuns (branco) . . . 44
Figura 6 – Arquitetura do modelo computacional proposto . . . 49
Figura 7 – Diagrama de modos de operação . . . 51
Figura 8 – Analogia do modelo computacional: variável para predição de perda de prazos . . . 54
Figura 9 – Exemplo de cálculo da lassidão . . . 55
Figura 10 – Analogia ente uma rodovia e uma mudança de modo proativa . . . 57
Figura 11 – Conjunto de tarefas em estado de execução . . . 58
Figura 12 – Exemplo de lassidão de pior caso (observado vs predito) . . . 59
Figura 13 – Exemplo de tarefas para cálculo de lassidão e velocidade . . . 61
Figura 14 – Exemplo de aplicação - Variáveis de entrada para lógica difusa . . . 62
Figura 15 – Exemplo de aplicação - Variável de saída de lógica difusa . . . 63
Figura 16 – Exemplo de aplicação - Processo de defuzzificação (Tarefa 𝜏1) . . . 64
Figura 17 – Visão geral: modelo computacional proativo . . . 65
Figura 18 – Visão expandida do modelo computacioanl proativo . . . 67
Figura 19 – Diagrama do modelo de simulação - Parte I . . . 70
Figura 20 – Diagrama do modelo de simulação - Parte II . . . 71
Figura 21 – 𝑊 𝐶𝑅𝑇 em estado estacionário . . . . 76
Figura 22 – WCRT em mudança do modo M1 para o modo M2 . . . . 77
Figura 23 – WCRT em mudança do modo 𝑀 2 para o modo 𝑀 1 . . . . 78
Figura 24 – Visão geral dos estudos de caso . . . 81
Figura 25 – Estudo de caso 1 - Latência dado o tamanho da fila (M1) - não usando predição . . . 83
Figura 26 – Estudo de caso 1 - Latência dado o tamanho da fila (M2) - não Usando predição . . . 84
Figura 27 – Estudo de caso 1 - Comparação da latência usando predição e não usando predição . . . 85
Figura 30 – Estudo de caso 2 - Tempo de antecipação antes da perda de prazo . . . . 90
Figura 31 – Estudo de caso 2 - Comparação valor predito vs. valor observado . . . . 91
Figura 32 – Estudo de caso 2 - Comparação de prazos perdidos . . . 92
Figura 33 – Estudo de caso 3 - Tempo de antecipação antes da perda de prazo . . . . 95
Figura 34 – Estudo de caso 3 - Comparação valor predito vs. valor observado . . . . 96
Figura 35 – Estudo de caso 3 - Comparação de prazos perdidos . . . 97
Figura 36 – Estudo de caso 4 - Tempo de predição antes da perda de prazo . . . 100
Figura 37 – Estudo de caso 4 - Comparação valor predito vs. valor observado . . . . 100
Figura 38 – Estudo de caso 4 - Comparação de prazos perdidos . . . 101
Figura 39 – Estudo de caso 5 - Variáveis de entrada de lógica difusa . . . 104
Figura 40 – Estudo de caso 5 - Variável de saída da lógica difusa . . . 105
Figura 41 – Estudo de caso 5 - Tempo de predição antes da perda de prazo . . . 107
Figura 42 – Estudo de caso 5 - Comparação valor predito vs. valor observado . . . . 107
Figura 43 – Estudo de caso 5 - Comparação de prazos perdidos . . . 108
Figura 44 – Estudo de caso 6 - Variáveis de entrada da lógica difusa . . . 112
Figura 45 – Estudo de caso 6 - Variável de saída da lógica difusa . . . 112
Figura 46 – Estudo de caso 6 - Tempo de predição antes da perda de prazo . . . 114
Figura 47 – Estudo de caso 6 - Comparação valor predito vs. valor observado . . . . 115
Figura 48 – Estudo de caso 6 - Comparação de prazos Perdidos . . . 116
Figura 49 – Estudo de caso 7 - Variáveis de entrada para lógica difusa . . . 120
Figura 50 – Estudo de caso 7 - Variável de saída da lógica difusa . . . 121
Figura 51 – Estudo de caso 7 - Tempo de predição antes da perda de prazo . . . 122
Figura 52 – Estudo de caso 7 - Comparação valor predito vs. valor observado . . . . 123
Figura 53 – Estudo de caso 7 - Comparação de prazos perdidos . . . 124
Figura 54 – Estudo de caso 8 - Variáveis de entrada da lógica difusa . . . 127
Figura 55 – Estudo de caso 8 - Variável de saída da lógica difusa . . . 128
Figura 56 – Estudo de caso 8 - Tempo de predição antes da perda de prazo . . . 130
Figura 57 – Estudo de caso 8 - Comparação valor predito vs. valor observado . . . . 130
Figura 58 – Estudo de caso 8 - Comparação de prazos perdidos . . . 131
Figura 59 – Comparativo de Prazos Perdidos . . . 133
Figura 60 – Gráfico de dispersão . . . 134
Figura 61 – Número de publicações encontradas por ano. . . 148
Tabela 1 – Exemplo de regras de lógica difusa para mudança de modo . . . 50
Tabela 2 – Exemplos de modos de operação . . . 51
Tabela 3 – Exemplo de lassidão de pior caso (observado vs predito) . . . 59
Tabela 4 – Exemplo de cálculo de lassidão e velocidade (tempos em unidade de tempo (ut) . . . 61
Tabela 5 – Regras de lógica difusa para mudança de modo - Exemplo de aplicação . 62 Tabela 6 – Exemplo de aplicação de lógica difusa no processo de decisão de uma MCR 63 Tabela 7 – Conjunto de tarefas utilizadas para validação . . . 75
Tabela 8 – Resultados analíticos vs simulação em estado estacionário . . . 76
Tabela 9 – Resultados Analíticos vs Simulação em mudança de modo . . . 77
Tabela 10 – Intervalo de confiança . . . 79
Tabela 11 – Estudo de caso 1 - Média da latência de mudança de modo . . . 84
Tabela 12 – Estudo de caso 2 - Conjunto de tarefas . . . 87
Tabela 13 – Estudo de caso 2 - Regras de lógica difusa para mudança de modo . . . . 89
Tabela 14 – Estudo de caso 2 - Resultados . . . 90
Tabela 15 – Estudo de caso 3 - Resultados . . . 95
Tabela 16 – Estudo de caso 4 - Resultados . . . 99
Tabela 17 – Estudo de caso 5 - Regras de lógica difusa . . . 105
Tabela 18 – Estudo de caso 5 - Resultados . . . 106
Tabela 19 – Estudo de caso 6 - Conjunto de tarefas . . . 110
Tabela 20 – Estudo de caso 6 - Regras de lógica difusa . . . 113
Tabela 21 – Estudo de caso 6 - Resultados . . . 114
Tabela 22 – Estudo de caso 7 - Tarefas GAP . . . 119
Tabela 23 – Estudo de caso 7 - Regras de lógica difusa . . . 121
Tabela 24 – Estudo de caso 7 - Resultados . . . 122
Tabela 25 – Estudo de caso 8 - Tarefas GAP . . . 126
Tabela 26 – Estudo de caso 8 - Regras da lógica difusa . . . 128
Tabela 27 – Estudo de caso 8 - Resultados . . . 129
Tabela 28 – Resumo comparativo de prazos perdidos . . . 132
Tabela 29 – Dados utilizados para os testes de hipótese e de correlação . . . 134
Tabela 30 – Exemplo de estratégia de pesquisa para o IEEE Xplore e o número de ocorrências retornadas . . . 148
Caracteres Latinos
𝐵 Tempo de Bloqueio
𝐶 Tempo Computacional de Pior Caso 𝐷 Deadline
𝐺 Matriz de Ganho de Kalman 𝐻 Matriz de Observações 𝐿 Latência
𝑁 Matriz de Covariâncias do Ruído de Observação 𝑂 Offset 𝑌 or 𝑍
𝑄 Matriz de Covariâncias do Ruído do Processo 𝑃 Prioridade
𝑅 WCRT da Tarefa 𝜏𝑖
𝑇 Período entre liberações da tarefa 𝜏𝑖 𝑈 Utilização do Processador
𝑉 Velocidade
𝑌 Offset medido a partir de uma requisição de mudança de modo
𝑍 Offset medido medido a partir do final da última instância da tarefa no modo antigo
Caracteres Gregos
𝜏 Tarefa
Φ Modelo de transição de estado (ou seja, matriz) que é aplicado ao estado ante-rior 𝑥𝑘−1
𝐴 Tarefas abortadas 𝐶 Tarefas Alteradas
𝑁 Tarefas pertencentes do Modo Novo
𝑂 Tarefas pertencentes do Modo Antigo (Completadas) 𝑈 Tarefas não Alteradas
𝑊 Tarefas pertencentes exclusivamente ao Modo Novo
Abreviações
Lass Lassidão
ILass Índice de Lassidão
MIN Mínimo
ANN Artificial Neural Networks
DMS Deadline Monotonic Scheduling
EDF Earliest Deadline First
ELM Extreme Learning Machine
EM Expectation-Maximization
FP Fixed Priority
FPPS Fixed Priority Preemptive System
HPP Homogeneous Poisson Process
IPCP Immediate Priority Ceiling Protocol
KSLX Predictor Based on the Kalman Filter
LD Latency Definition
LTT Laplace Trend Test
LLF Lowest Laxity First
MCD Mode-Change Deadline
MCR Mode-Change Request
MSE Mean Square Error
NAE Number of Accumulated Errors
OS-ELM Online Sequential Extreme Learning Machine
RBF Radial-Basis Function
RMS Rate-Monotonic Scheduling
RMSE Root Mean Square Error
SRGM Software Reliability Growth Model
RSS WCRT of a Task in Steady-State Mode
RTOS Real-Time Operation System
SVM Support Vector Machine
WCL Worst Case Laxity
WCRT Worst Case Response Time
1 Introdução . . . . 22
1.1 Motivação . . . 24
1.2 Objetivos . . . 24
1.3 Requisitos . . . 25
1.3.1 Requisitos Funcionais . . . 25
1.3.2 Requisitos não Funcionais . . . 26
1.4 Modelo Conceitual . . . 26
1.5 Questões de Pesquisa . . . 27
1.6 Hipótese da Tese . . . 27
1.7 Organização . . . 28
2 Revisão de Literatura . . . . 29
2.1 Definição de Sistema Operacional de Tempo Real . . . 29
2.2 Servidores Esporádicos . . . 30
2.3 Definição de Modos . . . 31
2.4 Mudanças de Modo Genéricas em Sistemas de Tempo Real . . . 33
2.4.1 Análise de Escalonabilidade para Prioridade Fixa . . . 35
2.4.1.1 Análise para tarefas do modo antigo . . . 36
2.4.1.2 Análise para tarefas do modo novo . . . 37
2.5 Sistemas de Tempo Real com Criticalidade Mista . . . 38
2.6 Mudanças de Modo em Sistemas de Tempo Real de Criticalidade Mista . . . 39
2.7 Tolerância à Falhas em Sistemas de Tempo Real . . . 39
2.8 Predição . . . 40
2.8.1 Filtro de Kalman . . . 41
2.8.2 Algoritmo KSL/KSLX . . . 42
2.8.2.1 Teste de Tendência de Laplace . . . 44
2.8.2.2 Modelo de Predição 𝑛-Passos à Frente . . . . 44
2.8.3 Predição de Perda de Prazos em Sistemas de Tempo Real . . . 45
2.9 Principais Descobertas . . . 46
2.10 Lacunas Idenfificadas . . . 47
3 Modelo Computacional e Implementação . . . . 48
3.1 Arquitetura do Modelo Computacional Proposto . . . 48
3.2 Cálculo da Lassidão e Analogia com o Mundo Físico . . . 53
3.5 Implementação do Modelo de Simulação . . . 66
3.6 Modelo de atribuição de mudança de modo . . . 72
3.7 Metodologia . . . 73
4 Validação do Modelo de Simulação . . . . 75
5 Predizendo Mudanças de Modo e Perdas de Prazos . . . . 80
5.1 Estudos de Caso . . . 80
5.1.1 Estudo de Caso 1 - Predizendo Mudanças de Modo em FPPS . . . . 82
5.1.1.1 Configuração . . . 82
5.1.1.2 Resultados . . . 83
5.1.1.3 Compração da Latência de Mudança de Modo . . . 84
5.1.1.4 Discussão Preliminar . . . 85
5.1.2 Estudo de Caso 2 - Predizendo Perdas de Prazos em EDF . . . 86
5.1.2.1 Premissas . . . 86
5.1.2.2 Configuração . . . 87
5.1.2.3 Resultados . . . 89
5.1.2.4 Discussão Preliminar . . . 92
5.1.3 Estudo de Caso 3 - Predizendo Perdas de Prazos em EDF Utilizando offsets Dinâmicos . . . . 93
5.1.3.1 Premissas . . . 93
5.1.3.2 Configuração . . . 94
5.1.3.3 Resultados . . . 94
5.1.3.4 Discussão Preliminar . . . 97
5.1.4 Estudo de Caso 4 - Predizendo Perdas de Prazos em FPPS com offsets 98 5.1.4.1 Premissas . . . 98
5.1.4.2 Configuração . . . 99
5.1.4.3 Resultados . . . 99
5.1.4.4 Discussão Preliminar . . . 102
5.1.5 Estudo de Caso 5 - Predizendo Perdas de Prazos em EDF utilizando Offsets Dinâmicos e incluindo nova variável de entrada de lógica difusa 102 5.1.5.1 Premissas . . . 102
5.1.5.2 Configuração . . . 103
5.1.5.3 Resultados . . . 106
5.1.5.4 Discussão Preliminar . . . 109
5.1.6 Estudo de Caso 6 - Predizendo Perdas de Prazos em FPPS utilizando Offsets Dinâmico e incluindo nova variável de entrada para lógica difusa109 5.1.6.1 Premissas . . . 110
5.1.6.3 Resultados . . . 113
5.1.6.4 Discussão Preliminar . . . 116
5.1.7 Estudo de Caso 7 - Predizendo Perdas de Prazos em EDF (GAP) . . 117
5.1.7.1 Premissas . . . 117
5.1.7.2 Configuração . . . 118
5.1.7.3 Resultados . . . 122
5.1.7.4 Discussão Preliminar . . . 124
5.1.8 Estudo de Caso 8 - Predizendo Perdas de Prazos em FPPS (GAP) . . 125
5.1.8.1 Premissas . . . 125
5.1.8.2 Configuração . . . 125
5.1.8.3 Resultados . . . 129
5.1.8.4 Discussão Preliminar . . . 131
5.2 Resumo Comparativo de Prazos Perdidos . . . 132
5.3 Teste de Hipótese . . . 133
6 Discussão . . . . 135
7 Sumário e Conclusão . . . . 137
Referências . . . . 140
Apêndices
145
APÊNDICE A Método utilizado para Revisão de Literatura . . . . 146A.1 Definição de tópico de pesquisa . . . 146
A.2 Definição dos conceitos envolvidos . . . 146
A.3 Seleção das fontes de literatura . . . 147
A.4 Definição de termos de pesquisa . . . 147
A.5 Definição da estratégia de pesquisa . . . 147
A.6 Critério de seleção . . . 149
Declaração
Declaro que a pesquisa descrita nesta dissertação é um trabalho original que realizei entre fevereiro de 2015 e novembro de 2019. Declaro ainda, que os resultados parciais desse trabalho foram publicados em Massaro et al. (2018).
Glossário
Immediate Priority Ceiling Protocol (IPCP) - “With IPCP, a resource has a ceiling
priority assigned to it, not lower than that of the highest priority task that may use it. A task using a resource, immediately inherits its ceiling priority, thus avoiding unbounded priority inversion, deadlocks and transitive blocking” (REAL; CRESPO, 2001a).
Laxity - “The time difference between time span to deadline and remaining execution time
which indicates the available flexibility for scheduling of corresponding task. A Laxity of 𝑡 means even if a task’s execution defers insomuch time units, it will still have the opportunity to meet its deadline” (RAMEZANI; SEDAGHAT, 2014).
Promptness - “There may be new-mode tasks whose execution must be completed before a
determinate time after the mode change was requested. This requirement models the need for a prompt response, specially useful when switching to an emergency mode” (REAL; CRESPO, 2001a).
Mode Change - “ The mode change occurs when one entity issues a mode-change request
command (MCR). Once the system receives the MCR, its state changes to transient-mode. During the mode change the old-mode tasks will either be aborted or completed. New-mode tasks will start their execution. At the end of the transition the system changes back to steady state/mode” (MASSARO, 2015).
Offset - “Offset is a value that delays the introduction of a task during the mode change.
Offsets are assigned to new-mode tasks to reduce the interference between tasks during the mode change” (MASSARO, 2015).
Steady State - “The system is in steady state when it executes a fixed task set (without
1 Introdução
Sistemas de tempo real são usados em operações críticas (naves espaciais, aeronaves, veículos, controle de tráfego aéreo, comunicações multimídia, etc.), onde garantias de tempo de execução são necessárias para um determinado conjunto de tarefas que são executadas em um sistema mono ou multiprocessado. Tais garantias podem ser providas pela análise de escalonabilidade de pior caso, que calcula o tempo de resposta de pior caso, Worst Case Response Time (WCRT), que corresponde ao intervalo entre a liberação e a conclusão de cada tarefa. O sistema é considerado viável quando o WCRT de todas as tarefas forem inferiores ao seu respectivo prazo (BURNS; WELLINGS, 2009).
Cada vez mais, os sistemas modernos precisam ser dinamicamente adaptáveis ao am-biente operacional, ou seja, mudanças no amam-biente operacional podem, em contrapartida, exigir mudanças no comportamento do sistema. Para realizar tais alterações, faz-se necessá-rio a utilização de vánecessá-rios modos de operação, onde cada modo de operação é representado por um conjunto de tarefas otimizadas para operar em uma condição, cenário ou fase específica do sistema. Uma mudança no cenário pode requerer uma mudança correspondente no modo de operação do sistema para que este melhor se adapte às condições externas. Assim, os sistemas podem ser cartacterizados como “monomodo”, quando possuem um único modo de operação e “multimodo”, quando possuem mais que um modo de operação.
Além disso, as novas gerações de sistemas de tempo real exigem projetos em que tarefas com diferentes níveis de criticalidade devam coexistir na mesma plataforma. Esses recursos são fornecidos por sistemas de tempo real de criticalidade mista (VESTAL, 2007). Em tais sistemas, as tarefas são subdivididas em dois ou mais níveis de criticalidade (por exemplo, segurança crítica, missão crítica e não crítica). Nesse contexto, tarefas com um nível mais alto de criticalidade exigem garantias de tempo real, enquanto tarefas de baixa criticalidade toleram a perda de alguns prazos.
Em um sistema de tempo real, a correção do comportamento do sistema depende não apenas dos resultados lógicos dos cálculos, mas também do instante físico em que esses resultados são produzidos. Portanto, a previsibilidade do comportamento do sistema é a preocupação mais importante nesses sistemas. A previsibilidade é frequentemente obtida pela análise dinâmica ou estática do escalonamento das tarefas de tempo real.
CPU
MEM
E/S
RTOS
TAREFAS
n C, T, D, P 1 2 3 4 5T/D
C
P
TEMPO
Figura 1 – Modelo simplificado de arquitetura de um sistema de tempo real
A Figura 1 demonstra o modelo de arquitetura de um sistema de tempo real. Essa arquitetura representa um sistema monoprocessado gerenciado por um sistema operacional de tempo real - real-time operation system (RTOS), responsável por administrar a execução do conjunto de tarefas de acordo com os parâmetros predeterminados. Como parâmetros podemos citar a prioridade das tarefas (𝑃 ), o tempo computacional (𝐶) e o período entre liberação de novas instâncias (𝑇 ) que no caso é igual ao seu respetivo prazo (𝐷).
Em muitos sistemas, o comportamento proativo faz-se necessário, pois, uma vez que uma condição de sobrecarga ou anomalia é detectada, pode ser tarde demais para se tentar remediar o contexto, levando potencialmente à perda de prazos. Esse documento refere-se à palavra “proatividade” com a seguinte acepção: “característica de quem busca identificar ou resolver os problemas por antecipação, com antecedência; presteza, diligência” (PROATIVI-DADE, 2019).
No âmbito de sistemas de criticalidade mista, abortar tarefas de baixa criticalidade pode ocasionar que os recursos alocados não sejam totalmente liberados ao sistema, deixando-o em um estaddeixando-o incdeixando-onsistente. Pdeixando-ortantdeixando-o, deixando-o usdeixando-o de escaldeixando-onamentdeixando-o prdeixando-oativdeixando-o, usanddeixando-o algdeixando-oritmdeixando-os de predição, pode propiciar uma mudança de modo que seja menos suscetível a tais efeitos indesejáveis (estados inconsistentes). A suposição é que ao se detectar uma condição de sobre-carga antecipadamente, tarefas de baixa criticalidade possam ser concluídas e/ou abortadas sem comprometer o estado do sistema.
Nesse trabalho, argui-se que os algoritmos de predição podem ser uma alternativa viável para sistemas de criticalidade mista, em particular, permitindo a implementação de uma forma mais segura para eliminar tarefas de baixa criticalidade, já que abortar de forma
imediata tais tarefas pode desencadear problemas que levem o sistema a um estado inconsis-tente. Uma abordagem potencialmente mais vantajosa seria eliminar tais tarefas dentro de uma janela de antecipação, depois de terem concluído sua execução.
Embora a questão dos estados inconsistentes tenha sido identificada por Burns (2014), ainda não foi devidamente abordada na literatura. Esse trabalho tenta mitigar tais efeitos por meio de um comportamento proativo. Assim, buscando prover suporte para sistemas de criticalidade mista, no que tange à eliminação de tarefas de baixa criticalidade.
1.1
Motivação
Em sistemas de tempo real, as garantias de execução das tarefas dentro de seus res-pectivos prazos (em inglês deadlines) é um fator crucial. Entretanto, durante o período de execução do sistema, eventos não previstos podem levá-lo a um comportamento anômalo que implica diretamente em atrasos inesperados que possam desencadear a perda de prazo de algumas instâncias das tarefas. Dessa forma, mecanismos que identifiquem previamente a possibilidade da perda dos prazos de algumas tarefas podem prover suporte para um compor-tamento proativo que busque evitar tais perdas. No entanto, como demonstrado no Capítulo 2, existe uma lacuna a ser preenchida nesse contexto. Assim, a abordagem proposta neste trabalho busca dar os primeiros passos para preencher essa lacuna.
1.2
Objetivos
Este trabalho possui os seguintes objetivos:
1. Propor um modelo flexível e proativo: para executar mudanças de modo em sistemas de tempo real com criticalidade mista. O sistema é denominado flexível devido a sua capacidade de se adaptar dinamicamente e de forma autônoma às condições do meio externo;
2. Prover controle baseado em predição: para minimizar a perda de prazos de tarefas. Para isso, propõe-se a implementação de um modelo de mudança de modo proativo subsidiado por mecanismos de predição e lógica difusa;
3. Implementar o modelo: em um ambiente de simulação por eventos discretos, que im-plemente dois modos de operação e políticas de escalonamento Earliest-Deadline First (EDF) e Fixed-Priority Preemptive Scheduling (FPPS). Esse modelo deverá ser vali-dado comparando os resultados obtidos durante a simulação com os resultados calcu-lados por meio de um modelo analítico.
4. Avaliar o desempenho: por meio de estudos de caso que serão implementados no modelo de simulação. A análise de desempenho deverá avaliar o número de tarefas com prazos perdidos, tanto no estado estacionário, como durante uma mudança de modo, em três cenários: a) reativo, b) proativo com lógica difusa e c) proativo com lógica difusa e predição.
1.3
Requisitos
Nesta seção serão apresentados os requisitos que vão ser utilizados como base para criação do simulador utilizado como ferramenta de suporte na elaboração deste trabalho. Os requisitos foram classificados em duas categorias: requisitos funcionais e não funcionais. Cada um dos requisitos elencados foram detalhados de forma a possibilitar um maior esclarecimento das características implementadas no simulador.
1.3.1
Requisitos Funcionais
1. Possibilitar a simulação de sistemas de tempo real monomodo e multimodo;
2. Permitir a utilização de escalonamento EDF e FPPS, que são as políticas de escalona-mento em sistemas de tempo real;
3. Possibilitar a configuração personalizada do conjunto de tarefas periódicas a ser utili-zado no processo de simulação, possibilitando especificar o tipo, o período (T), o tempo de execução de pior caso (C), a prioridade (P), os Offsets (Y,Z), que correspondem a um atraso para a liberação da primeira instância da tarefa, e o prazo de cada uma das tarefas;
4. Liberar as tarefas, durante a simulação, de acordo com a periodicidade especificada em tempo de projeto;
5. Atribuir o tempo de execução e o prazo de cada tarefa no momento de sua liberação; 6. Computar o tempo de resposta (R) de cada uma das tarefas quando completam sua
execução;
7. Possibilitar a geração aleatória de indisponibilidade de CPU utilizando distribuições estatísticas;
8. Incorporar a utilização de lógica difusa (fuzzy);
10. Atualizar as variáveis utilizadas no processo de predição a cada ponto de escalonamento; 11. Gravar os valores das variáveis utilizadas no processo de simulação de forma a
possibi-litar uma análise detalhada dos dados;
12. Implementar um gerenciador de mudanças de modo que possibilite a mudança do con-texto operacional de forma proativa ou reativa;
13. O simulador deverá ser desenvolvido com base em um modelo de simulação por eventos discretos.
1.3.2
Requisitos não Funcionais
Neste trabalho, os requisitos não funcionais são basicamente temporais. Assim, não fazem parte do contexto principal, os requisitos de robustez, confiabilidade e tolerância a falhas. No entanto, não foi excluída a necessidade de utilização de redundâncias nos com-ponentes do modelo computacional utilizado. Entretanto, tais redundâncias foram omitidas intencionalmente por questões de brevidade. Mais especificamente os requisitos temporais são os seguintes:
1. As tarefas devem cumprir com os prazos especificados em tempo de projeto;
2. O conjunto de tarefas a ser utilizado no processo de simulação deve ser previamente submetido à análise de escalonabilidade de pior caso. Somente deverá ser utilizado, se todas as tarefas obtiverem o tempo de resposta de pior caso inferior ao seu respectivo prazo.
1.4
Modelo Conceitual
Em linhas gerais, o modelo proposto neste trabalho contempla um framework que provê a integração de diversos componentes e essa integração se traduz em um modelo pro-ativo de mudança de modo. A Figura 2 representa, por meio de um modelo conceitual, os componentes abrangidos no processo de integração. Nela, pode-se observar que a partir do uso de simulação é possível integrar os componentes necessários para implementação de um modelo de mudança de modo proativo para sistemas de tempo real de criticalidade mista, alicerçado por algoritmos de predição, utilizando KSLX em conjunto com lógica difusa, além de permitir o uso de políticas de escalonamento EDF/FPPS e atribuição de offsets dinâmicos.
INTEGRAÇÃO
SIMULAÇÃO MIXED CRITICALITY KSLX FUZZY EDF / FPPS OFFSETS DINÂMICOSFigura 2 – Modelo conceitual
1.5
Questões de Pesquisa
Ao término deste trabalho, espera-se que as seguintes questões possam ser respondi-das:
1. É possível prever a perda de um prazo?
2. Quais variáveis candidatas devem ser preditas?
3. Antecipar uma mudança de modo pode reduzir o número de prazos perdidos?
4. O uso de lógica difusa em conjunto com o preditor tem melhores resultados do que o uso de lógica difusa isoladamente?
5. Como podemos nos beneficiar ou explorar o uso de predição e comportamento proativo na programação e, em particular, em Sistemas de Criticalidade Mista - Mixed Criticality Systems (MCS)?
1.6
Hipótese da Tese
O propósito deste estudo experimental será testar a teoria de que o percentual de instâncias de tarefas com prazos perdidos é reduzido se uma mudança de modo proativa
for iniciada quando uma perda iminente de um prazo puder ser prevista dentro de uma janela de antecipação. Comparando o percentual de prazos perdidos com o tempo médio de antecipação da mudança de modo proativa, controlado pelo período da tarefa, o tempo de processamento, a prioridade, o prazo, o offset, a lassidão, para tarefas executadas em sistemas de tempo real de criticalidade mista com políticas de escalonamento FPPS e EDF. A variável independente “tempo médio de antecipação da mudança de modo proativa” é definida pela média do tempo de antecipação da mudança de modo proativa, com base na aplicação de algoritmos de predição combinados com lógica difusa. A variável dependente “percentual de instâncias de tarefas com prazos perdidos” é definida pelo número absoluto de tarefas que perderam seus respectivos prazos dividido pelo número total de instâncias de tarefas liberadas durante o tempo total de execução do sistema. As variáveis de controle são definidas como “período”, correspondente ao intervalo de tempo entre a liberação de novas instâncias , “tempo de processamento”, que corresponde ao tempo computacional necessário para execução de uma respectiva tarefa, “prioridade”, que corresponde à prioridade para executar uma tarefa, “prazo”, que é o prazo para execução de uma tarefa, medido desde a sua liberação, “offset”, que é o valor correspondente ao atraso para introdução de uma tarefa durante as mudanças de modo e “lassidão”, que é o percentual medido entre o término da execução de uma tarefa e seu respectivo deadline. Com base na definição descrita, sugere-se a seguinte hipótese nula: “O tempo médio de antecipação da mudança de modo proativa não afeta o percentual de instâncias de tarefas com prazos perdidos.”
1.7
Organização
Este trabalho está organizado da seguinte forma: o Capítulo 2 apresenta um contexto histórico e revisão de literatura, o Capítulo 3 aborda o modelo computacional e os pressupos-tos subjacentes, o Capítulo 4 apresenta a validação do modelo de simulação. A descrição e os resultados obtidos nos estudos de caso serão demonstrados no Capítulo 5. No Capítulo 6 são discutidos os resultados obtidos. Finalmente, no Capítulo 7 são apresentadas as conclusões deste trabalho.
2 Revisão de Literatura
Neste capítulo será apresentada uma revisão estruturada da literatura, que apresenta o estado da arte em mudanças de modo gerais e de criticalidade mista em sistemas de tempo real de criticalidade mista (MCS). Também foram abrangidos os fundamentos básicos da predição, que é um dos elementos chave neste trabalho. A pesquisa foi orientada pela estrutura PRISMA (Apêndice A).
2.1
Definição de Sistema Operacional de Tempo Real
De acordo Tanenbaum e Bos (2014), por definição, “um Sistema Operacional de Tempo Real é aquele em que o tempo desempenha um papel essencial. Tipicamente, um ou mais dispositivos físicos externos ao computador geram estímulos e o computador deve reagir adequadamente a eles dentro de um período fixo de tempo” 1.
Ainda de acordo com Tanenbaum e Bos (2014), os Sistemas de Tempo Real são clas-sificados em Sistemas hard real-time e soft real-time. Nos sistemas hard real-time, perdas de prazos absolutos (deadlines) não são toleradas, enquanto nos sistemas soft real-time a perda ocasional de uma prazo é indesejável, porém, tolerável. Em ambos os casos, o comporta-mento em tempo real é alcancável a partir da divisão do programa em vários processos cujo comportamento é conhecido e passível de previsão. Tais processos possuem curtos prazos de execução, geralmente inferiores a 1 segundo. Quando um evento externo é detectado o escalonador de processos é responsável por escalonar a execução da instância da tarefa de forma que todos os prazos possam ser devidamente cumpridos. Os eventos que o sistema pode responder são classificados como periódicos (que ocorrem em intervalos regulares) e aperiódicos (que ocorrem em intervalos não previsíveis).
De acordo com (PEDRO; BURNS, 1998), as garantias de tempo real são providas pela análise de escalonabilidade de pior caso, que compara os piores tempos de resposta de todas as tarefas com seus respectivos prazos. O sistema é considerado viável quando todas as tarefas possuem tempo de resposta de pior caso inferiores aos seus respectivos prazos.
1 “a real-time system is one in which time plays an essential role. Typically, one or more physical devices
external to the computer generate stimuli, and the computer must react appropriately to them within a fixed amount of time.” (TANENBAUM; BOS, 2014)
2.2
Servidores Esporádicos
De acordo com Sprunt et al. (1989), as tarefas em sistemas de tempo real podem ser divididas, com base em seu padrão de chegada e prazo, em quatro categorias:
∙ Periodic Hard real-time: Tarefas do tipo periodic hard real-time possuem prazos rígi-dos para completarem sua execução e periodicidade de liberação de novas instâncias predefinidas em tempo de projeto, assim, por premissa, atrasos não são tolerados; ∙ Periodic Soft real-time: Tarefas do tipo periodic soft real-time possuem prazos para
completarem sua execução e periodicidade de liberação de novas instâncias predefinidos em tempo de projeto, porém, perdas ocasionais de alguns prazos são toleradas;
∙ Aperiódicas: Tarefas do tipo aperiódicas possuem intervalos irregulares para liberação de novas instâncias, os prazos não são rígidos (soft) e normalmente necessitam de um tempo médio de resposta curto;
∙ Esporádicas: Tarefas do tipo esporádica, assim como as tarefas periódicas, possuem in-tervalos irregulares para liberação de novas instâncias, porém com um intervalo mínimo entre chegadas e prazos rígidos (hard).
Para prover garantias de tempo real para as tarefas do tipo hard real-time, faz-se necessária a implementação de mecanismos que possibilitem um controle efetivo na execução das tarefas aperiódicas e esporádicas. Dessa forma, garantindo que as tarefas do tipo hard real-time possam cumprir seus prazos na íntegra, provendo tempo médio de resposta curtos para tarefas esporádicas e garantindo o agendamento das tarefas mesmo quando ocorra uma sobrecarga transitória no sistema. Nesse sentido, Sprunt et al. (1989) propuseram um algo-ritmo de escalonamento para sistemas de tempo real com prioridades fixas chamado “Servidor Esporádico” - “Sporadic Server (SS)”. Esse algoritmo tem como objetivos: 1) fornecer tempo de respostas curtos para as tarefas aperiódicas e 2) garantir a execução das tarefas do tipo esporádicas dentro dos prazos estipulados em tempo de projeto.
Basicamente um servidor esporádico recebe para uma determinada janela de tempo, uma capacidade máxima (budget) para execução de tarefas periódicas e aperiódicas. Quando as tarefas aperiódicas e esporádicas são escalonadas, o budget é decrementado, assim, limi-tando o escalonamento das tarefas aperiódicas e esporádicas de forma a não ultrapassarem a capacidade máxima estipulada. O budget é reestabelecido quando a janela de tempo expira, assim, permitindo escalonar tarefas aperiódicas e esporádicas que estiverem aguardando.
2.3
Definição de Modos
De acordo com Pedro et al. (2012), na literatura, o conceito de modos de opera-ção é abordado de forma mais abrangente em trabalhos relacionados à interaopera-ção homem-computador e interação homem-automação (projeto de aviação e cockpit). De modo geral, os modos são associados à ideia de funções, estados, comportamento e escalonamento. Espe-cificamente no que tange a área de sistemas de tempo real, os trabalhos concentram-se na análise de escalonabilidade e mudanças de modo.
Ainda de acordo com Pedro et al. (2012) os modos de operação estão relacionados a: ∙ Funcionalidades: esses modos representam funções que podem ser organizadas de forma hierárquica. Um exemplo dessa classificação de modo foi apresentado em Papadopoulos (1996). Nesse trabalho, com foco em sistemas críticos de segurança, um modo é definido pelo “conjunto de funções ativas que o sistema está preparado para oferecer enquanto opera nesse modo”2. Um outro exemplo é o trabalho de Norman (1981) que afirma que
“Todo sistema de controle que pode executar uma variedade de funções possui modos: quanto mais funções, mais modos” 3.
∙ Estados especiais: esses modos são abordados principalmente na interação humano-computador e na interface. Segundo Howe (1985), assume-se que os estados estendem-se ao longo do tempo com atividades específicas sendo executadas, observando que “um modo é um estado geral, geralmente usado com um adjetivo que descreve o estado” 4.
Já os modos da interface são definidos por Tesler (1981) como “um estado da interface do usuário que dura por um período de tempo. Não está associado a nenhum objeto específico (de exibição) e não tem outra função além de colocar uma interpretação da entrada do operador” 5.
∙ Comportamento do sistema: esses modos são relacionados à interação humano-automação (por exemplo, design de interface do cockpit). Segundo Degani et al. (1999), um modo é a maneira de comportamento de um dado sistema, onde este pode possuir compor-tamento mutuamente exclusivos. Esses comporcompor-tamentos são definidos pelas entradas, saídas e estados do sistema. Assim, mudanças de modos são iniciadas em decorrência de eventos no ambiente (DEGANI; KIRLIK, 1995).
2 “set of active functions that the system is prepared to deliver while operating in that mode”
(PAPADO-POULOS, 1996)
3 “Every control system that can perform a variety of functions has modes: the more functions, the more
modes” (NORMAN, 1981)
4 “a mode is a general state, usually used with an adjective describing the state” (HOWE, 1985)
5 “a state of the user interface that lasts for a period of time. It is not associated with any particular (display)
Pedro et al. (2012) também observa que na área de ciência da computação os modos são descritos no programa (código ou executável) que encontra-se em estado de execução. Portanto, qualquer alteração no programa reflete em uma alteração no modo operacional. Um modo também pode ser considerado como uma determinada configuração do sistema durante uma fase de operação específica. Por exemplo, Degani et al. (1999) define “um modo como uma configuração de máquina que corresponde a um comportamento único” 6.
Baseado nesse contexto, Pedro et al. (2012) define “um modo de operação como o comportamento do sistema durante a execução de um determinado cronograma” 7. Também destaca que o conceito de comportamento foi usado para tratar modos com os níveis mais altos de abstração de um sistema em tempo real, como o próprio aplicativo ou o design da interface e que função e desempenho são componentes fundamentais em um sistema de tempo real. Assim, a funcionalidade do sistema está diretamente ligada ao seu desempenho e uma mudança de funcionalidade ou de desempenho do sistema tem relação direta com uma mudança de comportamento.
Baseado nas considerações apresentadas, Pedro et al. (2012) destacam a seguinte definição de modos: “Um modo de um sistema em tempo real é definido pelo comportamento do sistema, descrito por um conjunto de funções permitidas e seus atributos de desempenho e, portanto, por um único cronograma, contendo um conjunto de processos e seus parâmetros de tempo” 8 (MARTINS; BURNS, 2008).
Segundo Real e Crespo (2004), em sistemas multimodo, a aplicação é composta por vários modos de operação. Cada modo, está relacionado a comportamento e funcionalidades diferentes. Para tal, é necessário relacionar um conjunto de tarefas específico para cada modo de operação. Para maior esclarecimento sobres os tipos de modos que podem ser utilizadas, Real e Crespo (2004) citam os seguintes exemplos:
1. Modo de inicialização: virtualmente todos os sistemas de tempo real possuem uma fase de inicialização onde os recursos de hardware e os módulos de software precisam ser inicializados antes do início da operação;
2. Modo de checagem: nesse modo, o sistema testa se os diferentes dispositivos estão sob controle e operando de forma correta;
6 “a mode as a machine configuration that corresponds to a unique behavior” (DEGANI et al., 1999)
7 “a mode of operation as the system’s behavior while executing a given schedule” (PEDRO et al., 2012)
8 “A mode of a real-time system is defined by the behavior of the system, described by a set of allowable
functions and their performance attributes, and hence by a single schedule, containing a set of processes and their timing parameters” (MARTINS; BURNS, 2008)
3. Modo de emergência: o sistema precisa operar com um número reduzido de recursos, por exemplo, mediante a ocorrência de uma falha de energia;
4. Modo de alarme: o sistema opera em um estado específico devido a um acidente ou a uma situação de risco;
5. Modo de descarga de dados: alguns sistemas funcionam como marcapassos ou regis-tradores de temperatura e têm um modo de operação especial, onde fornecem dados históricos obtidos durante sua operação normal;
6. Modo de baixa potência: nesse modo o sistema otimiza a fonte de alimentação de energia, minimizando o número de atividades em execução ou sua frequência, a fim de reduzir o consumo de energia;
7. Modo de alta confiabilidade: nesse modo, técnicas como redundância são usadas para garantir que o sistema continue operando de forma funcional mesmo mediante a ocor-rência de falhas;
8. Modo de recuperação de falhas: nesse modo, a reinicialização de tarefas com falhas, ações de recuperação e diagnósticos são executados.
Um novo modo é inciado quando é detectada uma mudança no ambiente ou num estado interno do sistema. Para realizar uma mudança de modo, é necessário excluir algumas tarefas e realizar a liberação de outras (REAL; CRESPO, 2004).
2.4
Mudanças de Modo Genéricas em Sistemas de Tempo Real
Mudanças de modo em sistemas de tempo real foram introduzidas por Tindell et al. (1992). Nesse trabalho, os autores apresentaram os principais conceitos que suportam o modelo de mudança de modo, também foi apresentada uma proposta simples para o escalo-namento de tarefas durante uma mudança de modo. No entanto, para fornecer as garantias de tempo real, faz-se necessário o uso de uma análise de escalonabilidade estática que englobe todo o contexto de uma mudança de modo.
Uma outra abordagem de análise de escalonabilidade para sistemas monoprocessados de tempo real FPPS foi apresentada por Pedro e Burns (1998). Diferentemente da análise de um modo estacionário, onde o cálculo do WCRT para uma determinada tarefa avalia apenas o nível de interferência de tarefas com maior prioridade pertencendo a um único modo de operação, esta abordagem considerou o nível de interferência durante uma mudança de modo em ambos os modos (antigo e novo). Para garantir que as tarefas cumpram seus prazos
durante uma mudança de modo, as tarefas pertencentes exclusivamente ao modo novo são liberadas com um offset na sua primeira execução.
Em Real e Crespo (2004), a abordagem inicial proposta por Pedro e Burns (1998) foi estendida permitindo o uso de diferentes offsets para as tarefas que permanecem inalteradas em ambos os modos de operação (antigo e novo).
Real e Crespo (2001b) propuseram um algoritmo para atribuição automática de off-sets. O objetivo desse algoritmo consiste na priorização de promptness e a garantia de não violação do IPCP (Immediate Priority Ceiling Protocol). Esse protocolo garante que as ta-refas de menor prioridade pertencentes ao modo antigo, que compartilham recursos, não bloqueiem os recursos usados por tarefas de maior prioridade pertencentes ao modo novo. Promptness tende a permitir que tarefas de maior prioridade sejam executadas de forma prioritária durante uma janela de mudança de modo (REAL; WELLINGS, 1999).
Outra abordagem para a atribuição de offsets que minimiza a latência de mudança de modo e/ou offsets usando algoritmos genéticos foi proposta por Martins et al. (2016). A questão da minimização da latência de mudança de modo é modelada utilizando otimização com um único objetivo e também com otimização multiobjetivo. O uso de algoritmos ge-néticos trouxe maior flexibilidade, permitindo a modelagem de vários cenários de mudança de modo (MASSARO, 2015). Além disso, explorou-se neste trabalho uma abordagem para medir a latência de mudança de modo, destacando a importância de sua minimização para implementar uma mudança de modo viável.
O foco dos trabalhos apresentados anteriormente foi o uso de análise de escalonabili-dade em sistemas monoprocessados. Uma proposta de análise de escalabiliescalonabili-dade para FPPS em mudança de modo para sistemas multicore é demonstrada em Negrean et al. (2011). Essa abordagem considera a dependência entre tarefas que podem ser executadas em paralelo por diferentes processadores.
Uma outra abordagem que usa mudança de modo e escalonamento em sistema mul-ticore usando EDF (Earliest Deadline First) foi apresentada por Nelis et al. (2011). O es-calonamento usando o EDF prioriza a execução de tarefas que estão com deadline próximo. Embora seja uma abordagem de programação eficiente que elimina a etapa de atribuição de prioridade para o conjunto de tarefas, assim, proporcionando uma redução na complexidade do design do sistema, ela não substitui de forma satisfatória o FPPS quando diferentes ní-veis de criticalidade são adicionados ao modelo, porque em alguns sistemas o escalonamento usando o EDF tradicional não seria suportado (BARUAH; VESTAL, 2008). Porém, essa li-mitação foi mitigada em Ekberg e Yi (2012) onde foi proposta a utilização de um prazo de execução virtual (virtual deadline), assim permitindo que as tarefas de maior criticalidade
possam ser escalonadas prioritariamente ao utilizar a política EDF.
O uso de modos de operação e de mudanças de modos podem ser uma alternativa viável para reduzir a complexidade de projeto de sistemas de tempo real, uma vez que redu-zem o uso de recursos computacionais, como apontado por Dziurzanski et al. (2016). Nessa abordagem, os autores implementaram um sistema usando modos de operação em uma pla-taforma de hardware real em uma aplicação veicular e demonstraram que o uso de modos de operação pode reduzir o consumo de energia em até 75%.
2.4.1
Análise de Escalonabilidade para Prioridade Fixa
Nessa seção, será apesentada a análise de escalonabilidade que foi usada para calcular o tempo de resposta de pior caso de uma tarefa em uma mudança de modo. Esse modelo analítico foi utilizado para validação do modelo de simulação. Para mais detalhes sobre os fundamentos da análise de escalonabilidade em tempo real, sugere-se a leitura de Burns e Wellings (2009).
Um conjunto de tarefas é composto de tarefas periódicas ou esporádicas 𝜏 = {𝜏1, 𝜏2, . . .
𝜏𝑖, . . . 𝜏𝑝} para cada modo de operação. Cada tarefa 𝜏𝑖 é definida pelos parâmetros 𝑆𝑖 = {𝑇𝑖, 𝐷𝑖, 𝐶𝑖, 𝑃𝑖}, onde: 1) 𝑇𝑖 e 𝐷𝑖 são respectivamente o período da tarefa 𝜏𝑖 (ou, se for uma tarefa esporádica, o tempo mínimo do fluxo de chegada entre tarefas sucessivas 𝑖) e o prazo; 2) 𝐶𝑖 é o pior tempo de execução (WCET) da tarefa 𝜏𝑖. Considera-se que esse valor abrange os custos totais dada à mudança de contexto. Além disso, os valores de 𝐶𝑖, 𝐷𝑖 e 𝑇𝑖 determinam 𝐶𝑖 < 𝐷𝑖≤ 𝑇𝑖 e 3) 𝑃𝑖representa a prioridade da tarefa 𝜏𝑖, atribuída de acordo com o algoritmo de escalonamento monotônico de prazos (para FPPS).
Uma requisição de mudança de modo - Mode-Change Request - (MCR) é o evento que aciona uma transição de um modo antigo de operação para um novo modo. A janela “x” corresponde ao deslocamento entre o MCR e o ativação da tarefa 𝜏𝑖.
Existem dois tipos de offsets de tarefas 𝑂𝑖(𝑁 ): 𝑌 que é medido desde o início de uma mudança de modo (MCR) e 𝑍 que é medido a partir do final do período da tarefa anterior do modo antigo (REAL; CRESPO, 2001a). A janela 𝑥 é o período de tempo entre o MCR e a ativação da tarefa 𝜏𝑖.
A Figura 3 ilustra o modelo de mudança de modo. O sistema passa por três estágios distintos: ao receber uma solicitação de mudança de modo, o sistema passa de um modo antigo (estado estacionário) para um período transitório de mudança de modo e finaliza o processo ao operar em novo modo de operação em estado estacionário. A simples equação de análise monotônica de prazo iterativo garante a escalonabilidade de tarefas no estado estacionário. Dado o modo atual, uma requisição de mudança de modo (MCR) e um conjunto
Modo Antigo Modo Novo Y1 Inalteradas Completadas Abortadas Alteradas x Z Y2 L Tarefas τ1 τ2 τ3 τ4 Mudança de Modo
Requisição de Mudança de Modo (MCR)
Fim de Mudança de Modo Tempo
τ5 Totalmente
Novas
Figura 3 – Modelo de mudança de modo
de tarefas, o objetivo da análise de escalonabilidade de pior caso em mudança de modo, é descobrir se as tarefas são escalonáveis durante o processo de transição. Inerente à análise de escalonabilidade, está o fato de que tarefas antigas que para completar sua execução avançam através do período de mudança de modo, interferem e sofrem interferência de novas tarefas liberadas durante a mudança de modo.
A análise de escalonabilidade da mudança de modo é dividida em duas partes: análise das tarefas do modo antigo e análise das tarefas do novo modo, como segue:
2.4.1.1 Análise para tarefas do modo antigo
O nível de interferência das tarefas do modo antigo é dado de acordo com a classifi-cação dos tipos de tarefas:
1. Interferência de tarefas concluídas do modo antigo de prioridade mais alta 𝐼ℎ𝑝(𝑖)𝑂;
2. Interferência de tarefas abortadas de prioridade mais alta 𝐼ℎ𝑝(𝑖)𝐴;
3. Interferência de tarefas de modo novo de prioridade mais alta 𝐼ℎ𝑝(𝑖)𝑁, e 4. Interferência de tarefas inalteradas ℎ𝑝(𝑖)𝑈.
Combinando a análise de interferência de cada tipo de tarefa, obtemos o modelo de análise do modo antigo, dado pela seguinte equação de recorrência:
𝑤𝑖𝑛+1= 𝐶𝑖+ 𝐵𝑖+ ∑︁ ∀𝑗∈ℎ𝑝(𝑖)𝑂 ⌈︃ 𝑥 𝑇𝑗 ⌉︃ 𝐶𝑗+ ∑︁ ∀𝑗∈ℎ𝑝(𝑖)𝐴 (︃⌊︃ 𝑥 𝑇𝑗 ⌋︃ 𝐶𝑗+ 𝑚𝑖𝑛 (︃ 𝑥 − ⌊︃ 𝑥 𝑇𝑗 ⌋︃ 𝑇𝑗, 𝐶𝑗 )︃)︃ + ∑︁ ∀𝑗∈ℎ𝑝(𝑖)𝑁 ⌈︃ 𝑤𝑛𝑖 − 𝑥 − 𝑌𝑗 𝑇𝑗 ⌉︃ 0 𝐶𝑗+ ∑︁ ∀𝑗∈ℎ𝑝(𝑖)𝑈 ⌈︃ 𝑥 𝑇𝑗 ⌉︃ 𝐶𝑗 + ⌈︃ 𝑤𝑛𝑖 − ⌈𝑥/𝑇𝑗⌉𝑇𝑗− 𝑍𝑗 𝑇𝑗 ⌉︃ 0 𝐶𝑗 (2.1)
A notação ⌈𝑧⌉0 denota uma função de teto modificada, que retorna zero se 𝑍 < 0. O
valor inicial de 𝑤𝑖 é definido como zero. Isso demonstra que 𝑤𝑛+1𝑖 > 𝑤𝑛𝑖 e, portanto, a relação de recorrência é executada enquanto os valores não convergirem (ou seja, 𝑤𝑖𝑛+1 = 𝑤𝑖𝑛) ou quando algum limite for excedido, como 𝐷𝑖. Contudo, o pior caso para a tarefa de resposta 𝑅𝑖, que deve então ser comparado com o respectivo prazo, é dado por 𝑅𝑖 = 𝑤𝑖 + 𝐶𝑖.
2.4.1.2 Análise para tarefas do modo novo
Como as tarefas do novo modo sofrem com a interferência de outras tarefas antigas e novas de maior prioridade, precisa-se garantir seu escalonamento durante a mudança de modo. Se, no entanto, uma nova tarefa 𝜏𝑖 tem um offset tal que sua primeira liberação ocorre após todas as tarefas do modo antigo de prioridade mais alta serem concluídas, seu escalonamento é garantido pela análise de escalonabilidade de estado estacionário. A interferência sofrida a partir de uma nova tarefa de modo é analisada da seguinte forma:
1. Interferência de tarefas do modo antigo de maior prioridade ℎ𝑝(𝑖)𝑂; 2. Interferência das tarefas pertencentes apenas ao novo modo 𝐼ℎ𝑝(𝑖)𝑁, e
3. Interferência de tarefas inalteradas ℎ𝑝(𝑖)𝑈.
dado por: 𝑤𝑛+1𝑖 = 𝐵𝑖+ ∑︁ ∀𝑗∈ℎ𝑝(𝑖)𝑂 𝐶𝑗+ ∑︁ ∀𝑗∈ℎ𝑝(𝑖)𝑁 ⌈︃ 𝑤𝑖𝑛− 𝑌𝑗 𝑇𝑗 ⌉︃ 0 𝐶𝑗+ ∑︁ ∀𝑗∈ℎ𝑝(𝑖)𝑈 (︃ 𝐶𝑗+ ⌈︃ 𝑤𝑖𝑛− 𝑇𝑗− 𝑍𝑗 𝑇𝑗 ⌉︃ 0 𝐶𝑗 )︃ (2.2)
O valor inicial de 𝑤𝑖 é definido como zero. Pode ser mostrado que 𝑤𝑖𝑛+1 > 𝑤𝑖𝑛 e, portanto, a relação de recorrência termina quando existe convergência (ou seja, 𝑤𝑖𝑛+1 = 𝑤𝑛
𝑖) ou quando algum limite for excedido, como 𝐷𝑖. No entanto, o pior caso para a tarefa de resposta 𝑅𝑖, que deve então ser comparado com o respectivo prazo, é dado por 𝑅𝑖 = 𝑤𝑖 -𝑌𝑖.
2.5
Sistemas de Tempo Real com Criticalidade Mista
Restrições rígidas de tempo real nem sempre são necessárias em alguns sistemas. Em algumas aplicações reais, existem tarefas com diferentes níveis de criticalidade e nesses mo-delos de sistemas é aceitável que tarefas de baixa criticalidade suportem a perda de alguns prazos, dentro de padrões aceitáveis. O trabalho de Vestal (2007) abordou a análise de WCRT para sistemas monoprocessadores e demonstrou que nem a taxa monotônica nem as atribui-ções de prioridade monotônica foram satisfatórias para uso em Mixed-Criticality Systems (MCS), assim, o autor sugeriu a utilização do algoritmo proposto por Audsley (2001). Em Baruah e Vestal (2008), o trabalho apresentado por Vestal (2007) foi estendido para permitir a utilização de tarefas esporádicas. Além disso, essa abordagem demonstrou que o EDF não supera o FPPS quando os níveis de criticalidade são levados em consideração.
Para prover as garantias de tempo real necessárias para aplicações reais, uma análise de escalonabilidade preemptiva de FPPS para MCS utilizando um sistema monoprocessado foi proposta em Baruah et al. (2011). Essa proposta permitiu o uso de dois níveis de criticali-dade. Uma nova abordagem que permitiu a implementação de múltiplos níveis de criticalidade usando sistemas multicore foi introduzida por Pathan (2012). No entanto, essa abordagem é limitada porque não permite que uma tarefa altere seu período entre diferentes níveis de criticalidade.
Ekberg e Yi (2012) propuseram uma abordagem em que incorporaram ao escalona-mento EDF características similares ao esquema FPPS através da atribuição de dois prazos relativos a cada tarefa de alta criticalidade. O primeiro prazo representa o prazo “real” da tarefa e o segundo um prazo “virtual”. O prazo virtual é usado para aumentar a probabilidade
de que tarefas de alta criticalidade sejam executadas antes de tarefas de baixa criticalidade. Uma extensão desse trabalho foi apresentada em Ekberg e W.Yi (2014), onde os autores intro-duziram o uso de mais de dois níveis de criticalidade e permitiram mudanças nos parâmetros da tarefa. No entanto, sua proposta foi projetada para ser usada em sistemas monoprocessa-dos. Uma nova abordagem que permitiu o uso da análise de escalonabilidade usando o EDF em criticalidade mista usando multicore foi apresentada por Baruah et al. (2014). Esse tra-balho é baseado no mesmo conceito de prazos virtuais introduzidos por Ekberg e Yi (2012) e propõe um algoritmo de escalonamento chamado EDF-VD, onde a validação da análise teó-rica foi realizada através da simulação. Em sua proposta, as tarefas de maior prioridade têm seus prazos reduzidos (se necessário) durante a execução de um modo de baixa criticalidade.
2.6
Mudanças de Modo em Sistemas de Tempo Real de Criticalidade
Mista
Uma discussão sobre mudanças de modo geral e sua relação com sistemas de critica-lidade mista foi apresentada por Burns (2014). Esse trabalho elencou os principais conceitos envolvidos e propôs formas de permitir o uso de mudanças de modo em sistemas de critica-lidade mista. Além disso, Burns (2014) concluiu que em mudanças de criticacritica-lidade (isto é, mudanças de baixa para alta criticalidade) são as mais próximas a uma mudança grosseira após a falha parcial do sistema, enquanto as mudanças de alta para baixa têm mais em comum com uma mudança funcional.
Outra proposta relevante que aborda mudanças de modo geral e coexistência de criti-calidade mista no mesmo sistema foi apresentada por Niz e Phan (2014). Nesse trabalho, foi apresentada uma abordagem de escalonamento particionado para multiprocessadores em sis-temas multimodais de tempo real de criticalidade mista, onde foi observado que é necessário prover garantias temporais para o sistema em relação às criticalidades das tarefas, não apenas dentro de cada modo, mas também durante as mudanças de modo. Seu esquema consiste em um algoritmo de empacotamento e um algoritmo de escalonamento para cada processador que leva em consideração tanto as mudanças de modo quanto as de criticalidade.
2.7
Tolerância à Falhas em Sistemas de Tempo Real
Um sistema tolerante a falhas é provido de garantias que permitem a continuidade de sua operação mesmo sob a presença de falhas. Tais garantias possivelmente irão comprometer o desempenho normal do sistema, porém, mantendo as suas funcionalidades. Sistemas dessa
natureza são utilizados em operações críticas onde faz-se necessário que o sistema mantenha sua condição operacional mesmo sob condições adversas (AVIZIENS, 1976; JOHNSON, 1984). Apesar dos esforços despendidos na fase de desenvolvimento, não é possível garantir que todas as falhas de software serão eliminadas. Outro aspecto a ser considerado é que durante a execução do sistema o hardware pode apresentar problemas devido a falhas in-ternas ou exin-ternas. Por isso, os Sistemas de Tempo Real - Real-Time Operation Systems (RTOS) - devem incorporar mecanismos que permitam que o sistema não tenha suas funcio-nalidades críticas comprometidas mesmo sob a presença de erros e/ou falhas (RAMEZANI; SEDAGHAT, 2013).
As estratégias de tolerância à falhas em RTOS normalmente estão ligadas à alta disponibilidade de recursos por meio da replicação de hardware, dessa forma, provendo um cenário que permita que o sistema tenha condições normais de operação mesmo sob a presença de falhas (MELLIAR-SMITH; MOSER, 2004). Porém, tais estratégias podem ser inviáveis em sistemas onde existem restrições quanto a peso e espaço, como por exemplo, em missões espaciais, assim, a redundância de tempo se torna crucial (PUNNEKKAT, 1997).
A redundância de tempo é provida por meio de blocos de recuperação, reexecução da tarefa afetada ou por ponto de recuperação (checkpointing) e reversão (roolback). Dentre as estratégias de tempo citadas, o ponto de recuperação e reversão é um método que dispende menor necessidade de recursos para prover tolerância a falhas em RTOS. De forma distinta à estratégia de reexecução, a utilização de pontos de recuperação consiste na recuperação do estado de execução do sistema (dados de variáveis e conteúdo dos registros do sistema) armazenados no último ponto de recuperação. Para isso, o armazenamento do estado em cada ponto de recuperação requer um local confiável e garantias de que o sistema esteja operando em um estado seguro, ou seja, sem a presença de falhas. Assim, quando uma falha é detectada, o sistema recupera o estado de execução armazenado no último ponto de recuperação, dessa forma, restaurando sua operação normal. Essa estratégia permite reduzir o tempo de recuperação do sistema após a ocorrência de falhas devido ao salvamento de estados intermediários de uma tarefa em um local de armazenamento estável (ZHENGYONG et al., 2014).
2.8
Predição
Os métodos de previsão usam modelos estatísticos baseados nos princípios de infe-rência estatística. O conhecimento prévio de uma amostra de uma população pode ser usado para prever outros parâmetros populacionais relacionados ao mesmo ou a diferentes momen-tos no tempo. Exemplos de técnicas estatísticas empregadas para previsão incluem (mas não
se limitam) a análise de regressão e suas subcategorias, como regressão linear e modelos li-neares generalizados (regressão logística, regressão de Poisson, regressão de probits) (COX, 2006). A seguir serão apresentados os principais mecanismos de predição utilizados.
2.8.1
Filtro de Kalman
O filtro de Kalman ou estimador quadrático linear linear quadratic estimation -(LQE), consiste em um algoritmo que utiliza dados observados ao longo do tempo, conta-minados por ruídos e incertezas, para estimar valores de variáveis. O filtro de Kalman foi nomeado em homenagem a Rudolf Kalman, embora Thorvald Nicolai Thiele e Peter Swerling já haviam desenvolvido anteriormente algoritmos similares (LAURITZEN, 1981; LAURIT-ZEN, 2002). Os trabalhos de Swerling (1958), Kalman (1960) e Kalman e Bucy (1961) foram os percursores, que descreveram os princípios básicos para implementação do filtro de Kal-man.
Durante uma visita ao NASA Ames Research Center, Kalman identificou a possibi-lidade de aplicação do filtro de Kalman para estimativa de trajetórias no programa Apollo. Assim, a solução proposta acabou sendo incorporada com sucesso ao sistema de navegação do programa. Além disso, o filtro de Kalman, ao longo do tempo, vem sendo incorporado com êxito em diversas aplicações, onde é possível destacar sua utilização em sistemas de navegação de submarinos, em sistemas de direcionamento e navegação de mísseis, como por exemplo o Tomahawk que é utilizado pela marinha americana, em sistemas de navegação de ônibus espaciais (GAYLOR; LIGHTSEY, 2003).
O método de Kalman (Linear Discreto) consiste em sistemas dinâmicos lineares dis-cretizados no domínio do tempo, cuja modelagem é realizada em uma cadeia de Markov com operadores lineares cujas pertubações são dadas a partir de distribuições normais.
Figura 4 demonstra a abordagem utilizada pelo filtro de Kalman, onde os círculos representam vetores, quadrados representam matrizes, e estrelas o ruído gaussiano associado à matriz de covariância. Abaixo estão descritas as equações de estados que compõem o modelo de Kalman (observação e modelagem).
𝑦𝑘 = 𝐻𝑥𝑘+ 𝑣𝑘 (2.3)
e,
𝑥𝑘+1 = Φ𝑥𝑘+ 𝐺𝑢𝑘+ Γ𝑤𝑘 (2.4)
