Aula 011 - SD e de TR - Sistemas de Tempo Real

Sistemas de tempo
real
Sistema de tempo real
– Um sistema de tempo real é um sistema em que seu comportamento
não depende apenas dos resultados lógicos dos cálculos, mas
também do tempo físico que esse resultado é produzido. (Hermann
Kopetz)
– Young (1982) define um sistema de tempo real como:

“any information processing activity or system which has to respond to
externally input stimuli within a finite and specified period”
– Randell et al., 1995

“A real-time system is a system that is required to react to stimuli from
the environment (including the passage of physical time) within
time intervals dictated by the environment”
Sistemas de tempo real
– Requisitos temporais
• A maioria dos requisitos temporais mais rigorosos têm origem em
laços de controle, como um motor automotivo
• Os requisitos temporais relacionados a IHM normalmente são
menos rigorosos, pois existe um atraso na percepção humana
• O sistema tem um tempo determinado para alterar a vazão da
válvula de acordo com alterações na temperatura e fluxo do líquido
– Requisitos de confiabilidade
• A noção de confiança abrange os atributos relacionados a
qualidade de serviço que um sistema entrega aos usuários
 Confiabilidade
 Safety
 Manutenção
 Disponibilidade
 Security
• Confiabilidade
 A confiabilidade de um sistema é a probabilidade que o sistema
irá prover um serviço no tempo estimado
 A probabilidade de um sistema falhar em um intervalo de tempo
é expresso pela taxa de falha (FIT)
 1 FIT significa que o tempo médio de falhas (MTTF) de um
dispositivo é 109 h, ou seja, uma falha a cada 115 mil anos
• Safety
 Safety está relacionada às falhas críticas do sistema
 Uma falha crítica tem uma magnitude muito maior do que o
funcionamento normal do sistema
 Como um acidente de avião causado por falha do sistema
 Normalmente o sistema precisa passar por uma certificação para
atender os requisitos de segurança
• Manutenção
 Medida de tempo gasto para recuperar de uma falha não crítica
 Probabilidade do sistema se recuperar em um intervalo de tempo
após uma falha
• Disponibilidade
 Medido pelo tempo em que o serviço está disponível para prestar
um serviço
 Para calcular leva-se em consideração o tempo médio de falhas
(MTTF) e o tempo médio de reparos (MTTR).
A = MTTF / (MTTF + MTTR)
• Security
 Relacionado com a autenticidade e integridade das informações
 Além de prevenir acessos não autorizados ao sistema
 Normalmente está relacionado aos dados que o sistema possui
que são confidenciai
– Classificação:
• Sistemas de tempo real Críticos vs Não-Críticos
• Fail-Safe vs Fail-Operational
• Resposta Garantida vs Melhor esforço
• Recurso adequado vs Recurso inadequado
• Event-Triggered vs Time-Triggered
 Os requisitos de tempo de resposta em sistemas críticos são
da ordem de milissegundos ou menos, impedindo a ação
humana durante momentos críticos. Deve ser autônomo para
garantir funcionamento em segurança
 Em sistemas não-críticos o tempo de resposta é na ordem dos
segundos e se alguma deadline for perdida não há grandes
problemas
 Em sistemas críticos casos de pico de carga devem ser previstos
e deve ser garantido que o sistema irá cumprir a deadline em
todos os cenários
 Em sistemas não-críticos perda de performance durante esses
momentos de pico de carga é tolerável por razões de custo
 A segurança de sistemas críticos gera diversas consequências
no desenvolvimento do sistema
 O sistema deve ser autônomo para detecção de erros e
recuperação de um estado seguro
 Normalmente sistemas críticos trabalham com dados de
menor tamanho
 Em sistemas não-críticos o maior problema é manter a
integridade de grandes arquivos durante muito tempo
• Fail-Safe vs Fail-Operational
 Sistemas Fail-Safe são sistemas que possuem diversos estados
de segurança que podem ser recuperados em caso de falhas
 Em outros sistemas após ocorrer a falha não há estados de
segurança definidos e o sistema deve permanecer com pelo
menos o nível mínimo operacional para evitar catástrofes
• Resposta garantida vs Melhor esforço
 Sistemas que durante o desenvolvimento preveem todos os
casos de falhas e picos de carga com certeza são os de resposta
garantida
 Sistemas de melhor esforço não tem essas garantias, o
