UNIVERSIDADE DE SO PAULO

ESCOLA DE ENGENHARIA DE SO CARLOS

RAFAEL MOYA RODRIGUES PEREIRA

Processos de Software para Implementaes de Especificaes

Relacionadas ao Projeto Frmula SAE/EESC/USP

So Carlos
2012

RAFAEL MOYA RODRIGUES PEREIRA

PROCESSOS DE SOFTWARE PARA

IMPLEMENTAES DE
ESPECIFICAES RELACIONADAS
AO PROJETO FRMULA
SAE/EESC/USP

Trabalho de Concluso de Curso apresentado

Escola de Engenharia de So Carlos, da
Universidade de So Paulo
Curso de Engenharia Eltrica com nfase em
Eletrnica
ORIENTADOR: Professor Doutor Ivan Nunes da Silva

So Carlos
2012

AUTORIZO A REPRODUO TOTAL OU PARCIAL DESTE TRABALHO,

POR QUALQUER MEIO CONVENCIONAL OU ELETRNICO, PARA FINS
DE ESTUDO E PESQUISA, DESDE QUE CITADA A FONTE.

M436p

Moya Rodrigues Pereira, Rafael

Processos de Software para Implementaes de
Especificaes Relacionadas ao Projeto Frmula
SAE/EESC/USP / Rafael Moya Rodrigues Pereira;
orientador Ivan Nunes da Silva. So Carlos, 2012.
Monografia (Graduao em Engenharia Eltrica com
nfase em Eletrnica) -- Escola de Engenharia de So
Carlos da Universidade de So Paulo, 2012.
1. Engenharia de Software. 2. CAN. 3. Frmula SAE.
4. sensores. I. Ttulo.

vi

Dedico este trabalho e a graduao para os meus pais,

familiares, colegas de curso e aos amigos da equipe
Frmula SAE que participaram e me ajudaram a passar por
esta etapa da minha vida.

vi

Agradecimentos
Aos meus pais, exemplos de f, dedicao, honestidade e persistncia, por toda a
ateno, carinho e suporte que me dedicaram durante mais esta etapa de minha vida. A
minha tia Encarnacion e a minha irm sempre ao meu lado para apoiar, incentivar e
motivar-me a continuar esta caminhada. A todos os familiares, que me deram fora e
motivao para sempre seguir em frente e sobrepor todas as barreiras que apareceram ao
longo desses anos.
Aos colegas de equipe FSAE, em especial Andr Lui, Danilo Porto, Jos Ernesto
por me motivarem e colobararem diretamente neste trabalho; Aos colegas de curso, em
especial Michel Lacerda pelas suas orientaes, Daniel Corral e Ciro Castro pelo incentivo
as nossas participaes em projetos extracurrilares, a Leticia Braga pela sua amizade e a
Jussara Ribeiro que serviu de lder e exemplo por todos esses anos, aos companheiros de
TCC Luciano Falqueto, Rafael Mattazio, e a Rafaela Peixoto pelas inmeras trocas sobre
formatao e redao de nossos trabalhos. Ao Professor Ivan pelo conhecimento,
orientao e ateno fornecida durante a graduao e o trabalho.
E a todos que contriburam de alguma forma para o sucesso deste trabalho e para a
realizao de um sonho.

Muito Obrigado!

ix

Resumo
Este trabalho faz parte de um projeto maior de desenvolvimento de um prottipo de
competio universitria, FSAE, da equipe Frmula SAE/EESC/USP da Escola de
Engenharia de So Carlos, que consiste no desenvolvimento de softwares para controle,
aquisio e transmisso de dados dos sensores do prottipo. Os sensores fornecem um sinal
eltrico entre 0 e 5 V. Tais sinais sero ento tratados pelo conjunto software/hardware
desenvolvido pela equipe, em que neste caso, ns iremos estudar o projeto destes softwares,
denominados POPA, PROA e Painel, conforme a posio do hardware no prottipo. Alm
de receber os sinais dos sensores, tm-se tambm o software que envia sinais para o atuador
pneumtico e para a ECU (Unidade de controle eletrnico do motor). Todos os sinais esto
disponibilizados em um barramento CAN, que tem um n transmissor que faz comunicao
via RF com um programa em Labview, o qual exibe em tempo real a situao do prottipo
na pista.
Palavras-Chave: Engenharia de Software, CAN, Frmula SAE, sensores

xi

xii

Abstract
This work is part of a bigger development project of a students competition
prototype, known as FSAE, belonging to Frmula SAE EESC/USP team from Escola de
Engenharia de So Carlos. The project is based on control, aquisition and data transmission
hardware/software from the sensors alocated in many places of the car.

The sensors sends

an eletric signal between 0-5V. This signals will be treated by the software/hardware
developed by the team. In this case, we will study the project of this softwares, called by us
POPA, PROA and Painel, according to the hardwares position in the car. Besides
receiving the signals from the sensors,these softwares control a pneumatic actuador and
communicate with the prototype's ECM (Eletronics Control Motor). The information is
transmitted through the CAN bus, that has one transmissor node responsible for the RF
communication with another software, this one developed in Labview, that shows real time
data of the prototype during the race.
Palavras-Chave: Software Engineering, CAN, SAE Formula, sensors

xiii

xiv

Lista de Figuras
Figura 1 - Quadro para controle das atividades de um projeto. ............................................ 24
Figura 2 - Modelo Real de Processo de Software ................................................................ 30
Figura 3 - Modelo Cascata.................................................................................................... 33
Figura 4 - Competio FSAE Brasil 2011 ............................................................................ 36
Figura 5 - Prtotipo EX ........................................................................................................ 37
Figura 6 - Organograma Equipe Formula SAE .................................................................... 38
Figura 7 - Organograma Equipe Eletrnica .......................................................................... 39
Figura 8 Exemplo de tela a ser exibida pelo software Tratamento de Dados ................... 61
Figura 9 Disposio dos Mdulos ..................................................................................... 62
Figura 10 Cronograma ....................................................................................................... 78
Figura 11 Projeto de arquitetura ........................................................................................ 78
Figura 12 - Fluxo de leitura de um dado analgico .............................................................. 79
Figura 13 - Fluxo da comunicao da ECM ......................................................................... 79
Figura 14 - Unidade de Controle do Motor (ECM) .............................................................. 80
Figura 15 - Fluxo da leitura de um dado digital (Atuadrores) .............................................. 80
Figura 16 Borboletas e vlvula solenoide para troca de marcha ...................................... 81
Figura 17 - Fluxo de leitura de um dado digital (Sensores) ................................................. 81
Figura 18 - Sensor de velocidade ......................................................................................... 82
Figura 19 - Fluxograma procedimentos programao .......................................................... 85

xv

xvi

Lista de Tabelas
Tabela 1 Atributos de software .......................................................................................... 25
Tabela 2 Modelos de processo........................................................................................... 29
Tabela 3 Diferenas Engenharia de Software x demais Engenharias ............................... 40

xvii

xviii

Lista de Siglas
FSAE : Frmula SAE
SAE: Sociedade dos Engenheiros da Mobilidade
EESC: Escola de Engenharia de So Carlos
USP: Universidade de So Paulo

xix

xx

Sumrio
Agradecimentos ..................................................................................................................... ix
Resumo .................................................................................................................................. xi
Abstract ................................................................................................................................ xiii
Lista de Figuras .................................................................................................................... xv
Lista de Tabelas .................................................................................................................. xvii
Lista de Siglas ...................................................................................................................... xix
Sumrio................................................................................................................................ xxi
Captulo 1 Introduo ........................................................................................................ 23
1.1

Apresentao ........................................................................................................ 23

1.2

Objetivos............................................................................................................... 25

1.3

Organizao da Monografia ................................................................................. 26

Captulo 2 Reviso de Literatura ....................................................................................... 29

2.1

Atividades de processo Engenharia de Software .................................................. 30

2.1.1

Requisitos ou Especificao de software........................................................ 30

2.1.2

Projeto de software (Cdigo).......................................................................... 32

2.1.3

Testes .............................................................................................................. 33

2.1.4

Manuteno .................................................................................................... 33

2.2

Conceitos de Frmula SAE .................................................................................. 35

2.2.1

A Competio FSAE ...................................................................................... 35

2.2.2

O Projeto EX e a Equipe EESC USP ............................................................. 37

2.2.3

O Projeto Eletrnica e a Equipe Eletrnica EESC USP ................................. 39

Captulo 3 Modelos de Relatrios Tcnicos ...................................................................... 43

3.1

Especificao Sistema Eletrnica FSAE .............................................................. 43

3.1.1

Objetivo .......................................................................................................... 43

3.1.2

