Aplicação Do Método de Desenvolvimento Baseado em Modelos para Uma Função de Software Automotivo

UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN
DEPARTAMENTO DE ELETRNICA
ENGENHARIA ELETRNICA
JOO HENRIQUE ZANDER NEME
APLICAO DO MTODO DE DESENVOLVIMENTO BASEADO EM

MODELOS PARA UMA FUNO DE SOFTWARE AUTOMOTIVO:
SISTEMA DE ILUMINAO EXTERNA
PONTA GROSSA
2014
APLICAO DO MTODO DE DESENVOLVIMENTO BASEADO EM

MODELOS PARA UMA FUNO DE SOFTWARE AUTOMOTIVO:
SISTEMA DE ILUMINAO EXTERNA
Trabalho de Concluso de Curso
apresentado como requisito parcial
obteno do ttulo de Bacharel, em
Engenharia Eletrnica, do Departamento
de
Eletrnica,
da
Universidade
Tecnolgica Federal do Paran.
Orientador: Prof. Dr. Max Mauro Dias
Santos
PONTA GROSSA
2014
Ministrio da Educao
Universidade Tecnolgica Federal do Paran
Ponta Grossa
Departamento de Eletrnica
Engenharia Eletrnica
TERMO DE APROVAO
APLICAO DO MTODO DE DESENVOLVIMENTO BASEADO EM MODELOS
PARA UMA FUNO DE SOFTWARE AUTOMOTIVO: SISTEMA DE ILUMINAO
EXTERNA
por
Este Trabalho de Concluso de Curso foi apresentado em 17 de Dezembro de 2014
como requisito parcial para a obteno do ttulo de Bacharel em Engenharia
Eletrnica. O candidato foi arguido pela Banca Examinadora composta pelos
professores abaixo assinados. Aps deliberao, a Banca Examinadora considerou
o trabalho aprovado.
__________________________________
Dr. Max Mauro Dias Santos
Prof. Orientador
___________________________________
Dr. Sergio Luiz Stevan Junior
Prof. Co-Orientador
___________________________________
Dr. Claudinor Bitencourt Nascimento
Membro titular
___________________________________
Dra. Fernanda Cristina Correa
Membro titular
- O Termo de Aprovao assinado encontra-se na Coordenao do Curso -
AGRADECIMENTOS
A esta universidade, seu corpo docente, direo e administrao que

oportunizaram o apoio e estrutura necessria para adquirir conhecimentos
necessrios para desenvolver este trabalho.
Ao meu orientador Max Mauro Dias Santos pelo suporte e ensinamentos
durante todo este processo.
Aos meus pais, pelo amor, incentivo e suporte necessrio para que este
trabalho fosse possvel.
A Fernanda, minha noiva e futura esposa, por ser a razo e inspirao para
que eu sempre busque ser uma pessoa melhor e mais capacitada.
A Letcia, minha cunhada, pelas consultorias de normas e metodologias.
A Deus por ter me dado sade e fora para superar as dificuldades.
E a todos os colegas e amigos que direta ou indiretamente fizeram parte da
minha formao, o meu muito obrigado.
RESUMO
NEME, Joo Henrique Zander. Aplicao do Mtodo de Desenvolvimento

Baseado em modelos para uma Funo de Software Automotivo: Sistema de
Iluminao Externa. 2014. 60 folhas. Trabalho de Concluso de Curso (Bacharelado
em Engenharia Eletrnica) - Universidade Tecnolgica Federal do Paran. Ponta
Grossa, 2014.
A demanda por sistemas embarcados cresce exponencialmente. Na rea automotiva

a procura por estes sistemas para controlar funcionalidades de eltrica e eletrnica
cresce do mesmo modo. Este fato impulsiona a complexidade do desenvolvimento
destes sistemas. O mercado automobilstico um setor agressivo, que cobra
constante melhoria e diminuio de gastos com recursos. Este trabalho busca
analisar o desenvolvimento baseado em modelos aplicando mtodos como Modelin-the-Loop, Software-in-the-Loop e Rapid Control Prototyping e comprovar a
eficcia destes mtodos no objetivo de desenvolver softwares automotivos de
maneira mais eficiente e utilizando menos recursos.
Palavras-chave: Desenvolvimento Baseado em Modelo. Desenvolvimento de
Softwares Automotivos. Model-in-the-Loop. Software-in-the-Loop. Rapid Control
Prototyping.
ABSTRACT
NEME, Joo Henrique Zander. Model Based Design for Automotive Software
Function: External Lighting System. 2014. 60 pages. Trabalho de Concluso de
Curso (Bacharelado em Engenharia Eletrnica) - Federal Technology University Parana. Ponta Grossa, 2014.
The demand for embedded systems grows exponentially. In the automotive area, the
demand for these systems to control electric and electronic features is growing in the
same way. This fact drives the complexity of the development of these systems. The
automotive industry operates in an aggressive market, obliging suppliers to align its
quality strategy to constant improvement. This paper analyzes Model Based Designs
methods, such as Model-in-the-Loop, Software-in-the-Loop and Rapid Control
Prototyping to prove the effectiveness of these methods in order to develop
automotive software more efficiently and using fewer resources.
Keywords: Model Based Design. Development of Automotive Software. Model-inthe-Loop. Software-in-the-Loop. Rapid Control Prototyping.
LISTA DE ILUSTRAES
Figura 1 - Crescente demanda por componentes eltricos, eletrnicos e software
para veculos automotores...................................................................................11
Figura 2 - ECUs automotivas......................................................................................18
Figura 3 - Sequncia de desenvolvimento de software automotivo...........................19
Figura 4 - Exemplo de diagrama do modelo em V.....................................................20
Figura 5 - Mtodo de desenvolvimento tradicional.....................................................23
Figura 6 - Desenvolvimento Baseado em Modelo (MBD).........................................24
Figura 7 - Sequncia de mtodos para verificao de sistema embarcado..............26
Figura 8 - Workflow para o MIL demonstrando telas genricas dos programas
utilizados..............................................................................................................27
Figura 9 - Workflow para o SIL demonstrando telas genricas dos programas
utilizados..............................................................................................................28
Figura 10 - Workflow para o PIL demonstrando telas genricas dos programas
utilizados e imagens ilustrativas das plataformas...............................................29
Figura 11 - Workflow para o HIL demonstrando telas genricas dos programas
utilizados e imagens ilustrativas das plataformas...............................................30
Figura 12 - Plataforma de hardware MicroAutoBox, da empresa dSpace..............32
Figura 13 - Comparao do desenvolvimento tradicional com o desenvolvimento do
Rapid Control Prototyping....................................................................................32
Figura 14 - Estratgia de controle e estgios de verificao......................................33
Figura 15 - Sequncia de desenvolvimento deste trabalho e ferramentas utilizadas
durante o processo..............................................................................................34
Figura 16 - Sistema externo de iluminao automotivo..............................................36
Figura 17 - Circuito para a luz indicadora de direo.................................................38
Figura 18 - Diagrama de blocos de uma BCM............................................................40
Figura 19 - Arquitetura funcional do sistema com as entradas de teste criadas para
validao..............................................................................................................42
Figura 20 - Disposio dos subsistemas todos os sistemas de iluminao...............42
Figura 21 - Diagrama Stateflow para a lgica das luzes de posio.......................45
Figura 22 - - Diagrama Stateflow para controlar o funcionamento da luz baixa......46
Figura 23 - Diagrama Stateflow referente a luz alta.................................................47

Figura 24 - Diagrama Stateflow referente a luz de freio..........................................48
Figura 25 - Diagrama Stateflow referente a luz de pisca direito..............................49
Figura 26 - Diagrama Stateflow referente a luz de pisca esquerdo.........................50
Figura 27 - Diagrama Stateflow referente a luz de r..............................................51
Figura 28 - Diagrama Stateflow referente a posio da chave de ignio..............52
Figura 29 - Sinais de entradas utilizados para o caso de teste..................................53
Figura 30 - Entradas para a posio da chave de ignio.........................................54
Figura 31 - Entrada de teste referente ao nvel de bateria.........................................54
Figura 32 - Imagem da S-Function gerada a partir do modelo inicial.........................56
Figura 33 - Entradas para a posio da chave de ignio.........................................57
Figura 34 - Ligaes feitas entre o MABX e a DAQ...................................................58
Figura 35 - Fluxo de trabalho desenvolvido para o RCP............................................58
Figura 36 - Entradas criadas para o caso de teste do RCP.......................................59
Figura 37 - Entradas relevantes para o funcionamento do sistema...........................60
Figura 38 - Comparao das entradas do modelo e as sadas verificadas nos scopes
.............................................................................................................................61
Figura 39 - Quadro comparativo entre as sadas da fase MIL com as da fase SIL. . .64
Figura 40 - Comparao dos sinais de entrada e sada para o RPC.........................65
LISTA DE SIGLAS E ACRNIMOS
LISTA DE SIGLAS
BCM
CCM
CTM
EBCM
ECU
ECM
E/E
GEM
ICM
IPC
MABX
MBD
PCM
RCP
SCM
TCM
TCU
UPA
Body Control Module

Central Control Module
Central Time Module
Electronic Brake Control module
Electronic Control Unit
Engine Control Module
Eltrica e Eletrnica
General Electronic Module
Intrsument Control Module
Instrument Panel Control
MicroAutoBox
Model Based Design
Powertrain Control Module
Rapid Control Prorotyping
Suspension Control Module
Transmission Control Module
Transmission Control Unit
Ultrasonic Park Assis
LISTA DE ACRNIMOS
HIL
MIL
OEM
PIL
SIL
Hardware-in-the-Loop
Model-in-the-Loop
Original Equipment Manufacturer
Processor-in-the-Loop
Software-in-the-Loop
SUMRIO
INTRODUO ........................................................................................
1
TEMA .......................................................................................................
1.1
1.1.
1
Delimitao do Tema ...............................................................................

PROBLEMA .............................................................................................
1.2
OBJETIVOS .............................................................................................
1.3
1.3.
1
1.3.
2
Objetivo Geral ..........................................................................................

Objetivos Especficos ..............................................................................
JUSTIFICATIVA .......................................................................................
1.4
MTODO DA PESQUISA ........................................................................
1.5
DESENVOLVIMENTO .............................................................................
2
2.1
V-MODEL
PARA
DESENVOLVIMENTO
DE
SOFTWARE
AUTOMOTIVO .........................................................................................
SISTEMA EXTERNO DE ILUMINAO AUTOMOTIVO ........................
2.2
2.3
ARQUITETURA ELTRICA DO SISTEMA DE ILUMINAO

EXTERNA
CONTROLE ELETRNICO DE BODY CCONTROL MODULE ..............
2.4
3
3.1
MODEL BASED DESIGN OU DESENVOLVIMENTO BASEADO EM

MODELO .................................................................................................
DESENVOLVIMENTO TRADICIONAL VERSUS MODEL BASED
DESIGN ...................................................................................................
MTODOS DE TESTE PARA MBD ........................................................
3.2
RAPID CONTROL PROTOTYPING ........................................................
3.3
3.4
3.4.
1
3.4.
2
3.4.
3
MODEL-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE

ILUMINAO AUTOMOTIVO .................................................................
Definio dos Requisitos .........................................................................
Projeto do Controlador Baseado em Eventos .........................................
Caso de teste ...........................................................................................
SOFTWARE-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE
1
0
1
2
1
2
1
3
1
3
1
3
1
3
1
4
1
4
1
6
1
9
2
1
2
4
2
5
2
7
2
8
3
0
3
3
3
7
3
7
3
8
4
5
4
3.5
3.6
ILUMINAO
AUTOMOTIVO
..................................................................
RAPID CONTROL PROTOTYPING PARA UM SISTEMA EXTERNO
DE
ILUMINAO
AUTOMOTIVO ..................................................................
RESULTADOS ........................................................................................
6
4
8
5
2
MODEL-IN-THE-LOOP ............................................................................ 5
4.1
2
SOFTWARE-IN-THE-LOOP .................................................................... 5
4.2
4
RAPID
CONTROL 5
4.3
PROTOTYPING .........................................................
5
CONCLUSO .......................................................................................... 5
5
7
REFERNCIAS .................................................................................................. 5
9
ANEXO A - Cdigo em C gerado para a S-Function do SIL .......................... 6
1
4
10
1 INTRODUO
Atualmente praticamente impossvel imaginar um mundo sem sistemas
embarcados, principalmente para controle de sistemas mecatrnicos. Eles esto
presentes em toda a variedade de produtos, como utilidades domsticas, sistemas
complexos de transporte e at em equipamentos militares. Segundo Holtmann
(2011), a parte funcional destes sistemas, que realizada por software tem crescido
constantemente.
Para o domnio de aplicao automotivo, sistemas de controle embarcados
so atualmente o foco principal de inovaes e melhoria na qualidade destes
produtos. Isto se d em funo da crescente demanda dinmica dos atores deste
mercado
Este uso intensivo de componentes eltricos e eletrnicos na indstria
automotiva tem impulsionado inovaes no desenvolvimento e produo que visam
diminuir custos, tempo de produo e melhorando a qualidade do produto final,
proporcionando maior conforto e segurana. Consequentemente, os engenheiros
tm trabalhado para aumentar a funcionalidade destes elementos de eletrnica em
substituio a sistemas mecnicos.
A primeira
mudana
significativa
desta
migrao
de
componentes
mecnicos, hidrulicos e pneumticos por componentes eltricos e eletrnicos

