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

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

DEPARTAMENTO DE ELETRÔNICA

ENGENHARIA ELETRÔNICA

JOÃO HENRIQUE ZANDER NEME

APLICAÇÃO DO MÉTODO DE DESENVOLVIMENTO BASEADO EM

MODELOS PARA UMA FUNÇÃO DE SOFTWARE AUTOMOTIVO:

SISTEMA DE ILUMINAÇÃO EXTERNA

PONTA GROSSA

2014


APLICAÇÃO DO MÉTODO DE DESENVOLVIMENTO BASEADO EM

MODELOS PARA UMA FUNÇÃO DE SOFTWARE AUTOMOTIVO:

SISTEMA DE ILUMINAÇÃO EXTERNA

Trabalho de Conclusão de Curso apresentado como requisito parcial à obtenção do título de Bacharel, em Engenharia Eletrônica, do Departamento de Eletrônica, da Universidade Tecnológica Federal do Paraná.

Orientador: Prof. Dr. Max Mauro Dias Santos

PONTA GROSSA

2014

Ministério da EducaçãoUniversidade Tecnológica Federal do Paraná

Ponta Grossa

Departamento de EletrônicaEngenharia Eletrônica

TERMO DE APROVAÇÃO

APLICAÇÃO DO MÉTODO DE DESENVOLVIMENTO BASEADO EM MODELOS PARA UMA FUNÇÃO DE SOFTWARE AUTOMOTIVO: SISTEMA DE

ILUMINAÇÃO EXTERNA

por


Este Trabalho de Conclusão de Curso foi apresentado em 17 de Dezembro de 2014

como requisito parcial para a obtenção do título de Bacharel em Engenharia

Eletrônica. O candidato foi arguido pela Banca Examinadora composta pelos

professores abaixo assinados. Após deliberação, 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 Aprovação assinado encontra-se na Coordenação do Curso -

AGRADECIMENTOS

A esta universidade, seu corpo docente, direção e administração que

oportunizaram o apoio e estrutura necessária para adquirir conhecimentos

necessários 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 necessário para que este

trabalho fosse possível.

A Fernanda, minha noiva e futura esposa, por ser a razão e inspiração para

que eu sempre busque ser uma pessoa melhor e mais capacitada.

A Letícia, minha cunhada, pelas consultorias de normas e metodologias.

A Deus por ter me dado saúde e força para superar as dificuldades.

E a todos os colegas e amigos que direta ou indiretamente fizeram parte da

minha formação, o meu muito obrigado.

RESUMO

NEME, João Henrique Zander. Aplicação do Método de Desenvolvimento Baseado em modelos para uma Função de Software Automotivo: Sistema de Iluminação Externa. 2014. 60 folhas. Trabalho de Conclusão de Curso (Bacharelado em Engenharia Eletrônica) - Universidade Tecnológica 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 elétrica e eletrônica cresce do mesmo modo. Este fato impulsiona a complexidade do desenvolvimento destes sistemas. O mercado automobilístico é um setor agressivo, que cobra constante melhoria e diminuição de gastos com recursos. Este trabalho busca analisar o desenvolvimento baseado em modelos aplicando métodos como Model-in-the-Loop, Software-in-the-Loop e Rapid Control Prototyping e comprovar a eficácia destes métodos 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, João Henrique Zander. Model Based Design for Automotive Software Function: External Lighting System. 2014. 60 pages. Trabalho de Conclusão de Curso (Bacharelado em Engenharia Eletrônica) - 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 Design’s 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-in-the-Loop. Software-in-the-Loop. Rapid Control Prototyping.

LISTA DE ILUSTRAÇÕES

Figura 1 - Crescente demanda por componentes elétricos, eletrônicos e software

para veículos automotores.................................................................................11

Figura 2 - ECUs automotivas.....................................................................................18

Figura 3 - Sequência de desenvolvimento de software automotivo...........................19

Figura 4 - Exemplo de diagrama do modelo em V.....................................................20

Figura 5 - Método de desenvolvimento tradicional....................................................23

Figura 6 - Desenvolvimento Baseado em Modelo (MBD).........................................24

Figura 7 - Sequência de métodos para verificação de sistema embarcado..............26

Figura 8 - Workflow para o MIL demonstrando telas genéricas dos programas

utilizados.............................................................................................................27

Figura 9 - Workflow para o SIL demonstrando telas genéricas dos programas

utilizados.............................................................................................................28

Figura 10 - Workflow para o PIL demonstrando telas genéricas dos programas

utilizados e imagens ilustrativas das plataformas...............................................29

Figura 11 - Workflow para o HIL demonstrando telas genéricas dos programas

utilizados e imagens ilustrativas das plataformas...............................................30

Figura 12 - Plataforma de hardware MicroAutoBox®, da empresa dSpace..............32

Figura 13 - Comparação do desenvolvimento tradicional com o desenvolvimento do

Rapid Control Prototyping...................................................................................32

Figura 14 - Estratégia de controle e estágios de verificação.....................................33

Figura 15 - Sequência de desenvolvimento deste trabalho e ferramentas utilizadas

durante o processo.............................................................................................34

Figura 16 - Sistema externo de iluminação automotivo.............................................36

Figura 17 - Circuito para a luz indicadora de direção................................................38

Figura 18 - Diagrama de blocos de uma BCM...........................................................40

Figura 19 - Arquitetura funcional do sistema com as entradas de teste criadas para

validação............................................................................................................42

Figura 20 - Disposição dos subsistemas todos os sistemas de iluminação..............42

Figura 21 - Diagrama Stateflow® para a lógica das luzes de posição.......................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 posição da chave de ignição..............52

Figura 29 - Sinais de entradas utilizados para o caso de teste.................................53

Figura 30 - Entradas para a posição da chave de ignição.........................................54

Figura 31 - Entrada de teste referente ao nível de bateria........................................54

Figura 32 - Imagem da S-Function gerada a partir do modelo inicial........................56

Figura 33 - Entradas para a posição da chave de ignição.........................................57

Figura 34 - Ligações 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 - Comparação das entradas do modelo e as saídas verificadas nos scopes

............................................................................................................................61

Figura 39 - Quadro comparativo entre as saídas da fase MIL com as da fase SIL.. .64

Figura 40 - Comparação dos sinais de entrada e saída para o RPC........................65

LISTA DE SIGLAS E ACRÔNIMOS

LISTA DE SIGLAS

BCM Body Control ModuleCCM Central Control ModuleCTM Central Time ModuleEBCM Electronic Brake Control moduleECU Electronic Control Unit ECME/E

Engine Control Module Elétrica e Eletrônica

GEM General Electronic ModuleICMIPCMABXMBDPCMRCPSCMTCMTCUUPA

Intrsument Control Module Instrument Panel ControlMicroAutoBoxModel Based DesignPowertrain Control Module Rapid Control ProrotypingSuspension Control ModuleTransmission Control ModuleTransmission Control UnitUltrasonic Park Assis

LISTA DE ACRÔNIMOS

HIL Hardware-in-the-LoopMILOEM

Model-in-the-LoopOriginal Equipment Manufacturer

PILSIL

Processor-in-the-LoopSoftware-in-the-Loop

SUMÁRIO

1 INTRODUÇÃO ........................................................................................ 10 1.1 TEMA ....................................................................................................... 12

1.1.1 Delimitação do Tema ............................................................................... 12

1.2 PROBLEMA ............................................................................................. 13

1.3 OBJETIVOS ............................................................................................. 13

1.3.1 Objetivo Geral .......................................................................................... 13

1.3.2 Objetivos Específicos .............................................................................. 13

1.4 JUSTIFICATIVA ....................................................................................... 14

1.5 MÉTODO DA PESQUISA ........................................................................ 14 2 DESENVOLVIMENTO ............................................................................. 16

2.1 V-MODEL PARA DESENVOLVIMENTO DE SOFTWARE AUTOMOTIVO .........................................................................................

19

2.2 SISTEMA EXTERNO DE ILUMINAÇÃO AUTOMOTIVO ........................ 21

2.3 ARQUITETURA ELÉTRICA DO SISTEMA DE ILUMINAÇÃO EXTERNA

24

2.4 CONTROLE ELETRÔNICO DE BODY CCONTROL MODULE .............. 25 3 MODEL BASED DESIGN OU DESENVOLVIMENTO BASEADO EM

MODELO .................................................................................................27

3.1 DESENVOLVIMENTO TRADICIONAL VERSUS MODEL BASED DESIGN ...................................................................................................

28

3.2 MÉTODOS DE TESTE PARA MBD ........................................................ 30

3.3 RAPID CONTROL PROTOTYPING ........................................................ 33

3.4 MODEL-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE ILUMINAÇÃO AUTOMOTIVO .................................................................

37

3.4.1 Definição dos Requisitos ......................................................................... 37

3.4.2 Projeto do Controlador Baseado em Eventos ......................................... 38

3.4.3 Caso de teste ........................................................................................... 45

3.5 SOFTWARE-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE ILUMINAÇÃO AUTOMOTIVO ..................................................................

46

3.6 RAPID CONTROL PROTOTYPING PARA UM SISTEMA EXTERNO DE ILUMINAÇÃO AUTOMOTIVO ..................................................................

48

4 RESULTADOS ........................................................................................ 52

4.1 MODEL-IN-THE-LOOP ............................................................................ 52

4.2 SOFTWARE-IN-THE-LOOP .................................................................... 54

4.3 RAPID CONTROL PROTOTYPING .........................................................

55

5 CONCLUSÃO .......................................................................................... 57

REFERÊNCIAS .................................................................................................. 59

ANEXO A - Código em C gerado para a S-Function do SIL .......................... 61

10

1 INTRODUÇÃO

Atualmente é praticamente impossível imaginar um mundo sem sistemas

embarcados, principalmente para controle de sistemas mecatrônicos. Eles estão

