Sistemas de Tempo Real - macedo.ufba.br · 7 Equívocos comuns • Tempo-real não implica em ´rap idez´, mas sim em previsibilidade • Conceito de rápido depende do contexto:

1

Sistemas de Tempo Real

Prof. Raimundo Macêdo

Raimundo Macêdo LaSiD/DCC/UFBA

1

2o trimestre de 2011

Habilidades esperadas ao final do curso

Conhecimento sobre os principais problemas e conceitos de sistemastempo real (tipos, arquiteturas, requisitos de segurança, temporal, etc).tempo real (tipos, arquiteturas, requisitos de segurança, temporal, etc).

Entendimento do principais mecanismos de projeto de tempo real(gerencia de tempo global, escalonamento, confiabilidade, etc.)


2

Capacidade de projetar e implementar um software de tempo real(projeto prático)

2

Programação

1. Aulas expositivas

2. Seminários pelos Alunos

3. Discussões Orientadas por Textos Previamente Dados

4. Projeto Prático (?)

5 P


3

5. Prova

Avaliação

50 ou 30 % Prova Escrita (1 prova)

50 ou 35% Seminários (pelo menos 2 seminários)

35% Projeto Prático? (1 projeto individual)


4

3

Programa do Curso

1. Introdução1. Conceituação e definições básicas2. Motivação para Sistemas de Tempo Real3. Exemplos de Sistemas de Tempo Realp S p4. Requisitos Temporais5. Confiabilidade6. Escalonamento7. Tipos de Sistemas Operacionais quanto ao Escalonamento

2. Sistemas Distribuídos de Tempo Real (Modelos de Sistemas)3. Escalonamento (princípios, mecanismos e restrições)4. Cálculo do Tempo de Execução no Pior Caso (WCET)5 T Si i ã d R ló i


5

5. Tempo e Sincronização de Relógios6. Confiabilidade e Determinismo de Réplicas7. Arquiteturas de Sistemas de Tempo Real

Artigos para serem lidos e discutidos pelos alunos, por assunto

Introdução1. Misconceptions about real-time computing. JOHN A. STANKOVIC . IEEE Computer, 1988

Sistemas Distribuídos de Tempo Real (Modelos de Sistemas)1. An Integrated Group Communication Infrastructure for Hybrid Real-Time Distributed Systems. Raimundo g p y y

José de Araújo Macêdo. In 9th Workshop on Real-Time Systems (WTR 2007). Belém, Brazil, May 28th, 2007. (somente introdução)

Escalonamento (princípios, mecanismos e restrições)1. Scheduling algorithms and operating systems support for real-timesystems. KRITHI RAMAMRITHAM AND

JOHN A. STANKOVIC. Proc. Of IEEE. Jan 1994. Volume: 82, Issue: 1. page(s): 55-672. LIU, C. L. and LAYLAND, James W. Scheduling Algorithms for Multiprogramming in a Hard-Real-Time

Environment. Journal of the Association for Computing Machinery 20, 1(Janauary 1973), 46-61.3. + artigos de análise probabilistica

Tempo e Sincronização de Relógios1 Temporal uncertainties in interactions among real-time objects H Kopetz and K Kim Ninth


6

1. Temporal uncertainties in interactions among real-time objects. H. Kopetz and K. Kim. NinthSymposium on Reliable Distributed Systems. 9-12 Oct 1990. pages: 165- 174.

2. On the role of time in distributed systems Verissimo, P.; Distributed Computing Systems, 1997., Proceedings of the Sixth IEEE Computer Society Workshop on Future Trends of , 29-31 Oct. 1997.

3. Probalibistic Clock Synchronization. Distributed Computing. Vol. 3 (Springer Verlag) pp. 146-185

4

Arquiteturas de Sistemas de Tempo Real

1. The time-triggered architecture. Kopetz, H.; Bauer, G.; Proceedings of the IEEE , Volume: 91 Issue: 1 , Jan. 2003.2. Adaptive middleware: Middleware for real-time and embedded systems. Douglas C. Schmidt June

2002 Comm nications of the ACM Vol me 45 Iss e 62002 Communications of the ACM, Volume 45 Issue 6.3. Real-Time Component Software For Flexible And Interoperable Automation Systems.

Sandro Santos Andrade; Raimundo José de Araújo MacêdoIn Anais do XII Congresso Brasileiro de Automática (XII CBA).Salvador. 2006. v. 1. p. 3014-3019. 2006.