funcionamento dele é dado principalmente nas fases de teste e
integração
• Recurso adequado vs Recurso inadequado
 Sistemas críticos normalmente são do tipo recurso adequado, ou
seja, devem possuir recursos físicos suficientes para garantir
funcionamento em picos ou falhas
 Já sistemas não críticos normalmente não possuem os recursos
para todos os casos, principalmente pelo custo
• Event-Triggered vs Time-Triggered
 É baseado nos tipos de triggers internos do sistema
 Triggers são eventos internos que iniciam a execução de uma
tarefa do sistema
 Event-Triggered são sistemas que atividades e comunicações
acontecem após um evento especial
 Time-triggered são sistemas que se baseiam no tempo real do
relógio
– Arquitetura
• Um sistema em tempo real pode ser decomposto em três
subsistemas de comunicação:
 Objeto controlado  parte física do subsistema, cujo
comportamento é regido pelas leis da física.
 Subsistema de computador "distribuído"  sistema
cibernético, cujo comportamento é regido pelos programas que
são executados em computadores digitais.
 Usuário humano ou operador.
O sistema de computador distribuído consiste em nós

computacionais que interagem pela troca de mensagens. Um nó
computacional pode hospedar um ou mais componentes
computacionais.
– Arquitetura
• Componentes e mensagens
 Tarefa  Processo de execução de um algoritmo por uma
unidade de processamento.
 Componente  Unidade de hardware / software independente
que interage com seu ambiente exclusivamente pela troca de
mensagens.
– Arquitetura
 Uma tarefa é executada de forma independente, mas elas
precisam interagir entre si para que o sistema atinja seus
objetivos.
 Para exemplificar, vamos supor um simples sistema de alarmes:
 Tarefa 1  responsável pela leitura constante dos sensores de
presença e movimento.
 Tarefa 2  responsável pelo acionamento da sirene.
 Tarefa 3  responsável pelo acionamento da discagem
telefônica.
 Tarefa 4  responsável pela lógica de detecção de intrusos do
sistema de alarme.
– Arquitetura
 Um componente consiste em um projeto (por exemplo, o
software) e uma modalidade (por exemplo, o hardware, incluindo
uma unidade de processamento, memória e uma interface de
I/O).
 Em tempo real componente contém um relógio em tempo real e,
portanto, está ciente da progressão de tempo real.
 Após a inicialização, um componente entra em um estado pronto,
aguardando por um sinal de disparo, iniciando assim a execução
dos cálculos do componente.
Um princípio importante é a separação dos

componentes computacionais da infraestrutura
de comunicação em um sistema de computador
distribuído.
– Arquitetura
 A infraestrutura de comunicação fornece o transporte de
mensagens unidirecionais de um componente a um ou mais
componentes (multicast) dentro de um determinado intervalo de
tempo real.
 A Unidirecionalidade de mensagens elimina qualquer
dependência do remetente no(s) receptor(es).
 Esta propriedade de independência do remetente é de extrema
importância no projeto de sistemas tolerantes a falhas, porque
evita a retropropagação de erro de um componente receptor,
com defeito, para um componente de envio, funcional.
– Arquitetura
• Controle Temporal vs Controle Lógico
 Controle temporal se preocupa em determinar os instantes no
domínio de tempo real quando os cálculos devem ser realizados,
ou seja, quando as tarefas devem ser ativadas.
 Controle lógico se preocupa com o fluxo de controle dentro de
uma tarefa, que é determinada pela estrutura de tarefa dada e os
dados de entrada particulares, a fim de realizar a computação
desejada.
O controle temporal está relacionado ao

tempo real, enquanto o controle lógico está
relacionado a tempo de execução.
– Arquitetura
• Requisitos para comunicação em tempo real
 Protocolo de baixa latência.
 Contenção de erros temporais.
 Jitter mínimo.
 Base de tempo global.
 Detecção rápida de erros no receptor.
– Interface
• As interfaces fazem comunicação com os componentes e os
organiza de diversas maneiras.
• Podem ser usadas para troca de mensagens entre componentes.
• Podem ser usadas para monitorar, controlar e debugar
componentes.
– Interface
• Existem dois modos das interfaces lidarem com a chegada de
informações nos componentes.
 Push  O sistema de comunicação gera uma interrupção e
força o componente a parar e agir imediatamente.
O controle sobre o comportamento temporal do componente é
delegado ao ambiente externo.
 Pull  O sistema de comunicação coloca a mensagem em um
local de armazenamento intermediário. O componente verifica
periodicamente se uma nova mensagem chegou.
O controle temporal permanece dentro do componente.
– Interface
• Em sistemas em tempo real, a estratégia Pull deve ser seguida
sempre que possível.
• Apenas em situações em que uma ação imediata é necessária, e o
atraso de um ciclo que é introduzido pela estratégia Pull não é
aceitável, devemos recorrer à estratégia Push.
• Neste último caso, mecanismos devem ser colocados para proteger
o componente de interrupções errôneas causadas por falhas
externas ao componente.
• A estratégia Push viola os princípios de independência.
– Event-Triggered vs Time-Triggered
• A noção de um sinal de disparo (triggering signal), ou seja, um
sinal de controle, indica o instante em que uma atividade deve
começar no domínio temporal.
• Quais são as possíveis origens de tal sinal de ativação?
• O sinal de acionamento pode ser associado à ocorrência de um
evento significativo – Event-Triggered - ou com a chegada de um
determinado instante na linha do tempo – Time-Triggered
– Event-Triggered
• Basicamente existem duas entidades principais
 Publisher
 Subscriber
– Event-Triggered
 Publisher
 São componentes que emitem notificações da ocorrência de
seus próprios eventos.
 Publicador é quem observa seus próprios eventos e sua principal
função é enviar notificações para o Serviço de Notificação.
 Ele não sabe quais são os assinantes interessados
– Event-Triggered
 Subscriber
 Recebe as notificações que são entregues pelo Serviço de
Notificação.
 Enviam inscrições para o Serviço de Notificação , apenas
indicando seus interesses em determinadas classes de eventos
 Tanto o envio de inscrições e no recebimento de notificações , o
assinante não tem conhecimento do respectivo publicador
– Event-Triggered
• Um remetente envia uma mensagem sempre que um evento
significativo ocorrer, por exemplo, o término de uma tarefa, um sinal
de interrupção, etc.
• Esta mensagem é colocada em uma fila no site do remetente até
que o serviço básico de transporte de mensagens (BMTS) esteja
pronto para transportar a mensagem para o receptor.
– Time-Triggered
• Em um sistema de comunicação acionado por tempo, o remetente e
o (s) destinatário (s) concordam a priori em uma programação de
comunicação livre de conflito e controlada por tempo cíclico para o
envio de mensagens.
• Esta programação de comunicação cíclica pode ser expressa em o
modelo cíclico de tempo.
– Time-Triggered
• De certa forma, a comunicação acionada por tempo se assemelha a
um circuito de comutação controlado por tempo (TCCS), onde um
canal dedicado, controlado por tempo entre um remetente e
receptor, é estabelecido para o transporte de uma mensagem.
• Por exemplo
 Um conjunto coordenado de semáforos ao longo de uma estrada
que estabelece periodicamente um onda verde.
– Real-Time Operating Systems
• Um sistema operacional (SO) em tempo real dentro de um
componente deve ser temporariamente previsível.
• Em contraste com os sistemas operacionais para computadores
pessoais, um sistema operacional em tempo real deve ser
determinista e apoiar a implementação de tolerância a falhas por
replicação ativa.
• Em aplicações críticas de segurança, o sistema operacional deve
ser certificado.
• A certificação do comportamento de uma estrutura de controle
dinâmica é difícil, portanto mecanismos dinâmicos devem ser
evitados, sempre que possível, em sistemas críticos para a
segurança.
• Sistemas são construídos a partir dos serviços oferecidos por um
sistema operacional.
• O atendimento dos requisitos temporais depende não somente do
código da aplicação, mas também da colaboração do sistema
operacional.
• O sistema operacional deve permitir previsibilidade ou pelo menos
um desempenho satisfatório.
• Muitas vezes os requisitos temporais da aplicação são tão rigorosos
que o SO é substituído por um simples núcleo de tempo real.
• Este núcleo não inclui serviços como Sistema de arquivos ou
Gerência sofisticada de memória
• Núcleos de tempo real oferecem uma funcionalidade mínima, mas
são capazes de apresentar excelente comportamento temporal.
• SO convencionais são construídos com o objetivo de apresentar um
bom comportamento médio.
• Distribuem os recursos do sistema de forma justa entre as tarefas e
os usuários
• Não existe uma preocupação com previsibilidade temporal
• Mecanismo como Memória virtual e Fatiamento de tempo do
processador, melhoram o desempenho médio do sistema, mas
tornaram mais difícil de fazer afirmações sobre os tempos de uma
tarefa em particular.
• Aplicações com restrições de tempo são:
• Menos interessadas em uma distribuição uniforme dos recursos
• Mais interessadas em atender requisitos tais como períodos de
ativação e deadlines Sistema operacional de tempo real
• Atenção dedicada ao comportamento temporal
• Serviços são definidos não somente em termos funcionais mas
também termos temporais.
• Como qualquer SO, o SOTR procura tornar a utilização do
computador mais eficiente e conveniente
• Facilidades provindas de um SO de propósito geral são bem vindas
em um SOTR
• Aplicações de tempo real são usualmente organizadas na forma de
várias threads ou tarefas concorrentes.
• Logo, um requisito básico de um SOTR é oferecer suporte para
tarefas e threads
– Tarefas e Threads
• Tarefas ou processos são abstrações que incluem
 Um espaço de endereçamento próprio (possivelmente
compartilhado)
 Um conjunto de arquivos abertos
 Um conjunto de direitos de acesso
 Um contexto de execução formado pelos registradores do
processador
 Vários outros atributos
– Tarefas e Threads
• Comunicação entre Tarefas e entre Threads
 Uma aplicação de tempo real é tipicamente um programa
concorrente
 Formado por tarefas e/ou threads
 Que se comunicam e se sincronizam
 Existem duas grandes classes de soluções para programação
concorrente
 Troca de mensagens
 Variáveis compartilhadas
 A correta programação da comunicação e sincronização das tarefas
 Garante o seu comportamento funcional
 Mas não o seu comportamento temporal
– Instalação de Tratadores de Dispositivos
• Sistemas de tempo real lidam com periféricos especiais, diferentes tipos de
sensores e atuadores
 Automação industrial
 Controle de equipamentos em laboratório
• Projetista da aplicação deve ser capaz de
 Desenvolver os seus próprios tratadores de dispositivos (device
drivers)
 Incorpora-los ao sistema operacional
• Muitas vezes a aplicação e o periférico estão fortemente integrados
 Código da aplicação confunde-se com o código do tratador do
dispositivo
 Acontece no contexto dos sistemas embutidos (embeded systems)
 SOTR deve permitir a aplicação instalar os seus próprios tratadores
de interrupções
– Temporizadores
• Aplicações precisam realizar operações que manipulam tempo
 Ler a hora com o propósito de atualizar um histórico
 Realizar determinada ação a cada X unidades de tempo
 Realizar uma ação depois de cada Y unidades de tempo a partir
de agora
 Realizar determinada ação a partir do instante absoluto de tempo
Z
• SOTR deve oferecer um conjunto de serviços que atenda estas
necessidades
• Tipicamente o sistema possui pelo menos um temporizador (timer)
implementado em hardware
 Gera interrupções com uma dada frequência
 SOTR utiliza este temporizador para criar temporizadores lógicos
– Aspectos temporais
• Aplicações de SOTR compartilham os mesmos recursos do hardware
• Comportamento temporal do SOTR afeta o comportamento temporal da
aplicação
• Por exemplo
 Rotina do SO que trata as interrupções do timer
• O projetista da aplicação pode ignorar completamente a função desta rotina
• Mas não pode ignorar o seu efeito temporal
 A interferência que ela causa na execução da aplicação
• Solicitar um serviço ao SO através de chamada de sistema significa
 Processador será ocupado pelo código do SO
 Capacidade da aplicação atender seus deadlines passa a depender
da capacidade do SO em fornecer o serviço solicitado em um tempo
que não inviabilize aqueles deadlines
– Modelagem de sistemas de tempo real
• Foco na estrutura e nos aspectos temporais do comportamento do
sistema
• Capacidade limitada das informações do mundo real
• Utilização de premissas
• Distinção de características relevantes e não relevantes
• Premissas
 São considerações sobre o entendimento e simplificações
utilizadas na construção do modelo
 Assumption coverage ( Cobertura de Premissa)
 Duas principais
 Hipótese de carga
 Hipótese de falha
• Premissas
 Assumption coverage ( Cobertura de Premissa)
 Duas principais
 Hipótese de carga
o Todo o sistema computacional tem uma capacidade finita de
processamento
o Considera o máximo de carga que o sistema consegue processar
 Hipótese de falha
o Conjunto de premissas que relatam o tipo e frequência de falhas que o
sistema supostamente manipulará
o Um sistema de computação tolerante a falhas é projetado para suportar
falhas cobertas pela hipótese de falha
o Falhas não cobertas pela hipótese de falha causaram falha no sistema,
mesmo que ele seja tolerante
– O que é relevante?
• Noção de tempo
• Duração das ações
• Pior caso de execução(WECT)
• Jitter
• Frequência de ativação
– O que não é relevante?
• Atributos que podem ser descartados sem perda de propósito do
modelo
• Exemplo
 Detalhes de transformação de dados
 Resultados processados
– Técnicas de Modelagem em STR
• Técnicas Informais( ou semi-formais)
 Abordagem Orientada a Objetos
 Enfatizam a compreensão, simplificando a comunicação entre o
desenvolvedor e o usuário
 Apresentam redundâncias, inconsistências, lacunas,…
• Técnicas Formais
 Caracterizam-se pelo formalismo, em detrimento da
compreensão do modelo ou da sua facilidade de uso
 Permitem validação do modelo
– Especificação de requisitos
• Formal
 Tem uma base matemática rigorosa
• Informal
 Não pode ser completamente traduzida para uma notação
matemática rigorosa
 Uma especificação textual
 Não são suficientes para sistemas de tempo real
• Semi-formal
 Entre formal e informal
 UML? UML 2.0?
– Requisitos de sistema
• Confiabilidade
• Disponibilidade
• Segurança
• Manutenibilidade
• Portabilidade
• Reuso
– Requisitos não funcionais
• Requisitos tecnológicos
• Tolerância a Falhas
• Redundâncias
• Funcionamento degragadado
• Manutenção
• Consumo de Energia
• Tamanho, Peso
• Ergonomia
• ...
– Métodos formais na especificação de sistemas
• Os métodos formais contribuem significativamente para a
formulação e validação de requisitos pelo uso e extensão de
técnicas matemáticas eficazes
• Um dos principais benefícios dos métodos formais é que eles
fornecem uma perspectiva científica exata para a especificação do
sistema e o design de software
– Métodos formais na especificação de sistemas
• Verificação de Consistência
 O comportamento dos requisitos do sistema são descritos
usando uma notação de base matemática
• Model checking
 Utiliza máquinas de estado para verificar onde uma determinada
propriedade é satisfeita sob todas as condições
• Prova de Teoremas
 Axiomas do comportamento do sistema são empregados para
derivar uma prova de que o sistema vai se comportar sob uma
determinada forma
– Máquinas de estado finito
• Diagrama de Transições de Estados
 É um modelo formal, matemático usado na especificação e
projeto de sistemas
 Muitos sistemas podem ser representados por um número finito
de estados
 Os sistemas transitam de estado pela ocorrência de eventos
 A decorrência de um período de tempo é um evento
 Estas máquinas podem ser especificadas sob a forma de
diagramas.
• Diagrama de Transições de Estados
• Vantagens:
 Como existem técnicas matemáticas rigorosas para reduzir o
número de estados, o código do programa com base nos FSMs
pode ser formalmente otimizado. Essa otimização pode até ser
automatizada
• Desvantagens:
 Os aspectos internos dos módulos não podem ser representados.
Não há como indicar como as funções (estados) podem ser divididos
em subfunções (subestados).
 É difícil descrever a comunicação entre tarefas entre vários FSMs.
 Dependendo do sistema específico e do alfabeto usado, o número
de estados às vezes pode crescer muito grande.
– Statechats
• É uma forma de modelar o comportamento de sistemas que podem ser
descritos pelo princípio de máquinas de estado ou autômatos finitos.
• Estende os diagramas convencionais de transição de estado com
essencialmente três elementos, lidando, respectivamente, com as
noções de hierarquia, concorrência e comunicação.
– Redes de Petri
• Outra classe de métodos formais usados para especificar e analisar
operações simultâneas em sistemas em tempo real.
• É representado por um conjunto de círculos chamado "lugares" (places)
e por retângulos que representam transições ou eventos.
• Cada local (P) e transição (T) é rotulado com uma contagem de dados e
uma função de transição, respectivamente, e eles são conectados por
setas unidirecionais.
• Cada posição pode armazenar um ou mais tokens. Apenas os tokens
mudam de lugar quando uma transição dispara
• Não especificam sequências temporais
– Redes de Petri
• As rede de Petri são uma poderosa ferramenta, frequentemente utilizadas,
para a análise de race-condicions e identificação de deadlock
• Cada transição possui locais
de entrada e locais de saída.
• Uma transição pode ser
acionada se houver pelo
menos um token em cada um
de seus locais de entrada.
• Quando a transição é
acionada, um token para cada
local de entrada é consumido
e um token é gerado em cada
um dos locais de saída.
– Quando utilizar Métodos Formais
• Concorrência
 Os sistemas possuem um padrão complexo
 Sistemas de controle em tempo-real, sistemas distribuídos, projeto
de hardware e processamento paralelo
• Qualidade crítica
 Sistemas cuja confiabilidade e disponibilidade são importantes
 Aplicações financeiras, telecomunicações e Sistemas Operacionais
• Segurança crítica
 Controle de sistemas vitais – defesa, medicina, trens, entre outros
 Prevenção de acesso não autorizados – sistemas bancários,
segurança nacional, etc.
• Padronizações  Para definição de padrões, em especial padrões
internacionais e especificações de protocolos
– Limitações de Métodos Formais
• Formalismo é usado para garantir correções e segurança
 Ele pode eventualmente garantir nenhum
• Especificações formais de software tem que ser convertidas em
design e implementação
 Isto pode introduzir erros se feita manualmente
– Métodos Semi Formais
• Métodos semi formais são usados extensivamente na especificação
de sistemas em tempo real por causa de sua versatilidade típica
• A abordagem orientada a objetos fornece:
 Distributividade e simultaneidade
 Gerenciamento eficaz da complexidade
 Reutilização aprimorada
 Excelente rastreabilidade
 Melhor compreensão e capacidade de manutenção
 Maior extensibilidade
 Modularidade do design
– Métodos Semi Formais
• Mas também apresentam algumas deficiências:
 As representações voltadas com a abordagem orientada a objetos
não têm eficácia em projetos de larga escala para contexto e
comunicação
– UML
• Tem por objetivo estabelecer uma linguagem de modelagem visual
comum, semanticamente e sintaticamente rica, para arquitetura,
design e implementação de sistemas de software complexos, tanto
estruturalmente quanto para comportamentos.
• Diagramas estruturais : diagramas de classe, objeto,
componentes, implantação, pacote e estrutura.
• Diagramas comportamentais  diagramas de casos de uso,
máquinas de estados, atividades e de interação.
– Modelando processos
• Um processo é a execução de um programa sequencial
• O seu estado consiste nos valores de suas variáveis
• Conforme executa, transforma seu estado através da execução de
comandos
• Cada comando consiste de uma sequência de uma ou mais ações
não atômicas que faz com que um estado mude
• Um modelo mais abstrato apenas considera um processo tendo um
estado modificado por ações atômicas indivisíveis
 Cada ação causa uma transição de estados
 A ordem possível das ações é determinada pelo grafo de transições
 Uma representação abstrata do programa
– Programação concorrente
• Processamentos em paralelo
• Múltiplas linhas de execução
• Controle de atividades externas
• Vantagens
 Aumento de desempenho e throughput
 Estrutura apropriada para sistemas de tempo-real
 Atendimento às restrições temporais
• Desvantagens
 Aumento da Complexidade
 Sincronização
– Estados
• Separam o passado do futuro
• O estado habilita a determinação de uma futura saída baseando
somente no estado atual do sistema e da entrada futura
• O estado possui todo o histórico de um sistema
• Noção de passado e futuro
– History state ( H-state)
• Possui todas as informações necessárias para iniciar um nó ou uma
tarefa em determinado instante de tempo
• Mínimo no tempos antes e depois do cálculo
• Deve ser pequeno nos instantes de reintegração
– Ground State ( G-state)
• Feito para facilitar a reintegração dinâmica de um componente em
um sistema que já está em funcionamento
• Nesse instante, deve-se ter um history state pequeno
• Acontece quando todas as tarefas estão inativas e não há
mensagens sendo transmitidas.
Exercícios

Aula 011 - SD e de TR - Sistemas de Tempo Real

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula 011 - SD e de TR - Sistemas de Tempo Real

Enviado por

Direitos autorais:

Formatos disponíveis

Sistemas de tempo

– Young (1982) define um sistema de tempo real como:

– Randell et al., 1995

O sistema de computador distribuído consiste em nós

Um princípio importante é a separação dos

O controle temporal está relacionado ao

Você também pode gostar