See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/267298521

Projeto de Sistemas Embarcados

Article

CITATION READS

1 743

1 author:

Marcos Zurita
Universidade Federal do Piauí
6 PUBLICATIONS   24 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Marcos Zurita on 20 November 2014.

The user has requested enhancement of the downloaded file.

 Projeto de Sistemas Embarcados
Marcos E. P. V. Zurita
Universidade Federal do Piauí, Curso de Engenharia Elétrica
Campus Universitário Ministro Petrônio Portela - 64049-550 - Teresina – PI
zurita@ufpi.edu.br, www.ufpi.edu.br/zurita

Resumo sistemas embarcados. Por outro lado, a

complexidade cada vez maior das novas aplicações
A vasta gama de aplicações nas quais os sistemas e o aumento da dinâmica do mercado consumidor
embarcados estão presentes atualmente requer
tem exigido a melhoria das técnicas e metodologias
diferentes técnicas e abordagens para sua empregadas em seu projeto de forma e executa-lo
elaboração. O conhecimento prévio dessas
no menor espaço de tempo possível. Isto significa
metodologias e sua correta adoção é de que os profissionais que pretendem atuar nessa área
fundamental importância para o sucesso do projeto
precisam estar familiarizados com essas
em condições limitadas de tempo e recursos. Nesse metodologias e técnicas de projeto, bem como as
sentido, são abordados neste documento alguns
particularidades desse tipo de sistema.
conhecimentos introdutórios fundamentais a
respeito de sistemas embarcados e seu projeto, no Neste artigo são apresentados alguns conceitos
intuito de guiar os passos iniciais para o básicos a respeito de sistemas embarcados e uma
aprofundamento no tema. breve introdução respeito do seu projeto.
1 Introdução 2 Sistemas Embarcados
A popularização dos microprocessadores, iniciada Um Sistema Embarcado (SE), é definido pela IEEE
em meados da década de 80, aliada à contínua [3] como “um sistema computacional que faz parte
redução dos custos da tecnologia, deu início a uma de um sistema maior e implementa alguns dos
verdadeira revolução na vida cotidiana. Os requerimentos deste sistema”. Esta definição,
processadores, antes quase totalmente restritos a estabelecida há mais de duas décadas continua
computadores corporativos e algumas grandes válida, embora a revolução experimentada por esse
máquinas, hoje podem ser encontrados segmento durante estes últimos anos tenha
praticamente por toda a parte. Automóveis, impulsionado alguns autores a complementarem-na.
televisores, brinquedos, máquinas de lavar, Nesta linha, Steve Heath o define como sendo “um
telefones, aparelhos de som, relógios de pulso, sistema baseado em um microprocessador, que é
cartões de banco e até mesmo etiquetas de projetado para controlar uma função ou uma gama
identificação descartáveis [1] são hoje objetos de funções, e não para ser programado pelo
permeados por microprocessadores. A adoção de usuário final como ocorre com os PCs” [4].
microprocessadores fora do universo dos
computadores pessoais e corporativos, deu origem Por se tratarem de sistemas computacionais, Arnold
aos chamados Sistemas Computacionais Berger [5] prefere descreve-los enumerando as
Embarcados, ou simplesmente “Sistemas características que os distinguem dos computadores
Embarcados”. pessoais. São elas:

Segundo uma recente pesquisa realizada pela IDC 1. São dedicados a tarefas específicas enquanto
[2], cerca de 19% de todos os sistemas eletrônicos PCs são plataformas genéricas de
vendidos hoje no mundo são sistemas embarcados, computação – Esta característica tem
e este número deverá crescer para 33% até 2015. impacto principalmente no poder
Eles são atualmente responsáveis por uma receita computacional da máquina. PCs devem
anual de 1 trilhão de dólares, o que deve dobrar nos poder rodar um grande número de
próximos 4 anos, quando então serão responsáveis aplicativos, com diferentes exigências de
pelo consumo de cerca de 14,5 bilhões de processamento, mantendo um bom
processadores por ano, mais de 2 para cada desempenho, enquanto SEs precisam realizar
habitante no mundo. apenas uma ou poucas tarefas bem
específicas;
O rápido crescimento desse setor implica numa
demanda igualmente crescente de recursos 2. São suportados por uma vasta gama de
humanos adequados para poder suplanta-lo. Em processadores e arquiteturas de
outras palavras, há uma imensa oportunidade para processadores – Atualmente, mais de 40
projetistas e desenvolvedores na área de projetos de empresas de semicondutores disputam o
mercado de microprocessadores e
 microcontroladores [6]. Cada uma delas por grande variedade. A indústria automotiva,