7

Livros1. Hermann Kopetz, Real-Time Systems (Design Principles for Distributed Embedded Aplications, Kluwer Ac.

Publishers. 1997

2. A. Burns & A. Wellings, Real-TimeSystems and Programming Languages, 3rd Edition, Addison-Wesley, 2001.

3. Jane W. S. Liu, Real-time Systemes, Prentice Hall, 2000.

4. Tratando a previsibilidade em sistemas de tempo-real distribuídos: Especificação. Linguagens, Middleware e Mecanismos Básicos. R. J. A Macêdo, G. M. Lima, L. P. Barreto, A.M.S.Andrade, F.J.R.Barboza, A. Sá, R. Albuquerque, S. Andrade. Capítulo 3 do Livro texto para o mini-curso a ser apresentado no do 22o. Simpósio Brasileiro de Redes de Computadores, SBRC'2004, pp. 105-163, ISBN: 85-88442-82-5, 10 a 14 de maio de 2004, Gramado, RS. (livre download : http://www.lasid.ufba.br/public/publicacoes.html)

5. Jean-Marie Farines (UFSC), Joni da S. Fraga (UFSC), Rômulo S. de Oliveira (UFRGS) (Escola de Computação, 2000). Livre para download em http://www.lcmi.ufsc.br/gtr/livro/principal.htm

6. Paulo Veríssimo and Luís Rodrigues. Distributed Systems for System Architects, Kluwer Academic Piblishers, 2001.

7. Pankaj Jalote. Fault-Tolerance in Distributed Systems. Prentice Hall, 1994.


8

SitesIEEE Technical Committee on Real Time Systems http://cs-www.bu.edu/pub/ieee-rts/Home.html

5

Outros Artigos

The future of autonomous decentralized systemsKopetz, H.; Autonomous Decentralized Systems, 2003. ISADS 2003. The Sixth International Symposium on , 9-11 April 2003

Fault containment and error detection in the time-triggered architectureKopetz, H.; Autonomous Decentralized Systems, 2003. ISADS 2003. The Sixth International Symposium on , 9-11 April 2003

Safe automotive software developmentKen Tindell; Kopetz, H.; Ernst, F.R.; Design, Automation and Test in Europe Conference and Exhibition, 2003 , March 3-7, 203

Automotive electronics Kopetz, H.; Real-Time Systems, 1999. Proceedings of the 11th Euromicro Conference on , 9-11 June 1999

Which models and architectures of distributed real-time computing systems suit which application area? Kopetz, H.;Object-Oriented Real-Time Distributed Computing, 1999. (ISORC '99) Proceedings. 2nd IEEE International Symposium on , 2-5 May 1999

The time-triggered architecture Kopetz, H.; Object-Oriented Real-Time Distributed Computing, 1998. (ISORC 98) Proceedings. 1998 First International Symposium on , 20-22 April 1998


9

The design of fault-tolerant real-time systemsKopetz, H.; EUROMICRO 94. System Architecture and Integration. Proceedings of the 20th EUROMICRO Conference. , 5-8 Sept. 1994

How hard is hard real-time communication on field-buses? Verissimo, P.; Rufino, J.; Li Ming;Fault-Tolerant Computing, 1997. FTCS-27. Digest of Papers., Twenty-Seventh Annual International Symposium on , 24-27 June 1997

Deadline Handling in Real Time Distributed Objects K H (Kane) Kim Juqiang Liu Moon Hae KimDeadline Handling in Real-Time Distributed Objects K. H. (Kane) Kim Juqiang Liu Moon-Hae Kim

Proc. ISORC 2000 (IEEE CS 3rd Int'l Symp. on Object-oriented Real-time distributed Computing), Newport Beach, CA, March 2000, pp.7-15.

A TMO Based Approach to Structuring Real-Time Agents. K. H. (Kane) Kim. Proc. ICTAI 2002 (IEEE CS 14th Int'l Conf. on Tools with AI), Washington, D.C., Nov. 2002, pp. 165-172.

Group Communication in Real-Time Computing Systems: Issues and Directions

K. H. (Kane) Kim, Proc. FTDCS '99 (7 th IEEE Workshop on Future Trends of Distributed Computing Systems), Cape Town, South Africa, Dec.20 -22, 1999, pp.252-258.

•C. Lu, B. Blum, T. Abdelzaher, J. Stankovic, and T. He, RAP: A Real-Time Communication Architecture for Large-Scale Wireless Sensor Networks, RTAS, September 2002.


10

•Strategic directions in real-time and embedded systems John A. Stankovic.December 1996 ACM Computing Surveys (CSUR), Volume 28 Issue 4

6

Real-time and embedded systems John A. Stankovic

March 1996 ACM Computing Surveys (CSUR), Volume 28 Issue 1

Adaptive middleware: Middleware for real-time and embedded systems Douglas C. Schmidt June 2002 Communications of the ACM, Volume 45 Issue 6


11

O que é um Sistema de Tempo Real ?

um sistema de processamento de informação que tem que responder a estímulos externos dentro de limites (finitos) de tempo especificados

Mais ainda......

a correção da computação não depende só do resultado lógico, mas dotempo em que este foi produzido


12

7

Equívocos comuns

• Tempo-real não implica em ´rapidez´, mas sim em previsibilidade

• Conceito de rápido depende do contexto:– Atrasos de transmissão em Satélite– Telefonia

• Não adianta ´correr´ se for impossível tratar o pior caso– Algum dia pode acontecer pane geral


13

Um sistema computacional de tempo real é sempre parte de umasistema maior (sistema de tempo real) que muda seu estado em funçãodo tempo físico.Ex: uma reação química continua mudando seu estado mesmodepois do sistema computacional de controle tenha parado.

Alguns desafios:gu s desa os:

• modelar a interação entre o computador e o mundo real

• manter a precisão da medidas de tempo (a temperatura de um formohá 30 minutos atrás pode não ser mais útil)

• acomodar cargas relevantes de processamento com recursos finitos


14

• reconhecer prazos (deadlines)

• tolerar falhas (se o computador de controle falhar, nenhum prazo será atendido)

• complicações adicionais acontecem se o sistemas é distribuído

8

Principais entidades de um sistema de tempo-real (TR)

Objeto ouinterface de

sensores e atuadores

operador

Sistema Computacional tempo-real de controle

Objeto ou sistema controlado, ou Planta

interfacehomem-máquina

interface de instrumentação

monitor, teclado, etc.


15

ambiente

EX: Controlador Digital PID(Proporcional, Integral e Derivativo)

A/DEntrada de

R(t) rk

CONTROLADOR

A/D

Computação da Leide Controle

D/AEntrada dereferência

yk

uk

u(t)y(t)


16

AtuadorPlantaSensor

Seja o erro e(t) = r(t) – y(t)u(t) envolve três termos: proporcional a e(t); proporcional a integral de e(t); proporcional a derivada de e(t).

Amostras de r(t) e y(t) são coletadas periodicamente (a cada T unidades de tempo), k = 0,1,2,....uk = uk-2 + αek + βek-1 + γ(ek-2) ….. α, β e γ são escolhidos em tempo de projeto

9

EX: Controlador Digital PID(Proporcional, Integral e Derivativo)

Seja o erro e(t) = r(t) – y(t)u(t) envolve três termos: proporcional a e(t); proporcional a integral de e(t); proporcional a derivada de e(t)u(t) envolve três termos: proporcional a e(t); proporcional a integral de e(t); proporcional a derivada de e(t).

Amostras de r(t) e y(t) são coletadas periodicamente (a cada T unidades de tempo), k = 0,1,2,....uk = uk-2 + αek + βek-1 + γ(ek-2) ….. α, β e γ são escolhidos em tempo de projeto

Set timer to interrupt periodically with period TAt each timer interrupt, do

do analog-to-digital conversion to get y;compute control output u;

Programa do controlador


17

output u and do digital-to-analog conversion;End do;

A escolha de T é um ponto chave para manter a estabilidade da função de controle, o tempo de respostadentro de limites aceitáveis (ex: a ação de um piloto), e para manter os recursos do sistema dentro de limitesdisponíveis

Exemplos de Sistemas de Tempo-Real

Controlador de fluxo de um canoControlador de fluxo de um canoem geral deve-se dispor de sensores independentes para medir o efeitoda ação nos atuadores(ex: sensor de posição da válvula)

sistema computacional de controleponto de operaçãoselecionado pelo operador


18

válvula de controlede vapor

sensor de fluxo

10

Requisitos Temporais

loops de controle em geral definem os requisitos temporais

i t t i l d t l d di t t d li ido sistema computacional de controle deve medir a temperatura do liquido periodicamente para detectar desvios entre o valor desejado e o real



19

sensor temperatura


cano de vapor

sensor de fluxo


Controlador de motor de carroControlador de motor de carro

calcula a quantidade de combustível e o exato momento em que estecalcula a quantidade de combustível e o exato momento em que estedeve ser injetado na câmara de combustão de cada cilindrodeve ser injetado na câmara de combustão de cada cilindro


20Raimundo Macêdo LaSiD/DCC/UFBA

20

11


Controlador de motor de carroControlador de motor de carro

calcula a quantidade de combustível e o exato momento em que estecalcula a quantidade de combustível e o exato momento em que estedeve ser injetado na câmara de combustão de cada cilindrodeve ser injetado na câmara de combustão de cada cilindro


21

Sistemas de Tempo-Real

AmbienteEntidade de tempo

Sistema de computação

Sistema de computação

AmbienteEntidade de tempoEntidade de tempo-

real, operadorcomputação(objeto de tempo-

real)

computação (objeto de tempo-

real)

Entidade de tempo-real, operador

Evento Estímulo(s) Tarefa(s) Resposta


22

12

Como projetar um sistema de tempo-real?

Especificação dos requisitos

mecanismos de redundância

linguagens + middleware

aplicação

Prova de propriedades

Técnicas de tolerância a falhas

Testes validação


23

ambiente

gerencia de recursos Escalonamento + reserva

Tempo e previsibilidade Uma questão vital

O que significa tempo ???

Tempo de execuçãoTempo de execuçãop çp ç

Tempo lógico (Lamport)Tempo lógico (Lamport)

Tempo denso Tempo denso ⇔⇔ tempo físico representado pelos números reaistempo físico representado pelos números reais

Tempo Discreto Tempo Discreto ⇔⇔ tempo físico representado pelos naturais positivos tempo físico representado pelos naturais positivos

T Gl b l ( f i ú iT Gl b l ( f i ú i l t dl t d ii di t ib íd )di t ib íd )


24

Tempo Global (referencia única,Tempo Global (referencia única, vale para todos os vale para todos os sites sites distribuídos)distribuídos)

Tempo Local Tempo Local

13

Rede de Comunicação

Sistemas Distribuídos de Tempo-Real requerem:p q

Relógios Globais para medidas relativas de tempo (durações) e absolutas (ponto no tempo)

Exs: sincronização do progresso de um sistema concorrente


25

(tempo para acionar troca de pontos e semáforos num sistemade trens representado por um grupo de atuadores)

concordância no tempo em que aconteceram certos eventos (umlog distribuído de alarmes pode determinar causas, implicações ,etc).

Rede de Comunicação

Precisão (π) : divergência relativaentre medidas em cada processo

Exatidão (acuracy, α) :divergência absoluta em relação ao tempo externo

Granularidade (g) : duração de umabatida do relógio virtual (que pode

α

P1

P2

Pexterno

ser maior que o relógio físico)


26

P3

Batida (tick) global i i+1 i+2

πg

14

Estruturação do Sistema de Tempo-Real

• Modelo de tarefas Г = {τ1, τ2, …, τn}– Alguns dos atributos mais comuns

• Tempo máximo de computação (Ci) – é usado o WCET• Tempo máximo de computação (Ci) é usado o WCET

• Deadline (Di)

• Período (Ti) – refere-se a ativação das tarefas– Periódicas, esporádicas ou aperiódicas

• Jitter – variação máxima entre duas ativações consecutivas


27

– Restrições Típicas: Di = T; tarefas são periódicas etc

atributos temporaisTi periodicidade

Di

...

deadlinerelativo


28

TempoCiAi

di0

T. ativação T. execuçãodeadlineabsoluto

15

Tarefas podem ser

Periódicas (T exato é conhecido)

Esporádica (mínimo T é conhecido)

Aperiódica (T não conhecido)


29

Tarefa Periódica

T T

CAi di

Di

CAi di

Di


30

CiAi di Ci

Ai di

16

Ativação de Tarefas

• Por evento (Event-triggered)– Tarefas são disparadas pela percepção da ocorrência de

eventos– Sistemas mais versáteis– Requerem ferramentas mais elaboradas para garantia de

correção• Por tempo (Time-triggered)


31

– Tarefas respondem a eventos em momentos predeterminados

– Sistemas menos versáteis– Mais fáceis de se garantir correção

Sobre deadlines (prazos)

Um sistema computacional de TR tem que reagir a estímulos a partirdo objeto controlado (ou operador) dentro de intervalos de tempoimpostos pelo ambiente.

Deadline é o instante em que o resultado deve ser produzido

Se o resultado tem utilidade depois do prazo soft deadline


32

Caso contrário firm deadline

Se uma catástrofe pode acontecer hard deadline

.

17

Um sistema computacional que tem de garantir pelo menos um hard

Deadline é chamado hard real-time computer system (ou safety-critical computer system) - HRT

Ou Sistema computacional de tempo-real rígido (crítico)

Se todos deadlines são soft é um soft real-time computer system ou

Sistema computacional de tempo-real brando


33

Um sistema computacional HRT tem que garantir comportamento temporal correto mesmo sob quaisquer

condições de carga e falhas.

Exemplos de Sistemas de Tempo-Real quanto à rigidez dos prazos

soft (brandos ou não críticos)soft (brandos ou não críticos)falhas temporais ocasionais são aceitáveis (nenhuma catástrofe)

ex: reserva aérea, comutação telefônica.

Hard (críticos)


34

falhas temporais podem levar a catástrofes

ex: controle de vôo, planta nuclear

18

Problema de Escalonamento

Qual tarefa executar agora? σ2 σ3

• Disparadas por tempo (time-trigged)– Determina-se off-line a seqüência de ativação de

f d d i

Nenhuma deve violar suas restrições temporais! σ1


35

tarefas durante a construção do sistema• Disparadas por evento (event-trigged)

– Técnicas on-line são usadas

Requisitos de um sistema de tempo real

Funcionais

Temporais

Confiança no Funcionamento (dependability)


36

19

Requisitos funcionais1. Coleção de dados de tempo-real

2. Controle digital direto

3. Interação homem-máquina

1) Coleção de dados de tempo-real

O objeto controlado muda seu estado em função do tempo. O estado doobjeto é representado pelos valores das variáveis de estado, cada uma representando uma entidade de tempo real (real-time entity)

EX bj t t l d RTE l li ã l id d i ã d h


37

EX: objeto controlado carro. RTEs : localização, velocidade, posição das chaves do painel, posição do pistão no cilindro, etc.

Tempo 40k/h 30k/h 40k/h 60k/h




Uma imagem de tempo real somente tem precisão temporal dentro de

I d l

Uma imagem de tempo real somente tem precisão temporal dentro deum limite de tempo. O conjunto de todas as imagens precisas de tempo-realde um objeto controlado é chamado de banco de dados de tempo-real

Deve ser atualizado toda vez que uma entidade de tempo real muda seu valor !!

Time-trigged


38

Tempo 40k/h 30k/h 40k/h 60k/h

Imagem de tempo-real Event-trigged

20




Condicionamento de sinalCondicionamento de sinal

Processamento necessário para transformar sinais de sensores (ex: voltagens)em dados manipuláveis da entidade de tempo-real.

Técnicas : tirar média para eliminar erros, fazer testes de conformidade, etc.

Monitoramento de Alarmes


39


O sistema computacional deve monitorar continuamente as entidades de tempo-real paradetectar comportamentos anormais (ex: rupturas de canos ou containeres podem causardesvios de comportamentos em muitas ETR (entidade de tempo-real), causando disparosde alarmes pre-fixados (temperaturas, níveis de líquidos, etc) : Shower.





O sistema computacional de TR deve detectar e mostrar (display) os alarmes, assistindo o OPERADOR no trabalho de identificação do evento inicial causador do alarm shower

Para isso os alarmes são salvos em logs com o registro de tempo de suas ocorrências


40

Para isso os alarmes são salvos em logs com o registro de tempo de suas ocorrências.

O Sistema Computacional de TR deve ter comportamento correto mesmo em situaçõesde picos de carga de disparo de alarmes

21




Controle Digital Direto

Muitos sistemas computacionais de TR devem calcular os set points para os atuadores e controladiretamente o Objeto controlado (sem ajuda de um sistema de controle subjacente).

Aplicações de controle consistem em seqüências de períodos de controle

1. leitura (amostragem) da entidade de tempo-real2. calculo do novo set point para o atuador3. output do set point para o atuador

LOOP


41

Interação homem-máquina

Interface homem-máquina é um componente fundamental : informa o operador o estadocorrente do objeto controlado e assiste o operador na função de controle do objeto (plantaou máquina)

Requisitos Temporais

loops de controle em geral definem os requisitos temporais

i t t i l d t l d di t t d li ido sistema computacional de controle deve medir a temperatura do liquido periodicamente para detectar desvios entre o valor desejado e o real



42

sensor temperatura


cano de vapor

sensor de fluxo

22

Algumas definições

a duração entre os dois pontos de verificação é chamado de períodode amostragem (sample period, dsample)

1/dsample = freqüência de amostragem1/dsample = freqüência de amostragem

assumindo que o sistema esteja em equilíbrio :

toda vez que que o fluxo de vapor é aumentado por uma função de passo(step function), a temperatura do vaso irá aumentar até que novo equilíbrioseja atingido (de acordo com uma função resposta – response function)


43

seja atingido (de acordo com uma função resposta response function)

A função resposta da temperatura depende da quantidade de liquido no vaso e do fluxo de vapor no trocador de calor (i.e., a dinâmica do objeto controlado)

Parâmetros básicos que caracterizam a função resposta;

latência do objeto (object delay, dobject)

período de tempo para a temperatura medida começar a subir(inércia inicial do processo)

tempo de subida da temperatura (rise time, drise)

período até que novo equilíbrio seja alcançado


44

Uma regra geral : dsample < drise / 10 (kopetz)

dsample

drise

23

temperaturatemp do liquido

fluxo do vapor


45dobject)drise

tempo-real

O computador compara a temperatura medida com a selecionada pelooperador e calcula do erro.

O erro calculado é a base para o calculo de um novo valor atribuído a variável de controle pelo algoritmo de controle

A cada intervalo de tempo depois do ponto de verificação (latência docomputador, dcomputer), o computador controlador passará o novovalor para a válvula de controle. dcomputer < dsample

dcomputer é o intervalo de tempo entre o ponto de amostragem (observação do objeto controlado) e o uso dessa informação (saída para o atuador do objeto controlado)

tempo de calculo + tempo de comunicaçãoponto de amostragem ponto de amostragem


46

dcomputer

dsample

24

A diferença entre a menor e maior latências do computador é chamadode jitter

O jitter influencia na qualidade do controle (<<<< melhor)

Tempo Morto do Loop de Controle

intervalo de tempo entre a observação da entidade TR e o começo da reação do objeto controlado devido a ação do computador de controle

(deve ser o menor possível)


47

= dcomputer + dobject

depende da dinâmica do objeto

depende da dinâmica da implementação

símbolo parâmetro esfera de controle

relaciona-mentos

dobject latência do ob. controlado

objeto controlado processo físico

drise tempo de subida objeto controlado processo físicofunção resposta

dsample período de amostragem

computador dsample << drise

dcomputer latência do computador

computador dcomputer <dsample


48

Δdcomputer jitter da latência do computador

computador Δdcomputer<<dcomputer

ddeadtime tempo morto computador e ob. controlado

dcomputer +dobject

parâmetros de um loop de controle elementar : extraída do livro de H. Kopetz

25

Outros requisitos temporais

latência mínima de jitter

muitas aplicações assumem que o jitter de latência é muito pequeno em relação à latência do computador Δdcomputer<<dcomputer

Latência de jiiter traz uma incerteza adicional no loop de controle que pode refletir negativamente na qualidade do controle. EX: O jitter pode ser interpretado como um erro adicional na medição da temperatura.

Latência de detecção de erro


49

tem que ser da mesma ordem de magnitude do período de amostragemdo loop de controle mais rápido para que seja possível tomar açõescorretivas ou levar o sistema a um estado seguro

Confiança no Funcionamento (Dependability)

Propriedade não-funcional (ou meta-funcional) relacionadaà qualidade do serviço disponibilizado num período de tempo


50

26

Requisitos de Confiança no Funcionamento (Dependability)

Reliability(confiabilidade)

Propriedade do sistema dispor do serviço especificado até tempo t

dado que o mesmo funcionava no tempo t0(confiabilidade)

Safety

Maintanability

dado que o mesmo funcionava no tempo t0

Supondo que uma razão constante de falhas λdefeitos por hora

R(t) = E (- λ(t – t0)) - Kopetz

1/ λ = MTTF (mean-time-to-failure)


51

Availability

Security

Seja X uma variável aleatória que representa tempo para o sistema falhar. Se F é a função de distribuição de probabilidade de X

R(t) = probabilidade do sistema está funcionando no tempo t

= P (X > t) = 1 – F(t)

R(t=0) = 1 e R(t=∞) = 0.

Requisitos de Confiança no Funcionamento (Dependability)

Reliability

Confiabilidade em relação a modos de defeitos críticos

O custo da falha é ordens de magnitude maior do que o beneficio do sistema em funcionamento normal

Safety

Maintanability

Availability

Safety-critical (hard) real-time systems devem ter uma razão de falhas em relação a defeitos críticos de acordo com requisitos ultra-rigorosos

Validação1) Subsistemas críticos devem estar protegidos da propagação de

erros a partir de outros componentes


52

Availability

Security2) Todos os cenários que são cobertos pelas hipóteses de falha e

carga devem ser resolvidos sem uso de argumentos probabilísticos

3) A arquitetura deve possibilitar a certificação dos subsistemas de forma independente (deadlines da comunicação, carga da CPU, ...)

