Você está na página 1de 10

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 sistemas embarcados. Por outro lado, a


complexidade cada vez maior das novas aplicaes
A vasta gama de aplicaes nas quais os sistemas e o aumento da dinmica do mercado consumidor
embarcados esto presentes atualmente requer
tem exigido a melhoria das tcnicas e metodologias
diferentes tcnicas e abordagens para sua empregadas em seu projeto de forma e executa-lo
elaborao. O conhecimento prvio dessas
no menor espao de tempo possvel. Isto significa
metodologias e sua correta adoo de que os profissionais que pretendem atuar nessa rea
fundamental importncia para o sucesso do projeto
precisam estar familiarizados com essas
em condies limitadas de tempo e recursos. Nesse metodologias e tcnicas de projeto, bem como as
sentido, so abordados neste documento alguns
particularidades desse tipo de sistema.
conhecimentos introdutrios fundamentais a
respeito de sistemas embarcados e seu projeto, no Neste artigo so apresentados alguns conceitos
intuito de guiar os passos iniciais para o bsicos a respeito de sistemas embarcados e uma
aprofundamento no tema. breve introduo respeito do seu projeto.
1 Introduo 2 Sistemas Embarcados
A popularizao dos microprocessadores, iniciada Um Sistema Embarcado (SE), definido pela IEEE
em meados da dcada de 80, aliada contnua [3] como um sistema computacional que faz parte
reduo dos custos da tecnologia, deu incio a uma de um sistema maior e implementa alguns dos
verdadeira revoluo na vida cotidiana. Os requerimentos deste sistema. Esta definio,
processadores, antes quase totalmente restritos a estabelecida h mais de duas dcadas continua
computadores corporativos e algumas grandes vlida, embora a revoluo experimentada por esse
mquinas, hoje podem ser encontrados segmento durante estes ltimos anos tenha
praticamente por toda a parte. Automveis, impulsionado alguns autores a complementarem-na.
televisores, brinquedos, mquinas de lavar, Nesta linha, Steve Heath o define como sendo um
telefones, aparelhos de som, relgios de pulso, sistema baseado em um microprocessador, que
cartes de banco e at mesmo etiquetas de projetado para controlar uma funo ou uma gama
identificao descartveis [1] so hoje objetos de funes, e no para ser programado pelo
permeados por microprocessadores. A adoo de usurio 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 caractersticas que os distinguem dos computadores
Embarcados. pessoais. So elas:

