Prototipagem Rápida de Funções para Módulo de Controle Eletrônico (ECM)

X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 � AEA

1

PROTOTIPAGEM DE FUNÇÕES PARA MÓDULO DE CONTROLE ELETRÔNICO

(ECM) COM NI LABVIEW E A PLATAFORMA NI COMPACTRIO

Ricardo Andrade Ranal e Robson Alves Nascimento

MWM International RESUMO

Com a crescente demanda por novas funções de controle nos sistemas de injeção eletrônica de

combustível, são requeridas freqüentes alterações no software base desses sistemas, que tem

longos prazos e elevados custos de desenvolvimento até que a função esteja validada e

aprovada. Isso se deve ao fato de que o desenvolvimento de hardware e software, na maioria das empresas fornecedoras de sistemas de injeção, é realizado nos centros de desenvolvimento

espalhados pelo mundo. Levando em conta tal premissa, e sabendo que o desenvolvimento de software possui, pelo menos, as seguintes etapas:

Descrição dos requisitos Modelagem Simulação Prototipagem Testes funcionais Codificação Implementação em módulos Testes de homologação Liberação final

O objetivo desse trabalho é abordar o tema de maneira a apresentar uma proposta de baixo custo para simulação e prototipagem de funções de software para sistemas de injeção

eletrônica de combustível, baseado em um controlador programável externo com tecnologia

FPGA (Field Programable Gate Array) para implementação dos protótipos das funções. E somente após o modelo da função ter alcançado um nível de maturidade satisfatório seria

então encaminhado para sua finalização nos centros de desenvolvimento, diminuindo os

custos totais de projeto já que a parte inicial do desenvolvimento seria realizada no local de origem da demanda. INTRODUÇÃO

Os fornecedores de sistemas de injeção eletrônica de combustível possuem toda estrutura

necessária para desenvolver as funções de software e circuitos específicos de hardware, porém

esses recursos estão espalhados ao redor do mundo, o que dificulta o acesso a eles. Quando um cliente solicita algum desenvolvimento em software ou hardware os custos são elevados e

o prazo geralmente é muito longo, o que muitas vezes inviabiliza o desenvolvimento do


2

projeto na sua melhor forma. Esse é o paradigma da engenharia versus custos e prazos. O que

acaba sendo implementado, na prática, é um software com as funcionalidades reduzidas ou

são utilizados blocos prontos (black boxes) já desenvolvidos previamente para outras

aplicações, onde nem sempre todas as funções serão utilizadas. Cada vez mais o desenvolvimento de funções de software é considerado uma questão

estratégica pelas montadoras e fabricantes de motores de combustão, pois aqueles que tiverem

a capacidade de desenvolver e testar protótipos de funções específicos para sua necessidade

terão uma vantagem competitiva no mercado. Se fosse possível realizar as etapas iniciais do

desenvolvimento das funções (Descrição dos Requisitos, Modelagem, Simulação,

Prototipagem e Testes Funcionais) na própria montadora ou no fabricante de motores,

possivelmente, haveria uma redução significativa nos custos totais juntamente com a

propriedade intelectual da função específica ou do algoritmo. Como seria possível realizar tal

desenvolvimento em uma montadora ou fabricante de motores? A descrição de requisitos e a modelagem de funções de software realizadas utilizando as

técnicas da engenharia de software através de abordagens de modelos estruturados ou

orientados a objetos, são essenciais. Porém, sendo considerados pré-requisitos, não fazem

parte desse estudo. A simulação, a prototipagem de funções e os testes funcionais dependem de softwares

aplicativos e hardware para implantação. Para realizar essas etapas existem basicamente duas

opções no mercado:

1ª) Utilizar o mesmo software e hardware do fornecedor de sistemas de injeção para

desenvolver a simulação e os protótipos de funções. É uma alternativa excelente do

ponto de vista técnico, pois possui integração total com a plataforma de hardware e software originais. Suas desvantagens são o elevado custo (centenas de milhares de

dólares) e a dificuldade de treinamento de pessoal (aplicativos altamente complexos).