27

Requisitos de Confiabilidade

Reliability

Medida de tempo requerida paraconsertar um sistema (componente)após falha.

Safety

Maintainability

Availability

M(d) = probabilidade do sistema serconsertado dentro do intervalo d após falha

MTTR (mean-time-to-repair) = 1/reparos por hora

Conflito

Reliability x Maintainability


53

Security

y y

+ unidades removíveis + mais fácil e rápido de manter

Menos reliability (unidade ligados por interfacessoldadas são mais confiáveis que unidades ligadaspor interfaces removíveis (plugs, sockets, etc.)


Reliability

Medida de tempo para a disponibilização do serviço emrelação a alternância entre serviços corretos e incorretos(operacional e não-operacional)

Fração do tempo que o sistema está pronto para prover oserviço especificado

Safety

Maintainability

Availability

Security

Ou a probabilidade do sistema está pronto (disponível) no tempo t

EX: quando pegamos o telefone qual a probabilidade domesmo estar funcionando ?

A = MTTF / (MTTF + MTTR))

MTTF + MTTR = tempo médio entre falhas


54

y MTTF MTTR tempo médio entre falhas

up

down

defeito reparo

MTTR

MTTF

MTBFReal-time

28

Availability:

a probabilidade do sistema estar operacional em algummomento dado que este alterna entre os estados : operacional eem reparo/manutenção.

