Tempo Real - Sistemas de Tempo Real

Sistemas de Tempo Real
CONCEITOS BÁSICOS
Conceitos Básicos
 Computador de Tempo Real
é aquele em
que o bom funcionamento do sistema
depende não apenas dos resultados
lógicos da computação, mas também do
tempo no qual eles são produzidos.
 Um computador de tempo real
normalmente faz parte de um sistema de
tempo real.
Conceitos Básicos
 Um sistema de tempo real muda seu estado
em função do tempo.
 Para efeito de análise é útil de dividir este
sistema em conjuntos (clusters).
 Cluster operador, cluster computacional,
cluster controlado
Conceitos Básicos
 Sistema de tempo real distribuído:
conjunto de nós computacionais
interconectados por uma rede de
comunicação de tempo real.
Conceitos básicos
 Um computador de tempo real deve reagir
a um estimulo de um objeto controlado
dentro de um intervalo de tempo definido
por seu ambiente.
 O instante no qual o resultado deve ser
apresentado é chamado de deadline.
Conceitos básicos
 Se o resultado tiver utilidade mesmo após
o deadline ter expirado, o deadline é
denominado de soft, caso contrário de firm.
 Se uma catástrofe resultar do não
cumprimento do deadline, ele é dito hard.
 Um computador que tenha pelo menos um
deadline hard é denominado de
computador de tempo real hard.
Requisitos de um sistema de
tempo real
 Funcionais
 Temporais
 Dependabilidade
Requisitos Funcionais
 Coleta de dados
 Controle digital direto
 Interação homem-máquina
Requisitos funcionais: coleta de
dados
 Um objeto controlado muda de estado com
o tempo, podendo seu estado atual ser
descrito pelo registro dos valores de suas
variáveis de estado naquele momento.
 Nem todas as variáveis de estado são de
interesse.
 Entidades de tempo real (ETD): variáveis de
estado significativas.
Requisitos funcionais: coleta de
dados
 Cada ETR está na esfera de controle de um
subsistema, podendo apenas ele mudar o
estado desta ETR.
 Fora desta esfera de controle, a ETR não
pode ser modificada, mas pode ser
observada.
Requisitos funcionais: coleta de
dados
 Requesito:
observação das ETR em um
objeto controlado e a coleção destas
observações.
 Observação = imagem da ETR.
 A imagem tem uma fidelidade com respeito
à sua respectiva ETR que é temporária. Este
tempo depende da dinâmica do objeto
controlado.
Requisitos funcionais: coleta de
dados
 Base de dados de tempo real: conjunto de
todas as imagens dos ETR que sejam
fidedignas em um dado instante.
 A base deve ser atualizada sempre que uma
ETR muda de estado.
Requisitos funcionais: coleta de
dados
 A atualização da base de dados pode ser
feita: de tempos em tempos dado por um
relógio de tempo real (observação
engatilhada pelo tempo); ou
imediatamente após a mudança de estado
(evento) de uma ETR (observação
engatilhada por evento)
Requisitos funcionais:
condicionamento do sinal
 Dimimuir o erro de medida através de um
processo de cálculo de média.
 Transformar o sinal em unidades de
medida padrão (calibragem).
 Testar a coerência da medida.
Requisitos funcionais:
Monitoramento de alarmes
 Detecção de comportamento anormais de
ETRs.
 Registro dos alarmes.
 Ordem de acionamento dos alarmes pode
auxiliar na solução do problema.
Requisitos funcionais: Controle
digital direto
 O computador de tempo real deve calcular
os “set-points” para os atuadores e
controlar o objeto controlado diretamente.
 O algorítmo de controle deve levar em
conta distúrbios aleatórios.
Requisitos funcionais: Interação
homem-máquina
 Deve informa o operador sobre o estado
atual do objeto controlado.
 Deve assistir o operador no controle do
objeto.
 Fonte de problemas : mal operação.
 Interfaces amigáveis
Requisitos Temporais
 Controle de processos com laços de
controle de tempo crítico.
 Requisitos temporais da interface homemmáquina não são críticos.