2ª) Utilizar um controlador externo e uma plataforma de software aberta para realizar as simulações e testes com as funções protótipos. As maiores vantagens são o baixo custo

(poucos milhares de dólares) e a facilidade de implementação de modelos em

plataforma aberta. A desvantagem é a necessidade de utilizar um controlador externo,

não sendo possível implementar as funções no módulo controlador do motor. Esse trabalho irá abordar a segunda alternativa: utilizar um controlador externo e uma

plataforma de software aberta. Com essa configuração é possível construir um sistema de

baixo custo e fácil implementação, o que sempre é interessante do ponto de vista financeiro,

viabilizando assim, sua aplicação. 1. DESCRIÇÃO

O sistema de simulação e prototipagem de funções de software proposto nesse artigo, é

baseado na plataforma de software de desenvolvimento LabVIEW e no controlador externo CompactRIO, ambos da National Instruments.


3

O software de desenvolvimento consiste em um ambiente gráfico, com várias ferramentas

para sistemas de medição, análise e controle, com uma linguagem de programação através

de símbolos e blocos funcionais gráficos. Possui plataforma aberta, o que facilita a sua

�interface� com outros sistemas e equipamentos e suporta múltiplos protocolos de

comunicação.

Figura 1. Exemplo de um controlador PID implementado no ambiente de desenvolvimento.

O controlador externo é robusto e reconfigurável. Possui um processador local para obter

performance ultra rápida podendo processar funções de controle em tempo real. Baseado

em dispositivos FPGA, que são dispositivos programáveis formados por células com

milhares de portas lógicas configuráveis utilizadas de acordo com a necessidade da

aplicação, possui também módulos de I/O que são instalados de acordo com a aplicação,

inclusive com I/O para barramento CAN.

Figura 2. Detalhe construtivo do controlador externo.


4

O sistema utilizado para simulação e teste das funções protótipos, consiste na função

implementada na plataforma do software de desenvolvimento e no controlador externo. A função desenvolvida é carregada no controlador externo que processa os algoritmos e

realiza as funções de controle. A flexibilidade é total, sendo possível implementar

controladores digitais de malha aberta ou fechada, com atuação direta de dispositivos via

saída PWM ou analógica. Também é possível realizar a conexão direta com sensores

analógicos ou digitais. O conjunto funciona como um �by-pass� trazendo para fora do

controlador original os parâmetros necessários para o processamento no controlador

externo, ou seja, independente do sistema de injeção eletrônica. A comunicação é feita via

barramento CAN ou conexão direta com sensores e atuadores. A simulação pode ser realizada em computador, através de estímulos padrões ou através

de algum modelo específico previamente modelado no software de desenvolvimento.

Figura 3. Algoritmo de controle implementado no controlador externo. 2. APLICAÇÃO

Nas montadoras e nos fabricantes de motores há sempre necessidade de desenvolvimento

e testes de novas funções de software de controle de algum dispositivo, bem como os algoritmos de diagnose do sistema.

O tipo de situação mais comum de se encontrar é a impossibilidade de se ter acesso aos

desenvolvedores do software que, geralmente, estão alocados em outros continentes. Por

isso, faz-se necessário diversas reuniões com os representantes locais para descrição do

software que serão posteriormente encaminhados para os especialistas. Quando a informação chega ao programador ela pode conter erros que resultam em

�bugs� no software que só serão descobertos, muitas vezes, na hora do teste no

dinamômetro ou no veículo. Esse tipo de problema obriga a repetição da parte final do

ciclo de desenvolvimento, gerando várias versões de software até se corrigir todos os

�bugs�, acarretando atrasos e aumento dos custos. Grande parte desses problemas podem ser evitados, com a utilização prática da simulação

e testes dentro da própria montadora ou fabricante de motores, pois o algoritmo somente

seria entregue para codificação depois de ter atingido um nível de maturidade sem �bugs�

e, conseqüentemente, haveria uma sensível diminuição no número de liberações de

software com erros.


5

válvula

admissão

válvula

escape

válvula

EGR

bomba

de vácuo

válvula

controle

fluxo de ar ECM

admissão

escape

válvula

Throttle

3. ESTUDO DE CASO