observada por um estudo feito por MERCER et al. (2011 apud BROY, 2004). O
estudo foca a questo de como os fatores de custo no desenvolvimento de um
veculo iro mudar at o ano de 2015 em comparao ao ano de 2002. Em 2015,
prev-se que, dos custos totais envolvidos em um produto automotivo, 35% sero
destinados a componentes de eltrica e eletrnica. Prev-se ainda que enquanto o
custo relativo a funes de motorizao dos carros ter um pequeno aumento, os
custos relacionados com funes eltricas e eletrnicas triplicar.
Segundo PLOSS (2008) de 1997 a 2008 a produo de veculos aumentou
44%, enquanto que a utilizao de elementos de eletrnicos (E/E) cresceu 155% e
de semicondutores 355%. A figura 1 demonstra que em 2008 o gasto com sistemas
que utilizam semicondutores era de 320 dlares, e uma estimativa diz que em 2020
este valor subir para 700 dlares.
11
Figura 1 - Crescente demanda por componentes eltricos, eletrnicos e software para veculos
automotores
Fonte: PLOSS (2008)
O motivo destas mudanas se faz em funo do menor custo, tamanho e

maior desempenho que os componentes eltricos e eletrnicos alcanam,
possibilitando a sua melhor aplicao no controle de sistemas mecatrnicos. O
contedo dos sistemas de software embarcado em automveis cresceu rapidamente
nos ltimos anos em funo da insero de componentes que implementam funes
eltricas e eletrnicas.
No domnio automotivo os subsistemas automotivos so gerenciados por
unidades de controle eletrnicas denominadas simplesmente por ECU (Electronic
Control Unit). Tem-se assim que um veculo, que um conjunto de subsistemas,
possui diversos tipos de ECUs capazes de gerenciar funes como controle do
motor, transmisso, carroceria, entre outros. Para o gerenciamento de cada um
destes subsistemas as ECUs so nomeadas de acordo com o propsito de controle,
sendo ECM (Engine Control Module) para gerenciamento do motor, TCM
(Transmission Control Module) para a transmisso, BCM (Body Control Module) para
a carroceria, ICM (Instrument Control Module) para o painel de instrumentos, entre
outros.
12
Deve-se considerar que o software parte integrante essencial de um

sistema mecatrnico para o qual considerado como um componente de
desenvolvimento, produo e servios.
A engenharia de software automotiva consiste na adoo de mtodos,
processos, ferramentas e padronizaes adequados que assegurem aos produtos
automotivos um nvel de qualidade, confiabilidade, segurana, satisfao as
regulamentaes e conforto, perceptveis e mensurveis aos clientes e todos
envolvidos no processo.
Este processo consiste em trs etapas, sendo: desenvolvimento; produo e
servios. Para o caso de sistemas embarcados automotivos, levou-se em
considerao apenas o processo de desenvolvimento de software de controle
especficos.
Este trabalho tem como objetivo investigar e apresentar resultados ao nvel
de engenharia de software automotivo utilizando metodologias, processos,
ferramentas e padronizaes adequados, de modo a demonstrar como possvel
desenvolver e testar uma funo de software embarcado automotivo.
Para isso sero explorados os mtodos aplicados atualmente para o
desenvolvimento de softwares para a rea automotiva, como a metodologia de
desenvolvimento baseado em modelo (Model Based Design, MBD), e utilizando para
isso ferramentas computacionais especficas. Tem-se como objetivo final demonstrar
o valor destes mtodos e ferramentas em um processo complexo e de dispendioso.
1.1 TEMA
O presente trabalho aborda o projeto de desenvolvimento baseado em
modelo de um sistema de iluminao externa de um veculo. Desta forma, busca-se
destacar a potencialidade dos mtodos e ferramentas envolvidas no processo,
proporcionando aos interessados a capacidade de compreenso deste assunto.
Este tema
foi considerando por existir poucas referncias bibliogrficas com
descritivos simples funcionais e objetivos.
13
1.1.1 Delimitao do Tema

Neste trabalho aplicada a metodologia de desenvolvimento baseado em
modelo, o qual em ingls conhecido como Model Based Design (MBD). A
metodologia
MDB
consiste
na
utilizao
de
modernas
ferramentas
de
desenvolvimento grfico para modelar o sistema fsico a ser controlado. Desta forma
pode-se desenvolver a estratgia de controle fazendo uso de testes virtuais nas
fases preliminares do projeto. O desenvolvimento da estratgia de controle virtual
em ferramentas computacionais possibilita posteriormente a gerao de cdigo
automtico de forma que se possa embarcar em um sistema final.
Desta maneira no necessrio se preocupar em desenvolver o
funcionamento do sistema de maneira textual e com codificao manual, algo que
pode consumir muito tempo e recursos. Ao contrrio, todo o funcionamento pode ser
idealizado de maneira grfica e atravs de diagramas de blocos, que resultam em
uma interface muito mais fcil de ser utilizada.
Estes modelos so desenvolvidos em ferramentas de software especficas e
podem ser facilmente simuladas sem necessariamente testar em uma plataforma
fsica. Na abordagem tradicional, os testes e simulaes do cdigo eram
complicados e por vezes impossveis e principalmente podiam gerar muitos erros.
Em busca deste objetivo, este trabalho ser balizado pela abordagem do
MDB, para desenvolver e testar a funo desejada, considerando dois mtodos
tradicionais de verificao de sistemas, Model-in-the-Loop (MIL) e Software-in-theLoop (SIL). Para tambm validar a funo ser realizado o Rapid Control Prototyping
(RCP) que permite que a validao seja feita em um hardware, com uma mquina
em tempo real. Com o RCP possvel verificar como as interfaces e a dinmica da
funo se comportam no mundo externo. O mtodo de RCP desenvolvido foi o de
fullpass, que utiliza a mquina de prototipagem para substituir a ECU de maneira
completa, ao contrrio do modo bypass que utilizado para substituir apenas partes
individuais da ECU.
Estas abordagens apresentam inmeras vantagens para o projeto. No caso
do MIL e SIL, como todo o processo se baseia na modelagem grfica do
funcionamento do software em contraste com o modo textual de programao, h
14
uma economia enorme de tempo e recursos. Do mesmo modo, com o RCP existe
tambm grande economia de tempo que normalmente gasto para o
desenvolvimento do cdigo a ser embarcado em um hardware para a validao. O
RCP permite que um modelo seja diretamente embarcado em uma plataforma a fim
de ser verificado.
Para o desenvolvimento destes modelos sero utilizadas ferramentas
especficas. No caso do MIL e SIL sero utilizadas as ferramentas da MathWorks
Matlab/Simulink e Stateflow. O Stateflow um ambiente de simulao de
decises combinacionais e sequenciais baseadas em mquinas de estados e
fluxogramas. Para a realizao do RCP ser utilizado alm destes programas o
LabVIEW da National Instruments para simular as entradas de testes desta fase.
Durante o processo foi tambm utilizada a ferramenta da dSpace chamada Control
Desk que auxiliou na verificao dos modelos desenvolvidos.
1.2 PROBLEMA
Atualmente
existe
uma
ampla
utilizao
de
sistemas
embarcados
automotivos. O nvel e volume de novas funes automotivas esto em crescimento

e com isso a complexidade segue o mesmo caminho O conhecimento e maturidade
de mtodos, processos e ferramentas adequados, so fatores diferenciais a este
domnio de aplicao.
Desta forma a metodologia MBD extensivamente utilizada para
desenvolvimento de software automotivo. No cenrio nacional no existem
referncias que possam proporcionar pesquisas e desenvolvimento nesta rea. Isto
se deve devido ao fato de existem poucos profissionais que conheam totalmente
este assunto. Isto tudo torna-se um motivador para o desenvolvimento deste
trabalho.
1.3 OBJETIVOS
15
1.3.1 Objetivo Geral

Desenvolver uma estratgia de controle baseada em eventos para o sistema
de iluminao externa automotivo usando as metodologias de desenvolvimento
baseadas em modelo (MBD) e seguindo o mesmo fluxo de trabalho e fazendo uso
de ferramentas que so utilizadas por empresas e fornecedores atualmente.
1.3.2 Objetivos Especficos
Estabelecer o fluxo de trabalho e as ferramentas computacionais
necessrias para desenvolvimento de funo para software automotivo.

Definir os requisitos de funcionamento do sub sistema de controle.
Modelar e simular a planta fsica a controlar.
Desenvolver a estratgia de controle baseada em eventos.
Definir o conjunto de testes para validar os requisitos.
Aplicar as fases de MIL, SIL e RCP.
Confrontar os sinais de teste e as respostas esperadas.
Apresentar a gerao do cdigo em linguagem C automaticamente.
1.4 JUSTIFICATIVA
O setor automobilstico extremamente dinmico e exigente. De um lado o
consumidor procura cada vez mais melhorias em conforto, segurana, qualidade e
tecnologia fazendo com que o ciclo de vida dos sistemas embarcados seja curto e a
complexidade aumente.
Por outro lado a indstria pressiona desenvolvedores e fornecedores pela
diminuio de custos e tempo de trabalho para conseguir manter-se neste mercado
dinmico e agressivo alm de ter que satisfazer as restries de regulamentao.
Com o aumento constante na demanda de automveis, a necessidade de que a
produo aumente concomitantemente mandatria.
O desenvolvimento de softwares automotivos utiliza mtodos, conceitos e
ferramentas especficas que so definidas por grandes grupos formados por
montadoras e seus fornecedores. Porm, estes conceitos e conhecimentos vm
para nosso pas com determinada limitao e atraso, visto que os veculos com
16
elevado nvel de contedos eletroeletrnico ainda so desenvolvidos, fabricados e

consumidos fora de nosso territrio nacional. Justificado pelo no atendimento a
demanda de conhecimento em que estes produtos requerem de profissionais.
Desta forma, temos assim um motivador para desenvolver trabalhos na rea
de desenvolvimento em engenharia de software automotiva com intuito em reduzir
esta defasagem tecnolgica ao mximo, melhorando e equalizando a mo de obra
nacional ao nvel internacional de forma competitiva, com benefcios considerveis e
mensurveis no contexto mercadolgico regional e nacional.
1.5 MTODO DA PESQUISA

Trata-se de um projeto que prope o desenvolvimento de uma funo de
software para um sistema de iluminao externo de um automvel atravs de
mtodos e ferramentas adequadas e padronizadas.
Inicialmente sero definidos os requisitos para a funo de controle, para
isso ser analisado as necessidades do usurio. Depois de mapeadas as
coordenadas do projeto ser iniciada a modelagem do sistema fsico a controlar. O
passo seguinte ser o desenvolvimento do controlador para toda a planta. Para
tanto, sero utilizadas ferramentas computacionais especficas da MathWorks, como
o Matlab/Simulink, Stateflow e LabVIEW
Aps esta etapa sero definidos sinais de entrada para todas as etapas, de
modo a poder simular e observar os sinais de sada de cada caso do sistema de
controle. Estes sinais no sero gerados aleatoriamente, como alguns tero seu
funcionamento interligado, estes sinais de entrada sero idealizados de modo a
comprovar que no h nenhum erro de lgica no desenvolvimento do modelo.
Inicialmente
estas
entradas
de
teste
sero
utilizadas
no
modelo
desenvolvido no Simulink, para verificar a etapa de MIL. Em seguida, a fase de SIL,

consiste em utilizar este modelo do Simulink para gerar automaticamente o cdigo
em linguagem C. Utilizando as mesmas entradas de testes sero ser feita a
verificao do funcionamento do cdigo. A fase de RPC ser executada embarcando
o cdigo diretamente em um hardware denominado MicroAutoBox (MABX) da
17
dSpace. Novamente exatamente as mesmas entradas de teste sero utilizadas,

desta vez no MABX, de modo a verificar a estratgia de controle.
2 DESENVOLVIMENTO
Nesta seo, sero abordados alguns conceitos relevantes e fundamentais
ao desenvolvimento da pesquisa em relao s tecnologias envolvidas, explorando
metodologias, equipamentos, componentes e tambm softwares utilizados.
Os sistemas eletrnicos automotivos consistem em diversas ECUs, as quais
controlam subsistemas automotivos, que so interligados atravs de sistemas com
barramentos
de
comunicao,
satisfazendo
uma
arquitetura
computacional
distribuda. Um sistema de computao distribudo uma arquitetura caracterizada