Escopo do Fornecimento ................................................................................ 43

3.1.3

Arquitetura do Sistema Eletrnica FSAE ....................................................... 43

3.2

Relatrio Tcnico Softwares ................................................................................ 44

xxi

3.2.1

Objetivo .......................................................................................................... 44

3.2.2

Escopo do Fornecimento ................................................................................ 44

3.2.3

Requisitos ou Especificao de software........................................................ 44

3.2.3.1

Estudo da Viabilidade ................................................................................. 44

3.2.3.2

Anlise Econmica ..................................................................................... 45

3.2.3.3

Anlise de Cronograma .............................................................................. 45

3.2.4

Projeto de Software (Cdigo) ......................................................................... 45

3.2.4.1

Projeto de arquitetura .................................................................................. 45

3.2.4.2

Projeto de componente................................................................................ 46

3.2.4.3

Projeto de estruturas de dados..................................................................... 46

3.2.4.4

Projeto de algoritmo.................................................................................... 46

3.2.5

Testes .............................................................................................................. 46

3.2.5.1

Teste de Componente.................................................................................. 46

3.2.5.2

Teste de Sistema ......................................................................................... 47

3.2.5.3

Teste de Aceitao ...................................................................................... 47

3.2.6

Manuteno .................................................................................................... 47

3.2.6.1

Manuteno Corretiva................................................................................. 47

3.2.6.2

Manuteno Adaptativa .............................................................................. 47

Captulo 4 Resultados e Concluses .................................................................................. 49

4.1

Concluses Gerais ................................................................................................ 49

4.2

Trabalhos Futuros ................................................................................................. 49

Bibliografia ........................................................................................................................... 51
Anexo 1 Especificao Sistema Eletrnica FSAE ............................................................ 53
Anexo 2 Relatrio Tcnico Softwares FSAE .................................................................... 65

xxii

Captulo 1 Introduo
1.1 Apresentao
Nas ltimas dcadas o desenvolvimento tecnolgico tem avanado rapidamente.
Com a globalizao, as necessidades de produtos especficos tm aumentado e com isso
gerando a necessidade de adaptao dos projetos de engenharia. O desenvolvimento
mecnico dos componentes percorreu um maior tempo; dessa forma, o desenvolvimento do
software que ir controlar esse componente mecnico tem se tornado cada vez mais o
diferencial de um projeto, sendo determinstico no funcionamento adequado do produto e,
para tal desenvolvimento, o uso de mtodos de projeto de suma importncia,
consequentemente dando espao a uma nova necessidade nos projetos, ou seja, controlar a
qualidade, ditar mtodos de testes, validao e etc, abrindo espao para o surgimento e
crescimento da Engenharia de Software, mas o que engenharia de software?
Engenharia de Software o estabelecimento e uso de slidos princpios de
engenharia para que se possa obter economicamente um software que seja confivel e que
funcione eficientemente em mquinas reais Software engineering is the establishment and
use of sound engineering principles in order to obtain economically software that is reliable
and works efficiently on real machines. Naur and Randell, [1].
Nos processos de desenvolvimento do prottipo de competio FSAE, consta nas
regras determinadas pela SAE a possibilidade das equipes desenvolverem e investigar, alm
dos sistemas mecnicos, como freios, suspenso, chassi que influenciam o comportamento
dinnico do veculo, sistemas de powertrain e eletrnica, estes responsveis por controle de
todo fornecimento de potncia e energia para movimentar o veculo, assim como sistemas
de telemetria, aquisio de dados, controle e atuao responsveis por fornecer aos outros
integrantes (subsistemas) dados para validar e/ou desenvolver novas tcnicas e produtos,
visando o desenvolvimento dos estudantes das diversas engenharias aplicadas ao projeto.
O gerenciamento das atividades do projeto do prottipo realizado num contexto
geral, levando em conta alguns princpios de gesto de projetos, conhecidas tcnicas de
gerenciamento de projetos, contudo, ao lidar com o desenvolvimento de softwares para
aquisio e tratamento de dados, controle de atuadores para troca de marcha, e sistema em
tempo real de telemetria, devemos nos atentar necessidade de tratamento diferenciado,
23

sabido que um software no pode ser manufaturado no sentido fsico de entregar uma pea
pronta para complementar um sistema de freios por exemplo. A Figura 1 apresenta um
exemplo de quadro para controle das atividades de um projeto.

Figura 1 - Quadro para controle das atividades de um projeto.

24

1.2 Objetivos
Este trabalho prope como objetivo principal aplicar conceitos de Engenharia de
Software no projeto do software utilizado pela equipe Frmula/SAE/EESC/USP para
aquisio, tratamento e telemetria do veculo prottipo EX 2012.
De modo anlogo ao projeto do sistema Estrutural, os projetos de software da
Eletrnica devem seguir um mtodo de produo e avalio quanto aos seus atributos.
Esses atributos so inerentes funo do software, e so comumente usados na avaliao
de qualidade e refletem o comportamento perante (quanto) sua execuo, estrutura e
organizao do cdigo-fonte, bem como toda documentao referente ao projeto. O
conjunto especifco de atributos que voc pode esperar de um sistema de software pode ser
generalizado conforme Tabela 1 [2, 3].
Tabela 1 Atributos de software

COMPONENTE

DESCRIO
O software deve ser escrito de modo que possa evoluir para atender

Facilidade de

s necessidades de mudana dos clientes. um atributo fundamental,

manuteno

pois a mudana de software uma consequncia inevitvel de um

ambiente de negcios em constante mutao.
O nvel de confiana do software tem uma srie de caractersticas,

Confiana

incluindo confiabilidade, proteo e segurana. Um software

confivel no deve causar danos fsicos ou econmicos no caso de
falha no sistema.
O software no deve desperdiar os recursos do sistema, como

Eficincia

memria e ciclos do processador. Portanto, a eficincia inclui tempo

de resposta, tempo de processamento, utilizao de memria etc.
O software deve ser usvel, sem esforo excessivo, pelo tipo de

Usabilidade

usurio para o qual ele foi projetado. Isso significa que ele deve
apresentar uma interface com o usurio e documentao adequadas.

A equipe EESC/USP/FSAE j possui tais sistemas e vem evoluindo o

desenvolvimento e robustez dos softwares a cada novo prottipo; porm, com este trabalho
25

ter um padro a ser seguido e posteriormente adequado com a evoluo das necessidades,
impactando em softwares mais confiaveis, de manuteno e evoluo simplificada, e
resultados melhores na competio.
Ciente que o time que trabalha no projeto de software da Equipe FSAE formado
por estudantes em formao com nvel de maturidade incipiente em implementao de
processos, e com o objetivo de implantar prticas de Engenharia de Software ao longo do
projeto, a abordagem ter como foco definir cada atividade, gerar documentos tcnicos de
especificao de projeto e de documentao do projeto. [4]
Com este intuito, o trabalho rene vrios campos abordados durante o curso de
graduao (circuitos eletrnicos, programao, instrumentao eletrnica) e tambm
conhecimentos da Engenharia Mecnica em busca de atender os requisitos impostos para
alcanar o objetivo do projeto do grupo de eletrnica a fim de prover informao aos
diversos subsistemas da equipe em busca do melhor projeto de engenharia na competio
FSAE Brasil.

1.3 Organizao da Monografia

A monografia se estrutura de acordo com a segmentao em captulos proposta a
seguir:
Captulo 1: Introduo - Faz um apanhado geral do tema da monografia de modo a
fornecer uma idia abrangente do projeto.
Captulo 2: Reviso de Literatura Tem como objetivo apresentar o tema
gerenciamento de projetos e engenharia de software, abordando alguns mtodos e
atividades usuais em projetos de software, assim como abordaremos brevemente sobre
Frmula SAE e suas atividades, contextualizando ento este trabalho dentro do mesmo.
Captulo 3: Modelos de Relatrios Tcnicos Este captulo apresenta dois
documentos bsicos resultantes do estudo terico de Engenharia de Software e de
aplicaes anteriores da equipe, assim como experincias adquiridas durante o estgio.
Estes documentos sero autoexplicativos e tem-se por objetivo que sejam utilizados e
aperfeioados com os projetos seguintes.

26

Captulo 4: Resultados e Concluses Este captulo apresenta as anlises e os

resultados obtidos com a implementao da metodologia. Aponta tambm possiveis
melhorias a serem feitas futuramente e a concluso do projeto.
Anexo 1: Documento de Especificao do Sistema Eletrnica FSAE
Anexo 2: Relatrio Tcnico (Softwares Proa, Popa e Painel)

27

28

Captulo 2 Reviso de Literatura