Segundo uma recente pesquisa realizada pela IDC 1. So dedicados a tarefas especficas enquanto
[2], cerca de 19% de todos os sistemas eletrnicos PCs so plataformas genricas de
vendidos hoje no mundo so sistemas embarcados, computao Esta caracterstica tem
e este nmero dever crescer para 33% at 2015. impacto principalmente no poder
Eles so atualmente responsveis por uma receita computacional da mquina. PCs devem
anual de 1 trilho de dlares, o que deve dobrar nos poder rodar um grande nmero de
prximos 4 anos, quando ento sero responsveis aplicativos, com diferentes exigncias de
pelo consumo de cerca de 14,5 bilhes 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
especficas;
O rpido crescimento desse setor implica numa
demanda igualmente crescente de recursos 2. So 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 indstria automotiva,
sua vez oferece vrias solues distintas. por exemplo, possu um padro chamado
Apenas a Microchip [7], uma das lderes OSEK, no qual esto definidas uma srie de
deste segmento, tem hoje uma lista de mais especificaes a serem seguidas pelos seus
de 500 diferentes microcontroladores. RTOSs [13].
Naturalmente, um grande leque de opes
aumenta o grau de liberdade de escolha dos 6. Neles, as implicaes de uma falha de
projetistas mas tambm requer deles software so muito mais severas do que num
conhecimento adequado para encontrar as desktop muitos SEs interagem com o
solues mais apropriadas a cada projeto; ambiente ou seres humanos, como o caso
de sistemas de vida-crticos (life-critical
3. So geralmente sensveis aos custos a systems) [14][15], por exemplo. Falhas
maior parte dos sistemas embarcados podem ter consequncias no ambiente, no
possuem bem menos componentes e custam prprio 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 adio de meia dzia sistema de injeo eletrnica de um
de componentes bem mais significativo automvel, por exemplo, pode reduzir a vida
num sistema que possui uma dzia deles do til de componentes do motor e aumentar o
que num que possui mais de uma centena. consumo e a emisso de gases poluentes. Um
Em alguns sistemas de identificao sem bug no software de controle da dosagem de
contato (RFId), um simples capacitor pode radiao de uma mquina de raios-X poderia
representar at 20% dos custos totais [8]. ter consequncias srias na sade do
paciente. Por essa razo, muitos SEs
4. Possuem requisitos de tempo-real neste possuem mecanismos de segurana 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 sensvel e os que possuem Marwedel [17] estabelece 5 parmetros de
requisitos de tempo crtico. As tarefas de caraterizao de SEs:
tempo crtico so 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 no falhar;
de acionamento dos airbags de um carro so
um bom exemplo disso. Nele, alguns Manutenibilidade: a probabilidade
milissegundos podem fazer a diferena entre que uma falha no sistema possa ser
salvar ou no a vida do motorista [9]. Tarefas corrigida em um certo intervalo de
de tempo sensvel, por outro lado, so mais tempo;
tolerantes. Se a tarefa responsvel pelo Disponibilidade: a probabilidade do
fechamento da vlvula de gua de uma sistema estar disponvel. Ser tanto
mquina 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 alm do necessrio, perdendo
um pouco da eficincia almejada; Segurana: descreve a probabilidade
do sistema de no causar algum tipo de
5. Quando utilizam um sistema operacional, dano;
este quase sempre um RTOS A principal
Confidencialidade: descreve quo
diferena 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
comunicao autenticada;
convencional que num RTOS a importncia
para o sistema da finalizao de uma tarefa 7. Costumam ter restries 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 so alimentados
de deadlines para finalizao de cada tarefa. unicamente por pequenas baterias. Neles, a
Uma vez que o tempo de resposta visto reduo de alguns miliwatts/hora no
como parte crucial da exatido do software consumo pode estender a durao das
(SW), ele deve poder ser comprovado sem baterias por dias ou meses. Frequentemente,
argumentos estatsticos [12]. Assim como os a responsabilidade de poupar energia
microcontroladores, os RTOSs existem em atribuda unicamente aos engenheiros do
hardware (HW), mas em SEs essa memrias RAM de alta capacidade,
responsabilidade deve ser compartilhada processadores grficos e monitores de alta
tambm pelos desenvolvedores do software. resoluo, so recursos comuns dos desktops
Em um PDA, por exemplo, o consumo pode atuais. A capacidade de armazenamento da
ser reduzido em at 60% atravs de memria RAM desses computadores
alteraes na forma como o software pessoais maior do que todo o disco rgido
escrito [18]. Evidentemente, as escolhas de um tpico PC do final da dcada 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 memria
SEs o principal vilo 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 no chega a
Marte, por exemplo, teve o consumo como quinhentos bytes, todo o SW deve caber em
uma das principais restries de projeto. alguns poucos kB e rodar em um processador
Todos os mdulos 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 funes.
em sleep mode durante a noite, quando as Muitos no tem sequer um display e a
clulas fotovoltaicas deixavam de captar interface com o usurio se d atravs de
energia e a eficincia da bateria caa devido LEDs e sons. Evidentemente, o cdigo
queda de temperatura. Mesmo quando em escrito para essas aplicaes precisa observar
modo operacional, o software no podia uma srie de cuidados que os voltados para
manter ligado mais de um mdulo ao mesmo PCs no precisam. Uma simples operao
tempo devido escassez de energia matemtica, pode consumir 1% ou 70% da
disponvel [19]; memria em um dado microcontrolador,
dependendo apenas da forma como escrita;
8. Devem poder operar em condies
ambientais extremas A natureza porttil 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 caracterstica pode parecer insignificante mas
condies que seus usurios ou sistemas no . Ter seu cdigo armazenado em uma
receptores. Um PDA deve poder funcionar ROM impe severas limitaes ao sistema. A
40C na praia de Copacabana, a -15C nos primeira, discutida anteriormente, diz
Alpes ou a 11.000 metros de altitude na respeito ao tamanho do cdigo. A outra est
cabine de um avio. Da mesma forma, o ligada aos mtodos usados para projeta-lo.
sistema de frenagem ABS deve funcionar no Um cdigo armazenado numa ROM no
calor de 45C de Teresina, no frio de -5C 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 condies aps depurador precisa remover uma instruo do
5.000 km de estrada de terra trepidante. Os programa e substitui-la por outra responsvel
requisitos ambientais de operao geralmente por desviar a execuo para algum ponto do
tm consequncias diretas no hardware e as depurador, tarefa impossvel numa memria
vezes at mesmo no software. Um que no pode ser alterada aleatoriamente;
processador que precise ser selado em
borracha de silicone para poder suportar 11. Requerem ferramentas e mtodos
elevados ndices de umidade, ter sua especializados para serem eficientemente
capacidade de dissipao trmica 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 mudanas na sua forma de
software; concepo, teste e depurao, em relao a
um projeto de hardware e um projeto de
9. Seus recursos de sistema so extremamente software feitos isoladamente. Depurar um
menores do que os de um desktop sistema de processamento de vdeo no qual
Processadores com mltiplos ncleos parte dos blocos so implementados em
rodando frequncias superiores a 2 GHz, software e outra parte em hardware no
discos rgidos 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 depurao.
portas de comunicao de alta vazo, Muitas vezes, necessrio 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 especificao funcional, sob a forma
depurao. Depurar um sistema de controle de um conjunto de relaes explcitas ou
de altitude usando o prprio avio no implcitas que envolvem entradas, sadas, e
muito prtico, tampouco uma boa ideia; possveis estados internos;

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