Pode ser traduzido em downtime por ano

90% > 1 mês PC sem assistencia99% 4 dias PC com manutenção99,9% 9 horas cluster99 99% 1 hora multicomputer


55

99,99% 1 hora multicomputer99,999% 5 minutos embeded system (PC)99,99999% 3 segundos embeded system (HD especial)

Tabela extraída do livro de P. Verissimo e Luis Rodrigues


Reliability

Safety

Maintainability

Availability

Security

Prevenção contra acesso não autorizado

Serviços (ex: senhas para celular ou carro)

Informações


56

Security

29

Hard x Soft C t í ti

Classificação dos Sistemas de TR

Fail-safe x Fail-operational

Garanteed timeliness x Best effort

Características da aplicação


57

Garanteed-timeliness x Best-effort

Resorse-adequade x Resourse-inadeuqate

Event-trigged x Time-trigged

Características daImplementação

Algumas características de Sistemas de TR


58

30

Response –time (Tempo de resposta)

Hard real-time

deve ser autônomo para garantir a continuidade da operação semintervenção humana na ordem de milisegundos

Soft real-time (on-line)

O tempo pode receber intervenção humana (retardo) e é na ordem de segundos

Performance em picos de CargaHard real-time


59

os cenários têm que ser bem definidos e os prazos atendidos emqualquer cenário