pela descentralizao de funes. Estas funes trocam informaes dentro do
barramento de comunicao atravs de mensagens, sendo que cada um destes
sistemas computacionais suporta funes de controle embarcado especficas.
Os tipos de ECUs, genericamente falando, incluem o mdulo de
gerenciamento do motor (ECM), mdulo de gerenciamento de
powertrain
(Powertrain control module, PCM), mdulo de gerenciamento da transmisso

(Transmission control unit, TCU), mdulo de controle do freio (Electronic Brake
Control Module, EBCM), mdulo de controle central (Central Control Module, CCM),
mdulo de sincronismo central (Central Timing Module, CTM), mdulo eletrnico
geral (General Electronic Module, GEM), mdulo de controle do da carroceria (Body
Control Module, BCM), o mdulo de controle de suspenso (Suspension Control
Module, SCM), mdulo de assistncia ao estacionamento (Ultrasonic Park Assist,
UPA), unidade de controle, ou controle de mdulo, entre outros. De forma conjunta,
estes sistemas so muitas vezes referidos como o sistema computacional do
veculo. Uma ECU automotiva genericamente formada pelos seguintes elementos:
Interfaces de Entrada (Sensores e Entradas de comunicao): Os sensores

capturam continuamente parmetros significantes na forma de variveis fsicas ou
estados tais como velocidade do motor, velocidade do veculo ou temperatura e
converte-os para um valor eltrico correspondente; As entradas de comunicao
so interfaces padronizadas que recebem frames de dados e controle de
protocolos que contm sinais de grandezas fsicas e estados.
18
Software de Controle: Baseado nas informaes de entrada, um algoritmo ou

estratgia de controle implementado em software determina a ao que precisa
ser realizada controlando ou regulando as sadas do veculo;

Interfaces de Sada (Atuadores e Sadas de comunicao): As interfaces de sada
controlam os atuadores para realizar uma ao de controle determinada pela
malha de controle implementada no software executado sob o micro controlador
dentro da ECU; As sadas de comunicao so interfaces padronizadas que
transmitem frames de dados e controle de protocolos que contm sinais de
grandezas fsicas e estados relacionados ao sistema a controlar.
Para o projeto de arquitetura eltrica e eletrnica distribuda automotiva,
existe uma forte separao entre o sistema lgico funcional e o sistema fsico, onde o
sistema funcional abstrai qualquer aspecto fsico e foca puramente sob as
dependncias lgicas entre as funes de um veculo.
A Figura 2 apresenta de forma ilustrativa alguns exemplos de ECUs
automotivas que so empregadas em veculos, tais como o mdulo de controle do
motor ou PCM
(Powertrain Control module), mdulo eletrnico geral ou GEM
(General Electronic module), mdulo de controle de carroceria ou
BCM (Body
Control Module), mdulo de controle do painel de instrumentos ou IPC (Instrument

Panel Control) e a unidade de assistncia de estacionamento ou UPA (Univesal Park
Assist).
.
19
Figura 2 - ECUs automotivas

Fonte: Elaborado pelo Autor(2014)
A abstrao da forma e caractersticas do hardware (ex.: ECUs, sistema de

comunicao, etc) so fatores importantes de forma que possa proporcionar ao
projetista a capacidade de mapear aquelas funes definidas preliminarmente em
entidades executveis sob as entidades computacionais fsicas (ECUs distribudas)
e determinam assim as caractersticas da rede de comunicao e hardware
envolvidos. Tem-se assim a necessidade em caracterizar:
Mapeamento das ECUs sob a arquitetura eltrica;

Descrio da especificao tcnica do componente (ECM, EBCM, IPC,
BCM, etc.);
Determinao das relaes de comunicao entre as ECUs (ex.:
especificao do dicionrio de dados);

Especificaes de diagnsticos das ECUs.
A Figura 3 apresenta a sequncia de desenvolvimento de software

embarcado automotivo, em que a partir da parte superior tem-se inicialmente a
determinao dos subsistemas que compe um funo global do veculo, em
seguida definio das funes que sero distribudas e por ltimo como so
descritas em tarefas de forma que possam ser alocadas e executadas fisicamente
em ECUs distribudas.
20
Figura 3 - Sequncia de desenvolvimento de software automotivo

Fonte: Elaborado pelo Autor (2014)
Foi assim apresentada uma viso geral de sistemas eletroeletrnico

automotivos de forma genrica com o intuito de ilustrar como a engenharia de
software automotivo empregada e possui diversos desafios para investigao
futura. A seguir apresentado o tradicional mtodo de desenvolvimento de software
embarcado automotivo V-Model.
2.1 V-MODEL PARA DESENVOLVIMENTO DE SOFTWARE AUTOMOTIVO

O desenvolvimento de software embarcado automotivo sob uma Arquitetura
Eltrica e Eletrnica (E\E) baseado na metodologia de desenvolvimento V-Model,
que j possui considervel grau de maturidade. A especificao definida em
conjunto e coordenadamente entre as matrizes dos fabricantes originais de
equipamentos (Original Equipment Manufacturer ou OEMs), fornecedores e
fornecedores de ferramentas.
A Figura 4 apresenta as atividades, fluxo e responsabilidade do ciclo de
desenvolvimento em V-Model.
21
Figura 4 - Exemplo de diagrama do modelo em V

A composio da metodologia V-Model pode ser explicada observando seu

ciclo de desenvolvimento na figura 4. Do lado esquerdo so definidos os requisitos,
especificaes, projeto e implementao e na parte direita tem-se os testes para
verificao e validao de componentes, sistemas e contedos, que podem ser
utilizados durante todas as etapas de desenvolvimento. O processo tem como
obetivo enfatizar a qualidade e o controle do software de forma a detectar erros
antecipadamente.
Analisando o modelo V de desenvolvimento detalhadamente, a primeira
etapa a de definio dos requisitos do sistema desejado, seguido da modelagem
do funcionamento da planta, chamada de arquitetura funcional. Em seguida,
baseada na arquitetura funcional criada a arquitetura fsica ou planta fsica, que
consiste em uma montagem fsica de componentes que simulam o sistema
planejado. Com as arquiteturas j desenvolvidas possvel gerar o cdigo em
linguagem C do controlador.
Aps o lado esquerdo do modelo em V finalizado passa-se para o lado
direito da figura 4. Nesta parte do desenvolvimento toda implementao realizada.
Inicialmente valida-se o sistema
22
A estrutura funcional utilizada para validao via software, onde a planta

ainda est sendo executada exclusivamente em software e o controlador executado
tanto em hardware quanto em software.
Utilizando a arquitetura fsica, que pode ser considerada a planta fsica do
modelo, possvel se realizar a verificao com o controlador sendo executado
tanto em software quanto em hardware. A verificao utilizando as plantas funcional
e fsica, at esta altura, desenvolvida e testada em uma estrutura de diagramas de
blocos.
Com o cdigo gerado automaticamente na quarta etapa possvel fazer a
validao do sistema em ambas as arquiteturas, porm utilizando o cdigo em
linguagem C para controlar o processo e no mais modelos de diagramas de blocos.
Por ltimo a integrao funcional e a validao no veculo servem para fazer
a verificao e validao final em ambientes reais, seja em prottipos ou no alvo
final do desenvolvimento.
Esta metodologia amplamente aplicada no desenvolvimento de software
automotivo em sintonia com fornecedores. Os desenvolvedores de ferramentas
disponibilizam
ferramentas
desenvolvimento
possam
adequadas
ser
para
posteriormente
que
cada
integrados
fase
ao
ciclo
do
processo
de
desenvolvimento de produto da OEM.
2.2 MODEL BASED DESIGN OU DESENVOLVIMENTO BASEADO EM MODELO

Segundo Kelemenov (2013) atualmente as indstrias esto sob constante
presso para reduzir o tempo de desenvolvimento de novos produtos. Trabalhar de
forma eficiente indispensvel para o sucesso em um mundo globalizado,
principalmente para empresas de alta tecnologia como a automobilstica,
aeroespacial e de comunicao. Nestas empresas, controles eletrnicos so uma
parte vital de cada produto desenvolvido. O desenvolvimento baseado em modelo
uma abordagem que pode cortar custos e diminuir o tempo de um projeto pois
possibilita que se trabalhe com apenas um modelo de uma funo ou com um
sistema completo em um ambiente integrado de software.
A principal caracterstica e vantagem do processo de desenvolvimento
baseado em modelo o desenvolvimento em uma nica plataforma, permitindo que
23
se crie a planta do sistema desejado e seu controlador utilizando a mesma

ferramenta computacional Isto facilita a visualizao e o entendimento do sistema
assim como possveis erros. O resultado em um sistema funcional e de fcil
verificao, diminuindo significativamente a possibilidade de que os componentes
individuais no se encaixem de maneira otimizada.
Segundo a empresa MathWorks, no design baseado em modelo um
modelo de sistema est no centro do processo de desenvolvimento, desde a
definio dos pr-requisitos, passa pelo design, implementao e testes. O design
baseado em modelo est transformando o modo que engenheiros e cientistas
trabalham, tirando as tarefas do projeto do laboratrio e do campo para uma rea de
trabalho.
Segundo Lennon (2007) o MBD simplifica o desenvolvimento de sistemas,
proporcionando um ambiente comum para design e comunicao entre diferentes
reas de engenharia.
Algumas principais vantagens que o MBD oferece em comparao com as
abordagens tradicionais so (FANTUZZI, 2014):
a) Possibilidade de um ambiente de projeto comum, o que facilita a
comunicao, anlise de dados e verificao do sistema entre os grupos
envolvidos no desenvolvimento;
b) Os engenheiros podem localizar e corrigir erros no incio do projeto do
sistema, quando o tempo e custo para alguma modificao no sistema
so ainda pequenos;
c) Expanso das oportunidades
de
reutilizao
de
projetos
para
atualizaes de sistema ou para sistemas derivativos.
2.3
DESENVOLVIMENTO
TRADICIONAL
VERSUS
DESENVOLVIMENTO
BASEADO EM MODELOS
No processo desenvolvimento tradicional, a elaborao dos requisitos, o
desenvolvimento fsico do prottipo, o desenvolvimento de cdigos, o processo para
embarcar e posteriores testes so realizados sequencialmente em ambientes
diferentes e com muitos passos manuais. Os requisitos so descritos textualmente,
utilizando ferramentas de edio de texto. Os projetos so muitas vezes
24
desenvolvidos em ferramentas de linguagem de domnio especfico, o que impede

testes do sistema at a fase de implementao em software ou hardware,
dependendo do caso. Os projetos so ento traduzidos manualmente em cdigo, o
que normalmente significa em um processo que consome muito tempo e propenso a
falhas. Em cada fase, defeitos podem surgir, porm estas falhas s sero
observadas na fase de implementao.
O resultado disso que a fase final se torna em uma etapa maante,
demandando muito tempo e recursos. A figura 5 demonstra a separao que este
processo causa no projeto
Figura 5 - Mtodo de desenvolvimento tradicional

Fonte: MathWorks, adaptado pelo autor(2014)
O MBD se inicia com o mesmo conjunto de requisitos do processo

tradicional. Porm, ao invs de servir para desenvolver especificaes de modo
textual, os requisitos so utilizados para desenvolver um modelo executvel. Os
envolvidos no projeto utilizam este modelo para esclarecer e facilitar o entendimento
dos requisitos e especificaes. Os projetos so ento utilizados para desenvolver
um projeto detalhado. Utilizando ferramentas computacionais possvel simular o
sistema, descobrindo falhas e defeitos muito antes da implementao. Com o
modelo finalizado e verificado possvel gerar automaticamente o cdigo e refazer
testes a partir destes cdigos.
Este fluxo de trabalho permite que se permanea sempre no mesmo
ambiente de trabalho, minimizando o trabalho necessrio. Alm disso possvel
iniciar os testes nas fases iniciais, j nos modelos recm projetados e verificar se os
requisitos esto sendo alcanados. Como resultado, falhas so encontradas e
corrigidas mais cedo do que no modelo de desenvolvimento tradicional, diminuindo o
tempo de desenvolvimento total e reduzindo a utilizao de recursos.
25
A figura 6 ilustra o fluxo de trabalho facilitado do MBD. Todas as etapas se

conectam com facilidade, permitindo que se acesse e modifique caractersticas do
das fases iniciais de mesmo nas ltimas etapas de implementao.
Figura 6 - Desenvolvimento Baseado em Modelo (MBD)

Fonte: MathWorks (2014)
No MBD de sistema de controles o desenvolvimento segue basicamente as

mesmas etapas demonstradas no diagrama do V-model.
Definio dos Requisitos.

Desenvolvimento da Arquitetura Funcional.
Desenvolvimento da Arquitetura Fsica.
Codificao.
Validao do Sistema.
Integrao Funcional.
Validao do Veculo.
Inicialmente define-se todos os requisitos necessrios para o funcionamento