Apresentação de um caso prático onde foi necessário desenvolver uma função de controle

protótipo para corrigir a atuação da válvula EGR em um determinado evento transiente de pressão de admissão onde o nível de emissões (NOx) era prejudicado. A função existente no módulo de injeção eletrônica não era capaz de tomar uma ação em cima do evento transiente. Era necessário desenvolver e implementar uma função

protótipo baseada nos requisitos de projeto designados pelo cliente em conjunto com o departamento de engenharia de performance e emissões.

Figura 4. Diagrama de blocos dos requisitos da função protótipo.

A válvula EGR (Exhaust Gas Recirculation) tem como objetivo reduzir as emissões de

NOx (óxidos de nitrogênio) mantendo a temperatura de combustão abaixo da faixa crítica.

Para isso, através dessa válvula, é introduzida uma pequena quantidade de gases de escapamento (recirculação) na admissão de maneira a "contaminar" a mistura ar-combustível.

Figura 5. Esquema da recirculação dos gases de escapamento (EGR).


6

Sendo assim, a função a ser prototipada precisaria corrigir a atuação da válvula EGR

simultaneamente com a atuação da válvula Throttle (admissão). Na ocorrência do evento transiente, ambas as válvulas deveriam atuar de maneira inversa: a EGR totalmente fechada e a Throttle totalmente aberta. Depois de transcorrido o evento, ambas deveriam retornar aos seus regimes normais de funcionamento. A função original não poderia ser

alterada.

Figura 6. Proposta utilizada como referência no desenvolvimento da função protótipo. Atuação da válvula

EGR (verde) em função do evento transiente de pressão de admissão (vermelho). Era necessário também que a função atendesse às condições da máquina de estados

designada nos requisitos.

Figura 7. Máquina de Estados da função protótipo.


7

Decidiu-se que as variáveis de entrada seriam lidas diretamente do barramento CAN da ECM e posteriormente processadas pela função protótipo no controlador externo compact RIO (cRIO). Ainda seguindo os requisitos do projeto, esse processamento deveria ser realizado em 5ms no máximo. Ambas as válvulas deveriam ser controladas por PWM (Pulse Width Modulation) com o duty cycle variando de 5% a 95% e freqüência de 140 Hz para a vávula EGR e 250 Hz para a válvula Throttle. O sistema de simulação com a respectiva função protótipo teria que ser desenvolvido, testado e validado em 2 semanas antes de sua implementação na ECM pelo fabricante.

4. CONCLUSÃO

Definiu-se que a arquitetura do sistema ficaria da seguinte maneira:

Figura 8. Arquitetura do Sistema de Simulação e suas interfaces.

O software foi, basicamente, dividido em três partes:

Host (PC): consiste na indicação gráfica dos acionamentos das válvulas, indicação

numérica das variáveis de entrada e comunicação com o controlador externo. Real-Time (cRIO): algoritmo da função protótipo, pontos calibráveis de trabalho

das válvulas, posição da máquina de estados e comunicação com o barramento

CAN e o host. FPGA (chip no cRIO): gerenciamento da modulação por largura de pulso (PWM)

dos sinais de acionamento das válvulas.

chicote com

sensores e

atuadores

ECM

NI cRIO

CAN

ethernet

válv. Throttle

válv. EGR

notebook rodando

software de medição e

calibração (NI LabVIEW)

placa controladora rodando

software de simulação e

controle (NI LabVIEW)

PWM com DO


8

Figura 9. Tela e código do software do Host (PC).

Figura 10. Código do software Real-Time (cRIO).

Todo o sistema foi desenvolvido, testado e validado em 5 dias. Sendo 2 dias para o desenvolvimento da função e montagem do sistema e 3 dias para os testes.


9

Durante os testes realizados no veículo houve a necessidade de se realizar alguns ajustes no algoritmo da função. É importante ressaltar que todas as alterações ocorreram sem que

fosse necessário qualquer manuseio do cRIO ou qualquer alteração nas instalações do

sistema de simulação. Todas as modificações foram feitas apenas com a mudança do software via computador e o posterior �download� da função para o ambiente Real-Time da placa controladora do cRIO. Analisando-se os dados dos testes constatou-se uma pequena diminuição no nível de NOx,

