ARQUITETURA

DE SISTEMAS

Jailson Costa dos Santos

Arquitetura
de softwares embutidos
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

 Caracterizar os softwares embutidos e suas necessidades.

 Discutir o projeto de sistemas embutidos.
 Descrever os padrões para o desenvolvimento de softwares embutidos.

Introdução
Os sistemas embutidos possibilitam que os computadores exerçam
controle em uma quantidade extensa de sistemas. Esse tipo de sistema
tem apresentado custo cada vez mais baixo e alto nível de acessibilidade.
Além disso, eles exigem um menor consumo de energia e se apresentam
de maneira mais compacta e com maior poder de processamento. Dessa
forma, o mundo fica cada vez mais conectado.
Neste capítulo, você vai estudar os softwares embutidos, analisando
suas características e necessidades. Você também vai explorar o desenvol-
vimento de projetos direcionados para sistemas embutidos e como esse
tipo de sistema está relacionado ao ambiente da engenharia de sistemas.
Você vai identificar os padrões de arquitetura, verificando como eles se
estabelecem e quais as suas principais características. Por fim, você vai
explorar a análise de timing, percebendo como ela se insere no processo
de desenvolvimento de um software embutido, e vai verificar o conceito
de sistemas operacionais de tempo real, analisando a sua funcionalidade.

Aspectos introdutórios sobre sistemas embutidos

Você já percebeu que os computadores conseguem exercer controle sobre uma
quantidade extensa de sistemas? Jogos, plantas de fabricação e até máquinas
de uso doméstico são alguns exemplos disso. É preciso entender que essas
2 Arquitetura de softwares embutidos

máquinas estão relacionadas com dispositivos de hardware, e os softwares

reagem a eventos criados por esses dispositivos, lançando sinais de controle
como uma reação a esses eventos, conforme leciona Sommerville (2011).
Para compreender de maneira mais efetiva sobre o funcionamento de um
sistema embutido, observe o funcionamento de um aparelho de ar-condicionado:
o equipamento é instalado em uma parede, porém, seu funcionamento é regulado
por meio de um dispositivo (controle remoto), que contém um sistema embutido
inserido nele. Isso ocorre também com refrigeradores e smart TVs que dispõem
de um controle remoto embutido para realizar suas ações.
Taurion (2005) afirma que o uso de sistemas embutidos é uma tendência
cada vez maior e que a sociedade praticamente não consegue viver sem esses
sistemas, atualmente. A indústria automobilística, por exemplo, tem encomendado
softwares que efetuam ações críticas relacionadas ao controle de frenagem e
aceleração de veículos. Vale ressaltar que uma falha ocasionada em um sistema
como esse pode trazer danos extremamente graves à organização empresarial.
É quase unanimidade a presença de softwares em aparelhos (dispositivos)
elétricos. Sistemas de telefones e eletrodomésticos, por exemplo, geralmente
apresentam uma gama de sistemas embutidos. Você pode estar se questionando:
o que diferencia o sistema embutido dos outros sistemas? Bem, a capacidade
de resposta full-time é, sem dúvida, o diferencial desses sistemas — ou seja,
neles, quase tudo ocorre em tempo real, conforme lecionam Gagner, Galvin
e Silberschatz (2008). Analisando-se, por exemplo, os sistemas mais tradi-
cionais, é possível verificar que a principal função deles está relacionada ao
processamento de dados. São sistemas que não respondem em tempo real, e
sua correção é estabelecida por meio da especificação das entradas de sistema
que monitoram as saídas relacionadas.
Quando se analisa um sistema de tempo real, observa-se que a correção
está ligada à resposta para uma determinada entrada e ao tempo suficiente
para criar essa resposta, conforme aponta Sommerville (2011). Note que,
se um sistema demorar muito para dar uma resposta, isso pode levar a uma
ineficácia na resposta obtida. Imagine, por exemplo, um software embutido
com um desempenho lento, que tenha a função de controlar um veículo que
apresenta um sistema de frenagem. A consequência disso será um provável
acidente, já que é praticamente impossível deter um carro de imediato.
É possível visualizar outras diferenças entre o sistema embutido e os sis-
temas tradicionais. Primeiramente, observa-se que os sistemas embutidos não
operam de maneira contínua, sendo iniciados quando o hardware é acionado
e devendo estar ativos até o seu desligamento. Nesse contexto, os métodos da
área de engenharia de software tendem a ser empregados para assegurar essa
 Arquitetura de softwares embutidos 3

