X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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
1
X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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.
2
X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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.
3
X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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.
4
X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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 arcombustível. admissão
válvula admissão
válvula escape
válvula EGR
válvula Throttle
bomba de vácuo
escape
válvula controle fluxo de ar
ECM
Figura 5. Esquema da recirculação dos gases de escapamento (EGR).
5
X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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.
6
X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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:
placa controladora rodando software de simulação e controle (NI LabVIEW) NI cRIO
ethernet
chicote com ECM
CAN
sensores e
notebook rodando
atuadores
software de medição e calibração (NI LabVIEW) válv. Throttle
PWM com DO
válv. EGR
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.
7
X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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.
8
X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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).
9
X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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.
≈7V Atraso:
38,8000 µs
≈ 10 V
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
10
X Seminário sobre a Eletro-Eletrônica Aplicada a Mobilidade São Paulo, 29 de maio de 2008 – AEA
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.
11