possuem circuitos dedicados para depurao deve satisfazer, dadas na forma de um
Conforme explicado anteriormente, a conjunto de relaes entre entradas, sadas
depurao do cdigo programado em uma e estados, que possam ser comparados com
ROM encontra srias dificuldades. Por essa a especificao funcional;
razo, microprocessadores voltados para Um conjunto de ndices de desempenho
aplicaes embarcadas costumam incluir que avaliem a qualidade do projeto em
circuitos especialmente dedicados termos de custo, confiabilidade, velocidade,
depurao. Alguns fabricantes oferecem duas tamanho, etc., dados como um conjunto de
verses dos seus microprocessadores, uma equaes que envolvam, entre outras
de desenvolvimento, contendo os recursos coisas, entradas e sadas;
de depurao, necessrios ao projeto, e uma
verso de produo, sem tais recursos, a Um conjunto de restries sobre os ndices
fim de poupar rea de silcio e reduzir os de desempenho.
custos do componente. Dessa forma, o projeto durante o processo de
Uma vez expostas, em linhas gerais, as especificao e modelagem pode ser visto como a
caractersticas tpicas de um sistema embarcado, sequncia de passos que implementam o modelo
torna-se evidente a necessidade do estudo e especificado cumprindo as formalidades descritas
domnio de metodologias de projeto que permitam acima.
implementa-lo de forma eficiente no menor tempo Uma vez estabelecido o modelo, ele deve ser
possvel. validado. Segundo o IEEE [22], a verificao e
3 Projeto de Sistemas Embarcados validao 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 prprio software e do sistema esto
metodologia precisa. Segundo Waine Wolf [20], corretos, completos, precisos e consistentes,
trs razes principais justificam a importncia de se assegurando assim a qualidade de um produto de
seguir uma metodologia de projeto: 1 - permitir que software. Este conceito pode ser estendido tambm
o cumprimento dos requisitos de projeto possam ser para componentes de hardware, at porque eles
assegurados de maneira formal medida que o tambm podem ser modelados em linguagens
projeto avana; 2 - potencializar o uso de semelhantes s de programao (linguagens de
ferramentas de automatizao das tarefas (tais descrio de hardware). As duas principais
como ferramentas de CAD), uma vez que cada ferramentas utilizadas nessa etapa so a simulao e
etapa conhecida e pode ser dividida em pequenas a verificao formal [21]. Se um erro ou
tarefas automatizveis; 3 - facilitar a comunicao inconformidade com os requisitos detectado, o
entre as equipes de desenvolvimento, j que o processo se modelagem deve ser retomado para
estabelecimento da metodologia tambm auxilia a corrigi-lo, repetindo o ciclo, tantas vezes quantas
repartio de responsabilidades, permitindo que forem necessrias at que o modelo seja validado.
cada equipe tome cincia das atribuies das
demais e da maneira como esto vinculadas no Se um modelo foi validado ele pode ser sintetizado.
projeto. Por sntese entende-se, de forma abrangente, o
processo de se transformar uma especificao mais
Seja qual for a metodologia adotada, ela deve ser abstrata em uma menos abstrata, ou seja, o
capaz de realizar trs aes comuns a todo projeto processo de se aumentar o nvel de detalhamento de
[21]: especificao/modelagem, validao e sntese. uma especificao. Este conceito frequentemente
confundido com o conceito de compilao,
O processo de especificao e modelagem de um entretanto, conveniente estabelecer uma diferena
sistema, sub-sistema ou componente, pode ser entre eles. A compilao tem como entrada um
resumido como o processo que inicia com a software e como sada um software em um nvel de
descrio de uma especificao e termina com a abstrao mais baixo. A sntese, por outro lado,
descrio de um modelo. Segundo Edwards [21], mais abrangente. Ela pode ter como entrada um
software e como sada uma descrio de hardware, fisicamente implementado com componentes de
ou mesmo uma descrio de hardware e como sada silcio.
uma descrio de hardware em um nvel de
abstrao mais baixo. Neste exemplo o projeto foi divido em 4 nveis de
abstrao: sistema, processador, lgica e circuito.
Neste ponto, interessante introduzir outro No nvel do sistema o projeto descrito em termos
importante conceito, o de nveis de abstrao. Para de componentes tais como processadores,
isso, oportuno apresentar o diagrama em Y barramentos e memrias. No nvel do processador
proposto por Daniel Gajski [23], bastante popular os componentes do nvel de sistema so detalhados
entre projetistas de sistemas embarcados. Segundo em componentes da macro-arquitetura como
Gajski, toda a informao sobre um sistema pode processadores especficos, controladores de
ser representada por meio de um diagrama em Y, memria, rbitros de barramento, etc. No nvel da
conforme esboado na Fig. 1. lgica os componentes da macroarquitetura so
detalhados em componentes como portas lgicas,
Sistema flip-flops e registradores, enquanto no nvel de
ss
Comportamental Proce ador Estrutural circuito eles passam a ser descritos em termos de
Lgica pequenas clulas formadas por transistores
rcuito interconectados (pMOS e nMOS no caso da
Ci
tecnologia CMOS).
Naturalmente, o nmero de nveis de abstrao de
um projeto no rgido, 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 nveis de
abstrao so definidos pelas ferramentas de
Fsica
projeto adotadas, que por sua vez seguem um certa
Fig. 1: Diagrama em Y de Gajski padronizao, o que acaba por criar conjuntos bem
definidos de nveis de abstrao para as
Neste diagrama, toda a informao a respeito do metodologias mais populares.
sistema repartida em trs dimenses:
comportamental, estrutural e fsica. Na dimenso importante observar que uma vez que a diferena
comportamental cada componente visto como de detalhamento entre os modelos de nveis
uma caixa preta com sadas descritas em termos das consecutivos de abstrao gradual, a passagem de
entradas aplicadas em funo do tempo. Nela no um nvel para outro pode ser feita muitas vezes de
h qualquer informao de como ela construda, maneira automtica ou semi-automtica atravs de
ou seja, ela descreve o que o componente, mas ferramentas apropriadas. Da mesma forma,
no como ele . Na dimenso estrutural a caixa ferramentas de verificao podem ser utilizadas
preta representada como um conjunto de para analisar se os modelos de um mesmo sistema,
componentes e conexes. Na dimenso fsica ou sub-sistema, so coerentes entre si em diferentes
informaes de geometria so adicionadas, tais nveis de abstrao, a fim de detectar possveis
como altura, largura, peso, posio dos erros de implementao.
componentes, comprimento e forma das conexes,
etc. De maneira geral, o produto final do projeto situa-
se na camada mais interna do eixo de descrio
Cada um dos crculos concntricos (ou camadas) do fsica. A maneira como o diagrama percorrido
diagrama descreve o sistema alvo com diferentes at chegar a esse ponto definida pela metodologia
nveis de detalhamento. Percorrendo-o de fora para de projeto adotada. No exemplo esboado na Fig. 1,
dentro, parte-se do menor ao maior nvel de a metodologia parte da descrio comportamental
detalhamento, o que implica numa elevao da em nvel de sistema, refinando-a para uma
complexidade. Quanto menor o nvel de descrio comportamental em nvel de processador,
detalhamento na descrio do sistema, menor a depois para uma descrio estrutural no mesmo
complexidade e maior o nvel de abstrao dessa nvel, passando para uma descrio estrutural em
descrio, ou seja, a descrio do sistema vai do nvel de lgica, em seguida para uma descrio
nvel mais abstrato (e menos complexo) ao menos fsica, at finalmente sintetizar o projeto em uma
abstrato (e mais complexo) nas camadas mais descrio fsica em nvel de circuitos.
internas. Ao mesmo tempo, quanto mais se desce
nas camadas do diagrama, mais a descrio do Diversas metodologias de projeto de sistemas
projeto se assemelha ao seu nvel final: o produto embarcados tm sido propostas ao longo dos
ltimos anos. De maneira geral, podemos enquadra-
las em trs principais categorias, conforme a Infelizmente, estimativas no so perfeitas, o
sequncia em que do evoluo ao projeto. So que acaba por no eliminar o risco de
elas: reiteraes no projeto.

Bottom-up - o projeto inicia a partir da Meet-in-the-middle uma combinao das


descrio detalhada dos componentes metodologias bottom-up e top-down, visando
elementares do sistema. Esses componentes aproveitar as vantagens de cada uma delas e
so ento conectados para formar ao mesmo tempo evitar suas inconvenincias.
subsistemas, que por sua vez so conectados Em geral, essa metodologia emprega a
para formarem subsistemas maiores e assim, abordagem top-down nos nveis de abstrao
sucessivamente at compor o sistema mais altos e a bottom-up nos nveis mais
completo. Numa metodologia botton-up baixos [24]. Nela o projeto inicia com uma
tpica, os projetistas desenvolvem uma srie descrio em alto nvel de abstrao que
de componentes e os armazenam em uma refinada sucessivamente para nveis cada vez
biblioteca para serem utilizadas no prximo mais baixos at atingir um nvel intermedirio
nvel de abstrao. A vantagem desta quando ento descrito em termos de
metodologia de separar claramente cada componentes de uma biblioteca. Cada um dos
nvel de abstrao em sua prpria biblioteca. componentes dessa biblioteca, por sua vez,
Isto permite a repartio de todo o projeto em tem as descries dos nveis de abstrao
pequenas partes a cada nvel de abstrao e inferiores feitas atravs de alguma
facilitando o gerenciamento do projeto, j que metodologia botton-up. Um exemplo tpico
cada grupo fornece uma biblioteca de desta metodologia a Metodologia de Projeto
componentes para o prximo nvel de Baseada em Plataforma, proposta por
abstrao. Por outro lado, a desvantagem Sangiovanni-Vincentelli [25].
dessa metodologia que as bibliotecas devem
conter todos os possveis componentes com Atualmente, a maior parte dos projetistas utilizam
todos os possveis parmetros, devendo ser algum tipo de metodologia meet-in-the-middle [24].
otimizados para os requisitos do nvel de P:or essa razo, estes ltimos pargrafos sero
abstrao seguinte, algo difcil de se prever dedicados a expor um pouco mais sobre ela.
nos baixos nveis de abstrao. Um fluxo de projeto bastante popular, compatvel
Top-down - o projeto inicia com uma com metodologias meet-in-the-middle,
formulao geral das caractersticas 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 Especificao do Produto

implementado. medida que o projeto


Particionamento
Refinamento do

avana, o sistema vai sendo refinado, dividido


do HW e SW

Fase 6 Aceitao e Testes


Fase 5 Integrao
Fase 3 Iterao e

em subsistemas, os subsistemas em sub- e Atualizao


Fase 7 Manuteno

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

elementares. Alm de ser bastante intuitiva, Projeto do HW


esta metodologia tem a grande vantagem de
permitir um bom grau de automatizao, o
que permite reduzir o tempo de projeto e Lanamento do
Projeto do SW
minimizar a introduo de falhas humanas. Produto

Por outro lado, tem a desvantagem de no Fig. 2: Fluxo de projeto de sistemas embarcados
permitir conhecer com preciso as reais
mtricas do sistema at que o ltimo passo Neste fluxo, o ciclo de vida do projeto de sistemas
tenha sido completado. Quando elas no embarcados divido em 7 fases:
atendem aos requisitos, o projeto precisa
1. Especificao do produto;
recuar e ser refeito repetidas vezes at que
eles sejam alcanados. Para minimizar esse 2. Particionamento do projeto em
inconveniente, so empregados os chamados componentes de hardware e software;
estimadores, ferramentas capazes de estimar
3. Iterao e refinamento do particionamento;
caractersticas de um nvel mais baixo de
descrio, tais como consumo, desempenho, 4. Tarefas independentes de projeto do
rea de silcio ocupada, latncia, vazo, etc., a hardware e do software;
partir de descries em mais alto nvel.
5. Integrao dos componentes de hardware e CPU.
software;
Durante a fase de iterao e refinamento do
6. Testes, aceitao e lanamento do produto; particionamento, o particionamento definido na
7. Manuteno e atualizao contnua. fase anterior posto prova por meio de
ferramentas de alto nvel. Projetistas de hardware
Na fase de especificao o sistema inicialmente podero se valer de ferramentas de simulao
descrito de maneira informal atravs de uma srie arquitetural, por exemplo, enquanto projetistas de
de especificaes. Durante a especificao deve-se software podero rodar ferramentas de benchmark
destacar de forma clara quais so os requisitos do em placas de avaliao do processador ou
projeto que se deseja realizar. Os requisitos so as microcontrolador escolhido. Em funo dos
guias-mestre do projeto e estabelecem critrios resultados obtidos nesta fase, o particionamento
importantes tomada de decises durante as etapas pode ser revisto, repetindo-se o processo at que as
futuras. Pontos de otimizao subjetiva, se simulaes forneam resultados satisfatrios,
existirem, devem ser colocados de forma indicando que o projeto atender aos requisitos
hierrquica, ou seja, devem ser estabelecidos em estabelecidos.
ordem decrescente de relevncia, j que muitas
vezes sua implementao conflitante, fazendo Uma vez concluda a fase de iterao e refinamento
com que a otimizao de um deprecie as do particionamento, tem incio a fase seguinte, na
caractersticas 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 so duas modelado separadamente. Durante essa fase,
caractersticas que comumente se deseja otimizar. O ferramentas e tcnicas de verificao so
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. Aps
ao final da fase 5, as duas caractersticas atenderem essa fase os componentes de HW e SW so
aos requisitos (com algum grau de liberdade), os reunidos e integrados (fase 5) de forma a compor o
projetistas devero saber qual delas dever ser sistema embarcado completo. Idealmente, ao se
priorizada na otimizao. Ao final da fase de reunir os componentes tudo deveria funcionar
especificao, as especificaes, inicialmente perfeitamente, mas a realidade costuma ser
informais, devem ter sido formalizadas diferente e erros aparecem. Por se tratarem de
(frequentemente atravs de alguma linguagem de sistemas complexos, a tarefa de se localizar e
alto nvel, como UML, por exemplo), de tal sorte corrigir as fontes dos problemas no costuma ser
que um diagrama de blocos do sistema embarcado algo evidente. Alm disso, alguns problemas podem
completo possa ser visualizado, e cada bloco ter seu mecanismo de ativao bastante complexo,
contenha especificaes funcionais e dependendo, por exemplo, de uma sequncia
comportamentais. especfica 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
devero decidir quais partes do sistema sero ponto, ferramentas de co-simulao e verificao,
implementadas em hardware e quais sero em conjunto com instrumentos como osciloscpios
implementadas em software. Essas partes podem e analisadores lgicos costumam ser necessrios.
tanto ser blocos definidos na fase de especificao,
como tambm fraes deles (sub-blocos). Aps a integrao do sistema e depurao dos erros
Dependendo da metodologia utilizada, esse encontrados, vem a fase de testes e lanamento do
particionamento pode ser guiado em funo dos produto. Nesta fase o sistema testado
componente de HW e SW pr-existentes nas exaustivamente em condies idnticas s que ele
bibliotecas de projeto em uso. Deve-se notar no ser submetido aps o lanamento do produto.
entanto que essa deciso deve atender Durante esses testes, o sistema dever responder e
prioritariamente os requisitos estabelecidos na fase comportar-se conforme os requisitos estabelecidos
de especificao. A deciso de implementar um no incio do projeto.
dado bloco em hardware implica, na maioria das
vezes, num aumento da complexidade, tempo e Finalmente, aps o lanamento do produto no
custos do projeto, mas permite um ganho de mercado, vem a fase de manuteno e atualizao.
desempenho bem maior que sua implementao 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 diferena entre ter uma placa dedicada novamente. Faz parte dessa fase tambm a busca
acelerao grfica e emular OpenGL na prpria por otimizar as caractersticas do produto lanado,
bem como o enriquecimento da documentao Springer, Novembro de 2004.
externa (para o pblico) 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 Concluso Systems Symposium, pp 112-122, 1985.
Foram apresentados alguns conceitos bsicos 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 exposio 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,
informao foi omitida pela brevidade deste rev. 1, outubro de 1997.
documento. Por essa razo, literaturas que [14] Bowen, J.P, Stavridou, V., Safety-Critical
considero imprescindveis 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 Referncias 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 20112015
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. 162167, Rio Rico, AZ, Maro 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. 366390, Maro 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, Reviso do padro IEEE Std
[9] Jung, C. R.; Osrio, F. S.; Kelber, C.; Heinen,
1012-1998, 2004.
F., Computao Embarcada: Projeto e
[23] Gajski D., Kuhn, R., New VLSI Tools,
Implementao de Veculos Autnomos
Computer Magazine, pp 1114, Dezembro de
Inteligentes, Anais do CSBC05 XXIV
1983.
Jornada de Atualizao em Informtica (JAI),
[24] Gajski, D.D., Abdi, S., Gerstlauer, A.,
v. 1, p. 13581406, So 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.