Controle da válvula de controle
de fluxo de calor
Tempos de retardo e subida da
resposta ao degrau
Simbolo
Parâmetro
Esfera de Controle
Relacionamentos
dobjeto
Delay do
objeto
controlado
Objeto controlado
Processo físico
drise
Rise time da
resposta ao
step
Objeto controlado
Processo físico
dsample
Período de
amostragem
Computador
dsample << drise
dcomputer
Delay do
computador
Computador
dcomputer < dsample
Δdcomputer
Jitter do delay Computador
do
computador
Δdcomputer << dcomputer
ddeadtime
Dead time
dcomputer + dobjeto
Computador e
objeto controlado
Latência mínima do Jitter
Jitter delays trazem uma incerteza adicional no loop
de controle que tem um fator adverso na qualidade
do controle
O jitter pode ser visto como uma incerteza sobre o
instante que a entidade de tempo real foi observada.
Esse jitter pode ser interpretado como causador de
um erro adicional no valor ΔT da variável de
temperatura medida.
O delay jitter deve ser sempre uma pequena fração
do delay (d = 1 ms; delay jitter = µsecs)
Latência minima na deteção de
erros
Aplicações Hard Real-time são safety critical
A latência na deteção de erros deve ser da mesma
ordem de magnitude que o período de amostragem
do loop de controle mais rápido.
Isso torna possível se tomar ações corretivas antes
que falhas o erro cause grandes defeitos no sistema.
Sistemas sem jitter sempre terão menor latência de
deteção de erros.
Dependabilidade
Cobre atributos metafuncionais de um sistema de
computador que se relacionam com a qualidade do
serviço que um sistema entrega a seus usuários
durante um intervalo de tempo.
R(t) = exp (-λ(t – t0))
MTTF = 1/ λ
Safety
Safety é confiabilidade considerando modos de
falhas críticos (critical failures modes)
Safety critical Hard Real-time são devem ter uma
taxa de falhas com relação a modos de falhas
críticos em no nível de requisitos de confiabilidade
ultra-high (10-9 falhas/hora)
Mantenabilidade
(Maintainability)
Medida do tempo requerido para reparar um
sistema após a ocorrência de uma falha.
Medida pela probabilidade M(d) que o sistema
esteja restaurado após um intervalo de tempo d
após a falhas.
MTTR = 1/µ
Conflito confiabilidade e mantenabilidade.
Disponibilidade (Availability)
Probabilidade que o sistema esteja disponível em
um tempo t+t1, dado que ele estava operacional em
t.
A = MTTF/(MTTF + MTTR)
MTBF = MTTF + MTTR
Relacionamento entre MTTF,
MTTR e MTBF
Estado do sistema
Falha
Falha
up
down
MTTR
MTTF
MTBF
Segurança
Habilidade de um sistema evitar que pessoas nãoautorizadas acessem uma informação.
CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time : Tempo
de Resposta
 Hard real-time na ordem de milisegundos
ou menos (inviável para intervenção
humana) devendo ser altamente autônomo.
 Soft real-time podem ser da ordem de
segundos, sem graves consequencias em
caso de perda do deadline
CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time :
Desempenho em carga
 Hard real-time – cenário de pico de carga
deve ser bem definido e projeto deve
gararantir que deadlines serão satisfeitos
em todas condições.
 Soft real-time – desempenho médio é que é
importante e operação degradada pode ser
tolerada em raros casos de pico de carga
CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time : Controle
de passo
 Hard real-time -
computador deve
permanecer em sincronia com o estado do
objeto controlado em todos cenários
operacionais.
 Soft real-time - pode exercer algum
controle sobre o objeto controlado caso
não possa processar a carga (extensão do
tempo de resposta)
CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time : Safety
 Hard real-time -
deteção de erros deve ser
autônoma para o sistema iniciar ações de
recuperação dentro do intervalo de tempo
ditado pela aplicação.
CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time :
Tamanho dos arquivos de dados
 Sistemas de TR têm pequenos arquivos de
dados (RT Database) que é composto de
imagens de entidades de TR.
 Sistemas hard real-time têm ênfase em
preservar a fidelidade do RT Database em
curto intervalo de tempo
 Sistemas de processamente de transações
a ênfase é na manutenção da intridade dos
dados de DB-RT por longo período
CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time : Tipo de
Redundância
 Sistemas on-line – Rollback
 Hard real-time – rollback não tem muita
utilidade: dificuldade de garantir deadline;
objeto não-recuperável; fidelidade
temporal dos dados no ponto de
recuperação em relação ao tempo “agora”
CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time : Fail-Safe
versus Fail-operational
 Para sistemas com hard real-time, um
estado seguro dever existir no caso de uma
falha crítica (fail-safe). Estado seguro é
uma característica do objeto controlado e
sistema deve ter alta cobertura de falha.
Caso watchdog
 Inexistência de estado seguro (aviação):
sistema deve prover um mínimo nível de
serviço em caso de falha crítica
CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time :
Resposta Garantida versus Melhor Esforço
 Resposta Garantida: se a partir de uma
dada hipótese de carga e falha, é possível
produzir um projeto que torne possível
avaliar a sua adequação sem referência a
argumentos probabilísticos, mesmo no
caso de pico de carga e cenário de falha
(requer análise complexa)
 Caso contrário: melhor esforço (difícil se
garantir operação correta)
:CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time: Recursos
Adequados X Recursos Indequados
 Sistemas com Resposta Garantida são
baseados em Recursos Adequados (No
suficiente em caso de pico de carga e
falha).
 Muitos sistemas que não são safety critical