do controle do sistema conforme esperado. Estes requisitos so descritos
textualmente e permitem que se desenvolva a arquitetura funcional do sistema, que
normalmente consiste em um modelo desenvolvido em ferramentas computacionais.
Aps esta etapa possvel desenvolver fisicamente o modelo, construindo um
prottipo do sistema a ser controlado. Com o prottipo pronto possvel, utilizando o
modelo funcional gerar um cdigo na linguagem desejada que ser embarcado em
26
outras fases em um hardware escolhido. Com o modelo desenvolvido em software e

o cdigo gerado possvel verificar o funcionamento do projeto utilizando entradas
de teste j desenvolvidas. Esta verificao pode ser via software ou hardware. Com
todas as funes verificadas possvel embarcar o cdigo no sistema alvo final e
validar o sistema como um todo.
2.4 MTODOS DE TESTE PARA MBD

Normalmente no MBD so utilizadas tradicionais tcnicas de validao
chamadas
Model-in-the-Loop,
Hardware-in-the-Loop.
Software-in-the-Loop,
utilizao
destes
Processor
mtodos
in-the-Loop
geralmente
segue
cronologicamente esta sequncia. Alm disso, via de regra, as trs primeiras etapas
utilizam as mesmas entradas de teste. Conforme demonstrado na Figura 7.
Figura 7 - Sequncia de mtodos para verificao de sistema embarcado

Fonte: MathWorks (2014)
Apesar de que apenas os mtodos de Model-in-the-Loop e o Software-inthe-Loop sero utilizadas para validar a funo desejada neste trabalho, relevante
que todos os mtodos sejam explicados. A seguir sero explicados um a um os
27
principais mtodos utilizados para o MBD, porm muitas vezes outras denominaes
so encontradas na bibliografia. Esta variao normalmente causada quando o
sistema a ser desenvolvido especfico e obriga os engenheiros a fazer testes que
normalmente no seriam desenvolvidos na maior parte dos sistemas.
a) Model-In-the Loop (MIL): o primeiro estgio de simulao que serve
como referncia para os estgios seguintes e fornece os valores
mnimos e mximos das variveis. A estratgia de controle e o modelo
fsico so de desenvolvimento extremamente rpido, possibilitando
mudanas e testes rpidos no sistema. Neste trabalho esta fase foi
desenvolvida em ambiente Matlab/Simulink. A figura 8 ilustra o ambiente
em que o MIL geralmente aplicado. O modelo da planta e do
controlador, assim como todos os testes para verificao so
desenvolvidos em Simulink.
Figura 8 - Workflow para o MIL demonstrando telas genricas dos programas utilizados
b) Software-In-the Loop (SIL): Esta simulao o estgio onde a

ferramenta de gerao automtica de cdigo fornece a estratgia de
28
controle estabelecida no MIL automaticamente em cdigo em linguagem

C ou C++. Aqui o modelo de controle um pouco mais real. Este
essencialmente um teste para o sistema de gerao de cdigo (seja feito
de maneira automtica ou manual). A interao do modelo diminui um
pouco com relao ao MIL, mas j possvel enxergar erros de
codificao. O fluxograma desta fase pode ser observado na Figura 9.
Conforme a figura ilustra, o controlador representado pelo cdigo em
linguagem C e a planta segue sendo representada por um diagrama de
blocos de Simulink.
Figura 9 - Workflow para o SIL demonstrando telas genricas dos programas utilizados
c) Processor-In-the Loop (PIL): nesta fase no se roda mais o cdigo do

sistema em simulao, ao invs disso ele implementado em um micro
controlador. Enquanto o cdigo do controle est rodando no micro
controlador, a planta ainda est sendo representada por um diagrama de
Simlulink. Este teste projetado para expor problemas com a
execuo em um sistema embarcado. Neste estgio as principais tarefas
envolvem medio de memria, perfil de tempo de execuo e
29
verificao do cdigo alvo. Aa Figura 10 ilustra as plataformas

envolvidas nesta etapa.
Figura 10 - Workflow para o PIL demonstrando telas genricas dos programas utilizados e
imagens ilustrativas das plataformas
d) Hardware-In-the Loop (HIL): nesta etapa o sistema de controle est

instalado no sistema final de controle e pode apenas interagir com a
planta atravs das entradas apropriadas do controlador. A planta est
rodando em um computador em tempo real com entradas e sadas
simuladas para fazer com que o controlador acredite que est instalado
na planta real. Neste caso a nica diferena entre a aplicao final e o
ambiente HIL a fidelidade do modelo da planta e os vetores teste que
esto sendo utilizados. O HIL geralmente utilizado para validao de
software ao invs de desenvolvimento, pois a interao do modelo
muito lenta. Apesar disso, este teste muito prximo da realidade da
aplicao final e por isso deixa claro a maior parte dos problemas que
podero ser encontrados. A fase de HIL ilustrada pela Figura 11.
30
Figura 11 - Workflow para o HIL demonstrando telas genricas dos programas utilizados e
imagens ilustrativas das plataformas
2.5 RAPID CONTROL PROTOTYPING

Outro importante e valioso mtodo de validao para softwares automotivos,
e que ser tambm utilizado neste trabalho, conhecido como Rapid Control
Prototyping (RPC)
O
principal
desejo
de
Engenheiros
que
trabalham
com
projetos
automobilsticos poder se concentrar completamente em funes das Unidades

Eletrnicas de Controle (ECU) e executar rapidamente testes em seus sistemas
alvo. No apenas testes off-line, como tambm em veculos reais ou em bancos de
teste. Neste cenrio preciso de uma rpida confirmao de que o projeto est indo
no caminho certo.
O RCP um processo de calibrao dos algoritmos de controle em um
prottipo de hardware. Este processo permite que testes sejam feitos antes de que
haja uma ECU disponvel para o processo. As plataformas RCP normalmente
oferecem um mtodo que permita que sejam importados modelos matemticos de
31
um software e executados em um sistema operacional em tempo real com entradas

e sadas fsicas.
O RCP permite aos engenheiros testar e interagir suas estratgias de
controle rapidamente. Consequentemente, os modelos matemticos so importados
automaticamente com MATLAB/Simulink em uma mquina em tempo real com
interfaces reais e entradas e sadas para se conectar aos sistemas do mundo real.
Alm disso esse processo diminui o tempo de desenvolvimento, permitindo
que correes sejam feitas no incio do processo produto. Essa oportunidade de
conseguir verificar o processo em fases iniciais do projeto permite que erros sejam
corrigidos e mudanas serem feitas enquanto o custo ainda pequeno.
Segundo Dong (2008), no RCP as plantas e o controlador so
implementados em uma placa de processamento de sinal digital, permitindo um fcil
ajuste de vrios parmetros da planta e do controlador.
De acordo com Fang et al. (2009) o principal conceito do RCP entender os
requisitos do sistema e traar um plano geral de desenvolvimento, levando em
considerao a eficincia e rapidez, e ento selecionar ou desenvolver um design de
modelo de controlador e uma plataforma de hardware.
Seguindo esses requisitos, engenheiros podem otimizar os projetos at que
o
resultado
seja
satisfatrio. Falhas de
projeto
podem
ser
encontradas
imediatamente, e as correes podem ser realizadas imediatamente, visando a

eficincia de tempo e a confiabilidade do sistema.
Recentemente, cada vez mais empresas esto oferecendo solues para o
desenvolvimento de RCP. O software da MathWorks, Matlab/Simulink talvez a
ferramenta mais conhecida e amplamente usada para modelagem e simulao de
sistemas. No quesito hardware o MicroAutoBox (MABX) da dSpace, que pode ser
visto na Figura 12, uma ferramenta poderosa, com diversas entradas e sadas
digitais e analgicas que permitem a simulao de sistemas complexos. Usando
Matlab/Simulink com o MicroAutoBox da dSpace pode-se facilmente realizar
testes para validar qualquer modelo.
32
Figura 12 Plataforma de hardware MicroAutoBox, da empresa dSpace

Fonte: dSpace (2014)
Os blocos e diagramas de estado do Simulink e Stateflow so os pontos

de partida para o desenvolvimento da funo para prototipagem. Segundo Fang et al
(2009) eles representam o controlador e o seu ambiente de forma grfica e podem
ser simulados off-line para uma validao inicial e no minuciosa. Para realizar o
RCP, os diagramas de bloco criados em ambiente Simulink so implementados
diretamente em um sistema de prototipagem e rodados em tempo real, sem a
necessidade de qualquer programao manual. O hardware de prototipagem
geralmente possui um poder de processamento maior do que o ECU real, portanto,
no h necessidade de se preocupar com limitaes de hardware.
Neste ambiente de prototipagem rpida o desenvolvimento pode avanar
muito mais rpido, j que o profissional responsvel pelo design de controle pode
facilmente executar funes que, em um ambiente de desenvolvimento tradicional,
normalmente seria executado por trs departamentos. A Figura 13 compara os
procedimentos do RCP com os procedimentos tradicionais.
Figura 13 - Comparao do desenvolvimento tradicional com o desenvolvimento do Rapid

Control Prototyping
33
Atualmente os softwares controle automobilstico so submetidos a quatro

etapas de verificao (Figura 14), a saber:
Simulao Offline (como MIL).

Rapid Control Prototyping.
Simulao HIL
Validao na ECU.
Figura 14 - Estratgia de controle e estgios de verificao

As duas primeiras fases de verificao destinam-se a verificar o

desempenho funcional do algoritmo de controle. Esta verificao realizada no
modelo de estratgia de controle antes do o software de produo ser gerado. As
ltimas duas fases de verificao so executadas em software e incorporado na
ECU.
34
3 DESENVOLVIMENTO
Com todas as etapas que sero realizadas no trabalho apresentadas ser
iniciado a parte prtica do trabalho. O fluxo de trabalho foi organizado de maneira
que todas as arquiteturas e controladores foram modelados respeitando a sequncia
tradicional do MBD. Inicialmente modelou-se a arquitetura funcional e seu
controlador em Simulink. Aps esta fase foi gerado o cdigo em linguagem C para
o controlador para possibilitar a etapa de SIL. Por ltimo as entradas e sadas da
planta foram alteradas com blocos especficos para o hardware utilizado durante a
fase de RCP. Esta sequncia ilustrada na Figura 15.
Figura 15 Sequncia de desenvolvimento deste trabalho e ferramentas utilizadas durante o

processo
Inicialmente ser demonstrado todos os dados utilizados e desenvolvidos

para que fosse possvel realizar as etapas separadamente, incluindo as entradas de
testes que sero utilizadas para a verificao. Depois de todos os dados
demonstrados e explicados sero demonstrados os resultados, seguindo a mesma
ordem de desenvolvimento.
A anlise da verificao ser feita apenas durante a fase de MIL, pois com
todos os requisitos alcanados nesta fase possvel apenas comparar estes
resultados com os das outras fases.
35
3.1 SISTEMA EXTERNO DE ILUMINAO AUTOMOTIVO

O sistema de iluminao de um automvel constitudo por dispositivos de
iluminao e de sinalizao montados ou integrados em vrias partes de um veculo.
Estas podem incluir: a frente, as laterais, a traseira e, em alguns casos, a parte
superior do veculo. O objetivo deste sistema fornecer a iluminao para o
motorista. Isso permite a operao segura do veculo noite e aumenta a
visibilidade para o motorista. Este sistema tambm facilita a visualizao do veculo
por terceiros, a sua posio, seu tamanho, a direo da viagem, e as intenes do
motorista em relao a direo e velocidade de deslocamento.
Nos sistemas atuais de iluminao externa automotivo os principais itens
para definio dos pr-requisitos se baseiam nos seguintes elementos:
O estado (ligado ou desligado) dos interruptores de acionamento de

cada um dos casos de iluminao, como o de escolha do tipo de luz
frontal, de acionamento de luzes de indicao de direo, pedal de freio
ou engate de marcha r;
Nvel de tenso fornecida pela bateria;
Posio da chave na ignio (off", acessrio ou acessrio (acc), on e
crank).
As opes normalmente disponveis no interruptor para a escolha do tipo de

luz frontal so: desligado; luzes de posio e luz baixa. A luz alta normalmente
possui um interruptor prprio.
A posio crank a posio que d partida ao motor, logo aps a posio
on, que permite que todos os sistemas e sensores do carro sejam acionados. A
posio acc uma posio intermediria entre on e off e habilita alguns
sistemas do carro, variando dependendo do modelo de carro observado.
Neste trabalho, vamos analisar apenas as luzes tradicionais e de uso mais
comum, pois luzes laterais, de nevoeiro e luzes de aparncia no esto presentes
em grande parte dos modelos. Portanto as luzes que sero analisadas sero:
a) Luzes dianteiras: luzes indicadoras de direo ou pisca-pisca (esquerda
e direita), luz baixa, luz alta e luzes de posio;
b) Luzes traseiras: luz de r, luz de freio, luzes indicadoras de direo ou
pisca-pisca (esquerda e direita) e luzes de posio.
36
A Figura 16 apresenta uma distribuio fsica do sistema de iluminao