continuidade. Segundo Sommerville (2011), é possível acrescentar técnicas

de atualização que toleram uma reconfiguração mais dinâmica, para que,
enquanto estiver no serviço, o sistema passe por constantes atualizações.
Outro aspecto está relacionado às interações existentes com o ambiente,
que normalmente são imprevisíveis e, consequentemente, incontroláveis.
Os sistemas interativos apresentam um ritmo de interação norteado pelo
sistema; ao se restringirem as alternativas de usuário, os eventos são visua-
lizados de maneira antecipada. Por sua vez, quando se analisam os sistemas
embutidos, que oferecem respostas em tempo real, é preciso verificar a sua
capacidade de tratar de eventos não programados, que podem ocorrer a qualquer
instante. Nesse cenário, são criados projetos que têm a concorrência como
referência — ou seja, diversos processos serão realizados simultaneamente.

Segundo Sommerville (2011), os sistemas interativos são sistemas de processamento

de transações que possibilitam que as informações em um banco de dados sejam
visualizadas e alteradas por diversos usuários.

Um ponto importante a ser mencionado está relacionado às restrições

físicas que atingem o projeto de um sistema. Tais limitações estão relacionadas
à energia direcionada para o sistema, além do espaço físico abrangido pelo
hardware. Portanto, essas restrições tendem a exigir atributos para o software
embutido. Pode haver a necessidade de se criar uma interação direta com
o hardware. A chamada camada de software, bastante visível em sistemas
interativos e de informações, é responsável por ocultar o hardware do sistema
operacional. Segundo Sommerville (2011), isso acontece graças a uma conexão
existente entre alguns modelos de dispositivos e esses sistemas. Entretanto,
os sistemas embutidos estão propensos a manter uma interação com uma
diversidade de dispositivos de hardware que não apresentam drivers separados.
O projeto do sistema pode ser dominado por assuntos relacionados à se-
gurança e à confiabilidade. Os dispositivos são norteados pelos sistemas
embutidos, portanto, a presença de erros indica aumento nos custos econômicos
e humanos, por exemplo. Deve-se assegurar ao projeto de sistema um perfil
crítico relacionado à segurança em situações como essa.
4 Arquitetura de softwares embutidos

Projeto de software embutido:

definições e características
O processo de projeto para sistemas embutidos consiste em um procedimento
ligado à área de engenharia de sistemas, em que os profissionais levam em
consideração o projeto e o comportamento do hardware. Uma área do processo
de projeto do sistema é responsável por definir quais recursos de sistema
serão disponibilizados tanto no software quanto no hardware. É importante
frisar que o consumo de energia e os custos de hardware são mais críticos
nos sistemas de tempo real embutidos em produtos de consumo, conforme
aponta Sommerville (2011). Outro aspecto desses sistemas é a necessidade
de utilização de processadores específicos, criados para auxiliar sistemas
embutidos, além do hardware especial construído para alguns sistemas.
Geralmente, um sistema de tempo real se caracteriza por apresentar um
processo de projeto de software em que é impraticável a verticalização; ou
seja, o uso inicial de um modelo abstrato desfragmentado, que desencadeia
uma série de etapas, não é viável. Deve-se compreender que é na fase inicial
do processo que o software de suporte, o timing de sistema e as decisões
que envolvem hardwares de nível mais baixo são levados em consideração.
Esses aspectos restringem uma ação mais flexível dos profissionais responsá-
veis pelo projeto do sistema e indicam a inclusão de requisitos de um software
adicional.

A análise de timing é um recurso utilizado por projetistas de sistemas que se baseia

no tempo orientado pelos deadlines para criar respostas aos estímulos e estabelecer
processamentos. Seu objetivo é definir a quantidade de vezes que cada processo
deve ser realizado no sistema e qual o tempo de execução estimado e verificar qual
o tempo do processo realizado de maneira insatisfatória.

É importante deixar claro que um sistema embutido tem um comportamento

reativo, ou seja, dentro do seu ambiente natural, ele costuma reagir aos eventos.
Com isso, o modelo denominado de estímulo–resposta serve de referência
 Arquitetura de softwares embutidos 5

para uma abordagem mais generalista de projetos de software embutido em

full-time (tempo real).
Observando o Quadro 1, é possível estabelecer um perfil de um sistema
real com base nos estímulos que o sistema recebe, nas respostas relacionadas a
esses estímulos e no período em que essas respostas serão geradas. O exemplo
abordado no Quadro 1 se refere a um sistema contra roubo, sendo apresentado
o comportamento que o sistema apresenta ao ser estimulado.