presentes em toda a variedade de produtos, como utilidades domésticas, 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 domínio de aplicação automotivo, sistemas de controle embarcados

são atualmente o foco principal de inovações e melhoria na qualidade destes

produtos. Isto se dá em função da crescente demanda dinâmica dos atores deste

mercado

Este uso intensivo de componentes elétricos e eletrônicos na indústria

automotiva tem impulsionado inovações no desenvolvimento e produção que visam

diminuir custos, tempo de produção e melhorando a qualidade do produto final,

proporcionando maior conforto e segurança. Consequentemente, os engenheiros

têm trabalhado para aumentar a funcionalidade destes elementos de eletrônica em

substituição a sistemas mecânicos.

A primeira mudança significativa desta migração de componentes

mecânicos, hidráulicos e pneumáticos por componentes elétricos e eletrônicos é

observada por um estudo feito por MERCER et al. (2011 apud BROY, 2004). O

estudo foca a questão de como os fatores de custo no desenvolvimento de um

veículo irão mudar até o ano de 2015 em comparação ao ano de 2002. Em 2015,

prevê-se que, dos custos totais envolvidos em um produto automotivo, 35% serão

destinados a componentes de elétrica e eletrônica. Prevê-se ainda que enquanto o

custo relativo a funções de motorização dos carros terá um pequeno aumento, os

custos relacionados com funções elétricas e eletrônicas triplicará.

Segundo PLOSS (2008) de 1997 a 2008 a produção de veículos aumentou

44%, enquanto que a utilização de elementos de eletrônicos (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 dólares, e uma estimativa diz que em 2020

este valor subirá para 700 dólares.

11

Figura 1 - Crescente demanda por componentes elétricos, eletrônicos e software para veículos automotores

Fonte: PLOSS (2008)

O motivo destas mudanças se faz em função do menor custo, tamanho e

maior desempenho que os componentes elétricos e eletrônicos alcançam,

possibilitando a sua melhor aplicação no controle de sistemas mecatrônicos. O

conteúdo dos sistemas de software embarcado em automóveis cresceu rapidamente

nos últimos anos em função da inserção de componentes que implementam funções

elétricas e eletrônicas.

No domínio automotivo os subsistemas automotivos são gerenciados por

unidades de controle eletrônicas denominadas simplesmente por ECU (Electronic

Control Unit). Tem-se assim que um veículo, que é um conjunto de subsistemas,

possui diversos tipos de ECUs capazes de gerenciar funções como controle do

motor, transmissão, carroceria, entre outros. Para o gerenciamento de cada um

destes subsistemas as ECUs são nomeadas de acordo com o propósito de controle,

sendo ECM (Engine Control Module) para gerenciamento do motor, TCM

(Transmission Control Module) para a transmissão, 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 mecatrônico para o qual é considerado como um componente de

desenvolvimento, produção e serviços.

A engenharia de software automotiva consiste na adoção de métodos,

processos, ferramentas e padronizações adequados que assegurem aos produtos

automotivos um nível de qualidade, confiabilidade, segurança, satisfação as

regulamentações e conforto, perceptíveis e mensuráveis aos clientes e todos

envolvidos no processo.

Este processo consiste em três etapas, sendo: desenvolvimento; produção e

serviços. Para o caso de sistemas embarcados automotivos, levou-se em

consideração apenas o processo de desenvolvimento de software de controle

específicos.

Este trabalho tem como objetivo investigar e apresentar resultados ao nível

de engenharia de software automotivo utilizando metodologias, processos,

ferramentas e padronizações adequados, de modo a demonstrar como é possível

desenvolver e testar uma função de software embarcado automotivo.

Para isso serão explorados os métodos 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 específicas. Tem-se como objetivo final demonstrar

o valor destes métodos 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 iluminação externa de um veículo. Desta forma, busca-se

destacar a potencialidade dos métodos e ferramentas envolvidas no processo,

proporcionando aos interessados a capacidade de compreensão deste assunto.

Este tema foi considerando por existir poucas referências bibliográficas com

descritivos simples funcionais e objetivos.

13

1.1.1 Delimitação do Tema

Neste trabalho é aplicada a metodologia de desenvolvimento baseado em

modelo, o qual em inglês é conhecido como Model Based Design (MBD). A

metodologia MDB consiste na utilização de modernas ferramentas de

desenvolvimento gráfico para modelar o sistema físico a ser controlado. Desta forma

pode-se desenvolver a estratégia de controle fazendo uso de testes virtuais nas

fases preliminares do projeto. O desenvolvimento da estratégia de controle virtual

em ferramentas computacionais possibilita posteriormente a geração de código

automático de forma que se possa embarcar em um sistema final.

Desta maneira não é necessário se preocupar em desenvolver o

funcionamento do sistema de maneira textual e com codificação manual, algo que

pode consumir muito tempo e recursos. Ao contrário, todo o funcionamento pode ser

idealizado de maneira gráfica e através de diagramas de blocos, que resultam em

uma interface muito mais fácil de ser utilizada.

Estes modelos são desenvolvidos em ferramentas de software específicas e

podem ser facilmente simuladas sem necessariamente testar em uma plataforma

física. Na abordagem tradicional, os testes e simulações do código eram

complicados e por vezes impossíveis e principalmente podiam gerar muitos erros.

Em busca deste objetivo, este trabalho será balizado pela abordagem do

MDB, para desenvolver e testar a função desejada, considerando dois métodos

tradicionais de verificação de sistemas, Model-in-the-Loop (MIL) e Software-in-the-

Loop (SIL). Para também validar a função será realizado o Rapid Control Prototyping

(RCP) que permite que a validação seja feita em um hardware, com uma máquina

em tempo real. Com o RCP é possível verificar como as interfaces e a dinâmica da

função se comportam no mundo externo. O método de RCP desenvolvido foi o de

fullpass, que utiliza a máquina de prototipagem para substituir a ECU de maneira

completa, ao contrário do modo bypass que é utilizado para substituir apenas partes

individuais da ECU.

Estas abordagens apresentam inúmeras vantagens para o projeto. No caso

do MIL e SIL, como todo o processo se baseia na modelagem gráfica do

funcionamento do software em contraste com o modo textual de programação, há

14

uma economia enorme de tempo e recursos. Do mesmo modo, com o RCP existe

também grande economia de tempo que normalmente é gasto para o

desenvolvimento do código a ser embarcado em um hardware para a validação. O

RCP permite que um modelo seja diretamente embarcado em uma plataforma a fim

de ser verificado.

Para o desenvolvimento destes modelos serão utilizadas ferramentas

específicas. No caso do MIL e SIL serão utilizadas as ferramentas da MathWorks®

Matlab/Simulink® e Stateflow®. O Stateflow é um ambiente de simulação de

decisões combinacionais e sequenciais baseadas em máquinas de estados e

fluxogramas. Para a realização do RCP será utilizado além destes programas o

LabVIEW® da National Instruments® para simular as entradas de testes desta fase.

Durante o processo foi também utilizada a ferramenta da dSpace® chamada Control

Desk® que auxiliou na verificação dos modelos desenvolvidos.

1.2 PROBLEMA

Atualmente existe uma ampla utilização de sistemas embarcados

automotivos. O nível e volume de novas funções automotivas estão em crescimento

e com isso a complexidade segue o mesmo caminho O conhecimento e maturidade

de métodos, processos e ferramentas adequados, são fatores diferenciais a este

domínio de aplicação.

Desta forma a metodologia MBD é extensivamente utilizada para

desenvolvimento de software automotivo. No cenário nacional não existem

referências que possam proporcionar pesquisas e desenvolvimento nesta área. Isto

se deve devido ao fato de existem poucos profissionais que conheçam 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 estratégia de controle baseada em eventos para o sistema

de iluminação externa automotivo usando as metodologias de desenvolvimento

baseadas em modelo (MBD) e seguindo o mesmo fluxo de trabalho e fazendo uso

de ferramentas que são utilizadas por empresas e fornecedores atualmente.

1.3.2 Objetivos Específicos

Estabelecer o fluxo de trabalho e as ferramentas computacionais

necessárias para desenvolvimento de função para software automotivo.

Definir os requisitos de funcionamento do sub sistema de controle.

Modelar e simular a planta física a controlar.

Desenvolver a estratégia 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 geração do código em linguagem C automaticamente.

1.4 JUSTIFICATIVA

O setor automobilístico é extremamente dinâmico e exigente. De um lado o

consumidor procura cada vez mais melhorias em conforto, segurança, qualidade e

tecnologia fazendo com que o ciclo de vida dos sistemas embarcados seja curto e a

complexidade aumente.

Por outro lado a indústria pressiona desenvolvedores e fornecedores pela

diminuição de custos e tempo de trabalho para conseguir manter-se neste mercado

dinâmico e agressivo além de ter que satisfazer as restrições de regulamentação.

Com o aumento constante na demanda de automóveis, a necessidade de que a

produção aumente concomitantemente é mandatória.

16

O desenvolvimento de softwares automotivos utiliza métodos, conceitos e

ferramentas específicas que são definidas por grandes grupos formados por

montadoras e seus fornecedores. Porém, estes conceitos e conhecimentos vêm

para nosso país com determinada limitação e atraso, visto que os veículos com

elevado nível de conteúdos eletroeletrônico ainda são desenvolvidos, fabricados e

consumidos fora de nosso território nacional. Justificado pelo não 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 tecnológica ao máximo, melhorando e equalizando a mão de obra

nacional ao nível internacional de forma competitiva, com benefícios consideráveis e

mensuráveis no contexto mercadológico regional e nacional.

1.5 MÉTODO DA PESQUISA

Trata-se de um projeto que propõe o desenvolvimento de uma função de

software para um sistema de iluminação externo de um automóvel através de

métodos e ferramentas adequadas e padronizadas.

Inicialmente serão definidos os requisitos para a função de controle, para

isso será analisado as necessidades do usuário. Depois de mapeadas as

coordenadas do projeto será iniciada a modelagem do sistema físico a controlar. O

passo seguinte será o desenvolvimento do controlador para toda a planta. Para

tanto, serão utilizadas ferramentas computacionais específicas da MathWorks, como

o Matlab/Simulink®, Stateflow® e LabVIEW®

Após esta etapa serão definidos sinais de entrada para todas as etapas, de

modo a poder simular e observar os sinais de saída de cada caso do sistema de

controle. Estes sinais não serão gerados aleatoriamente, como alguns terão seu

funcionamento interligado, estes sinais de entrada serão idealizados de modo a

comprovar que não há nenhum erro de lógica no desenvolvimento do modelo.

Inicialmente estas entradas de teste serão 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 código

17

em linguagem C. Utilizando as mesmas entradas de testes serão será feita a

verificação do funcionamento do código. A fase de RPC será executada embarcando

o código diretamente em um hardware denominado MicroAutoBox® (MABX) da

dSpace. Novamente exatamente as mesmas entradas de teste serão utilizadas,

desta vez no MABX, de modo a verificar a estratégia de controle.

2 DESENVOLVIMENTO

Nesta seção, serão abordados alguns conceitos relevantes e fundamentais

ao desenvolvimento da pesquisa em relação às tecnologias envolvidas, explorando

metodologias, equipamentos, componentes e também softwares utilizados.

Os sistemas eletrônicos automotivos consistem em diversas ECUs, as quais

controlam subsistemas automotivos, que são interligados através de sistemas com

barramentos de comunicação, satisfazendo uma arquitetura computacional

distribuída. Um sistema de computação distribuído é uma arquitetura caracterizada

pela descentralização de funções. Estas funções trocam informações dentro do

barramento de comunicação através de mensagens, sendo que cada um destes

sistemas computacionais suporta funções de controle embarcado específicas.

Os tipos de ECUs, genericamente falando, incluem o módulo de

gerenciamento do motor (ECM), módulo de gerenciamento de powertrain

(Powertrain control module, PCM), módulo de gerenciamento da transmissão

(Transmission control unit, TCU), módulo de controle do freio (Electronic Brake

Control Module, EBCM), módulo de controle central (Central Control Module, CCM),

módulo de sincronismo central (Central Timing Module, CTM), módulo eletrônico

geral (General Electronic Module, GEM), módulo de controle do da carroceria (Body

Control Module, BCM), o módulo de controle de suspensão (Suspension Control

Module, SCM), módulo de assistência ao estacionamento (Ultrasonic Park Assist,

UPA), unidade de controle, ou controle de módulo, entre outros. De forma conjunta,

estes sistemas são muitas vezes referidos como o sistema computacional do

veículo. Uma ECU automotiva é genericamente formada pelos seguintes elementos:

Interfaces de Entrada (Sensores e Entradas de comunicação): Os sensores

capturam continuamente parâmetros significantes na forma de variáveis físicas ou

estados tais como velocidade do motor, velocidade do veículo ou temperatura e

converte-os para um valor elétrico correspondente; As entradas de comunicação

18

são interfaces padronizadas que recebem frames de dados e controle de

protocolos que contém sinais de grandezas físicas e estados.

Software de Controle: Baseado nas informações de entrada, um algoritmo ou

estratégia de controle implementado em software determina a ação que precisa

ser realizada controlando ou regulando as saídas do veículo;

Interfaces de Saída (Atuadores e Saídas de comunicação): As interfaces de saída

controlam os atuadores para realizar uma ação de controle determinada pela

malha de controle implementada no software executado sob o micro controlador

dentro da ECU; As saídas de comunicação são interfaces padronizadas que

transmitem frames de dados e controle de protocolos que contém sinais de

grandezas físicas e estados relacionados ao sistema a controlar.

Para o projeto de arquitetura elétrica e eletrônica distribuída automotiva,

existe uma forte separação entre o sistema lógico funcional e o sistema físico, onde o

sistema funcional abstrai qualquer aspecto físico e foca puramente sob as

dependências lógicas entre as funções de um veículo.

A Figura 2 apresenta de forma ilustrativa alguns exemplos de ECUs

automotivas que são empregadas em veículos, tais como o módulo de controle do

motor ou PCM (Powertrain Control module), módulo eletrônico geral ou GEM

(General Electronic module), módulo de controle de carroceria ou BCM (Body

Control Module), módulo de controle do painel de instrumentos ou IPC (Instrument

Panel Control) e a unidade de assistência de estacionamento ou UPA (Univesal

Park Assist).

.

19

Figura 2 - ECUs automotivasFonte: Elaborado pelo Autor(2014)

A abstração da forma e características do hardware (ex.: ECUs, sistema de

comunicação, etc) são fatores importantes de forma que possa proporcionar ao

projetista a capacidade de mapear aquelas funções definidas preliminarmente em

entidades executáveis sob as entidades computacionais físicas (ECUs distribuídas)

e determinam assim as características da rede de comunicação e hardware

envolvidos. Tem-se assim a necessidade em caracterizar:

Mapeamento das ECUs sob a arquitetura elétrica;

Descrição da especificação técnica do componente (ECM, EBCM, IPC,

BCM, etc.);

Determinação das relações de comunicação entre as ECUs (ex.:

especificação do dicionário de dados);

Especificações de diagnósticos das ECUs.

A Figura 3 apresenta a sequência de desenvolvimento de software

embarcado automotivo, em que a partir da parte superior tem-se inicialmente a

determinação dos subsistemas que compõe um à função global do veículo, em

seguida à definição das funções que serão distribuídas e por último como são

descritas em tarefas de forma que possam ser alocadas e executadas fisicamente

em ECUs distribuídas.

20

Figura 3 - Sequência de desenvolvimento de software automotivoFonte: Elaborado pelo Autor (2014)

Foi assim apresentada uma visão geral de sistemas eletroeletrônico

automotivos de forma genérica com o intuito de ilustrar como a engenharia de

software automotivo é empregada e possui diversos desafios para investigação

futura. A seguir é apresentado o tradicional método 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

Elétrica e Eletrônica (E\E) é baseado na metodologia de desenvolvimento V-Model,

que já possui considerável grau de maturidade. A especificação é 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 VFonte: Elaborado pelo Autor (2014)

A composição da metodologia V-Model pode ser explicada observando seu

ciclo de desenvolvimento na figura 4. Do lado esquerdo são definidos os requisitos,

especificações, projeto e implementação e na parte direita tem-se os testes para

verificação e validação de componentes, sistemas e conteúdos, 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 definição 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 física ou planta física, que

consiste em uma montagem física de componentes que simulam o sistema

planejado. Com as arquiteturas já desenvolvidas é possível gerar o código em

linguagem C do controlador.

Após o lado esquerdo do modelo em V finalizado passa-se para o lado

direito da figura 4. Nesta parte do desenvolvimento toda implementação é realizada.

Inicialmente valida-se o sistema

22

A estrutura funcional é utilizada para validação 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 física, que pode ser considerada a planta física do

modelo, é possível se realizar a verificação com o controlador sendo executado

tanto em software quanto em hardware. A verificação utilizando as plantas funcional

e física, até esta altura, é desenvolvida e testada em uma estrutura de diagramas de

blocos.

Com o código gerado automaticamente na quarta etapa é possível fazer a

validação do sistema em ambas as arquiteturas, porém utilizando o código em

linguagem C para controlar o processo e não mais modelos de diagramas de blocos.

Por último a integração funcional e a validação no veículo servem para fazer

a verificação e validação final em ambientes reais, seja em protótipos 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 adequadas para que cada fase e ciclo do

desenvolvimento possam ser posteriormente integrados ao processo de

desenvolvimento de produto da OEM.

2.2 MODEL BASED DESIGN OU DESENVOLVIMENTO BASEADO EM MODELO

Segundo Kelemenová (2013) atualmente as indústrias estão sob constante

pressão para reduzir o tempo de desenvolvimento de novos produtos. Trabalhar de

forma eficiente é indispensável para o sucesso em um mundo globalizado,

principalmente para empresas de alta tecnologia como a automobilística,

aeroespacial e de comunicação. Nestas empresas, controles eletrônicos são 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 função ou com um

sistema completo em um ambiente integrado de software.

23

A principal característica e vantagem do processo de desenvolvimento

baseado em modelo é o desenvolvimento em uma única plataforma, permitindo que

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

ferramenta computacional Isto facilita a visualização e o entendimento do sistema

assim como possíveis erros. O resultado é em um sistema funcional e de fácil

verificação, diminuindo significativamente a possibilidade de que os componentes

individuais não 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

definição dos pré-requisitos, passa pelo design, implementação e testes. O design

baseado em modelo está transformando o modo que engenheiros e cientistas

trabalham, tirando as tarefas do projeto do laboratório 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 comunicação entre diferentes

áreas de engenharia.

Algumas principais vantagens que o MBD oferece em comparação com as

abordagens tradicionais são (FANTUZZI, 2014):

a) Possibilidade de um ambiente de projeto comum, o que facilita a

comunicação, análise de dados e verificação do sistema entre os grupos

envolvidos no desenvolvimento;

b) Os engenheiros podem localizar e corrigir erros no início do projeto do

sistema, quando o tempo e custo para alguma modificação no sistema

são ainda pequenos;

c) Expansão das oportunidades de reutilização de projetos para

atualizações de sistema ou para sistemas derivativos.

2.3 DESENVOLVIMENTO TRADICIONAL VERSUS DESENVOLVIMENTO

BASEADO EM MODELOS

No processo desenvolvimento tradicional, a elaboração dos requisitos, o

desenvolvimento físico do protótipo, o desenvolvimento de códigos, o processo para

24

embarcar e posteriores testes são realizados sequencialmente em ambientes

diferentes e com muitos passos manuais. Os requisitos são descritos textualmente,

utilizando ferramentas de edição de texto. Os projetos são muitas vezes

desenvolvidos em ferramentas de linguagem de domínio específico, o que impede

testes do sistema até a fase de implementação em software ou hardware,

dependendo do caso. Os projetos são então traduzidos manualmente em código, o

que normalmente significa em um processo que consome muito tempo e propenso a

falhas. Em cada fase, defeitos podem surgir, porém estas falhas só serão

observadas na fase de implementação.

O resultado disso é que a fase final se torna em uma etapa maçante,

demandando muito tempo e recursos. A figura 5 demonstra a separação que este

processo causa no projeto

Figura 5 - Método de desenvolvimento tradicionalFonte: MathWorks, adaptado pelo autor(2014)

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

tradicional. Porém, ao invés de servir para desenvolver especificações de modo

textual, os requisitos são utilizados para desenvolver um modelo executável. Os

envolvidos no projeto utilizam este modelo para esclarecer e facilitar o entendimento

dos requisitos e especificações. Os projetos são então utilizados para desenvolver

um projeto detalhado. Utilizando ferramentas computacionais é possível simular o

sistema, descobrindo falhas e defeitos muito antes da implementação. Com o

modelo finalizado e verificado é possível gerar automaticamente o código e refazer

testes a partir destes códigos.

Este fluxo de trabalho permite que se permaneça sempre no mesmo

ambiente de trabalho, minimizando o trabalho necessário. Além disso é possível

iniciar os testes nas fases iniciais, já nos modelos recém projetados e verificar se os

25

requisitos estão sendo alcançados. Como resultado, falhas são encontradas e

corrigidas mais cedo do que no modelo de desenvolvimento tradicional, diminuindo o

tempo de desenvolvimento total e reduzindo a utilização de recursos.

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

conectam com facilidade, permitindo que se acesse e modifique características do

das fases iniciais de mesmo nas últimas etapas de implementação.

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.

Definição dos Requisitos.

Desenvolvimento da Arquitetura Funcional.

Desenvolvimento da Arquitetura Física.

Codificação.

Validação do Sistema.

Integração Funcional.

Validação do Veículo.

Inicialmente define-se todos os requisitos necessários para o funcionamento

do controle do sistema conforme esperado. Estes requisitos são descritos

26

textualmente e permitem que se desenvolva a arquitetura funcional do sistema, que

normalmente consiste em um modelo desenvolvido em ferramentas computacionais.

Após esta etapa é possível desenvolver fisicamente o modelo, construindo um

protótipo do sistema a ser controlado. Com o protótipo pronto é possível, utilizando o

modelo funcional gerar um código na linguagem desejada que será embarcado em

outras fases em um hardware escolhido. Com o modelo desenvolvido em software e

o código gerado é possível verificar o funcionamento do projeto utilizando entradas

de teste já desenvolvidas. Esta verificação pode ser via software ou hardware. Com

todas as funções verificadas é possível embarcar o código no sistema alvo final e

validar o sistema como um todo.

2.4 MÉTODOS DE TESTE PARA MBD

Normalmente no MBD são utilizadas tradicionais técnicas de validação

chamadas Model-in-the-Loop, Software-in-the-Loop, Processor in-the-Loop e

Hardware-in-the-Loop. A utilização destes métodos geralmente segue

cronologicamente esta sequência. Além disso, via de regra, as três primeiras etapas

utilizam as mesmas entradas de teste. Conforme demonstrado na Figura 7.

Figura 7 - Sequência de métodos para verificação de sistema embarcadoFonte: MathWorks (2014)

27

Apesar de que apenas os métodos de Model-in-the-Loop e o Software-in-

the-Loop serão utilizadas para validar a função desejada neste trabalho, é relevante

que todos os métodos sejam explicados. A seguir serão explicados um a um os

principais métodos utilizados para o MBD, porém muitas vezes outras denominações

são encontradas na bibliografia. Esta variação normalmente é causada quando o

sistema a ser desenvolvido é específico e obriga os engenheiros a fazer testes que

normalmente não seriam desenvolvidos na maior parte dos sistemas.

a) Model-In-the Loop (MIL): É o primeiro estágio de simulação que serve

como referência para os estágios seguintes e fornece os valores

mínimos e máximos das variáveis. A estratégia de controle e o modelo

físico são de desenvolvimento extremamente rápido, possibilitando

mudanças e testes rápidos 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 verificação são

desenvolvidos em Simulink®.

28

Figura 8 - Workflow para o MIL demonstrando telas genéricas dos programas utilizadosFonte: Elaborado pelo Autor (2014)

b) Software-In-the Loop (SIL): Esta simulação é o estágio onde a

ferramenta de geração automática de código fornece a estratégia de

controle estabelecida no MIL automaticamente em código em linguagem

C ou C++. Aqui o modelo de controle é um pouco mais real. Este é

essencialmente um teste para o sistema de geração de código (seja feito

de maneira automática ou manual). A interação do modelo diminui um

pouco com relação ao MIL, mas já é possível enxergar erros de

codificação. O fluxograma desta fase pode ser observado na Figura 9.

Conforme a figura ilustra, o controlador é representado pelo código em

linguagem C e a planta segue sendo representada por um diagrama de

blocos de Simulink.

29

Figura 9 - Workflow para o SIL demonstrando telas genéricas dos programas utilizadosFonte: Elaborado pelo Autor (2014)

c) Processor-In-the Loop (PIL): nesta fase não se roda mais o código do

sistema em simulação, ao invés disso ele é implementado em um micro

controlador. Enquanto o código 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

execução em um sistema embarcado. Neste estágio as principais tarefas

envolvem medição de memória, perfil de tempo de execução e

verificação do código alvo. Aa Figura 10 ilustra as plataformas

envolvidas nesta etapa.

30

Figura 10 - Workflow para o PIL demonstrando telas genéricas dos programas utilizados e imagens ilustrativas das plataformasFonte: Elaborado pelo Autor (2014)

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 através das entradas apropriadas do controlador. A planta está

rodando em um computador em tempo real com entradas e saídas

simuladas para fazer com que o controlador acredite que está instalado

na planta real. Neste caso a única diferença entre a aplicação final e o

ambiente HIL é a fidelidade do modelo da planta e os vetores teste que

estão sendo utilizados. O HIL é geralmente utilizado para validação de

software ao invés de desenvolvimento, pois a interação do modelo é

muito lenta. Apesar disso, este teste é muito próximo da realidade da

aplicação final e por isso deixa claro a maior parte dos problemas que

poderão ser encontrados. A fase de HIL é ilustrada pela Figura 11.

31

Figura 11 - Workflow para o HIL demonstrando telas genéricas dos programas utilizados e imagens ilustrativas das plataformasFonte: Elaborado pelo Autor (2014)

2.5 RAPID CONTROL PROTOTYPING

Outro importante e valioso método de validação para softwares automotivos,

e que será também utilizado neste trabalho, é conhecido como Rapid Control

Prototyping (RPC)

O principal desejo de Engenheiros que trabalham com projetos

automobilísticos é poder se concentrar completamente em funções das Unidades

Eletrônicas de Controle (ECU) e executar rapidamente testes em seus sistemas

alvo. Não apenas testes off-line, como também em veículos reais ou em bancos de

teste. Neste cenário é preciso de uma rápida confirmação de que o projeto está indo

no caminho certo.

O RCP é um processo de calibração dos algoritmos de controle em um

protótipo de hardware. Este processo permite que testes sejam feitos antes de que

haja uma ECU disponível para o processo. As plataformas RCP normalmente

oferecem um método que permita que sejam importados modelos matemáticos de

32

um software e executados em um sistema operacional em tempo real com entradas

e saídas físicas.

O RCP permite aos engenheiros testar e interagir suas estratégias de

controle rapidamente. Consequentemente, os modelos matemáticos são importados

automaticamente com MATLAB/Simulink® em uma máquina em tempo real com

interfaces reais e entradas e saídas para se conectar aos sistemas do mundo real.

Além disso esse processo diminui o tempo de desenvolvimento, permitindo

que correções sejam feitas no início do processo produto. Essa oportunidade de

conseguir verificar o processo em fases iniciais do projeto permite que erros sejam

corrigidos e mudanças serem feitas enquanto o custo ainda é pequeno.

Segundo Dong (2008), no RCP as plantas e o controlador são

implementados em uma placa de processamento de sinal digital, permitindo um fácil

ajuste de vários parâmetros da planta e do controlador.

De acordo com Fang et al. (2009) o principal conceito do RCP é entender os

requisitos do sistema e traçar um plano geral de desenvolvimento, levando em

consideração a eficiência e rapidez, e então 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 satisfatório. Falhas de projeto podem ser encontradas

imediatamente, e as correções podem ser realizadas imediatamente, visando a

eficiência de tempo e a confiabilidade do sistema.

Recentemente, cada vez mais empresas estão oferecendo soluções para o

desenvolvimento de RCP. O software da MathWorks®, Matlab/Simulink® é talvez a

ferramenta mais conhecida e amplamente usada para modelagem e simulação de

sistemas. No quesito hardware o MicroAutoBox® (MABX) da dSpace®, que pode ser

visto na Figura 12, é uma ferramenta poderosa, com diversas entradas e saídas

digitais e analógicas que permitem a simulação de sistemas complexos. Usando

Matlab/Simulink® com o MicroAutoBox® da dSpace® pode-se facilmente realizar

testes para validar qualquer modelo.

33

Figura 12 – Plataforma de hardware MicroAutoBox®, da empresa dSpaceFonte: dSpace (2014)

Os blocos e diagramas de estado do Simulink® e Stateflow® são os pontos

de partida para o desenvolvimento da função para prototipagem. Segundo Fang et al

(2009) eles representam o controlador e o seu ambiente de forma gráfica e podem

ser simulados off-line para uma validação inicial e não minuciosa. Para realizar o

RCP, os diagramas de bloco criados em ambiente Simulink® são implementados

diretamente em um sistema de prototipagem e rodados em tempo real, sem a

necessidade de qualquer programação manual. O hardware de prototipagem

geralmente possui um poder de processamento maior do que o ECU real, portanto,

não há necessidade de se preocupar com limitações de hardware.

Neste ambiente de prototipagem rápida o desenvolvimento pode avançar

muito mais rápido, já que o profissional responsável pelo design de controle pode

facilmente executar funções que, em um ambiente de desenvolvimento tradicional,

normalmente seria executado por três departamentos. A Figura 13 compara os

procedimentos do RCP com os procedimentos tradicionais.

Figura 13 - Comparação do desenvolvimento tradicional com o desenvolvimento do Rapid Control Prototyping

Fonte: Elaborado pelo Autor (2014)

34

Atualmente os softwares controle automobilístico são submetidos a quatro

etapas de verificação (Figura 14), a saber:

Simulação Offline (como MIL).

Rapid Control Prototyping.

Simulação HIL

Validação na ECU.

Figura 14 - Estratégia de controle e estágios de verificaçãoFonte: Elaborado pelo Autor (2014)

As duas primeiras fases de verificação destinam-se a verificar o

desempenho funcional do algoritmo de controle. Esta verificação é realizada no

modelo de estratégia de controle antes do o software de produção ser gerado. As

últimas duas fases de verificação são executadas em software e incorporado na

ECU.

35

3 DESENVOLVIMENTO

Com todas as etapas que serão realizadas no trabalho apresentadas será

iniciado a parte prática do trabalho. O fluxo de trabalho foi organizado de maneira

que todas as arquiteturas e controladores foram modelados respeitando a sequência

tradicional do MBD. Inicialmente modelou-se a arquitetura funcional e seu

controlador em Simulink®. Após esta fase foi gerado o código em linguagem C para

o controlador para possibilitar a etapa de SIL. Por último as entradas e saídas da

planta foram alteradas com blocos específicos para o hardware utilizado durante a

fase de RCP. Esta sequência é ilustrada na Figura 15.

Figura 15 – Sequência de desenvolvimento deste trabalho e ferramentas utilizadas durante o processo


Inicialmente será demonstrado todos os dados utilizados e desenvolvidos

para que fosse possível realizar as etapas separadamente, incluindo as entradas de

testes que serão utilizadas para a verificação. Depois de todos os dados

demonstrados e explicados serão demonstrados os resultados, seguindo a mesma

ordem de desenvolvimento.

A análise da verificação será feita apenas durante a fase de MIL, pois com

todos os requisitos alcançados nesta fase é possível apenas comparar estes

resultados com os das outras fases.

36

3.1 SISTEMA EXTERNO DE ILUMINAÇÃO AUTOMOTIVO

O sistema de iluminação de um automóvel é constituído por dispositivos de

iluminação e de sinalização montados ou integrados em várias partes de um veículo.

Estas podem incluir: a frente, as laterais, a traseira e, em alguns casos, a parte

superior do veículo. O objetivo deste sistema é fornecer a iluminação para o

motorista. Isso permite a operação segura do veículo à noite e aumenta a

visibilidade para o motorista. Este sistema também facilita a visualização do veículo

por terceiros, a sua posição, seu tamanho, a direção da viagem, e as intenções do

motorista em relação a direção e velocidade de deslocamento.

Nos sistemas atuais de iluminação externa automotivo os principais itens

para definição dos pré-requisitos se baseiam nos seguintes elementos:

O estado (ligado ou desligado) dos interruptores de acionamento de

cada um dos casos de iluminação, como o de escolha do tipo de luz

frontal, de acionamento de luzes de indicação de direção, pedal de freio

ou engate de marcha ré;

Nível de tensão fornecida pela bateria;

Posição da chave na ignição (“off", acessório ou acessório (acc), on e

crank).

As opções normalmente disponíveis no interruptor para a escolha do tipo de

luz frontal são: desligado; luzes de posição e luz baixa. A luz alta normalmente

possui um interruptor próprio.

A posição “crank” é a posição que dá partida ao motor, logo após a posição

“on”, que permite que todos os sistemas e sensores do carro sejam acionados. A

posição “acc” é uma posição intermediária 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 aparência não estão presentes

em grande parte dos modelos. Portanto as luzes que serão analisadas serão:

a) Luzes dianteiras: luzes indicadoras de direção ou pisca-pisca (esquerda

e direita), luz baixa, luz alta e luzes de posição;

37

b) Luzes traseiras: luz de ré, luz de freio, luzes indicadoras de direção ou

pisca-pisca (esquerda e direita) e luzes de posição.

A Figura 16 apresenta uma distribuição física do sistema de iluminação

exterior no veículo.

Figura 16 - Sistema externo de iluminação automotivoFonte: Elaborado pelo Autor (2014)

As descrições de cada uma das funções do sistema externo de iluminação

segundo o Anexo 1 da Lei 9.503 de 1997, conhecida como Código de Trânsito

Brasileiro, estão descritas abaixo:

a) Luzes de posição: é a "luz do veículo destinada a indicar a presença e a

largura do veículo" (Anexo 1, Lei 9.503 de 1997). A luz de posição é

obrigatória à noite quando o veículo estiver parado para carga e descarga de

passageiros ou mercadorias e facultativa no caso de neblina, chuva forte, ou

cerração (artigo 40, incisos IV e VII, Lei 9.503 de 1997). Para ativar as luzes

de posição são necessárias algumas condições: a posição da ignição deve

estar em “Acessório” e o interruptor de luz em “luzes de posição”. Caso a

chave de ignição for virada no sentido horário as luzes de posição

continuarão acesas, só sendo desativadas caso a chave seja girada no

sentido anti-horário para a posição “off”.

b) Luz baixa: é "o facho de luz do veículo destinada a iluminar a via diante do

veículo, sem ocasionar ofuscamento ou incômodo injustificáveis aos

condutores e outros usuários da via que venham em sentido contrário" (Anexo

1, Lei 9.503 de 1997). Ela é obrigatória em dois casos; à noite em qualquer

38

situação e de dia em túneis providos com iluminação pública (artigo 40, inciso

I, Lei 9.503 de 1997). Na maioria dos sistemas de iluminação de carros este

caso é ativado quando a ignição está em qualquer posição diferente de “off” e

o interruptor de luz está em “luz baixa”.

c) Luz alta: é "o facho de luz do veículo destinado a iluminar a via até uma

grande distância do veículo" (Anexo 1, Lei 9.503 de 1997). É mandatório em

vias não iluminadas quando não houver outro veículo vindo na direção

contrária ou à frente (artigo 40, inciso II, Lei 9.503 de 1997). A luz alta será

ativada quando a posição da ignição não estiver em “off” e o interruptor

estiver em “luz alta”.

d) Luz indicadora de direção ou pisca-pisca: é a "luz do veículo destinada a

indicar aos demais usuários da via que o condutor tem o propósito de mudar

de direção para a direita ou para a esquerda" (Anexo I, Lei 9.503 de 1997).

Há duas maneiras de ativar luz indicadora com a ignição em qualquer posição

exceto “off” e o interruptor da luz indicadora na posição para cima ou para

baixo. Se o interruptor estiver para cima as luzes frontal e traseira do lado

direito serão acesas intermitentemente. Já se o interruptor estiver para baixo

as luzes frontal e traseira do lado esquerdo serão ativadas intermitentemente.

A outra forma de ativar as luzes indicadoras é o botão de “alerta” ser

apertado. Nesta situação as luzes direita e esquerda, frontais e traseiras,

serão ativadas intermitentemente de forma sincronizada, independentemente

da posição da chave de ignição.

e) Luz de marcha ré: é "a luz do veículo destinada a iluminar atrás do veículo e

advertir aos demais usuários da via que o veículo está efetuando ou a ponto

de efetuar uma manobra de marcha à ré" (Anexo I, Lei 9.503 de 1997).

Comumente são utilizadas lâmpadas de luz branca para este sistema. A luz

de marcha ré é ativada sempre que a marcha ré for acionada e a ignição se

encontrar em qualquer posição além de “off”.

f) Luz de freio: é "a luz do veículo destinada a indicar aos demais usuários da

via, que se encontram atrás do veículo, que o condutor está aplicando o freio

de serviço" (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.

39

3.2 ARQUITETURA ELÉTRICA DO SISTEMA DE ILUMINAÇÃO EXTERNA

O sistema elétrico de controle do sistema de iluminação externa era baseado

nos componentes elétricos tradicionais, sem o uso das facilidades da eletrônica. A

Figura 17 demonstra um exemplo de esquema elétrico do circuito de luz indicadora

de direção.

Figura 17 - Circuito para a luz indicadora de direçãoFonte: Elaborado pelo Autor (2014)

Como é possível visualizar o sistema de controle era totalmente controlado a

partir de chaves. Este sistema, por ter funcionamento mecânico, além de ser

extremamente suscetível a desgaste podendo causar falhas, necessita de tempo

para ser montado e, no caso da alteração em sua estratégia de controle, precisa ser

alterado por completo. Em um sistema moderno, controlado por softwares este

problema não se observa, visto que não há desgaste no sistema de controle e caso

haja necessidade de alguma alteração, basta que o software seja alterado e

atualizado.

4

3.3 CONTROLE ELETRÔNICO DAS FUNÇÕES DE CARROCERIA

40

As várias peças eletrônicas de um veículo podem ser controladas por um

módulo, desde o sistema de iluminação do carro até as fechaduras das portas, cada

parte tem um módulo que a controla. Nas configurações dos automóveis atuais,

esses módulos já estão operando sob uma única montagem Este módulo em

questão é o módulo de controle das funções de carroceria, conhecido como body

control module (BCM). O BCM executa uma função muito complexa e utiliza uma

grande gama de dispositivos de entrada e saída. Os dispositivos de entrada referem-

se a componentes que alimentam dados no módulo (como sensores e resistores

variáveis) para ajudar o módulo a determinar sua resposta. Enquanto isso, os

dispositivos de saída são aqueles que o módulo utiliza para produzir a sua resposta

à entrada enviada para ele. Estas peças podem incluir relés e solenóides que que

podem ligar e desligar dispositivos.

Segundo Liuguilong (2013) na eletrônica automotiva, a BCM é o principal

componente de uma ampla gama de funções. Pode compará-lo com o sistema

nervoso central de um ser humano. O sistema nervoso controla a coordenação no

corpo humano através da transmissão de sinais. Enquanto isso, o BCM regula a

atividade de coordenação entre as diferentes partes de um carro também através de

sinais.

O BCM torna tudo mais simples na operação de dispositivos eletrônicos em

um carro. No entanto, apesar de oferecer uma ampla gama de benefícios se

comparado as configurações anteriores, ele também apresenta problemas relativos

a sua estrutura. Quando houver um problema na BCM, isso causará mal

funcionamento em várias partes que ele controla, como o funcionamento

intermitente no levantamento de vidros elétricos, 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 funções controladas.

41

Figura 18 - Diagrama de blocos de uma BCMFonte: Freescale (2014)

3.4 MODEL-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE ILUMINAÇÃO

AUTOMOTIVO

Com a definição de todos os princípios do MBD pode-se implementar esta

metodologia para desenvolver o projeto do sistema externo de iluminação

automotivo. Para isso deve-se seguir os passos definidos anteriormente.

3.4.1 Definição dos Requisitos

Para iniciar o projeto é necessário definir os pré-requisitos de cada

subsistema a ser controlado. Os pré-requisitos serão apresentados separados caso

a caso, no Quadro 1.

42

Para ativar as luzes de posição:

REQ-01: a posição da ignição deve estar em "on", "acessório", ou "crank".

REQ-02: o interruptor de luz deve estar em "luzes de posição".

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 indicação de posição esquerda:


REQ-08: o interruptor da luz de indicação de posição deve ser direcionado para

baixo.

Para ativar as luzes de indicação de posição direita:

REQ-09: a posição da ignição deve estar em "on", "acessórios", ou "crank".

REQ-10: o interruptor da luz de indicação de posição deve ser direcionado para

cima.

Para ativar as duas luzes indicadoras de posição 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 nível de tensão da bateria deve estar entre 16 e 9 Volts.

Quadro 1 - Definição dos requisitos de funcionamentoFonte: Elaborado pelo Autor (2014)

3.4.2 Projeto da Arquitetura Funcional

Após a definição dos requisitos é possível desenvolver a planta ou

arquitetura funcional do sistema desejado. A arquitetura em questão é modelada

utilizando-se blocos de Simulink® do Matlab®. Cada caso do sistema de iluminação

estudado é representado por um bloco de sub-rotina no Simulink®. Na Figura 19 é

possível ver a tela principal da arquitetura funcional desenvolvida.

43

Figura 19 – Arquitetura funcional do sistema com as entradas de teste criadas para

validação


É importante considerar que o bloco de signal builder que aparece em

vermelho na Figura 19 (de rótulo “Lamps”) foi criado para gerar um sinal de erro

caso alguma das lâmpadas esteja queimada. Este sinal, em um veículo real, pode

ser gerado por um sensor de corrente instalado nas lâmpadas. Caso este sinal seja

alto significa que a lâmpada está funcionando, caso contrário ele terá valor baixo irá

gerar um sinal de erro. Porém apesar desta funcionalidade estar ativa, nos testes

44

estes sinais serão considerados sempre habilitados, significando que todas as

lâmpadas estão funcionando corretamente.

No subsistema central, mostrado na Figura 19, está localizado todos os

casos a ser analisados. A Figura 20 demonstra a organização destes casos dentro

do subsistema.

Nesta figura é possível observar que os subsistemas estão localizados do

lado direito da imagem. Cada um destes subsistemas se refere a um dos casos de

iluminação considerados (luz de posição, Luz baixa, luz alta, etc.). Do lado esquerdo

está localizado o subsistema que gera o sinal que habilita o sistema. Este sinal é

dependente das condições da bateria e da posição da chave de ignição. Este sinal

será alto apenas quando a bateria estiver dentro do nível aceitável e a chave de

ignição esteja em acc, on ou crank.

Os sinais que alimentarão estes sistemas serão demonstrados na seção

3.4.4, onde o caso de teste será apresentado.

Figura 20 - Disposição dos subsistemas todos os sistemas de iluminaçãoFonte: Elaborado pelo Autor (2014)

45

Cada subsistema destes vistos na Figura 20 contém a lógica de

funcionamento dos casos. Esta lógica desenvolvida é o controlador do sistema.

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

demonstrarão todos os gráficos de Stateflow® desenvolvidos, na seguinte ordem:

Luz de posição, luz baixa, luz alta, luz de freio, luz de pisca direito, luz de pisca

esquerdo e luz de ré. Para facilitar o entendimento dos gráficos será apresentada

antes de cada caso os requisitos necessários para seu funcionamento.

Para que o sistema de luzes de posição seja habilitado é necessário que os

seguintes requisitos sejam cumpridos:

O interruptor da luz de posição esteja acionado (PLS=1);

A chave de ignição não esteja em off e a bateria esteja em nível aceitável

(IP=1);

O sinal de que a lâmpada está funcionando esteja alto (PL1=1);

Desta forma o sinal de saída que habilita o sistema de luzes de posição será

alto (PL=1), caso contrário ele terá valor baixo (PL=0).

Observando estes requisitos foi possível desenvolver os diagramas em

Stateflow®. O diagrama referente ao funcionamento das luzes de posição é

demonstrado na figura 21.

46

Figura 21 - Diagrama Stateflow® para a lógica das luzes de posiçãoFonte: Elaborado pelo Autor (2014)

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

sendo necessário apenas inserir as condições para que o sistema mude de estado.

Para que a luz baixa seja ativada é necessário que seus requisitos também

sejam cumpridos. Estes requisitos são:

O interruptor da luz baixa esteja acionado (LS=1);


(IP=1);

O sinal de que a lâmpada está funcionando esteja alto (LB1=1);


alto (LB=1), caso contrário ele terá valor baixo (LB=0).

Com os requisitos listados foi possível desenvolver o diagrama Stateflow®

demonstrado na figura 22.

47

Figura 22 - Diagrama Stateflow® para controlar o funcionamento da luz baixaFonte: Elaborado pelo Autor (2014)

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

requisitos necessários são:

O interruptor da luz alta esteja acionado (FBS=1);


(IP=1);

O sinal de que a lâmpada está funcionando esteja alto (FB1=1);


alto (FB=1), caso contrário ele terá valor baixo (FB=0).

Com estes requisitos foi possível gerar o gráfico em Stateflow que controla o

funcionamento da luz alta. Este gráfico é demonstrado na figura 23.

48

Figura 23 - Diagrama Stateflow® referente a luz altaFonte: Elaborado pelo Autor (2014)

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

funcionamento seja habilitado é necessário o cumprimento dos seguintes requisitos:

O pedal de freio seja acionado (BLS=1);


(IP=1);

O sinal de que a lâmpada está funcionando esteja alto (BL1=1);


alto (BL=1), caso contrário ele terá valor baixo (BL=0).

Com estes requisitos foi possível desenvolver o diagrama Stateflow® de

funcionamento deste sistema. A figura 24 demonstra este diagrama.

49

Figura 24 - Diagrama Stateflow® referente a luz de freioFonte: Elaborado pelo Autor (2014)

As luzes de pisca têm seu funcionamento idêntico, sendo diferenciadas

apenas pela posição da alavanca que se encontra no volante. Além disso, caso o

botão de alerta seja acionado, ambos os casos deverão ser ativados. Portando para

o pisca direito é possível listar os seguintes requisitos

A alavanca do pisca deve estar deslocada para cima (RLS=1);


(IP=1);

O sinal de que a lâmpada 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 contrário ele terá valor baixo (RL=0).

Com estes requisitos definidos, foi possível desenvolver o diagrama

Stateflow® da figura 25.

50

Figura 25 - Diagrama Stateflow® referente a luz de pisca direitoFonte: Elaborado pelo Autor (2014)

Considerando o funcionamento do pisca direito é possível listar os seguintes

requisitos

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


(IP=1);

O sinal de que a lâmpada 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 contrário ele terá valor baixo (LL=0).

Com estes requisitos definidos, foi possível desenvolver o diagrama Stateflow® da

figura 26.

51

Figura 26 - Diagrama Stateflow® referente a luz de pisca esquerdoFonte: Elaborado pelo Autor (2014)

Por último foi criado o controlador da luz de ré. Para que seu funcionamento

seja habilitado é necessário o cumprimento dos seguintes requisitos:

A alavanca da transmissão seja colocada na posição de marcha ré (RLS=1);


(IP=1);

O sinal de que a lâmpada está funcionando esteja alto (RL1=1);


alto (RL=1), caso contrário ele terá valor baixo (RL=0).

Com estes requisitos foi possível desenvolver o diagrama Stateflow® de

funcionamento deste sistema. A figura 27 demonstra este diagrama.

52

Figura 27 - Diagrama Stateflow® referente a luz de réFonte: Elaborado pelo Autor (2014)

Um controle importante a ser representado é o que define o funcionamento

de todo os sistemas de acordo com a posição da chave de ignição e o nível 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 são os seguintes:

A chave de ignição esteja na posição acc, run ou Crank (Acc=1,

Run=1 ou Crank=1);

O nível da bateria esteja em um nível aceitável (Batt=1).

Com estes requisitos foi criado o diagrama da figura 28.

53

Figura 28 - Diagrama Stateflow® referente a posição da chave de igniçãoFonte: Elaborado pelo Autor (2014)

3.4.4 Caso de teste

Para motivos de simulação, valores para as variáveis de entrada foram

criados para simular a operação de cada caso, e nomeadas de acordo.

No sistema de iluminação externa existem tarefas que podem ser ativadas por

sinais diferentes, caso das luzes indicadoras de posição (pisca-pisca). Esta tarefa

pode ser ativada tanto pelo seu switch próprio ou pelo sinal de alerta. Portanto para

comprovar que o sistema não falha em um momento que o sinal de alerta está

ativado os sinais de entrada referente a estes sistemas foram criados de maneira a

54

comprovar que a lógica do controlador funciona corretamente. Os sinais de entrada

podem ser vistos na Figura 29.

Figura 29 - Sinais de entradas utilizados para o caso de testeFonte: Elaborado pelo Autor (2014)

Outro fator levado em consideração nos pré-requisitos é a posição da chave

de ignição. Apesar de neste caso específico, para todos os casos, a única posição

que desabilita as luzes é a posição “off”, é importante que sejam simuladas

alterações nas posições da chave. Para isso foi criado outro grupo de sinais de

entrada para as posições Acessório, On e Crank, como se vê na Figura 30.

55

Figura 30 - Entradas para a posição da chave de igniçãoFonte: Elaborado pelo Autor (2014)

Para que todos os sistemas do carro funcionem é necessário que o nível da

bateria esteja em um valor aceitável. Na maioria dos carros de passeio este nível

está na faixa de 9 a 16 volts. Portanto foi criado uma entrada de teste que simula a

variação da tensão da bateria no tempo. Este sinal é demonstrado na figura 31.

Figura 31 – Entrada de teste referente ao nível de bateriaFonte: Elaborado pelo autor (2014)

Como dito anteriormente, este cenário foi desenvolvido de modo a mostrar

que não há erros na lógica do sistema. É possível ver que:

O interruptor das luzes de posição é ativado antes que a chave de

ignição passe para a posição “Acc”;

O botão de alerta é acionado enquanto o indicador de posição esquerdo

está ativado e depois o mesmo ocorre com o do lado direito;

O nível da bateria chega a um nível inferior a 9 Volts quando várias

entradas estão ativas.

56

3.5 SOFTWARE-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE ILUMINAÇÃO

AUTOMOTIVO

O método de Software-in-the-loop combina a um simulador flexível 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 também na fase de testes

e, potencialmente oferece uma enorme economia de custos, maximizando a

reutilização de código e minimizando o esforço necessário para o desenvolvimento

de software.

Na simulação do SIL parte do modelo já existe na ferramenta utilizada para

esta simulação, e no caso deste trabalho o Simulink®. Esta ferramenta já oferece a

opção de se criar o código em linguagem C do modelo desenvolvido na fase de MIL.

Acessando a função de geração de uma função chamada de S-Function,

automaticamente o Simulink® cria o código referente ao funcionamento do modelo e

embarca em um bloco do próprio programa.

Com este bloco é possível rodar novamente a simulação, com os mesmos

valores de entrada e verificar se as saídas estão idênticas ao teste realizado para o

MIL e principalmente se estão de acordo com o esperado.

O modelo no Simulink® para o MIL tem uma aparência muito próxima com

com o modelo da fase de MIL, porém o bloco principal não é mais um subsistema

com outros blocos, e sim apenas um bloco que possui em seu interior o código em

linguagem C que funciona exatamente como o modelo com os blocos.

Para provar que este o código é idêntico ao subsistema com a lógica

construída com blocos, nova simulação é feita com as mesmas entradas e as saídas

analisadas. Este procedimento será demonstrado no item 4.2.

O código que foi gerado automaticamente e inserido dentre do bloco de

Simulink® será disponibilizado no Apêndice A.

A figura 32 demonstra o modelo funcional desenvolvido para o SIL, a partir

do modelo do MIL, com o código em linguagem C embarcado no bloco principal.

57

Figura 32 - Imagem da S-Function gerada a partir do modelo inicialFonte: Elaborado pelo Autor (2014)

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

ILUMINAÇÃO AUTOMOTIVO

Segundo o site da National Instruments, com o RCP é possível projetar o

algoritmo de controle e executar uma simulação off-line em um computador. Para

que seja possível executar o RCP é necessário primeiramente fazer alterações no

modelo desenvolvido no Simulink® durante o MIL. Para verificar o primeiro modelo

58

era necessário apenas os próprios scopes do Simulink®, pois o processo era

validado apenas com simulação no programa. Para o RCP, é necessário embarcar o

código em um hardware externo. Como dito anteriormente o hardware em questão é

o MicroAutoBox® da dSpace.

Para isso é necessário trocar as saídas normais do Simulink® para os

blocos de entradas e saídas digitais (DIO) do MicroAutoBox®. Estes blocos ficam

disponíveis para o usuário após a instalação dos programas que são utilizados no

processo. Além disso, a dSpace disponibiliza vários modelos de MicroAutoBox®, o

que foi utilizado para este trabalho especificamente foi o de código DS1401. A

Figura 33 demonstra como ficou o novo modelo já utilizando os blocos do MABX.

Após esta preparação, é necessário fazer algumas parametrizações nas

configurações do Simulink®. As mais importantes e que merecem ser mencionadas

aqui são a de definir o sistema alvo a ser utilizado (MABX DS1401) e de acertar o

passo de cálculo com os clocks dos gráficos de Stateflow®.

Figura 33 - Entradas para a posição da chave de ignição


59

Para o funcionamento da luz de pisca foi criada uma lógica de

funcionamento que simula a atividade real

Como o RCP não faz a simulação em software do sistema, não foi utilizado

sinais gerados pelo Simulink®. Para simular os sinais de entrada no MABX e

visualizar as saídas, foi utilizado um instrumento de aquisição de sinal da Texas

Instruments® chamado Data Aquisition (DAQ) em conjunto com o software

LabVIEW® da mesma empresa. A Figura 34 demonstra as ligações feitas na DAQ.

Figura 34 - Ligações feitas entre o MABX e a DAQFonte: Elaborado pelo Autor (2014)

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 RCPFonte: Elaborado pelo Autor (2014)

Em ambiente LabVIEW® foram criadas duas VI’s diferentes, uma

responsável pela geração, nomeada “Gerador” dos sinais de teste a serem injetados

nas entradas so MABX, e outra, nomeada “Aquisição” responsável pela leitura das

60

saídas do MABX para comparação e posterior validação. Estes instrumentos virtuais

foram criados de uma maneira que possam ser reutilizados para outras funções, e

respeitando as seguintes características.

Gerador:

Máximo 10 saídas digitais simultâneas;

Tempo mínimo de atualização 100ms;

Os sinais podem ser alterados no tempo de acordo com a descrição em

um arquivo de texto simples.

Aquisição:

Máximo 16 entradas digitais simultâneas;

Tempo de amostragem 10ms ou frequência de amostragem 100Hz

Os sinais de saída podem ser exportados os para arquivo (bmp ou xls)

Os sinais criados são exatamente os mesmos criados para o caso de teste

do Model-in-the-Loop e Software-in-the-Loop. Estes sinais não serão ilustrados da

mesma forma pois, como dito, foram gerados por programas diferentes mas, se

analisados com atenção, possuem o mesmo comportamento no tempo. Estes sinais

são demonstrados na Figura 36.

Figura 36 - Entradas criadas para o caso de teste do RCPFonte: Elaborado pelo Autor (2014)

61

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

entradas que simulam o nível da bateria e a posição da chave de ignição. Estes

sinais podem ser vistos na Figura 37.

Figura 37 - Entradas relevantes para o funcionamento do sistemaFonte: Elaborado pelo Autor (2014)

Após a definição de todas as entradas, foi necessário determinar como estas

entradas serão conectadas ao MABX. Para isso foi mapeado todas as entradas e

saídas do MABX e estas entradas foram conectadas as entradas e saídas do DAQ.

Após todas as conexões terem sido checadas a simulação pode ser feita e

seus resultados são apontados no item 4.3.

4 RESULTADOS

62

Após desenvolvidas todas as modelagens e acertos necessários para todas

as fases que fazem parte do escopo deste trabalho, é necessário rodar as

simulações e tarefas inerentes a cada uma das etapas. Para facilitar a leitura e o

entendimento, este capítulo será também dividido em partes e na mesma sequência

do desenvolvimento.

4.1 MODEL-IN-THE-LOOP

Como explicado no capítulo 2, a fase de MIL executa a simulação do modelo

criado em ambiente Simulink®. Portanto fazendo uso das entradas criadas e

demonstradas anteriormente, fez se a simulação do sistema em um tempo de 10

segundos.

Para ajudar a observação e comparação dos sinais e a consequente

validação do modelo, os sinais de saída serão colocados lado a lado com os de

entrada, gerados nos signal builders. Esta comparação pode ser vista na Figura 38.

Figura 38 - Comparação das entradas do modelo e as saídas verificadas nos scopesFonte: Elaborado pelo Autor (2014)

63

Para analisar os dados é necessário lembrar que tanto a posição da chave

de ignição quanto o nível de bateria ditam se o sistema funcionará o não. Portanto

quando algum destes sinais não estiver de acordo com os pré-requisitos, o sistema

não deve apresentar nenhum sinal alto.

Para resumir e facilitar o entendimento da verificação, o Quadro 2 mostra

que os requisitos relatados no Quadro 1 foram satisfeitos.

Chave de Ignição:

A chave de ignição está pelo menos na posição “Acc” de t=60 até t=8.

Luz de posição:

REQ-01 e REQ-02: A luz de posição está ativa durante o intervalo de t=0.5 até t=9. A

saída 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 saída

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 saída

mostra que este caso está ativo de t=1.5 até t=4 e de t=6 até t=7.3.

Luz indicadora de direção esquerda

REQ-07 e REQ-08: A luz indicadora de direção esquerda está ativa de t=5 até t=6 e

de t=8.5 até t=9. Além disso o botão de emergência está ativo de t=1 até t=2.5 e de

t=5.5 até t=6.5. A saída mostra que este caso está ativo de t=1 até t=2.5 e de t=5 até

t=6.5.

Luz indicadora de direção direita

REQ-09 e REQ-10: A luz indicadora de direção direita está ativa de t=3 até t=3.5 e de

t=6 até t=7. Além disso o botão de emergência está ativo de t=1 até t=2.5 e de t=5.5

até t=6.5. A saída 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 botão de alerta está ativo ambas as luzes de

indicação de direção estão ativas.

Luz de ré:

REQ-12 e REQ-13: a luz de ré está ativa de t=4 até t=6. A saída 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

saída 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.

64

Quadro 2 - Observações e verificação dos requisitos de funcionamentoFonte: Elaborado pelo Autor (2014)

Após a verificação pode-se dizer que a fase de Model-in-the-Loop foi

cumprida com sucesso. Todas as saídas correspondem com o desejo demonstrado

no momento da criação das entradas. Provou-se através da criação de entradas

interligadas no tempo que não há erros de lógica no sistema.

Com isso a primeira fase de um projeto para criação de um sistema

direcionado para uso em automóveis foi satisfeita. Na sequência 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 código em linguagem

C, a partir do modelo criado para o MIL, que representa o funcionamento do

controlador.

A verificação desta fase pode ser mais simples do que a efetuada para o

MIL, pois como já foi comprovado que as saídas da fase anterior estão conforme o

esperado, podemos apenas comparar as saídas do MIL com as do SIL

O controlador que foi testado nesta fase agora é representado pelo código

em linguagem C gerado automaticamente pelo Simulink®. Existe uma grande

facilidade em executar o SIL utilizando esta ferramenta computacional. É possível

gerar a S-Function e incluir o código automaticamente utilizando uma função do

próprio programa. Seria possível também com o Simulink®, gerar um código

genérico em C e utilizar um bloco diferente de S-Function e adicionar manualmente

o código, porém o modo automático funciona perfeitamente.

A Figura 39 traça um comparativo destas saídas. Como pode-se ver as

saídas são idênticas provando que o código gerado é condizente com o

funcionamento esperado e baseado nos pré-requisitos definidos no início do projeto.

65

Figura 39 - Quadro comparativo entre as saídas da fase MIL com as da fase SILFonte: Elaborado pelo Autor (2014)

4.3 RAPID CONTROL PROTOTYPING

Para que haja a validação do sistema no Rapid Control Prototyping o

procedimento é muito parecido com os outros métodos. Novamente é necessário

comparar os sinais gerados como entradas do caso de teste e comparar com os de

saída. Portanto é necessário compararmos os sinais demonstrados na Figura 36 do

capítulo 3.6 e compararmos com os obtidos nas saídas do DAQ e demonstrados no

LabVIEW®, sempre levando em consideração os sinais demonstrados na Figura 37

do capítulo 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 saídas do MABX. Apesar disso é claro que o sistema funciona perfeitamente e nos

oferece as saídas conforme o esperado.

66

Levando em consideração este fato e observando as restrições causadas ao

sistema pelas entradas demonstradas na Figura 37, pode-se afirmar que a validação

para RPC foi executada com sucesso. Se observarmos os resultados e tempos

relatados nos itens 4.1 e 4.2, referente a validação do Model-in-the-Loop e do

Software-in-the-Loop, chegamos à conclusão que o resultado foi idêntico.

A Figura 40 coloca lado a lado estes dados para facilitar a comparação e

validação.

Figura 40 - Comparação dos sinais de entrada e saída para o RPCFonte: Elaborado pelo Autor (2014)

Observando o gráfico do LabVIEW é possível ver que os casos não estão

alinhados corretamente. Isto porque, o RCP foi inicialmente testado em uma planta

física, e nesta planta física o sinal das luzes de posição acionaram LEDs referentes

ao sistema de luzes de posição traseiro e dianteiro. Desta forma é necessário

comparar a entrada das luzes de posição, no lado esquerdo da figura 40, com as

duas primeiras linhas do gráfico de sinais de saída, do lado direito da imagem.

Para facilitar o entendimento da validação do RCP, os gráficos de saída

foram então divididos em dois grupos. O primeiro apresenta a comparação apenas

das luzes de posição, luz baixa, luz alta e luz de freio. Esta comparação é vista na

figura 41.

67

Figura 41 – Grupo 1 de validação para RCP


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

ré. A comparação do grupo 2 pode ser vista na figura 42.

Figura 42 – Grupo 2 de validação para RCPFonte: Elaborado pelo Autor (2014)

Analisando o gráfico podemos ver que, exatamente como nas fases de MIL

e SIL, o sistema se comportou corretamente. Os requisitos foram todos respeitados,

inclusive o de nível de bateria, visto que nada no sistema funciona após o tempo de

t=7.3 s. O sinal de pisca no RCP funcionou conforme o esperado, respeitando a

lógica que faz com que o sinal funcione de maneira intermitente quando ativo.

68

5 CONCLUSÃO

A engenharia de software automotiva consiste na adoção de métodos,

processos, ferramentas e padronizações adequados que assegurem aos produtos

automotivos um nível de qualidade, confiabilidade, segurança, satisfação as

regulamentações e conforto, perceptíveis e mensuráveis aos clientes e todos

envolvidos no processo.

A elevada quantidade em linhas de código dos veículos se caracteriza pela

grande quantidade de conteúdos funcionais que os automóveis possuem

atualmente, como funções de iluminação, segurança, conforto, sistemas de

assistência ao motorista, detecção de ponto cego entre outros. Esta proliferação de

conteúdos funcionais faz com que o software em automóveis seja um elemento que

proporcione características diferenciadas do produto ao consumidor, sendo

considerado como um elemento facilitador que pode proporcionar novas

funcionalidades aos requisitos de atores de um automóvel como usuário,

concessionária, ambiente e regulamentações.

Esta comparação ao nível de linhas de código é um exemplo ilustrativo para

apresentar o nível de complexidade que os veículos atuais apresentam quando

observamos ao nível de desenvolvimento, manutenção e recursos necessários. Isto

porque fica claro que o nível de complexidade em todos os níveis vai crescendo de

forma exponencial.

Dentro deste cenário a utilização de métodos como o Model Based Design e

o Rapid Control Prototyping se demonstram excelentes ferramentas para diminuir o

tempo de desenvolvimento de novos produtos para automóveis e

concomitantemente balizam diversos testes que aumentam a segurança e

confiabilidade destes produtos.

Neste trabalho verificou-se que, utilizando os conceitos do MBD, durante

todo o desenvolvimento foi possível verificar a validade do sistema. Desde a

confecção da primeira planta em Simulink, vários testes puderam ser executados.

Estes testes possibilitaram que os erros encontrados pudessem ser rapidamente

excluídos e possíveis melhorias fossem adicionadas ao modelo em fases iniciais.

69

Este tipo de desenvolvimento permite que, ao chegar em fases avançadas

de um projeto, todas as lógicas criadas tenham mais confiabilidade resultando em

um sistema mais seguro e de maior qualidade.

REFERÊNCIAS

BRASIL. Lei nº 9.503., de 23 de dezembro de 1997. Código de Trânsito Brasileiro.. Brasília, Disponível 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. Disponível 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.1838-1843, 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. Disponível 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. Disponível em: <http://www.ni.com/white-paper/4074/en/>. Acesso em: 25 jun. 2014.

70

KELEMENOVÁ, Tatiana et al (Org.). Shortening the Embedded Design Cycle with Model-Based Design. 2013. Disponível 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. Disponível em: <http://machinedesign.com/archive/model-based-design-mechatronics-systems>. 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? Disponível em: <http://www.mathworks.com/model-based-design/>. Acesso em: 08 dez. 2014.

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 (Graduação) - 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.

71

ANEXO A - Código em linguagem C gerado para a S-Function do SIL

72

A.1 CÓDIGO EM LINGUAGEM C GERADO PARA A S-FUNCTION DO SIL

No item 3.5 foi desenvolvido o método de Software-in-the-Loop. Para que fosse

possível executar os testes foi necessário embarcar um código em linguagem C

gerado a partir do modelo da planta de controle. O código foi gerado

automaticamente pelo Simulink® e será demonstrado neste Apêndice. É necessário

salientar que este código é apenas parte de todos os códigos gerados para este

sistema. Por se tratar de um sistema complexo e com muitos subsistemas o

programa gera 10 arquivos de código separados. Este disponibilizado aqui é o

principal e possui os chamados (calls) para os outros códigos.

/* Include files */

#include "SILELS_sfun.h"

#include "SILELS_sfun_debug_macros.h"

#include "c1_SILELS.h"








/* Type Definitions */

/* Named Constants */

/* Variable Declarations */

/* Variable Definitions */

73

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;


74


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")) {





75

} 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:



break;

} case 6:



break;

} case 7:



break;

} case 8:

76



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 */


77


if (strcmp(commandName,"get_autoinheritance_info"))

return 0;

mxGetString(prhs[2], aiChksum,sizeof(aiChksum)/sizeof(char));

aiChksum[(sizeof(aiChksum)/sizeof(char)-1)] = '\0';

{ unsigned int chartFileNumber;



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) {



78

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;

}

plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);

break;

} case 8:

{ if (strcmp(aiChksum, "7t1ZED8HsMHA4gQqIPvMvG") == 0) {



break;


break;

} default:

79


} } 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

*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:






80


break;

} case 3:







break;

} case 4:







break;

} case 5:







break;

} case 6:







81

break;

} case 7:







break;

} case 8:







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));

82

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) {


83


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);

84

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;

}}

Documents

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