exterior no veculo.
Figura 16 - Sistema externo de iluminao automotivo

As descries de cada uma das funes do sistema externo de iluminao

segundo o Anexo 1 da Lei 9.503 de 1997, conhecida como Cdigo de Trnsito
Brasileiro, esto descritas abaixo:
a) Luzes de posio: a "luz do veculo destinada a indicar a presena e a
largura do veculo" (Anexo 1, Lei 9.503 de 1997). A luz de posio
obrigatria noite quando o veculo estiver parado para carga e descarga de
passageiros ou mercadorias e facultativa no caso de neblina, chuva forte, ou
cerrao (artigo 40, incisos IV e VII, Lei 9.503 de 1997). Para ativar as luzes
de posio so necessrias algumas condies: a posio da ignio deve
estar em Acessrio e o interruptor de luz em luzes de posio. Caso a
chave de ignio for virada no sentido horrio as luzes de posio
continuaro acesas, s sendo desativadas caso a chave seja girada no
sentido anti-horrio para a posio off.
b) Luz baixa: "o facho de luz do veculo destinada a iluminar a via diante do
veculo, sem ocasionar ofuscamento ou incmodo injustificveis aos
condutores e outros usurios da via que venham em sentido contrrio" (Anexo
1, Lei 9.503 de 1997). Ela obrigatria em dois casos; noite em qualquer
situao e de dia em tneis providos com iluminao pblica (artigo 40, inciso
I, Lei 9.503 de 1997). Na maioria dos sistemas de iluminao de carros este
37
caso ativado quando a ignio est em qualquer posio diferente de off e

o interruptor de luz est em luz baixa.
c) Luz alta: "o facho de luz do veculo destinado a iluminar a via at uma
grande distncia do veculo" (Anexo 1, Lei 9.503 de 1997). mandatrio em
vias no iluminadas quando no houver outro veculo vindo na direo
contrria ou frente (artigo 40, inciso II, Lei 9.503 de 1997). A luz alta ser
ativada quando a posio da ignio no estiver em off e o interruptor
estiver em luz alta.
d) Luz indicadora de direo ou pisca-pisca: a "luz do veculo destinada a
indicar aos demais usurios da via que o condutor tem o propsito de mudar
de direo para a direita ou para a esquerda" (Anexo I, Lei 9.503 de 1997).
H duas maneiras de ativar luz indicadora com a ignio em qualquer posio
exceto off e o interruptor da luz indicadora na posio para cima ou para
baixo. Se o interruptor estiver para cima as luzes frontal e traseira do lado
direito sero acesas intermitentemente. J se o interruptor estiver para baixo
as luzes frontal e traseira do lado esquerdo sero ativadas intermitentemente.
A outra forma de ativar as luzes indicadoras o boto de alerta ser
apertado. Nesta situao as luzes direita e esquerda, frontais e traseiras,
sero ativadas intermitentemente de forma sincronizada, independentemente
da posio da chave de ignio.
e) Luz de marcha r: "a luz do veculo destinada a iluminar atrs do veculo e
advertir aos demais usurios da via que o veculo est efetuando ou a ponto
de efetuar uma manobra de marcha r" (Anexo I, Lei 9.503 de 1997).
Comumente so utilizadas lmpadas de luz branca para este sistema. A luz
de marcha r ativada sempre que a marcha r for acionada e a ignio se
encontrar em qualquer posio alm de off.
f) Luz de freio: "a luz do veculo destinada a indicar aos demais usurios da
via, que se encontram atrs do veculo, que o condutor est aplicando o freio
de servio" (Anexo I, Lei 9.503 de 1997). A luz de freio ativada quando o
motorista pisar no pedal de freio e desativada quando o pedal for solto.
3.2 ARQUITETURA ELTRICA DO SISTEMA DE ILUMINAO EXTERNA
38
O sistema eltrico de controle do sistema de iluminao externa era baseado

nos componentes eltricos tradicionais, sem o uso das facilidades da eletrnica. A
Figura 17 demonstra um exemplo de esquema eltrico do circuito de luz indicadora
de direo.
Figura 17 - Circuito para a luz indicadora de direo

Como possvel visualizar o sistema de controle era totalmente controlado a

partir de chaves. Este sistema, por ter funcionamento mecnico, alm de ser
extremamente suscetvel a desgaste podendo causar falhas, necessita de tempo
para ser montado e, no caso da alterao em sua estratgia de controle, precisa ser
alterado por completo. Em um sistema moderno, controlado por softwares este
problema no se observa, visto que no h desgaste no sistema de controle e caso
haja necessidade de alguma alterao, basta que o software seja alterado e
atualizado.
4
3.3 CONTROLE ELETRNICO DAS FUNES DE CARROCERIA
As vrias peas eletrnicas de um veculo podem ser controladas por um
mdulo, desde o sistema de iluminao do carro at as fechaduras das portas, cada
parte tem um mdulo que a controla. Nas configuraes dos automveis atuais,
39
esses mdulos j esto operando sob uma nica montagem Este mdulo em
questo o mdulo de controle das funes de carroceria, conhecido como body
control module (BCM). O BCM executa uma funo muito complexa e utiliza uma
grande gama de dispositivos de entrada e sada. Os dispositivos de entrada referemse a componentes que alimentam dados no mdulo (como sensores e resistores
variveis) para ajudar o mdulo a determinar sua resposta. Enquanto isso, os
dispositivos de sada so aqueles que o mdulo utiliza para produzir a sua resposta
entrada enviada para ele. Estas peas podem incluir rels e solenides que que
podem ligar e desligar dispositivos.
Segundo Liuguilong (2013) na eletrnica automotiva, a BCM o principal
componente de uma ampla gama de funes. Pode compar-lo com o sistema
nervoso central de um ser humano. O sistema nervoso controla a coordenao no
corpo humano atravs da transmisso de sinais. Enquanto isso, o BCM regula a
atividade de coordenao entre as diferentes partes de um carro tambm atravs de
sinais.
O BCM torna tudo mais simples na operao de dispositivos eletrnicos em
um carro. No entanto, apesar de oferecer uma ampla gama de benefcios se
comparado as configuraes anteriores, ele tambm apresenta problemas relativos
a sua estrutura. Quando houver um problema na BCM, isso causar mal
funcionamento em vrias partes que ele controla, como o funcionamento
intermitente no levantamento de vidros eltricos, travas e luzes. Em certos casos,
estes sistemas podem mesmo deixar de funcionar inteiramente. A Figura 18 ilustra o
diagrama de blocos de uma BCM com as principais funes controladas.
40
Figura 18 - Diagrama de blocos de uma BCM

Fonte: Freescale (2014)
3.4 MODEL-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE ILUMINAO

AUTOMOTIVO
Com a definio de todos os princpios do MBD pode-se implementar esta
metodologia para desenvolver o projeto do sistema externo de iluminao
automotivo. Para isso deve-se seguir os passos definidos anteriormente.
3.4.1 Definio dos Requisitos
Para iniciar o projeto necessrio definir os pr-requisitos de cada
subsistema a ser controlado. Os pr-requisitos sero apresentados separados caso
a caso, no Quadro 1.
41
Para ativar as luzes de posio:
REQ-01: a posio da ignio deve estar em "on", "acessrio", ou "crank".

REQ-02: o interruptor de luz deve estar em "luzes de posio".
Para ativar a luz baixa:

REQ-04: o interruptor de luz deve estar em "luz baixa".
Para ativar a luz alta:

REQ-06: o interruptor completa do feixe deve ser puxado.
Para ativar as luzes de indicao de posio esquerda:

REQ-08: o interruptor da luz de indicao de posio deve ser direcionado para
baixo.
Para ativar as luzes de indicao de posio direita:
REQ-09: a posio da ignio deve estar em "on", "acessrios", ou "crank".

REQ-10: o interruptor da luz de indicao de posio deve ser direcionado para
cima.
Para ativar as duas luzes indicadoras de posio ao mesmo tempo:
REQ-11: o interruptor de alerta deve ser pressionado.
Para ativar a luz de r:

REQ-13: a marcha r deve ser engatada.
Para ativar luzes de freio:
REQ-14: o pedal do freio deve ser pressionado.
Para todos os casos:
REQ-15: o nvel de tenso da bateria deve estar entre 16 e 9 Volts .

Quadro 1 - Definio dos requisitos de funcionamento
3.4.2 Projeto da Arquitetura Funcional

Aps a definio dos requisitos possvel desenvolver a planta ou
arquitetura funcional do sistema desejado. A arquitetura em questo modelada
utilizando-se blocos de Simulink do Matlab. Cada caso do sistema de iluminao
estudado representado por um bloco de sub-rotina no Simulink. Na Figura 19
possvel ver a tela principal da arquitetura funcional desenvolvida.
Figura 19 Arquitetura funcional do sistema com as entradas de teste criadas para
validao
42
importante considerar que o bloco de signal builder que aparece em

vermelho na Figura 19 (de rtulo Lamps) foi criado para gerar um sinal de erro
caso alguma das lmpadas esteja queimada. Este sinal, em um veculo real, pode
ser gerado por um sensor de corrente instalado nas lmpadas. Caso este sinal seja
alto significa que a lmpada est funcionando, caso contrrio ele ter valor baixo ir
gerar um sinal de erro. Porm apesar desta funcionalidade estar ativa, nos testes
estes sinais sero considerados sempre habilitados, significando que todas as
lmpadas esto funcionando corretamente.
43
No subsistema central, mostrado na Figura 19, est localizado todos os

casos a ser analisados. A Figura 20 demonstra a organizao destes casos dentro
do subsistema.
Nesta figura possvel observar que os subsistemas esto localizados do
lado direito da imagem. Cada um destes subsistemas se refere a um dos casos de
iluminao considerados (luz de posio, Luz baixa, luz alta, etc.). Do lado esquerdo
est localizado o subsistema que gera o sinal que habilita o sistema. Este sinal
dependente das condies da bateria e da posio da chave de ignio. Este sinal
ser alto apenas quando a bateria estiver dentro do nvel aceitvel e a chave de
ignio esteja em acc, on ou crank.
Os sinais que alimentaro estes sistemas sero demonstrados na seo
3.4.4, onde o caso de teste ser apresentado.
Figura 20 - Disposio dos subsistemas todos os sistemas de iluminao

Cada subsistema destes vistos na Figura 20 contm a lgica de

funcionamento dos casos. Esta lgica desenvolvida o controlador do sistema.
44
3.4.2 Projeto do Controlador

O controlador foi totalmente desenvolvido em diagramas Stateflow. Para
deixar mais claro o funcionamento destes sistemas, as Figuras 21 at 27
demonstraro todos os grficos de Stateflow desenvolvidos, na seguinte ordem:
Luz de posio, luz baixa, luz alta, luz de freio, luz de pisca direito, luz de pisca
esquerdo e luz de r. Para facilitar o entendimento dos grficos ser apresentada
antes de cada caso os requisitos necessrios para seu funcionamento.
Para que o sistema de luzes de posio seja habilitado necessrio que os
seguintes requisitos sejam cumpridos:
O interruptor da luz de posio esteja acionado (PLS=1);

A chave de ignio no esteja em off e a bateria esteja em nvel aceitvel
(IP=1);
O sinal de que a lmpada est funcionando esteja alto (PL1=1);
Desta forma o sinal de sada que habilita o sistema de luzes de posio ser
alto (PL=1), caso contrrio ele ter valor baixo (PL=0).
Observando estes requisitos foi possvel desenvolver os diagramas em
Stateflow. O diagrama referente ao funcionamento das luzes de posio

demonstrado na figura 21.
45
Figura 21 - Diagrama Stateflow para a lgica das luzes de posio

Como pode-se ver o funcionamento do Stateflow relativamente simples,

sendo necessrio apenas inserir as condies para que o sistema mude de estado.
Para que a luz baixa seja ativada necessrio que seus requisitos tambm
sejam cumpridos. Estes requisitos so:
O interruptor da luz baixa esteja acionado (LS=1);

(IP=1);
O sinal de que a lmpada est funcionando esteja alto (LB1=1);
alto (LB=1), caso contrrio ele ter valor baixo (LB=0).
Com os requisitos listados foi possvel desenvolver o diagrama Stateflow
demonstrado na figura 22.
46
Figura 22 - Diagrama Stateflow para controlar o funcionamento da luz baixa

Sem seguida partiu-se para o desenvolvimento do sistema de luz alta. Os

requisitos necessrios so:
O interruptor da luz alta esteja acionado (FBS=1);

(IP=1);
O sinal de que a lmpada est funcionando esteja alto (FB1=1);
alto (FB=1), caso contrrio ele ter valor baixo (FB=0).
Com estes requisitos foi possvel gerar o grfico em Stateflow que controla o
funcionamento da luz alta. Este grfico demonstrado na figura 23.
47
Figura 23 - Diagrama Stateflow referente a luz alta

O sistema seguinte a ser demonstrado o da luz de freio. Para que seu

funcionamento seja habilitado necessrio o cumprimento dos seguintes requisitos:
O pedal de freio seja acionado (BLS=1);

(IP=1);
O sinal de que a lmpada est funcionando esteja alto (BL1=1);
alto (BL=1), caso contrrio ele ter valor baixo (BL=0).
Com estes requisitos foi possvel desenvolver o diagrama Stateflow de
funcionamento deste sistema. A figura 24 demonstra este diagrama.
48
Figura 24 - Diagrama Stateflow referente a luz de freio

As luzes de pisca tm seu funcionamento idntico, sendo diferenciadas

apenas pela posio da alavanca que se encontra no volante. Alm disso, caso o
boto de alerta seja acionado, ambos os casos devero ser ativados. Portando para
o pisca direito possvel listar os seguintes requisitos
A alavanca do pisca deve estar deslocada para cima (RLS=1);

(IP=1);
O sinal de que a lmpada est funcionando esteja alto (RL1=1);
Caso o sinal de alerta seja ativado, o sistema deve
funcionar
independentemente de outros requisitos (HW=1).

alto (RL=1), caso contrrio ele ter valor baixo (RL=0).
Com estes requisitos definidos, foi possvel desenvolver o diagrama
Stateflow da figura 25.
49
Figura 25 - Diagrama Stateflow referente a luz de pisca direito

Considerando o funcionamento do pisca direito possvel listar os seguintes

requisitos
A alavanca do pisca deve estar deslocada para baixo (LLS=1);

(IP=1);
O sinal de que a lmpada est funcionando esteja alto (LL1=1);
Caso o sinal de alerta seja ativado, o sistema deve
funcionar
independentemente de outros requisitos (HW=1).

alto (LL=1), caso contrrio ele ter valor baixo (LL=0).
Com estes requisitos definidos, foi possvel desenvolver o diagrama Stateflow da
figura 26.
50
Figura 26 - Diagrama Stateflow referente a luz de pisca esquerdo

Por ltimo foi criado o controlador da luz de r. Para que seu funcionamento
seja habilitado necessrio o cumprimento dos seguintes requisitos:
A alavanca da transmisso seja colocada na posio de marcha r (RLS=1);

(IP=1);
O sinal de que a lmpada est funcionando esteja alto (RL1=1);
alto (RL=1), caso contrrio ele ter valor baixo (RL=0).
Com estes requisitos foi possvel desenvolver o diagrama Stateflow de
funcionamento deste sistema. A figura 27 demonstra este diagrama.
51
Figura 27 - Diagrama Stateflow referente a luz de r

Um controle importante a ser representado o que define o funcionamento

de todo os sistemas de acordo com a posio da chave de ignio e o nvel de
bateria. Para controlar estes requisitos foi criado um outro diagrama Stateflow que
foi colocado no subsistema que pode ser visto na Figura 19 e rotulado como
Ignition_SS.
Os requisitos para que este sinal seja habilitado so os seguintes:
A chave de ignio esteja na posio acc, run ou Crank (Acc=1,
Run=1 ou Crank=1);
O nvel da bateria esteja em um nvel aceitvel (Batt=1).
Com estes requisitos foi criado o diagrama da figura 28.
52
Figura 28 - Diagrama Stateflow referente a posio da chave de ignio

3.4.4 Caso de teste

Para motivos de simulao, valores para as variveis de entrada foram
criados para simular a operao de cada caso, e nomeadas de acordo.
No sistema de iluminao externa existem tarefas que podem ser ativadas por
sinais diferentes, caso das luzes indicadoras de posio (pisca-pisca). Esta tarefa
pode ser ativada tanto pelo seu switch prprio ou pelo sinal de alerta. Portanto para
comprovar que o sistema no falha em um momento que o sinal de alerta est
ativado os sinais de entrada referente a estes sistemas foram criados de maneira a
53
comprovar que a lgica do controlador funciona corretamente. Os sinais de entrada

podem ser vistos na Figura 29.
Figura 29 - Sinais de entradas utilizados para o caso de teste

Outro fator levado em considerao nos pr-requisitos a posio da chave

de ignio. Apesar de neste caso especfico, para todos os casos, a nica posio
que desabilita as luzes a posio off, importante que sejam simuladas
alteraes nas posies da chave. Para isso foi criado outro grupo de sinais de
entrada para as posies Acessrio, On e Crank, como se v na Figura 30.
54
Figura 30 - Entradas para a posio da chave de ignio

Para que todos os sistemas do carro funcionem necessrio que o nvel da

bateria esteja em um valor aceitvel. Na maioria dos carros de passeio este nvel
est na faixa de 9 a 16 volts. Portanto foi criado uma entrada de teste que simula a
variao da tenso da bateria no tempo. Este sinal demonstrado na figura 31.
Figura 31 Entrada de teste referente ao nvel de bateria

Fonte: Elaborado pelo autor (2014)
Como dito anteriormente, este cenrio foi desenvolvido de modo a mostrar

que no h erros na lgica do sistema. possvel ver que:
O interruptor das luzes de posio ativado antes que a chave de
ignio passe para a posio Acc;

O boto de alerta acionado enquanto o indicador de posio esquerdo
est ativado e depois o mesmo ocorre com o do lado direito;

O nvel da bateria chega a um nvel inferior a 9 Volts quando vrias
entradas esto ativas.
3.5 SOFTWARE-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE ILUMINAO

AUTOMOTIVO
55
O mtodo de Software-in-the-loop combina a um simulador flexvel e de

baixo custo com a fidelidade de um emulador de hardware. Segundo Demers (2007),
o SIL pode ser tanto utilizado no design do projeto, como tambm na fase de testes
e, potencialmente oferece uma enorme economia de custos, maximizando a
reutilizao de cdigo e minimizando o esforo necessrio para o desenvolvimento
de software.
Na simulao do SIL parte do modelo j existe na ferramenta utilizada para
esta simulao, e no caso deste trabalho o Simulink. Esta ferramenta j oferece a
opo de se criar o cdigo em linguagem C do modelo desenvolvido na fase de MIL.
Acessando a funo de gerao de uma funo chamada de S-Function,
automaticamente o Simulink cria o cdigo referente ao funcionamento do modelo e
embarca em um bloco do prprio programa.
Com este bloco possvel rodar novamente a simulao, com os mesmos
valores de entrada e verificar se as sadas esto idnticas ao teste realizado para o
MIL e principalmente se esto de acordo com o esperado.
O modelo no Simulink para o MIL tem uma aparncia muito prxima com
com o modelo da fase de MIL, porm o bloco principal no mais um subsistema
com outros blocos, e sim apenas um bloco que possui em seu interior o cdigo em
linguagem C que funciona exatamente como o modelo com os blocos.
Para provar que este o cdigo idntico ao subsistema com a lgica
construda com blocos, nova simulao feita com as mesmas entradas e as sadas
analisadas. Este procedimento ser demonstrado no item 4.2.
O cdigo que foi gerado automaticamente e inserido dentre do bloco de
Simulink ser disponibilizado no Apndice A.
A figura 32 demonstra o modelo funcional desenvolvido para o SIL, a partir
do modelo do MIL, com o cdigo em linguagem C embarcado no bloco principal.
56
Figura 32 - Imagem da S-Function gerada a partir do modelo inicial

3.6. RAPID CONTROL PROTOTYPING (RCP) PARA UM SISTEMA EXTERNO DE

ILUMINAO AUTOMOTIVO
Segundo o site da National Instruments, com o RCP possvel projetar o
algoritmo de controle e executar uma simulao off-line em um computador. Para
que seja possvel executar o RCP necessrio primeiramente fazer alteraes no
modelo desenvolvido no Simulink durante o MIL. Para verificar o primeiro modelo
57
era necessrio apenas os prprios scopes do Simulink, pois o processo era

validado apenas com simulao no programa. Para o RCP, necessrio embarcar o
cdigo em um hardware externo. Como dito anteriormente o hardware em questo
o MicroAutoBox da dSpace.
Para isso necessrio trocar as sadas normais do Simulink para os
blocos de entradas e sadas digitais (DIO) do MicroAutoBox. Estes blocos ficam
disponveis para o usurio aps a instalao dos programas que so utilizados no
processo. Alm disso, a dSpace disponibiliza vrios modelos de MicroAutoBox, o
que foi utilizado para este trabalho especificamente foi o de cdigo DS1401. A Figura
33 demonstra como ficou o novo modelo j utilizando os blocos do MABX.
Aps esta preparao, necessrio fazer algumas parametrizaes nas
configuraes do Simulink. As mais importantes e que merecem ser mencionadas
aqui so a de definir o sistema alvo a ser utilizado (MABX DS1401) e de acertar o
passo de clculo com os clocks dos grficos de Stateflow.
Figura 33 - Entradas para a posio da chave de ignio

58
Para o funcionamento da luz de pisca foi criada uma lgica de

funcionamento que simula a atividade real
Como o RCP no faz a simulao em software do sistema, no foi utilizado
sinais gerados pelo Simulink. Para simular os sinais de entrada no MABX e
visualizar as sadas, foi utilizado um instrumento de aquisio de sinal da Texas
Instruments chamado Data Aquisition (DAQ) em conjunto com o software
LabVIEW da mesma empresa. A Figura 34 demonstra as ligaes feitas na DAQ.
Figura 34 - Ligaes feitas entre o MABX e a DAQ

Para facilitar o entendimento de como acontece o RCP, a imagem 35

demonstra um fluxograma de como foi o fluxo de trabalho entre as interfaces
envolvidas no processo
Figura 35 Fluxo de trabalho desenvolvido para o RCP

Em ambiente LabVIEW foram criadas duas VIs diferentes, uma

responsvel pela gerao, nomeada Gerador dos sinais de teste a serem injetados
nas entradas so MABX, e outra, nomeada Aquisio responsvel pela leitura das
59
sadas do MABX para comparao e posterior validao. Estes instrumentos virtuais

foram criados de uma maneira que possam ser reutilizados para outras funes, e
respeitando as seguintes caractersticas.
Gerador:
Mximo 10 sadas digitais simultneas;

Tempo mnimo de atualizao 100ms;
Os sinais podem ser alterados no tempo de acordo com a descrio em
um arquivo de texto simples.
Aquisio:
Mximo 16 entradas digitais simultneas;

Tempo de amostragem 10ms ou frequncia de amostragem 100Hz
Os sinais de sada podem ser exportados os para arquivo (bmp ou xls)
Os sinais criados so exatamente os mesmos criados para o caso de teste

do Model-in-the-Loop e Software-in-the-Loop. Estes sinais no sero ilustrados da
mesma forma pois, como dito, foram gerados por programas diferentes mas, se
analisados com ateno, possuem o mesmo comportamento no tempo. Estes sinais
so demonstrados na Figura 36.
Figura 36 - Entradas criadas para o caso de teste do RCP

60
Assim como no Model-in-the-Loop e Software-in-the-Loop foram criadas

entradas que simulam o nvel da bateria e a posio da chave de ignio. Estes
sinais podem ser vistos na Figura 37.
Fig
ura 37 - Entradas relevantes para o funcionamento do sistema
Aps a definio de todas as entradas, foi necessrio determinar como estas

entradas sero conectadas ao MABX. Para isso foi mapeado todas as entradas e
sadas do MABX e estas entradas foram conectadas as entradas e sadas do DAQ.
Aps todas as conexes terem sido checadas a simulao pode ser feita e
seus resultados so apontados no item 4.3.
4 RESULTADOS
61
Aps desenvolvidas todas as modelagens e acertos necessrios para todas

as fases que fazem parte do escopo deste trabalho, necessrio rodar as
simulaes e tarefas inerentes a cada uma das etapas. Para facilitar a leitura e o
entendimento, este captulo ser tambm dividido em partes e na mesma sequncia
do desenvolvimento.
4.1 MODEL-IN-THE-LOOP
Como explicado no captulo 2, a fase de MIL executa a simulao do modelo
criado em ambiente Simulink. Portanto fazendo uso das entradas criadas e
demonstradas anteriormente, fez se a simulao do sistema em um tempo de 10
segundos.
Para ajudar a observao e comparao dos sinais e a consequente
validao do modelo, os sinais de sada sero colocados lado a lado com os de
entrada, gerados nos signal builders. Esta comparao pode ser vista na Figura 38.
Figura 38 - Comparao das entradas do modelo e as sadas verificadas nos scopes

62
Para analisar os dados necessrio lembrar que tanto a posio da chave

de ignio quanto o nvel de bateria ditam se o sistema funcionar o no. Portanto
quando algum destes sinais no estiver de acordo com os pr-requisitos, o sistema
no deve apresentar nenhum sinal alto.
Para resumir e facilitar o entendimento da verificao, o Quadro 2 mostra
que os requisitos relatados no Quadro 1 foram satisfeitos.
Chave de Ignio:
A chave de ignio est pelo menos na posio Acc de t=60 at t=8.

Luz de posio:
REQ-01 e REQ-02: A luz de posio est ativa durante o intervalo de t=0.5 at t=9. A
sada mostra que este caso est ativo de t=0.6 at t=7.3.
Luz baixa:
REQ-03 e REQ-04: a luz baixa est ativa de t=3 at t=4 e de t=7 at t=8. A sada
mostra que este caso est ativo de t=3 at t=4 e de t=7 at t=7.3.
Luz alta:
REQ-05 e REQ-06: a luz alta est ativa de t=1.5 at t=4 e de t=8.5 at t=9. A sada
mostra que este caso est ativo de t=1.5 at t=4 e de t=6 at t=7.3.
Luz indicadora de direo esquerda
REQ-07 e REQ-08: A luz indicadora de direo esquerda est ativa de t=5 at t=6 e
de t=8.5 at t=9. Alm disso o boto de emergncia est ativo de t=1 at t=2.5 e de
t=5.5 at t=6.5. A sada mostra que este caso est ativo de t=1 at t=2.5 e de t=5 at
t=6.5.
Luz indicadora de direo direita
REQ-09 e REQ-10: A luz indicadora de direo direita est ativa de t=3 at t=3.5 e de
t=6 at t=7. Alm disso o boto de emergncia est ativo de t=1 at t=2.5 e de t=5.5
at t=6.5. A sada mostra que este caso est ativo de t=1 at t=250, de t=3 at t=3.5 e
de t=5.5 at t=7.
REQ-11: como observado, quando o boto de alerta est ativo ambas as luzes de
indicao de direo esto ativas.
Luz de r:
REQ-12 e REQ-13: a luz de r est ativa de t=4 at t=6. A sada mostra que este caso
est ativo de t=4 at t=6.
Luz de freio:
REQ-14 o pedal de freio est ativo de t=1 at t=2, de t=4 at t=5 e de t=7 at t=8. A
sada mostra que este caso est ativo de t=1 at t=2, de t=4 at t=5 e de t=7 at
t=7.3.
Bateria:
REQ-15: todos os casos s podem estar ativos de t=0 at t=7.3.
63
Quadro 2 - Observaes e verificao dos requisitos de funcionamento

Aps a verificao pode-se dizer que a fase de Model-in-the-Loop foi

cumprida com sucesso. Todas as sadas correspondem com o desejo demonstrado
no momento da criao das entradas. Provou-se atravs da criao de entradas
interligadas no tempo que no h erros de lgica no sistema.
Com isso a primeira fase de um projeto para criao de um sistema
direcionado para uso em automveis foi satisfeita. Na sequncia da abordagem de
MBD a fase de Software-in-the-Loop.
4.2 SOFTWARE-IN-THE-LOOP
Conforme relatado no item 3.5, a fase de SIL cria um cdigo em linguagem
C, a partir do modelo criado para o MIL, que representa o funcionamento do
controlador.
A verificao desta fase pode ser mais simples do que a efetuada para o
MIL, pois como j foi comprovado que as sadas da fase anterior esto conforme o
esperado, podemos apenas comparar as sadas do MIL com as do SIL
O controlador que foi testado nesta fase agora representado pelo cdigo
em linguagem C gerado automaticamente pelo Simulink. Existe uma grande
facilidade em executar o SIL utilizando esta ferramenta computacional. possvel
gerar a S-Function e incluir o cdigo automaticamente utilizando uma funo do
prprio programa. Seria possvel tambm com o Simulink, gerar um cdigo
genrico em C e utilizar um bloco diferente de S-Function e adicionar manualmente
o cdigo, porm o modo automtico funciona perfeitamente.
A Figura 39 traa um comparativo destas sadas. Como pode-se ver as
sadas so idnticas provando que o cdigo gerado condizente com o
funcionamento esperado e baseado nos pr-requisitos definidos no incio do projeto.
64
Figura 39 - Quadro comparativo entre as sadas da fase MIL com as da fase SIL
4.3 RAPID CONTROL PROTOTYPING

Para que haja a validao do sistema no Rapid Control Prototyping o
procedimento muito parecido com os outros mtodos. Novamente necessrio
comparar os sinais gerados como entradas do caso de teste e comparar com os de
sada. Portanto necessrio compararmos os sinais demonstrados na Figura 36 do
captulo 3.6 e compararmos com os obtidos nas sadas do DAQ e demonstrados no
LabVIEW, sempre levando em considerao os sinais demonstrados na Figura 37
do captulo 3.6.
importante esclarecer que h um pequeno atraso no sinal demonstrado no
RCP. Isso provavelmente causado pelo tempo de resposta na leitura das entradas
e sadas do MABX. Apesar disso claro que o sistema funciona perfeitamente e nos
oferece as sadas conforme o esperado.
65
Levando em considerao este fato e observando as restries causadas ao

sistema pelas entradas demonstradas na Figura 37, pode-se afirmar que a validao
para RPC foi executada com sucesso. Se observarmos os resultados e tempos
relatados nos itens 4.1 e 4.2, referente a validao do Model-in-the-Loop e do
Software-in-the-Loop, chegamos concluso que o resultado foi idntico.
A Figura 40 coloca lado a lado estes dados para facilitar a comparao e
validao.
Figura 40 - Comparao dos sinais de entrada e sada para o RPC

Observando o grfico do LabVIEW possvel ver que os casos no esto

alinhados corretamente. Isto porque, o RCP foi inicialmente testado em uma planta
fsica, e nesta planta fsica o sinal das luzes de posio acionaram LEDs referentes
ao sistema de luzes de posio traseiro e dianteiro. Desta forma necessrio
comparar a entrada das luzes de posio, no lado esquerdo da figura 40, com as
duas primeiras linhas do grfico de sinais de sada, do lado direito da imagem.
Para facilitar o entendimento da validao do RCP, os grficos de sada
foram ento divididos em dois grupos. O primeiro apresenta a comparao apenas
das luzes de posio, luz baixa, luz alta e luz de freio. Esta comparao vista na
figura 41.
66
Figura 41 Grupo 1 de validao para RCP

O segundo grupo foi formado com os sinais De ambos os piscas e da luz de

r. A comparao do grupo 2 pode ser vista na figura 42.
Figura 42 Grupo 2 de validao para RCP

Analisando o grfico podemos ver que, exatamente como nas fases de MIL
e SIL, o sistema se comportou corretamente. Os requisitos foram todos respeitados,
inclusive o de nvel de bateria, visto que nada no sistema funciona aps o tempo de
t=7.3 s. O sinal de pisca no RCP funcionou conforme o esperado, respeitando a
lgica que faz com que o sinal funcione de maneira intermitente quando ativo.
67
5 CONCLUSO
A engenharia de software automotiva consiste na adoo de mtodos,
processos, ferramentas e padronizaes adequados que assegurem aos produtos
automotivos um nvel de qualidade, confiabilidade, segurana, satisfao as
regulamentaes e conforto, perceptveis e mensurveis aos clientes e todos
envolvidos no processo.
A elevada quantidade em linhas de cdigo dos veculos se caracteriza pela
grande quantidade de contedos funcionais que os automveis possuem
atualmente, como funes de iluminao, segurana, conforto, sistemas de
assistncia ao motorista, deteco de ponto cego entre outros. Esta proliferao de
contedos funcionais faz com que o software em automveis seja um elemento que
proporcione caractersticas diferenciadas do produto ao consumidor, sendo
considerado como um elemento facilitador que pode proporcionar novas
funcionalidades aos requisitos de atores de um automvel como usurio,
concessionria, ambiente e regulamentaes.
Esta comparao ao nvel de linhas de cdigo um exemplo ilustrativo para
apresentar o nvel de complexidade que os veculos atuais apresentam quando
observamos ao nvel de desenvolvimento, manuteno e recursos necessrios. Isto
porque fica claro que o nvel de complexidade em todos os nveis vai crescendo de
forma exponencial.
Dentro deste cenrio a utilizao de mtodos como o Model Based Design e
o Rapid Control Prototyping se demonstram excelentes ferramentas para diminuir o
tempo
de
desenvolvimento
de
novos
produtos
para
automveis
concomitantemente balizam diversos testes que aumentam a segurana e

confiabilidade destes produtos.
Neste trabalho verificou-se que, utilizando os conceitos do MBD, durante
todo o desenvolvimento foi possvel verificar a validade do sistema. Desde a
confeco da primeira planta em Simulink, vrios testes puderam ser executados.
Estes testes possibilitaram que os erros encontrados pudessem ser rapidamente
excludos e possveis melhorias fossem adicionadas ao modelo em fases iniciais.
68
Este tipo de desenvolvimento permite que, ao chegar em fases avanadas

de um projeto, todas as lgicas criadas tenham mais confiabilidade resultando em
um sistema mais seguro e de maior qualidade.
REFERNCIAS
BRASIL. Lei n 9.503., de 23 de dezembro de 1997. Cdigo de Trnsito
Brasileiro..
Braslia,
Disponvel
em:
<http://www.planalto.gov.br/ccivil_03/leis/l9503.htm>. Acesso em: 25 maio 2014
BROY, Manfred; KIRSTAN, Sascha; KRCMAR, Helmut. What is the benefit of a
model-based design of embedded software systems in the car industry? 2012.
Disponvel em: https://wwwbroy.in.tum.de/~schaetz/papers/Benefit_of_MBEES.pdf>.
Acesso em: 12 maio 2014
DEMERS, Stephanie; GOPALAKRISHNAN, Praveen; KANT, Latha. A Generic
Solution to Software-in-the-Loop. Military Communications Conference, Orlando,
Fl, EUA, p.1-6, 29 out. 2007.
FANG, Zheng et al. Design and implementation of a low cost dsp based rapid
control prototyping system. Industrial Electronics And Applications, Xi'an, p.18381843, 25 maio 2009.
FANTUZZI, Cesare. Chapter 02-Modeling: Modena: Universit Degli Studi di
Modena e Reggio Emilia, 2014. 55 slides.
HOLTMANN, Jorg; MEYER, Jan; MEYER, Matthias. A Seamless Model-Based
Development Process for Automotive Systems. 2011. Disponvel em:
<http://www.cs.uni-paderborn.de/uploads/tx_sibibtex/HMM11.pdf>. Acesso em: 23
mai. 2014.
INSTRUMENTS, National (Org.). Shortening the Embedded Design Cycle with
Model-Based
Design. 2012.
Disponvel
em:
<http://www.ni.com/whitepaper/4074/en/>. Acesso em: 25 jun. 2014.
69
KELEMENOV, Tatiana et al (Org.). Shortening the Embedded Design Cycle with

Model-Based
Design. 2013.
Disponvel
em:
<http://pubs.sciepub.com/ajme/1/7/25/ajme-1-7-25.pdf>. Acesso em: 03 jul. 2014.
LENNON, Tony. Model-based design for mechatronics systems. 2007. Disponvel
em:
<http://machinedesign.com/archive/model-based-design-mechatronicssystems>. Acesso em: 23 maio 2014
LIUGUILONG. The Design of BCM in Automotive Base on CAN/LIN Bus. 2013.
132 f. Tese (Mestrado) - Curso de Control Engineering, East China University Of
Science And Technology, Xangai, 2013
MATHWORKS.
Why
Use
Model-Based
Design?
Disponvel
<http://www.mathworks.com/model-based-design/>. Acesso em: 08 dez. 2014.
em:
MITSCHANG, Jonas. Evaluation of a Model-Based Development Process for

Automotive Embedded Systems: Model-Based Development of an Adaptive Cruise
Control System. 2009. 115 f. Tese (Graduao) - Curso de Software
Engineering,Departamento de Department Of Computer Sciences, University Of
Kaiserslautern, Kaiserslautern, 2009.
Site official de Delphi Automotive LLP.
Site official de dSPACE GmbH.
Site official de National Instruments Corporation.
Site official de The Mathworks Inc.
X. Dong, M. Yu, C. Liao, W. Chen. Rapid Control Prototyping Development of
Intelligent Control System of Vehicle Semi-active Suspension World Congress
on Intelligent Control and Automation, Junho, 2008, pp 1971-1975.
70
ANEXO A - Cdigo em linguagem C gerado para a S-Function do SIL
71
A.1
CDIGO EM LINGUAGEM C GERADO PARA A S-FUNCTION DO SIL
No item 3.5 foi desenvolvido o mtodo de Software-in-the-Loop. Para que fosse

possvel executar os testes foi necessrio embarcar um cdigo em linguagem C
gerado a partir do modelo da planta de controle. O cdigo foi gerado
automaticamente pelo Simulink e ser demonstrado neste Apndice. necessrio
salientar que este cdigo apenas parte de todos os cdigos gerados para este
sistema. Por se tratar de um sistema complexo e com muitos subsistemas o
programa gera 10 arquivos de cdigo separados. Este disponibilizado aqui o
principal e possui os chamados (calls) para os outros cdigos.
/* Include files */
#include "SILELS_sfun.h"
#include "SILELS_sfun_debug_macros.h"
#include "c1_SILELS.h"
/* Type Definitions */
/* Named Constants */
/* Variable Declarations */
/* Variable Definitions */
72
uint32_T _SILELSMachineNumber_;
real_T _sfTime_;
/* Function Declarations */
/* Function Definitions */
void SILELS_initializer(void)
{}
void SILELS_terminator(void)
{}
/* SFunction Glue Code */
unsigned int sf_SILELS_method_dispatcher(SimStruct *simstructPtr, unsigned int
chartFileNumber, const char* specsCksum, int_T method, void *data)
{ if (chartFileNumber==1) {
c1_SILELS_method_dispatcher(simstructPtr, method, data);
return 1;
} if (chartFileNumber==2) {
return 1;
return 1;
return 1;
return 1;
return 1;
return 1;
73

return 1;
} return 0;
}unsigned int sf_SILELS_process_check_sum_call( int nlhs, mxArray * plhs[], int
nrhs, const mxArray * prhs[] )
{ #ifdef MATLAB_MEX_FILE
char commandName[20];
if (nrhs<1 || !mxIsChar(prhs[0]) )
return 0;
/* Possible call to get the checksum */
mxGetString(prhs[0], commandName,sizeof(commandName)/sizeof(char));
commandName[(sizeof(commandName)/sizeof(char)-1)] = '\0';
if (strcmp(commandName,"sf_get_check_sum"))
return 0;
plhs[0] = mxCreateDoubleMatrix( 1,4,mxREAL);
if (nrhs>1 && mxIsChar(prhs[1])) {
if (!strcmp(commandName,"machine")) {
((real_T *)mxGetPr((plhs[0])))[0] = (real_T)(2436673724U);
} else if (!strcmp(commandName,"exportedFcn")) {
} else if (!strcmp(commandName,"makefile")) {
74
} else if (nrhs==3 && !strcmp(commandName,"chart")) {

unsigned int chartFileNumber;
chartFileNumber = (unsigned int)mxGetScalar(prhs[2]);
switch (chartFileNumber) {
case 1:
{ extern void sf_c1_SILELS_get_check_sum(mxArray *plhs[]);
sf_c1_SILELS_get_check_sum(plhs);
break;
} case 2:
break;
} case 3:
break;
} case 4:
break;
}
{
case 5:
extern void sf_c5_SILELS_get_check_sum(mxArray *plhs[]);
break;
}
{
case 6:
break;
}
{
case 7:
break;
case 8:
75

break;
default:
((real_T *)mxGetPr((plhs[0])))[0] = (real_T)(0.0);

}
} else if (!strcmp(commandName,"target")) {

} else {
return 0;
} } else {
} return 1;
#else
return 0;
#endif
}unsigned int sf_SILELS_autoinheritance_info( int nlhs, mxArray * plhs[], int
{#ifdef MATLAB_MEX_FILE
char aiChksum[64];
if (nrhs<3 || !mxIsChar(prhs[0]) )
return 0;
/* Possible call to get the autoinheritance_info */
76
if (strcmp(commandName,"get_autoinheritance_info"))
return 0;
mxGetString(prhs[2], aiChksum,sizeof(aiChksum)/sizeof(char));
aiChksum[(sizeof(aiChksum)/sizeof(char)-1)] = '\0';
{

case 1:
{
if (strcmp(aiChksum, "0eMjNtWrPcM8IsKjH8FrHE") == 0) {
extern mxArray *sf_c1_SILELS_get_autoinheritance_info(void);
plhs[0] = sf_c1_SILELS_get_autoinheritance_info();
break;
}
plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
break;
}
case 2:
if (strcmp(aiChksum, "UTMeEz7aP6MZ9Grb12OdWH") == 0) {
break;
}
break;
}
case 3:
if (strcmp(aiChksum, "50UTTgswUeJ8IfJyve0K2E") == 0) {
break;
}
break;
}
{
case 4:
if (strcmp(aiChksum, "3SFRG2doR2S8YyJLVlxmR") == 0) {
77
break;
}
break;
}
case 5:
if (strcmp(aiChksum, "x5VTW5KRUQPXzNydmMkniH") == 0) {
break;
}
break;
}
case 6:
if (strcmp(aiChksum, "iwtJtEyL2IXTgXBPEYDBOF") == 0) {
break;
}
break;
} case 7:
{
if (strcmp(aiChksum, "JF1Popq7zwpku6CviAFY0") == 0) {
break;
}
break;
case 8:
if (strcmp(aiChksum, "7t1ZED8HsMHA4gQqIPvMvG") == 0) {
break;
}
break;
}
default:
78
} } return 1;
#else
return 0;
#endif
}unsigned int sf_SILELS_get_eml_resolved_functions_info( int nlhs, mxArray *
plhs[], int nrhs, const mxArray * prhs[] )
{#ifdef MATLAB_MEX_FILE
if (nrhs<2 || !mxIsChar(prhs[0]))
return 0;
/* Possible call to get the get_eml_resolved_functions_info */
if (strcmp(commandName,"get_eml_resolved_functions_info"))
return 0;
{

case 1:
{
extern
const
mxArray
const
mxArray
*sf_c1_SILELS_get_eml_resolved_functions_info(void);
mxArray *persistentMxArray = (mxArray *)
sf_c1_SILELS_get_eml_resolved_functions_info();
plhs[0] = mxDuplicateArray(persistentMxArray);
mxDestroyArray(persistentMxArray);
break;
}
case 2:
{
extern
79
break;
}
case 3:
{
extern
const
mxArray
const
mxArray
const
mxArray
const
mxArray
break;
}
case 4:
{
extern
break;
}
case 5:
{
extern
break;
}
case 6:
{
extern
80
break;
}
case 7:
{
extern
const
mxArray
const
mxArray
break;
}
case 8:
{
extern
break;
}
default:
} } return 1;
#else
return 0;
#endif
}unsigned int sf_SILELS_third_party_uses_info( int nlhs, mxArray * plhs[], int
{ char commandName[64];
char tpChksum[64];
if (nrhs<3 || !mxIsChar(prhs[0]))
return 0;
/* Possible call to get the third_party_uses_info */
mxGetString(prhs[2], tpChksum,sizeof(tpChksum)/sizeof(char));
81
tpChksum[(sizeof(tpChksum)/sizeof(char)-1)] = '\0';
if (strcmp(commandName,"get_third_party_uses_info"))
return 0;
{

case 1:
{
if (strcmp(tpChksum, "dM7eHftvA6UbOhMuKijooC") == 0) {
extern mxArray *sf_c1_SILELS_third_party_uses_info(void);
plhs[0] = sf_c1_SILELS_third_party_uses_info();
break;
}
case 2:
{
if (strcmp(tpChksum, "eDUzH921FR0Ap0uDADO7wD") == 0) {
break;
}
case 3:
{
if (strcmp(tpChksum, "9HMWzFudZOXHo23f1AfmMD") == 0) {
break;
}
case 4:
{
if (strcmp(tpChksum, "oZscz0oMeGq6oKqqA16lhC") == 0) {
break;
}
case 5:
{
if (strcmp(tpChksum, "xMd0k7bgiWhGPHiH2fLLg") == 0) {
82
break;
}
case 6:
{
if (strcmp(tpChksum, "tTnu24zIiqt6gDmvpfMhoE") == 0) {
break;
}
case 7:
{
if (strcmp(tpChksum, "RqnE0wyETT02gwGaqCW9H") == 0) {
break;
}
case 8:
{
if (strcmp(tpChksum, "GfVejiabfylIfgIjxhEpuB") == 0) {
break;
}
default:
} }
return 1;
}void SILELS_debug_initialize(struct SfDebugInstanceStruct* debugInstance)
{
_SILELSMachineNumber_
sf_debug_initialize_machine(debugInstance,"SILELS",
"sfun",0,8,0,0,0);
sf_debug_set_machine_event_thresholds(debugInstance,_SILELSMachineNumber_
,0,0);
83
sf_debug_set_machine_data_thresholds(debugInstance,_SILELSMachineNumber_,
0);
}
void SILELS_register_exported_symbols(SimStruct* S)
{}
static mxArray* sRtwOptimizationInfoStruct= NULL;
mxArray* load_SILELS_optimization_info(void)
{ if (sRtwOptimizationInfoStruct==NULL) {
sRtwOptimizationInfoStruct = sf_load_rtw_optimization_info("SILELS",
"SILELS");
mexMakeArrayPersistent(sRtwOptimizationInfoStruct);
} return(sRtwOptimizationInfoStruct);
}void unload_SILELS_optimization_info(void)
{ if (sRtwOptimizationInfoStruct!=NULL) {
mxDestroyArray(sRtwOptimizationInfoStruct);
sRtwOptimizationInfoStruct = NULL;
}}

Aplicação Do Método de Desenvolvimento Baseado em Modelos para Uma Função de Software Automotivo

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aplicação Do Método de Desenvolvimento Baseado em Modelos para Uma Função de Software Automotivo

Uploaded by

Copyright:

Available Formats

UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN

JOO HENRIQUE ZANDER NEME

APLICAO DO MTODO DE DESENVOLVIMENTO BASEADO EM

JOO HENRIQUE ZANDER NEME

APLICAO DO MTODO DE DESENVOLVIMENTO BASEADO EM

- O Termo de Aprovao assinado encontra-se na Coordenao do Curso -

A esta universidade, seu corpo docente, direo e administrao que

NEME, Joo Henrique Zander. Aplicao do Mtodo de Desenvolvimento

A demanda por sistemas embarcados cresce exponencialmente. Na rea automotiva

Figura 23 - Diagrama Stateflow referente a luz alta.................................................47

LISTA DE SIGLAS E ACRNIMOS

Body Control Module

Delimitao do Tema ...............................................................................

Objetivo Geral ..........................................................................................

ARQUITETURA ELTRICA DO SISTEMA DE ILUMINAO

MODEL BASED DESIGN OU DESENVOLVIMENTO BASEADO EM

MODEL-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE

mecnicos, hidrulicos e pneumticos por componentes eltricos e eletrnicos

O motivo destas mudanas se faz em funo do menor custo, tamanho e

Deve-se considerar que o software parte integrante essencial de um

foi considerando por existir poucas referncias bibliogrficas com

descritivos simples funcionais e objetivos.

1.1.1 Delimitao do Tema

automotivos. O nvel e volume de novas funes automotivas esto em crescimento

1.3.1 Objetivo Geral

1.3.2 Objetivos Especficos

Estabelecer o fluxo de trabalho e as ferramentas computacionais

necessrias para desenvolvimento de funo para software automotivo.

elevado nvel de contedos eletroeletrnico ainda so desenvolvidos, fabricados e

1.5 MTODO DA PESQUISA

desenvolvido no Simulink, para verificar a etapa de MIL. Em seguida, a fase de SIL,

dSpace. Novamente exatamente as mesmas entradas de teste sero utilizadas,

distribuda. Um sistema de computao distribudo uma arquitetura caracterizada

(Powertrain control module, PCM), mdulo de gerenciamento da transmisso

Interfaces de Entrada (Sensores e Entradas de comunicao): Os sensores

Software de Controle: Baseado nas informaes de entrada, um algoritmo ou

ser realizada controlando ou regulando as sadas do veculo;

(Powertrain Control module), mdulo eletrnico geral ou GEM

(General Electronic module), mdulo de controle de carroceria ou

Control Module), mdulo de controle do painel de instrumentos ou IPC (Instrument

Figura 2 - ECUs automotivas

A abstrao da forma e caractersticas do hardware (ex.: ECUs, sistema de

Mapeamento das ECUs sob a arquitetura eltrica;

especificao do dicionrio de dados);

A Figura 3 apresenta a sequncia de desenvolvimento de software

Figura 3 - Sequncia de desenvolvimento de software automotivo

Foi assim apresentada uma viso geral de sistemas eletroeletrnico

2.1 V-MODEL PARA DESENVOLVIMENTO DE SOFTWARE AUTOMOTIVO

Figura 4 - Exemplo de diagrama do modelo em V

A composio da metodologia V-Model pode ser explicada observando seu

A estrutura funcional utilizada para validao via software, onde a planta

desenvolvimento de produto da OEM.

2.2 MODEL BASED DESIGN OU DESENVOLVIMENTO BASEADO EM MODELO

se crie a planta do sistema desejado e seu controlador utilizando a mesma

atualizaes de sistema ou para sistemas derivativos.

desenvolvidos em ferramentas de linguagem de domnio especfico, o que impede

Figura 5 - Mtodo de desenvolvimento tradicional

O MBD se inicia com o mesmo conjunto de requisitos do processo

A figura 6 ilustra o fluxo de trabalho facilitado do MBD. Todas as etapas se

Figura 6 - Desenvolvimento Baseado em Modelo (MBD)

No MBD de sistema de controles o desenvolvimento segue basicamente as

Definio dos Requisitos.

Inicialmente define-se todos os requisitos necessrios para o funcionamento