Quadro 1. Estímulos e respostas para um sistema de alarme contra roubo

Estímulo Resposta

Único sensor positivo  Iniciar o alarme

 Acender as luzes em torno do local do sensor
positivo

Dois ou mais  Iniciar o alarme

sensores positivos  Acender as luzes em torno dos locais de sensores
positivos
 Chamar a polícia com a localização da suspeita do
arrombamento

Queda de tensão  Comutar para bateria reserva

entre 10 e 20%  Executar o teste de fornecimento de energia

Queda de tensão  Comutar para bateria reserva

de mais de 20%  Iniciar o alarme
 Chamar a polícia
 Executar o teste de fornecimento de energia

Falha de fonte de Chamar o serviço técnico

alimentação

Falha de sensor Chamar o serviço técnico

Botão de pânico de  Iniciar o alarme

console positivo  Acender as luzes em torno do console
 Chamar a polícia

Limpar alarmes  Desligar todos os alarmes ativos

 Apagar todas as luzes que tiverem sido ligadas

Fonte: Adaptado de Sommerville (2008).

6 Arquitetura de softwares embutidos

Os estímulos são classificados em dois tipos. Os estímulos periódicos

acontecem em espaços de tempo previstos. Por exemplo, no caso de um sensor,
o sistema pode analisá-lo dentro de um curto intervalo de tempo e dar uma
resposta baseada nesse estímulo. Já os estímulos aperiódicos se caracterizam
por serem imprevisíveis e sem padrão.
É importante observar que os estímulos são originados dos sensores dentro
do ambiente do sistema, enquanto as respostas são direcionadas aos atuadores.
Assim, o projeto de sistemas de tempo real, de maneira geral, tende a apre-
sentar uma divisão de processos para cada modalidade de sensor e atuador,
conforme pode ser observado na Figura 1. Cabe aos atuadores exercerem
o papel de controle dos dispositivos, realizar as mudanças pertinentes ao
ambiente do sistema e criar estímulos. Tais estímulos servem para indicar
alguma anormalidade, que será sanada pelo sistema.

Figura 1. Processo de sensores e atuadores.

Fonte: Sommerville (2011, p. 378).

É possível criar um procedimento de gerenciamento direcionado à coleta

de dados de cada modelo de sensor. Com isso, os processamentos de dados
têm a função de mensurar as respostas que atendam aos estímulos adquiridos
pelo sistema. Cada atuador está ligado aos processos de controle responsáveis
pela sua execução. Por meio desse modelo, os dados são coletados do sensor
de maneira rápida.
 Arquitetura de softwares embutidos 7

Acesse o link a seguir e assista a um vídeo sobre as principais funcionalidades de um

sistema embutido (embarcado).

https://qrgo.page.link/mLjBK

Responder aos estímulos que acontecem em momentos distintos é uma

das funções do sistema de tempo real. Assim, é preciso que você crie uma
arquitetura sistêmica capaz de transferir o controle para o tratador correto, à
medida que os estímulos sejam recebidos. Logo, esse tipo de procedimento
não é viável em programas denominados sequenciais.
Segundo Sommerville (2011), o sistema de tempo real geralmente é criado
como uma série de processos concorrentes colaborativos. Isso significa dizer
que, para auxiliar na gestão desses processos, a plataforma de execução do
sistema pode acrescentar um sistema operacional de tempo real, cuja funcio-
nalidade é adquirida por meio de um sistema de suporte de run-time (tempo
de execução), direcionado para a linguagem de programação de tempo real
utilizada.

Não existe um procedimento padronizado em relação aos projetos de sistemas em-

butidos, já que processos distintos são empregados a partir do modelo do sistema
implementado, da disponibilização do hardware e da empresa responsável pela criação
do sistema.
8 Arquitetura de softwares embutidos

Algumas tarefas podem ser acrescidas em um projeto de software de tempo

real. Segundo Sommerville (2011), essas atividades são classificadas em:

 seleção de plataforma, que se caracteriza por selecionar plataformas

de execução para um sistema;
 identificação de estímulos/resposta, que está relacionada ao reco-
nhecimento dos estímulos processados pelo sistema e das respostas
disponibilizadas;
 análise de timing, que avalia as limitações de tempo impostas a cada
estímulo e a resposta adquirida;
 projeto de processo, que se refere à fase em que os processos concor-