Soft real-timePerformance média é importante e operações degradadas são toleradas

Controle do Ritmo (control of pace)

Hard real-time

Tem que se manter síncrono com o ambiente (objeto controlado e operador)

O passo é ditado pelas mudanças que ocorrem no ambiente

Soft Real-time

Pode impor controle sobre o ambiente


60

Tipos de Redundância

Ativa (espacial) --- geralmente em Hard real-time

Roll-back recovery (Temporal) – geralmente em soft-real time

31

Redundância Temporal

FalhaDetecção

retorno a um estadoconsistente

A mesma parte do código pode ser executada várias vezes


61

Transações Atômicas Distribuídas é exemplo típico

Redundância Espacial

Falha

Detecção

A falha é “mascarada” eo componente faltosoé posteriormente substituído.


62

S1 S2 S3 S4

componente replicado

32

Fail-safe

Quando um ou mais estados de segurança podem ser identificados(ex: sistema de sinalização de trens)

E uma falha pode ser rapidamente identificada de modo a colocarE uma falha pode ser rapidamente identificada de modo a colocaro sistema num estado seguro

É necessario uma cobertura de detecção de falhas muito alta : propabilidadede uma erro ser detectado próximo de 1

Fail-operational


63

Quando estados seguros não podem ser identificados (ex: controle de vôo)