O desenvolvimento de software se orienta normalmente a partir de modelos, de
representaes abstratas e de processo de sofware. Na Tabela 2 apresentaremos alguns
modelos genricos de processo que podem ser ampliados e adaptados para criar processos
mais especficos de engenharia de software [2].
Tabela 2 Modelos de processo

MTODO

CARACTERSTICA
Considera as atividades fundamentais do processo

Modelo em
cascata

compreendendo especificao, desenvolvimento, validao e

evoluo, e as representa como fases de processos separadas, tais
como especificao de requisitos, projeto de software,
implementao, teste e assim por diante.
Esta abordagem intercala as atividades de especificao,

Desenvolvimento
evolucionrio

desenvolvimento e validao. Um sistema inicial desenvolvido

rapidamente baseado em especificaes abstratas. Este sistema ,
ento, refinado com as entradas do cliente para produzir um
sistema que satisfaa as necessidades do cliente.

Engenharia de
software baseada
em componentes

Esta abordagem baseia-se na existncia de um nmero

significativo de componentes reutilizveis. O processo de
desenvolvimento do sistema enfoca a integrao desses
componentes, em vez de desenvolv-los a partir do zero.

Em suma, na prtica, so utilizados conceitos dos trs modelos citados, como

podemos notar, pelo modelo real de processos (Figura 2) durante o desenvolvimento dos
softwares, partes podem ser reusadas, partes podem ter especificao simples e detalhada
no incio do projeto, outras ocorrero em virtude de atualizao das especificaes ou
alteraes de hardware, sendo que no projeto final de software tenha sido empregado o uso
em conjunto dos modelos, portanto a abordagem deste trabalho passa a ter foco nos
processos em particular [5].
29

Especificao
de Software

Projeto de
Cdigo

Manuteno

Testes

Figura 2 - Modelo Real de Processo de Software

2.1 Atividades de processo Engenharia de Software

Os processos de software divergem quanto organizao das quatro atividades
bsicas do processo especificao, desenvolvimento, validao e evoluo. No modelo
em cascata, as atividades so organizadas sequencialmente, enquanto, no desenvolvimento
evolucionrio, elas so intercaladas. Como essas atividades realizadas dependem do tipo de
software, pessoas e estruturas organizacionais envolvidas. No existe uma forma certa ou
errada de organizar essas atividades e essas especificamente seguem o mesmo formato,
independente do modelo de processo [2].

2.1.1 Requisitos ou Especificao de software

A atividade de especificao de software pode ser considerada uma das etapas mais
complexas devido necessidade de compreender e definir os servios necessrios,
restries de operao e de desenvolvimento. A execuo de um bom cdigo e entrega de
um software de qualidade depende do projeto incial proveniente da especificao de
software, sendo perceptvel que erros na engenharia de requisitos conduziro a falhas na
implementao do sistema [5].
30

O resultado da especificao de software um documento de requisitos, seguindo

um processo com quatro fases principais para publicao final do documento para incio do
projeto de software por parte dos programadores e acertos financeiros por parte do
departamento de venda/compra dos interessados, desta forma usualmente h dois nveis de
detalhamento neste documento.
As quatro fases principais do processo de engenharia de requisitos:
i. Estudo de viabilidade.
ii. Elicitao e anlise de requisitos.
iii. Especificao de requisitos
iv. Validao de requisitos.
Rotineiramente, a anlise de requisitos ocorre desde o incio do projeto at prximo
da entrega do sistema ao cliente. Assim, as quatro fases ocorrem concomitantementes de
forma a esclarecer os limites do projeto, pois com o andamento do projeto novas
solicitaes e novos obstculos podem surgir gerando necessidade de adaptao, seja ela
tcnica, comercial ou de outra natureza. [2].
Padro mais amplamente conhecido o IEEE/ANSI 830-1998 (IEEE,1998). O
padro IEEE sugere a seguinte estrutura para os documentos de requisitos:
1.Introduo
1.1 Proposito do documento de requisitos
1.2 Escopo do produto
1.3 Definies, acrnimos e abreviaturas
1.4 Referncias
1.5 Viso geral do restante do documento
2. Descrio geral
2.1 Perspectiva do produto
2.2 Funes do produto
2.3 Caractersticas dos usurios
2.4 Restries gerais
2.5 Suposies e dependncias
3. Requisitos especficos
4. Apndices
31

5. ndice.

2.1.2 Projeto de software (Cdigo)

A atividade de desenvolvimento de software consiste em converter uma
especificao de sistema em um sistema executvel. Esta atividade envolve a definio da
arquitetura, dos componentes, das interfaces do sistema, algoritmo entre outras especificas
a cada projeto, geralmente ocorre nesta etapa um refinamento da especificao inicial do
sistema.
Um projeto de software deve conter a descrio da estrutura de software a ser
implementada, dos dados que so partes do sistema, das interfaces entre os componentes do
sistema e, dos algoritmos usados. Todo processo do projeto decomposto permitindo que
os erros e as omisses em estgios anteriores sejam descobertos.
De acordo com o guia [6] esta atividade de grande importncia, pois durante
suas tarefas que podem ser detectados problemas de funcionamento e de especificao do
software que podem comprometer seu uso e concluso do mesmo. Caso estes problemas
no fossem detectados nesta etapa, teramos a concluso do projeto do sistema
comprometida e, em caso de possveis ajustes, suas correes se tornariam bastante custosa
e grande parte do trabalho de desenvolvimento seria perdido. Alm disso, o projeto do
software procura prover uma viso mais geral do sistema, permitindo-se calcular possveis
impactos das decises tomadas durante o projeto e de cada deciso tomada no decorrer do
projeto.
A sada de cada tarefa de projeto uma especificao para o prximo estgio.
Conforme o processo das tarefas realizado, essas especificaes tornam-se mais
detalhadas, convergindo para especificaes precisas dos algoritmos e estruturas de dados a
serem implementados.
As tarefas resumidas desta atividade so as seguintes:
i. Projeto de arquitetura.
ii. Projeto de componente
iii. Projeto de estruturas de dados
iv. Projeto de algoritmo

32

2.1.3 Testes
As atividades de testes constituem os processos de software. Em alguns casos como
no modelo cascata da Figura 3, a ltima etapa antes da entrega ao cliente e, portanto
durante esta atividade que qualquer falha que tenha passado despercebida deve ser
detectada, garantido que o sistema a ser entregue represente o qu est definido na
especificao de software [2, 5, 7]

Figura 3 - Modelo Cascata

A fase de verificao e validao tem carter revisor. E, desta forma, demanda em

muitas ocasies recursos em propores maiores que a soma das outras etapas juntas, como
de apresentar que o sistema est em conformidade com sua especificao para atender as
exigncias do cliente.
Os testes de software so distribudos resumidamente em trs etapas:
1.

Teste de componente (ou unidade).

2.

Teste de sistema.

3.

Teste de aceitao.

Ressalta-se que as diversas literaturas existentes dizem que os testes no garantem

que o software est correto, indicando apenas que a realizao dos testes de modo rotineiro
e planejado assegura o atendimento de requisitos mnimos de qualidade.

2.1.4 Manuteno

33

A atividade de manuteno iniciada assim que o sistema de software entregue

para operao. No projeto corrente, esse momento ocorre quando o prottipo lanado e
uma primeira verso de todos os subsistemas contempla seu lanamento.
Diferentemente da manuteno de hardware, em que existe a fadiga por uso,
desgaste do componente, falha ou defeito na fabricao, que pode ser feita com a troca ou
reparo da pea que apresenta mau funcionamento, a manuteno de software, para correo
de falhas/defeitos uma vez que em termos de software so sinnimos, uma vez que afetam a
qualidade do produto, pode ocorrer mudanas simples para corrigir erros de codificao,
mudanas mais extensas para corrigir erros de projetos ou melhorias significativas para
corrigir erros de especificao ou para acomodar novos requisitos, conforme classificao
abaixo.
Existem trs tipos diferentes de manuteno de software, ou sejam:
1. Manuteno para reparo de defeitos de software.(Corretiva).
2. Manuteno para adaptar o software a um ambiente operacional diferente
(adaptativa).
3. Manuteno para adicionar funcionalidade ao sistema ou modifica-las
(evolutiva).
Os estudos realizados por [8] e abordados em [2] e [9] ressaltam, juntamente com a
questo da manuteno evolutiva a questo da evoluo do software, sendo esta deciso
entre iniciar um novo projeto ou fazer a modificao para atender um novo requisito um
processo no trivial, onde os custos envolvidos, a confiabilidade do software aps
manuteno e sua capacidade para mudanas futuras devem ser levadas em considerao.
Voltando estas discusses ao projeto da equipe constata-se claramente, como
poderemos notar nos documentos anexos, que questes financeiras no devem influenciar o
projeto negativamente, fazendo com que a deciso caminhe para o lado de confiabilidade e
capacidade para mudanas futuras que nos leva a iniciar um novo projeto a cada novo
prottipo da equipe, fazendo porm reuso de hardware, cdigos e experincias anteriores
devido similaridade evolutiva entre os projetos.