rentes são agregados ao estímulo e à mudança de respostas;
 projeto de algoritmo, em que cada estímulo e resposta condiciona a
criação de algoritmos para a realização de processamentos necessários;
 projeto de dados, que consiste na especificação de informações trocadas
entre os processos e dos eventos responsáveis por essa coordenação,
sendo também responsável por gerar estruturas de dados capazes de
gerir as trocas de informações;
 programação de processo, pela qual se planeja um sistema de progra-
mação capaz de assegurar o início dos processos no tempo correto,
fazendo com que os deadlines sejam cumpridos.

Padrões de arquitetura
De maneira conceitual, pode-se dizer que os padrões de arquitetura são
definições abstratas referentes às boas práticas de projeto, conforme aponta
Sommerville (2011). Esses padrões estabelecem como as arquiteturas de sis-
temas são organizadas e qual é a sua forma de utilização, abordando os seus
benefícios e desvantagens. Entretanto, um padrão de arquitetura não pode ser
analisado como um projeto generalista. Ou seja, o padrão deve ser aplicado
para compreender o funcionamento de uma arquitetura de maneira geral e
possibilitar que você crie o seu próprio projeto de arquitetura de maneira
específica.
 Arquitetura de softwares embutidos 9

Assista à palestra Introdução ao Linux Embarcado, ministrada por Igor Tavares e disponível
no link a seguir. Nessa palestra, é demonstrado o cenário do Linux Embarcado atual e
são observadas as aplicabilidades e características desse sistema, especialmente no
que tange aos problemas relacionados à engenharia.

https://qrgo.page.link/93JFD

As diferenças existentes entre os softwares embutidos e os interativos

implicam afirmar que padrões distintos de arquitetura são empregados para
os sistemas embutidos, que, por sua vez, são orientados a processos. É possível
observar basicamente três padrões de arquitetura de tempo real que são
bastante utilizados. Veja-os a seguir.

 Observar e reagir — consiste em um padrão utilizado quando uma

série de sensores é exposta e monitorada habitualmente. Os sensores
são responsáveis por realizar sinais quando ocorrer algum evento, para
que o sistema responda e esse evento seja tratado.
 Controle de ambiente — ocorre quando um sistema acrescenta sensores
capazes de disponibilizar informações referentes ao ambiente, assim
como atuadores habilitados para promover mudanças nesse ambiente.
É perceptível a emissão de sinais de controle direcionados para os
atuadores de sistema como uma forma de responder às alterações am-
bientais verificadas pelo sensor.
 Pipeline de processo — configura-se como um padrão aplicado à medida
que os dados são transformados, passando de uma representação para
outra, antes do efetivo processamento, conforme expõe Sommerville
(2011). Essa mudança é imposta como um conjunto de fases de proces-
samento executadas simultaneamente, possibilitando que a manipulação
de dados ocorra de maneira acelerada.
10 Arquitetura de softwares embutidos

É importante mencionar que os padrões descritos podem estar dispostos de maneira

combinada; ou seja, é possível observar mais de um padrão inserido em um mesmo
sistema.

Como você pode perceber, os padrões abordados se referem à arquitetura,

que apresenta aspectos da estrutura geral de um sistema embutido. Tais padrões
são considerados um start para a implementação de um projeto de sistemas
embutidos. Porém, eles não podem ser vistos como modelos de projeto, o que
levaria a uma interpretação errônea do processo de arquitetura. É preciso aper-
feiçoar a estrutura de processo, visando a assegurar a redução dos processos,
garantindo uma relação direta entre eles e os atuadores e sensores do sistema.

Análise de timing
Corrigir um sistema de tempo real envolve compreender como as saídas são
criadas. Nesse contexto, a análise de timing se insere como uma tarefa relevante
no processo de desenvolvimento de um software embutido. Nesse modelo
de avaliação, é possível medir a frequência com que o processo do sistema,
de maneira individualizada, é realizado, para assegurar que as entradas, em
sua totalidade, sejam processadas e que todas as respostas do sistema sejam
criadas dentro do período correto, conforme orienta Sommerville (2011).
Os resultados obtidos por meio da análise de timing são utilizados para definir
com que frequência cada processo será realizado, uma vez que esses processos
precisam ser planejados por meio do sistema operacional de tempo real.

Acesse o link a seguir e leia o artigo “Análise de requisitos temporais para sistemas
embarcados automotivos”, que apresenta as características e funcionalidades dos
sistemas automotivos embutidos.

