See

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

Projeto de Sistemas Embarcados

ARTICLE

READS

14

1 AUTHOR:

Marcos Zurita
Universidade Federal do Piau
3 PUBLICATIONS 18 CITATIONS

SEE PROFILE

All in-text references underlined in blue are linked to publications on ResearchGate, Available from: Marcos Zurita
letting you access and read them immediately. Retrieved on: 02 February 2016
 Projeto de Sistemas Embarcados
Marcos E. P. V. Zurita
Universidade Federal do Piau, Curso de Engenharia Eltrica
Campus Universitrio Ministro Petrnio Portela - 64049-550 - Teresina PI
zurita@ufpi.edu.br, www.ufpi.edu.br/zurita
Resumo
A vasta gama de aplicaes nas quais os sistemas
embarcados esto presentes atualmente requer
diferentes tcnicas e abordagens para sua
elaborao. O conhecimento prvio dessas
metodologias e sua correta adoo de
fundamental importncia para o sucesso do projeto
em condies limitadas de tempo e recursos. Nesse
sentido, so abordados neste documento alguns
conhecimentos introdutrios fundamentais a
respeito de sistemas embarcados e seu projeto, no
intuito de guiar os passos iniciais para o
aprofundamento no tema.
1 Introduo
A popularizao dos microprocessadores, iniciada
em meados da dcada de 80, aliada contnua
reduo dos custos da tecnologia, deu incio a uma
verdadeira revoluo na vida cotidiana. Os
processadores, antes quase totalmente restritos a
computadores corporativos e algumas grandes
mquinas, hoje podem ser encontrados
praticamente por toda a parte. Automveis,
televisores, brinquedos, mquinas de lavar,
telefones, aparelhos de som, relgios de pulso,
cartes de banco e at mesmo etiquetas de
identificao descartveis [1] so hoje objetos
permeados por microprocessadores. A adoo de
microprocessadores fora do universo dos
computadores pessoais e corporativos, deu origem
aos chamados Sistemas Computacionais
Embarcados, ou simplesmente Sistemas
Embarcados.
Segundo uma recente pesquisa realizada pela IDC
[2], cerca de 19% de todos os sistemas eletrnicos
vendidos hoje no mundo so sistemas embarcados,
e este nmero dever crescer para 33% at 2015.
Eles so atualmente responsveis por uma receita
anual de 1 trilho de dlares, o que deve dobrar nos
prximos 4 anos, quando ento sero responsveis
pelo consumo de cerca de 14,5 bilhes de
processadores por ano, mais de 2 para cada
habitante no mundo.
O rpido crescimento desse setor implica numa
demanda igualmente crescente de recursos
humanos adequados para poder suplanta-lo. Em
outras palavras, h uma imensa oportunidade para
projetistas e desenvolvedores na rea de projetos de
sistemas embarcados. Por outro lado, a
complexidade cada vez maior das novas aplicaes
e o aumento da dinmica do mercado consumidor
tem exigido a melhoria das tcnicas e metodologias
empregadas em seu projeto de forma e executa-lo
no menor espao de tempo possvel. Isto significa
que os profissionais que pretendem atuar nessa rea
precisam estar familiarizados com essas
metodologias e tcnicas de projeto, bem como as
particularidades desse tipo de sistema.
Neste artigo so apresentados alguns conceitos
bsicos a respeito de sistemas embarcados e uma
breve introduo respeito do seu projeto.
2 Sistemas Embarcados
Um Sistema Embarcado (SE), definido pela IEEE
[3] como um sistema computacional que faz parte
de um sistema maior e implementa alguns dos
requerimentos deste sistema. Esta definio,
estabelecida h mais de duas dcadas continua
vlida, embora a revoluo experimentada por esse
segmento durante estes ltimos anos tenha
impulsionado alguns autores a complementarem-na.
Nesta linha, Steve Heath o define como sendo um
sistema baseado em um microprocessador, que
projetado para controlar uma funo ou uma gama
de funes, e no para ser programado pelo
usurio final como ocorre com os PCs [4].
Por se tratarem de sistemas computacionais, Arnold
Berger [5] prefere descreve-los enumerando as
caractersticas que os distinguem dos computadores
pessoais. So elas:
1. So dedicados a tarefas especficas enquanto
PCs so plataformas genricas de
computao Esta caracterstica tem
impacto principalmente no poder
computacional da mquina. PCs devem
poder rodar um grande nmero de
aplicativos, com diferentes exigncias de
processamento, mantendo um bom
desempenho, enquanto SEs precisam realizar
apenas uma ou poucas tarefas bem
especficas;
2. So suportados por uma vasta gama de
processadores e arquiteturas de
processadores Atualmente, mais de 40
empresas de semicondutores disputam o
mercado de microprocessadores e
 microcontroladores [6]. Cada uma delas por