34

2.2 Conceitos de Frmula SAE

2.2.1 A Competio FSAE
Frmula SAE uma competio estudantil organizada pela SAE (Sociedade dos
Engenheiros da Mobilidade). A primeira competio aconteceu em 1979, quando Mark
Marshek, ento na Universidade de Houston (Texas), entrou em contato com o
Departamento de Relao Educacional da SAE para discutir a criao de uma variao da
competio Mini Baja, dando incio nova categoria com o nome Mini Indy.
Tendo em vista o potencial do evento, Mike Best, Robert Edwards e John Telkamp,
estudantes da Universidade do Texas em Austin, entraram em contato com Dr. Ron
Matthews com uma ideia que tal outro Mini-Indy, mas com algumas mudanas? Criaram
novas regras, porm com maior flexibilidade execuo do projeto. O desejo era que essa
nova competio levasse os carros prximo ao nvel de engenharia, j que a competio de
Baja era tima para projetos estruturais, mas muitos estudantes tambm queriam a
flexibilidade de trabalhar com os motores. As novas regras modificaram as restries
mnimas destes: seriam permitidos quaisquer motores 4 cilindros, desde que com potncia
limitada por uma restrio de 25.4mm na entrada de ar.
Com apoio total dos estudantes, Dr. Ron Matthews contatou o Departamento de
Relao Educacional da SAE e colocou a nova ideia em ao. Para diferenciar este novo
evento do Mini-Indy, era preciso um novo nome. Assim surge o Formula SAE, nome que
reflete a natureza de corrida em pista do evento e o contedo avanado de engenharia.
O conceito por trs do Formula SAE tal que uma empresa fictcia est contratando
uma equipe de projeto para desenvolver um pequeno carro de corrida tipo Formula. O
prottipo do carro de corrida ser avaliado pelo seu potencial de produo em srie. Para
fins de marketing do projeto, o pblico alvo so os corredores de autocross amadores. Cada
equipe dever ento projetar, construir e testar o prottipo seguindo uma serie de regras,
cujo propsito garantir a realizao do evento com segurana e forar a proposta de
solues inteligentes.
Formula SAE promove profissionalmente e excelncia em engenharia, assim como
engloba todos os aspectos da indstria automotiva, incluindo pesquisa, projeto, manufatura,
testes, desenvolvimento, marketing, gerenciamento e finanas. Formula SAE leva os
35

estudantes para fora das salas de aula e permite a aplicao das teorias dos livros em casos
reais de trabalho.
Atualmente, a competio se expandiu e inclui um grande nmero de eventos
agregados. Internacionalmente, participando da srie Formula SAE, usando as regras
Formula SAE Rules Copyright, h competies nos Estados Unidos, em duas localidades,
Lincoln e Michigan, sendo este o maior e mais longo evento. Outras competies Formula
so as seguintes
Formula SAE Australia
Formula SAE Brasil
Formula SAE Italia
Formula Student Reino Unido
Formula Student Alemanha
Formula SAE Japo
As informaes descritas acima foram retiradas do site da SAE International [10] e
seu objetivo deixar o leitor familiarizado e ciente do contexto em que o trabalho foi
realizado.A Figura 4 mostra dois integrantes recebendo os trofus em competio realizada
em 2011.

Figura 4 - Competio FSAE Brasil 2011

36

2.2.2 O Projeto EX e a Equipe EESC/USP

A Equipe EESC-USP de Formula SAE foi fundada em Junho de 2003 por alunos da
Escola de Engenharia de So Carlos, alunos estes que em sua maioria eram ex-membros da
Equipe EESC-USP de Mini-Baja. Neste ano a equipe est desenvolvendo seu 10 prottipo,
denominado EX, para participar da 9 Competio SAE Brasil Petrobras de Formula SAE
a ser realizada dos dias 30 de Novembro a 02 de Dezembro.

Figura 5 - Prtotipo EX

A Figura 5 apresenta o prottipo durante testes realizados em Paulnia.

A equipe se divide em reas tcnica e administrativa, com subdiviso em sistemas e
subsistemas, permitindo melhor diviso e controle das tarefas. Abaixo temos o
organograma da equipe.

37

Diretor Geral

Gerente de
Marketing

Gerente de RH

Gerente
Financeiro

Gerente de
Projetos

Gerente de
Manufatura

Grupo
Estrutural

Grupo
Eletrnica

Grupo
Powertrain

Suspenso e
Direo

Bloco do Motor

Chassi

Arrefecimento

Compsitos

Transmisso

Freio e Base dos

Pedais

Admisso e
Exausto

Gerente de
Documentao

Figura 6 - Organograma Equipe Formula SAE

A gesto do projeto se inicia com a descrio das atividades com a construo de

uma estrutura de decomposio de tarefas (EDT), posteriormente, a gesto elabora um
cronograma para realizao das tarefas, determinando prazos e datas limites para entrega
dos produtos.
Durante a competio, cada equipe visa ter seu projeto aceito por um fabricante
fictcio. Os alunos devem trabalhar em equipe em todas as fases do projeto
(desenvolvimento, construo, testes, promoo e operao), desenvolvendo um veculo
que respeite as regras impostas pela organizao. Cabe aos alunos viabilizar e gerenciar
suporte financeiro para o projeto. Tudo deve ser feito sempre respeitando as prioridades
acadmicas.

38

2.2.3 O Projeto Eletrnica e a Equipe Eletrnica EESC/USP

Dentro do organograma exibido na Figura 6 nota-se o grupo da Eletrnica,
responsvel pelas tarefas de controle do motor, especificao e construo do chicote
eltrico, desenvolvimento do software, controle para troca de marchas eletro-pneumatico. A
equipe est subdividida conforme organograma abaixo (Figura 7).

Figura 7 - Organograma Equipe Eletrnica

A gesto dos projetos deste subgrupo est alocada e segue o mesmo conceito e
regras adotadas pela equipe como um todo. De certa forma, essa gesto tem se revelado
suficientemente eficiente, visto os resultados alcanandos pelo subgrupo nas competies,
tendo ganhado por duas vezes o prmio de inovao tcnologica. Pelo uso de telemetria em
tempo real. E, posteriormente, com o uso da comunicao entre mdulo seguindo protocolo
CAN para elaborao do sistema de aquisio de dados e telemetria.
Ao analisarmos todas as atribuies referentes a este subgrupo, notamos as
diferentes necessidades de acompanhamento, pois a gesto na engenharia de software
diferente da gesto das outras engenharias. Tais diferenas tornam esse gerenciamento um
pouco mais complicado como podemos notar na
Tabela 3.

39

Tabela 3 Diferenas Engenharia de Software x demais Engenharias

CARACTERSTICA

DESCRIO
O gerente de um projeto de construo de um navio ou de um
projeto de engenharia civil pode ver o produto que est sendo
construdo. Se o cronograma atrasa, o efeito sobre o produto

Intangilibidade do

visvel partes da estrutura estaro, obviamente, no concludas.

produto

O software intangvel. No pode ser visto ou tocado. Os gerentes

de projetos de software no podem ver o progresso. Eles contam
com outras pessoas para produzir a documentao necessria para
examinar o progresso.
Em reas da engenharia com um longo histrico, o processo
experimentado e testado. O processo de engenharia de alguns tipos
de sistema, como pontes e prdios, bem compreendido. No
entanto, os processos de software variam drasticamente de uma

Falta de processos
padro

organizao para outra. Embora nossa compreenso desses

processos tenha se desenvolvido de modo significativo nos
ltimos anos, ainda no podemos prever, confiavelmente, quando
determinado processo de software provavelmente apresentar
problemas de desenvolvimento. Isso especialmente verdadeiro
quando o projeto de software parte de um projeto mais amplo de
engenharia de sistemas.
Projetos de software de grande porte so geralmente diferentes, de
alguma forma, de projetos anteriores. Portanto, mesmo os gerentes
que tm uma grande experincia podem considerar difcil prever

Projetos nicos

problemas. Alm disso, as rpidas mudanas de tecnologia em

computadores e comunicaes podem tornar a experincia do
gerente obsoleta. As lies aprendidas em projetos anteriores
podem no ser aproveitadas em novos projetos.

40

Estas diferenas justificam os atrasos, estouros de oramento e a entrega do produto