https://qrgo.page.link/3ErVz
 Arquitetura de softwares embutidos 11

Cabe frisar que a análise de timing direcionada para sistemas de tempo

real é complexa, na medida em que os sistemas lidam com a combinação de
estímulos periódicos, aperiódicos e respostas. Para lidar com a imprevisibili-
dade dos estímulos aperiódicos, é preciso realizar pressuposições referentes às
possibilidades de eles acontecerem e solicitarem serviços a qualquer instante.
Existe a possibilidade de que esses pressupostos estejam errados, devido ao
comportamento inadequado do sistema após a entrega.
O projeto de muitos sistemas utilizando apenas estímulos periódicos passou
a ser viável graças à inovação e à rapidez dos computadores. Em processadores
mais lentos, os estímulos aperiódicos eram utilizados com maior frequência,
visando a assegurar o processamento dos eventos críticos em um período
anterior ao deadline, já que geralmente, os atrasos ocorridos no processamento
resultavam em alguma perda sistêmica.
Para realizar uma análise dos atributos característicos do timing dos sis-
temas embutidos, além de planejar sistemas que atendam a esses requisitos,
é preciso verificar alguns fatores essenciais, como os deadlines, que estão
relacionados ao período em que os estímulos serão processados e o sistema
apresentará alguma resposta. Além dos deadlines, outros fatores podem ser
analisados; por exemplo:

 a frequência, que representa a quantidade de vezes, por segundo, que

a execução de uma atividade ocorre por meio de um processo, para se
certificar de que o sistema consegue exercer seus deadlines;
 o tempo de execução, que se refere ao tempo ideal para realizar o
processamento de um estímulo e criar uma resposta.

É preciso levar em consideração que existem basicamente dois tempos

distintos de execução: o tempo médio de execução de um processo e o pior
tempo de execução para esse processo.

Sistemas operacionais de tempo real

Segundo Sommerville (2011), a plataforma de execução disponível para grande
parte dos sistemas que envolvem aplicações pode ser definida como um sistema
operacional que administra recursos compartilhados, além de oferecer atribu-
tos, como um sistema de arquivos. Entretanto, vale ressaltar que um sistema
operacional considerado convencional ocupa espaço e atrasa a execução dos
programas, devido à sua ampla funcionalidade. Isso explica o fato de que alguns
12 Arquitetura de softwares embutidos

sistemas considerados como padrão, como o Windows, geralmente não são

utilizados como plataforma de execução para sistemas full-time.
Os aplicativos embutidos são desenvolvidos por meio de um sistema opera-
cional que opera em tempo real (RTOS, do inglês real time operating system),
que consiste em um sistema que disponibiliza os recursos necessários para os
sistemas que atuam em full-time. Entretanto, os sistemas embutidos conside-
rados mais simples em relação ao seu desenvolvimento podem ser aplicados
sem um sistema operacional padrão, já que o próprio software apresenta os
procedimentos de inicialização e desligamento do sistema, além da gestão e
programação dos processos.

Os processos e a alocação dos recursos para um sistema de tempo real são geridos por
um RTOS. Ele dá início e interrompe os processos, para que os estímulos possam ser
tratados e os recursos de memória sejam direcionados e processados. Os elementos
de um RTOS estão relacionados ao tamanho e à complexidade do sistema de tempo
real que está sendo criado. Segundo Sommerville (2011), os sistemas RTOS, de maneira
geral, incluem:
 um relógio de tempo real, que disponibiliza informações cruciais para programar
os processos;
 um tratador de interrupções, que administra requisições aperiódicas de serviço;
 um programador, que tem a função de analisar os processos que podem ser rea-
lizados e selecionar um deles para execução;
 um gerenciador de recursos, no sentido de direcionar os recursos de memória, um
processador, para os processos serem programados na execução, e um despachador,
responsável por dar início à realização dos processos.
 Arquitetura de softwares embutidos 13

GAGNER, G.; GALVIN, P. B.; SILBERSCHATZ, A. Sistemas operacionais com Java. Rio de
Janeiro: Elsevier, 2008.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
TAURION, C. Software embarcado: oportunidades e potencial de mercado. Rio de
Janeiro. Brasport, 2005.

Leituras recomendadas
MENDES, A. Arquitetura de software. Rio de Janeiro: Campus, 2002.
PRESSMAN, R. S. Engenharia de software. São Paulo: Pearson Education do Brasil, 1995.