sua vez oferece várias soluções distintas. por exemplo, possuí um padrão chamado
Apenas a Microchip [7], uma das líderes OSEK, no qual estão definidas uma série de
deste segmento, tem hoje uma lista de mais especificações a serem seguidas pelos seus
de 500 diferentes microcontroladores. RTOSs [13].
Naturalmente, um grande leque de opções
aumenta o grau de liberdade de escolha dos 6. Neles, as implicações de uma falha de
projetistas mas também requer deles software são muito mais severas do que num
conhecimento adequado para encontrar as desktop – muitos SEs interagem com o
soluções mais apropriadas a cada projeto; ambiente ou seres humanos, como é o caso
de sistemas de vida-críticos (life-critical
3. São geralmente sensíveis aos custos – a systems) [14][15], por exemplo. Falhas
maior parte dos sistemas embarcados podem ter consequências no ambiente, no
possuem bem menos componentes e custam próprio sistema ou até mesmo nas pessoas
bem menos do que um PC. Evidentemente o em torno dele. Um bug no software do
impacto nos custos da adição de meia dúzia sistema de injeção eletrônica de um
de componentes é bem mais significativo automóvel, por exemplo, pode reduzir a vida
num sistema que possui uma dúzia deles do útil de componentes do motor e aumentar o
que num que possui mais de uma centena. consumo e a emissão de gases poluentes. Um
Em alguns sistemas de identificação sem bug no software de controle da dosagem de
contato (RFId), um simples capacitor pode radiação de uma máquina de raios-X poderia
representar até 20% dos custos totais [8]. ter consequências sérias na saúde do
paciente. Por essa razão, muitos SEs
4. Possuem requisitos de tempo-real – neste possuem mecanismos de segurança para
aspecto, SEs geralmente podem ser divididos detectar e contornar falhas, tal como o
em dois grupos: os que possuem requisitos watchdog timer [16]. Neste aspecto, Peter
de “tempo sensível” e os que possuem Marwedel [17] estabelece 5 parâmetros de
requisitos de “tempo crítico”. As tarefas de caraterização de SEs:
tempo crítico são intolerantes a atrasos,
devem ser realizadas dentro de um intervalo • Confiabilidade: é a probabilidade do
preciso de tempo ou a tarefa falha. O sistema sistema de não falhar;
de acionamento dos airbags de um carro são
um bom exemplo disso. Nele, alguns • Manutenibilidade: é a probabilidade
milissegundos podem fazer a diferença entre que uma falha no sistema possa ser
salvar ou não a vida do motorista [9]. Tarefas corrigida em um certo intervalo de
de tempo sensível, por outro lado, são mais tempo;
tolerantes. Se a tarefa responsável pelo • Disponibilidade: é a probabilidade do
fechamento da válvula de água de uma sistema estar disponível. Será tanto
máquina de lavar atrasar um ou dois maior quanto maior for sua
segundos, a roupa será lavada com um pouco confiabilidade e manutenibilidade;
mais de água além do necessário, perdendo
um pouco da eficiência almejada; • Segurança: descreve a probabilidade
do sistema de não causar algum tipo de
5. Quando utilizam um sistema operacional, dano;
este é quase sempre um RTOS – A principal
• Confidencialidade: descreve quão
diferença entre um Sistema Operacional de
capaz é o sistema de manter dados
Tempo Real (RTOS – Real Time Operating
confidenciais e de garantir uma
System) e um sistema operacional
comunicação autenticada;
convencional é que num RTOS a importância
para o sistema da finalização de uma tarefa é 7. Costumam ter restrições no consumo de
um valor que varia com o tempo [10][11]. energia – Ao contrario dos PCs, grande parte
Este valor geralmente é descrito em termos dos sistemas embarcados são alimentados
de deadlines para finalização de cada tarefa. unicamente por pequenas baterias. Neles, a
Uma vez que o tempo de resposta é visto redução de alguns miliwatts/hora no
como parte crucial da exatidão do software consumo pode estender a duração das
(SW), ele deve poder ser comprovado sem baterias por dias ou meses. Frequentemente,
argumentos estatísticos [12]. Assim como os a responsabilidade de poupar energia é
microcontroladores, os RTOSs existem em atribuída unicamente aos engenheiros do
 hardware (HW), mas em SEs essa memórias RAM de alta capacidade,
responsabilidade deve ser compartilhada processadores gráficos e monitores de alta
também pelos desenvolvedores do software. resolução, são recursos comuns dos desktops
Em um PDA, por exemplo, o consumo pode atuais. A capacidade de armazenamento da
ser reduzido em até 60% através de memória RAM desses computadores
alterações na forma como o software é pessoais é maior do que todo o disco rígido
escrito [18]. Evidentemente, as escolhas de um típico PC do final da década de 90.
feitas no projeto do hardware tem impacto Com isso, a maior parte dos aplicativos
crucial no consumo do sistema. Em muitos podem ser escritos assumindo a memória
SEs o principal vilão do consumo é o como um recurso infinito. Para um sistema
processador, mas esse nem sempre é o caso. embarcado a realidade é bem diferente. Na
A Pathfinder, sonda espacial enviada para maior parte deles a RAM não chega a
Marte, por exemplo, teve o consumo como quinhentos bytes, todo o SW deve caber em
uma das principais restrições de projeto. alguns poucos kB e rodar em um processador
Todos os módulos da sonda foram projetados cujo clock mal chega a 20 MHz. A
para poderem ser ligados e desligados quantidade de teclas é bastante limitada
individualmente e a sonda inteira permanecia fazendo com que precisem acumular funções.
em “sleep mode” durante a noite, quando as Muitos não tem sequer um display e a
células fotovoltaicas deixavam de captar interface com o usuário se dá através de
energia e a eficiência da bateria caía devido à LEDs e sons. Evidentemente, o código
queda de temperatura. Mesmo quando em escrito para essas aplicações precisa observar
modo operacional, o software não podia uma série de cuidados que os voltados para
manter ligado mais de um módulo ao mesmo PCs não precisam. Uma simples operação
tempo devido à escassez de energia matemática, pode consumir 1% ou 70% da
disponível [19]; memória em um dado microcontrolador,
dependendo apenas da forma como é escrita;
8. Devem poder operar em condições
ambientais extremas – A natureza portátil de 10. Geralmente todo seu programa fica
muitos sistemas embarcados implica que eles armazenado em uma ROM – Esta
devem ser capazes de suportar as mesmas característica pode parecer insignificante mas
condições que seus usuários ou sistemas não é. Ter seu código armazenado em uma
receptores. Um PDA deve poder funcionar à ROM impõe severas limitações ao sistema. A
40ºC na praia de Copacabana, a -15ºC nos primeira, discutida anteriormente, diz
Alpes ou a 11.000 metros de altitude na respeito ao tamanho do código. A outra está
cabine de um avião. Da mesma forma, o ligada aos métodos usados para projeta-lo.
sistema de frenagem ABS deve funcionar no Um código armazenado numa ROM não
calor de 45ºC de Teresina, no frio de -5ºC de pode ser depurado da mesma maneira como
Porto Alegre, em dias secos e dias chuvosos, ocorre nos PCs. Para inserir um breakpoint, o
e em todas essas mesmas condições após depurador precisa remover uma instrução do
5.000 km de estrada de terra trepidante. Os programa e substitui-la por outra responsável
requisitos ambientais de operação geralmente por desviar a execução para algum ponto do
têm consequências diretas no hardware e as depurador, tarefa impossível numa memória
vezes até mesmo no software. Um que não pode ser alterada aleatoriamente;
processador que precise ser selado em
borracha de silicone para poder suportar 11. Requerem ferramentas e métodos
elevados índices de umidade, terá sua especializados para serem eficientemente
capacidade de dissipação térmica projetados – O fato dos sistemas embarcados
comprometida e precisará ter seu clock serem compostos por hardware e software
reduzido, afetando o desempenho do integrados exige mudanças na sua forma de
software; concepção, teste e depuração, em relação a
um projeto de hardware e um projeto de
9. Seus recursos de sistema são extremamente software feitos isoladamente. Depurar um
menores do que os de um desktop – sistema de processamento de vídeo no qual
Processadores com múltiplos núcleos parte dos blocos são implementados em
rodando à frequências superiores a 2 GHz, software e outra parte em hardware não é
discos rígidos com capacidade da ordem de uma tarefa nada trivial e necessita bem mais
tera-bytes, barramentos de alto desempenho, do que um simples aplicativo de depuração.
portas de comunicação de alta vazão, Muitas vezes, é necessário projetar uma
 plataforma que emule o sistema no qual o SE um modelo formal deve conter:
será integrado, paralelamente ao projeto
deste, para ser usado nas etapas de teste e • Uma especificação funcional, sob a forma
depuração. Depurar um sistema de controle de um conjunto de relações explícitas ou
de altitude usando o próprio avião não é implícitas que envolvem entradas, saídas, e
muito prático, tampouco uma boa ideia; possíveis estados internos;

12. Microprocessadores embarcados geralmente • Um conjunto de propriedades que o projeto

possuem circuitos dedicados para depuração deve satisfazer, dadas na forma de um
– Conforme explicado anteriormente, a conjunto de relações entre entradas, saídas
depuração do código programado em uma e estados, que possam ser comparados com
ROM encontra sérias dificuldades. Por essa a especificação funcional;
razão, microprocessadores voltados para • Um conjunto de índices de desempenho
aplicações embarcadas costumam incluir que avaliem a qualidade do projeto em
circuitos especialmente dedicados à termos de custo, confiabilidade, velocidade,
depuração. Alguns fabricantes oferecem duas tamanho, etc., dados como um conjunto de
versões dos seus microprocessadores, uma equações que envolvam, entre outras
“de desenvolvimento”, contendo os recursos coisas, entradas e saídas;
de depuração, necessários ao projeto, e uma
versão “de produção”, sem tais recursos, a • Um conjunto de restrições sobre os índices
fim de poupar área de silício e reduzir os de desempenho.
custos do componente. Dessa forma, o projeto durante o processo de
Uma vez expostas, em linhas gerais, as especificação e modelagem pode ser visto como a
características típicas de um sistema embarcado, sequência de passos que implementam o modelo
torna-se evidente a necessidade do estudo e especificado cumprindo as formalidades descritas
domínio de metodologias de projeto que permitam acima.
implementa-lo de forma eficiente no menor tempo Uma vez estabelecido o modelo, ele deve ser
possível. validado. Segundo o IEEE [22], a verificação e
3 Projeto de Sistemas Embarcados validação de software tem como principal objetivo,
determinar durante o ciclo de vida do software, se
O projeto de sistemas embarcados deve seguir uma os requisitos do próprio software e do sistema estão
metodologia precisa. Segundo Waine Wolf [20], corretos, completos, precisos e consistentes,
três razões principais justificam a importância de se assegurando assim a qualidade de um produto de
seguir uma metodologia de projeto: 1 - permitir que software. Este conceito pode ser estendido também
o cumprimento dos requisitos de projeto possam ser para componentes de hardware, até porque eles
assegurados de maneira formal à medida que o também podem ser modelados em linguagens
projeto avança; 2 - potencializar o uso de semelhantes às de programação (linguagens de
ferramentas de automatização das tarefas (tais descrição de hardware). As duas principais
como ferramentas de CAD), uma vez que cada ferramentas utilizadas nessa etapa são a simulação e
etapa é conhecida e pode ser dividida em pequenas a verificação formal [21]. Se um erro ou
tarefas automatizáveis; 3 - facilitar a comunicação inconformidade com os requisitos é detectado, o
entre as equipes de desenvolvimento, já que o processo se modelagem deve ser retomado para
estabelecimento da metodologia também auxilia a corrigi-lo, repetindo o ciclo, tantas vezes quantas
repartição de responsabilidades, permitindo que forem necessárias até que o modelo seja validado.
cada equipe tome ciência das atribuições das
demais e da maneira como estão vinculadas no Se um modelo foi validado ele pode ser sintetizado.
projeto. Por síntese entende-se, de forma abrangente, o
processo de se transformar uma especificação mais
Seja qual for a metodologia adotada, ela deve ser abstrata em uma menos abstrata, ou seja, o
capaz de realizar três ações comuns a todo projeto processo de se aumentar o nível de detalhamento de
[21]: especificação/modelagem, validação e síntese. uma especificação. Este conceito é frequentemente
confundido com o conceito de compilação,
O processo de especificação e modelagem de um entretanto, é conveniente estabelecer uma diferença
sistema, sub-sistema ou componente, pode ser entre eles. A compilação tem como entrada um
resumido como o processo que inicia com a software e como saída um software em um nível de
descrição de uma especificação e termina com a abstração mais baixo. A síntese, por outro lado, é
descrição de um modelo. Segundo Edwards [21], mais abrangente. Ela pode ter como entrada um
software e como saída uma descrição de hardware, fisicamente implementado com componentes de
ou mesmo uma descrição de hardware e como saída silício.
uma descrição de hardware em um nível de
abstração mais baixo. Neste exemplo o projeto foi divido em 4 níveis de
abstração: sistema, processador, lógica e circuito.
Neste ponto, é interessante introduzir outro No nível do sistema o projeto é descrito em termos
importante conceito, o de níveis de abstração. Para de componentes tais como processadores,
isso, é oportuno apresentar o diagrama em Y barramentos e memórias. No nível do processador
proposto por Daniel Gajski [23], bastante popular os componentes do nível de sistema são detalhados
entre projetistas de sistemas embarcados. Segundo em componentes da macro-arquitetura como
Gajski, toda a informação sobre um sistema pode processadores específicos, controladores de
ser representada por meio de um diagrama em Y, memória, árbitros de barramento, etc. No nível da
conforme esboçado na Fig. 1. lógica os componentes da macroarquitetura são
detalhados em componentes como portas lógicas,
Sistema flip-flops e registradores, enquanto no nível de
ss
Comportamental Proce ador Estrutural circuito eles passam a ser descritos em termos de
Lógica pequenas células formadas por transistores
rcuito interconectados (pMOS e nMOS no caso da
Ci
tecnologia CMOS).
Naturalmente, o número de níveis de abstração de
um projeto não é rígido, podendo variar de acordo
Caminho
do projeto com o tipo de projeto e a metodologia empregada.
(design path) Entretanto, na maior parte das vezes, os níveis de
abstração são definidos pelas ferramentas de
Física
projeto adotadas, que por sua vez seguem um certa
Fig. 1: Diagrama em Y de Gajski padronização, o que acaba por criar conjuntos bem
definidos de níveis de abstração para as
Neste diagrama, toda a informação a respeito do metodologias mais populares.
sistema é repartida em três dimensões:
comportamental, estrutural e física. Na dimensão É importante observar que uma vez que a diferença
comportamental cada componente é visto como de detalhamento entre os modelos de níveis
uma caixa preta com saídas descritas em termos das consecutivos de abstração é gradual, a passagem de
entradas aplicadas em função do tempo. Nela não um nível para outro pode ser feita muitas vezes de
há qualquer informação de como ela é construída, maneira automática ou semi-automática através de
ou seja, ela descreve o que é o componente, mas ferramentas apropriadas. Da mesma forma,
não como ele é. Na dimensão estrutural a caixa ferramentas de verificação podem ser utilizadas
preta é representada como um conjunto de para analisar se os modelos de um mesmo sistema,
componentes e conexões. Na dimensão física ou sub-sistema, são coerentes entre si em diferentes
informações de geometria são adicionadas, tais níveis de abstração, a fim de detectar possíveis
como altura, largura, peso, posição dos erros de implementação.
componentes, comprimento e forma das conexões,
etc. De maneira geral, o produto final do projeto situa-
se na camada mais interna do eixo de descrição
Cada um dos círculos concêntricos (ou camadas) do física. A maneira como o diagrama “é percorrido”
diagrama descreve o sistema alvo com diferentes até chegar a esse ponto é definida pela metodologia
níveis de detalhamento. Percorrendo-o de fora para de projeto adotada. No exemplo esboçado na Fig. 1,
dentro, parte-se do menor ao maior nível de a metodologia parte da descrição comportamental
detalhamento, o que implica numa elevação da em nível de sistema, refinando-a para uma
complexidade. Quanto menor o nível de descrição comportamental em nível de processador,
detalhamento na descrição do sistema, menor é a depois para uma descrição estrutural no mesmo
complexidade e maior é o nível de abstração dessa nível, passando para uma descrição estrutural em
descrição, ou seja, a descrição do sistema vai do nível de lógica, em seguida para uma descrição
nível mais abstrato (e menos complexo) ao menos física, até finalmente sintetizar o projeto em uma
abstrato (e mais complexo) nas camadas mais descrição física em nível de circuitos.
internas. Ao mesmo tempo, quanto mais se desce
nas camadas do diagrama, mais a descrição do Diversas metodologias de projeto de sistemas
projeto se assemelha ao seu nível final: o produto embarcados têm sido propostas ao longo dos
últimos anos. De maneira geral, podemos enquadra-
las em três principais categorias, conforme a Infelizmente, estimativas não são perfeitas, o
sequência em que dão evolução ao projeto. São que acaba por não eliminar o risco de
elas: reiterações no projeto.

• Bottom-up - o projeto inicia a partir da • Meet-in-the-middle – é uma combinação das

descrição detalhada dos componentes metodologias bottom-up e top-down, visando
elementares do sistema. Esses componentes aproveitar as vantagens de cada uma delas e
são então conectados para formar ao mesmo tempo evitar suas inconveniências.
subsistemas, que por sua vez são conectados Em geral, essa metodologia emprega a
para formarem subsistemas maiores e assim, abordagem top-down nos níveis de abstração
sucessivamente até compor o sistema mais altos e a bottom-up nos níveis mais
completo. Numa metodologia botton-up baixos [24]. Nela o projeto inicia com uma
típica, os projetistas desenvolvem uma série descrição em alto nível de abstração que é
de componentes e os armazenam em uma refinada sucessivamente para níveis cada vez
biblioteca para serem utilizadas no próximo mais baixos até atingir um nível intermediário
nível de abstração. A vantagem desta quando então é descrito em termos de
metodologia é de separar claramente cada componentes de uma biblioteca. Cada um dos
nível de abstração em sua própria biblioteca. componentes dessa biblioteca, por sua vez,
Isto permite a repartição de todo o projeto em tem as descrições dos níveis de abstração
pequenas partes a cada nível de abstração e inferiores feitas através de alguma
facilitando o gerenciamento do projeto, já que metodologia botton-up. Um exemplo típico
cada grupo fornece uma biblioteca de desta metodologia é a Metodologia de Projeto
componentes para o próximo nível de Baseada em Plataforma, proposta por
abstração. Por outro lado, a desvantagem Sangiovanni-Vincentelli [25].
dessa metodologia é que as bibliotecas devem
conter todos os possíveis componentes com Atualmente, a maior parte dos projetistas utilizam
todos os possíveis parâmetros, devendo ser algum tipo de metodologia meet-in-the-middle [24].
otimizados para os requisitos do nível de P:or essa razão, estes últimos parágrafos serão
abstração seguinte, algo difícil de se prever dedicados a expor um pouco mais sobre ela.
nos baixos níveis de abstração. Um fluxo de projeto bastante popular, compatível
• Top-down - o projeto inicia com uma com metodologias meet-in-the-middle, é
formulação geral das características finais do apresentado por Arnold Berger [5], conforme
sistema desejado, feita de maneira abstrata, ou exposto na Fig. 2.
seja, sem detalhes de como será
Fase 2 – Particionamento HW/SW
Fase 1 – Especificação do Produto

implementado. À medida que o projeto

Particionamento
Refinamento do

avança, o sistema vai sendo refinado, dividido

do HW e SW

Fase 6 – Aceitação e Testes

Fase 5 – Integração
Fase 3 – Iteração e

em subsistemas, os subsistemas em sub- e Atualização

Fase 7 – Manutenção

Fase 4 – Projeto
subsistemas, e assim por diante, até que seja Detalhado
descrito em termos de componentes do HW e SW

elementares. Além de ser bastante intuitiva, Projeto do HW

esta metodologia tem a grande vantagem de
permitir um bom grau de automatização, o
que permite reduzir o tempo de projeto e Lançamento do
Projeto do SW
minimizar a introdução de falhas humanas. Produto

Por outro lado, tem a desvantagem de não Fig. 2: Fluxo de projeto de sistemas embarcados
permitir conhecer com precisão as reais
métricas do sistema até que o último passo Neste fluxo, o ciclo de vida do projeto de sistemas
tenha sido completado. Quando elas não embarcados é divido em 7 fases:
atendem aos requisitos, o projeto precisa
1. Especificação do produto;
recuar e ser refeito repetidas vezes até que
eles sejam alcançados. Para minimizar esse 2. Particionamento do projeto em
inconveniente, são empregados os chamados componentes de hardware e software;
estimadores, ferramentas capazes de estimar
3. Iteração e refinamento do particionamento;
características de um nível mais baixo de
descrição, tais como consumo, desempenho, 4. Tarefas independentes de projeto do
área de silício ocupada, latência, vazão, etc., a hardware e do software;
partir de descrições em mais alto nível.
 5. Integração dos componentes de hardware e CPU.
software;
Durante a fase de iteração e refinamento do
6. Testes, aceitação e lançamento do produto; particionamento, o particionamento definido na
7. Manutenção e atualização contínua. fase anterior é posto à prova por meio de
ferramentas de alto nível. Projetistas de hardware
Na fase de especificação o sistema é inicialmente poderão se valer de ferramentas de simulação
descrito de maneira informal através de uma série arquitetural, por exemplo, enquanto projetistas de
de especificações. Durante a especificação deve-se software poderão rodar ferramentas de benchmark
destacar de forma clara quais são os requisitos do em placas de avaliação do processador ou
projeto que se deseja realizar. Os requisitos são as microcontrolador escolhido. Em função dos
guias-mestre do projeto e estabelecem critérios resultados obtidos nesta fase, o particionamento
importantes à tomada de decisões durante as etapas pode ser revisto, repetindo-se o processo até que as
futuras. Pontos de otimização subjetiva, se simulações forneçam resultados satisfatórios,
existirem, devem ser colocados de forma indicando que o projeto atenderá aos requisitos
hierárquica, ou seja, devem ser estabelecidos em estabelecidos.
ordem decrescente de relevância, já que muitas
vezes sua implementação é conflitante, fazendo Uma vez concluída a fase de iteração e refinamento
com que a otimização de um deprecie as do particionamento, tem início a fase seguinte, na
características de outro. Um exemplo tipico é o qual os componentes de hardware e software
projeto de um smartphone, no qual o desempenho devem ser implementados de fato. Cada um deles
de processamento e o consumo da bateria são duas modelado separadamente. Durante essa fase,
características que comumente se deseja otimizar. O ferramentas e técnicas de verificação são
problema é que, geralmente, o aumento do empregadas tanto nos componentes de HW quanto
desempenho implica no aumento do consumo. Se, nos de SW e os erros encontrados, corrigidos. Após
ao final da fase 5, as duas características atenderem essa fase os componentes de HW e SW são
aos requisitos (com algum grau de liberdade), os reunidos e integrados (fase 5) de forma a compor o
projetistas deverão saber qual delas deverá ser sistema embarcado completo. Idealmente, ao se
priorizada na otimização. Ao final da fase de reunir os componentes tudo deveria funcionar
especificação, as especificações, inicialmente perfeitamente, mas a realidade costuma ser
informais, devem ter sido formalizadas diferente e erros aparecem. Por se tratarem de
(frequentemente através de alguma linguagem de sistemas complexos, a tarefa de se localizar e
alto nível, como UML, por exemplo), de tal sorte corrigir as fontes dos problemas não costuma ser
que um diagrama de blocos do sistema embarcado algo evidente. Além disso, alguns problemas podem
completo possa ser visualizado, e cada bloco ter seu mecanismo de ativação bastante complexo,
contenha especificações funcionais e dependendo, por exemplo, de uma sequência
comportamentais. específica de pressionamento de teclas quando o
sistema se encontra em um dado estado interno e a
Na fase de particionamento HW/SW, os projetistas temperatura ultrapassa um valor limite. Neste
deverão decidir quais partes do sistema serão ponto, ferramentas de co-simulação e verificação,
implementadas em hardware e quais serão em conjunto com instrumentos como osciloscópios
implementadas em software. Essas partes podem e analisadores lógicos costumam ser necessários.
tanto ser blocos definidos na fase de especificação,
como também frações deles (sub-blocos). Após a integração do sistema e depuração dos erros
Dependendo da metodologia utilizada, esse encontrados, vem a fase de testes e lançamento do
particionamento pode ser guiado em função dos produto. Nesta fase o sistema é testado
componente de HW e SW pré-existentes nas exaustivamente em condições idênticas às que ele
bibliotecas de projeto em uso. Deve-se notar no será submetido após o lançamento do produto.
entanto que essa decisão deve atender Durante esses testes, o sistema deverá responder e
prioritariamente os requisitos estabelecidos na fase comportar-se conforme os requisitos estabelecidos
de especificação. A decisão de implementar um no início do projeto.
dado bloco em hardware implica, na maioria das
vezes, num aumento da complexidade, tempo e Finalmente, após o lançamento do produto no
custos do projeto, mas permite um ganho de mercado, vem a fase de manutenção e atualização.
desempenho bem maior que sua implementação em Manter e atualizar o produto concebido costuma ser
software. Os aficionados por jogos de PC sabem bem mais lucrativo do que refazer todo um projeto
bem a diferença entre ter uma placa dedicada à novamente. Faz parte dessa fase também a busca
aceleração gráfica e emular OpenGL na própria por otimizar as características do produto lançado,
bem como o enriquecimento da documentação Springer, Novembro de 2004.
externa (para o público) e interna (para os atuais e [11] Jensen, E.D., Locke, C.D., Tokuda, H., “A
futuros projetistas) a respeito dele. Time-Driven Scheduling Model For Real-
Time Operating Systems”, IEEE Real-Time
4 Conclusão Systems Symposium, pp 112-122, 1985.
Foram apresentados alguns conceitos básicos sobre [12] Kopetz, Hermann., “Real-Time Systems –
sistemas computacionais embarcados, e as linhas Design Principles for Distributed Embedded
gerais das metodologias de projeto mais aplicadas, Applications”, 1ª ed., Kluwer Academic
bem como uma exposição sucinta de alguns dos Publishers, Boston, MA, USA, 1997.
formalismos importantes. Embora pontos relevantes [13] OSEK/VDX Steering Committe,
tenham sido citados, uma quantidade imensa de “OSEK/VDX Operating System”, Ver. 2.0,
informação foi omitida pela brevidade deste rev. 1, outubro de 1997.
documento. Por essa razão, literaturas que [14] Bowen, J.P, Stavridou, V., “Safety-Critical
considero imprescindíveis foram citadas ao longo Systems, Formal Methods and Standards”,
do texto, a fim de permitir aos seus leitores Software Engineering Journal, vol. 8, no. 4,
aprofundar seus conhecimentos a respeito do tema. pp: 189-209, Julho de 1993.
[15] Butler, R.W., Finelli, G.B., “The Infeasibility
5 Referências of Quantifying the Reliability of Life-Critical
Real-Time Software”, IEEE Transactions on
[1] Klaus Finkenzeller, “RFID Handbook:
Software Engineering, vol. 19, no. 1, pp. 3-12,
Fundamentals and Applications in
1993.
Contactless Smart Cards and Identification”,
[16] Fumihide Kitamura et al., “Watch Dog
2ª ed., Wiley, 2003.
timer”, United States Patent, Patent number:
[2] Morales, M., Rau, S., Palma, M.J.,
4752930, 21 de Junho de 1988.
Venkatesan, M., Pulskamp, F., Dugar, A.,
[17] Marwedel, P., “Embedded System Design -
“Worldwide Intelligent Systems 2011–2015
Embedded Systems Foundations of Cyber-
Forecast: The Next Big Opportunity”,
Physical Systems”, 2ª ed., Springer, 2011.
International Data Corporation - IDC,
[18] Ellis, C.S., “The Case for Higher-Level
Setembro de 2011.
Power Management”, 7th IEEE Workshop on
[3] “IEEE Standard Glossary of Software
Hot Topics in Operating Systems (HotOS-
Engineering Terminology”, Version 610.12-
VIII), pp. 162–167, Rio Rico, AZ, Março de
1990, Standards Coordinating Committee of
1999.
the IEEE Computer Society, pp. 30, USA,
[19] H. W. Stone, “Mars Pathfinder Microrover:
1990.
A Low-Cost, Low-Power Spacecraft”, 1996
[4] Heath, Steve, “Embedded System Design”, 2ª
AIAA Forum on Advanced Developments in
ed., Elsevier, 2003.
Space Robotics, Madison WI, 1996.
[5] Berger, A.S., “Embedded Systems Design –
[20] Wolf, W., “Computers as Components -
An Introduction to Process, Tools, &
Principles of Embedded Computing System
Techniques”, CMP Books, USA, 2002.
Design”, Morgan Kaufmann Publishers, San
[6] Levy, Marcus, “EDN
Francisco, 2ª ed., Junho de 2008.
Microprocessor/Microcontroller Directory”,
[21] Edwards, S., Lavagno, L., Lee, E.A.,
EDN, 14 de setembro de 2000.
Sangiovanni-Vincentelli, A., “Design of
[7] Microchip Technology Inc.,
Embedded Systems: Formal Models,
www.microchip.com, outubro de 2011.
Validation and Synthesis”, IEEE, vol. 85, No
[8] Swamy, G., Sarma S., “Manufacturing Cost
3, pp. 366–390, Março de 1997.
Simulations for Low Cost RFID Systems”,
[22] IEEE, “IEEE Std 1012-2004 - IEEE
Auto-ID Center, MIT, USA, fevereiro de
Standard for Software Verification and
2003.
Validation”, Revisão do padrão IEEE Std
[9] Jung, C. R.; Osório, F. S.; Kelber, C.; Heinen,
1012-1998, 2004.
F., “Computação Embarcada: Projeto e
[23] Gajski D., Kuhn, R., “New VLSI Tools”,
Implementação de Veículos Autônomos
Computer Magazine, pp 11–14, Dezembro de
Inteligentes”, Anais do CSBC’05 XXIV
1983.
Jornada de Atualização em Informática (JAI),
[24] Gajski, D.D., Abdi, S., Gerstlauer, A.,
v. 1, p. 1358–1406, São Leopoldo, RS: SBC,
Schirner, G., “Embedded System Design -
julho de 2005.
Modeling, Synthesis and Verification”,
[10] Stankovic, J.A., Rajkumar, R., “Real-Time
Springer, 2009.
Operating Systems”, Real-Time Systems
[25] Sangiovanni-Vincentelli, A., Martin, G.,
Journal, Vol. 28, Issue 2, pp. 237-253,
 “Platform-based Design and Software
Design Methodology for Embedded
Systems”, IEEE Design and Test for
Computer, vol. 18, n. 6, p. 23-33, 2001.

View publication stats