final fora do prazo em diversos projetos de software. Os projetos inovadores de engenharia,
frequentemente, apresentam problemas com cronograma. Contando o carter inovador
presente nos sistemas de software e todas as dificuldades envolvidas, de se surpreender
que os projetos anteriores desenvolvidos pela equipe e que muitos projetos de software
sejam entregues no prazo e dentro do oramento! [2]

41

42

Captulo 3 Modelos de Relatrios Tcnicos

Esse captulo descreve os modelos para documentao tcnica do desenvolvimento
dos softwares feitos, sendo descrito a necessidade e o porqu de cada item, sendo levado
em conta o aprendizado terico e padres sugeridos ao longo do captulo 2. Ao iniciar uma
nova gesto e um novo projeto para a prxima competio, a equipe deve simular o pedido
de um cliente a um fornecedor de software, especificando todos os dados, formas e
necessidades referentes eletrnica, neste focamos a parte de aquisio de dados para
validao e desenvolvimento das partes mecnicas do prottipo.
Assim, definimos o primeiro documento a ser elaborado pela equipe, Especificao
Sistema Eletrnico FSAE a ser realizado durante a etapa de especificao do sistema de
eletrnica da equipe, listando os sensores, grandezas fsicas que devem ser obtidas, formato
de exibio na tela de monitoramento entres outras necessidades iniciais do projeto, e, um
segundo documento a ser elaborado ao termino do projeto denominado Relatrio Tcnico
Softwares em que ser relatada as etapas de especificao, projeto, testes e manuteno.
O resultado da aplicao destes modelos pode ser vistos nos anexos 1 e 2.

3.1 Especificao Sistema Eletrnica FSAE

3.1.1 Objetivo
Descrever sucintamente a finalidade do documento, isto , dizer a finalidade, metas,
comportamento e desempenho desejado do produto do trabalho.

3.1.2 Escopo do Fornecimento

Descrever o qu dever ser fornecido e o qu no ser fornecido dentro desta
especificao. Deve ser clara e abranger todos os itens de maneira mais especifica possvel,
pois quando surgirem dvidas no futuro, a gerncia deste escopo permitir garantir que o
projeto realizou todo e somente o trabalho necessrio para atingir seu objetivo.

3.1.3 Arquitetura do Sistema Eletrnico FSAE

43

Descrever uma proposta de arquitetura, em termos de mdulos (hardware), que

atenda as necessidades descritas na seo objetivo, para possibilitar o desenvolvimento dos
softwares necessrios.

3.2 Relatrio Tcnico Softwares

Este documento deve ser finalizado e entregue gerncia de projeto da equipe assim
que o software for aprovado, Tal documento poder ser usado nas provas de Design Judge e
Apresentao, com objetivo de auxiliar e agregar ao trabalho j realizado pela equipe.

3.2.1 Objetivo
Descrever sucintamente a finalidade do documento, isto , dizer a finalidade, metas,
comportamento e desempenho desejado do produto do trabalho.

3.2.2 Escopo do Fornecimento

Descrever o qu est sendo fornecido e o qu no foi fornecido dentro deste projeto
de software conforme as especificaes de software.

3.2.3 Requisitos ou Especificao de software

3.2.3.1

Estudo da Viabilidade

Como em qualquer novo processo, engenharia de requisitos tambm deve comear

com o estudo de viabilidade, cujo documento para estudo deve ser uma especificao
inicial como definida na Seo 3.1. O resultado deste estudo definir qual a melhor forma e
se a empresa deve prosseguir com a negociao. Esta atividade no se aplica diretamente s
atribuies da equipe FSAE, porm interessante o estudo devido a aplicao parcial da
teoria, onde pode ser aprovado o prosseguimento parcial da especificao incial.
Normalmente, deve-se tentar concluir um estudo de viabilidade em duas ou trs semanas
[2].
a) Viabilidade Operacional

44

Nesta seo, devem ser detalhados os estudos de viabilidade operacional

considerando as questes de recursos financeiros e humanos, de performance,
de eficincia e nvel de dificuldade de implementao.
b) Viabilidade Tcnica
uma avaliao da praticidade da soluo tcnica especfica e a
disponibilidade dos recursos tcnicos e dos especialistas.

3.2.3.2

Anlise Econmica

a) Custo de Aquisio
Descrever o custo de aquisio leva em considerao a aquisio de um
sistema em pleno funcionamento que atenda diretamente os requisitos e
necessidades levantadas nas etapas anteriores, caso em que a equipe adquire
produtos no mercado.
b) Custos para desenvolvimento
Descrever o custo de desenvolvimento deve levar em considerao a aquisio
de todos os componentes necessrios para desenvolvimento do um sistema
completo e em pleno funcionamento que atenda diretamente os requisitos e
necessidades levantadas nas etapas anteriores, caso em que a equipe
desenvolve os produtos.

3.2.3.3

Anlise de Cronograma

Deve ser elaborado um cronograma com as atividades do processo de

desenvolvimento do software contendo marcos de entregas, tarefas a serem realizadas,
diviso de trabalho na equipe e acompanhamento das atividades.

3.2.4 Projeto de Software (Cdigo)

Descrever todo o projeto de software e suas etapas como definidas abaixo

3.2.4.1

Projeto de arquitetura

Sistemas grandes so sempre decompostos em subsistemas que fornecem algum

conjunto de servios relacionados. O processo incial de projeto consiste em identificar

45

esses subsistemas e estabelecer um framework para controle e comunicao dos

subsistemas [2].

3.2.4.2

Projeto de componente

O projeto em nvel de componente para software equivalente a um conjunto de

desenhos detalhados para cada cmodo de uma casa. O projeto em nvel de componente de
software descreve completamente os detalhes internos para todos os objetos de dados locais
e detalhes algortmicos para todo o processamento que ocorre em um componente e em
uma interface que d acesso a todas as operaes do componente [5].

3.2.4.3

Projeto de estruturas de dados

O projeto de dados consiste na interpretao de objetos de dados em estruturas de

dados para os componentes de software e, quando necessrio, uma arquitetura de banco de
dados para a aplicao, organizando o arquivamento destes dados e facilitando assim uma
futura consulta e extrao do mesmo [5].

3.2.4.4

Projeto de algoritmo

O projeto de algoritmo consiste em estudo e definio das lgicas de procedimentos,

clculos, taxas de amostragem, sequenciamento, determinao da linguagem e software
para escrita do cdigo, sua respectiva organizao e documentao.

3.2.5 Testes
Descrever os mtodos e resultados obitdos durante os testes, assim como problemas
e solues encontradas.

3.2.5.1

Teste de Componente

Descrever os testes de componente individuais do sistema, expondo os defeitos

encontrados. Na maioria dos sistemas, os desenvolvedores so responsveis pelo teste de
componente.

46

3.2.5.2

Teste de Sistema

Descrever os testes de sistema realizados, teste esse que envolve a integrao de

dois ou mais sistemas que implementam funes caractersticas e, depois, o teste desse
sistema todo integrado, onde erros so encontrados e solues apontadas. A descrio
destes testes possibilitar maior facilidade para manuteno e entendimento do cdigo [5].

3.2.5.3

Teste de Aceitao

Descrever o teste de aceitao e o real funcionamento para aprovao do sistema,

descrever os pontos que devem ser corrigidos a partir da etapa de manuteno.

3.2.6 Manuteno
Descrever como as atividades de manuteno podem vir a ocorrer, quais as
possveis causas e solues para garantir manutenibilidade. As manutenes podem incluir
correes, melhorias ou adaptaes do software causada por mudanas no ambiente e nos
seus requisitos ou especificaes funcionais. (ISO/IEC 9126, 2003)
O conceito de manuteno por vezes se assimila com evoluo do software,
podendo por vezes ser considerado um novo produto, pois no estava previsto no escopo.
Dentro do projeto Formula SAE, consideraremos manuteno toda atividade realizada aps
a primeira entrega em funcionamento do projeto.

3.2.6.1

Manuteno Corretiva

Descrever todas as manutenes corretivas. Visando correo de defeitos de

software, realizadas at aceitao do software.

3.2.6.2

Manuteno Adaptativa

Descrever todas as manutenes adaptativas realizadas, visando adpatar o software

mudana de hardware, at aceitao do software.

47

48

Captulo 4 Resultados e Concluses

