Derivando Uma Falha de Resiliência Métrica para Sistemas em Tempo Real

...

Dado um conjunto de tarefas e uma política de escalonamento, o papel da análise de escalonabilidade é verificar se as tarefas cumprem seus prazos. Por exemplo, é bem conhecido que sob RM um conjunto de tarefas é escalonável se a relação na equação se mantém.[pic 4][pic 5]

[pic 6]

Para EDF, a escalonabilidade deve ser assegurada se, e somente se,

[pic 7]

Normalmente, a escalonabilidade do sistema é avaliada em cenários livres de falhas, embora estes tipos de equações sejam estendidas para tirar os efeitos de erros. Por exemplo, considerando um conjunto de tarefas agendado por RM em que ocorre um único erro durante um hiper período. A equação (1) pode ser facilmente adaptada para

[pic 8]

Supondo que uma tarefa é liberada no tempo , o seu prazo absoluto é dado por . O prazo relativo de cada tarefa não é maior do que o seu período . Além disso, as tarefas são assumidas como sendo independentes umas das outras e o seu pior caso de tempo de execução é conhecido e não é maior do que o min . A tolerância ao erro é fornecida através da execução de ações de recuperação após a detecção de erro. Estas ações, na verdade, representam a execução de qualquer código extra. A ação de recuperação associada a um determinado erro em pode ser uma re-execução de ou a execução de uma tarefa alternativa. Se erros são detectados durante a recuperação de , outras ações de recuperação podem ser liberadas.[pic 9][pic 10][pic 11][pic 12][pic 13][pic 14][pic 15][pic 16][pic 17][pic 18]

É interessante notar que este modelo está em linha com a maioria das técnicas de tolerância à falhas baseadas em redundância temporal, tais como blocos de recuperação ou de manipuladores de exceção, que tem sido amplamente aplicada aos sistemas em tempo real e pode ser implementado no nível da tarefa.

A fim de considerar a possibilidade de erros em sistemas de tempo real, um pior caso de erro é assumido. Em seguida, a avaliação atual é considerada sob tais circunstâncias. Por exemplo, em algumas abordagens são assumidos erros para ocorrer uma vez no hiper período, que é definido como o mínimo múltiplo comum de períodos de tarefas. Todas estas premissas são usadas ​​para tornar possível a incorporação dos efeitos devido a erros na análise. No entanto, eles não são adequados para representar a resiliência à falhas do sistema. De fato, o sistema pode lidar com mais do que o que foi assumido uma vez que apenas os cenários de pior caso foram considerados para fins de análise de escalonabilidade.

A falha de resiliência foi analisada por alguns autores através da verificação se o que tem assumido no pior caso é violado. Por exemplo, considerando uma distribuição de Poisson para a ocorrência de erro, um limite superior para a probabilidade de que o erro toma menos do que aquilo que é assumido foi derivado. Em outras abordagens, o número máximo de erros assumido foi considerado ser uma função de uma falha probabilística. No entanto, uma vez que os piores cenários dificilmente ocorrem, estas abordagens podem também ser pessimistas. Além disso, os padrões de erro assumidos são fortemente ligados com o sistema modelo de programação. Assim, torna-se difícil ou mesmo impossível de comparar diferentes sistemas a partir da perspectiva de falha de resiliência.

Uma proposta métrica mais geral tem como objetivo mensurar a resiliência do sistema para diferentes sistemas e modelos de falha. Apesar de não assumir uma política de programação especial, é limitado a essas políticas cujos trabalhos agendados têm prioridades fixas, tais como taxa de Monotonic e Earliest Deadline First.

3. Falha de resiliência métrica

A fim de dar uma intuição sobre a necessidade de uma falha de resiliência métrica, deve ser considerado o seguinte exemplo.

Exemplo 1: Supõe-se que seja um conjunto tarefa composta de duas tarefas periódicas = {Ƭ1, Ƭ2}. Assumir . Além disso, considere que a taxa Monotonic é usada para agendar as tarefas e assim Ƭ1 é a tarefa de mais alta prioridade. A Figura 1 mostra o agendamento para este conjunto de tarefas, considerando que não ocorra nenhum erro. Acima das setas, é o tempo médio de liberação tarefas.[pic 19][pic 20][pic 21]

[pic 22]

Figura 1 – Ilustração de um cronograma de RM para o conjunto de funções descritas no Exemplo 3.1.

O hiper período para este conjunto de tarefas é dado por . Observe que Ƭ1 tem cinco postos de trabalho dentro de , que são liberados nos tempos 0, 2, 4, 6 e 8, enquanto que Ƭ2 tem dois postos de trabalho

lançados nos tempos 0 e 5. Por causa de sua prioridade, o primeiro trabalho de Ƭ2 começa a executar em tempo 1. A linha pontilhada indica que Ƭ2 aguarda até que os postos de trabalho de maior prioridade terminem de ser executados.[pic 23][pic 24]

Assume-se que a recuperação baseia-se na nova execução dos trabalhos defeituosos. A Figura 2 apresenta o cronograma para o conjunto de tarefas mostrado no exemplo anterior. Nota-se que após o momento em que o erro ocorre, em tempo de 2, 6 e 8, o trabalho de recuperação (mostrado em cinza) é executado para manter a exatidão do sistema. Além disso, observa-se que a tarefa Ƭ2 pode lidar com um número diferente de erros dentro de 5 unidades de tempo. No intervalo de tempo [0, 5), o emprego de Ƭ2 pode lidar com apenas um único tipo de erro, enquanto que, no tempo 5 a 10, tal trabalho pode se recuperar de, no máximo, dois erros e ainda cumprir o prazo.

[pic 25]

Figura 2. Ilustração de Ƭ2 no Exemplo 3.1 sujeita a erros dentro de h.

Os planejamentos apresentados na Figura 2, dão a intuição de que a falha de resiliência métrica deve refletir o número de falhas que o sistema pode tolerar. Assim, assumindo que se deseja analisar o comportamento de um dado sistema quando é sujeito a falhas, o método de análise deve usar algumas falhas de resiliência métrica. Entende-se que tais métricas devem ter a seguinte hipótese em consideração. [pic 26]

Hipótese 1. A falha de resiliência de um sistema é proporcional ao número de erros. Na verdade, as falhas de resiliência métrica devem refletir a capacidade do sistema para manter o seu comportamento correto, após ocorrências de erro. Além disso, do ponto de vista dos designers