O computador de controle de tempo-real deve prover um nível mínimo deserviço para evitar catástrofes em caso de falha

Event-trigged

Atividade de processamento ou comunicação é iniciada devido a umamudança de estado

É á i i di â i d l t i t ãÉ necessário mecanismo dinâmico de escalonamento e interrupção

Time-trigged

Atividades de processamento ou comunicação são iniciadas em pontospredeterminados do tempo


64

p p

Usa interrupção do relógioRelógios têm que estar sincronizados (as observações do objeto controlado

levam o registro do tempo global)

33

Characteristic Hard real-time Soft-real time (on-line)

Response time Hard-required Soft-desired

Peak-load performance predictable degraded

Control of pace environment computer

safety Often critical Non-critical

Size of data files Small/medium large

Redundancy types active Checkpoint-recovery


65

Data integrity Short-term Long-term

Error detection autonomous User-assisted

Tabela extraída do livro de H. Kopetz

Nichos de mercado para sistemas de tempo-real

Sistemas Embarcados (embedded systems)

Sistemas de Automação de Plantas

Sistemas Multimídia


66

34

Sistemas Embarcados (embedded systems)parte de um produto “inteligente”

uma tendência com o barateamento dos microcontroladores : sistemas embutidos embarcados são introduzidos no lugar de mecanismos mecânicos/eletrônicosembarcados são introduzidos no lugar de mecanismos mecânicos/eletrônicos convencionais de controle