porém nada representativo. Verificou-se a possibilidade da função protótipo conter algum

tipo de erro. Nada foi encontrado, estando a função absolutamente de acordo com os requisitos do projeto. Dentre outras coisas, uma questão levantada pelo cliente a respeito da possível

ineficiência da simulação pareceu plausível. Era possível que o cRIO tivesse um atraso no processamento da função protótipo em relação ao processamento da ECM comprometendo a estratégia de controle? Para sanar essa dúvida realizou-se um pequeno experimento que consistia na medição do

acionamento das válvulas pela ECM e pelo cRIO simultaneamente com um osciloscópio.

Figura 11. Sinais de controle da válvula EGR via ECM (amarelo) e via cRIO (verde).


10

Com as medições, notou-se que realmente existia um atraso do cRIO em relação à ECM.

Mais precisamente um atraso de 38,8µs. Um valor insignificante levando-se em consideração que o loop de controle era de 5ms, ou seja, 5000µs. Ainda sim, cabe ressaltar uma outra análise feita em cima das medições realizadas. No instante em que o cRIO apresenta 10V em sua saída a ECM ainda encontra-se com 7V na sua. Com isso, se a diferença de velocidade de processamento e acionamento das válvulas já era pequena, com esse dado ela torna-se, praticamente, desprezível.

Figura 12. Medição do atraso de processamento entre a ECM e o controlador externo através da defasagem

dos sinais de controle da válvula EGR. Concluiu-se então que, apesar da função protótipo estar de acordo com os requisitos, a estratégia de controle proposta não era a melhor para a diminuição dos níveis de NOx

ocorridos nos eventos transientes anteriormente citados. Talvez houvesse a necessidade de um estudo mais aprofundado com o acréscimo de mais variáveis de entrada e,

conseqüentemente, uma função de controle mais aprimorada. Com esse resultado, resolveu-se suspender o projeto temporariamente. De qualquer maneira, as ferramentas utilizadas para a simulação de função provaram-se extremamente funcionais. Apesar da suspensão do projeto não houve qualquer tipo de

investimento adicional em equipamento nem tão pouco em treinamentos para a prototipagem da função de controle. Utilizaram-se tecnologias já existentes na empresa e

≈ 7 V

Atraso:

38,8000 µs

≈ 10 V


11

conhecimentos adquiridos de outros projetos. Fora isso, os conhecimentos absorvidos nesse experimento são inestimáveis na utilização das próximas simulações. Do contrário, seria necessário um investimento de 50.000,00 euros (cotação de 07/2007) para solicitar ao fabricante da ECM que prototipasse uma função onde, posteriormente, concluiría-se não ser apropriada para a resolução do problema. Um investimento altíssimo com os agravantes de não se reter os conhecimentos e o domínio da tecnologia e muito menos a conquista do projeto solicitado pelo cliente.

5. REFERÊNCIAS

ENGENHARIA DE SOFTWARE � ROGER S. PRESSMAN � ISBN 85 346 0237 9, Pearson Makron Books, 1995.

SISTEMAS DIGITAIS PRINCÍPIOS E APLICAÇÕES � RONALD J. TOCCI �

NEAL S. WIDMER � ISBN 85 216 1179 X.

AUTOMOBILE ELECTRICAL AND ELECTRONIC SYSTEMS � TOM DENTON � ISBN 0 7680 0271 0, SAE International, 2000.

ELETRÔNICA EMBARCADA AUTOMOTIVA � ALEXANDRE DE ALMEIDA

GUIMARÃES � ISBN 978 85 365 0157 4, Editora Érica, 2007.

TUT_2856_COMPACTRIO.PDF � http://zone.ni.com/devzone/cda/tut/p/id/2856 � ACESSADO EM 22/04/2008.

LabVIEW Fundamentals Manual � http://www.ni.com/pdf/manuals/374029a.pdf �

ACESSADO EM 22/04/2008.

http://zone.ni.com/devzone/cda/tut/p/id/2856

Documents

Prototipagem Rápida de Funções para Módulo de Controle Eletrônico (ECM)