sua vez oferece vrias solues distintas.
Apenas a Microchip [7], uma das lderes
deste segmento, tem hoje uma lista de mais
de 500 diferentes microcontroladores.
Naturalmente, um grande leque de opes
aumenta o grau de liberdade de escolha dos
projetistas mas tambm requer deles
conhecimento adequado para encontrar as
solues mais apropriadas a cada projeto;
3. So geralmente sensveis aos custos a
maior parte dos sistemas embarcados
possuem bem menos componentes e custam
bem menos do que um PC. Evidentemente o
impacto nos custos da adio de meia dzia
de componentes bem mais significativo
num sistema que possui uma dzia deles do
que num que possui mais de uma centena.
Em alguns sistemas de identificao sem
contato (RFId), um simples capacitor pode
representar at 20% dos custos totais [8].
4. Possuem requisitos de tempo-real neste
aspecto, SEs geralmente podem ser divididos
em dois grupos: os que possuem requisitos
de tempo sensvel e os que possuem
requisitos de tempo crtico. As tarefas de
tempo crtico so intolerantes a atrasos,
devem ser realizadas dentro de um intervalo
preciso de tempo ou a tarefa falha. O sistema
de acionamento dos airbags de um carro so
um bom exemplo disso. Nele, alguns
milissegundos podem fazer a diferena entre
salvar ou no a vida do motorista [9]. Tarefas
de tempo sensvel, por outro lado, so mais
tolerantes. Se a tarefa responsvel pelo
fechamento da vlvula de gua de uma
mquina de lavar atrasar um ou dois
segundos, a roupa ser lavada com um pouco
mais de gua alm do necessrio, perdendo
um pouco da eficincia almejada;
5. Quando utilizam um sistema operacional,
este quase sempre um RTOS A principal
diferena entre um Sistema Operacional de
Tempo Real (RTOS Real Time Operating
System) e um sistema operacional
convencional que num RTOS a importncia
para o sistema da finalizao de uma tarefa
um valor que varia com o tempo [10][11].
Este valor geralmente descrito em termos
de deadlines para finalizao de cada tarefa.
Uma vez que o tempo de resposta visto
como parte crucial da exatido do software
(SW), ele deve poder ser comprovado sem
argumentos estatsticos [12]. Assim como os
microcontroladores, os RTOSs existem em
grande variedade. A indstria automotiva,
por exemplo, possu um padro chamado
OSEK, no qual esto definidas uma srie de
especificaes a serem seguidas pelos seus
RTOSs [13].
6. Neles, as implicaes de uma falha de
software so muito mais severas do que num
desktop muitos SEs interagem com o
ambiente ou seres humanos, como o caso
de sistemas de vida-crticos (life-critical
systems) [14][15], por exemplo. Falhas
podem ter consequncias no ambiente, no
prprio sistema ou at mesmo nas pessoas
em torno dele. Um bug no software do
sistema de injeo eletrnica de um
automvel, por exemplo, pode reduzir a vida
til de componentes do motor e aumentar o
consumo e a emisso de gases poluentes. Um
bug no software de controle da dosagem de
radiao de uma mquina de raios-X poderia
ter consequncias srias na sade do
paciente. Por essa razo, muitos SEs
possuem mecanismos de segurana para
detectar e contornar falhas, tal como o
watchdog timer [16]. Neste aspecto, Peter
Marwedel [17] estabelece 5 parmetros de
caraterizao de SEs:
Confiabilidade: a probabilidade do
sistema de no falhar;
Manutenibilidade: a probabilidade
que uma falha no sistema possa ser
corrigida em um certo intervalo de
tempo;
Disponibilidade: a probabilidade do
sistema estar disponvel. Ser tanto
maior quanto maior for sua
confiabilidade e manutenibilidade;
Segurana: descreve a probabilidade
do sistema de no causar algum tipo de
dano;
Confidencialidade: descreve quo
capaz o sistema de manter dados
confidenciais e de garantir uma
comunicao autenticada;
7. Costumam ter restries no consumo de
energia Ao contrario dos PCs, grande parte
dos sistemas embarcados so alimentados
unicamente por pequenas baterias. Neles, a
reduo de alguns miliwatts/hora no
consumo pode estender a durao das
baterias por dias ou meses. Frequentemente,
a responsabilidade de poupar energia
atribuda unicamente aos engenheiros do
 hardware (HW), mas em SEs essa
responsabilidade deve ser compartilhada
tambm pelos desenvolvedores do software.
Em um PDA, por exemplo, o consumo pode
ser reduzido em at 60% atravs de
alteraes na forma como o software
escrito [18]. Evidentemente, as escolhas
feitas no projeto do hardware tem impacto
crucial no consumo do sistema. Em muitos
SEs o principal vilo do consumo o
processador, mas esse nem sempre o caso.
A Pathfinder, sonda espacial enviada para
Marte, por exemplo, teve o consumo como
uma das principais restries de projeto.
Todos os mdulos da sonda foram projetados
para poderem ser ligados e desligados
individualmente e a sonda inteira permanecia
em sleep mode durante a noite, quando as
clulas fotovoltaicas deixavam de captar
energia e a eficincia da bateria caa devido
queda de temperatura. Mesmo quando em
modo operacional, o software no podia
manter ligado mais de um mdulo ao mesmo
tempo devido escassez de energia
disponvel [19];
8. Devem poder operar em condies
ambientais extremas A natureza porttil de
muitos sistemas embarcados implica que eles
devem ser capazes de suportar as mesmas
condies que seus usurios ou sistemas
receptores. Um PDA deve poder funcionar
40C na praia de Copacabana, a -15C nos
Alpes ou a 11.000 metros de altitude na
cabine de um avio. Da mesma forma, o
sistema de frenagem ABS deve funcionar no
calor de 45C de Teresina, no frio de -5C de
Porto Alegre, em dias secos e dias chuvosos,
e em todas essas mesmas condies aps
5.000 km de estrada de terra trepidante. Os
requisitos ambientais de operao geralmente
tm consequncias diretas no hardware e as
vezes at mesmo no software. Um
processador que precise ser selado em
borracha de silicone para poder suportar
elevados ndices de umidade, ter sua
capacidade de dissipao trmica
comprometida e precisar ter seu clock
reduzido, afetando o desempenho do
software;
9. Seus recursos de sistema so extremamente
menores do que os de um desktop
Processadores com mltiplos ncleos
rodando frequncias superiores a 2 GHz,
discos rgidos com capacidade da ordem de
tera-bytes, barramentos de alto desempenho,
portas de comunicao de alta vazo,
memrias RAM de alta capacidade,
processadores grficos e monitores de alta
resoluo, so recursos comuns dos desktops
atuais. A capacidade de armazenamento da
memria RAM desses computadores
pessoais maior do que todo o disco rgido
de um tpico PC do final da dcada de 90.
Com isso, a maior parte dos aplicativos
podem ser escritos assumindo a memria
como um recurso infinito. Para um sistema
embarcado a realidade bem diferente. Na
maior parte deles a RAM no chega a
quinhentos bytes, todo o SW deve caber em
alguns poucos kB e rodar em um processador
cujo clock mal chega a 20 MHz. A
quantidade de teclas bastante limitada
fazendo com que precisem acumular funes.
Muitos no tem sequer um display e a
interface com o usurio se d atravs de
LEDs e sons. Evidentemente, o cdigo
escrito para essas aplicaes precisa observar
uma srie de cuidados que os voltados para
PCs no precisam. Uma simples operao
matemtica, pode consumir 1% ou 70% da
memria em um dado microcontrolador,
dependendo apenas da forma como escrita;
10. Geralmente todo seu programa fica
armazenado em uma ROM Esta
caracterstica pode parecer insignificante mas
no . Ter seu cdigo armazenado em uma
ROM impe severas limitaes ao sistema. A
primeira, discutida anteriormente, diz
respeito ao tamanho do cdigo. A outra est
ligada aos mtodos usados para projeta-lo.
Um cdigo armazenado numa ROM no
pode ser depurado da mesma maneira como
ocorre nos PCs. Para inserir um breakpoint, o
depurador precisa remover uma instruo do
programa e substitui-la por outra responsvel
por desviar a execuo para algum ponto do
depurador, tarefa impossvel numa memria
que no pode ser alterada aleatoriamente;
11. Requerem ferramentas e mtodos
especializados para serem eficientemente
projetados O fato dos sistemas embarcados
serem compostos por hardware e software
integrados exige mudanas na sua forma de
concepo, teste e depurao, em relao a
um projeto de hardware e um projeto de
software feitos isoladamente. Depurar um
sistema de processamento de vdeo no qual
parte dos blocos so implementados em
software e outra parte em hardware no
uma tarefa nada trivial e necessita bem mais
do que um simples aplicativo de depurao.
Muitas vezes, necessrio projetar uma
 plataforma que emule o sistema no qual o SE
ser integrado, paralelamente ao projeto
deste, para ser usado nas etapas de teste e
depurao. Depurar um sistema de controle
de altitude usando o prprio avio no
muito prtico, tampouco uma boa ideia;
12. Microprocessadores embarcados geralmente
possuem circuitos dedicados para depurao
Conforme explicado anteriormente, a
depurao do cdigo programado em uma
ROM encontra srias dificuldades. Por essa
razo, microprocessadores voltados para
aplicaes embarcadas costumam incluir
circuitos especialmente dedicados
depurao. Alguns fabricantes oferecem duas
verses dos seus microprocessadores, uma
de desenvolvimento, contendo os recursos
de depurao, necessrios ao projeto, e uma
verso de produo, sem tais recursos, a
fim de poupar rea de silcio e reduzir os
custos do componente.
Uma vez expostas, em linhas gerais, as
caractersticas tpicas de um sistema embarcado,
torna-se evidente a necessidade do estudo e
domnio de metodologias de projeto que permitam
implementa-lo de forma eficiente no menor tempo
possvel.
3 Projeto de Sistemas Embarcados
O projeto de sistemas embarcados deve seguir uma
metodologia precisa. Segundo Waine Wolf [20],
trs razes principais justificam a importncia de se
seguir uma metodologia de projeto: 1 - permitir que
o cumprimento dos requisitos de projeto possam ser
assegurados de maneira formal medida que o
projeto avana; 2 - potencializar o uso de
ferramentas de automatizao das tarefas (tais
como ferramentas de CAD), uma vez que cada
etapa conhecida e pode ser dividida em pequenas
tarefas automatizveis; 3 - facilitar a comunicao
entre as equipes de desenvolvimento, j que o
estabelecimento da metodologia tambm auxilia a
repartio de responsabilidades, permitindo que
cada equipe tome cincia das atribuies das
demais e da maneira como esto vinculadas no
projeto.
Seja qual for a metodologia adotada, ela deve ser
capaz de realizar trs aes comuns a todo projeto
[21]: especificao/modelagem, validao e sntese.
O processo de especificao e modelagem de um
sistema, sub-sistema ou componente, pode ser
resumido como o processo que inicia com a
descrio de uma especificao e termina com a
descrio de um modelo. Segundo Edwards [21],
um modelo formal deve conter:
Uma especificao funcional, sob a forma
de um conjunto de relaes explcitas ou
implcitas que envolvem entradas, sadas, e
possveis estados internos;
Um conjunto de propriedades que o projeto
deve satisfazer, dadas na forma de um
conjunto de relaes entre entradas, sadas
e estados, que possam ser comparados com
a especificao funcional;
Um conjunto de ndices de desempenho
que avaliem a qualidade do projeto em
termos de custo, confiabilidade, velocidade,
tamanho, etc., dados como um conjunto de
equaes que envolvam, entre outras
coisas, entradas e sadas;
Um conjunto de restries sobre os ndices
de desempenho.
Dessa forma, o projeto durante o processo de
especificao e modelagem pode ser visto como a
sequncia de passos que implementam o modelo
especificado cumprindo as formalidades descritas
acima.
Uma vez estabelecido o modelo, ele deve ser
validado. Segundo o IEEE [22], a verificao e
validao de software tem como principal objetivo,
determinar durante o ciclo de vida do software, se
os requisitos do prprio software e do sistema esto
corretos, completos, precisos e consistentes,
assegurando assim a qualidade de um produto de
software. Este conceito pode ser estendido tambm
para componentes de hardware, at porque eles
tambm podem ser modelados em linguagens
semelhantes s de programao (linguagens de
descrio de hardware). As duas principais
ferramentas utilizadas nessa etapa so a simulao e
a verificao formal [21]. Se um erro ou
inconformidade com os requisitos detectado, o
processo se modelagem deve ser retomado para
corrigi-lo, repetindo o ciclo, tantas vezes quantas
forem necessrias at que o modelo seja validado.
Se um modelo foi validado ele pode ser sintetizado.
Por sntese entende-se, de forma abrangente, o
processo de se transformar uma especificao mais
abstrata em uma menos abstrata, ou seja, o
processo de se aumentar o nvel de detalhamento de
uma especificao. Este conceito frequentemente
confundido com o conceito de compilao,
entretanto, conveniente estabelecer uma diferena
entre eles. A compilao tem como entrada um
software e como sada um software em um nvel de
abstrao mais baixo. A sntese, por outro lado,
mais abrangente. Ela pode ter como entrada um
software e como sada uma descrio de hardware,
ou mesmo uma descrio de hardware e como sada
uma descrio de hardware em um nvel de
abstrao mais baixo.
Neste ponto, interessante introduzir outro
importante conceito, o de nveis de abstrao. Para
isso, oportuno apresentar o diagrama em Y
proposto por Daniel Gajski [23], bastante popular
entre projetistas de sistemas embarcados. Segundo
Gajski, toda a informao sobre um sistema pode
ser representada por meio de um diagrama em Y,
conforme esboado na Fig. 1.
Sistema
ss
Comportamental Proce ador Estrutural
Lgica
rcuito
Ci
Caminho
do projeto
(design path)
Fsica
Fig. 1: Diagrama em Y de Gajski
Neste diagrama, toda a informao a respeito do
sistema repartida em trs dimenses:
comportamental, estrutural e fsica. Na dimenso
comportamental cada componente visto como
uma caixa preta com sadas descritas em termos das
entradas aplicadas em funo do tempo. Nela no
h qualquer informao de como ela construda,
ou seja, ela descreve o que o componente, mas
no como ele . Na dimenso estrutural a caixa
preta representada como um conjunto de
componentes e conexes. Na dimenso fsica
informaes de geometria so adicionadas, tais
como altura, largura, peso, posio dos
componentes, comprimento e forma das conexes,
etc.
Cada um dos crculos concntricos (ou camadas) do
diagrama descreve o sistema alvo com diferentes
nveis de detalhamento. Percorrendo-o de fora para
dentro, parte-se do menor ao maior nvel de
detalhamento, o que implica numa elevao da
complexidade. Quanto menor o nvel de
detalhamento na descrio do sistema, menor a
complexidade e maior o nvel de abstrao dessa
descrio, ou seja, a descrio do sistema vai do
nvel mais abstrato (e menos complexo) ao menos
abstrato (e mais complexo) nas camadas mais
internas. Ao mesmo tempo, quanto mais se desce
nas camadas do diagrama, mais a descrio do
projeto se assemelha ao seu nvel final: o produto
fisicamente implementado com componentes de
silcio.
Neste exemplo o projeto foi divido em 4 nveis de
abstrao: sistema, processador, lgica e circuito.
No nvel do sistema o projeto descrito em termos
de componentes tais como processadores,
barramentos e memrias. No nvel do processador
os componentes do nvel de sistema so detalhados
em componentes da macro-arquitetura como
processadores especficos, controladores de
memria, rbitros de barramento, etc. No nvel da
lgica os componentes da macroarquitetura so
detalhados em componentes como portas lgicas,
flip-flops e registradores, enquanto no nvel de
circuito eles passam a ser descritos em termos de
pequenas clulas formadas por transistores
interconectados (pMOS e nMOS no caso da
tecnologia CMOS).
Naturalmente, o nmero de nveis de abstrao de
um projeto no rgido, podendo variar de acordo
com o tipo de projeto e a metodologia empregada.
Entretanto, na maior parte das vezes, os nveis de
abstrao so definidos pelas ferramentas de
projeto adotadas, que por sua vez seguem um certa
padronizao, o que acaba por criar conjuntos bem
definidos de nveis de abstrao para as
metodologias mais populares.
importante observar que uma vez que a diferena
de detalhamento entre os modelos de nveis
consecutivos de abstrao gradual, a passagem de
um nvel para outro pode ser feita muitas vezes de
maneira automtica ou semi-automtica atravs de
ferramentas apropriadas. Da mesma forma,
ferramentas de verificao podem ser utilizadas
para analisar se os modelos de um mesmo sistema,
ou sub-sistema, so coerentes entre si em diferentes
nveis de abstrao, a fim de detectar possveis
erros de implementao.
De maneira geral, o produto final do projeto situa-
se na camada mais interna do eixo de descrio
fsica. A maneira como o diagrama percorrido
at chegar a esse ponto definida pela metodologia
de projeto adotada. No exemplo esboado na Fig. 1,
a metodologia parte da descrio comportamental
em nvel de sistema, refinando-a para uma
descrio comportamental em nvel de processador,
depois para uma descrio estrutural no mesmo
nvel, passando para uma descrio estrutural em
nvel de lgica, em seguida para uma descrio
fsica, at finalmente sintetizar o projeto em uma
descrio fsica em nvel de circuitos.
Diversas metodologias de projeto de sistemas
embarcados tm sido propostas ao longo dos
ltimos anos. De maneira geral, podemos enquadra-
las em trs principais categorias, conforme a
sequncia em que do evoluo ao projeto. So
elas:
Bottom-up - o projeto inicia a partir da
descrio detalhada dos componentes
elementares do sistema. Esses componentes
so ento conectados para formar
subsistemas, que por sua vez so conectados
para formarem subsistemas maiores e assim,
sucessivamente at compor o sistema
completo. Numa metodologia botton-up
tpica, os projetistas desenvolvem uma srie
de componentes e os armazenam em uma
biblioteca para serem utilizadas no prximo
nvel de abstrao. A vantagem desta
metodologia de separar claramente cada
nvel de abstrao em sua prpria biblioteca.
Isto permite a repartio de todo o projeto em
pequenas partes a cada nvel de abstrao e
facilitando o gerenciamento do projeto, j que
cada grupo fornece uma biblioteca de
componentes para o prximo nvel de
abstrao. Por outro lado, a desvantagem
dessa metodologia que as bibliotecas devem
conter todos os possveis componentes com
todos os possveis parmetros, devendo ser
otimizados para os requisitos do nvel de
abstrao seguinte, algo difcil de se prever
nos baixos nveis de abstrao.
Top-down - o projeto inicia com uma
formulao geral das caractersticas finais do
sistema desejado, feita de maneira abstrata, ou
seja, sem detalhes de como ser
implementado. medida que o projeto
avana, o sistema vai sendo refinado, dividido
em subsistemas, os subsistemas em sub-
subsistemas, e assim por diante, at que seja
descrito em termos de componentes
elementares. Alm de ser bastante intuitiva,
esta metodologia tem a grande vantagem de
permitir um bom grau de automatizao, o
que permite reduzir o tempo de projeto e
minimizar a introduo de falhas humanas.
Por outro lado, tem a desvantagem de no
permitir conhecer com preciso as reais
mtricas do sistema at que o ltimo passo
tenha sido completado. Quando elas no
atendem aos requisitos, o projeto precisa
recuar e ser refeito repetidas vezes at que
eles sejam alcanados. Para minimizar esse
inconveniente, so empregados os chamados
estimadores, ferramentas capazes de estimar
caractersticas de um nvel mais baixo de
descrio, tais como consumo, desempenho,
rea de silcio ocupada, latncia, vazo, etc., a
partir de descries em mais alto nvel.
Infelizmente, estimativas no so perfeitas, o
que acaba por no eliminar o risco de
reiteraes no projeto.
Meet-in-the-middle uma combinao das
metodologias bottom-up e top-down, visando
aproveitar as vantagens de cada uma delas e
ao mesmo tempo evitar suas inconvenincias.
Em geral, essa metodologia emprega a
abordagem top-down nos nveis de abstrao
mais altos e a bottom-up nos nveis mais
baixos [24]. Nela o projeto inicia com uma
descrio em alto nvel de abstrao que
refinada sucessivamente para nveis cada vez
mais baixos at atingir um nvel intermedirio
quando ento descrito em termos de
componentes de uma biblioteca. Cada um dos
componentes dessa biblioteca, por sua vez,
tem as descries dos nveis de abstrao
inferiores feitas atravs de alguma
metodologia botton-up. Um exemplo tpico
desta metodologia a Metodologia de Projeto
Baseada em Plataforma, proposta por
Sangiovanni-Vincentelli [25].
Atualmente, a maior parte dos projetistas utilizam
algum tipo de metodologia meet-in-the-middle [24].
P:or essa razo, estes ltimos pargrafos sero
dedicados a expor um pouco mais sobre ela.
Um fluxo de projeto bastante popular, compatvel
com metodologias meet-in-the-middle,
apresentado por Arnold Berger [5], conforme
exposto na Fig. 2.
Fase 2 Particionamento HW/SW
Fase 1 Especificao do Produto
Particionamento
Refinamento do
do HW e SW
Fase 6 Aceitao e Testes
Fase 5 Integrao
Fase 3 Iterao e
e Atualizao
Fase 7 Manuteno
Fase 4 Projeto
Detalhado
do HW e SW
Projeto do HW
Lanamento do
Projeto do SW
Produto
Fig. 2: Fluxo de projeto de sistemas embarcados
Neste fluxo, o ciclo de vida do projeto de sistemas
embarcados divido em 7 fases:
1. Especificao do produto;
2. Particionamento do projeto em
componentes de hardware e software;
3. Iterao e refinamento do particionamento;
4. Tarefas independentes de projeto do
hardware e do software;
 5. Integrao dos componentes de hardware e
software;
6. Testes, aceitao e lanamento do produto;
7. Manuteno e atualizao contnua.
Na fase de especificao o sistema inicialmente
descrito de maneira informal atravs de uma srie
de especificaes. Durante a especificao deve-se
destacar de forma clara quais so os requisitos do
projeto que se deseja realizar. Os requisitos so as
guias-mestre do projeto e estabelecem critrios
importantes tomada de decises durante as etapas
futuras. Pontos de otimizao subjetiva, se
existirem, devem ser colocados de forma
hierrquica, ou seja, devem ser estabelecidos em
ordem decrescente de relevncia, j que muitas
vezes sua implementao conflitante, fazendo
com que a otimizao de um deprecie as
caractersticas de outro. Um exemplo tipico o
projeto de um smartphone, no qual o desempenho
de processamento e o consumo da bateria so duas
caractersticas que comumente se deseja otimizar. O
problema que, geralmente, o aumento do
desempenho implica no aumento do consumo. Se,
ao final da fase 5, as duas caractersticas atenderem
aos requisitos (com algum grau de liberdade), os
projetistas devero saber qual delas dever ser
priorizada na otimizao. Ao final da fase de
especificao, as especificaes, inicialmente
informais, devem ter sido formalizadas
(frequentemente atravs de alguma linguagem de
alto nvel, como UML, por exemplo), de tal sorte
que um diagrama de blocos do sistema embarcado
completo possa ser visualizado, e cada bloco
contenha especificaes funcionais e dependendo, por exemplo, de uma sequncia
comportamentais.
Na fase de particionamento HW/SW, os projetistas
devero decidir quais partes do sistema sero
implementadas em hardware e quais sero
implementadas em software. Essas partes podem
tanto ser blocos definidos na fase de especificao,
como tambm fraes deles (sub-blocos).
Dependendo da metodologia utilizada, esse
particionamento pode ser guiado em funo dos
componente de HW e SW pr-existentes nas
bibliotecas de projeto em uso. Deve-se notar no
entanto que essa deciso deve atender
prioritariamente os requisitos estabelecidos na fase
de especificao. A deciso de implementar um
dado bloco em hardware implica, na maioria das
vezes, num aumento da complexidade, tempo e
custos do projeto, mas permite um ganho de
desempenho bem maior que sua implementao em
software. Os aficionados por jogos de PC sabem
bem a diferena entre ter uma placa dedicada
acelerao grfica e emular OpenGL na prpria
CPU.
Durante a fase de iterao e refinamento do
particionamento, o particionamento definido na
fase anterior posto prova por meio de
ferramentas de alto nvel. Projetistas de hardware
podero se valer de ferramentas de simulao
arquitetural, por exemplo, enquanto projetistas de
software podero rodar ferramentas de benchmark
em placas de avaliao do processador ou
microcontrolador escolhido. Em funo dos
resultados obtidos nesta fase, o particionamento
pode ser revisto, repetindo-se o processo at que as
simulaes forneam resultados satisfatrios,
indicando que o projeto atender aos requisitos
estabelecidos.
Uma vez concluda a fase de iterao e refinamento
do particionamento, tem incio a fase seguinte, na
qual os componentes de hardware e software
devem ser implementados de fato. Cada um deles
modelado separadamente. Durante essa fase,
ferramentas e tcnicas de verificao so
empregadas tanto nos componentes de HW quanto
nos de SW e os erros encontrados, corrigidos. Aps
essa fase os componentes de HW e SW so
reunidos e integrados (fase 5) de forma a compor o
sistema embarcado completo. Idealmente, ao se
reunir os componentes tudo deveria funcionar
perfeitamente, mas a realidade costuma ser
diferente e erros aparecem. Por se tratarem de
sistemas complexos, a tarefa de se localizar e
corrigir as fontes dos problemas no costuma ser
algo evidente. Alm disso, alguns problemas podem
ter seu mecanismo de ativao bastante complexo,
especfica de pressionamento de teclas quando o
sistema se encontra em um dado estado interno e a
temperatura ultrapassa um valor limite. Neste
ponto, ferramentas de co-simulao e verificao,
em conjunto com instrumentos como osciloscpios
e analisadores lgicos costumam ser necessrios.
Aps a integrao do sistema e depurao dos erros
encontrados, vem a fase de testes e lanamento do
produto. Nesta fase o sistema testado
exaustivamente em condies idnticas s que ele
ser submetido aps o lanamento do produto.
Durante esses testes, o sistema dever responder e
comportar-se conforme os requisitos estabelecidos
no incio do projeto.
Finalmente, aps o lanamento do produto no
mercado, vem a fase de manuteno e atualizao.
Manter e atualizar o produto concebido costuma ser
bem mais lucrativo do que refazer todo um projeto
novamente. Faz parte dessa fase tambm a busca
por otimizar as caractersticas do produto lanado,
bem como o enriquecimento da documentao
externa (para o pblico) e interna (para os atuais e
futuros projetistas) a respeito dele.
4 Concluso
Foram apresentados alguns conceitos bsicos sobre
sistemas computacionais embarcados, e as linhas
gerais das metodologias de projeto mais aplicadas,
bem como uma exposio sucinta de alguns dos
formalismos importantes. Embora pontos relevantes
tenham sido citados, uma quantidade imensa de
informao foi omitida pela brevidade deste
documento. Por essa razo, literaturas que
considero imprescindveis foram citadas ao longo
do texto, a fim de permitir aos seus leitores
aprofundar seus conhecimentos a respeito do tema.
5 Referncias
[1] Klaus Finkenzeller, RFID Handbook:
Fundamentals and Applications
Contactless Smart Cards and Identification,
2 ed., Wiley, 2003.
[2] Morales, M., Rau, S., Palma, M.J.,
Venkatesan, M., Pulskamp, F., Dugar, A.,
Worldwide Intelligent Systems 20112015
Forecast: The Next Big Opportunity,
International Data Corporation - IDC,
Setembro de 2011.
[3] IEEE Standard Glossary of Software
Engineering Terminology, Version 610.12-
1990, Standards Coordinating Committee of
the IEEE Computer Society, pp. 30, USA,
1990.
[4] Heath, Steve, Embedded System Design, 2
ed., Elsevier, 2003.
[5] Berger, A.S., Embedded Systems Design
An Introduction to Process, Tools, &
Techniques, CMP Books, USA, 2002.
[6] Levy, Marcus, EDN
Microprocessor/Microcontroller Directory,
EDN, 14 de setembro de 2000.
[7] Microchip Technology Inc.,
www.microchip.com, outubro de 2011.
[8] Swamy, G., Sarma S., Manufacturing Cost
Simulations for Low Cost RFID Systems,
Auto-ID Center, MIT, USA, fevereiro de
2003.
[9] Jung, C. R.; Osrio, F. S.; Kelber, C.; Heinen,
F., Computao Embarcada: Projeto e
Implementao de Veculos Autnomos
Inteligentes, Anais do CSBC05 XXIV
Jornada de Atualizao em Informtica (JAI),
v. 1, p. 13581406, So Leopoldo, RS: SBC,
julho de 2005.
[10] Stankovic, J.A., Rajkumar, R., Real-Time
Operating Systems, Real-Time Systems
Journal, Vol. 28, Issue 2, pp. 237-253,
Springer, Novembro de 2004.
[11] Jensen, E.D., Locke, C.D., Tokuda, H., A
Time-Driven Scheduling Model For Real-
Time Operating Systems, IEEE Real-Time
Systems Symposium, pp 112-122, 1985.
[12] Kopetz, Hermann., Real-Time Systems
Design Principles for Distributed Embedded
Applications, 1 ed., Kluwer Academic
Publishers, Boston, MA, USA, 1997.
[13] OSEK/VDX Steering Committe,
OSEK/VDX Operating System, Ver. 2.0,
rev. 1, outubro de 1997.
[14] Bowen, J.P, Stavridou, V., Safety-Critical
Systems, Formal Methods and Standards,
Software Engineering Journal, vol. 8, no. 4,
pp: 189-209, Julho de 1993.
[15] Butler, R.W., Finelli, G.B., The Infeasibility
of Quantifying the Reliability of Life-Critical
Real-Time Software, IEEE Transactions on
Software Engineering, vol. 19, no. 1, pp. 3-12,
in
1993.
[16] Fumihide Kitamura et al., Watch Dog
timer, United States Patent, Patent number:
4752930, 21 de Junho de 1988.
[17] Marwedel, P., Embedded System Design -
Embedded Systems Foundations of Cyber-
Physical Systems, 2 ed., Springer, 2011.
[18] Ellis, C.S., The Case for Higher-Level
Power Management, 7th IEEE Workshop on
Hot Topics in Operating Systems (HotOS-
VIII), pp. 162167, Rio Rico, AZ, Maro de
1999.
[19] H. W. Stone, Mars Pathfinder Microrover:
A Low-Cost, Low-Power Spacecraft, 1996
AIAA Forum on Advanced Developments in
Space Robotics, Madison WI, 1996.
[20] Wolf, W., Computers as Components -
Principles of Embedded Computing System
Design, Morgan Kaufmann Publishers, San
Francisco, 2 ed., Junho de 2008.
[21] Edwards, S., Lavagno, L., Lee, E.A.,
Sangiovanni-Vincentelli, A., Design of
Embedded Systems: Formal Models,
Validation and Synthesis, IEEE, vol. 85, No
3, pp. 366390, Maro de 1997.
[22] IEEE, IEEE Std 1012-2004 - IEEE
Standard for Software Verification and
Validation, Reviso do padro IEEE Std
1012-1998, 2004.
[23] Gajski D., Kuhn, R., New VLSI Tools,
Computer Magazine, pp 1114, Dezembro de
1983.
[24] Gajski, D.D., Abdi, S., Gerstlauer, A.,
Schirner, G., Embedded System Design -
Modeling, Synthesis and Verification,
Springer, 2009.
[25] Sangiovanni-Vincentelli, A., Martin, G.,
Platform-based Design and Software
Design Methodology for Embedded
Systems, IEEE Design and Test for
Computer, vol. 18, n. 6, p. 23-33, 2001.