são baseados em Recursos Inadequados
(viabilidade econômica).
Compartilhamento de recursos e
argumentos probabilísticos.
CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time : EventTriggered versus Time-Triggered
 Uma ocorrência no fluxo de tempo real
(clock) é um evento: inicio, fim, intervalo
 Um trigger é um evento que causa o inicio
de alguma ação (ex: execução de tarefa,
envio mensagem)
 Dependendo do mecanismo de
engatilhamento: evento (mudança de
estado); tempo, ações iniciadas em pontos
pré-determinados do tempo
CLASSIFICAÇÃO DE SISTEMAS DE TEMPO REAL:
Hard real-time X Software real-time : EventTriggered versus Time-Triggered
 Em sistemas engatilhado por tempo, todas
atividades são iniciadas pela progressão
do tempo.
 A base de dados de tempo real deve ser
atualizada sempre que uma entidade de
tempo real mudar de valor, quer
periodicamente (time-triggered), ou após
um evento que muda o estado do sistema.
CLASSIFICAÇÃO DE SISTEMAS DE
TEMPO REAL
Característica
Hard Real-Time
Soft-Real Time
(on-line)
Tempo de resposta
Hard-required
Soft-required
Peak-load performance
Predizível
Degradado
Controle de passo
Ambiente
Computador
Safety
Frequentemente
crítico
Não crítico
Tamanho dos arquivos de dados
Pequeno/médio
Grande
Tipo de redundância
Ativa
Checkpoint
recovery
Integridade dos dados
Short-term
Long-term
Deteçao de erros
Autônomo
Assistida pelo
usuário
Fail-Safe X Fail-Operational
Para alguns sistemas hard real-time, um ou mais
estados seguro (safe states) podem ser identificados
em caso de falha no sistema
Watchdog timers
Para alguns sitemas, estados seguros não podem ser
identificados. Nesse caso, o computador deve
fornecer um mínimo de serviço par evitar falhas
catastróficas.
Resposta Garantida X Melhor
Esforço
Se começarmos com uma hipótese de carga e falha
e fornecermos um projeto que seja possível
corresponder a esses requisitos sem referência a
argumentos probabilísticos, então, mesmo no caso
de carga no pico e cenários de falhas, pode-se falar
de um sistema com resposta garantida; caso
contrário falamos de um projeto com Melhor
Esforço.
Recursos Adequados X Recursos
não adequados
Sistemas de Resposta Garantida são baseados o
princípio de Recursos Adequados; os recursos são
suficientes mesmos no evento de carga máxima
e/ou falhas.
Disparo por Eventos X Disparo
por Tempo
Um disparo (trigger) é um evento que causa o
inicio de uma ação (execução de tarefa,
comunicação, etc).
Na abordagem Disparo por Evento, toda atividade
de computação e comunicação são iniciadas sempre
que ocorra uma mudança significativa de estado.
Na abordagem Disparo por Tempo, toda atividade
de computação ou comunicação são iniciadas em
pontos pré-determinados no tempo.
MODELANDO SISTEMAS DE TEMPO
REAL
Propósito do Modelo
Suposições do modelo para um sistema tolerante a
falhas de tempo real: hipótese de carga e hipótese de
falha
Afirmações sobre tempo de resposta podem somente
ser feitas sob a suposição que a carga do sistema
esteja abaixo da carga máxima (peak load): hipótese
de carga.
Propósito do Modelo
Um computador tolerante a falhas é projetado para
tolerar todas as falhas que são cobertas pela hipótese
de falhas as quais ele deve lidar.
Se as falhas que ocorrem no mundo real não são
cobertas pela hipótese de falhas, então, mesmo um
sistema de computador tolerante a falhas
perfeitamente projetado irá falhar
O que é relevante
Noção de Tempo Real: a progressão do tempo físico
é de importância central em um computador de
tempo real
Duração das ações: a execução de um comando
constitui uma ação.
A duração (tempo de execução) de uma ação
computacional ou comunicação entre a ocorrência de
um estímulo e a ocorrência da resposta associada
uma medida muito importante no domínio do tempo.
O que é relevante
Dada uma ação a, distingue-se as quatro quantidades
seguintes que descrevem seu comportamento
temporal:
Duração real (ou tempo de execução real): dada um
conjunto de entrada x, denota-se por c, o número de
unidades de tempo do clock de referência z que
ocorrem entre o começo o inicio de a até seu término
O que é relevante
Duração mínima (cmin): menor intervalo de tempo
para completar uma ação a, quantificada sobre todos
os dados de entrada possíveis.
Pior Caso para Tempo de Execução (Worst-Case
Execution Time): WCET é a duração máxima para
se completar uma ação a sob as hipóteses de carga e
falha, quantificada sobre todos os dados de entrada
possíveis.
O que é relevante
Jitter: jitter para uma ação a é a diferença entre
WCET e Cmin.
Frequencia de Ativações: número máximo de
ativações de uma ação por unidade de tempo.
Associado à frequencia tem-se o Período (p) de uma
ação a, ou tempo de ciclo (cycle time)
Deadline (d) de uma ação a é o instante que o
resultado de uma ação deve ser produzida.
Elementos Estruturais
Visto externamente, uma aplicação de tempo real
tolerante a falhas pode ser decomposta em um
conjunto de clusters computacionais que se
comunicam.
Cada cluster computacional pode ainda ser
particionado em um conjunto de unidades tolerantes
a falhas (FTUs) conetadas por uma rede local de
tempo real. Cada FTU consiste de um ou mais nós
computacionais.
Elementos Estruturais: Tarefas
(Tasks)
Uma tarefa é a execução (em um nó) de um
programa sequencial, que começa pela leitura de um
dado de entrada e o estado interno da tarefa, e
termina com a produção dos resultados e a
atualização do estado interno da tarefa. O intervalo
de tempo entre o inicio e o término caracteriza seu
tempo de execução c, em um dado hardware.
O Sistema Operacional (SO) gera um sinal de
controle que inicia a execução de uma tarefa.
Elementos Estruturais: Tarefas
(Tasks)
Uma tarefa que não tem um estado interno no ponto
que ele é ativada é chamada tarefa sem estado
(stateless tak); caso contrário, ela é chamada tarefa
com estado.
Tarefa Simples (S-Task): não existe nenhum ponto
de sincronização dentro da tarefa, isto é, quando ela
inicia, ela continua até seu término. Uma vez que ela
não pode ser bloqueada dentro do corpo da tarefa,
seu tempo de execução não depende diretamente do
progresso de outras tarefas no nó computacional (c
pode ser extendido devido a preempção)
Elementos Estruturais: Tarefas
(Tasks)
Tarefa Complexa (C-Task): contém uma comando de
sincronização blocante (semáfore Wait) dentro do
corpo da tarefa, devido ao fato dela ter que esperar
por uma condição ocorra fora da tarefa, ou até a
chegada de uma dada entrada.
O WCET de uma C-Task em um nó é uma questão
global porque ela depende diretamente do progresso
de outras tarefas no nó, ou dentro do ambiente do nó.
Processos Periódicos e
Esporádicos
Periódicos: são ativados em intervalos fixos de
tempo. São usados tipicamente para monitoramento
sistemático, polling, amostragem de informações de
sensores em longos intervalos de tempo.
Um processo periódico tem uma quantidade de
trabalho pré-determinada a fazer a cada ciclo, ou
período, e é, normalmente, liberado (released) no
começo de cada ciclo.
Processos Periódicos e
Esporádicos
Periódicos: são ativados em intervalos fixos de
tempo. São usados tipicamente para monitoramento
sistemático, polling, amostragem de informações de
sensores em longos intervalos de tempo.
Esporádicos: são ativados por eventos (um sinal
externo ou uma mudança de algum relacionamento).
Pode ser usado para reagir a um evento indicativo de
falha.
Processo Periódicos
Processo Periódico:
P::
loop
Wait_for_start_of_cycle;
P_code;
end loop
onde P_code representa o programa para o tarefa P.
P (c, p, d), onde c ≤ d ≤ p
Processo Periódico P = (c, p, d)
d
(i-1)p
ip
c
(i+1)p
Release de P
Processo P é ativado a cada t0 + ip unidades de tempo, onde i =
0, 1,.... e t0 é o tempo da liberação inicial do processo e a
i-nésima ativação dever completar antes de t0 + (i-1)p + d
Processo Periódico P = (c, p, d)
d
(i-1)p
ip
c
(i+1)p
Release de P
O período e o deadline são obtidos, ou derivados, dos requisitos
do sistema e, freqüentemente são idênticos. Tempo de
computação é encontrado através de simulação, medida ou
análise.
Processo Esporádicos
Processo Esporádico:
P::
loop
Wait_for_event;
P_code;
end loop
P é bloqueado até o
evento ocorrer, sendo
bloqueado novamente
após execução de
P_code
P (c, p, d), onde c ≤ d ≤ p ( p = tempo mínimo entre eventos).
Na ocorrência do evento, a computação deve ser completada
dentro do deadline especificado, i.e, t ≤ te + d (te tempo da
ocorrência do evento).
Processo Aperiódico
Forma de processo orientado a evento que permite que
eventos cheguem simultâneamente (p = 0), ou dentro
de um tempo arbitrariamente pequeno entre eles.
Teoricamente as restrições de tempo não podem mais
ser determinísticas. Na prática, ás vezes é possível se
usar restrições determinísticas. São soft-real time.