4.1 Concluses Gerais
Neste trabalho foi realizado o estudo para aplicao de mtodos e conceitos
pertinentes Engenharia de Software, com intuito de aplica-los nos processos
desenvolvidos pela equipe de eletrnica Frmula SAE/EESC/USP.
Tambm foi realizado um comparativo entre as atividades de gerenciamento
relacionado a projeto de carro e de software, demonstrando a real necessidade e
importncia do estudo e aplicao de Engenharia de Software nos projetos atuais em que
temos o desenvolvimento de algum software, seja ele parte ou produto nico do projeto.
A aplicao dos estudos ocorre com a determinao dos modelos apresentados no
captulo 3, que deram origem aos anexos 1 e 2 apresentados. Tal captulo apresenta de
forma sucinta os principais itens a serem descritos e observados durante o projeto de
software e sugere uma documentao apropriada visando prover informaes para todos os
futuros envolvidos no projeto Formula SAE, facilitando assim qualquer trabalho de
manuteno e/ou novos desenvolvimentos.
Portanto, considerando o carter acadmico e aplicado (profissional), percebe-se
claramente que os objetivos foram alcanados, uma vez que conceitos de engenharia de
software foram aplicados durante o projeto, isto , tarefas anteriormente executadas
voluntariamente a partir de experincias individuais passaram a ter um escopo bem
definido, que poder e dever evoluir conforme as necessidades de projeto.

4.2 Trabalhos Futuros

O projeto abre possibilidades para inmeras melhorias e revises. Logo de
princpio, os projetos devem se iniciar com algum conhecimento sobre a Engenharia de
Software e suas diversas aplicaes. Este projeto deu enfoque ao estudo inicial que ocorreu
paralelamente ao projeto de software da equipe. Desta forma, no houve, por exemplo, um
maior aproveitamento dos estudos realizados na parte de especificao de requisitos, parte
primordial para um bom resultado final. Tal etapa foi realizada nos mesmos moldes dos
projetos anteriores.

49

Um novo projeto com proposta similar ao deste poderia sugerir o uso dos modelos
apresentados para atingir nveis de exigncia dentro do padro ISO9126 de qualidade de
software, incrementando o novo conhecimento e experincia dos desenvolvedores de
software do projeto;
Pode-se tambm implementar a aplicao visando controle de custos, atravs de
apresentao de diversas propostas de arquiteturas a partir de uma especificao de
requisitos mais ricos, sendo este um trabalho que envolvesse a participao de toda equipe
responsvel

pelo projeto, fato este que no ocorreu neste estudo devido ao

desconhecimento da possibilidade de apresentaes e trabalhos de concluso de curso em

grupo.
A realizao de projetos com esta finalidade colobora para o desenvolvimento
acadmico e profissional dos envolvidos, e contempla a formao do estudante com o
entendimento da relao entre cada atividade at a entrega do produto final, alm de prover
nao, profissionais com maior conhecimento sobre engenharia de software e ajudando a
evoluo da qualidade dos softwares desenvolvidos no Brasil.

50

Bibliografia
[1] P. Naur and B. Randell, (Eds.). Software Engineering: Report of a
conference sponsored by the NATO Science Committee, Garmisch,
Germany, 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO
(1969).
[2] SOMMERVILLE, Engenharia de software, 8 edio, So Paulo: Pearson
Addison-Wesley, 2007.
[3] ISO, ISO/IEC 9126: Engenharia de software - Qualidade de produto,
2003.
[4] K. Weber, E. Arajo, A. R. Rocha, K. Oliveira, A. C. Rouiller, C. Gresse
von Wangenheim, R. Arajo, C. Salviano, C. Filipak Machado, D. Scalet,
O. Galarraga, M. Pecegueiro Amaral e D. Yoshida, Melhoria de
Processo do Software Brasileiro (MPS.BR) um Programa Mobilizador,
[Online]. Available:
http://www.softex.br/portal/softexweb/uploadDocuments/26.pdf. [Acesso
em 04 Outubro 2012].
[5] R. S. Pressman, Engenharia de Software, So Paulo: MCGRAW-HILL,
2006.
[6] SWEBOK, THE INSTITUTE OF ELECTRICAL AND ELETRONICS
ENGINEERS, INC - IEEE, GUIDE TO THE SOFTWARE
ENGINEERING BODY OF KNOWLEDGE, 2004.
[7] E. Y. Nakagawa, Uma Contribuio ao Projeto Arquitetural de
Ambientes de Engenharia de Software, So Carlos, 2006.
[8] M. M. PADUELLI, MANUTENO DE SOFTWARE: PROBLEMAS

51

TPICOS E DIRETRIZES PARA UMA DISCIPLINA ESPECFICA,

So Carlos, 2007.
[9] S. L. Pfleeger, Engenharia de Software: teoria e prtica, So Paulo:
Prentice Hahll, 2004.
[10] Formula SAE International, SAE International, [Online]. Available:
http://students.sae.org/competitions/formulaseries/about.htm. [Acesso em
03 Outubro 2012].

52

Anexo 1 Especificao Sistema Eletrnica FSAE

53

54

UNIVERSIDADE DE SO PAULO
ESCOLA DE ENGENHARIA DE SO CARLOS

EQUIPE FORMULA SAE EESC USP

Especificao Sistema Eletrnica FSAE

So Carlos
2012

55

56

Sumrio
1 Objetivo ...........................................................................................................................59
2 Escopo de fornecimento ..................................................................................................61
3 Arquitetura do Sistema Eletrnica FSAE ........................................................................63

57

58

Objetivo
Estabelecer as diretrizes e os critrios para fornecimento da plataforma de software e
aplicativos computacionais de aquisio de dados referentes ao sistema Eletrnica FSAE do
projeto Formula SAE EESC USP, prottipo com objetivo de participar da competio
universitria SAE Brasil a ser realizada em novembro de 2012 na cidade de Piracicaba-SP,
com finalidade de medio e anlise de desempenho e rendimento do prottipo.

59

60

Escopo de fornecimento

Sistema Aquisio de Dados: sistema de software em LabView que ir adquirir os

dados provenientes dos mdulos Proa e Popa e possibilitar monitor-los, gravar em
planilhas de dados e exibir em uma tela de computador de forma visual ao cliente, com
valores em km/h, m/s2, entre outros a serem detalhados (Figura 8).

Figura 8 Exemplo de tela a ser exibida pelo software Tratamento de Dados

Mdulo Popa: Sistema de software em linguagem C desenvolvido com

microcontroladores PIC18F2680 que dever aquisitar os dados de todos os sensores da
parte traseira do carro, atuar para realizao das trocas de marchas, assim como
converter os dados aquisitados em grandezas fsicas e envi-los via CAN para o mdulo
Painel
Mdulo Proa: Sistema de software em linguagem C desenvolvido com
microcontroladores PIC18F2680 que dever aquisitar os dados de todos os sensores da

61

dianteira do prottipo, comunicar com a ECM obtendo os dados desejados, convert-los

em grandezas fsicas e envi-los via CAN para o mdulo Painel
Mdulo Painel: Sistema de software em linguagem C desenvolvido com
microcontroladores PIC18F2680 com finalidade de exibir as informaes mais
relevantes ao piloto e, principalmente, enviar os dados para o transceptor, possibilitando
a captao dos dados no software Sistema Aquisio de Dados.
Mdulo ECM: Sistema de hardware e software utilizado para controle dos parmetros
necessrios para calibrao e funcionamento adequado do motor.

Figura 9 Disposio dos Mdulos

62

Arquitetura do Sistema Eletrnica FSAE

A arquitetura do Sistema Eletrnica FSAE dever ser composta pelos mdulos popa, proa,
painel e ECM (unidade de controle do motor), captando sinais dos sensores listados abaixo:

4 sensores para medir velocidade.

4 sensores de presso da linha do freio

Temperatura do ar

Presso do leo do carter

Acelermetro de 2 eixos

RPM do motor

Temperatura da gua

Tenso da bateria

Relao ar/combustvel na exausto (Sensor lambda)

Posio da borboleta (acelerador)

Presso do ar no coletor de admisso (MAP)

Curso do pedal de freio e embreagem

Curso da direo

63

64

Anexo 2 Relatrio Tcnico Softwares FSAE

65

66

UNIVERSIDADE DE SO PAULO
ESCOLA DE ENGENHARIA DE SO CARLOS

EQUIPE FORMULA SAE EESC USP

Relatrio Tcnico Software FSAE

So Carlos
2012

67

68

Lista de Figuras
Figura 10 Cronograma ....................................................................................................... 78
Figura 11 Projeto de arquitetura ........................................................................................ 78
Figura 12 - Fluxo de leitura de um dado analgico .............................................................. 79
Figura 13 - Fluxo da comunicao da ECM ......................................................................... 79
Figura 14 - Unidade de Controle do Motor (ECM) .............................................................. 80
Figura 15 - Fluxo da leitura de um dado digital (Atuadrores) .............................................. 80
Figura 16 Borboletas e vlvula solenoide para troca de marcha ...................................... 81
Figura 17 - Fluxo de leitura de um dado digital (Sensores) ................................................. 81
Figura 18 - Sensor de velocidade ......................................................................................... 82
Figura 19 - Fluxograma procedimentos programao .......................................................... 85