exs: controladores de motores de carros, marcadores/controladores de aquecimento e/ou ar-condicionado, maquinas de FAX, celulares, maquinas de lavar, forno micronondas....

embedded system


67


um produto inteligente consiste em :

1) um sub-sistema mecânico)

2) um computador embutido de controle

3) uma interface homem-máquina (na maioria das vezes)

embedded system


68

35


características que influenciam no processo de desenvolvimento

produção em massa

estrutura estática

interface homem-maquina

sub-sistemas mecânicos devem ser mínimos

funcionalidade determinado por software em ROM

facilidades de manutenção (ex: interface de diagnóstico)


69

facilidades de manutenção (ex: interface de diagnóstico)

habilidade de comunicação

o custo é em geral dominado pela produção

Sistemas de Automação de Plantas

•trazem enormes vantagens de custos e precisão nos processos das plantas•projeto e manutenção dominam os custos dos sistemas de tempo-real

(cada planta é única)

Sistemas Multimídia

deadlines são firmes mas não são hard (nenhuma catástrofe)


70

deadlines são firmes mas não são hard (nenhuma catástrofe)

adaptação e QoS são tópicos importantes

ex: sincronização de fluxos de dados de áudio e vídeo

36

Exercícios para a próxima aula

1) Quais funções típica um STR deve prover?

2) O que é um modo crítico de falha ? Cite exemplos) q p

3) De onde vem os requisitos temporais de aplicações de tempo-real.Quais são os parâmetros que descrevem as características temporais doobjeto controlado?

4) Ler o artigo de Stanchovic (Misconceptions ...)


71

Responder por escrito com suas palavras:a) o que você aprendeu da leiturab) qual foi sua maior dificuldade com a leitura/texto

Documents

Sistemas de Tempo Real - macedo.ufba.br · 7 Equívocos comuns • Tempo-real não implica em ´rap idez´, mas sim em previsibilidade • Conceito de rápido depende do contexto: