Sistemas Embutidos (embarcados)

Paulo C. Masiero

Caracterização

• São usados para controlar sistemas de diferentes tipos: máquinas domésticas, fábricas, carros, jogos etc.

• O software é embutido no hardware do sistema e com ele interage

• O tempo de resposta o diferencia de outros sistemas.

• É o tipo de sistema mais comum, com grande impacto econômico.

• Muitas vezes está integrado a um Sistema de Informação.

Definições

• SEs são sistemas de processamento de informação embutidos (ou embarcados) em um produto maior (Peter Marwedel)

• SE é um software integrado com processos físicos. O problema técnico é gerenciar tempo e concorrência em sistemas computacionais.

• Sistemas Ciber-Físicos (SCF, ou CPF: Cyber –Physical Systems) são a integração da computação com processos físicos (Edward Lee, 2006)

SEs devem ser “confiáveis” • Reliability R(t) = probabilidade de um sistema operar

corretamente desde que ele esteja operando no tempo t=0. • Maintainability M(d) = probabilidade de um sistema operar

corretamente d unidades de tempo após a ocorrência do erro. • Availability A(t): probabilidade de um sistema operar

corretamente no tempo t • Safety: nenhum prejuízo (mal) será causado • Security: comunicação confidencial and fidedigna

– Mesmo sistemas perfeitamente projetados podem falhar

se as suposições sobre sua carga de trabalho e possíveis erros se mostrarem incorretas.

– Tornar o sistema “confiável” não pode ser uma consideração posterior ao seu desenvolvimento, deve ser considerada desde o seu início.

Sistema de Tempo real

• O funcionamento depende dos resultados produzidos pelo sistema e do tempo em que esses resultados são produzidos

• STR Leve: se a operação for degradada caso os resultados não sejam produzidos de acordo com os requisitos de tempo/desempenho.

• STR Rígido (ou pesado ou crítico): se a operação for incorreta caso os resultados não forem produzidos de acordo com os requisitos de tempo/desempenho.

Eficiência

• Os SE embutidos devem ser eficientes quanto ao:

– Código (especialmente para os sistemas em chip)

– Tempo de execução

– Peso

– Custo

– Energia

SE e Hardware

Geralmente:

• O software que executa em um computador e controla outras máquinas é um sistema embarcado de tempo real.

• Recebe eventos (sinais) gerados pelo hardware e emite sinais de controle para o hardware em resposta a esses eventos.

• A resposta pode estar condicionada a restrições de tempo.

Requisitos de Tempo-Real

• Um sistema de tempo real (STR) deve reagir a estímulos do objeto controlado em um intervalo de tempo determinado pelo ambiente.

• Um requisito (ou restrição) de tempo de tempo é chamado de “crítico” (hard) quando ele não for satisfeito causar uma catastrofe (Kopetz, 1997).

• Para STR, respostas corretas muito tarde são erradas.

• Uma resposta garantida do sistema tem que ser explicada sem argumentos estatísticos.

SCF, STR e SE são sinônimos?

• Para alguns SE, comportamento de tempo real é menos importante. Ex. Tel. Celular. Daí SE ~ STR

• Para SCF, o comportamento de tempo real é essencial. Daí SCF STR

• Modelos de SCF também incluem um modelo do sistema físico.

• SE tipicamente modelam componentes de TI. Daí SCF SI (Componentes de TI) + Modelos Físicos

Aplicações: Eletrônica automotiva (claramente ciber-física)

• ABS: Anti-lock braking systems

• ESP: Electronic stability control

• Airbags

• Chaves inteligenets (prevenção de furtos)

• Sistemas de alerta de ângulo-cego.

• Etc.

Idem para aviões e VANTS

SE em outras indústrias

• Painéis de fornos de micro-onda, máquinas de lavar roupa, geladeiras etc.

• Alarmes anti-furtos (uso doméstico)

• Telefones celulares

• Dispositivos médicos

• Etc.

Projeto de Sistemas Embarcados

• É um processo de engenharia de sistemas em que os projetistas de software devem considerar em detalhes o projeto e o desempenho do hardware

• Um processo de cima para baixo(top down) pode ser difícil de usar. Decisões de baixo nível podem ter que ser consideradas no início do projeto.

• Esses fatores diminuem a flexibilidade do projeto.

Projeto de Sistemas Embarcados (Cont.)

• Os sistemas são geralmente reativos e baseados numa abordagem estímulo-resposta.

• O estímulo é uma entrada geralmente proveniente de sensores e deve produzir uma como saída uma resposta geralmente dirigida a atuadores

• Os estímulos podem ser de duas categorias: – Periódicos: ocorrem em intervalos previsíveis

– Aperiódicos: ocorrem de forma irregular e imprevisível

Projeto de Sistema Embutido (Cont.)

• Deve considerar em detalhes o projeto e o desempenho do hardware do sistema.

• É preciso decidir que recursos deve ser implementado em software e que parte em hardware

• Custos e consumo de energia são críticos.

• É necessário decidir se serão usados processadores de prateleira (ex. fpga) ou se deverá ser projetado e construído um novo hardware.

Um modelo sensor-sistema-atuador

Diretriz geral: processos separados para cada tipo de sensor e atuador.

PSE (Cont.)

• Atuadores também podem gerar estímulos (geralmente indicando problemas ocorridos)

• A arquitetura do sistema deve ser organizada para que, assim que um estímulo seja recebido, o controle seja transferido para o tratador correto.

• Isso é impraticável em sistemas sequenciais processos concorrentes.

Arquitetura genérica abstrata

• Contém 3 tipos de processos

• Para cada sensor existe um processo gerenciador

• Para cada atuador há um processo gerenciador

• Há um ou mais processos controladores/processadores.

• Essa arquitetura genérica pode ser instanciada para arquiteturas específicas. Ex.: sistemas de monitoração e de aquisição de dados.

Sistemas de tempo real

• As linguagens de programação precisam incluir recursos de baixo nível. Ex. C.

• Java vem sendo atualizada para incluir vários mecanismos que permitam o uso em sistemas de tempo real. – O mecanismo básico são as threads

• Mas já existem linguagens de alto nível (chamadas também de “modelos”) que permitem implementar sistemas embarcados.

Projeto de Sistemas Embutidos

• Não há um processo –padrão de sistemas embutidos e eles são definidos de acordo com o tipo e complexidade do sistema, do hardware disponível e da organização que está desenvolvendo.

• Decisão importante: quais partes serão implantadas como hardware e quais partes serão implantadas como software.

• Para muitos STR embutidos, os custos, consumo de energia e espaço são críticos.

Projeto de Sistemas: Atividades Principais

1. Seleção da plataforma (Hardware e SO)

2. Identificar estímulos e respostas

3. Analisar restrições temporais (timing), para cada estímulo (restrições de tempo)

4. Projeto de processos (concorrentes), os estímulos e respostas são agregados em processos concorrentes de acordo com a arquitetura do sistema.

Projeto de Sistemas: Atividades Principais

5. Projeto de algoritmos, para fazer o processamento necessário para cada estímulo e resposta

6. Projeto de dados: informações entre processos e eventos que coordenam a troca de informações

7. Programação de processo: projetar um sistema de alocação (scheduling) que permita atender as restrições temporais.

Processos de sensores e atuadores

Algumas considerações

• Coordenação de processos (semáforos, regiões críticas).

• Análises teóricas para avaliar se as restrições temporais serão atendidas. Isso pode ser difícil

• Linguagens OO podem não ser eficientes para implementar um STR.

Algumas considerações (Cont.)

• Os processos podem executar com diferentes velocidades.

• Isso pode ser resolvido implementando trocas de informações por meio de “buffers” compartilhados e uso de exclusão mútua para controlar o acesso ao buffer.

Modelagem de STR

• A resposta aos estímulos muitas vezes depende do estado do sistema uso de diagramas de estado

• UML: statecharts

• Um modelo de estado considera que em qualquer momento o sistema está em um dos vários estados possíveis. Os estímulos causam a transição para outros estados.

• Exemplo: uma bomba de gasolina automática

Exemplo: controlador de uma bomba de gasolina

Programação em Tempo Real

• As LP para desenvolver STR precisam ter recursos para: – Acessar o hardware

– Prever o tempo de duração de determinadas operações

• Muitas vezes se usa linguagens montadoras

• Também é necessário suporte para concorrência e gestão compartilhada de recursos.

Padrões de arquitetura

• Um padrão de arquitetura pode ser pensado como um projeto genérico para ser instanciado.

• Os padrões de SE são orientados a processos, em vez de orientados a objetos e componentes.

• Três padrões: – Observar e reagir – Controle de ambiente – Pipeline de processo

• Esses padrões podem ser combinados e haver mais de um deles em um mesmo sistema.

Observar e reagir

• É usado quando um conjunto de sensores é monitorado e exibido rotineiramente. Quando os sensores mostram que ocorreu um evento, o sistema reage e trata esse evento (ex. ligar um alarme).

• O estado do ambiente monitorado pelos sensores pode ser exibido em uma tela interna, telas especiais ou remotamente.

Exemplo: sistema de alarme contra furto

Descrição do Sistema

Controle de ambiente

• Quando o sistema inclui sensores que fornecem informações sobre o ambiente e atuadores capazes de alterar o ambiente, enviando sinais para os atuadores.

• São geralmente chamados de “sistemas de controle” e controlam equipamentos. Talvez seja o caso mais comum de sistemas embutidos.

• Ex: Freio ABS, controle de um aparelho de ar condicionado

É opcional

Padrão Pipeline

• Usado quando dados devem ser transformados de uma representação para outra antes de serem processados.

• Isso leva a uma sequência de processamentos, o que pode eventualmente ser feito em paralelo por diferentes processadores.

• Ex. um rádio que recebe pacotes de dados digitais e os transforma em sinais sonoros e depois transmite.

Padrão Pipeline (Cont.)

• É uma arquitetura eficiente quando se usam vários processadores ou processadores de muitos núcleos (cores)

• Exemplo típico: coleta (aquisição) de dados, em sistemas científicos e sistemas de controle.

• Os sensores podem gerar dados rapidamente e é preciso garantir que não se percam dados.

• Exemplo: Aquisição de dados em um reator nuclear.

Análise de tempos (timing)

• É o cálculo da frequência de execução de cada processo para garantir que todas as entradas sejam processadas e todas as saídas sejam produzidas no tempo esperado.

• O resultado é usado para decidir a frequência de execução e como o SOTR executará o processo.

• A análise é mais difícil quando o mesmo sistema trata eventos periódicos e aperiódicos

Fatores a considerar na análise

• Limites (Deadlines): o tempo para processar as entradas e produzir as saídas.

• Frequência: O número de vezes por segundo que um processo deve executar para cumprir seus deadlines

• Tempo de execução: o tempo necessário para processar as entradas e produzir as saídas . – Este tempo pode variar, por exemplo, pela execução

de um comando condicional.

– Análise do pior caso

Eventos aperiódicos

• Como são imprevisíveis, é necessário fazer suposições sobre sua taxa de chegada (probabilidade de ocorrência).

• As previsões podem não corresponder ao que ocorre quando o sistema se torna operacional.

• Como os computadores se tornaram mais rápidos, eventos aperiódicos podem ser tratados como eventos periódicos.

Eventos aperiódicos (cont.)

• Exemplo: uma falha de alimentação em um sistema embarcado pode significar que o SE precisa desligar o sistema físico de forma controlada, em um tempo definido (50ms, digamos)

• Aperiódico: implementar como uma interrupção de “falha de energia”

• Periódico: processo que é executado com alta frequência e verifica a energia, com tempo para desligar o sistema se detectar uma falha.

Análise de falha de energia

• Suposição: se houver falha de energia, demora 50ms para ela atingir um ponto que cause danos ao equipamento.

• Precaução: prever um limite de 40ms por causa de variações físicas nos equipamentos.

• Para ter certeza, fazer pelo menos duas observações para garantir a queda.

• Processo executa 250 vezes por segundo execução a cada 4ms 8ms para detectar o problema

Análise de falha de energia (Cont.)

• O pior caso de tempo de execução é 16ms

– São necessários 8ms para detectar o problema

– como são necessárias duas execuções do processo, temos (40ms – 8ms)/2= 16ms

• Para ter uma margem de segurança, o tempo de execução do processo deve ser bem menor que 16ms.

Sistema de alarme contra roubos • Listar as restrições de tempo para cada classe de sensor

separadamente • Atribuir processos concorrentes para cada tipo de sensor (há 4

tipos: tensão, porta, janela e movimento). • Como a checagem deve verificar se o estado do sensor mudou

(ex. de desligado para ligado), é razoável supor que o tempo de execução desse processo seja menor que 1ms.

Sistema de alarme contra roubos • Em seguida, decidir:

– Como os processos relacionados vão executar – Quantos sensores serão examinados em cada execução do

processo

EXEMPLOS: • Examinar 1 sensor por execução e N sensores de cada

tipo programar os processo para 4N vezes por segundo, para garantir que o limite de 0,25 ms por sensor seja satisfeito.

• Examinar 4 sensores por execução e N sensores tempo de execução = 4ms, mas o processo precisa ser executado só N/4 vezes/segundo para atender ao requisito de tempo.

R= Resposta ( a uma entrada) B= Background (2º. Plano) Processos periódicos são anotados com sua frequência O tempo de execução representado é o pior tempo

Sistema de alarme contra roubos (finalizando)

• O Sistema Operacional de Tempo Real deve ser usado para garantir a programação de processos que atendam aos deadlines. – O SOTR aloca um processo para um período de tempo, que

pode ser fixo ou variar, de acordo com a prioridade do processo.

• Processos com tempos mais estritos devem receber prioridade maior – Por exemplo, o processo “monitor de tensão” deve ter

prioridade mais alta que os demais porque precisa detectar a queda de tensão e a mudança para o gerador de backup seja feita com tempo para não parar o sistema.

Sistema Operacional de Tempo Real

• Muitos sistemas embutidos funcionam com um SOTR ou podem ser executados sem um sistema operacional.

• Os SOTR podem ser muito simples ou grandes e complexos. – Windows/CE, Vxworks e RTLinux

• Em geral possuem: relógio de tempo real, tratador de interrupções, alocador (scheduler) gerenciador de recurso e despachador

Gerenciamento de Processos

• É preciso tratar processos com prioridades

• Deve haver pelo menos dois níveis de prioridade:

– Nível de interrupção, para os processos que precisam de resposta muito rápida

– Nível de relógio, para os processos periódicos

Gerenciamento de Processos

• UM SOTR deve implementar pelo menos dois tipos de níveis prioridade para processos:

– Nível de Interrupção: é alocado para processos que exigem resposta muito rapidamente. Ex. o processo de relógio de tempo real.

– Nível de relógio: é alocado para processos periódicos

• Um terceiro nível, de 2º. Plano, também é desejável para processos que não precisam satisfazer deadlines. Ex: autoverificação e teste.

Gerenciamento de Processos (Cont.)

• Diferentes classes de processos podem ser alocados a diferentes prioridades.

• Muitas vezes dois processos diferentes devem ser executados no mesmo tique do relógio um deles deve ser retardado ( o que tiver maior deadline?).

Gerenciamento de Processos (Cont.)

• Processos que precisam responder rapidamente a eventos assíncronos podem ser dirigidos por interrupção.

• O SOTR tem políticas que determinam a ordem de execução de processos: – Programação não preemptiva

– Programação preemptiva

• Há diferentes algoritmos para isso: round-robin, rate monotonic (processo mas curto/frequência mais alta), shortest deadline first

Sistemas de monitoração e controle

• É uma categoria importante de STR

• Verificam sensores que fornecem informação sobre o ambiente do sistema e executam ações que dependem da leitura do sensor

• Sistemas de monitoração executam ações de acordo com os valores/sinais dos sensores

• Os sistemas de monitoração controlam continuamente os atuadores de hardware de acordo com os valores dos sensores associados.