69

70

Lista de Tabelas
Tabela 1 - Mensagens .........................................................................................................83
Tabela 2 - Normas, resolues e intervalo dos principais dados ........................................84

71

Lista de Siglas

72

Sumrio
Lista de Figuras ................................................................................................................. 69
Lista de Tabelas ................................................................................................................. 71
Lista de Siglas.................................................................................................................... 72
Sumrio.............................................................................................................................. 73
Captulo 1 Relatrio Tcnico Softwares ......................................................................... 75
1.1

Objetivo ............................................................................................................. 75

1.2

Escopo do fornecimento .................................................................................... 75

1.3

Requisitos ou Especificao de software........................................................... 76

1.3.1

Estudo da Viabilidade.................................................................................. 76

1.3.2

Anlise Econmica ...................................................................................... 77

1.3.3

Anlise de Cronograma ............................................................................... 77

1.4

Projeto de Software (Cdigo) ............................................................................ 78

1.4.1

Projeto de arquitetura................................................................................... 78

1.4.2

Projeto de componente ................................................................................ 79

1.4.3

Projeto de estruturas de dados ..................................................................... 82

1.4.4

Projeto de algoritmo .................................................................................... 83

1.5

Testes ................................................................................................................. 85

1.5.1

Teste de Componente .................................................................................. 85

1.5.2

Teste de Sistema .......................................................................................... 85

1.5.3

Teste de Aceitao ....................................................................................... 85

1.6

Manuteno ....................................................................................................... 86

1.6.1

Manuteno Corretiva ................................................................................. 86

1.6.2

Manuteno Adaptativa ............................................................................... 86

Captulo 2 Resultados e Concluses ............................................................................... 87

2.1

Concluses Gerais ............................................................................................. 87

73

74

Captulo 1 Relatrio Tcnico Softwares

Apresentamos neste documento o desenvolvivemto e execucao do projeto dos
softwares da equipe de eletrnica FSAE relatando as atividades realizadas ao longo do
processo.

1.1 Objetivo
Este relatrio tem como objetivo iniciar uma cultura com adoao de Engenharia de
Software dentro da equipe de desenvolvedores e permitir evoluo dos mesmos e dos
softwares produzidos pela equipe, indiretamente colaborando com todo o restante da equipe
em busca dos melhores projetos e resultados nas competies.
Neste documento ser abordado o escopo do fornecimento, estudo de viabilidade,
projeto de software, testes e manuteno de modo a descrever os procedimentos realizados
pela equipe durante o projeto 2012.

1.2 Escopo do fornecimento

O projeto de desenvolvimento segue o descrito na Especificao Sistema
Eletrnica FSAE e procura atender as necessidades para desenvolvimento e evoluo dos
outros subsistemas do prottipo. A seguir est descrito os mdulos do fornecimento.
Sistema Aquisio de Dados: sistema de software em LabView que ir adquirir os
dados provenientes dos mdulos Proa e Popa e possibilitar monitor-los, gravar em
planilhas de dados e exibir em uma tela de computador de forma visual ao cliente, com
valores em km/h, m/s2, entre outros a serem detalhados.
Mdulo Popa: Sistema de software em linguagem C desenvolvido com
microcontroladores PIC18F2680 que dever aquisitar os dados de todos os sensores da
parte traseira do carro, atuar para realizao das trocas de marchas, assim como converter
os dados aquisitados em grandezas fsicas e envia-los via CAN para o mdulo Painel
Mdulo Proa: Sistema de software em linguagem C desenvolvido com
microcontroladores PIC18F2680 que dever aquisitar os dados de todos os sensores da
dianteira do prottipo, comunicar com a ECM obtendo os dados desejados, convert-los em
grandezas fsicas e envi-los via CAN para o mdulo Painel

75

Mdulo Painel: Sistema de software em linguagem C desenvolvido com

microcontroladores PIC18F2680 com finalidade de exibir as informaes mais relevantes
ao piloto e, principalmente, enviar os dados para o transceptor, possibilitando a captao
dos dados no software Sistema Aquisio de Dados.

1.3 Requisitos ou Especificao de software

1.3.1 Estudo da Viabilidade
c) Viabilidade Operacional
Disposio de apoiadores, novos e antigos, recursos financeiros, recursos
humanos, dificuldades de implementao.
Do ponto de vista financeiro, o projeto se tornou vivel devido ao apoio dos
patrocinadores. Diversas empresas forneceram gratuitamente seus produtos
para desenvolvimento do projeto.
Do ponto de vista de recursos, a equipe tem pessoal suficiente, e sempre
buscando aprender para sanar as dificuldades e eventuais problemas, uma
vez que toda ela composta por estudantes. Deve ser considerado o lado
acadmico do projeto neste estudo de viabilidade.
Do ponto de vista das dificuldades de implementao, leva-se em conta
novamente o carter acadmico da equipe e implementa-se o software
atendendo todas as necessidades descritas na especificao.
Do ponto de vista de perfomance e eficincia, projeta-se os softwares
modulares, para que o funcionamento deles seja independente.
d) Viabilidade Tcnica
Todos os requisitos so atendidos em termos tcnicos, pois possvel
alcanar e prover todas as informaes requisitados. Atenta-se tambm para
buscar contato de patrocnio com os fabricantes dos sensores necessrios para
aquisio dos dados especificados. A disponibilidade de especialista no
considerada para definio deste estudo, uma vez que existe a possibilidade de
contar com apoio de professores com qualificao para ajudar o
desenvolvimento e aprendizado dos membros da equipe de eletrnica.
76

1.3.2 Anlise Econmica

No inicio do projeto a equipe de eletrnica lista juntamente dos grupos estrutural e
powertrain os sensores necessrios. Partindo desta lista procurada as empresas fabricantes
destes sensores em busca de parcerias e posteriormente a aquisio de sensores no mercado
de acordo com as diretrizes do projeto FSAE.
c) Custo de Aquisio
Custo de aquisio leva em considerao a aquisio dos componentes
necessrios

para

montagem

de

um

sistema

completo

para

pleno

funcionamento.
Os componentes comprados foram placas de cobre, conectores, componentes
eltricos (resistores, capacitores, etc), Doados: microcontrolador, sensores,
chicote eltrico.
d) Custos para desenvolvimento
Custo de desenvolvimento leva em considerao a aquisio de todos os
componentes necessrios para desenvolvimento do um sistema.
Os componentes usados foram: softwares Altium, Mplab, Circuit CAM,
computadores, fontes de tenso, osciloscpio, protoboards, equipamentos para
soldagem.

1.3.3 Anlise de Cronograma

Elaborao de um cronograma com as atividades do processo de desenvolvimento
do software contendo marcos de entregas, tarefas a serem realizadas, diviso de trabalho na
equipe e acompanhamento das atividades, como segue na Figura 10.

77

Figura 10 Cronograma

1.4 Projeto de Software (Cdigo)

1.4.1 Projeto de arquitetura
O projeto de arquitetura leva em conta a disposio fsica dos mdulos no carro, e
diviso das tarefas para facilitar e permitir um sistema modular. Desta forma segue-se a
Figura 11 representativa da arquitetura projetada.

Figura 11 Projeto de arquitetura

78

1.4.2 Projeto de componente

A estrutura do projeto de componente descrita pelos fluxogramas a seguir,
mostrando o fluxo dos dados desde que captado no sensor at sua disponibilizao na
rede.

Figura 12 - Fluxo de leitura de um dado analgico

A Figura 12 mostra a leitura de um dado analgico, dentre eles temos presso do

freio, curso do pedal, curso da direo, curso da embreagem, presso do leo e do freio e
acelermetro, que seguem o mesmo modelo.

Figura 13 - Fluxo da comunicao da ECM

A Figura 13 mostra a ordem da comunicao com a ECM, unidade que centraliza os

dados de temperatura, uptime, tenso de bateria, TPS, RPM, sensor lambda e outros
necessrios para controle da injeo de combustvel para o motor
.
79

Figura 14 - Unidade de Controle do Motor (ECM)

Na Figura 14 tem-se a imagem da ECM utilizada pela equipe, cujo desenvolvimento

foi feito pela empresa parceira, e algumas modificaes e melhorias foram solictadas pela
nossa equipe de desenvolvimento, que podemos citar a falha de comunicao segundo o
protocolo CAN.

Figura 15 - Fluxo da leitura de um dado digital (Atuadrores)

80

A Figura 15 nos mostra o fluxo do funcionamento do sistema de troca de marchas,

desde seu acionamento pelo piloto com uso de borboletas (boto) at o acionamento
eltrico do atuador pneumtico.

Figura 16 Borboletas e vlvula solenoide para troca de marcha

As imagens da Figura 16 mostram o sistema Shifter responsvel pela troca

automatizada de marchas, em que o piloto aciona as borboletas atrs do voltante sem retirar
as mos do volante, favorecendo o melhor desempenho.

Figura 17 - Fluxo de leitura de um dado digital (Sensores)

A Figura 17 apresenta o fluxo para leitura de dados digitais para determinao da

velocidade do prottipo.

81

Figura 18 - Sensor de velocidade

Na Figura 18 encontra-se o sensor para determinar velocidade, nota-se o

desenvolvimento em conjunto com a equipe de suspenso que projetou um suporte para o
mesmo ao desenhar as mangas do prottipo.

1.4.3 Projeto de estruturas de dados

A equipe no utiliza estrutura de dados complexas, sendo utilizadas poucas
variveis comuns a todo projeto. Devido ao uso do protocolo de comunicao CAN, os
dados so divididos em mensagens as quais possuem uma tabela de identificao que
permite a qualquer mdulo, ao ler esta mensagem, saber os dados contidos na mesma.

82

Tabela 4 - Mensagens

Nome da mensagem

Nmero

MSG_POPA_DATA

31

MSG_POPA_DATA_2

33

MSG_PROA_DATA_1

67

MSG_PROA_ECMDATA1

71

MSG_PROA_ECMDATA2

73

Dados contidos
DATA[0]: Presso de Freio 3 High Bits
DATA[1]: Presso de Freio 3 Low Bits
DATA[2]: Presso de Freio 4 High Bits
DATA[3]: Presso de Freio 4 Low Bits
DATA[4]: Acelerometro CM X
DATA[5]: Acelerometro CM Y
DATA[6]: Presso do leo High Bits
DATA[7]: Presso do leo Low Bits
DATA[0]: Neutro
DATA[1]: Velocidade roda 3
DATA[2]: Velocidade roda 4
DATA[3]: Contador trocas de marcha High Bits
DATA[4]: Contador trocas de marcha Low Bits
DATA[0]: Presso de Freio 1
DATA[1]: Presso de Freio 2
DATA[2]: Curso pedal de freio
DATA[3]: Curso da direo
DATA[4]: Curso da embreagem
DATA[5]: Velocidade 1
DATA[6]: Velocidade 2
DATA[0]: Uptime High
DATA[1]: Uptime Low
DATA[2]: Temperatura ar admisso
DATA[3]: Temperatura gua motor
DATA[4]: Tenso da Bateria
DATA[5]: Status sensor de fase
DATA[0]: TPS
DATA[1]: RPM High
DATA[2]: RPM Low
DATA[3]: Lambda High
DATA[4]: Lambda Low
DATA[5]: MAP High
DATA[6]: MAP Low

1.4.4 Projeto de algoritmo

A equipe utiliza o software MPLAB IDE para codificao e gravao, sendo o
cdigo escrito em linguagem C, devido ao conhecimento adquirido em diversas disciplinas
do curso que facilita sua manipulao, e por permitir escrita, compilao e gravao em
83

um nico ambiente. Durante o desenvolvimento do cdigo existe uma grande preocupao

em coment-lo visando facilitar manutenes futuras.
A Tabela 5 mostra informaes sobre norma, resoluo e intervalo dos dados
mdulos responsveis pela aquisio:
Tabela 5 - Normas, resolues e intervalo dos principais dados

Mdulo Dado
Presso freio 1
Presso freio 2
Curso pedal de freio
Proa Curso direo
Curso embreagem
Velocidade 1

Popa

ECM

84

Norma
SAEpr16
SAEpr16
SAEpc03
SAEpc04
SAEpc03
-

Resolution
50 kPa/bit
50 kPa/bit
0,4 %/bit, 0 offset
0,8%/bit, 0 offset
0,4 %/bit, 0 offset
0,2 m/s per bit, 0 m/s offset

Data range
0 to 12,5 MPa
0 to 12,5 MPa
0 to 100 %
-100% to 100%
0 to 100 %
0 to 51 m/s

Velocidade 2
Presso leo
Presso freio 3
Presso freio 4
Troca de marchas

SAEpr11
SAEpr16
SAEpr16
-

0 to 51 m/s
0 to 1,25 MPa
0 to 12,5 MPa
0 to 12,5 MPa
0 a 65535 trocas

Acelermetro X

SAEac02

Acelermetro Y
Velocidade 3

SAEac02
-

0,2 m/s per bit, 0 m/s offset

5 kPa/bit
50 kPa/bit
50 kPa/bit
1 troca/bit
0,1 m/s per bit, -12,5 m/s
offset
0,1 m/s per bit, -12,5 m/s
offset
0,2 m/s per bit, 0 m/s offset

Velocidade 4
Uptime
Temp. ar admisso
Temp. gua motor
Tenso bateria
Status sensor de fase
TPS
RPM
Lambda

SAEtm06
SPN 105
SPN 110
SAEr03
SPN 51
SAEr01

0,2 m/s per bit, 0 m/s offset

1 s/bit
1 deg C/bit, -40 deg C offset
1 deg C/bit, -40 deg C offset
0,1V/bit, 0 offset
1/bit
0,4 %/bit, 0 offset
1 rpm/bit
0,001/bit

0 to 51 m/s
0 to 65535 s
-40 to 210 deg C
-40 to 210 deg C
0 to 25,5V
0 to 255
0 to 100 %
0 to 65535 rpm
0 to 65,535

MAP

SAEpr03

0,1 kPa/bit

0 to 6425,5 kPa

-12.5 to +12.5 m/s

-12.5 to +12.5 m/s
0 to 51 m/s

Segue fluxograma dos procedimentos realizados para leitura, tratamento e clculos e

disponibilizao na rede.

Figura 19 - Fluxograma procedimentos programao

1.5 Testes
1.5.1 Teste de Componente
Descrevemos os testes dos componentes individuais do sistema, expondo os defeitos
encontrados.
ECM falha de comunicao e tratamento de dados.
ECM no permitia corte de centelha para troca de marchas.
Os outros componentes no apresentaram falhas individuais durante os testes.

1.5.2 Teste de Sistema

Teste de comunicao e teste entre os mdulos para integrao do sistema. Foi
encontrada uma falha na comunicao entre os mdulos PROA e ECM. Este no respondia
requisio de transmisso de dados que aquele enviava.

1.5.3 Teste de Aceitao

O teste de aceitao foi realizado antes do lanamento do prottipo, realizado no dia
08 de Agosto, atendendo requisitos mnimos de funcionamento, como controle do motor e
sensoriamento parcial. Desta forma, as atividades corretivas e adaptativas realizadas a fim
de alcanar a especificao inicial encontra-se descrita nas atividades de manuteno.

85

1.6 Manuteno
Descrevemos aqui as atividades de manuteno realizadas durante a implementao
do projeto de software, de forma a contemplar a documentao, auxiliando manutenes e
entendimento futuro deste projeto.
Dentro deste projeto Formula SAE, consideraremos manuteno toda atividade
realizada aps a primeira entrega em funcionamento de cada sistema.

1.6.1 Manuteno Corretiva

Durante implementao do software feito pela equipe, detectou-se problemas neste.
A partir disto, foram feitas correes no prprio software a fim de sanar os problemas
detectados. Por exemplo, quando foi requerido o envio de um sinal booleano (0 ou 1)
dependente da deteco de um valor especfico de um sensor.

1.6.2 Manuteno Adaptativa

No mdulo PROA havia um C.I. MAX232 para comunicao serial e foi retirado

86

Captulo 2 Resultados e Concluses

2.1 Concluses Gerais
A elaborao deste projeto colaborou com o desenvolvivemento da documentao e
organizao do mesmo, assim como permitiu a evoluo do grupo de desenvolvedores. Esta
documentao contribuir para futuros trabalhos de manuteno e novos desenvolvimentos.
Aprendemos com a confeco do mesmo que os trabalhos de manuteno e teste
podem ser realizados com maior foco, contendo mais informaes e descrevendo melhor
cada mtodo seguido pelos desenvolvedores independemente dos resultados alcanados.
Tal documentao poderia ser usado como manual de procedimentos para projeto de
software.
A execuo do projeto atingiu a maior parte dos objetivos, permitindo a evoluo
dos outros subsistemas com os resultados captados durante os testes do prottipo.

87